William Cattey wrote:
> Andi,
>
> Sorry to have taken so long to take another step with this problem.
> Once my customers had a work-around, other priorities crowded out this
> project. Today Chuck and I did a little more work. We'd heard that a
> more recent kernel alleged to fix this stuff. Doing some digging, we
> came across this:
Hi,
I cleaned up some completely bogus code in vm86.c. I don't have any
context for your mail though: is my change causing you problems, or
does it fix something for you?
Thanks,
J
>
> (http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.20)
>
> commit 49d26b6eaa8e970c8cf6e299e6ccba2474191bf5
> Author: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
> Date: Thu Dec 7 02:14:03 2006 +0100
>
> [PATCH] i386: Update sys_vm86 to cope with changed pt_regs and %gs
> usage
>
> sys_vm86 uses a struct kernel_vm86_regs, which is identical to
> pt_regs, but
> adds an extra space for all the segment registers. Previously
> this structure
> was completely independent, so changes in pt_regs had to be
> reflected in
> kernel_vm86_regs. This changes just embeds pt_regs in
> kernel_vm86_regs, and
> makes the appropriate changes to vm86.c to deal with the new naming.
>
> Also, since %gs is dealt with differently in the kernel, this
> change adjusts
> vm86.c to reflect this.
>
> While making these changes, I also cleaned up some frankly bizarre
> code which
> was added when auditing was added to sys_vm86.
>
> Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
> Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
> Cc: Chuck Ebbert <[EMAIL PROTECTED]>
> Cc: Zachary Amsden <[EMAIL PROTECTED]>
> Cc: Jan Beulich <[EMAIL PROTECTED]>
> Cc: Andi Kleen <[EMAIL PROTECTED]>
> Cc: Al Viro <[EMAIL PROTECTED]>
> Cc: Jason Baron <[EMAIL PROTECTED]>
> Cc: Chris Wright <[EMAIL PROTECTED]>
> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
>
> Chuck and I took a stab at extracting what we thought was the relevant
> change to the audit_syscall_exit code, but we must have gotten it
> wrong. The EDID transfer always comes up zeros with our extract of
> Fitzhardinge's patch.
>
>
> At this point Chuck and I are trying to decide what will get us the
> best testing with the least effort. (We keep planning to test with a
> stock kernel, but last time that was on our TODO list, the project
> languished for a month.)
>
> Do you have a specific stock kernel revision to recommend we try on
> our test system currently running Red Hat's 2.6.18? Are we right to
> presume it would be 2.6.18-0 to demonstrate failure and 2.6.20.0 to
> attempt to demonstrate success?
>
> Are you the Andi Kleen who signed off on Fitzhardinge's patch, and if
> so do you have some insight for Chuck and I about what pieces are
> required to test and see if the bug really got fixed with his cleanup?
>
> I'd feel a lot more confident we were on the right track if I could
> just correctly patch Fitzhardinge's cleanup into the test setup I have
> now.
>
> -Bill
>
> ----
>
> William Cattey
> Linux Platform Coordinator
> MIT Information Services & Technology
>
> N42-040M, 617-253-0140, [EMAIL PROTECTED]
> http://web.mit.edu/wdc/www/
>
>
> On Aug 14, 2007, at 6:19 PM, Andi Kleen wrote:
>
>> On Tue, Aug 14, 2007 at 06:14:40PM -0400, William Cattey wrote:
>>> In fact, I had begun the process of assuring myself that I could
>>> indeed take a main line kernel, and install it in place of a Red Hat
>>> Kernel.
>>
>> Should normally work. Sometimes there are incompatibilities
>> with udev -- it is safest to just compile in the drivers you
>> need to avoid that -- but likely it would work even without
>> that on a modern distro.
>>
>>> Shall I check back with you after we've re-run the test after putting
>>> the stock kernel on the machine? It will be a couple weeks because
>>> they're moving my office on Thursday, I'm away on vacation the
>>> following week, and I'm still unsure of the procedure to follow to
>>> build a totally stock totally mainline kernel and put it into place
>>> instead of what Red Hat has made.
>>
>> Better report to the list again in case others want to chime in.
>> But you can put me into cc because I would need to merge
>> any resulting patch anyways.
>>
>> -Andi
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
