From: lsorense@csclub.uwaterloo.ca (Lennart Sorensen)
To: Steve Kenton <skenton@ou.edu>
Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
Bjorn Helgaas <bhelgaas@google.com>,
yinghai Lu <yinghai@kernel.org>,
Blackmagic Developer Support <developer@blackmagicdesign.com>
Subject: Re: lspci not showing motherboard ethernet controller after PCIe card firmware update change from 32-bit to 64-bit BAR
Date: Mon, 26 Sep 2016 11:50:18 -0400 [thread overview]
Message-ID: <20160926155018.GL14311@csclub.uwaterloo.ca> (raw)
In-Reply-To: <efdbf332-841c-7617-efd1-facf785472fd@ou.edu>
On Sat, Sep 24, 2016 at 07:24:14PM -0500, Steve Kenton wrote:
> I have two different systems with Blackmagic Design Intensity Pro-4K
> cards. One uses an ECS H81H3-I motherboard and the other uses a Gigabyte
> GA-H110N motherboard. Previously both were working properly. When I
> upgraded the Blackmagic Design desktopvideo package from version 10.7 to
> version 10.8 it included an update of the firmware on the cards from
> version 0x85 to 0xbd. After the upgrade the Gigabyte-motherboard system
> continues to work properly, but the ECS-motherboard system no longer
> shows the motherboard ethernet controller with lspci. Downgrading the
> firmware makes the ethernet controller reappear with lspci. Upgrading
> again makes it disappear again. Attached are the output of lscpi -vv
> for each version of the firmware on the ECS-motherboard system.
> Upgrading to the most recent ECS-motherboard bios did not have any effect.
>
> There are a number of differences in the two lspci outputs but
> based on conversations I've seen on LKM, which I peruse but am not
> subscribed to, I suspect that this is the important one:
>
> lspci-Intensity-Pro-4K-10.7-firmware.txt: Region 0: Memory at
> f7d00000 (32-bit, non-prefetchable) [size=1M]
> lspci-Intensity-Pro-4K-10.8-firmware.txt: Region 0: Memory at
> f7c00000 (64-bit, non-prefetchable) [size=1M]
>
> The Engineers at Blackmagic Design have confirmed that the change to a
> 64-bit BAR with firmware version 0xbd was intentional and correct. And
> to be clear, the Blackmagic cards continue to work properly. The issue
> is the motherboard ethernet controller disappearing after upgrading the
> Blackmagic cards to new firmware with a 64-bit BAR. Note, however, that
> 64-bit BAR is below 4GB with the high four bytes being all zeros. After
> the firmware update it's like there is "no room at the inn" for the
> motherboard ethernet controller so it never gets enabled. I think we can
> all agree that it's a likely a problem with the PC motherboard bios. I'm
> hoping to find a workaround to allow me to configure a number of
> existing ECS-motherboard systems in the field for use with the new firmware.
>
> I normally run Ubuntu 14.04 LTS and tried the most recent 4.4.0-38
> kernel but then I noticed that the Ubuntu 16.10 daily build ISO switched
> to kernel 4.8-RC-something on Sept 21st. So I booted that
> livedvd and tried it to see if 4.8-RC included some recent PCIe
> 32-bit/64-bit resource fix but sadly the results were the same. With
> firmware 0xbd, the ethernet controller was still missing from the lspci
> output. I poked around with various of the kernel pci= parameters such
> as bios and nobios to no avail, but I really am out of my depth here.
>
> I'm available to run tests if anyone has any suggestions.
Well pci=bios is 32 bit only, so that doesn't work, pci=bfs was probably
supposed to be pci=bfsort. It sure looks like the bios fails to allocate
the network device when the other device is 64 bit. Sure looks like
a bios bug. I see nothing indicating that the address space ran out.
It looks fine.
You could try:
pci=realloc
pci=assign-busses
pci=bfsort (the one I think you were trying to do).
I certainly wouldn't be surprised if the only thing ever tested in that
board was a graphics card.
Of course your network card is also 64 bit bar (when seen), so the system
can work with such. Makes one wonder if the bios has a bus, or the H81
has a limit that only one of the ethernet and the add in card can use
64 bit bar at a time. That would seem weird of course.
--
Len Sorensen
next prev parent reply other threads:[~2016-09-26 15:50 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <2cc60cd1-bab1-a086-2326-7ce161b8f083@ou.edu>
2016-09-25 0:24 ` lspci not showing motherboard ethernet controller after PCIe card firmware update change from 32-bit to 64-bit BAR Steve Kenton
2016-09-26 15:50 ` Lennart Sorensen [this message]
2016-09-28 14:05 ` Steve Kenton
2016-09-29 14:24 ` Lennart Sorensen
2016-10-19 2:50 ` Intel H81 Chipset PCIe configuration question Steve Kenton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160926155018.GL14311@csclub.uwaterloo.ca \
--to=lsorense@csclub.uwaterloo.ca \
--cc=bhelgaas@google.com \
--cc=developer@blackmagicdesign.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=skenton@ou.edu \
--cc=yinghai@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).