Re: 2.5.73-mm1 falling over in SDET

Re: 2.5.73-mm1 falling over in SDET

[Andrew Morton]

"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.

Re: 2.5.73-mm1 falling over in SDET

[James Bottomley]

[-- 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;

Re: 2.5.73-mm1 falling over in SDET

[Martin J. Bligh]

--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.

Re: 2.5.73-mm1 falling over in SDET

[Maneesh Soni]

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/