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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <633ec24b-4212-581f-05f0-7a86eaf09fee@dommel.be>
Date:   Wed, 25 Apr 2018 04:13:17 +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: Fwd: [Bug 199473] New: pcieport does not scan devices behind PEX
 switch, while resources are allocated

dear Bjorn,

I understand the confusion.  I quite messed up the bug report. Sorry.
The problem is that lspci with kernel 4.17-rc1 shows exactly the same behaviour when no 
workaround is applied.
the lspci is from 4.17-rc1 with the workaround applied, but by default, it shows the same output 
as 4.14.27

kind regards,

Janpieter Sollie

On 24-04-18 19:31, Bjorn Helgaas wrote:
> 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

Powered by Openwall GNU/*/Linux Powered by OpenVZ