Date: Wed, 30 Dec 2020 10:03:39 -0800 From: Neel Chauhan <neel@neelc.org> To: Mark Johnston <markj@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: Debugging a WIP PCI/ACPI patch: Bad tailq NEXT(0xffffffff81cde660->tqh_last) != NULL Message-ID: <3c9ff844e527daacd04c51f48836b57d@neelc.org> In-Reply-To: <X%2ByzpNIclmFYgbr7@raichu> References: <44528336fa9168966d121bf771e1e229@neelc.org> <X%2ByzpNIclmFYgbr7@raichu>
next in thread | previous in thread | raw e-mail | index | archive | help
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@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to
> "freebsd-hackers-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3c9ff844e527daacd04c51f48836b57d>