Bug 432945
Summary: | i8042 mouse fails in virtualized environment (between 2.6.18-8.el5 and 2.6.18-53.1.13.el5) | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 5 | Reporter: | Bowe Strickland <bowe> | ||||||
Component: | kernel-xen | Assignee: | David Milburn <dmilburn> | ||||||
Status: | CLOSED WONTFIX | QA Contact: | Martin Jenner <mjenner> | ||||||
Severity: | low | Docs Contact: | |||||||
Priority: | low | ||||||||
Version: | 5.1 | CC: | armbru, dmilburn, xen-maint | ||||||
Target Milestone: | rc | ||||||||
Target Release: | --- | ||||||||
Hardware: | i386 | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2009-05-26 20:51:02 UTC | Type: | --- | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Bug Depends On: | |||||||||
Bug Blocks: | 492570 | ||||||||
Attachments: |
|
Description
Bowe Strickland
2008-02-15 10:49:29 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 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. |