lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <c4a4d74d-9914-19eb-6097-4ef8e0ed09c6@dommel.be> Date: Thu, 26 Apr 2018 04:57:57 +0000 From: Janpieter Sollie <janpieter.sollie@...mel.be> To: Bjorn Helgaas <bhelgaas@...gle.com> Cc: linux-pci@...r.kernel.org, Linux Kernel Mailing List <linux-kernel@...r.kernel.org> Subject: Re: [Bug 199473] New: pcieport does not scan devices behind PEX switch, while resources are allocated lspci -vv loaded in bugzilla. I referred to a pci port nr as the nr in an expansion slot On 25-04-18 19:05, Bjorn Helgaas wrote: > [Please retain the mailing list cc when replying] > > On Wed, Apr 25, 2018 at 3:28 AM Janpieter Sollie > <janpieter.sollie@...mel.be> > wrote: > >> Hi Bjorn, >> I'm at work now, but I saw your mail contained much more info than only > the remark "does it work at 4.17?", so I'll try to answer all your > questions: >> 1. as stated, it only assigns the address space of the second and 3rd > device when the PCI device is hotplugged and then the pc is restarted on a > port before the first device. In this case: >> - The Ellesmere 01.0-[4f] device is connected to port 3 (0-7) and > is always reported. For other devices, this is not the case. >> - The other devices are at port 1 and 2. When adding them on a > higher port, the workaround does not work. >> - The devices 05.0-[4c] and 07.0-[4b] are ALSO NOT VISIBLE in the > BIOS IRQ listing, it just talks about an endpoint. Not even with the > workaround. So a trick to discard bios info and let the PCIe switch report > its devices would be nice. > > BIOS info is not used when we enumerate devices, so I don't think there's > really anything to discard. > >> 2. I am always building my kernel from the kernel.org sources, not from > Gentoo sources, so it's not a distro problem. >> 3. The workaround only works with kernel 4.17 >> 4. You are probably right about the Broadcom driver, as it only picks up > the endpoint at 42.00.1 when loaded. I have no idea wat it does either, > besides taining the kernel. > > Let's simplify the situation by focusing only on v4.17. We can > also ignore the Broadcom driver, since it's not involved in enumeration. > >> So, to summarize: >> - Why are ports 4-7 not working when a device is plugged in at port 3? > I don't know what "port 3" and "ports 4-7" refer to. Are these labels on > slots in an expansion chassis? Something from lspci, e.g., the port number > from Link Capabilites, or the slot number from Slot Capabilities? > >> - Why do I need a hotplug event to push the device name into the kernel > after a cold start? This is complete madness, isn't it? > > I don't know why the hotplug would make a difference. It does sound like > complete madness. > >> - Why are resources allocated while the PCI slot is empty? > I don't know exactly what resources you're referring to (bus numbers, MMIO > space, I/O port space). In general we try to allocate some space for all > of those even if the slot is currently empty, because that makes it > possible to hot-add devices in the slot later. > > In this case, the bus number space is quite constrained because the host > bridge leading to the PEX switch only supports [bus 40-4f]. But I think > that should be enough for this case, since the only switch in this tree is > the PEX, and your Bonaire/Tobago/Ellesmere devices are all endpoints that > only require one bus number each. > > If you run "lspci -vv" as root, it'll decode more details. > >> -----Original Message----- >> From: Bjorn Helgaas [mailto:bhelgaas@...gle.com] >> Sent: dinsdag 24 april 2018 21:31 >> To: janpieter.sollie@...mel.be >> Cc: linux-pci@...r.kernel.org; Linux Kernel Mailing List >> Subject: Fwd: [Bug 199473] New: pcieport does not scan devices behind PEX > switch, while resources are allocated > >> Thanks for the report! >> I don't understand exactly what the issue is yet. You attached lspci >> output from v4.14.27 and v4.17-rc1. The v4.17-rc1 output shows several >> devices (4b:00, 4c:00, 4f:00) below the PEX switch, while the v4.14.27 >> output shows only the 4f:00 devices. >> Is the problem that v4.14.27 doesn't find the 4b:00 and 4c:00 devices? >> Does v4.17-rc1 work correctly? >> If v4.17-rc1 works but v4.14.27 does not, it's probably a question of >> working with your distro to see if they can (1) identify some change that >> fixed things, and (2) backport that change to the distro kernel. >> The Broadcom driver you attached at comment #4 shouldn't be related to > this >> problem. Device enumeration is performed by the PCI core and doesn't >> require any additional drivers. I didn't look at the Broadcom driver, so > I >> don't know what it does. The PEX switch does include an endpoint >> (42:00.1); it's possible the driver is for some functionality provided by >> that endpoint. >> ---------- Forwarded message --------- >> From: <bugzilla-daemon@...zilla.kernel.org> >> Date: Mon, Apr 23, 2018 at 12:20 AM >> Subject: [Bug 199473] New: pcieport does not scan devices behind PEX >> switch, while resources are allocated >> To: <bhelgaas@...gle.com> > >> https://bugzilla.kernel.org/show_bug.cgi?id=199473 >> Bug ID: 199473 >> Summary: pcieport does not scan devices behind PEX switch, >> while resources are allocated >> Product: Drivers >> Version: 2.5 >> Kernel Version: 4.17-rc1 >> Hardware: x86-64 >> OS: Linux >> Tree: Mainline >> Status: NEW >> Severity: normal >> Priority: P1 >> Component: PCI >> Assignee: drivers_pci@...nel-bugs.osdl.org >> Reporter: janpieter.sollie@...mel.be >> Regression: No >> Created attachment 275511 >> --> https://bugzilla.kernel.org/attachment.cgi?id=275511&action=edit >> dmesg stable kernel >> pcieport assigns the PEX 8619 pcie expander switch ports, but does not > scan >> them for additional objects behind the ports. only 1 device is added @ pci >> region 4f. Workaround for getting all devices online: while pc is on, >> remove >> the card, reinsert it at a slot before the working device, and make a cold >> start. >> It would be nice if the pcie switches are scanned properly. >> -- >> You are receiving this mail because: >> You are watching the assignee of the bug.
Powered by blists - more mailing lists