Date: Thu, 31 Dec 2020 12:07:44 -0800 From: Doug Ambrisko <ambrisko@ambrisko.com> To: Mark Johnston <markj@freebsd.org> Cc: Neel Chauhan <neel@neelc.org>, freebsd-hackers@freebsd.org, ambrisko@freebsd.org Subject: Re: Debugging a WIP PCI/ACPI patch: Bad tailq NEXT(0xffffffff81cde660->tqh_last) != NULL Message-ID: <20201231200744.GA95383@ambrisko.com> In-Reply-To: <X%2B3tfbxHGdiW1Kvt@raichu> References: <44528336fa9168966d121bf771e1e229@neelc.org> <X%2ByzpNIclmFYgbr7@raichu> <3c9ff844e527daacd04c51f48836b57d@neelc.org> <dbcc0e54eeb0080620ee4fb6d14845fc@neelc.org> <e73228a75b8f05c83214c62ed7e1ba68@neelc.org> <X%2B3tfbxHGdiW1Kvt@raichu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Dec 31, 2020 at 10:25:49AM -0500, Mark Johnston wrote: | On Wed, Dec 30, 2020 at 06:10:11PM -0800, Neel Chauhan wrote: | > 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). | | Hi Neel, | | In the future please avoid posting to multiple threads on the same | topic. | | I'm not sure what the problem is here. I cc'ed Doug, the author of the | driver, to see if he can help. For context, the goal is to add support | for a new device (ID 0x9a0b) to vmd(4), but vmd_bus_attach() fails with | the aforementioned error. We found a minor bug already in that | vmd_attach() does not call rman_fini() in error paths, but I don't know | enough about vmd to usefully comment further. FYI, looks like this needs to be ported over from Linux: static char __iomem *vmd_cfg_addr(struct vmd_dev *vmd, struct pci_bus *bus, unsigned int devfn, int reg, int len) { char __iomem *addr = vmd->cfgbar + ((bus->number - vmd->busn_start) << 20) + (devfn << 12) + reg; to vmd_read_config offset = (b << 20) + (s << 15) + (f << 12) + reg; vmd_write_config(device_t dev, u_int b, u_int s, u_int f, u_int reg, offset = (b << 20) + (s << 15) + (f << 12) + reg; ie. offset = ((b - sc->vmd_bus_start) << 20) + (s << 15) + (f << 12) + reg; vmd_bus_start should be added to the softc as a uint8_t type and needs to be set via attach. We need range checks to make sure vmd_write_config/vmd_read_config doesn't read something out of range since it has been reduced. Not sure what the shadow registers do. These both seem to be new Intel features and Intel doc's have been minimal. Looks like Intel is doing a sparse map now on newer devices. I'm concerned about the Linux comment of: * Certain VMD devices may have a root port configuration option which * limits the bus range to between 0-127, 128-255, or 224-255 since I don't see anything to limit it between 0-127 only starting at 0, 128 or 224, Maybe there is max of 128 busses overall? I don't have this type of HW to test things. Doug A.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20201231200744.GA95383>