On Wed, May 04, 2011 at 12:32:50PM -0700, Linus Torvalds wrote: > On Wed, May 4, 2011 at 12:07 PM, Alexey Dobriyan <adobriyan@xxxxxxxxx> wrote: > > Got one at the very end of burning session (haven't tried to reproduce yet). > > Apparently happened when cdrecord tried to open the door. > > > > __lock_acquire > > lock_acquire > > _raw_spin_lock_irq > > blk_get_request > > Hmm. That would be the > > spin_lock_irq(q->queue_lock); > > in there, I'm not seeing any other spinlock. > > > scsi_execute > > scsi_set_medium_removal > > sr_lock_door > > cdrom_release > > sr_block_release > > __blk_dev_put > > blkdev_put > > blkdev_close > > fput > > filp_close > > sys_close > > > > comm: cdrecord > > RAX was small number like 0x46(?) > > RBX 6b6b6b6b6b6b6b83 > > RDI 6b6b6b6b6b6b6b83 > > And that implies that 'q' has been free'd before it's used, and you > have SLUB-debugging turned on. > > > This model is USB device. > > Hmm. It looks a bit odd that cdrom_release() does the ->release call > before it does the ->tray_move thing, but I don't think that's it. > > Jens/James: What's the sequence to blk_cleanup_queue() for a SCSI > CD-ROM? It really does look like we're releasing the queue before > we're done with it. Second time, burning finished to the end successfully. -- 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
