Change request: "scsi: killing requests for dead queue"

Change request: "scsi: killing requests for dead queue"

[Ulrich Windl]

Hi!

I have a change request: I saw three message that I couldn't bring into context with any other event (SLES11 SP1 (2.6.32.49-0.3-default)):

Jan 18 15:33:04 h03 kernel: [2866825.805434] scsi: killing requests for dead queue
Jan 18 15:33:04 h03 kernel: [2866825.812129] scsi: killing requests for dead queue
Jan 18 15:33:04 h03 kernel: [2866825.815553] scsi: killing requests for dead queue

Unfortunately the kernel message doesn't give some kind of queue identifier, so that's hard to correlate with any other events.

Can this message be improved to include some variable output?

Regards,
Ulrich Windl

Re: Change request: "scsi: killing requests for dead queue"

[Joe Perches]

On Thu, 2012-01-19 at 08:30 +0100, Ulrich Windl wrote:
> Hi!
> 
> I have a change request: I saw three message that I couldn't bring into context with any other event (SLES11 SP1 (2.6.32.49-0.3-default)):
> 
> Jan 18 15:33:04 h03 kernel: [2866825.805434] scsi: killing requests for dead queue
> Jan 18 15:33:04 h03 kernel: [2866825.812129] scsi: killing requests for dead queue
> Jan 18 15:33:04 h03 kernel: [2866825.815553] scsi: killing requests for dead queue
> 
> Unfortunately the kernel message doesn't give some kind of queue identifier, so that's hard to correlate with any other events.
> 
> Can this message be improved to include some variable output?

It was improved by:

commit 745718132c3c7cac98a622b610e239dcd5217f71
Author: Hannes Reinecke <hare@suse.de>
Date:   Wed Nov 9 08:39:24 2011 +0100

    [SCSI] Silencing 'killing requests for dead queue'
    
    When we tear down a device we try to flush all outstanding
    commands in scsi_free_queue(). However the check in
    scsi_request_fn() is imperfect as it only signals that
    we _might start_ aborting commands, not that we've actually
    aborted some.
    So move the printk inside the scsi_kill_request function,
    this will also give us a hint about which commands are aborted.
    
    Signed-off-by: Hannes Reinecke <hare@suse.de>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>