From owner-freebsd-hackers@freebsd.org Thu Dec 31 20:07:52 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 12E7C4CDDE2 for ; Thu, 31 Dec 2020 20:07:52 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail2.ambrisko.com (mail2.ambrisko.com [70.91.206.91]) by mx1.freebsd.org (Postfix) with ESMTP id 4D6K2b4xg6z3mm9; Thu, 31 Dec 2020 20:07:51 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) IronPort-SDR: VbWFv33tOCMXIWQFctqZ5bO0Zez0KLeUdBXJTl+wbr5DxzI5IEi9gjIDKBwbQ5Qd14tzxS+wF8 zFafhIERhS6PpSx3wWMJ4eMFc5vckTHuw= X-Ambrisko-Me: Yes Received: from server2.ambrisko.com (HELO internal.ambrisko.com) ([192.168.1.2]) by ironport2.ambrisko.com with ESMTP; 31 Dec 2020 11:31:06 -0800 Received: from ambrisko.com (localhost [127.0.0.1]) by internal.ambrisko.com (8.15.2/8.15.2) with ESMTPS id 0BVK7iXU098379 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 31 Dec 2020 12:07:44 -0800 (PST) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.15.2/8.15.2/Submit) id 0BVK7iPU098378; Thu, 31 Dec 2020 12:07:44 -0800 (PST) (envelope-from ambrisko) Date: Thu, 31 Dec 2020 12:07:44 -0800 From: Doug Ambrisko To: Mark Johnston Cc: Neel Chauhan , 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> References: <44528336fa9168966d121bf771e1e229@neelc.org> <3c9ff844e527daacd04c51f48836b57d@neelc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4D6K2b4xg6z3mm9 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 20:07:52 -0000 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.