lkml.org 
[lkml]   [1998]   [Feb]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: solid lockup on 2.1.86 under heavy signal activity
On Sat, 14 Feb 1998, Dean Gaudet wrote:

> I'm testing race conditions in Apache and putting it under a heavy
> barrage of signals. When I do this under 2.1.86 (or 2.1.87-pre1) my
> system freezes after a few moments. How to reproduce:
>
> - grab apache 1.3b3 (should be good enough) Configure
> - run it with -f /path/to/conf/file/below
> - find the pid of the parent
> - attack it:
> while 1
> kill -USR1 parent_pid
> end
>
> This should result in no i/o traffic due to apache. But it will result
> in 5 fork()s, one killpg, and 5 exit()s, and 5 waits per iteration of
> the above loop. The forking and exiting is all interleaved.
>
> The lockup appears to be independant of i/o activity. It occurs within
> 10 seconds or so of starting the loop. Shift scrolllock et al does nothing.
>
> The system has dual pentium pro 166s, Tyan S1682D motherboard. IO-APIC is
> enabled.

More data. This is 2.1.86. Here's oopses and disassemblies and whatnot.
Note that the oopses were caused by mingo's nmi watchdog... and I'm
certain that the third of the oopses is really the watchdog's fault. The
first two are probably the interesting ones.

If it's of any use I can provide the httpd executable and a tiny conf file
for reproducing this.

Dean

First the oopses:

NMI Watchdog detected LOCKUP on CPU3, forcing oops
Unable to handle kernel NULL pointer dereference at virtual address 00000000
current->tss.cr3 = 07899000, %cr3 = 07899000
*pde = 00000000
Oops: 0002
CPU: 3
EIP: 0010:[<c010b110>]
EFLAGS: 00010092
eax: 00000033 ebx: 00000003 ecx: c7c7c000 edx: c0200e5c
esi: c7fd88b8 edi: c77d01f4 ebp: 0000000a esp: c77d1e84
ds: 0018 es: 0018 ss: 0018
Process httpd (pid: 227, process nr: 24, stackpage=c77d1000)
Stack: c01d8bb9 00000003 c77d0000 c010a082 c77d1e9c 00000000 c77ba000 c77d0000
00000032 c7fd88b8 c77d01f4 0000000a c7fd8800 00000018 00000018 ffffffff
c01d6d1a 00000010 00000002 c77ba000 00000003 fffffffd 000000e3 000001f4
Call Trace: [<c01d8bb9>] [<c010a082>] [<c01d6d1a>] [<c0112c4d>] [<c0112d86>] [<c011362b>] [<c01101f4>]
[<c0108e90>] [<c011211f>] [<c0128fc9>] [<c0109f46>]
Code: c7 05 00 00 00 00 00 00 00 00 83 c4 08 5b c3 90 89 14 9d 5c
NMI Watchdog detected LOCKUP on CPU0, forcing oops
Unable to handle kernel NULL pointer dereference at virtual address 00000000
current->tss.cr3 = 07836000, %cr3 = 07836000
*pde = 00000000
Oops: 0002
CPU: 0
EIP: 0010:[<c010b110>]
EFLAGS: 00010082
eax: 00000033 ebx: 00000000 ecx: c7c7c000 edx: c0200e5c
esi: 00000001 edi: c77bbf98 ebp: c77bbfac esp: c77bbf20
ds: 0018 es: 0018 ss: 0018
Process httpd (pid: 242, process nr: 20, stackpage=c77bb000)
Stack: c01d8bb9 00000000 c77ba000 c010a082 c77bbf38 00000000 00000001 bffffb2c
00000000 00000001 c77bbf98 c77bbfac c77ba000 c77b0018 00000018 ffffffff
c01d6de5 00000010 00000002 bffffb1c 00000001 00000000 bffffb08 c0108e90
Call Trace: [<c01d8bb9>] [<c010a082>] [<c01d6de5>] [<c0108e90>] [<c0109f46>]
Code: c7 05 00 00 00 00 00 00 00 00 83 c4 08 5b c3 90 89 14 9d 5c
NMI Watchdog detected LOCKUP on CPU3, forcing oops
Unable to handle kernel NULL pointer dereference at virtual address 00000000
current->tss.cr3 = 07fb6000, %cr3 = 07fb6000
*pde = 00000000
Oops: 0002
CPU: 3
EIP: 0010:[<c010b110>]
EFLAGS: 00010086
eax: 00000033 ebx: 00000003 ecx: c7c7c000 edx: c0200e5c
esi: ffffffff edi: 000000ed ebp: bffffa10 esp: c0093f4c
ds: 0018 es: 0018 ss: 0018
Process init (pid: 1, process nr: 2, stackpage=c0093000)
Stack: c01d8bb9 00000003 c0092000 c010a082 c0093f64 00000000 c77aa000 00000283
c022df1c ffffffff 000000ed bffffa10 00000000 c77a0018 00000018 ffffffff
c01d7170 00000010 00000002 c77aa000 c011b092 c77aa000 c0092000 00000000
Call Trace: [<c01d8bb9>] [<c010a082>] [<c01d7170>] [<c011b092>] [<c0109f46>]
Code: c7 05 00 00 00 00 00 00 00 00 83 c4 08 5b c3 90 89 14 9d 5c

The ksyms:

Using `System.map' to map addresses to symbols.

>>EIP: c010b110 <do_nmi+54/78>
Trace: c01d8bb9 <stext_lock+2069/30c7>
Trace: c010a082 <error_code+32/3c>
Trace: c01d6d1a <stext_lock+1ca/30c7>
Trace: c0112c4d <kill_pg_info+49/74>
Trace: c0112d86 <kill_something_info+26/128>
Trace: c011362b <sys_kill+4f/5c>
Trace: c01101f4 <pci_conf1_read_config_word+4c/8c>
Trace: c0108e90 <sys_sigaction+94/100>
Trace: c011211f <do_page_fault+1b7/3d0>
Trace: c0128fc9 <sys_write+129/1a8>
Trace: c0109f46 <system_call+3a/40>
Code: c010b110 <do_nmi+54/78> movl $0x0,0x0
Code: c010b11a <do_nmi+5e/78> addl $0x8,%esp
Code: c010b11d <do_nmi+61/78> popl %ebx
Code: c010b11e <do_nmi+62/78> ret
Code: c010b11f <do_nmi+63/78> nop
Code: c010b120 <do_nmi+64/78> movl %edx,0x9090005c(,%ebx,4)
Code: c010b127 <do_nmi+6b/78> nop
>>EIP: c010b110 <do_nmi+54/78>
Trace: c01d8bb9 <stext_lock+2069/30c7>
Trace: c010a082 <error_code+32/3c>
Trace: c01d6de5 <stext_lock+295/30c7>
Trace: c0108e90 <sys_sigaction+94/100>
Trace: c0109f46 <system_call+3a/40>
Code: c010b110 <do_nmi+54/78> movl $0x0,0x0
Code: c010b11a <do_nmi+5e/78> addl $0x8,%esp
Code: c010b11d <do_nmi+61/78> popl %ebx
Code: c010b11e <do_nmi+62/78> ret
Code: c010b11f <do_nmi+63/78> nop
Code: c010b120 <do_nmi+64/78> movl %edx,0x9090005c(,%ebx,4)
Code: c010b127 <do_nmi+6b/78> nop
>>EIP: c010b110 <do_nmi+54/78>
Trace: c01d8bb9 <stext_lock+2069/30c7>
Trace: c010a082 <error_code+32/3c>
Trace: c01d7170 <stext_lock+620/30c7>
Trace: c011b092 <sys_wait4+37a/438>
Trace: c0109f46 <system_call+3a/40>
Code: c010b110 <do_nmi+54/78> movl $0x0,0x0
Code: c010b11a <do_nmi+5e/78> addl $0x8,%esp
Code: c010b11d <do_nmi+61/78> popl %ebx
Code: c010b11e <do_nmi+62/78> ret
Code: c010b11f <do_nmi+63/78> nop
Code: c010b120 <do_nmi+64/78> movl %edx,0x9090005c(,%ebx,4)
Code: c010b127 <do_nmi+6b/78> nop

And the disassemblies:

stext_lock+2069 isn't code, it's data for the printk in do_nmi()

this one is spin_lock_irqsave(&t->sigmask_lock, flags);
in send_sig_info()
c01d6d13 <stext_lock+1c3> testb $0x1,0x4ac(%ebx)
c01d6d1a <stext_lock+1ca> jne c01d6d13 <stext_lock+1c3>
c01d6d1c <stext_lock+1cc> jmp c01129c2 <send_sig_info+de>

this is the spin_lock_irq(&current->sigmask_lock);
in do_sigaction()
c01d6dde <stext_lock+28e> testb $0x1,0x4ac(%eax)
c01d6de5 <stext_lock+295> jne c01d6dde <stext_lock+28e>
c01d6de7 <stext_lock+297> jmp c0113768 <do_sigaction+38>

this is acquiring tasklist_lock in release()
c01d7167 <stext_lock+617> lock btrl $0x1f,0xc02004e8
c01d7170 <stext_lock+620> cmpl $0x0,0xc02004e8
c01d7177 <stext_lock+627> jne c01d7170 <stext_lock+620>
c01d7179 <stext_lock+629> jmp c011a4b1 <release+a9>



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 13:41    [W:0.100 / U:0.308 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site