* Re:Re: [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops
@ 2003-11-18 23:48 Jon Foster
2003-11-19 3:24 ` Zwane Mwaikambo
0 siblings, 1 reply; 5+ messages in thread
From: Jon Foster @ 2003-11-18 23:48 UTC (permalink / raw)
To: linux-kernel; +Cc: zwane
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re:Re: [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops
2003-11-18 23:48 Re:Re: [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops Jon Foster
@ 2003-11-19 3:24 ` Zwane Mwaikambo
2003-11-19 5:45 ` Andrew Morton
0 siblings, 1 reply; 5+ messages in thread
From: Zwane Mwaikambo @ 2003-11-19 3:24 UTC (permalink / raw)
To: Jon Foster; +Cc: linux-kernel
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);
}
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops
2003-11-19 3:24 ` Zwane Mwaikambo
@ 2003-11-19 5:45 ` Andrew Morton
2003-11-19 6:50 ` Zwane Mwaikambo
0 siblings, 1 reply; 5+ messages in thread
From: Andrew Morton @ 2003-11-19 5:45 UTC (permalink / raw)
To: Zwane Mwaikambo; +Cc: jon, linux-kernel
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?
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops
2003-11-19 5:45 ` Andrew Morton
@ 2003-11-19 6:50 ` Zwane Mwaikambo
2003-11-19 7:24 ` Linus Torvalds
0 siblings, 1 reply; 5+ messages in thread
From: Zwane Mwaikambo @ 2003-11-19 6:50 UTC (permalink / raw)
To: Andrew Morton; +Cc: jon, linux-kernel
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops
2003-11-19 6:50 ` Zwane Mwaikambo
@ 2003-11-19 7:24 ` Linus Torvalds
0 siblings, 0 replies; 5+ messages in thread
From: Linus Torvalds @ 2003-11-19 7:24 UTC (permalink / raw)
To: Zwane Mwaikambo; +Cc: Andrew Morton, jon, linux-kernel
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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2003-11-19 7:24 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-11-18 23:48 Re:Re: [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops Jon Foster
2003-11-19 3:24 ` Zwane Mwaikambo
2003-11-19 5:45 ` Andrew Morton
2003-11-19 6:50 ` Zwane Mwaikambo
2003-11-19 7:24 ` Linus Torvalds
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).