>>>>> "Linus" == Linus Torvalds <torvalds@cs.helsinki.fi> writes:
Linus> On Fri, 26 Apr 1996, Matthew White wrote:
>>
>> 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.
Linus> Ok, this thing is more or less confirmed - there are some
Linus> serious problems with Cyrix chips. Not nice.
No, it's not confirmed. Not by any means.
First off, I had a crash very similar to the one Matthew reported on
April 6. This would have been from 1.3.83 or 1.3.84; I've reproduced
Matthew's report for comparison.
Apr 6 15:01:07 deanna kernel: Unable to handle kernel paging request at virtual address 00000004
Apr 6 15:01:08 deanna kernel: current->tss.cr3 = 014b7000, xr3 = 014b7000
Apr 6 15:01:08 deanna kernel: *pde = 00000000
Apr 6 15:01:08 deanna kernel: Oops: 0002
Apr 6 15:01:08 deanna kernel: CPU: 0
Apr 6 15:01:08 deanna kernel: EIP: 0010:[generic_file_read+580/996]
Apr 6 15:01:08 deanna kernel: EFLAGS: 00010206
Apr 6 15:01:08 deanna kernel: eax: 00ccbc0c ebx: 00001000 ecx: 00000400 edx: 01ca3000
Apr 6 15:01:08 deanna kernel: esi: 01ca3000 edi: 08724000 ebp: 00001000 esp: 01ab5f5c
Apr 6 15:01:08 deanna kernel: ds: 0018 es: 002b fs: 002b gs: 002b ss: 0018
Apr 6 15:01:08 deanna kernel: Process xemacs (pid: 1874, process nr: 31, stackpage=01ab5000)
Apr 6 15:01:08 deanna kernel: Stack: 00250018 008d2210 00010000 00a4aa50 08720000 00008000 00008000 00292a94
Apr 6 15:01:08 deanna kernel: 01ca3000 00000000 00000000 00004000 00004000 00000000 0011fbe4 00a4aa50
Apr 6 15:01:08 deanna kernel: 008d2210 08724000 0000c000 00ccbc0c 00010000 08720000 bffdaa9c 0010a2b9
Apr 6 15:01:08 deanna kernel: Call Trace: [sys_read+128/144] [system_call+89/160]
Apr 6 15:01:08 deanna kernel: Code: f3 a5 83 e3 03 89 d9 f3 a4 07 6a 00 8b 74 24 20 56 e8 3e 32
Unable to handle kernel paging request at virtual address 00000004
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>
To my untrained eye, these look suspiciously similar. My problem was
fixed completely by resetting all the jumpers on the motherboard
(there were a couple of wrong settings). The last 00000004 crash I
had was on April 6.
The jury is still out on whether my cache memory is bad, or whether
1.3.95 doesn't like my Cyrix system. I'm betting on Cache Memory at
the moment, but won't make any judgements without at least 80-90 hours
of error free uptime. I'm running flawlessly with 1.3.95 and new
external cache memory at the moment, *but* my worst problems have
tended to develop over time, and the worst crashes tended to be over
night, or after a couple of days of uptime.
At any right, I'm still in favor of considering it a (configurable)
hardware not a software problem, and in Matthew's case he probably has
the motherboard misjumpered. I am not ready to blame evil things on
the Cyrix chips at all.
Regards,
-- steve@miranova.com baur Unsolicited commercial e-mail will be proofread for $250/hour. Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone except you in November.