LKML Archive on lore.kernel.org
 help / color / Atom feed
* v5.9-rc1 commit reliably breaks pci nvme detection
@ 2020-08-17 13:50 Ahmed S. Darwish
  2020-08-17 15:56 ` Keith Busch
  0 siblings, 1 reply; 9+ messages in thread
From: Ahmed S. Darwish @ 2020-08-17 13:50 UTC (permalink / raw)
  To: Keith Busch, Jens Axboe, Sagi Grimberg
  Cc: Chaitanya Kulkarni, linux-nvme, linux-kernel

Hello,

Below v5.9-rc1 commit reliably breaks my boot on a Thinkpad e480
laptop. PCI nvme detection fails, and the kernel becomes not able
anymore to find the rootfs / parse "root=".

Bisecting v5.8=>v5.9-rc1 blames that commit. Reverting it *reliably*
fixes the problem and makes me able to boot v5.9-rc1.

Please advise.

commit 61f3b89630973037f67d8e25e5d26e80a51a7b37
Author: Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com>
Date:   Wed Jun 17 10:05:13 2020 +0200

    nvme-pci: use unsigned for io queue depth
    
    The NVMe PCIe declares module parameter io_queue_depth as int. Change
    this to u16 as queue depth can never be negative. Now to reflect this
    update module parameter getter function from param_get_int() ->
    param_get_uint() and respective setter function with type of n changed
    from int to u16 with param_set_int() to param_set_ushort(). Finally
    update struct nvme_dev q_depth member to u16 and use u16 in min_t()
    when calculating dev->q_depth in the nvme_pci_enable() (since q_depth is
    now u16) and use unsigned int instead of int when calculating
    dev->tagset.queue_depth as target variable tagset->queue_depth is of type
    unsigned int in nvme_dev_add().

Thanks,

--
Ahmed S. Darwish
Linutronix GmbH

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: v5.9-rc1 commit reliably breaks pci nvme detection
  2020-08-17 13:50 v5.9-rc1 commit reliably breaks pci nvme detection Ahmed S. Darwish
@ 2020-08-17 15:56 ` Keith Busch
  2020-08-17 15:58   ` Jens Axboe
  0 siblings, 1 reply; 9+ messages in thread
From: Keith Busch @ 2020-08-17 15:56 UTC (permalink / raw)
  To: Ahmed S. Darwish
  Cc: Jens Axboe, Sagi Grimberg, Chaitanya Kulkarni, linux-nvme, linux-kernel

On Mon, Aug 17, 2020 at 03:50:11PM +0200, Ahmed S. Darwish wrote:
> Hello,
> 
> Below v5.9-rc1 commit reliably breaks my boot on a Thinkpad e480
> laptop. PCI nvme detection fails, and the kernel becomes not able
> anymore to find the rootfs / parse "root=".
> 
> Bisecting v5.8=>v5.9-rc1 blames that commit. Reverting it *reliably*
> fixes the problem and makes me able to boot v5.9-rc1.

The fix is staged in the nvme tree here:

  http://git.infradead.org/nvme.git/commit/286155561ecd13b6c85a78eaf2880d3baea03b9e

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: v5.9-rc1 commit reliably breaks pci nvme detection
  2020-08-17 15:56 ` Keith Busch
@ 2020-08-17 15:58   ` Jens Axboe
  2020-08-20 15:35     ` Jens Axboe
  0 siblings, 1 reply; 9+ messages in thread
From: Jens Axboe @ 2020-08-17 15:58 UTC (permalink / raw)
  To: Keith Busch, Ahmed S. Darwish
  Cc: linux-nvme, Sagi Grimberg, Chaitanya Kulkarni, linux-kernel

On 8/17/20 8:56 AM, Keith Busch wrote:
> On Mon, Aug 17, 2020 at 03:50:11PM +0200, Ahmed S. Darwish wrote:
>> Hello,
>>
>> Below v5.9-rc1 commit reliably breaks my boot on a Thinkpad e480
>> laptop. PCI nvme detection fails, and the kernel becomes not able
>> anymore to find the rootfs / parse "root=".
>>
>> Bisecting v5.8=>v5.9-rc1 blames that commit. Reverting it *reliably*
>> fixes the problem and makes me able to boot v5.9-rc1.
> 
> The fix is staged in the nvme tree here:
> 
>   http://git.infradead.org/nvme.git/commit/286155561ecd13b6c85a78eaf2880d3baea03b9e

That would have been nice to have in -rc1...

-- 
Jens Axboe


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: v5.9-rc1 commit reliably breaks pci nvme detection
  2020-08-17 15:58   ` Jens Axboe
@ 2020-08-20 15:35     ` Jens Axboe
  2020-08-20 17:07       ` Ahmed S. Darwish
  0 siblings, 1 reply; 9+ messages in thread
From: Jens Axboe @ 2020-08-20 15:35 UTC (permalink / raw)
  To: Keith Busch, Ahmed S. Darwish
  Cc: linux-nvme, Sagi Grimberg, Chaitanya Kulkarni, linux-kernel

On 8/17/20 9:58 AM, Jens Axboe wrote:
> On 8/17/20 8:56 AM, Keith Busch wrote:
>> On Mon, Aug 17, 2020 at 03:50:11PM +0200, Ahmed S. Darwish wrote:
>>> Hello,
>>>
>>> Below v5.9-rc1 commit reliably breaks my boot on a Thinkpad e480
>>> laptop. PCI nvme detection fails, and the kernel becomes not able
>>> anymore to find the rootfs / parse "root=".
>>>
>>> Bisecting v5.8=>v5.9-rc1 blames that commit. Reverting it *reliably*
>>> fixes the problem and makes me able to boot v5.9-rc1.
>>
>> The fix is staged in the nvme tree here:
>>
>>   http://git.infradead.org/nvme.git/commit/286155561ecd13b6c85a78eaf2880d3baea03b9e
> 
> That would have been nice to have in -rc1...

And now we're getting very close to shipping items for -rc2, and it's still
not in. Can we please get the nvme pull request out for -rc2?

-- 
Jens Axboe


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: v5.9-rc1 commit reliably breaks pci nvme detection
  2020-08-20 15:35     ` Jens Axboe
@ 2020-08-20 17:07       ` Ahmed S. Darwish
  2020-08-20 17:10         ` Jens Axboe
  0 siblings, 1 reply; 9+ messages in thread
From: Ahmed S. Darwish @ 2020-08-20 17:07 UTC (permalink / raw)
  To: Jens Axboe
  Cc: Keith Busch, linux-nvme, Sagi Grimberg, Chaitanya Kulkarni, linux-kernel

On Thu, Aug 20, 2020 at 09:35:38AM -0600, Jens Axboe wrote:
> On 8/17/20 9:58 AM, Jens Axboe wrote:
> > On 8/17/20 8:56 AM, Keith Busch wrote:
> >> On Mon, Aug 17, 2020 at 03:50:11PM +0200, Ahmed S. Darwish wrote:
> >>> Hello,
> >>>
> >>> Below v5.9-rc1 commit reliably breaks my boot on a Thinkpad e480
> >>> laptop. PCI nvme detection fails, and the kernel becomes not able
> >>> anymore to find the rootfs / parse "root=".
> >>>
> >>> Bisecting v5.8=>v5.9-rc1 blames that commit. Reverting it *reliably*
> >>> fixes the problem and makes me able to boot v5.9-rc1.
> >>
> >> The fix is staged in the nvme tree here:
> >>
> >>   http://git.infradead.org/nvme.git/commit/286155561ecd13b6c85a78eaf2880d3baea03b9e
> >
> > That would have been nice to have in -rc1...
>
> And now we're getting very close to shipping items for -rc2, and it's still
> not in. Can we please get the nvme pull request out for -rc2?
>

I keep wondering that myself. Completely breaking the boot like this is
really not nice -- and for x86-64 laptops no less :-(

The fix is really small and isolated. "Urgent pull requests", containing
only a fix or two, were created *exactly* for this reson...

Thanks,

--
Ahmed S. Darwish
Linutronix GmbH

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: v5.9-rc1 commit reliably breaks pci nvme detection
  2020-08-20 17:07       ` Ahmed S. Darwish
@ 2020-08-20 17:10         ` Jens Axboe
  2020-08-20 17:12           ` Christoph Hellwig
  0 siblings, 1 reply; 9+ messages in thread
From: Jens Axboe @ 2020-08-20 17:10 UTC (permalink / raw)
  To: Ahmed S. Darwish
  Cc: Keith Busch, linux-nvme, Sagi Grimberg, Chaitanya Kulkarni, linux-kernel

On 8/20/20 11:07 AM, Ahmed S. Darwish wrote:
> On Thu, Aug 20, 2020 at 09:35:38AM -0600, Jens Axboe wrote:
>> On 8/17/20 9:58 AM, Jens Axboe wrote:
>>> On 8/17/20 8:56 AM, Keith Busch wrote:
>>>> On Mon, Aug 17, 2020 at 03:50:11PM +0200, Ahmed S. Darwish wrote:
>>>>> Hello,
>>>>>
>>>>> Below v5.9-rc1 commit reliably breaks my boot on a Thinkpad e480
>>>>> laptop. PCI nvme detection fails, and the kernel becomes not able
>>>>> anymore to find the rootfs / parse "root=".
>>>>>
>>>>> Bisecting v5.8=>v5.9-rc1 blames that commit. Reverting it *reliably*
>>>>> fixes the problem and makes me able to boot v5.9-rc1.
>>>>
>>>> The fix is staged in the nvme tree here:
>>>>
>>>>   http://git.infradead.org/nvme.git/commit/286155561ecd13b6c85a78eaf2880d3baea03b9e
>>>
>>> That would have been nice to have in -rc1...
>>
>> And now we're getting very close to shipping items for -rc2, and it's still
>> not in. Can we please get the nvme pull request out for -rc2?
>>
> 
> I keep wondering that myself. Completely breaking the boot like this is
> really not nice -- and for x86-64 laptops no less :-(

To be fair, I've only heard this one complaint about it, so hopefully it's
not too widespread. I'm on an x86-64 laptop myself with nvme, and it works
just fine :-)

> The fix is really small and isolated. "Urgent pull requests", containing
> only a fix or two, were created *exactly* for this reson...

Totally agree on that, it should have gone in for -rc1. This will be going
upstream tomorrow, so the end is near...

-- 
Jens Axboe


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: v5.9-rc1 commit reliably breaks pci nvme detection
  2020-08-20 17:10         ` Jens Axboe
@ 2020-08-20 17:12           ` Christoph Hellwig
  2020-08-20 17:14             ` Jens Axboe
  2020-08-21  7:28             ` John Garry
  0 siblings, 2 replies; 9+ messages in thread
From: Christoph Hellwig @ 2020-08-20 17:12 UTC (permalink / raw)
  To: Jens Axboe
  Cc: Ahmed S. Darwish, Keith Busch, linux-nvme, Sagi Grimberg,
	Chaitanya Kulkarni, linux-kernel

On Thu, Aug 20, 2020 at 11:10:58AM -0600, Jens Axboe wrote:
> To be fair, I've only heard this one complaint about it, so hopefully it's
> not too widespread. I'm on an x86-64 laptop myself with nvme, and it works
> just fine :-)

The cause for this is the weird NVMe of by ones, where 0 in a field
means 1.  So for the overflow to happen you need a controller that
supports USHORT_MAX queue entries.  Which don't seem to be all that
common.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: v5.9-rc1 commit reliably breaks pci nvme detection
  2020-08-20 17:12           ` Christoph Hellwig
@ 2020-08-20 17:14             ` Jens Axboe
  2020-08-21  7:28             ` John Garry
  1 sibling, 0 replies; 9+ messages in thread
From: Jens Axboe @ 2020-08-20 17:14 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Ahmed S. Darwish, Keith Busch, linux-nvme, Sagi Grimberg,
	Chaitanya Kulkarni, linux-kernel

On 8/20/20 11:12 AM, Christoph Hellwig wrote:
> On Thu, Aug 20, 2020 at 11:10:58AM -0600, Jens Axboe wrote:
>> To be fair, I've only heard this one complaint about it, so hopefully it's
>> not too widespread. I'm on an x86-64 laptop myself with nvme, and it works
>> just fine :-)
> 
> The cause for this is the weird NVMe of by ones, where 0 in a field
> means 1.  So for the overflow to happen you need a controller that
> supports USHORT_MAX queue entries.  Which don't seem to be all that
> common.

Yeah, don't think I've ever seen those. I come across 1023 and 128 all
the time, but I don't have one in my arsenal of NVMe drives that is
any different than those two.

-- 
Jens Axboe


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: v5.9-rc1 commit reliably breaks pci nvme detection
  2020-08-20 17:12           ` Christoph Hellwig
  2020-08-20 17:14             ` Jens Axboe
@ 2020-08-21  7:28             ` John Garry
  1 sibling, 0 replies; 9+ messages in thread
From: John Garry @ 2020-08-21  7:28 UTC (permalink / raw)
  To: Christoph Hellwig, Jens Axboe
  Cc: Sagi Grimberg, Chaitanya Kulkarni, linux-kernel, linux-nvme,
	Ahmed S. Darwish, Keith Busch

On 20/08/2020 18:12, Christoph Hellwig wrote:
> On Thu, Aug 20, 2020 at 11:10:58AM -0600, Jens Axboe wrote:
>> To be fair, I've only heard this one complaint about it, so hopefully it's
>> not too widespread. I'm on an x86-64 laptop myself with nvme, and it works
>> just fine:-)
> The cause for this is the weird NVMe of by ones, where 0 in a field
> means 1.

I thought that this was a common trick by spec writers to fit a number 
in range (0, 2^x] in x bits (as opposed to x+1).

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, back to index

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-08-17 13:50 v5.9-rc1 commit reliably breaks pci nvme detection Ahmed S. Darwish
2020-08-17 15:56 ` Keith Busch
2020-08-17 15:58   ` Jens Axboe
2020-08-20 15:35     ` Jens Axboe
2020-08-20 17:07       ` Ahmed S. Darwish
2020-08-20 17:10         ` Jens Axboe
2020-08-20 17:12           ` Christoph Hellwig
2020-08-20 17:14             ` Jens Axboe
2020-08-21  7:28             ` John Garry

LKML Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lkml.kernel.org/lkml/0 lkml/git/0.git
	git clone --mirror https://lkml.kernel.org/lkml/1 lkml/git/1.git
	git clone --mirror https://lkml.kernel.org/lkml/2 lkml/git/2.git
	git clone --mirror https://lkml.kernel.org/lkml/3 lkml/git/3.git
	git clone --mirror https://lkml.kernel.org/lkml/4 lkml/git/4.git
	git clone --mirror https://lkml.kernel.org/lkml/5 lkml/git/5.git
	git clone --mirror https://lkml.kernel.org/lkml/6 lkml/git/6.git
	git clone --mirror https://lkml.kernel.org/lkml/7 lkml/git/7.git
	git clone --mirror https://lkml.kernel.org/lkml/8 lkml/git/8.git
	git clone --mirror https://lkml.kernel.org/lkml/9 lkml/git/9.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ https://lkml.kernel.org/lkml \
		linux-kernel@vger.kernel.org
	public-inbox-index lkml

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git