Intel H81 Chipset PCIe configuration question
A while back I posted about a motherboard network controller that disappeared when the firmware on a PCIe card was upgraded which converted the card from a 32-bit BAR to a 64-bit BAR. That seems to be a BIOS bug rather than a kernel issue. But, I would really like to be able to upgrade the systems in the field so I'm still chasing the BIOS issue and I'm puzzled by a programming issue when configuring the PCIe settings of the Intel 8-Series/C220 chipset. I'm hoping someone here can shine a bit of light on it. The device of interest is the Realtek Lan at 1c.5 which is "Port6" in Intel nomencature. http://www.intel.com/content/www/us/en/chipsets/8-series-chipset-pch-datasheet.html The BIOS has an ME-Disable option so I disabled the Intel Management Engine and then used flashrom to create an 8MB "oem.bin" image of the bios. At the beginning of oem.bin is an SPI Flash Descriptor Signature 0FF0A55Ah so I used the coreboot ifdtool program to dump the SPI Flash Descriptor information below. It appears to be both valid and sane. In particular, soft strap 9 (PCHSTRP9: 0x30540580) looks like it sets all the PCIe lanes to an x1 configuration. On the other hand "lspci -s 1c.5 xxx" shows the Link Capabilities Register (LCAP: 0x06323C12) which means Port5 with x2 lanes, Port6 disabled and Ports7/8 (which do not exist on the H81 SKU) as x1 lanes. This is the working configuration so something strange is going on. To the best of my understanding it is not possible to change the port width and override the soft strap settings in ROM by rewriting any chipset registers. Anybody have any ideas how the BIOS could be doing this? After the firmware is upgraded on the card the the motherboard network controller disappears from lspci output and the bridge reports an x0 width link status instead of the x1 width previously shown with the working configuration. Very odd. Steve Kenton LnkCap: Port #6, Speed 5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <1us, L1 <16us ClockPM- Surprise- LLActRep+ BwNot+ LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk- ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x0, TrErr- Train+ SlotClk+ DLActive- BWMgmt- ABWMgmt- $ lspci -tv -[:00]-+-00.0 Intel Corporation 4th Gen Core Processor DRAM Controller +-01.0-[01]00.0 Blackmagic Design Intensity Pro 4K +-02.0 Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller +-03.0 Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller +-14.0 Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI +-1a.0 Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #2 +-1b.0 Intel Corporation 8 Series/C220 Series Chipset High Definition Audio Controller +-1c.0-[02]-- +-1c.5-[03]00.0 Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller +-1d.0 Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #1 +-1f.0 Intel Corporation C220 Series Chipset Family H81 Express LPC Controller +-1f.2 Intel Corporation 8 Series/C220 Series Chipset Family 6-port SATA Controller 1 [AHCI mode] \-1f.3 Intel Corporation 8 Series/C220 Series Chipset Family SMBus Controller sudo lspci -s 1c.5 -xxx >lspcis1c5xxxgood.txt 00:1c.5 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #6 (rev d5) 00: 86 80 1a 8c 07 04 10 00 d5 00 04 06 10 00 81 00 10: 00 00 00 00 00 00 00 00 00 03 03 00 e0 e0 00 00 20: c0 f7 c0 f7 01 f0 01 f0 00 00 00 00 00 00 00 00 30: 00 00 00 00 40 00 00 00 00 00 00 00 03 02 10 00 40: 10 80 42 01 00 80 00 00 00 00 10 00 12 3c 32 06 ==> 06323C12: LCAP@4Ch–4Fh = 0110 00 1 1 0 0 100 011 11 01 0010 Port6 from 1 x2 and 2 x1s: Port 5 (x2), Port 7 (x1) and Port 8 (x1) 50: 40 00 11 70 00 b2 2c 00 00 00 40 00 08 00 00 00 ==> 7011: LSTS@52h–53h = 01 1 1 0 0 01 0001 = x1 Negotiated Link Width NW 60: 00 00 00 00 17 08 00 00 00 04 00 00 00 00 00 00 70: 01 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 05 90 01 00 18 03 e0 fe 00 00 00 00 00 00 00 00 90: 0d a0 00 00 19 10 cf 7e 00 00 00 00 00 00 00 00 a0: 01 00 03 c8 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 01 42 18 00 00 08 80 11 0b 00 00 00 00 e0: 00 03 00 00 00 00 3c 88 11 00 00 00 00 00 00 00 f0: 50 00 00 00 40 00 00 0c b1 0f 06 08 b0 03 00 06 ==> 060003b0: PECR4@FCh–FFh = 00 000110 00 00 0 000 00 00 00 11101100 00 Root Port Configuration Strap RPC_STRAP ??? File oem.bin is 8388608 bytes FLMAP0:0x02040003 NR: 2 FRBA:0x40 NC: 1 FCBA:0x30 FLMAP1:0x15100206 ISL
Re: lspci not showing motherboard ethernet controller after PCIe card firmware update change from 32-bit to 64-bit BAR
On 09/26/2016 10:50 AM, Lennart Sorensen wrote: > 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. > I decided to experiment with /sys/bus/pci and the BIOS settings to try and understand things better. The BIOS has a settings to enable/disable the on-board LAN. When the Blackmagic card firmware is upgraded bus[03] and hence the on-board LAN disappears, but the apparently unused bus[02] is still visible and the BIOS setting is still enabled. When the BIOS LAN settings is disabled busses[02][03] and the on-board LAN disappear. In both cases, the "disappeared" resources are not restored by echo to /sys/.../rescan Why? What can the BIOS be doing to the chipset/busses[02][03] to make them invisible to /sys manipulation? There is apparently something I do not understand about the H81 chipset PCIe configuration. I have been reading the Intel Series 8 / Series C220 Chipset documentation but so far have come up empty. Anybody have cluebat for me? Steve Kenton = Here is the lspci tree output as configured by the BIOS with the on-board LAN enabled Using echo to various /sys files successfully removes and restores(rescan) the Blackmagic card, the Realtek LAN as well as busses[01][02][03] -[:00]-+-00.0 Intel Corporation 4th Gen Core Processor DRAM Controller [8086:0c00] +-01.0-[01]00.0 Blackmagic Design Intensity Pro 4K [bdbd:a139] +-02.0 Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller [8086:0412] +-03.0 Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller [8086:0c0c] +-14.0 Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI [8086:8c31] +-16.0 Intel Corporation 8 Series/C220 Series Chipset Family MEI Controller #1 [8086:8c3a] +-1a.0 Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #2 [8086:8c2d] +-1b.0 Intel Corporation 8 Series/C220 Series Chipset High Definition Audio Controller [8086:8c20] +-1c.0-[02]-- +-1c.5-[03]00.0 Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] +-1d.0 Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #1 [8086:8c26] +-1f.0 Intel Corporation C220 Series Chipset Family H81 Express LPC Controller [8086:8c5c] +-1f.2 Intel Corporation 8 Series/C220 Series Chipset Family 6-port SATA Controller 1 [AHCI mode] [8086:8c02] \-1f.3 Intel Corporation 8 Series/C220 Series Chipset Family SMBus Controller [8086:8c22] = Here is the lspci tree output as configured by the BIOS with the on-board LAN disabled Using echo to various /sys files I am unable to restore busses[02][03] so I cannot even attempt to restore the Realtek LAN -[:00]-+-00.0 Intel Corporation 4th Gen Core Processor DRAM Controller [8086:0c00] +-01.0-[01]00.0 Blackmagic Design Intensity Pro 4K [bdbd:a139] +-02.0 Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller [8086:0412] +-03.0 Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller [8086:0c0c] +-14.0 Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI [8086:8c31] +-16.0 Intel Corporation 8 Series/C220 Series Chipset Family MEI Controller #1 [8086:8c3a] +-1a.0 Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #2 [8086:8c2d] +-1b.0 Intel Corporation 8 Series/C220 Series Chipset High Definition Audio Controller [8086:8c20] +-1d.0 Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #1 [8086:8c26] +-1f.0 Intel Corporation C220 Series Chipset Family H81 Express LPC Controller [8086:8c5c] +-1f.2 Intel Corporation 8 Series/C220 Series Chipset Family 6-port SATA Co
/sys inconsistent newline requirement on write
Feature or bug?
Using shell echo to write to /sys files normally adds an implicit
newline but
write() in a C program must add it explicitly. Some but not all /sys files
require a newline or the write fails. 'Extra' new lines from echo are
silently ignored and do not cause errors.
For example:
writing "1" to /sys/block/sd*/device/delete does not require a trailing
newline
writing "offline" to /sys/block/sd*/device/state does require a
trailing newline
$ make test
$ sudo ./test
write failed without newline: Invalid argument
===
// Test program to illustrate required newline for writes to
/sys/block/sd*/device/state
#include
#include
int main(int argc, char **argv)
{
int sysfd;
if ((sysfd = open("/sys/block/sdb/device/state", O_WRONLY)) < 0)
perror("open failed");
else
{
if (write(sysfd, "offline", 7) < 0)
perror("write failed without newline");
if (write(sysfd, "offline\n", 8) < 0)
perror("write failed with newline");
if (close(sysfd))
perror("close failed");
}
return 0;
}
Re: fs/udf and udftools
On 02/11/2016 04:03 AM, Jan Kara wrote: > On Wed 10-02-16 21:45:05, Steve Kenton wrote: >> On 02/10/2016 08:19 PM, Ken Moffat wrote: >>> On Wed, Feb 10, 2016 at 05:56:16PM -0800, Randy Dunlap wrote: >>>> [add Jan Kara] >>>> >>>> On 02/10/16 13:29, Steve Kenton wrote: >>>>> Is anyone maintaining these or am I about to volunteer for another job? >> >> I guess I should have said "developing" rather than "maintaining" for >> fs/udf since it's clear that someone has been keeping it running in-tree. >> I started with udftools from source forge and then discovered that the >> kernel udf driver does not support fallocate() which I was hoping to use. >> >> Thanks for the pointer to Jan Kara. I'll see how he feels about patches >> from the wilderness. > > So I don't have too much time for UDF. That's why I mostly fix bugs someone > reports, occasionally improve stuff or review patches others send but I > don't have time for development of new features for UDF. OK, I'll see what I can do and try not to bother you until stuff is working well. > >>>> CUrrent MAINTAINERS file says: >>>> >>>> UDF FILESYSTEM >>>> M: Jan Kara >>>> S: Maintained >>>> F: Documentation/filesystems/udf.txt >>>> F: fs/udf/ >>>> >>>> and that Doc. file says: >>>> >>>> For the latest version and toolset see: >>>>http://linux-udf.sourceforge.net/ >> >> Yes, that's where I started. The last release was 1.0.0b3 in 2004. >> Which is what the Ubuntu 14.04LTS package reports as it's version too. > > Pali Rohar has recently startted a repo on github for udftools. It is at > https://github.com/pali/udftools > > So userspace patches go to him. Perfect! All of my googling pointed to source forge but this is what I was hoping for. smk > > Honza >
Re: fs/udf and udftools
On 02/10/2016 08:19 PM, Ken Moffat wrote: > On Wed, Feb 10, 2016 at 05:56:16PM -0800, Randy Dunlap wrote: >> [add Jan Kara] >> >> On 02/10/16 13:29, Steve Kenton wrote: >>> Is anyone maintaining these or am I about to volunteer for another job? I guess I should have said "developing" rather than "maintaining" for fs/udf since it's clear that someone has been keeping it running in-tree. I started with udftools from source forge and then discovered that the kernel udf driver does not support fallocate() which I was hoping to use. Thanks for the pointer to Jan Kara. I'll see how he feels about patches from the wilderness. >> >> CUrrent MAINTAINERS file says: >> >> UDF FILESYSTEM >> M: Jan Kara >> S: Maintained >> F: Documentation/filesystems/udf.txt >> F: fs/udf/ >> >> and that Doc. file says: >> >> For the latest version and toolset see: >> http://linux-udf.sourceforge.net/ Yes, that's where I started. The last release was 1.0.0b3 in 2004. Which is what the Ubuntu 14.04LTS package reports as it's version too. >> > A bit of googling for udftools suggests that gentoo are maintaining > their build, debian have patches for gcc-4 and gcc-5 among others, > Fedora have their own patches, and Arch have some patches (which > might be the same as some of hte others, I did not look). > > Looks like the normal "possibly abandonned, but still useful to some > people" software, where distros keep it building. Yep, that's where my ~works came from. Ah, thanks for the links. I'll pull them all together and see what's there. smk > > There may also be others. > > Links - > > https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-fs/udftools/ChangeLog?view=markup > > https://launchpad.net/debian/+source/udftools/+changelog > > http://pkgs.fedoraproject.org/cgit/rpms/udftools.git/tree/ > > https://aur.archlinux.org/packages/udftools/ > >> >>> I'm having to dig into fs/udf and udftools/mkudffs as part of a project I'm >>> working on. >>> It looks like both have been lacking in personal TLC for quite a while. The >>> changes to >>> fs/udf seem to be tree wide VFS work but not updates to things like write >>> support and >>> udftools seems to have been frozen for >10 years. Both ~work but I'd like >>> to fix an >>> oops I'm getting in udftools and work on adding fallocate() support to >>> fs/udf and then >>> feed it back to the community rather than let the changes bit rot locally. >>> >>> Where to go from here? I've been reading LKML on marc: for years, mainly to >>> see what Linus, >>> Al and a variable group of other people say/do but I've never done more >>> than tinker with >>> the kernel locally. I'm using git for the project mentioned above but again >>> am not an >>> expert but willing to learn. I'm not currently subscribed so please cc me >>> if you could. >>> >>> smk >>> >> >> >> -- >> ~Randy >
fs/udf and udftools
Is anyone maintaining these or am I about to volunteer for another job? I'm having to dig into fs/udf and udftools/mkudffs as part of a project I'm working on. It looks like both have been lacking in personal TLC for quite a while. The changes to fs/udf seem to be tree wide VFS work but not updates to things like write support and udftools seems to have been frozen for >10 years. Both ~work but I'd like to fix an oops I'm getting in udftools and work on adding fallocate() support to fs/udf and then feed it back to the community rather than let the changes bit rot locally. Where to go from here? I've been reading LKML on marc: for years, mainly to see what Linus, Al and a variable group of other people say/do but I've never done more than tinker with the kernel locally. I'm using git for the project mentioned above but again am not an expert but willing to learn. I'm not currently subscribed so please cc me if you could. smk
