Bug 432945 - i8042 mouse fails in virtualized environment (between 2.6.18-8.el5 and 2.6.18-53.1.13.el5)
Summary: i8042 mouse fails in virtualized environment (between 2.6.18-8.el5 and 2.6.18...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel-xen
Version: 5.1
Hardware: i386
OS: Linux
low
low
Target Milestone: rc
: ---
Assignee: David Milburn
QA Contact: Martin Jenner
URL:
Whiteboard:
Depends On:
Blocks: 492570
TreeView+ depends on / blocked
 
Reported: 2008-02-15 10:49 UTC by Bowe Strickland
Modified: 2009-05-26 20:51 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-05-26 20:51:02 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
Backport of upstream changes to i8042.c --- does NOT fix the bug (8.81 KB, patch)
2008-09-03 19:45 UTC, Markus Armbruster
no flags Details | Diff
Proposed fix for bug 450918 --- does NOT fix the bug (669 bytes, patch)
2008-09-27 11:46 UTC, Markus Armbruster
no flags Details | Diff

Description Bowe Strickland 2008-02-15 10:49:29 UTC
A Red Hat Academy customer is reporting the following problem, with fairly 
specific diagnosis referenced from other forums.

>> I am running our classroom rha-server as a virtual machine using Microsoft
>> Virtual PC. The mouse was working fine under kernel version 2.6.18-8.el5. 
>> When I upgraded the kernel to version 2.6.18-53.1.13.el5 (using yum update
via rhn),
>> the mouse stopped  working.

>> If I reboot back into the old kernel, the mouse works again. I spent some time
>> trying to reconfigure /etc/X11/xorg.conf but to no avail.

>> Eventually I found some information on the web that suggested that this was
>> caused by a bug in the Linux source code introduced somewhere between
>> linux-source-2.6-17 and linux-source-2.6.19. The problem affected all Linux
>> distributions and both Microsoft Virtual PC and VM Ware.

"This is probably a duplicate of:

https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/91330
+<https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/91330>
+<https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/91330
+<https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/91330> >

https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/108221
+<https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/108221>
+<https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/108221
+<https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/108221> >

https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/108382
+<https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/108382>
+<https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/108382
+<https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/108382> >



...and it's clearly affecting all other distros too, so this might not be the
+right place, but here goes.



See line 630 of /usr/src/linux-source-2.6.20/drivers/input/serio/i8042.c:

--------------------------------------------------------------------------------
+-------------

 if (wait_for_completion_timeout(&i8042_aux_irq_delivered,

     msecs_to_jiffies(250)) == 0) {

/*

 * AUX IRQ was never delivered so we need to flush the controller to
 * get rid of the byte we put there; otherwise keyboard may not work.

 */

  i8042_flush();

  retval = -1;

 }

--------------------------------------------------------------------------------
+-------------

Commenting out the i8042_flush(); and retval = -1; lines 'fixes' the problem.



before:

$ dmesg | grep "i8042 AUX" || echo nothing nothing



after:

$ dmesg | grep "i8042 AUX" || echo nothing [ 69.766263] serio: i8042 AUX port at
+0x60,0x64 irq 12



BTW I increased the timeout from 250ms to 20 seconds, and it didn't make a
+difference, so that's not it. It's just not responding at all.

Comment 2 Markus Armbruster 2008-07-08 21:44:58 UTC
I don't have Microsoft Virtual PC, so I can't reproduce this myself.

The problem might be
linux-2.6-input-i8042_interrupt-race-deliver-bytes-swapped.patch
which went into 2.6.18-30.el5.  To confirm that, I built a test kernel without
the patch.  Does that fix the mouse?

http://et.redhat.com/~armbru/rpms/kernel-2.6.18-95.el5.bz432945.1armbru.i686.rpm
http://et.redhat.com/~armbru/rpms/kernel-2.6.18-95.el5.bz432945.1armbru.x86_64.rpm


Comment 3 Bowe Strickland 2008-08-21 18:42:27 UTC
Original customer was Kelly.Crouch.edu.au, am looking for way to add as a CC: to the bug but cannot.  manually forwarding bug number for comment...

Comment 4 Bowe Strickland 2008-08-22 11:30:29 UTC
On Fri, Aug 22, 2008 at 12:05:01PM +1000, Crouch, Kelly wrote:
> Hi Bowe, 
>  
> I tried to download the test kernel but it appears to not be there. There appear to be no files in http://et.redhat.com/~armbru/rpms/.
>  
> I can send you a virtual machine that demonstrates the problem. It is 1.3 GB as a compressed tar file; will expend to just under 4GB. I will try and send it from home as having difficulties from work. You will need to create a new virtual machine in virtual PC, using an existing hard drive. If you boot into the older kernel, the mouse works. If you boot into the latest kernel (I just updated it), the mouse does not work.
>  
> Virtual PC can be downloaded for free from:
> http://www.microsoft.com/downloads/details.aspx?familyid=04D26402-3199-48A3-AFA2-2DC0B40A73B6&displaylang=en
>  
> Hopefully you guys have a Windows PC somewhere for testing purposes! :-)
>

Comment 5 Markus Armbruster 2008-08-27 12:13:35 UTC
The kernels in comment#2 timed out.  I made new ones, and the customer confirms that they "fix" the problem.  This implicates linux-2.6-input-i8042_interrupt-race-deliver-bytes-swapped.patch

Comment 6 Markus Armbruster 2008-09-03 19:45:03 UTC
Created attachment 315679 [details]
Backport of upstream changes to i8042.c --- does NOT fix the bug

In the hope of finding our fix upstream, I backported all the changes to i8042.c that seemed possibly relevant.  Unfortunately, the problem persists.  We need to dig deeper.

Comment 7 Markus Armbruster 2008-09-27 11:46:52 UTC
Created attachment 317864 [details]
Proposed fix for bug 450918 --- does NOT fix the bug

RHEL-4's bug 450918 is also about virtual mice, and this patch reportedly helped there.  It doesn't here.

Comment 8 David Milburn 2008-12-09 23:19:37 UTC
Bowe,

I was able to reproduce this problem on a laptop running Windows XP, this is
failing because i8042_check_aux times out waiting on i8042_aux_irq_delivered
which should be getting set when testing the delivery of the AUX IRQ. 
i8042_aux_test_irq actually runs, but the problem is when i8042_aux_test_irq
reads data and expects to see 0xa5, but the value actually read is 0xa7

        str = i8042_read_status();
        if (str & I8042_STR_OBF) {
                data = i8042_read_data();
                if (i8042_irq_being_tested &&
                    data == 0xa5 && (str & I8042_STR_AUXDATA)) <===FAILS
                        complete(&i8042_aux_irq_delivered);
        }

So, i8042_check_aux returns -1 and then i8042_setup_aux returns -ENODEV
(this why it worked for you when you commented out "retval = -1", and
it didn't matter when you increased the timeout since the isr actually runs).

The reason you didn't see this under -8.el5 is i8042_check_aux doesn't 
try to test the AUX IRQ delivery test, the -18.53.el5 kernel is more consistent
with the upstream driver.

Per Markus, I booted up with "i8042.noloop=1" on the kernel command line
so that i8042_check_aux will bypass the AUX IRQ delivery test, and verified
the mouse works. Can you re-test after booting with this module parameter on
the kernel command line?

Thanks,
David

Comment 9 David Milburn 2009-05-26 20:51:02 UTC
Closing since the kernel command line option "i8042.noloop=1" can be used
to bypass the AUX IRQ delivery test, please re-open if necessary.


Note You need to log in before you can comment on or make changes to this bug.