On Fri, 2007-09-14 at 13:56 -0700, Andrew Morton wrote: > On Fri, 14 Sep 2007 07:11:54 -0700 (PDT) > bugme-daemon@xxxxxxxxxxxxxxxxxxx wrote: > > > http://bugzilla.kernel.org/show_bug.cgi?id=9018 > > > > Summary: Kernel bug in aic94xx driver shipped with kernel > > 2.6.21.7 > > Product: Drivers > > Version: 2.5 > > KernelVersion: 2.6.21.7 > > Platform: All > > OS/Version: Linux > > Tree: Mainline > > Status: NEW > > Severity: normal > > Priority: P1 > > Component: Other > > AssignedTo: drivers_other@xxxxxxxxxxxxxxxxxxxx > > ReportedBy: martijn@xxxxxxxxxxx > > > > > > While rebuilding a MD raid5, every time I try to rebuild: > > > > -- START DUMP -- > > RAID5 conf printout: > > --- rd:3 wd:2 > > disk 0, o:1, dev:sdb1 > > disk 1, o:1, dev:sdc1 > > disk 2, o:1, dev:sdd1 > > md: recovery of RAID array md0 > > md: minimum _guaranteed_ speed: 1000 KB/sec/disk. > > md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) > > for recovery. > > md: using 128k window, over a total of 71681920 blocks. > > ------------[ cut here ]------------ > > kernel BUG at drivers/scsi/aic94xx/aic94xx_hwi.h:354! > > whee! That's BUG_ON(!list_empty(&ascb->list)); Yes; it means the task was still in use when we tried to free it. I surmise that this is the tascb not the ascb in asd_abort_task(). What this seems to indicate is some sort of race between the abort completing the task and the owning entity taking it off the sequencer list. I don't understand this piece of the driver enough yet to fix a more definite cause. > yet anoher scsi driver with no entry in MAINTAINERS. Darrick, maybe? Gilbert Wu should be taking over eventually, but for now it's a bit unmaintained. James - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
