* Re: 2.5.73-mm1 falling over in SDET [not found] ` <49400000.1056814561@[10.10.2.4]> @ 2003-06-29 0:02 ` Andrew Morton 2003-06-29 3:28 ` James Bottomley 0 siblings, 1 reply; 4+ messages in thread From: Andrew Morton @ 2003-06-29 0:02 UTC (permalink / raw) To: Martin J. Bligh; +Cc: linux-kernel, linux-scsi "Martin J. Bligh" <mbligh@aracnet.com> wrote: > > > The killer SDET has got you, but this is all I got from the chewed > > remains. Maybe the EIP is enough? ;-) I guess that's a NULL ptr > > dereference, though garbled somewhat. > > Repeated it and got a much better panic. This is with feral isp driver > + Mike's patch, BTW. Maybe it's just some stack overflow? Oh lovely. > Call Trace: > [<c01c42d3>] blk_insert_request+0x47/0x78 > [<c01d3679>] scsi_queue_insert+0x71/0x7c > [<c01d05a4>] scsi_dispatch_cmd+0x180/0x190 > [<c01d465c>] scsi_request_fn+0x1f4/0x264 > [<c01c42f1>] blk_insert_request+0x65/0x78 > [<c01d3679>] scsi_queue_insert+0x71/0x7c > [<c01d05a4>] scsi_dispatch_cmd+0x180/0x190 > [<c01d465c>] scsi_request_fn+0x1f4/0x264 > [<c01c42f1>] blk_insert_request+0x65/0x78 Yes, isplinux_queuecommand() returns non-zero and the scsi generic layer cheerfully goes infinitely recursive. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: 2.5.73-mm1 falling over in SDET 2003-06-29 0:02 ` 2.5.73-mm1 falling over in SDET Andrew Morton @ 2003-06-29 3:28 ` James Bottomley 2003-06-29 5:35 ` Martin J. Bligh 0 siblings, 1 reply; 4+ messages in thread From: James Bottomley @ 2003-06-29 3:28 UTC (permalink / raw) To: Andrew Morton; +Cc: Martin J. Bligh, Linux Kernel, SCSI Mailing List [-- Attachment #1: Type: text/plain, Size: 269 bytes --] On Sat, 2003-06-28 at 19:02, Andrew Morton wrote: > Yes, isplinux_queuecommand() returns non-zero and the scsi generic layer > cheerfully goes infinitely recursive. Sigh, certain persons need to be more careful when doing logic alterations. Try the attached. James [-- Attachment #2: tmp.diff --] [-- Type: text/plain, Size: 448 bytes --] ===== drivers/scsi/hosts.c 1.79 vs edited ===== --- 1.79/drivers/scsi/hosts.c Thu Jun 26 22:51:24 2003 +++ edited/drivers/scsi/hosts.c Sat Jun 28 22:14:12 2003 @@ -194,7 +194,7 @@ shost->use_blk_tcq = sht->use_blk_tcq; shost->highmem_io = sht->highmem_io; - if (!sht->max_host_blocked) + if (sht->max_host_blocked) shost->max_host_blocked = sht->max_host_blocked; else shost->max_host_blocked = SCSI_DEFAULT_HOST_BLOCKED; ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: 2.5.73-mm1 falling over in SDET 2003-06-29 3:28 ` James Bottomley @ 2003-06-29 5:35 ` Martin J. Bligh 2003-06-30 10:17 ` Maneesh Soni 0 siblings, 1 reply; 4+ messages in thread From: Martin J. Bligh @ 2003-06-29 5:35 UTC (permalink / raw) To: James Bottomley, Andrew Morton; +Cc: Linux Kernel, SCSI Mailing List --James Bottomley <James.Bottomley@SteelEye.com> wrote (on Saturday, June 28, 2003 22:28:57 -0500): > On Sat, 2003-06-28 at 19:02, Andrew Morton wrote: >> Yes, isplinux_queuecommand() returns non-zero and the scsi generic layer >> cheerfully goes infinitely recursive. > > Sigh, certain persons need to be more careful when doing logic > alterations. > > Try the attached. OK, that gets rather further, and I strongly suspect fixes the SCSI problem. Thanks very much. But now it just OOMs instead, which seems to be slab failing dismally to shrink it's fat ass enough to fit in that lazy-boy. Ext2 doesn't look desparately happy either. Maybe it's really that one's fault? EXT2-fs error (device sda2): ext2_new_inode: Free inodes count corrupted in group 30 Remounting filesystem read-only Out of Memory: Killed process 215 (portmap). Out of Memory: Killed process 338 (sshd). larry:~# cat /proc/meminfo MemTotal: 16076324 kB MemFree: 15068968 kB Buffers: 476 kB Cached: 260824 kB SwapCached: 0 kB Active: 241972 kB Inactive: 23196 kB HighTotal: 15335424 kB HighFree: 15047680 kB LowTotal: 740900 kB LowFree: 21288 kB SwapTotal: 0 kB SwapFree: 0 kB Dirty: 0 kB Writeback: 0 kB Mapped: 5396 kB Slab: 697856 kB Committed_AS: 9688 kB PageTables: 264 kB VmallocTotal: 114680 kB VmallocUsed: 3156 kB VmallocChunk: 111524 kB slabinfo: dentry_cache 3999781 4011624 160 24 1 : tunables 120 60 8 : slabdata 167151 167151 0 Bad dentries. no no. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: 2.5.73-mm1 falling over in SDET 2003-06-29 5:35 ` Martin J. Bligh @ 2003-06-30 10:17 ` Maneesh Soni 0 siblings, 0 replies; 4+ messages in thread From: Maneesh Soni @ 2003-06-30 10:17 UTC (permalink / raw) To: Martin J. Bligh Cc: James Bottomley, Andrew Morton, Linux Kernel, SCSI Mailing List On Sun, Jun 29, 2003 at 06:09:41AM +0000, Martin J. Bligh wrote: > --James Bottomley <James.Bottomley@SteelEye.com> wrote (on Saturday, June 28, 2003 22:28:57 -0500): > > > On Sat, 2003-06-28 at 19:02, Andrew Morton wrote: > >> Yes, isplinux_queuecommand() returns non-zero and the scsi generic layer > >> cheerfully goes infinitely recursive. > > > > Sigh, certain persons need to be more careful when doing logic > > alterations. > > > > Try the attached. > > OK, that gets rather further, and I strongly suspect fixes the SCSI > problem. Thanks very much. > > But now it just OOMs instead, which seems to be slab failing > dismally to shrink it's fat ass enough to fit in that lazy-boy. > Ext2 doesn't look desparately happy either. Maybe it's really > that one's fault? > I tried sdet on 16-way numaq with 2.5.73-mm2. It completes the run on ext2 (no OOMs), but gives following oops while running on ext3 ------------[ cut here ]------------ kernel BUG at fs/jbd/transaction.c:1132! invalid operand: 0000 [#1] SMP CPU: 5 EIP: 0060:[<c019f23d>] Not tainted VLI EFLAGS: 00010282 EIP is at journal_dirty_metadata+0x171/0x27c eax: 00000072 ebx: e66818e4 ecx: c03e85e0 edx: c03736d0 esi: e6681800 edi: da9e3580 ebp: e66818e4 esp: d755de84 ds: 007b es: 007b ss: 0068 Process cpio (pid: 32707, threadinfo=d755c000 task=d9f70ce0) Stack: c030f040 c030f5b4 c030f007 0000046c c030f5e0 00002f40 00000069 00000000 d832f6e4 c6f0b4c0 c01936d0 e042ca00 e50c2e0c d76df1a4 e042ca00 d76df1a4 d80f62a0 e5dfc000 00008000 e5dfc000 00000000 d832f660 e5e73400 e5e72d20 Call Trace: [<c01936d0>] ext3_new_inode+0x210/0x664 [<c0199658>] ext3_create+0x40/0x8c [<c0168ecb>] vfs_create+0x67/0x8c [<c01691cd>] open_namei+0x165/0x3e0 [<c01584ab>] filp_open+0x3b/0x5c [<c0158993>] sys_open+0x37/0x78 [<c01090b3>] syscall_call+0x7/0xb Code: 54 24 1c f0 0f ab 02 83 7f 14 00 75 29 68 e0 f5 30 c0 68 6c 04 00 00 68 07 f0 30 c0 68 b4 f5 30 c0 68 40 f0 30 c0 e8 db 14 f8 ff <0f> 0b 6c 04 07 f0 30 c0 83 c4 14 8b 47 14 3b 44 24 10 74 63 3b Regards, Maneesh -- Maneesh Soni IBM Linux Technology Center, IBM India Software Lab, Bangalore. Phone: +91-80-5044999 email: maneesh@in.ibm.com http://lse.sourceforge.net/ ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2003-06-30 9:56 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <45120000.1056810681@[10.10.2.4]>
[not found] ` <49400000.1056814561@[10.10.2.4]>
2003-06-29 0:02 ` 2.5.73-mm1 falling over in SDET Andrew Morton
2003-06-29 3:28 ` James Bottomley
2003-06-29 5:35 ` Martin J. Bligh
2003-06-30 10:17 ` Maneesh Soni
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox