Messages in this thread |  | | Date | Tue, 19 Sep 2000 19:53:19 +0200 | From | Jorge Nerin <> | Subject | NMI Watchdog detected LOCKUP on CPU1 (stext_lock)(2.4.0-test9-pre2) |
| |
Hello, using 2.4.0-test9-pre2 and thinking that there are no major bugs I found this again, I have observed what I think it's the same bug since 2.4.0-test7.
All the traces end up in stext_lock, so I think it' the same bug, this time it happened when I was about to use the iomega parport zip with autofs.
The modprobe of ppa failed but it was inserted (???) because of the rename of sd.o back again to sd_mod.o
ksymoops 2.3.4 on i586 2.4.0-test9-pre2. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.0-test9-pre2/ (default) -m /boot/System.map-2.4.0-test9-pre2 (specified)
cpu: 0, clocks: 668188, slice: 222729 cpu: 1, clocks: 668188, slice: 222729 NMI Watchdog detected LOCKUP on CPU1, registers: CPU: 1 EIP: 0010:[<c01df3aa>] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00000082 eax: 00000306 ebx: 00000246 ecx: 00000006 edx: 0041b1cb esi: 00000306 edi: 0000000c ebp: 00005864 esp: c583ded8 ds: 0018 es: 0018 ss: 0018 Process syslogd (pid: 389, stackpage=c583d000) Stack: c28aaf80 00000002 c015db32 00000306 c28aaf80 00000000 00000001 c28aaf80 00000006 c015dd03 00000001 c28aaf80 c28aad40 c10e7878 00000000 c38ee8bc 00000400 c01256b5 00000001 00000001 c583df30 c1054460 c28aaf80 c012576e Call Trace: [<c015db32>] [<c015dd03>] [<c01256b5>] [<c012576e>] [<c01257cd>] [<c0125680>] [<c0150c6d>] [<c0133526>] [<c01094b7>] Code: f3 90 7e f5 e9 a6 da f7 ff 80 3d 90 e7 21 c0 00 f3 90 7e f5
>>EIP; c01df3aa <stext_lock+32ba/7f30> <===== Trace; c015db32 <generic_make_request+ce/120> Trace; c015dd03 <ll_rw_block+17f/1f4> Trace; c01256b5 <writeout_one_page+35/4c> Trace; c012576e <do_buffer_fdatasync+5e/a0> Trace; c01257cd <generic_buffer_fdatasync+1d/38> Trace; c0125680 <writeout_one_page+0/4c> Trace; c0150c6d <ext2_sync_file+55/108> Trace; c0133526 <sys_fsync+4a/68> Trace; c01094b7 <system_call+37/40> Code; c01df3aa <stext_lock+32ba/7f30> 00000000 <_EIP>: Code; c01df3aa <stext_lock+32ba/7f30> <===== 0: f3 90 repz nop <===== Code; c01df3ac <stext_lock+32bc/7f30> 2: 7e f5 jle fffffff9 <_EIP+0xfffffff9> c01df3a3 <stext_lock+32b3/7f30> Code; c01df3ae <stext_lock+32be/7f30> 4: e9 a6 da f7 ff jmp fff7daaf <_EIP+0xfff7daaf> c015ce59 <blk_get_queue+9/60> Code; c01df3b3 <stext_lock+32c3/7f30> 9: 80 3d 90 e7 21 c0 00 cmpb $0x0,0xc021e790 Code; c01df3ba <stext_lock+32ca/7f30> 10: f3 90 repz nop Code; c01df3bc <stext_lock+32cc/7f30> 12: 7e f5 jle 9 <_EIP+0x9> c01df3b3 <stext_lock+32c3/7f30>
NMI Watchdog detected LOCKUP on CPU0, registers: CPU: 0 EIP: 0010:[<c01df3aa>] EFLAGS: 00000082 eax: 00000306 ebx: 00000246 ecx: 00000006 edx: 0041b1cb esi: 00000306 edi: 0000000c ebp: 0000801e esp: c5fb1f74 ds: 0018 es: 0018 ss: 0018 Process kflushd (pid: 5, stackpage=c5fb1000) Stack: c5edeaa0 00000002 c015db32 00000306 c5edeaa0 00000000 00000001 c5edeaa0 00000006 c015dd03 00000001 c5edeaa0 00000007 c14e2260 00000001 c5fb0000 00000400 c0136149 00000001 00000001 c5fb1fd8 00000001 c5fb0000 00000ad0 Call Trace: [<c015db32>] [<c015dd03>] [<c0136149>] [<c01363fd>] [<c01079bb>] Code: f3 90 7e f5 e9 a6 da f7 ff 80 3d 90 e7 21 c0 00 f3 90 7e f5
>>EIP; c01df3aa <stext_lock+32ba/7f30> <===== Trace; c015db32 <generic_make_request+ce/120> Trace; c015dd03 <ll_rw_block+17f/1f4> Trace; c0136149 <flush_dirty_buffers+91/d8> Trace; c01363fd <bdflush+8d/150> Trace; c01079bb <kernel_thread+23/30> Code; c01df3aa <stext_lock+32ba/7f30> 00000000 <_EIP>: Code; c01df3aa <stext_lock+32ba/7f30> <===== 0: f3 90 repz nop <===== Code; c01df3ac <stext_lock+32bc/7f30> 2: 7e f5 jle fffffff9 <_EIP+0xfffffff9> c01df3a3 <stext_lock+32b3/7f30> Code; c01df3ae <stext_lock+32be/7f30> 4: e9 a6 da f7 ff jmp fff7daaf <_EIP+0xfff7daaf> c015ce59 <blk_get_queue+9/60> Code; c01df3b3 <stext_lock+32c3/7f30> 9: 80 3d 90 e7 21 c0 00 cmpb $0x0,0xc021e790 Code; c01df3ba <stext_lock+32ca/7f30> 10: f3 90 repz nop Code; c01df3bc <stext_lock+32cc/7f30> 12: 7e f5 jle 9 <_EIP+0x9> c01df3b3 <stext_lock+32c3/7f30>
-- Jorge Nerin <jnerin@svalero.es> <comandante@zaralinux.com> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |