Re: Fwd: Need NVME QUIRK BOGUS for SAMSUNG MZ1WV480HCGL-000MV (Samsung SM-953 Datacenter SSD)

Pankaj Raghav
2023-07-11T06:54:46Z

>> 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?

This looks a like a new device that might have a firmware update. I will ping
internally first.

As you mentioned, the recent addition of globally unique ID check
is breaking a lot of devices because of non-compliant firmware. I will try to create
some awareness about this issue internally as well.

--
Pankaj