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

[Neel Chauhan]

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"