Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 23 Aug 2018 00:33:30 -0700
From:      Kevin Bowling <kevin.bowling@kev009.com>
To:        Roman Bogorodskiy <bogorodskiy@gmail.com>
Cc:        net@freebsd.org
Subject:   Re: igb: device_attach: igb1 attach returned 6
Message-ID:  <CAK7dMtDO_UzhHKBDtNAQ=XKWEFTdDU3K2FVsEmcMo8cbro0S7A@mail.gmail.com>
In-Reply-To: <CAK7dMtCEXdB_qSTc7rV_G7RTyDJ=xa6DE4PRJuOdfEG-iJj3_g@mail.gmail.com>
References:  <20180819142106.GA1539@kloomba> <CAK7dMtCbvFQpZYXgjkZ4gPLhHVhM19YDR8oDo8vEFQT8tCp4-Q@mail.gmail.com> <20180822090811.GA1691@kloomba> <CAK7dMtDsm2%2BwL1R5FLFAZF=5LCJBg8AMuU%2BUWeUWVAD-X7_ctQ@mail.gmail.com> <20180823071626.GA4446@kloomba> <CAK7dMtCEXdB_qSTc7rV_G7RTyDJ=xa6DE4PRJuOdfEG-iJj3_g@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Well I took a look at the phy code and actually don't see that we
abosrbed those commits.  I'll try and audit e1000 vs linux in the next
24 hours but in the mean time if you could confirm linux-next or the
like fix or don't fix the phy we can at least know if this is the
right path or if we need to ask Intel networking for help.

Regards,

On Thu, Aug 23, 2018 at 12:19 AM, Kevin Bowling
<kevin.bowling@kev009.com> wrote:
> Great thanks for the info about it not working on Ubuntu too, that
> narrows down the problem space considerably.
>
> Can you try that patch on FreeBSD -CURRENT?  It should apply with
> minimal changes the phy code is shared by multiple OSes.  If it works
> we can commit.
>
> Regards,
>
> On Thu, Aug 23, 2018 at 12:16 AM, Roman Bogorodskiy
> <bogorodskiy@gmail.com> wrote:
>> I haven't used this hardware before, so I don't if it ever worked. I
>> only tried 11.2 and it doesn't work. I've also tried Ubuntu 18.04 and it
>> doesn't work as well. Ubuntu prints the following error:
>>
>> [  343.053031] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.4.0-k
>> [  343.053032] igb: Copyright (c) 2007-2014 Intel Corporation.
>> [  343.415346] igb 0000:01:00.0: added PHC on eth0
>> [  343.415349] igb 0000:01:00.0: Intel(R) Gigabit Ethernet Network Connection
>> [  343.415352] igb 0000:01:00.0: eth0: (PCIe:5.0Gb/s:Width x4) 00:12:c0:00:e9:14
>> [  343.415427] igb 0000:01:00.0: eth0: PBA No: 106100-000
>> [  343.415430] igb 0000:01:00.0: Using MSI-X interrupts. 4 rx queue(s), 4 tx queue(s)
>> [  343.416422] igb 0000:01:00.0 enp1s0f0: renamed from eth0
>> [  343.416827] igb: probe of 0000:01:00.1 failed with error -3
>> [  343.485242] IPv6: ADDRCONF(NETDEV_UP): enp1s0f0: link is not ready
>> [  343.777894] igb 0000:01:00.2: added PHC on eth0
>> [  343.777897] igb 0000:01:00.2: Intel(R) Gigabit Ethernet Network Connection
>> [  343.777900] igb 0000:01:00.2: eth0: (PCIe:5.0Gb/s:Width x4) 00:12:c0:00:e9:16
>> [  343.777974] igb 0000:01:00.2: eth0: PBA No: 106100-000
>> [  343.777977] igb 0000:01:00.2: Using MSI-X interrupts. 4 rx queue(s), 4 tx queue(s)
>> [  343.781905] igb 0000:01:00.2 enp1s0f2: renamed from eth0
>> [  343.849424] IPv6: ADDRCONF(NETDEV_UP): enp1s0f2: link is not ready
>> [  344.139715] igb 0000:01:00.3: added PHC on eth0
>> [  344.139718] igb 0000:01:00.3: Intel(R) Gigabit Ethernet Network Connection
>> [  344.139722] igb 0000:01:00.3: eth0: (PCIe:5.0Gb/s:Width x4) 00:12:c0:00:e9:17
>> [  344.139797] igb 0000:01:00.3: eth0: PBA No: 106100-000
>> [  344.139800] igb 0000:01:00.3: Using MSI-X interrupts. 4 rx queue(s), 4 tx queue(s)
>> [  344.141054] igb 0000:01:00.3 enp1s0f3: renamed from eth0
>> [  344.213393] IPv6: ADDRCONF(NETDEV_UP): enp1s0f3: link is not ready
>>
>> I googled for this error message and found the following patch:
>>
>> https://www.spinics.net/lists/netdev/msg515557.html
>>
>> I'm not sure if it addresses my problem, but it looks related. I haven't
>> tried that yet though because I don't have a spare drive to install
>> Linux and rebuild drivers there.
>>
>>   Kevin Bowling wrote:
>>
>>> The phy code hasn't changed in any material way that I can see in a
>>> long time.  So I wonder if it's timing or some initialization issue.
>>>
>>> e1000_get_hw_semaphore
>>> e1000_put_hw_semaphore
>>> e1000_read_phy_reg_i2c
>>>
>>> This looks a bit funny, I think the hw sem should be held over the i2c
>>> call.  Is there a chance you can get the same log from the working
>>> kernel?
>>>
>>> Regards,
>>> Kevin
>>>
>>> On Wed, Aug 22, 2018 at 2:08 AM, Roman Bogorodskiy
>>> <bogorodskiy@gmail.com> wrote:
>>> >   Kevin Bowling wrote:
>>> >
>>> >> Roman,
>>> >>
>>> >> Interesting.. can you set DBG to 1 sys/dev/e1000/e1000_osdep.h Line
>>> >> 109 so we can see closer what is failing to initialize?
>>> >
>>> > Hi Kevin,
>>> >
>>> > Here's a relevant bit of dmesg with debug enabled:
>>> >
>>> > igb1: <Intel(R) PRO/1000 PCI-Express Network Driver> port 0xe040-0xe05f mem 0xf7800000-0xf79fffff,0xf7c08000-0xf7c0bfff irq 17 at device 0.1 on pci1
>>> > e1000_set_mac_type
>>> > igb1: attach_pre capping queues at 8
>>> > 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_read_sfp_data_byte
>>> > e1000_read_sfp_data_byte
>>> > e1000_init_nvm_params_82575
>>> > e1000_init_phy_params_82575
>>> > e1000_reset_mdicnfg_82580
>>> > e1000_sgmii_uses_mdio_82575
>>> > e1000_get_phy_id_82575
>>> > e1000_sgmii_uses_mdio_82575
>>> > e1000_read_phy_reg_sgmii_82575
>>> > e1000_acquire_phy_82575
>>> > e1000_acquire_swfw_sync
>>> > e1000_get_hw_semaphore
>>> > e1000_put_hw_semaphore
>>> > e1000_read_phy_reg_i2c
>>> > I2CCMD Error bit set
>>> > e1000_release_phy_82575
>>> > e1000_release_swfw_sync
>>> > e1000_get_hw_semaphore
>>> > e1000_put_hw_semaphore
>>> > PHY address 1 was unreadable
>>> > e1000_read_phy_reg_sgmii_82575
>>> > e1000_acquire_phy_82575
>>> > e1000_acquire_swfw_sync
>>> > e1000_get_hw_semaphore
>>> > e1000_put_hw_semaphore
>>> > e1000_read_phy_reg_i2c
>>> > I2CCMD Error bit set
>>> > e1000_release_phy_82575
>>> > e1000_release_swfw_sync
>>> > e1000_get_hw_semaphore
>>> > e1000_put_hw_semaphore
>>> > PHY address 2 was unreadable
>>> > e1000_read_phy_reg_sgmii_82575
>>> > e1000_acquire_phy_82575
>>> > e1000_acquire_swfw_sync
>>> > e1000_get_hw_semaphore
>>> > e1000_put_hw_semaphore
>>> > e1000_read_phy_reg_i2c
>>> > I2CCMD Error bit set
>>> > e1000_release_phy_82575
>>> > e1000_release_swfw_sync
>>> > e1000_get_hw_semaphore
>>> > e1000_put_hw_semaphore
>>> > PHY address 3 was unreadable
>>> > e1000_read_phy_reg_sgmii_82575
>>> > e1000_acquire_phy_82575
>>> > e1000_acquire_swfw_sync
>>> > e1000_get_hw_semaphore
>>> > e1000_put_hw_semaphore
>>> > e1000_read_phy_reg_i2c
>>> > I2CCMD Error bit set
>>> > e1000_release_phy_82575
>>> > e1000_release_swfw_sync
>>> > e1000_get_hw_semaphore
>>> > e1000_put_hw_semaphore
>>> > PHY address 4 was unreadable
>>> > e1000_read_phy_reg_sgmii_82575
>>> > e1000_acquire_phy_82575
>>> > e1000_acquire_swfw_sync
>>> > e1000_get_hw_semaphore
>>> > e1000_put_hw_semaphore
>>> > e1000_read_phy_reg_i2c
>>> > I2CCMD Error bit set
>>> > e1000_release_phy_82575
>>> > e1000_release_swfw_sync
>>> > e1000_get_hw_semaphore
>>> > e1000_put_hw_semaphore
>>> > PHY address 5 was unreadable
>>> > e1000_read_phy_reg_sgmii_82575
>>> > e1000_acquire_phy_82575
>>> > e1000_acquire_swfw_sync
>>> > e1000_get_hw_semaphore
>>> > e1000_put_hw_semaphore
>>> > e1000_read_phy_reg_i2c
>>> > I2CCMD Error bit set
>>> > e1000_release_phy_82575
>>> > e1000_release_swfw_sync
>>> > e1000_get_hw_semaphore
>>> > e1000_put_hw_semaphore
>>> > PHY address 6 was unreadable
>>> > e1000_read_phy_reg_sgmii_82575
>>> > e1000_acquire_phy_82575
>>> > e1000_acquire_swfw_sync
>>> > e1000_get_hw_semaphore
>>> > e1000_put_hw_semaphore
>>> > e1000_read_phy_reg_i2c
>>> > I2CCMD Error bit set
>>> > e1000_release_phy_82575
>>> > e1000_release_swfw_sync
>>> > e1000_get_hw_semaphore
>>> > e1000_put_hw_semaphore
>>> > PHY address 7 was unreadable
>>> > PHY Initialization Error
>>> > igb1: Setup of Shared code failed, error -2
>>> > igb1: IFDI_ATTACH_PRE failed 6
>>> > device_attach: igb1 attach returned 6
>>> >
>>> > I've also attached a complete dmesg.
>>> >
>>> >> Regards,
>>> >> Kevin
>>> >>
>>> >> On Sun, Aug 19, 2018 at 7:21 AM, Roman Bogorodskiy <novel@freebsd.org> wrote:
>>> >> > Hi,
>>> >> >
>>> >> > I have a 4-port Intel I350 network card. When I plug sfp rj45 module to
>>> >> > one of the ports, devices fails to initialise, e.g. ifconfig(8) only
>>> >> > shows three igb interfaces (expected to be four):
>>> >> >
>>> >> > igb0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
>>> >> >         options=e505bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,LRO,VLAN_HWFILTER,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6>
>>> >> >         ether 00:12:c0:00:e9:14
>>> >> >         media: Ethernet autoselect
>>> >> >         status: no carrier
>>> >> >         nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
>>> >> > igb1: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
>>> >> >         options=e505bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,LRO,VLAN_HWFILTER,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6>
>>> >> >         ether 00:12:c0:00:e9:16
>>> >> >         media: Ethernet autoselect
>>> >> >         status: no carrier
>>> >> >         nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
>>> >> > igb2: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
>>> >> >         options=e505bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,LRO,VLAN_HWFILTER,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6>
>>> >> >         ether 00:12:c0:00:e9:17
>>> >> >         media: Ethernet autoselect
>>> >> >         status: no carrier
>>> >> >         nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
>>> >> >
>>> >> > dmesg has the following:
>>> >> >
>>> >> > igb0: <Intel(R) PRO/1000 PCI-Express Network Driver> port 0xe060-0xe07f mem 0xf7a00000-0xf7bfffff,0xf7c0c000-0xf7c0ffff irq 16 at device 0.0 on pci1
>>> >> > igb0: attach_pre capping queues at 8
>>> >> > igb0: using 1024 tx descriptors and 1024 rx descriptors
>>> >> > igb0: msix_init qsets capped at 8
>>> >> > igb0: pxm cpus: 4 queue msgs: 9 admincnt: 1
>>> >> > igb0: using 4 rx queues 4 tx queues
>>> >> > igb0: Using MSIX interrupts with 5 vectors
>>> >> > igb0: allocated for 4 tx_queues
>>> >> > igb0: allocated for 4 rx_queues
>>> >> > igb0: Ethernet address: 00:12:c0:00:e9:14
>>> >> > igb0: netmap queues/slots: TX 4/1024, RX 4/1024
>>> >> > igb1: <Intel(R) PRO/1000 PCI-Express Network Driver> port 0xe040-0xe05f mem 0xf7800000-0xf79fffff,0xf7c08000-0xf7c0bfff irq 17 at device 0.1 on pci1
>>> >> > igb1: attach_pre capping queues at 8
>>> >> > igb1: Setup of Shared code failed, error -2
>>> >> > igb1: IFDI_ATTACH_PRE failed 6
>>> >> > device_attach: igb1 attach returned 6
>>> >> > igb1: <Intel(R) PRO/1000 PCI-Express Network Driver> port 0xe020-0xe03f mem 0xf7600000-0xf77fffff,0xf7c04000-0xf7c07fff irq 18 at device 0.2 on pci1
>>> >> > igb1: attach_pre capping queues at 8
>>> >> > igb1: using 1024 tx descriptors and 1024 rx descriptors
>>> >> > igb1: msix_init qsets capped at 8
>>> >> > igb1: pxm cpus: 4 queue msgs: 9 admincnt: 1
>>> >> > igb1: using 4 rx queues 4 tx queues
>>> >> > igb1: Using MSIX interrupts with 5 vectors
>>> >> > igb1: allocated for 4 tx_queues
>>> >> > igb1: allocated for 4 rx_queues
>>> >> > igb1: Ethernet address: 00:12:c0:00:e9:16
>>> >> > igb1: netmap queues/slots: TX 4/1024, RX 4/1024
>>> >> > igb2: <Intel(R) PRO/1000 PCI-Express Network Driver> port 0xe000-0xe01f mem 0xf7400000-0xf75fffff,0xf7c00000-0xf7c03fff irq 19 at device 0.3 on pci1
>>> >> > igb2: attach_pre capping queues at 8
>>> >> > igb2: using 1024 tx descriptors and 1024 rx descriptors
>>> >> > igb2: msix_init qsets capped at 8
>>> >> > igb2: pxm cpus: 4 queue msgs: 9 admincnt: 1
>>> >> > igb2: using 4 rx queues 4 tx queues
>>> >> > igb2: Using MSIX interrupts with 5 vectors
>>> >> > igb2: allocated for 4 tx_queues
>>> >> > igb2: allocated for 4 rx_queues
>>> >> > igb2: Ethernet address: 00:12:c0:00:e9:17
>>> >> > igb2: netmap queues/slots: TX 4/1024, RX 4/1024
>>> >> >
>>> >> > And in pciconf(8) it shows as:
>>> >> >
>>> >> > igb0@pci0:1:0:0:        class=0x020000 card=0x00101b6d chip=0x15228086 rev=0x01 hdr=0x00
>>> >> >     vendor     = 'Intel Corporation'
>>> >> >     device     = 'I350 Gigabit Fiber Network Connection'
>>> >> >     class      = network
>>> >> >     subclass   = ethernet
>>> >> > none1@pci0:1:0:1:       class=0x020000 card=0x00101b6d chip=0x15228086 rev=0x01 hdr=0x00
>>> >> >     vendor     = 'Intel Corporation'
>>> >> >     device     = 'I350 Gigabit Fiber Network Connection'
>>> >> >     class      = network
>>> >> >     subclass   = ethernet
>>> >> > igb1@pci0:1:0:2:        class=0x020000 card=0x00101b6d chip=0x15228086 rev=0x01 hdr=0x00
>>> >> >     vendor     = 'Intel Corporation'
>>> >> >     device     = 'I350 Gigabit Fiber Network Connection'
>>> >> >     class      = network
>>> >> >     subclass   = ethernet
>>> >> > igb2@pci0:1:0:3:        class=0x020000 card=0x00101b6d chip=0x15228086 rev=0x01 hdr=0x00
>>> >> >     vendor     = 'Intel Corporation'
>>> >> >     device     = 'I350 Gigabit Fiber Network Connection'
>>> >> >     class      = network
>>> >> >     subclass   = ethernet
>>> >> >
>>> >> > Any suggestions what could be wrong with that?
>>> >> >
>>> >> > The host is FreeBSD 12.0-ALPHA1 amd64 @ r337885. I don't know how/if it
>>> >> > worked before, just plugged that in.
>>> >> >
>>> >> > Roman Bogorodskiy
>>> >
>>> > Roman Bogorodskiy
>>
>> Roman Bogorodskiy



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAK7dMtDO_UzhHKBDtNAQ=XKWEFTdDU3K2FVsEmcMo8cbro0S7A>