Bug 228202

Summary: em/igb regression: after r333345 Intel I120 ethernet card is not initialized correctly
Product: Base System Reporter: Maciej Pasternacki <maciej>
Component: kernAssignee: Sean Bruno <sbruno>
Status: Closed FIXED    
Severity: Affects Some People CC: mmacy, mmacy, sbruno
Priority: --- Keywords: IntelNetworking, needs-qa, regression
Version: CURRENT   
Hardware: amd64   
OS: Any   
URL: https://reviews.freebsd.org/D15439
Attachments:
Description Flags
dmesg with e1000 DBG, without r333345 none

Description Maciej Pasternacki 2018-05-12 19:23:32 UTC
Created attachment 193339 [details]
dmesg with e1000 DBG, without r333345

After setting DBG to 1 in sys/dev/e1000/e1000_osdep.h, dmesg on r333486 shows following:

igb0: <Intel(R) PRO/1000 PCI-Express Network Driver> port 0x3000-0x301f mem 0xc1100000-0xc117ffff,0xc1180000-0xc1183fff irq 17 at device 0.0 on pci2
e1000_set_mac_type
igb0: attach_pre capping queues at 4
e1000_set_mac_type
e1000_init_mac_ops_generic
e1000_init_phy_ops_generic
e1000_init_nvm_ops_generic
e1000_init_function_pointers_82575
e1000_init_mac_params_82575
e1000_init_nvm_params_i210
e1000_init_nvm_params_82575
e1000_get_flash_presence_i210
e1000_init_phy_params_82575
e1000_reset_mdicnfg_82580
e1000_get_phy_id_82575
e1000_get_phy_id
e1000_read_phy_reg_gs40g
e1000_acquire_phy_82575
e1000_acquire_swfw_sync
e1000_get_hw_semaphore
Driver can't access device - SMBI bit is set.
PHY Initialization Error
igb0: Setup of Shared code failed, error -2
igb0: IFDI_ATTACH_PRE failed 6
device_attach: igb0 attach returned 6

The igb0 interface does not show up.

After locally reverting r333421 and r333345, the interface is initialized correctly. Debug dmesg with these revisions added as attachment as it is very long.

pciconf of the device:

igb0@pci0:2:0:0:	class=0x020000 card=0x35b48086 chip=0x15338086 rev=0x03 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = 'I210 Gigabit Network Connection'
    class      = network
    subclass   = ethernet

(without reverting r333345, the card shows in pciconf as "none2@pci0:2:0:0").

If I can provide any additional information about this issue, please let me know. My ability to debug this are limited, as this is a remote server and to access it without networking I need to apply for remote KVM, so experiments might take some time.

If I can add
Comment 1 Maciej Pasternacki 2018-05-12 19:28:48 UTC
Apologies for sending the original description too quickly. For clarity, as it cannot be edited: the final partial sentence ("If I can add") is leftover from editing the description and shouldn't be there; the attachment is dmesg on r333486 with r333421 and r333345 reverted, where the interface is working correctly.
Comment 2 Matthew Macy 2018-05-15 03:34:19 UTC
See
https://reviews.freebsd.org/D15439
Comment 3 Maciej Pasternacki 2018-05-15 11:25:20 UTC
https://reviews.freebsd.org/D15439 fixes the issue on my server.
Comment 4 Sean Bruno freebsd_committer freebsd_triage 2018-05-15 16:20:04 UTC
Committed at svn r333631

r333631 | sbruno | 2018-05-15 07:30:59 -0600 (Tue, 15 May 2018) | 11 lines

igb(4):
I210 restore functionality if pxeboot rom is enabled on this device.

r333345 attempted to determine if this code was needed or it was some kind
of work around for a problem.  Turns out, its definitely a work around for
hardware locking and synchronization that manifests itself if the option
Rom is enabled and is selected as a boot device (there was a PXE attempt).

Reviewed by:    mmacy
Differential Revision:  https://reviews.freebsd.org/D15439
Comment 5 Kubilay Kocak freebsd_committer freebsd_triage 2018-05-16 02:34:35 UTC
Assign to committer that resolved