Re:Re: [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops

Re:Re: [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops

[Jon Foster]

Hi,

> The other thing I've found printks to hide before is timing bugs / races.
> Unfortunately I can't see one here, but maybe someone else can ;-)
> Maybe inserting a 1ms delay or something in place of the printk would
> have the same effect?

One of my colleagues had an interesting bug caused by an
uninitialized variable - a printk() in the right place happened
to set the variable (which gcc had put in a register) to the
correct value for his code to work.

I've tried looking for uses of uninitialized registers in entry.S,
but the assembly there isn't easy to follow.

What happens if you replace the printk with assembly code
that clobbers eax, ecx, edx and (most of) eflags?  (Assuming
I've remembered the calling convention correctly, those are
the registers that printk will be overwriting).

Kind regards,

Jon

Re:Re: [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops

[Zwane Mwaikambo]

On Tue, 18 Nov 2003, Jon Foster wrote:

> > The other thing I've found printks to hide before is timing bugs / races.
> > Unfortunately I can't see one here, but maybe someone else can ;-)
> > Maybe inserting a 1ms delay or something in place of the printk would
> > have the same effect?
> 
> One of my colleagues had an interesting bug caused by an
> uninitialized variable - a printk() in the right place happened
> to set the variable (which gcc had put in a register) to the
> correct value for his code to work.

Very nice =)

> I've tried looking for uses of uninitialized registers in entry.S,
> but the assembly there isn't easy to follow.

I've walked that code and can't see anything wrong anywhere.

> What happens if you replace the printk with assembly code
> that clobbers eax, ecx, edx and (most of) eflags?  (Assuming
> I've remembered the calling convention correctly, those are
> the registers that printk will be overwriting).

Well i have tried a number of heavyweight functions, so far none of them 
have had the effect that a printk has had. It's also worth noting that a 
printk lookalike function such as the following, does not fix things 
either.

asmlinkage int kooh_la_la(const char *fmt, ...)
{
	return strlen(fmt);
}

Re: [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops

[Andrew Morton]

Zwane Mwaikambo <zwane@arm.linux.org.uk> wrote:
>
>  I've walked that code and can't see anything wrong anywhere.

fwiw, X comes up happily on a couple of boxes here, with the 4g/4g split
enabled.

Have you tried a different compiler?

Re: [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops

[Zwane Mwaikambo]

On Tue, 18 Nov 2003, Andrew Morton wrote:

> Zwane Mwaikambo <zwane@arm.linux.org.uk> wrote:
> >
> >  I've walked that code and can't see anything wrong anywhere.
> 
> fwiw, X comes up happily on a couple of boxes here, with the 4g/4g split
> enabled.

The exact same kernel runs fine on my other test boxes. But i really don't 
have faith in this compiler, it's the same one which constantly seems to be 
tripping into various problems.

> Have you tried a different compiler?

I just tried the RH9 2.96 and it also triple faulted. Oh my.. The only 
unique thing about this hardware compared ot the other stuff i have here 
is that it's an AMD K6. Everything else is Intel.

Re: [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops

[Linus Torvalds]

On Wed, 19 Nov 2003, Zwane Mwaikambo wrote:
> 
> I just tried the RH9 2.96 and it also triple faulted. Oh my.. The only 
> unique thing about this hardware compared ot the other stuff i have here 
> is that it's an AMD K6. Everything else is Intel.

Different TLB sizes (and organizations) etc can _easily_ matter, if the 
Intel one just happens to work because something stays in the TLB while 
the page table mapping is incorrect and keeps the system afloat.

Or - and in this case more likely - since the problem is fixed by running
a (complex) thing that trashes all over the DTLB/ITLB, it's more likely
that there might be a _missing_ TLB invalidate somewhere, and that the
Intel boxes stay up because they have a smaller TLB and the stale entry
gets flushed out early from them.

But you already tried a "flush_tlb_all()" which _should_ have flushed
absolutely everything, including global tables. I dunno. It could be
hitting a CPU bug too, of course. 

It would be interesting to hear if other K6 users see problems..

			Linus