* Re: [PATCH] scsi: Fix qemu boot hang problem
2014-08-10 12:54 [PATCH] scsi: Fix qemu boot hang problem Guenter Roeck
@ 2014-08-11 6:16 ` Hannes Reinecke
2014-08-11 14:12 ` Jens Axboe
` (3 subsequent siblings)
4 siblings, 0 replies; 11+ messages in thread
From: Hannes Reinecke @ 2014-08-11 6:16 UTC (permalink / raw)
To: Guenter Roeck, James E.J. Bottomley
Cc: linux-scsi, linux-kernel, Christoph Hellwig, Webb Scales,
Jens Axboe
On 08/10/2014 02:54 PM, Guenter Roeck wrote:
> The latest kernel fails to boot qemu arm images when using scsi
> for disk access. Boot gets stuck after the following messages.
>
> brd: module loaded
> sym53c8xx 0000:00:0c.0: enabling device (0100 -> 0103)
> sym0: <895a> rev 0x0 at pci 0000:00:0c.0 irq 93
> sym0: No NVRAM, ID 7, Fast-40, LVD, parity checking
> sym0: SCSI BUS has been reset.
> scsi host0: sym-2.2.3
>
> Bisect points to commit 71e75c97f97a ("scsi: convert device_busy to
> atomic_t"). Code inspection shows the following suspicious change
> in scsi_request_fn.
>
> out_delay:
> - if (sdev->device_busy == 0 && !scsi_device_blocked(sdev))
> + if (atomic_read(&sdev->device_busy) && !scsi_device_blocked(sdev))
> blk_delay_queue(q, SCSI_QUEUE_DELAY);
> }
>
> 'sdev->device_busy == 0' was replaced with 'atomic_read(&sdev->device_busy)',
> meaning the logic was reversed. Changing this expression to
> '!atomic_read(&sdev->device_busy)' fixes the problem.
>
> Cc: Christoph Hellwig <hch@lst.de>
> Cc: Hannes Reinecke <hare@suse.de>
> Cc: Webb Scales <webbnh@hp.com>
> Cc: Jens Axboe <axboe@kernel.dk>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> ---
> drivers/scsi/scsi_lib.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> index 9c44392..ce62e87 100644
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c
> @@ -1774,7 +1774,7 @@ static void scsi_request_fn(struct request_queue *q)
> blk_requeue_request(q, req);
> atomic_dec(&sdev->device_busy);
> out_delay:
> - if (atomic_read(&sdev->device_busy) && !scsi_device_blocked(sdev))
> + if (!atomic_read(&sdev->device_busy) && !scsi_device_blocked(sdev))
> blk_delay_queue(q, SCSI_QUEUE_DELAY);
> }
>
>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
hare@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [PATCH] scsi: Fix qemu boot hang problem
2014-08-10 12:54 [PATCH] scsi: Fix qemu boot hang problem Guenter Roeck
2014-08-11 6:16 ` Hannes Reinecke
@ 2014-08-11 14:12 ` Jens Axboe
2014-08-11 15:33 ` Venkatesh Srinivas
2014-08-15 18:22 ` Guenter Roeck
` (2 subsequent siblings)
4 siblings, 1 reply; 11+ messages in thread
From: Jens Axboe @ 2014-08-11 14:12 UTC (permalink / raw)
To: Guenter Roeck, James E.J. Bottomley
Cc: linux-scsi, linux-kernel, Christoph Hellwig, Hannes Reinecke,
Webb Scales
On 2014-08-10 06:54, Guenter Roeck wrote:
> The latest kernel fails to boot qemu arm images when using scsi
> for disk access. Boot gets stuck after the following messages.
>
> brd: module loaded
> sym53c8xx 0000:00:0c.0: enabling device (0100 -> 0103)
> sym0: <895a> rev 0x0 at pci 0000:00:0c.0 irq 93
> sym0: No NVRAM, ID 7, Fast-40, LVD, parity checking
> sym0: SCSI BUS has been reset.
> scsi host0: sym-2.2.3
>
> Bisect points to commit 71e75c97f97a ("scsi: convert device_busy to
> atomic_t"). Code inspection shows the following suspicious change
> in scsi_request_fn.
>
> out_delay:
> - if (sdev->device_busy == 0 && !scsi_device_blocked(sdev))
> + if (atomic_read(&sdev->device_busy) && !scsi_device_blocked(sdev))
> blk_delay_queue(q, SCSI_QUEUE_DELAY);
> }
>
> 'sdev->device_busy == 0' was replaced with 'atomic_read(&sdev->device_busy)',
> meaning the logic was reversed. Changing this expression to
> '!atomic_read(&sdev->device_busy)' fixes the problem.
>
> Cc: Christoph Hellwig <hch@lst.de>
> Cc: Hannes Reinecke <hare@suse.de>
> Cc: Webb Scales <webbnh@hp.com>
> Cc: Jens Axboe <axboe@kernel.dk>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> ---
> drivers/scsi/scsi_lib.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> index 9c44392..ce62e87 100644
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c
> @@ -1774,7 +1774,7 @@ static void scsi_request_fn(struct request_queue *q)
> blk_requeue_request(q, req);
> atomic_dec(&sdev->device_busy);
> out_delay:
> - if (atomic_read(&sdev->device_busy) && !scsi_device_blocked(sdev))
> + if (!atomic_read(&sdev->device_busy) && !scsi_device_blocked(sdev))
> blk_delay_queue(q, SCSI_QUEUE_DELAY);
> }
>
>
That's a no-brainer obvious fix!
Acked-by: Jens Axboe <axboe@fb.com>
--
Jens Axboe
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [PATCH] scsi: Fix qemu boot hang problem
2014-08-11 14:12 ` Jens Axboe
@ 2014-08-11 15:33 ` Venkatesh Srinivas
2014-08-11 16:21 ` Guenter Roeck
0 siblings, 1 reply; 11+ messages in thread
From: Venkatesh Srinivas @ 2014-08-11 15:33 UTC (permalink / raw)
To: Jens Axboe
Cc: Guenter Roeck, James E.J. Bottomley, linux-scsi, linux-kernel,
Christoph Hellwig, Hannes Reinecke, Webb Scales
Should we wrap the sdev->device_busy read and test in a new
scsi_device_busy(), so as to preserve the old polarity?
Reviewed-by: Venkatesh Srinivas <venkateshs@google.com>
On 8/11/14, Jens Axboe <axboe@kernel.dk> wrote:
> On 2014-08-10 06:54, Guenter Roeck wrote:
>> The latest kernel fails to boot qemu arm images when using scsi
>> for disk access. Boot gets stuck after the following messages.
>>
>> brd: module loaded
>> sym53c8xx 0000:00:0c.0: enabling device (0100 -> 0103)
>> sym0: <895a> rev 0x0 at pci 0000:00:0c.0 irq 93
>> sym0: No NVRAM, ID 7, Fast-40, LVD, parity checking
>> sym0: SCSI BUS has been reset.
>> scsi host0: sym-2.2.3
>>
>> Bisect points to commit 71e75c97f97a ("scsi: convert device_busy to
>> atomic_t"). Code inspection shows the following suspicious change
>> in scsi_request_fn.
>>
>> out_delay:
>> - if (sdev->device_busy == 0 && !scsi_device_blocked(sdev))
>> + if (atomic_read(&sdev->device_busy) &&
>> !scsi_device_blocked(sdev))
>> blk_delay_queue(q, SCSI_QUEUE_DELAY);
>> }
>>
>> 'sdev->device_busy == 0' was replaced with
>> 'atomic_read(&sdev->device_busy)',
>> meaning the logic was reversed. Changing this expression to
>> '!atomic_read(&sdev->device_busy)' fixes the problem.
>>
>> Cc: Christoph Hellwig <hch@lst.de>
>> Cc: Hannes Reinecke <hare@suse.de>
>> Cc: Webb Scales <webbnh@hp.com>
>> Cc: Jens Axboe <axboe@kernel.dk>
>> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
>> ---
>> drivers/scsi/scsi_lib.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
>> index 9c44392..ce62e87 100644
>> --- a/drivers/scsi/scsi_lib.c
>> +++ b/drivers/scsi/scsi_lib.c
>> @@ -1774,7 +1774,7 @@ static void scsi_request_fn(struct request_queue
>> *q)
>> blk_requeue_request(q, req);
>> atomic_dec(&sdev->device_busy);
>> out_delay:
>> - if (atomic_read(&sdev->device_busy) && !scsi_device_blocked(sdev))
>> + if (!atomic_read(&sdev->device_busy) && !scsi_device_blocked(sdev))
>> blk_delay_queue(q, SCSI_QUEUE_DELAY);
>> }
>>
>>
>
> That's a no-brainer obvious fix!
>
> Acked-by: Jens Axboe <axboe@fb.com>
>
>
> --
> Jens Axboe
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [PATCH] scsi: Fix qemu boot hang problem
2014-08-11 15:33 ` Venkatesh Srinivas
@ 2014-08-11 16:21 ` Guenter Roeck
0 siblings, 0 replies; 11+ messages in thread
From: Guenter Roeck @ 2014-08-11 16:21 UTC (permalink / raw)
To: Venkatesh Srinivas, Jens Axboe
Cc: James E.J. Bottomley, linux-scsi, linux-kernel, Christoph Hellwig,
Hannes Reinecke, Webb Scales
On 08/11/2014 08:33 AM, Venkatesh Srinivas wrote:
> Should we wrap the sdev->device_busy read and test in a new
> scsi_device_busy(), so as to preserve the old polarity?
>
I don't see a difference in polarity, or at least replacing '== 0' with '!'
is not a reverse in polarity for me. Anyway, I don't really care if
or how this is wrapped, as long as it is getting fixed.
Thanks,
Guenter
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] scsi: Fix qemu boot hang problem
2014-08-10 12:54 [PATCH] scsi: Fix qemu boot hang problem Guenter Roeck
2014-08-11 6:16 ` Hannes Reinecke
2014-08-11 14:12 ` Jens Axboe
@ 2014-08-15 18:22 ` Guenter Roeck
2014-08-15 18:34 ` Jens Axboe
2014-08-15 18:45 ` Webb Scales
2014-08-19 17:31 ` Christoph Hellwig
4 siblings, 1 reply; 11+ messages in thread
From: Guenter Roeck @ 2014-08-15 18:22 UTC (permalink / raw)
To: James E.J. Bottomley
Cc: linux-scsi, linux-kernel, Christoph Hellwig, Hannes Reinecke,
Webb Scales, Jens Axboe
ping ... the problem fixed by this patch still affects the upstream kernel
(v3.16-11383-gc9d2642) as well as -next (20140815).
Guenter
On 08/10/2014 05:54 AM, Guenter Roeck wrote:
> The latest kernel fails to boot qemu arm images when using scsi
> for disk access. Boot gets stuck after the following messages.
>
> brd: module loaded
> sym53c8xx 0000:00:0c.0: enabling device (0100 -> 0103)
> sym0: <895a> rev 0x0 at pci 0000:00:0c.0 irq 93
> sym0: No NVRAM, ID 7, Fast-40, LVD, parity checking
> sym0: SCSI BUS has been reset.
> scsi host0: sym-2.2.3
>
> Bisect points to commit 71e75c97f97a ("scsi: convert device_busy to
> atomic_t"). Code inspection shows the following suspicious change
> in scsi_request_fn.
>
> out_delay:
> - if (sdev->device_busy == 0 && !scsi_device_blocked(sdev))
> + if (atomic_read(&sdev->device_busy) && !scsi_device_blocked(sdev))
> blk_delay_queue(q, SCSI_QUEUE_DELAY);
> }
>
> 'sdev->device_busy == 0' was replaced with 'atomic_read(&sdev->device_busy)',
> meaning the logic was reversed. Changing this expression to
> '!atomic_read(&sdev->device_busy)' fixes the problem.
>
> Cc: Christoph Hellwig <hch@lst.de>
> Cc: Hannes Reinecke <hare@suse.de>
> Cc: Webb Scales <webbnh@hp.com>
> Cc: Jens Axboe <axboe@kernel.dk>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> ---
> drivers/scsi/scsi_lib.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> index 9c44392..ce62e87 100644
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c
> @@ -1774,7 +1774,7 @@ static void scsi_request_fn(struct request_queue *q)
> blk_requeue_request(q, req);
> atomic_dec(&sdev->device_busy);
> out_delay:
> - if (atomic_read(&sdev->device_busy) && !scsi_device_blocked(sdev))
> + if (!atomic_read(&sdev->device_busy) && !scsi_device_blocked(sdev))
> blk_delay_queue(q, SCSI_QUEUE_DELAY);
> }
>
>
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [PATCH] scsi: Fix qemu boot hang problem
2014-08-15 18:22 ` Guenter Roeck
@ 2014-08-15 18:34 ` Jens Axboe
2014-08-15 19:22 ` Christoph Hellwig
0 siblings, 1 reply; 11+ messages in thread
From: Jens Axboe @ 2014-08-15 18:34 UTC (permalink / raw)
To: Guenter Roeck, James E.J. Bottomley
Cc: linux-scsi, linux-kernel, Christoph Hellwig, Hannes Reinecke,
Webb Scales
On 2014-08-15 12:22, Guenter Roeck wrote:
> ping ... the problem fixed by this patch still affects the upstream kernel
> (v3.16-11383-gc9d2642) as well as -next (20140815).
James, could you upstream this one in time for -rc1?
--
Jens Axboe
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] scsi: Fix qemu boot hang problem
2014-08-15 18:34 ` Jens Axboe
@ 2014-08-15 19:22 ` Christoph Hellwig
2014-08-15 19:26 ` Guenter Roeck
0 siblings, 1 reply; 11+ messages in thread
From: Christoph Hellwig @ 2014-08-15 19:22 UTC (permalink / raw)
To: Jens Axboe
Cc: Guenter Roeck, James E.J. Bottomley, linux-scsi, linux-kernel,
Christoph Hellwig, Hannes Reinecke, Webb Scales
On Fri, Aug 15, 2014 at 12:34:22PM -0600, Jens Axboe wrote:
> On 2014-08-15 12:22, Guenter Roeck wrote:
>> ping ... the problem fixed by this patch still affects the upstream kernel
>> (v3.16-11383-gc9d2642) as well as -next (20140815).
>
> James, could you upstream this one in time for -rc1?
It's in the core-for-3.17 updates I sent to James yesterday, just needs to
be forwarded..
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] scsi: Fix qemu boot hang problem
2014-08-15 19:22 ` Christoph Hellwig
@ 2014-08-15 19:26 ` Guenter Roeck
0 siblings, 0 replies; 11+ messages in thread
From: Guenter Roeck @ 2014-08-15 19:26 UTC (permalink / raw)
To: Christoph Hellwig, Jens Axboe
Cc: James E.J. Bottomley, linux-scsi, linux-kernel, Hannes Reinecke,
Webb Scales
On 08/15/2014 12:22 PM, Christoph Hellwig wrote:
> On Fri, Aug 15, 2014 at 12:34:22PM -0600, Jens Axboe wrote:
>> On 2014-08-15 12:22, Guenter Roeck wrote:
>>> ping ... the problem fixed by this patch still affects the upstream kernel
>>> (v3.16-11383-gc9d2642) as well as -next (20140815).
>>
>> James, could you upstream this one in time for -rc1?
>
> It's in the core-for-3.17 updates I sent to James yesterday, just needs to
> be forwarded..
>
Great, thanks a lot!
Guenter
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] scsi: Fix qemu boot hang problem
2014-08-10 12:54 [PATCH] scsi: Fix qemu boot hang problem Guenter Roeck
` (2 preceding siblings ...)
2014-08-15 18:22 ` Guenter Roeck
@ 2014-08-15 18:45 ` Webb Scales
2014-08-19 17:31 ` Christoph Hellwig
4 siblings, 0 replies; 11+ messages in thread
From: Webb Scales @ 2014-08-15 18:45 UTC (permalink / raw)
To: Guenter Roeck, James E.J. Bottomley
Cc: linux-scsi, linux-kernel, Christoph Hellwig, Hannes Reinecke,
Jens Axboe
On 8/10/14 8:54 AM, Guenter Roeck wrote:
> The latest kernel fails to boot qemu arm images when using scsi
> for disk access. Boot gets stuck after the following messages.
>
> brd: module loaded
> sym53c8xx 0000:00:0c.0: enabling device (0100 -> 0103)
> sym0: <895a> rev 0x0 at pci 0000:00:0c.0 irq 93
> sym0: No NVRAM, ID 7, Fast-40, LVD, parity checking
> sym0: SCSI BUS has been reset.
> scsi host0: sym-2.2.3
>
> Bisect points to commit 71e75c97f97a ("scsi: convert device_busy to
> atomic_t"). Code inspection shows the following suspicious change
> in scsi_request_fn.
>
> out_delay:
> - if (sdev->device_busy == 0 && !scsi_device_blocked(sdev))
> + if (atomic_read(&sdev->device_busy) && !scsi_device_blocked(sdev))
> blk_delay_queue(q, SCSI_QUEUE_DELAY);
> }
>
> 'sdev->device_busy == 0' was replaced with 'atomic_read(&sdev->device_busy)',
> meaning the logic was reversed. Changing this expression to
> '!atomic_read(&sdev->device_busy)' fixes the problem.
>
> Cc: Christoph Hellwig <hch@lst.de>
> Cc: Hannes Reinecke <hare@suse.de>
> Cc: Webb Scales <webbnh@hp.com>
> Cc: Jens Axboe <axboe@kernel.dk>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> ---
> drivers/scsi/scsi_lib.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> index 9c44392..ce62e87 100644
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c
> @@ -1774,7 +1774,7 @@ static void scsi_request_fn(struct request_queue *q)
> blk_requeue_request(q, req);
> atomic_dec(&sdev->device_busy);
> out_delay:
> - if (atomic_read(&sdev->device_busy) && !scsi_device_blocked(sdev))
> + if (!atomic_read(&sdev->device_busy) && !scsi_device_blocked(sdev))
> blk_delay_queue(q, SCSI_QUEUE_DELAY);
> }
Good catch!
Reviewed-by: Webb Scales <webbnh@hp.com>
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [PATCH] scsi: Fix qemu boot hang problem
2014-08-10 12:54 [PATCH] scsi: Fix qemu boot hang problem Guenter Roeck
` (3 preceding siblings ...)
2014-08-15 18:45 ` Webb Scales
@ 2014-08-19 17:31 ` Christoph Hellwig
4 siblings, 0 replies; 11+ messages in thread
From: Christoph Hellwig @ 2014-08-19 17:31 UTC (permalink / raw)
To: Guenter Roeck
Cc: James E.J. Bottomley, linux-scsi, linux-kernel, Christoph Hellwig,
Hannes Reinecke, Webb Scales, Jens Axboe, Linus Torvalds
James, can you please send this on ASAP? Sitting for oever a week
on a boot regression that comes with a patch isn't reasonable.
On Sun, Aug 10, 2014 at 05:54:25AM -0700, Guenter Roeck wrote:
> The latest kernel fails to boot qemu arm images when using scsi
> for disk access. Boot gets stuck after the following messages.
>
> brd: module loaded
> sym53c8xx 0000:00:0c.0: enabling device (0100 -> 0103)
> sym0: <895a> rev 0x0 at pci 0000:00:0c.0 irq 93
> sym0: No NVRAM, ID 7, Fast-40, LVD, parity checking
> sym0: SCSI BUS has been reset.
> scsi host0: sym-2.2.3
>
> Bisect points to commit 71e75c97f97a ("scsi: convert device_busy to
> atomic_t"). Code inspection shows the following suspicious change
> in scsi_request_fn.
>
> out_delay:
> - if (sdev->device_busy == 0 && !scsi_device_blocked(sdev))
> + if (atomic_read(&sdev->device_busy) && !scsi_device_blocked(sdev))
> blk_delay_queue(q, SCSI_QUEUE_DELAY);
> }
>
> 'sdev->device_busy == 0' was replaced with 'atomic_read(&sdev->device_busy)',
> meaning the logic was reversed. Changing this expression to
> '!atomic_read(&sdev->device_busy)' fixes the problem.
>
> Cc: Christoph Hellwig <hch@lst.de>
> Cc: Hannes Reinecke <hare@suse.de>
> Cc: Webb Scales <webbnh@hp.com>
> Cc: Jens Axboe <axboe@kernel.dk>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> ---
> drivers/scsi/scsi_lib.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> index 9c44392..ce62e87 100644
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c
> @@ -1774,7 +1774,7 @@ static void scsi_request_fn(struct request_queue *q)
> blk_requeue_request(q, req);
> atomic_dec(&sdev->device_busy);
> out_delay:
> - if (atomic_read(&sdev->device_busy) && !scsi_device_blocked(sdev))
> + if (!atomic_read(&sdev->device_busy) && !scsi_device_blocked(sdev))
> blk_delay_queue(q, SCSI_QUEUE_DELAY);
> }
>
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
---end quoted text---
^ permalink raw reply [flat|nested] 11+ messages in thread