Re: Intel TigerLake NVMe vmd: Adding Support & Debugging a Patch

From: Neel Chauhan <neel_at_neelc.org>
Date: Wed, 30 Dec 2020 21:04:12 -0800
I think I found the issue:

This PCIe controller is not detected:

10000:e0:1d.0 PCI bridge [0604]: Intel Corporation Tiger Lake-LP PCI 
Express Root Port #9 [8086:a0b0] (rev 20) SI

I believe the above PCIe controller is exposed by VMD (as it is on 
Linux), but FreeBSD vmd/vmd_bus is unable to attach this controller.

It is likely because VMD uses PCI domain above 0x10000 but we aren't 
looking at this.

Source: 
https://github.com/torvalds/linux/blob/master/drivers/pci/controller/vmd.c#L437

Don't yet have a patch though. Sorry for the number of emails earlier.

-Neel

On 2020-12-30 10:04, Chuck Tuffli wrote:
> On Tue, Dec 29, 2020 at 6:30 PM Neel Chauhan <neel_at_neelc.org> wrote:
>> 
>> Hi freebsd-hackers_at_, CC'd freebsd-current_at_,
>> 
>> I hope you all had a wonderful holiday season.
>> 
>> I recently got a HP Spectre x360 13t-aw200 which is an Intel
>> TigerLake-based laptop. It has the Intel "Evo" branding and an 
>> "Optane"
>> SSD which I disabled (so I can get a "second" SSD).
>> 
>> On the Spectre, the NVMe is not detected: https://imgur.com/a/ighTwHQ
>> 
>> I don't know if it is HP or Intel, but the VMD IDs device id is
>> 8086:9a0b. I'm guessing Intel since Dell laptops (XPS, Vostro) also 
>> have
>> this device ID [1].
>> 
>> Sadly, NVMe RAID is forced on this laptop.
>> 
>> I wrote a rough patch to add the device IDs, and the patch is below:
> 
> FWIW, that is the same change I would have made. Peeking at the Linux
> vmd driver, it doesn't appear to do anything special for 8086:9a0b as
> compared to the 8086:2a0c device the FreeBSD driver already supports.
> That said, the Linux driver reads a capability register to determine
> the bus number start (vmd_bus_number_start()) which I don't see in the
> FreeBSD driver. This is curious because, looking at the "lspci all"
> output from the XPS link you provided, the NVMe device shows up in PCI
> domain 0x1000 (i.e. not 0x0000). Which (and I have no direct
> experience with this device or code) only happens if the bus number
> start function returns 0x0.
> 
> What is the output from
> # pciconf -rb pci0:0:14:0 0x40:0x48
> 
> --chuck
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to 
> "freebsd-current-unsubscribe_at_freebsd.org"
Received on Thu Dec 31 2020 - 04:04:17 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:26 UTC