Messages in this thread | | | Date | Fri, 26 Apr 1996 12:37:11 -0400 (EDT) | From | Matthew White <> | Subject | Re: Another oops (1.3.93) |
| |
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.
| |