From owner-freebsd-hackers@freebsd.org Sat Jan 2 17:20:28 2021 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 D74C94D7AD8 for ; Sat, 2 Jan 2021 17:20:28 +0000 (UTC) (envelope-from neel@neelc.org) Received: from rainpuddle.neelc.org (rainpuddle.neelc.org [IPv6:2001:19f0:8001:fed:5400:2ff:fe73:c622]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D7TDX1BL2z4gBk; Sat, 2 Jan 2021 17:20:28 +0000 (UTC) (envelope-from neel@neelc.org) Received: from mail.neelc.org (rainpuddle.neelc.org [IPv6:2001:19f0:8001:fed:5400:2ff:fe73:c622]) by rainpuddle.neelc.org (Postfix) with ESMTPSA id 5A550EB2A5; Sat, 2 Jan 2021 09:20:20 -0800 (PST) MIME-Version: 1.0 Date: Sat, 02 Jan 2021 09:20:20 -0800 From: Neel Chauhan To: Doug Ambrisko Cc: Mark Johnston , freebsd-hackers@freebsd.org, ambrisko@freebsd.org Subject: Re: Debugging a WIP PCI/ACPI patch: Bad tailq NEXT(0xffffffff81cde660->tqh_last) != NULL In-Reply-To: <4f3f6a02a452f766063ae2acb060dc64@neelc.org> References: <44528336fa9168966d121bf771e1e229@neelc.org> <3c9ff844e527daacd04c51f48836b57d@neelc.org> <20201231200744.GA95383@ambrisko.com> <4f3f6a02a452f766063ae2acb060dc64@neelc.org> User-Agent: Roundcube Webmail/1.4.9 Message-ID: <7cda3be6594d5ad5bdc69019f72b03d3@neelc.org> X-Sender: neel@neelc.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4D7TDX1BL2z4gBk X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=neelc.org; spf=pass (mx1.freebsd.org: domain of neel@neelc.org designates 2001:19f0:8001:fed:5400:2ff:fe73:c622 as permitted sender) smtp.mailfrom=neel@neelc.org X-Spamd-Result: default: False [-1.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[neel]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+a]; RBL_DBL_DONT_QUERY_IPS(0.00)[2001:19f0:8001:fed:5400:2ff:fe73:c622:from]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_SHORT(1.00)[1.000]; SPAMHAUS_ZRD(0.00)[2001:19f0:8001:fed:5400:2ff:fe73:c622:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; SUBJECT_HAS_EXCLAIM(0.00)[]; DMARC_POLICY_ALLOW(-0.50)[neelc.org,none]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; RCVD_COUNT_ONE(0.00)[1]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:20473, ipnet:2001:19f0:8000::/38, country:US]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers]; ONCE_RECEIVED(0.10)[] 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: Sat, 02 Jan 2021 17:20:28 -0000 Just to ping you in case you may have missed my reply (I understand, New Years Day). Is there a reason why "b = pci_get_bus(dev);" return 0 even when the bus number is shifted (as it is on Linux)? -Neel On 2020-12-31 21:49, Neel Chauhan wrote: > Hi Doug, > > Thank you so much for this information. > > On 2020-12-31 12:07, Doug Ambrisko wrote: >> 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. > > One thing I noticed is that the "b" variable (which corresponds to the > Linux bus->number) is 0 (thanks to printf). This should be the bus > number if we want to attach. > > If I use: "b = pci_get_bus(dev);" in the attach, b is still 0. > > And that leads to a kernel panic. > >> 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 guess Linux is our best hope. Unless the new Intel docs is the Linux > kernel source. > >> 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 could be wrong, but I guess that's a typo. > >> I don't have this type of HW to test things. > > I can use my hardware for testing. In the worse case scenario, I can > donate an entry-level 11th Gen/TigerLake system if I have the funds > and/or can get a tax credit. > >> Doug A. > > -Neel > _______________________________________________ > 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"