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

[Mark Johnston]

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()...