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

Neel Chauhan neel at neelc.org
Thu Dec 31 02:10:16 UTC 2020


I have attached two files:

  * pcidump: A dump of `pciconf -lv`
  * acpidump: A dump of `acpidump`

Hope this can help.

-Neel

On 2020-12-30 14:36, Neel Chauhan wrote:
> 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"
> _______________________________________________
> 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"
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: acpidump
URL: <http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20201230/85c776e9/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: pcidump
URL: <http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20201230/85c776e9/attachment-0001.ksh>


More information about the freebsd-hackers mailing list