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.
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
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...
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! :-) >
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
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.
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.
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
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.