Bug 196501 - [em] Intel 82573 nic built on my pdsbm-ln2 1U server and only one port will work.
Summary: [em] Intel 82573 nic built on my pdsbm-ln2 1U server and only one port will w...
Status: Closed Overcome By Events
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 10.1-RELEASE
Hardware: amd64 Any
: --- Affects Many People
Assignee: freebsd-net mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-01-05 06:01 UTC by Mark
Modified: 2020-01-28 04:35 UTC (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mark 2015-01-05 06:01:03 UTC
Using Intel 82573 nic built on my pdsbm-ln2 1U server and only one port will work. 

em0: <Intel(R) PRO/1000 Network Connection 7.4.2> port 0x4000-0x401f irq 16 at device 0.0 on pci2
pcib0: allocated type 3 (0xd0200000-0xd02fffff) for rid 20 of pcib2
pcib2: allocated initial memory window of 0xd0200000-0xd02fffff
pcib2: allocated memory range (0xd0200000-0xd021ffff) for rid 10 of em0
em0: Lazy allocation of 0x20000 bytes rid 0x10 type 3 at 0xd0200000
em0: attempting to allocate 1 MSI vectors (1 supported)
msi: routing MSI IRQ 256 to local APIC 0 vector 51
em0: using IRQ 256 for MSI
em0: Using an MSI interrupt
em0: Setup of Shared code failed
device_attach: em0 attach returned 6

And when this happens I can not use my Intel Dual NIC pci card in the system it will freeze the boot. Even a Linksys wifi PCI card in the system will freeze.  

If I disable the two onboard 82573 dual nic ports I then can use the PCI slot for wifi or dual older legacy dual lan PCI card and both ports works it is Intel 82546 dual nic card.

Problem was not present in 8.1 only started in 10.1 release of Freebsd 10.1 64 bit
Comment 1 Mark 2015-01-05 07:29:02 UTC
My complete dmesg log

http://pastebin.com/tW9Qe3g2
Comment 2 Mark Linimon freebsd_committer freebsd_triage 2015-01-06 01:39:13 UTC
reclassify.
Comment 3 Eric Joyner 2015-01-07 01:02:04 UTC
I installed 10.1-RELEASE amd64 on an old system we have with two 82573 ports, and they both attached fine. Here's the relevant pciconf output:

em0@pci0:13:0:0:        class=0x020000 card=0x108c15d9 chip=0x108c8086 rev=0x03 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = '82573E Gigabit Ethernet Controller (Copper)'
    class      = network
    subclass   = ethernet
em1@pci0:14:0:0:        class=0x020000 card=0x109a15d9 chip=0x109a8086 rev=0x00 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = '82573L Gigabit Ethernet Controller'
    class      = network
    subclass   = ethernet

I don't know what to say about your problem. The shared code setup failure indicates that attach fails very early in the driver load, so it seems like a hardware problem of some sort. Especially since both devices in your case seem to be the same, but only one fails to attach.
Comment 4 ken73.chen 2015-01-07 07:51:09 UTC
There is no problem on FreeBSD 8.4, but same problem on 10.1 i386 platform.

Dec 25 22:36:25 db2 kernel: FreeBSD 10.1-RELEASE #0 r274401: Tue Nov 11 22:51:51 UTC 2014

Dec 25 22:36:25 db2 kernel: em0: 0x20 bytes of rid 0x20 res 4 failed (0, 0xffffffff).
Dec 25 22:36:25 db2 kernel: em0: Unable to allocate bus resource: ioport
Dec 25 22:36:25 db2 kernel: em0: Allocation of PCI resources failed
Dec 25 22:36:25 db2 kernel: device_attach: em0 attach returned 6
Dec 25 22:36:25 db2 kernel: em0: <Intel(R) PRO/1000 Legacy Network Connection 1.0.5> mem 0xfe6e0000-0xfe6fffff,0xfe6c0000-0xfe6dffff irq 49 at device 3.0 on pci5
Dec 25 22:36:25 db2 kernel: em0: 0x20 bytes of rid 0x20 res 4 failed (0, 0xffffffff).
Dec 25 22:36:25 db2 kernel: em0: Unable to allocate bus resource: ioport
Dec 25 22:36:25 db2 kernel: em0: Allocation of PCI resources failed

==================================

pciconf -lv


none3@pci0:5:2:0:   class=0x020000 card=0x30001458 chip=0x100d8086 rev=0x02 hdr=0x00
  vendor  = 'Intel Corporation'
  device  = '82544GC Gigabit Ethernet Controller (LOM)'
  class  = network
  subclass  = ethernet
none4@pci0:5:3:0:   class=0x020000 card=0x30001458 chip=0x100d8086 rev=0x02 hdr=0x00
  vendor  = 'Intel Corporation'
  device  = '82544GC Gigabit Ethernet Controller (LOM)'
  class  = network
  subclass  = ethernet
Comment 5 John Baldwin freebsd_committer freebsd_triage 2015-01-13 21:23:04 UTC
Try setting 'hint.agp.0.disabled=1' in loader.conf.  agp0 allocates a page of address space that causes a trickle down effect where em0 and em1 have to allocate different BARs.

That said, em0/1 should be able to cope with the alternate BARs, though it may be that em0 doesn't work because em1's bridge is still decoding those addresses when em0 tries to probe.  I bet that if we forced em0 to reattach it would actually work ok (e.g using my devctl thing that isn't in the tree yet).

Ultimately this is a PCI bus bug, not an em(4) issue.
Comment 6 Mark 2015-01-14 09:08:09 UTC
hint.agp.0.disabled=1 in my loader.conf has resolved the problem.  It is funny how only in freebsd you have to do this but every other system is fine with both nic's
Comment 7 John Baldwin freebsd_committer freebsd_triage 2015-01-14 13:51:59 UTC
It is a workaround.  The real issue is a PCI bus issue that I hope to ultimately resolve via other means.
Comment 8 Ian Jefferson 2015-08-03 14:39:59 UTC
For what it is worth.

I had a similar problem that was resolved by this hint my configuration:

NAS4Free  	10.1.0.2
Intel D525MW motherboard
Promise SATA300 TX4

The system would fail to boot and hang after:

pcib5: <ACPI PCI-PCI bridge> at device 30.0 on pic0
pcib5: failed to allocate initial memory window: 0xe0100000-0xe01fffff
atapic0: <Promise PDC40718 SATA300 controller> port 0x1000-0x10ff irq 20 at device 0.0 on pci5


See also:  https://bugs.pcbsd.org/issues/3244

At boot setting the variable:

hint.agp.0.disabled=1

resolved the issue.

Oddly this problem was somewhat random.  Sometimes I could boot although 9/10 times the system would hang.

Ian
Comment 9 Ian Jefferson 2019-11-21 12:38:21 UTC
(In reply to Ian Jefferson from comment #8)
This still seems to be an issue in 11.3.  Same hardware configuration but finally getting around to upgrading Xigmanas to something moderately current.
Comment 10 Kubilay Kocak freebsd_committer freebsd_triage 2020-01-28 04:35:50 UTC
^Triage: Correct resolution, not technically resolved (worked around: comment 6)