[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ZKwqvTMPVmhnkZjS@kbusch-mbp.dhcp.thefacebook.com>
Date: Mon, 10 Jul 2023 09:58:53 -0600
From: Keith Busch <kbusch@...nel.org>
To: Linux regressions mailing list <regressions@...ts.linux.dev>
Cc: Bagas Sanjaya <bagasdotme@...il.com>, Jens Axboe <axboe@...nel.dk>,
Christoph Hellwig <hch@....de>,
Sagi Grimberg <sagi@...mberg.me>,
"Clemens S." <cspringsguth@...il.com>,
Martin Belanger <martin.belanger@...l.com>,
Chaitanya Kulkarni <kch@...dia.com>,
John Meneghini <jmeneghi@...hat.com>,
Hannes Reinecke <hare@...e.de>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux NVMe <linux-nvme@...ts.infradead.org>,
Pankaj Raghav <p.raghav@...sung.com>,
Kanchan Joshi <joshi.k@...sung.com>
Subject: Re: Fwd: Need NVME QUIRK BOGUS for SAMSUNG MZ1WV480HCGL-000MV
(Samsung SM-953 Datacenter SSD)
On Mon, Jul 10, 2023 at 10:52:52AM +0200, Linux regression tracking (Thorsten Leemhuis) wrote:
> On 27.06.23 18:10, Keith Busch wrote:
> > On Mon, Jun 26, 2023 at 08:15:49AM +0700, Bagas Sanjaya wrote:
> >> See Bugzilla for the full thread.
> >>
> >> The reporter had a quirk (see above) that fixed this regression,
> >> nevertheless I'm adding it to regzbot to make sure it doesn't fall
> >> through cracks unnoticed:
> >>
> >> #regzbot introduced: 86c2457a8e8112f https://bugzilla.kernel.org/show_bug.cgi?id=217593
> >> #regzbot title: NVME_QUIRK_BOGUS_NID is needed for SAMSUNG MZ1WV480HCGL-000MV
> >
> > These bug reports really should go to the vendors that created the
> > broken device with non-unique "unique" fields.
>
> I understand that, but I think we need middlemen for that, as I or Bagas
> don't have the contacts -- and it's IMHO also a bit much too ask us for
> in general, as regression tracking is hard enough already. At least
> unless this becomes something that happen regularly, then a list of
> persons we could contact would be fine I guess. But we simply can't deal
> with too many subsystem specific special cases.
I'm not asking the Linux regression trackers to fill that role, though.
I'm asking people who experience these issues report it to their vendor
directly because these device makers apparently have zero clue that
their spec non-compliance is causing painful experiences for their
customers and annoyance for maintainers. They keep pumping out more and
more devices with the same breakage.
This particular vendor has been great at engaging with Linux, but that's
not necessarily normal among all device makers, and I don't have
contacts with the majority of the vendors we've had to quirk for this
issue.
We did complain to the NVMe spec workgroup that their complaince cert
suite is not testing for this. There was a little initial interest in
fixing that gap, but it fizzled out...
> Another request came in today, even with a pseudo-patch:
> https://bugzilla.kernel.org/show_bug.cgi?id=217649
>
> To quote:
> ```
> As with numerous NVMe controllers these days, Samsung's
> MZAL41T0HBLB-00BL2, which Lenovo builds into their 16ARP8 also suffers
> from invalid IDs, breaking suspend and hibernate also on the latest
> kernel 6.4.2.
>
> The following change restores this functionality:
>
> File: root/drivers/nvme/host/pci.c
> Change:
>
> - { PCI_DEVICE(0x144d, 0xa80b), /* Samsung PM9B1 256G and 512G */
> - .driver_data = NVME_QUIRK_DISABLE_WRITE_ZEROES, },
>
> + { PCI_DEVICE(0x144d, 0xa80b), /* Samsung PM9B1 256G, 512G and 1TB */
> + .driver_data = NVME_QUIRK_BOGUS_NID |
> + NVME_QUIRK_DISABLE_WRITE_ZEROES, },
Panjaj, okay with this one too?
Powered by blists - more mailing lists