Hi, On Tuesday 17 April 2007, Neil Brown wrote: > On Monday April 16, [EMAIL PROTECTED] wrote: > > > > cfq_dispatch_insert() was called with rq == 0. This one is getting really > > annoying... and md is involved again (RAID0 this time.) > > Yeah... weird. > RAID0 is so light-weight and so different from RAID1 or RAID5 that I > feel fairly safe concluding that the problem isn't in or near md. > But that doesn't help you. > > This really feels like a locking problem. > > The problem occurs when ->next_rq is NULL, but ->sort_list.rb_node is > not NULL. That happens plenty of times in the code (particularly as > the first request is inserted) but always under ->queue_lock so it > should never be visible to cfq_dispatch_insert.. > > Except that drivers/scsi/ide-scsi.c:idescsi_eh_reset calls > elv_next_request which could ultimately call __cfq_dispatch_requests > without taking ->queue_lock (that I can see). But you probably aren't > using ide-scsi (does anyone?).
ide-scsi is holding ide_lock while calling elv_next_request() (for ide ide_lock == ->queue_lock) Also from the original report: On Sunday 15 April 2007, Brad Campbell wrote: > > The box is booted with PXE and runs an nfsroot. It's Debian 3.1. It has 2 SIL > 3112 controllers in it > with 4 WD 200GB ATA drives all on PATA->SATA bridges. and you can even see libata functions in the OOPS... Bart - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/