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
My complete dmesg log http://pastebin.com/tW9Qe3g2
reclassify.
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.
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
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.
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
It is a workaround. The real issue is a PCI bus issue that I hope to ultimately resolve via other means.
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
(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.
^Triage: Correct resolution, not technically resolved (worked around: comment 6)