Jens and guys,
followup to my own mail, I managed to get snapshot of the oops trace.
On X11 screen, I had wmsvencd appication running, and on a text virtual
console, I typed "cat /cdrom/.../* >/dev/null" and quickly got oops.
Just as I pushed the shutter, watchdog output scrolled the previous
output away and then console was dead.
Note that cat-ing just one file from cdrom does not trigger oops, it
happens only on operations on multiple files.
Below are two traces: from wmsvencd and from the NMI watchdog. The
system is SMP Pentium, SCSI CDROM on ncr53c810. Please tell me if I
can provide more information.
Eugene
========================================================================
ksymoops 2.3.3 on i586 2.3.49. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.3.49/ (default)
-m /usr/src/linux/System.map (default)
Warning: You did not tell me where to find symbol information. I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc. ksymoops -h explains the options.
CPU: 1
EIP: 0010:[<c018ee0c>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010046
eax: 00000000 ebx: 00000000 ecx: c1497e18 edx: c115b5c0
esi: c1497ef4 edi: c1497ea0 ebp: c1497ea0 esp: c3bad74c
ds: 0018 es: 0018 ss: 0018
Process wmsvencd (pid: 234, stackpage=c3bad000)
Stack: 00000000 c1497ef4 c1497ea0 c1497ef4 c0195a61 00000000 c1497ea0 c115b5c0
00000000 00000000 c115b5e4 c1497ea0 00000286 c3bad848 00000000 c11f0000
c115b5c0 c0195047 c115b5e4 c1497ea0 c3bad8dc c3bad84c c018edf7 c1497ea0
Call trace: [<c0195a61>] [<c0195047>] [<c018edf7>] [<c018ecc2>] [<c018dfe8>]
[<dead4ead>] [<dead4ead>]
[<c019b7eb>] [<c01a3fc5>] [<c019d530>] [<c01a5330>] [<c01a52ea>]
[<c0107e7c>] [<c01951e5>] [<c018e8e3>]
[<c018ed1c>] [<dead4ead>] [<dead4ead>] [<c018e1da>] [<c019bea9>]
[<c019c34d>] [<c01a4995>] [<c012d9f2>]
[<c0128a35>] [<c0128bc8>] [<c0114459>] [<c019d69f>] [<c4802014>]
[<c0210287>] [<c019d5b1>] [<c019d530>]
[<c0107e7c>] [<c019d69f>] [<c4802014>] [<c0210287>] [<c019d51b>]
[<c019d530>] [<c0107e7c>] [<c018f079>]
[<c01ad4f6>] [<c01ac3a6>] [<c0112e53>] [<c0112e53>] [<c01e9cfd>]
[<c01ac3a6>] [<c01ac153>] [<c01de340>]
[<c01175ed>] [<c01df201>] [<c014398c>] [<c014b15d>] [<c010a3a8>]
Code: 66 7c 43 0a 01 01 8b 43 04 89 5d 50 85 c0 75 0a 68 ed a9 20
>>EIP; c018ee0c <scsi_init_cmd_from_req+c/174> <=====
Trace; c0195a61 <scsi_request_fn+1c5/458>
Trace; c0195047 <scsi_insert_special_req+93/f0>
Trace; c018edf7 <scsi_do_req+bf/c8>
Trace; c018ecc2 <scsi_wait_req+aa/120>
Trace; c018dfe8 <scsi_wait_done+0/58>
Trace; dead4ead <END_OF_CODE+1a28024a/????>
Trace; dead4ead <END_OF_CODE+1a28024a/????>
Trace; c019b7eb <sr_packet+ff/160>
Trace; c01a3fc5 <cdrom_read_subchannel+61/c0>
Trace; c019d530 <ncr_queue_command+628/648>
Trace; c01a5330 <mmc_ioctl+40c/e34>
Trace; c01a52ea <mmc_ioctl+3c6/e34>
Trace; c0107e7c <__down+3e8/3f4>
Trace; c01951e5 <scsi_queue_next_request+7d/188>
Trace; c018e8e3 <scsi_release_command+143/14c>
Trace; c018ed1c <scsi_wait_req+104/120>
Trace; dead4ead <END_OF_CODE+1a28024a/????>
Trace; dead4ead <END_OF_CODE+1a28024a/????>
Trace; c018e1da <scsi_release_request+22/28>
Trace; c019bea9 <sr_do_ioctl+299/2a8>
Trace; c019c34d <sr_audio_ioctl+111/184>
Trace; c01a4995 <cdrom_ioctl+881/e10>
Trace; c012d9f2 <filemap_nopage+ee/404>
Trace; c0128a35 <do_no_page+4d/d0>
Trace; c0128bc8 <handle_mm_fault+110/220>
Trace; c0114459 <do_page_fault+179/4c0>
Trace; c019d69f <ncr_put_start_queue+bf/cc>
Trace; c4802014 <_end+453982c/4549868>
Trace; c0210287 <RCSid+3467/b145>
Trace; c019d5b1 <ncr_start_next_ccb+61/90>
Trace; c019d530 <ncr_queue_command+628/648>
Trace; c0107e7c <__down+3e8/3f4>
Trace; c019d69f <ncr_put_start_queue+bf/cc>
Trace; c4802014 <_end+453982c/4549868>
Trace; c0210287 <RCSid+3467/b145>
Trace; c019d51b <ncr_queue_command+613/648>
Trace; c019d530 <ncr_queue_command+628/648>
Trace; c0107e7c <__down+3e8/3f4>
Trace; c018f079 <scsi_do_cmd+105/110>
Trace; c01ad4f6 <alloc_skb+ee/1a0>
Trace; c01ac3a6 <sock_wmalloc+26/54>
Trace; c0112e53 <smp_apic_timer_interrupt+127/194>
Trace; c0112e53 <smp_apic_timer_interrupt+127/194>
Trace; c01e9cfd <call_apic_timer_interrupt+5/18>
Trace; c01ac3a6 <sock_wmalloc+26/54>
Trace; c01ac153 <sock_getsockopt+21b/2f8>
Trace; c01de340 <unix_stream_sendmsg+320/3e0>
Trace; c01175ed <schedule+44d/a50>
Trace; c01df201 <unix_ioctl+f1/100>
Trace; c014398c <blkdev_ioctl+28/34>
Trace; c014b15d <sys_ioctl+235/2e8>
Trace; c010a3a8 <system_call+38/40>
Code; c018ee0c <scsi_init_cmd_from_req+c/174>
00000000 <_EIP>:
Code; c018ee0c <scsi_init_cmd_from_req+c/174> <=====
0: 66 7c 43 jl 46 <_EIP+0x46> c018ee52
<scsi_init_cmd_from_req+52/174> <=====
Code; c018ee0f <scsi_init_cmd_from_req+f/174>
3: 0a 01 orb (%ecx),%al
Code; c018ee11 <scsi_init_cmd_from_req+11/174>
5: 01 8b 43 04 89 addl %ecx,0x5d890443(%ebx)
Code; c018ee16 <scsi_init_cmd_from_req+16/174>
a: 5d
Code; c018ee17 <scsi_init_cmd_from_req+17/174>
b: 50 pushl %eax
Code; c018ee18 <scsi_init_cmd_from_req+18/174>
c: 85 c0 testl %eax,%eax
Code; c018ee1a <scsi_init_cmd_from_req+1a/174>
e: 75 0a jne 1a <_EIP+0x1a> c018ee26
<scsi_init_cmd_from_req+26/174>
Code; c018ee1c <scsi_init_cmd_from_req+1c/174>
10: 68 ed a9 20 00 pushl $0x20a9ed
=========================================================================
1 warning issued. Results may not be reliable.
ksymoops 2.3.3 on i586 2.3.49. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.3.49/ (default)
-m /usr/src/linux/System.map (default)
Warning: You did not tell me where to find symbol information. I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc. ksymoops -h explains the options.
NMI Watchdog detected LOCKUP on CPU1, registers:
CPU: 1
EIP: 0010:[<c01e47c6>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00000002
eax: 00000058 ebx: 00000008 ecx: 00000001 edx: 00000001
esi: 00000246 edi: c02b8500 ebp: 00000803 esp: c1ccdee0
ds: 0018 es: 0018 ss: 0018
Process syslogd (pid: 68, stackpage=c1ccd000)
Stack: 00000008 c1057c90 c156f244 c1ccdf34 c0173d22 00000803 c369d540 c1057c90
c156f244 00000000 00000001 c0173efa 00000001 00000001 c1ccdf34 00000000
c012b45b 00000001 00000001 c1ccdf34 c10ea7a8 c369d540 c012b58f c10ea7a8
Call trace: [<c0173d22>] [<c0173efa>] [<c012b45b>] [<c012b58f>] [<c012b681>]
[<c012b428>] [<c0156e9f>]
[<c013a3fd>] [<c013bd68>] [<c010a3a8>]
Code: f3 90 75 f5 e9 e5 de f8 ff f6 05 30 0d 23 c0 01 f3 90 75 f5
>>EIP; c01e47c6 <stext_lock+28d6/6f70> <=====
Trace; c0173d22 <__ll_rw_block+22/1e4>
Trace; c0173efa <ll_rw_block+16/1c>
Trace; c012b45b <writeout_one_page+33/4c>
Trace; c012b58f <do_buffer_fdatasync+db/1b0>
Trace; c012b681 <generic_buffer_fdatasync+1d/38>
Trace; c012b428 <writeout_one_page+0/4c>
Trace; c0156e9f <ext2_sync_file+87/178>
Trace; c013a3fd <sys_writev+a9/d0>
Trace; c013bd68 <sys_fsync+f8/160>
Trace; c010a3a8 <system_call+38/40>
Code; c01e47c6 <stext_lock+28d6/6f70>
00000000 <_EIP>:
Code; c01e47c6 <stext_lock+28d6/6f70> <=====
0: f3 90 repz nop <=====
Code; c01e47c8 <stext_lock+28d8/6f70>
2: 75 f5 jne fffffff9 <_EIP+0xfffffff9> c01e47bf
<stext_lock+28cf/6f70>
Code; c01e47ca <stext_lock+28da/6f70>
4: e9 e5 de f8 ff jmp fff8deee <_EIP+0xfff8deee> c01726b4
<blk_get_queue+54/e4>
Code; c01e47cf <stext_lock+28df/6f70>
9: f6 05 30 0d 23 testb $0x1,0xc0230d30
Code; c01e47d4 <stext_lock+28e4/6f70>
e: c0 01
Code; c01e47d6 <stext_lock+28e6/6f70>
10: f3 90 repz nop
Code; c01e47d8 <stext_lock+28e8/6f70>
12: 75 f5 jne 9 <_EIP+0x9> c01e47cf <stext_lock+28df/6f70>
1 warning issued. Results may not be reliable.
====================================================================
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Mar 05 2000 - 13:50:31 EST