linux-kernel - Re: [BUG] Bisected Problem with LSI PCI FC Adapter

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] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 11 Sep 2014 14:42:47 -0600
From:	Bjorn Helgaas <bhelgaas@...gle.com>
To:	Dirk Gouders <dirk@...ders.net>
Cc:	Yinghai Lu <yinghai@...nel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andreas Noever <andreas.noever@...il.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>
Subject: Re: [BUG] Bisected Problem with LSI PCI FC Adapter

On Thu, Sep 11, 2014 at 2:33 PM, Dirk Gouders <dirk@...ders.net> wrote:
> What I was currently trying was to construct a test-environment so that
> I do not need to do tests and diagnosis on a busy machine.
>
> I noticed that this problem seems to start with the narrow Root
> Bridge window (00-07) but every other machine that I had a look at,
> starts with (00-ff), so those will not trigger my problem.
>
> I thought I could perhaps try to shrink the window in
> acpi_pci_root_add() to trigger the problem and that kind of works: it
> triggers it but not exactly the same way, because it basically ends at
> this code in pci_scan_bridge():
>
>         if (max >= bus->busn_res.end) {
>                 dev_warn(&dev->dev, "can't allocate child bus %02x from %pR (pass %d)\n",
>                          max, &bus->busn_res, pass);
>                 goto out;
>         }
>
> If this could work but I am just missing a small detail, I would be
> glad to hear about it and do the first tests this way.  If it is
> complete nonsense, I will just use the machine that triggers the problem
> for the tests.

I was about to suggest the same thing.  If the problem is related to
the bus number change, we should be able to force that to happen on a
different machine.  Your approach sounds good, so I'm guessing we just
need a tweak.

I would first double-check that the PCI adapters are identical,
including the firmware on the card.  Can you also include your patch
and the resulting dmesg (with debug enabled as before)?

Is the test machine itself similar to the failing one?  Do they have
the same BIOS version?  From [1], it looks like you already have the
latest BIOS on the failing machine.  It's interesting that the notes
for your version mention "Fixed a PCI Bus Number re-allocation error."

Bjorn

[1] http://www.tyan.com/support_download_bios.aspx?model=B.VX50B4985-E
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/