Debugging a WIP PCI/ACPI patch: Bad tailq NEXT(0xffffffff81cde660->tqh_last) != NULL

[Neel Chauhan]

Mark, thank you so much for your help!

However, I am getting an issue with `pci_read_device()` where it returns 
a `vid` (PCI Vendor ID) of 0xffff.

This ends up returning "Cannot allocate dinfo!" from vmd.

Log (via grep): https://imgur.com/a/tAmmY7i

What usually causes this?

I'm no expert on PC hardware, my $DAYJOB is not related to hardware (I'm 
a C#/.NET developer for a living).

I do however want my Spectre running FreeBSD and am willing to write 
patches (to some extent at least).

-Neel

On 2020-12-30 10:03, Neel Chauhan wrote:
> Thank you so much!
> 
> Adding a rman_fini() call made my system boot.
> 
> I get stuck at a "Cannot allocate dinfo!" error now (I can't see the
> SSD), but I will debug first before coming back.
> 
> -Neel
> 
> On 2020-12-30 09:06, Mark Johnston wrote:
>> On Wed, Dec 30, 2020 at 08:43:17AM -0800, Neel Chauhan wrote:
>>> Hi all,
>>> 
>>> I'm writing a patch to support the VMD subsystem in Intel TigerLake
>>> systems such as the HP Spectre x360 13t-aw200. VMD is needed for NVMe
>>> here.
>>> 
>>> The patch is as follows
>>> 
>>> --- a/sys/dev/vmd/vmd.c
>>> +++ b/sys/dev/vmd/vmd.c
>>> @@ -66,13 +66,20 @@ struct vmd_type {
>>>   #define INTEL_VENDOR_ID                0x8086
>>>   #define INTEL_DEVICE_ID_VMD    0x201d
>>>   #define INTEL_DEVICE_ID_VMD2   0x28c0
>>> +#define INTEL_DEVICE_ID_VMD3   0x9a0b
>>> 
>>>   static struct vmd_type vmd_devs[] = {
>>>           { INTEL_VENDOR_ID, INTEL_DEVICE_ID_VMD,  "Intel Volume
>>> Management Device" },
>>>           { INTEL_VENDOR_ID, INTEL_DEVICE_ID_VMD2, "Intel Volume
>>> Management Device" },
>>> +        { INTEL_VENDOR_ID, INTEL_DEVICE_ID_VMD3, "Intel Volume
>>> Management Device" },
>>>           { 0, 0, NULL }
>>> 
>>> However, when I use the patch, I get a kernel panic related to PCI:
>>> https://imgur.com/a/XUQksOi (sorry for the image)
>>> 
>>> It gives me the Bad tailq NEXT(0xffffffff81cde660->tqh_last) != NULL
>>> error.
>>> 
>>> Could you please help me figure out why it's panicking?
>> 
>> Based on the backtrace, we are panicking in rman_init() because the
>> global rman_head list is corrupted (the panic message is basically
>> stating that the next element of the last element of the list is not
>> NULL).  This suggests that the item was freed without removing it from
>> the list, i.e., an rman_fini() call is missing.
>> 
>> vmd_attach() creates a resource container with rman_init().  If
>> vmd_attach() fails for some reason, it calls vmd_free(), which is
>> supposed to roll back anything done by vmd_attach().  Note that if
>> attach is successful, the driver subsystem may later call vmd_detach()
>> to deinitialize the driver, and vmd_detach() does a bit of extra work 
>> in
>> addition to calling vmd_free()...
>> _______________________________________________
>> freebsd-hackers at freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>> To unsubscribe, send any mail to 
>> "freebsd-hackers-unsubscribe at freebsd.org"
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to 
> "freebsd-hackers-unsubscribe at freebsd.org"