On 10/04/2007 07:58 PM, William Cattey wrote:
>
> Sadly, the effect of the patch is the same as the most recent candidate
> patch from Jeremy Fitzhardinge: The EDID transfer still comes up all
> zeros.
>
I think maybe a better question is: why does read_edid still work?
The X server might be
Thanks very much for thinking about this and providing a revised
candidate patch.
Sadly, the effect of the patch is the same as the most recent
candidate patch from Jeremy Fitzhardinge: The EDID transfer still
comes up all zeros.
This is very perplexing to me. If I take the code that
Thanks very much for thinking about this and providing a revised
candidate patch.
Sadly, the effect of the patch is the same as the most recent
candidate patch from Jeremy Fitzhardinge: The EDID transfer still
comes up all zeros.
This is very perplexing to me. If I take the code that
On 10/04/2007 07:58 PM, William Cattey wrote:
Sadly, the effect of the patch is the same as the most recent candidate
patch from Jeremy Fitzhardinge: The EDID transfer still comes up all
zeros.
I think maybe a better question is: why does read_edid still work?
The X server might be making
On 09/25/2007 07:38 PM, William Cattey wrote:
>
> 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.
>
I think you need to zero both registers if you're using 2.6.16, and force
%eax as the source so
On 09/25/2007 07:38 PM, William Cattey wrote:
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.
I think you need to zero both registers if you're using 2.6.16, and force
%eax as the source so it
William Cattey wrote:
> Thanks very much for responding.
>
> From your two replies, I crafted the attached patch.
> Alas, the EDID transfer comes up all zeros.
> I see two possible causes of this behavior:
>
> 1. I misunderstood how you intended the file to be modified.
> 2. The fix for my bug is
Thanks very much for responding.
From your two replies, I crafted the attached patch.
Alas, the EDID transfer comes up all zeros.
I see two possible causes of this behavior:
1. I misunderstood how you intended the file to be modified.
2. The fix for my bug is NOT in correcting the audit call,
Thanks very much for responding.
From your two replies, I crafted the attached patch.
Alas, the EDID transfer comes up all zeros.
I see two possible causes of this behavior:
1. I misunderstood how you intended the file to be modified.
2. The fix for my bug is NOT in correcting the audit call,
William Cattey wrote:
Thanks very much for responding.
From your two replies, I crafted the attached patch.
Alas, the EDID transfer comes up all zeros.
I see two possible causes of this behavior:
1. I misunderstood how you intended the file to be modified.
2. The fix for my bug is NOT in
Jeremy Fitzhardinge wrote:
> @@ -306,19 +334,18 @@ static void do_sys_vm86(struct kernel_vm
> tsk->thread.screen_bitmap = info->screen_bitmap;
> if (info->flags & VM86_SCREEN_BITMAP)
> mark_screen_rdonly(tsk->mm);
> __asm__ __volatile__("xorl %eax,%eax; movl
William Cattey wrote:
> Your fix seems to have remedied a problem we are having with EDID
> fetches through vm86.c. At the present moment, we're trying to
> understand your cleanup so as to back port it to an earlier rev of the
> kernel (2.6.18).
>
> 3 questions for you:
>
> 1. Are we correct in
William Cattey wrote:
Your fix seems to have remedied a problem we are having with EDID
fetches through vm86.c. At the present moment, we're trying to
understand your cleanup so as to back port it to an earlier rev of the
kernel (2.6.18).
3 questions for you:
1. Are we correct in
Jeremy Fitzhardinge wrote:
@@ -306,19 +334,18 @@ static void do_sys_vm86(struct kernel_vm
tsk-thread.screen_bitmap = info-screen_bitmap;
if (info-flags VM86_SCREEN_BITMAP)
mark_screen_rdonly(tsk-mm);
__asm__ __volatile__(xorl %eax,%eax; movl %eax,%fs;
Your fix seems to have remedied a problem we are having with EDID
fetches through vm86.c. At the present moment, we're trying to
understand your cleanup so as to back port it to an earlier rev of
the kernel (2.6.18).
3 questions for you:
1. Are we correct in understanding that your
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.
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
Your fix seems to have remedied a problem we are having with EDID
fetches through vm86.c. At the present moment, we're trying to
understand your cleanup so as to back port it to an earlier rev of
the kernel (2.6.18).
3 questions for you:
1. Are we correct in understanding that your
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
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
The system was otherwise completely idle. The only active task was
starting the X server.
The failure is 100% reproducible on my test system.
We have not run a lot of different kernels per se. We ran 2.6.9, and
it was fine. When we ran RHEL 5, it came with 2.6.18. All we really
did
On Tue, Aug 14, 2007 at 04:52:54PM -0400, William Cattey wrote:
> The corruption originally looked like a race condition.
>
> Sometimes the EDID buffer would be all zeros.
> Sometimes it would contain partial data, and then the rest of the
> buffer filled with zeros.
> The amount of data
The corruption originally looked like a race condition.
Sometimes the EDID buffer would be all zeros.
Sometimes it would contain partial data, and then the rest of the
buffer filled with zeros.
The amount of data transferred into the buffer before going to all
zeros is non-deterministic.
Chuck Anderson <[EMAIL PROTECTED]> writes:
>
> If I'm reading correctly, it appears that the code above trashes the
> %fs and %gs registers, or otherwise doesn't leave them at zero before
> returning from the system call as the old code did. Is this a correct
> analysis?
The kernel runs
Please Cc: any replies, as we are not subscribed to linux-kernel.
Thanks.
Somewhere around 2.6.16.12 a call to audit_syscall_exit was added to
vm86.c:
static void do_sys_vm86(struct kernel_vm86_struct *info, struct task_struct
*tsk)
{
struct tss_struct *tss;
+ long eax;
/*
Please Cc: any replies, as we are not subscribed to linux-kernel.
Thanks.
Somewhere around 2.6.16.12 a call to audit_syscall_exit was added to
vm86.c:
static void do_sys_vm86(struct kernel_vm86_struct *info, struct task_struct
*tsk)
{
struct tss_struct *tss;
+ long eax;
/*
Chuck Anderson [EMAIL PROTECTED] writes:
If I'm reading correctly, it appears that the code above trashes the
%fs and %gs registers, or otherwise doesn't leave them at zero before
returning from the system call as the old code did. Is this a correct
analysis?
The kernel runs with
The corruption originally looked like a race condition.
Sometimes the EDID buffer would be all zeros.
Sometimes it would contain partial data, and then the rest of the
buffer filled with zeros.
The amount of data transferred into the buffer before going to all
zeros is non-deterministic.
On Tue, Aug 14, 2007 at 04:52:54PM -0400, William Cattey wrote:
The corruption originally looked like a race condition.
Sometimes the EDID buffer would be all zeros.
Sometimes it would contain partial data, and then the rest of the
buffer filled with zeros.
The amount of data transferred
The system was otherwise completely idle. The only active task was
starting the X server.
The failure is 100% reproducible on my test system.
We have not run a lot of different kernels per se. We ran 2.6.9, and
it was fine. When we ran RHEL 5, it came with 2.6.18. All we really
did
30 matches
Mail list logo
