Bug 8633 (Flaky-EDID-Fetch)
Summary: | Fetch of EDID 128 byte buffer by X server through vm86 INT 10 call is flaky. | ||
---|---|---|---|
Product: | Platform Specific/Hardware | Reporter: | William Cattey (wdc) |
Component: | i386 | Assignee: | other_other |
Status: | CLOSED PATCH_ALREADY_AVAILABLE | ||
Severity: | normal | CC: | khadgaray, protasnb |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 2.6.18-8 and 2.6.20 have been tested. | Subsystem: | |
Regression: | Yes | Bisected commit-id: | |
Attachments: | Patch to disable call to audit_syscall_exit |
Description
William Cattey
2007-06-15 12:30:58 UTC
Created attachment 11995 [details]
Patch to disable call to audit_syscall_exit
A friend helped me learn how to build a kernel. He also bench-checked the vm86.c code, and suggested that perhaps the registers required for reliable int10 emulation were being trashed by the call to audit_syscall_exit.
The attached patch disables the call to audit_syscall_exit.
With this patch applied, error messages complaining about freeing multiple contexts return, but the EDID data transfers are once again 100% reliable from inside the X server.
If someone familiar with the change to call audit_syscall_exit could re-examine that change, and supply an amended vm86.c, we'd be happy to test it. We didn't presume to understand things well enough to propose a better placement of the call.
Can you confirm the problem is still in 2.6.22+ and if so attach your boot log (dmesg) and dmidecode output if possible. If this problem wasn't happening with 2.6.9, you might have to try git bisect to find changes that caused it. Thanks. Bill, I think I found someone to look into the vm86. I suppose the problem is still there with latest kernel? Thanks very much. We've been working this bug with Red Hat at: https://bugzilla.redhat.com/show_bug.cgi?id=254024 The update since 8/26 is that the 2.6.21 kernel does NOT have the problem. Our current operating theory is that a change introduced at 2.6.20 remedied the problem: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=49d26b6eaa8e970c8cf6e299e6ccba2474191bf5 It looks like kernel.org need not worry about this bug. Now it's up to Red Hat to decide if a back port of stuff in 2.20 or later to their Enterprise kernel (2.6.18 baseline) is possible, feasable, sensible. I apologize for not updating this bug with the relevant status. Great, thanks for the update! |