Re: Another oops (1.3.93)

Matthew White (spooner@sunspot.tiac.net)
Fri, 26 Apr 1996 12:37:11 -0400 (EDT)


Hi Linus-

I do have a Cyrix chip. 486-DX2/66. And you know, I got another oops on
Apr. 23. As well, the 00000004 came up. I can send that to you too, if
you'd like. If it makes a difference, I also a victim of the sig11 bug
(I even got one while making clean!) but I 99.44% sure it's my cache memory.

-Matthew

On Fri, 26 Apr 1996, Linus Torvalds wrote:

>
>
> On Thu, 25 Apr 1996, Matthew White wrote:
> >
> > I got this one while compiling .95. Could someone post the "stress test"
> > script. I tried using 'make -j -l 3.50' but it ran out of virtual
> > memory. (With 16M physical and 32M swap.) Shouldn't 32M be enough?
>
> Sure should..
>
> Do you happen to have a Cyrix CPU, by any chance? This looks like the
> cyrix problem that has been seen before..
>
> > Unable to handle kernel paging request at virtual address 00000004
>
> "00000004" again..
>
> > current->tss.cr3 = 0081b000,
> > *pde = 00000000
> > Oops: 0002
> > CPU: 0
> > EIP: 0010:[<0011c90e>]
> > EFLAGS: 00010206
> > eax: 00002000 ebx: 00001000 ecx: 00000400 edx: 00948000
> > esi: 00948000 edi: 08076000 ebp: 00950000 esp: 006c2f50
> > ds: 0018 es: 002b fs: 002b gs: 002b ss: 0018
> > Process cpp (pid: 3785, process nr: 25, stackpage=006c2000)
> > Stack: 00000018 004f3980 00a724b0 00003adb 08074000 00003000 001d12a0 00950000
> > 00000000 000a724b 00001000 00948000 00000000 00000000 00002000 00002000
> > 00000000 00122ba2 00a724b0 004f3980 08076000 00001adb 00819018 08074000
> > Call Trace: [<00122ba2>] [<0010a5d9>]
> > Code: f3 a5 83 e3 03 89 d9 f3 a4 07 6a 00 8b 74 24 2c 56 e8 6c 36
> > Using `/System.map' to map addresses to symbols.
> >
> > >>EIP: 11c90e <generic_file_read+48e/630>
> > Trace: 122ba2 <sys_read+c2/e0>
> > Trace: 10a5d9 <system_call+59/a0>
> >
> > Code: 11c90e <generic_file_read+48e/630> repz movsl %ds:(%esi),%es:(%edi)
>
> And once again we're copying to user mode, and neither %esi nor %edi
> (source and destination) have anything at all in them that could result
> in a virtual address translation of 00000004. esi = 00948000 (perfectly
> reasonable kernel address) and edi = 08076000 (perfectly reasonable user
> space address). The count (in ecx) is a perfectly normal 0x400, ie we
> copy the whole page (that's normal, it's going to the stdio buffers).
>
> I wonder what makes this happen.. But first, please confirm that it is
> indeed a Cyrix chip (Steven Baur - can you compare chip notes?)
>
> Linus
>

A bird in the hand is worth what it will bring.