2.4.1pre8 Oops

Nothing special with this box. SMP no modules, Squid proxy and running VNC/Pan at the time. Using kernel version of reiserfs on filesystems other than root.

Be glad to offer any other info if needed.

EIP: 0010:[<c01c36a7>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00000002
eax: 00000300 ebx: 000f41fb ecx: 00004000 edx: 000003fd
esi: c02ed380 edi: c0303da0 ebp: c02ed381 esp: c992fe9c
ds: 0018 es: 0018 ss: 0018
Process pan (pid: 23322, stackpage=c992f000)

Stack: c01c7858 c0303da0 00000005 c02a61a0 0000001b c02ed366 c02ed381 
0000001b
       0000000d c0116e42 c02a61a0 c02ed366 0000001b 00000001 c02ea068 
00000020
       0000000d 00000082 00000001 c02ed381 0000001e c01125bf c023d0a0 
00000001
Call Trace: [<c01c7858>] [<c0116e42>] [<c01125bf>] [<c0100018>] 
[<c01f2aa5>] [<c011aafc>] [<c010a8c5>] [<c0109014>] [<c0130018>] 
[<c0132a30>] [<c0108f53>]
Code: 0f b6 c0 c3 90 53 8b 54 24 08 8b 44 24 0c 8b 5c 24 10 83 7a

Trace; c01c7858 <serial_console_write+5c/134>
Trace; c0116e42 <printk+12a/17c>
Trace; c01125bf <smp_error_interrupt+43/48>
Trace; c0100018 <startup_32+18/cb>
Trace; c01f2aa5 <net_tx_action+5/118>
Trace; c011aafc <do_softirq+5c/8c>
Trace; c010a8c5 <do_IRQ+e5/f4>
Trace; c0109014 <ret_from_intr+0/20>
Trace; c0130018 <shmem_truncate+2c/11c>
Trace; c0132a30 <sys_read+a8/c4>
Trace; c0108f53 <system_call+33/38>
Code; c01c36a7 <serial_in+37/3c>
00000000 <_EIP>:
Code; c01c36a7 <serial_in+37/3c> <=====
0: 0f b6 c0 movzbl %al,%eax <=====
Code; c01c36aa <serial_in+3a/3c>
3: c3 ret
Code; c01c36ab <serial_in+3b/3c>
4: 90 nop
Code; c01c36ac <serial_out+0/40>
5: 53 push %ebx
Code; c01c36ad <serial_out+1/40>
6: 8b 54 24 08 mov 0x8(%esp,1),%edx
Code; c01c36b1 <serial_out+5/40>
a: 8b 44 24 0c mov 0xc(%esp,1),%eax
Code; c01c36b5 <serial_out+9/40>
e: 8b 5c 24 10 mov 0x10(%esp,1),%ebx
Code; c01c36b9 <serial_out+d/40>
12: 83 7a 00 00 cmpl $0x0,0x0(%edx)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

I also failed to mention that I use devfs.

[Oops snipped]

Upgraded to 2.4.1pre9 and got the following Oops:

EIP: 0010:[<c022b533>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00000086
eax: 00000001 ebx: 00000001 ecx: 00000001 edx: c0238440
esi: c02d7068 edi: 00000020 ebp: 0000000d esp: c7a63ed0
ds: 0018 es: 0018 ss: 0018
Process pan (pid: 2318, stackpage=c7a63000)

Stack: 00000001 c02d7068 00000020 0000000d 00000082 00000001 c02da381
0000001e
       c01125bf c0238440 00000001 00000001 00000001 00000001 c0233d6d
00000001
       00000020 c02f502c c02d7068 00000020 0000000d ffffe000 c1460018
c0100018
Call Trace: [<c01125bf>] [<c0100018>] [<c01ed565>] [<c011916c>]
[<c010a8c5>] [<c0109014>] [<ffff0018>]
       [<c0130018>] [<c0130e19>] [<c0108f53>] [<c010002b>]
Code: 80 3d c0 6d 28 c0 00 f3 90 7e f5 e9 d6 b7 ee ff 80 3d c0 6d

Trace; c01125bf <smp_error_interrupt+43/48>
Trace; c0100018 <startup_32+18/cb>
Trace; c01ed565 <net_tx_action+5/118>
Trace; c011916c <do_softirq+5c/8c>
Trace; c010a8c5 <do_IRQ+e5/f4>
Trace; c0109014 <ret_from_intr+0/20>
Trace; ffff0018 <END_OF_CODE+3fcd7e44/????>
Trace; c0130018 <sys_fchdir+c/11c>
Trace; c0130e19 <sys_read+a1/c4>
Trace; c0108f53 <system_call+33/38>
Trace; c010002b <startup_32+2b/cb>
Code; c022b533 <stext_lock+787/662d>
00000000 <_EIP>:
Code; c022b533 <stext_lock+787/662d> <=====
0: 80 3d c0 6d 28 c0 00 cmpb $0x0,0xc0286dc0 <=====
Code; c022b53a <stext_lock+78e/662d>
7: f3 90 repz nop
Code; c022b53c <stext_lock+790/662d>
9: 7e f5 jle 0 <_EIP>
Code; c022b53e <stext_lock+792/662d>
b: e9 d6 b7 ee ff jmp ffeeb7e6 <_EIP+0xffeeb7e6>
c0116d19 <printk+11/17c>
Code; c022b543 <stext_lock+797/662d>
10: 80 3d c0 6d 00 00 00 cmpb $0x0,0x6dc0

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Would I be correct in assuming that you're using a serial console, and that the oops was caused by the NMI watchdog?

It seems that this is _bound_ to happen - we're busy waiting on the UART with interrupts disabled....

Some fixes which come to mind are:

1: the serial console code tells the NMI oopser that it knows what
it's doing.

2: the serial console code aborts the write if it doesn't make any
progress for 1/10th of a second.

3: Boot the kernel with the `nmi_watchdog=0' LILO option if you're
using an unreliable serial console.

-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Another NMI oops?

You've deadlocked over my old friend console_lock. I can't
see _why_ though. Was this with the same setup, using the
serial console? If so then probably the other CPU was stuck in the serial console driver, holding console_lock.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/