Something like the following:
-------------------------------------------------------------------------
... at vrituall address c0000001
current->txx.cr3=00101000, %cr3=00101000
*pde=00102067
*pte=00000027
Oops: 0000
CPU: 0
EIP: 0010[<0018d912>]
EFLAGS: 00010202
eax: 00000001 ebx: 00000000 ecx: 00092f60 edx: 00092f64
esi: 00000000 edi: 00095808 ebp: 00000000 esp: 00092f24
ds: 0018 es: 0018 fs: 002b gs: 0018 ss:0018
Process swapper (pid: 1, process nr: 1 stackpage=00092000)
Stack: 00000000 00000000 00000000 00009000 00092f69 00000000 00092f6e 00000008
0000017d 00092f6c 00000000 0008e000 00001000 00000246 00000000 00000002
00000000 00092f64 00000000 00000000 00090000 0018e2ca 00000000 001bea80
Call Trace: [<0018e2ca>][<001899b3>][<00168e81>][<0012dd68>][<0010a5b2>][<0011e4d0>][<001093aa>]
[<001091b4>][<001091bb>][<00109360>]
Code ff 08 88 d6 e5 00 00 8b b7 f0 00 00 00 43 85 f6 0f 84 54
-------------------------------------------------------------------------
no warranty for absolut correctness :-)
> > This oops occures on an i486-PCI-System with saturn II Rev 4 (without bug),
> > ncr53c810, and an amd586-p75 ... maybe I should check this with my old
> > amd486dx4-100.
> >
> > On other systems on work (all i586) there are no problems with ncr53c810
> > and 53c7,8xx driver .... timing problem?
>
> Or a NULL pointer dereference that isn't seen by the Pentium machines because
> the pentium 4MB pages hide the problem (the kernel NULL address is actually
> mapped to physical address 0 on Pentiums). You can try this by undefining
> "USE_PENTIUM_MM" in asm-i386/pgtable.h and see if the pentiums crash..
Hmmm --- interesting point ... I -- or better -- we will try it :-)
>
> Linus
>
Thanks
Werner