Very Computer

by **Adam William** » Fri, 12 Jun 1998 04:00:00

Linux 2.0.34 has crashed for the second time, not including the crashes
for 2.0.33.

My configuration includes a soundblaster 16 and plip. 2.0.34 faithfully
dumps debug messages in /var/log/messages. Am I being punished for not
standardizing on Microsoft?

Last week's crash dumped:

general protection: 0000
CPU: 0
EIP: 0010:[namei+56/72]
EFLAGS: 00010282
eax: 01a08080 ebx: 00000000 ecx: 001a502c edx: 00000000
esi: 01b2efb4 edi: 00000001 ebp: 080a6ddc esp: 01b2ef84
ds: 0018 es: 0018 fs: 002b gs: 002b ss: 0018
Process sh (pid: 30797, process nr: 42, stackpage=01b2e000)
Stack: 01a08000 01cd5b00 00000001 01b2efb4 bffffd40 080a644c 01a08000
001295e9
080a644c 01b2efb4 01d82414 bffffd40 0135a000 0010a655 080a644c
bffffd40
080a644c bffffd40 00000001 080a6ddc ffffffda 0805002b 0805002b
0000002b
Call Trace: [sys_newstat+41/88] [system_call+85/128]
Code: a0 fa ff ff 83 c4 00 01 d8 5b 5e 83 c4 04 c3 90 83 ec 10 55

This week's crash dumped:

Jun 11 17:22:22 pppd[2510]: pppd 2.2.0 started by root, uid 0
Jun 11 17:22:23 chat[2515]: timeout set to 3 seconds
Jun 11 17:22:23 chat[2515]: send (AT^M)
Jun 11 17:22:23 pppd[2510]: Connect script failed
Jun 11 17:22:23 pppd[2510]: Exit.
Jun 11 17:22:33 kernel: Unable to handle kernel paging request at
virtual address cab81008
Jun 11 17:22:33 kernel: current->tss.cr3 = 03749000, ^_r3 = 03749000
Jun 11 17:22:33 kernel: *pde = 00000000
Jun 11 17:22:33 kernel: Oops: 0002
Jun 11 17:22:33 kernel: CPU: 0
Jun 11 17:22:33 kernel: EIP: 0010:[tcp_listen_select+96/152]
Jun 11 17:22:33 kernel: EFLAGS: 00013297
Jun 11 17:22:33 kernel: eax: 00000000 ebx: 03c8624c ecx: 0374c89c
edx: 0ab81000
Jun 11 17:22:33 kernel: esi: 00000000 edi: 0374be78 ebp: 03c86200
esp: 0374bdd4
Jun 11 17:22:33 kernel: ds: 0018 es: 0018 fs: 002b gs: 002b ss:
0018
Jun 11 17:22:33 kernel: Process XF86_SVGA (pid: 159, process nr: 24,
stackpage=0374b000)
Jun 11 17:22:33 kernel: Stack: 00000001 03949f68 0374be78 00145ec2
0374c810 00000001 0374be78 00000001
Jun 11 17:22:33 kernel: 03949f68 00000001 03c86200 00151b36
0374c810 00000001 0374be78 00000001
Jun 11 17:22:33 kernel: 00136361 03c86290 00000001 0374be78
0013633c 0012d2e2 03c86200 03949f68
Jun 11 17:22:33 kernel: Call Trace: [tcp_select+34/336]
[inet_select+34/44] [sock_select+37/48] [sock_select+0/48]
[check+50/132] [do_select+349/640] [sys_select+398/608]
Jun 11 17:22:33 kernel: [do_readv_writev+422/612]
[old_select+63/80] [system_call+85/128]
Jun 11 17:22:33 kernel: Code: 89 5a 08 a1 d4 c4 1b 00 89 02 c7 42 04 00
00 00 00 9c 5e fa
Jun 11 17:23:00 kernel: Unable to handle kernel NULL pointer dereference
at virtual address c0000001
Jun 11 17:23:00 kernel: current->tss.cr3 = 03b23000, ^_r3 = 03b23000
Jun 11 17:23:00 kernel: *pde = 00102067
Jun 11 17:23:00 kernel: *pte = 00000000
Jun 11 17:23:00 kernel: Oops: 0000
Jun 11 17:23:00 kernel: CPU: 0
Jun 11 17:23:00 kernel: EIP: 0010:[__iget+60/544]
Jun 11 17:23:00 kernel: EFLAGS: 00010202
Jun 11 17:23:00 kernel: eax: 00000301 ebx: 00000001 ecx: 00000000
edx: 00003901
Jun 11 17:23:00 kernel: esi: 001b1528 edi: 00000000 ebp: 001be688
esp: 03cfeef0
Jun 11 17:23:00 kernel: ds: 0018 es: 0018 fs: 002b gs: 002b ss:
0018
Jun 11 17:23:00 kernel: Process sh (pid: 2520, process nr: 23,
stackpage=03cfe000)
Jun 11 17:23:00 kernel: Stack: 0395ef00 03cfef74 0000000a 0133a005
00160649 0016067c 001be688 00003901
Jun 11 17:23:00 kernel: 00000001 0395ef00 03cfef74 03cfef74
0000000a 0395ef00 00003901 0012b23a
Jun 11 17:23:00 kernel: 0395ef00 0133a005 0000000a 03cfef74
00000000 03cfef74 03cfefb4 0000000b
Jun 11 17:23:00 kernel: Call Trace: [ext2_lookup+129/368]
[ext2_lookup+180/368] [lookup+222/248] [_namei+90/228] [namei+48/72]
[sys_newstat+41/88] [system_call+85/128]
Jun 11 17:23:00 kernel: Code: 66 39 03 75 0d 8b 4c 24 1c 39 4b 04 0f 84
fa 00 00 00 8b 5b
Jun 11 17:23:08 kernel: plip1: transmit timeout(1,87)
Jun 11 17:23:40 kernel: Unable to handle kernel NULL pointer dereference
at virtual address c0000001
Jun 11 17:23:40 kernel: current->tss.cr3 = 039dd000, ^_r3 = 039dd000
Jun 11 17:23:40 kernel: *pde = 00102067
Jun 11 17:23:40 kernel: *pte = 00000000
Jun 11 17:23:40 kernel: Oops: 0000
Jun 11 17:23:40 kernel: CPU: 0
Jun 11 17:23:40 kernel: EIP: 0010:[__iget+60/544]
Jun 11 17:23:40 kernel: EFLAGS: 00010202
Jun 11 17:23:40 kernel: eax: 00000301 ebx: 00000001 ecx: 00c8ec18
edx: 001be688
Jun 11 17:23:40 kernel: esi: 001b1528 edi: 00000000 ebp: 001be688
esp: 03956ecc
Jun 11 17:23:40 kernel: ds: 0018 es: 0018 fs: 002b gs: 002b ss:
0018
Jun 11 17:23:40 kernel: Process getty (pid: 153, process nr: 21,
stackpage=03956000)
Jun 11 17:23:40 kernel: Stack: 01f15000 00c8ec18 00000005 00892005
00c8ec18 0016071f 001be688 00001101
Jun 11 17:23:40 kernel: 00000001 01f15000 00000001 03956f54
00000005 0081a090 00001101 0012b23a
Jun 11 17:23:40 kernel: 01f15000 00892005 00000005 03956f54
00000005 00000001 000081a4 03956f8c
Jun 11 17:23:40 kernel: Call Trace: [ext2_lookup+343/368]
[lookup+222/248] [open_namei+525/1048] [do_open+89/292]
[sys_open+63/120] [system_call+85/128]
Jun 11 17:23:40 kernel: Code: 66 39 03 75 0d 8b 4c 24 1c 39 4b 04 0f 84
fa 00 00 00 8b 5b
Jun 11 17:23:41 kernel: Unable to handle kernel NULL pointer dereference
at virtual address c0000001
Jun 11 17:23:41 kernel: current->tss.cr3 = 030cc000, ^_r3 = 030cc000
Jun 11 17:23:41 kernel: *pde = 00102067
Jun 11 17:23:41 kernel: *pte = 00000000
Jun 11 17:23:41 kernel: Oops: 0000
Jun 11 17:23:41 kernel: CPU: 0
Jun 11 17:23:41 kernel: EIP: 0010:[__iget+60/544]
Jun 11 17:23:41 kernel: EFLAGS: 00010202
Jun 11 17:23:41 kernel: eax: 00000301 ebx: 00000001 ecx: 00000000
edx: 00001101
Jun 11 17:23:41 kernel: esi: 001b1528 edi: 00000000 ebp: 001be688
esp: 03956ecc
Jun 11 17:23:41 kernel: ds: 0018 es: 0018 fs: 002b gs: 002b ss:
0018
Jun 11 17:23:41 kernel: Process getty (pid: 2521, process nr: 21,
stackpage=03956000)
Jun 11 17:23:41 kernel: Stack: 01f15000 00000001 00000005 03e07005
00160649 0016067c 001be688 00001101
Jun 11 17:23:41 kernel: 00000001 01f15000 00000001 03956f54
00000005 01f15000 00001101 0012b23a
Jun 11 17:23:41 kernel: 01f15000 03e07005 00000005 03956f54
00000005 00000001 000081a4 03956f8c
Jun 11 17:23:41 kernel: Call Trace: [ext2_lookup+129/368]
[ext2_lookup+180/368] [lookup+222/248] [open_namei+525/1048]
[do_open+89/292] [sys_open+63/120] [system_call+85/128]
Jun 11 17:23:41 kernel: Code: 66 39 03 75 0d 8b 4c 24 1c 39 4b 04 0f 84
fa 00 00 00 8b 5b
Jun 11 17:23:42 kernel: Unable to handle kernel NULL pointer dereference
at virtual address c0000001
Jun 11 17:23:42 kernel: current->tss.cr3 = 03b59000, ^_r3 = 03b59000
Jun 11 17:23:42 kernel: *pde = 00102067
Jun 11 17:23:42 kernel: *pte = 00000000
Jun 11 17:23:42 kernel: Oops: 0000
Jun 11 17:23:42 kernel: CPU: 0
Jun 11 17:23:42 kernel: EIP: 0010:[__iget+60/544]
Jun 11 17:23:42 kernel: EFLAGS: 00010202
Jun 11 17:23:42 kernel: eax: 00000301 ebx: 00000001 ecx: 03956f04
edx: 00001101
Jun 11 17:23:42 kernel: esi: 001b1528 edi: 00000000 ebp: 001be688
esp: 03956ecc
Jun 11 17:23:42 kernel: ds: 0018 es: 0018 fs: 002b gs: 002b ss:
0018
Jun 11 17:23:42 kernel: Process getty (pid: 2522, process nr: 21,
stackpage=03956000)
Jun 11 17:23:42 kernel: Stack: 01f15000 00000001 00000005 03a0d005
00160649 0016067c 001be688 00001101
Jun 11 17:23:42 kernel: 00000001 01f15000 00000001 03956f54
00000005 01f15000 00001101 0012b23a
Jun 11 17:23:42 kernel: 01f15000 03a0d005 00000005 03956f54
00000005 00000001 000081a4 03956f8c
Jun 11 17:23:42 kernel: Call Trace: [ext2_lookup+129/368]
[ext2_lookup+180/368] [lookup+222/248] [open_namei+525/1048]
[do_open+89/292] [sys_open+63/120] [system_call+85/128]
Jun 11 17:23:42 kernel: Code: 66 39 03 75 0d 8b 4c 24 1c 39 4b 04 0f 84
fa 00 00 00 8b 5b
Jun 11 17:23:43 kernel: Unable to handle kernel NULL pointer dereference
at virtual address c0000001
Jun 11 17:23:43 kernel: current->tss.cr3 = 03a8e000, ^_r3 = 03a8e000
Jun 11 17:23:43 kernel: *pde = 00102067
Jun 11 17:23:43 kernel: *pte = 00000000
Jun 11 17:23:43 kernel: Oops: 0000
Jun 11 17:23:43 kernel: CPU: 0
Jun 11 17:23:43 kernel: EIP: 0010:[__iget+60/544]
Jun 11 17:23:43 kernel: EFLAGS: 00010202
Jun 11 17:23:43 kernel: eax: 00000301 ebx: 00000001 ecx: 03956f04
edx: 00001101
Jun 11 17:23:43 kernel: esi: 001b1528 edi: 00000000 ebp: 001be688
esp: 03956ecc
Jun 11 17:23:43 kernel: ds: 0018 es: 0018 fs: 002b gs: 002b ss:
0018
Jun 11 17:23:43 kernel: Process getty (pid: 2523, process nr: 21,
stackpage=03956000)
Jun 11 17:23:43 kernel: Stack: 01f15000 00000001 00000005 01066005
00160649 0016067c 001be688 00001101
Jun 11 17:23:43 kernel: 00000001 01f15000 00000001 03956f54
00000005 01f15000 00001101 0012b23a
Jun 11 17:23:43 kernel: 01f15000 01066005 00000005 03956f54
00000005 00000001 000081a4 03956f8c
Jun 11 17:23:43 kernel: Call Trace: [ext2_lookup+129/368]
[ext2_lookup+180/368] [lookup+222/248] [open_namei+525/1048]
[do_open+89/292] [sys_open+63/120] [system_call+85/128]
Jun 11 17:23:43 kernel: Code: 66 39 03 75 0d 8b 4c 24 1c 39 4b 04 0f 84
fa 00 00 00 8b 5b
Jun 11 17:23:44 kernel: Unable to handle kernel NULL pointer dereference
at virtual address c0000001
Jun 11 17:23:44 kernel: current->tss.cr3 = 03983000, ^_r3 = 03983000
Jun 11 17:23:44 kernel: *pde = 00102067
Jun 11 17:23:44 kernel: *pte = 00000000
Jun 11 17:23:44 kernel: Oops: 0000
Jun 11 17:23:44 kernel: CPU: 0
Jun 11 17:23:44 kernel: EIP: 0010:[__iget+60/544]
Jun 11 17:23:44 kernel: EFLAGS: 00010202
Jun 11 17:23:44 kernel: eax: 00000301 ebx: 00000001 ecx: 03956f04
edx: 00001101
Jun 11 17:23:44 kernel: esi: 001b1528 edi: 00000000 ebp: 001be688
esp: 03956ecc
Jun 11 17:23:44 kernel: ds: 0018 ...

read more »

by **your secret admir** » Sat, 13 Jun 1998 04:00:00

2.0.34 kernel is unstable I've heard/read. Anyway, it hasn't crashed once on
me yet and I have a pathetically unreliable computer, not to mention a
'Microsoft Sound System.' Performance is decent and I've been running
smoothly.

On Thu, 11 Jun 1998 18:22:45 -0400,

Quote:> Linux 2.0.34 has crashed for the second time, not including the crashes
> for 2.0.33.

> My configuration includes a soundblaster 16 and plip. 2.0.34 faithfully
> dumps debug messages in /var/log/messages. Am I being punished for not
> standardizing on Microsoft?

> Last week's crash dumped:

> general protection: 0000

[...cpu crash!...]

Quote:
> This week's crash dumped:

> Jun 11 17:22:22 pppd[2510]: pppd 2.2.0 started by root, uid 0
> Jun 11 17:22:23 chat[2515]: timeout set to 3 seconds
> Jun 11 17:22:23 chat[2515]: send (AT^M)
> Jun 11 17:22:23 pppd[2510]: Connect script failed
> Jun 11 17:22:23 pppd[2510]: Exit.
> Jun 11 17:22:33 kernel: Unable to handle kernel paging request at
> virtual address cab81008

[...pppd crash!...]

--
============================================================

http://www.tical.net/~blue | my diabolic schemes." - blue
============================================================

by **Lee Reynold** » Sat, 13 Jun 1998 04:00:00

> 2.0.34 kernel is unstable I've heard/read. Anyway, it hasn't crashed once on
> me yet and I have a pathetically unreliable computer, not to mention a
> 'Microsoft Sound System.' Performance is decent and I've been running
> smoothly.

It depends on which 034 kernel you are talking about. If you're running redhat
5.1 with the
pre-release 034 they shipped with it, then I have no doubt that you will see
some instability.
But I doubt the same could be said for the final version which came out a couple
of weeks
ago.

Lee Reynolds

by **Lee Reynold** » Sat, 13 Jun 1998 04:00:00

> Linux 2.0.34 has crashed for the second time, not including the crashes
> for 2.0.33.

> My configuration includes a soundblaster 16 and plip. 2.0.34 faithfully
> dumps debug messages in /var/log/messages. Am I being punished for not
> standardizing on Microsoft?

First off if you don't know the reason it is crashing you cannot say for
sure
the crashes have anything to do with linux or are due to flaws in linux.
Play
with your hardware and make sure that there is nothing wrong with it,
particularly
the memory including the cache. Gone are the days of parity memory that
would tell you when something was wrong. Unless you have ecc memory the
only indication that there is a problem is the computer crashing and
generally
acting in a brain damaged fashion. If your memory is bad te computer will
lock up under windog just as easily if not more easily than it does under
linux.

Lee Reynolds

by **Adam William** » Sun, 14 Jun 1998 04:00:00

The kernel was downgraded to 2.0.32 and it still crashed without leaving
a debug report so the problem isn't Linux. Now the CPU fan has been
cleaned, the case is off, and I'm wondering if SLDRAM is going to be
standardized in time for a new motherboard.

by **Nathan Kenned** » Sun, 14 Jun 1998 04:00:00

> If your memory is bad te computer will
> lock up under windog just as easily if not more easily than it does under
> linux.

Not necessarily. Processor-intensive tasks in Linux are often more trying
on hardware in Linux than in Wingdows. Sometimes memory problems
start extremely rarely, just a bit flipped every couple hours, and won't
show as obviously in Wingdows, which GPFs or segfaults of its own
accord. F'rinstance, I had a 386 whose memory always tested fine and
ran fine under MS-DOG, or 3.1, but memory/processor intensive tasks
like in Linux would completely freeze the machine. These slowly
became more frequent until it was unuseable..
So although it may only show up in Linux, that doesn't discount memory
problems by far.

Very Computer

2.0.34 keeps crashing and crashing and crashing and ...

2.0.34 keeps crashing and crashing and crashing and ...

2.0.34 keeps crashing and crashing and crashing and ...

2.0.34 keeps crashing and crashing and crashing and ...

2.0.34 keeps crashing and crashing and crashing and ...

2.0.34 keeps crashing and crashing and crashing and ...

2.0.34 keeps crashing and crashing and crashing and ...