pch_gbe problems with Debian kernels

[Bryan Smith]

Hey Guys,

I've been running into a lot of issues with the pch_gbe module with all Debian kernels below:

vmlinuz-3.10-2-rt-686-pae

vmlinuz-3.10-3-rt-686-pae

vmlinuz-3.2.0-4-686-pae

vmlinuz-3.2.0-4-rt-686-pae

The device refuses to come up at first citing:

pch_gbe: pch-gbe.miim won't go ready

Then after a few times of booting with the Angstrom kernel the interface actually comes up with ALL of my Debian kernels but it's in a state of limbo.

At this point the interface can be brought up and down, it allows me to assign an ipaddress but it can't ping anything. Strangely enough though if I ping the Minnow's ip it fails to respond but the RX bytes shown by ifconfig go up as if it is receiving packets. Furthermore if I run iptraf I can see a .20kb spike in traffic to eth0 when I initiate pings from another system.

Oddly enough bringing the interface up and down sometimes  also crashes the system periodically.

Can anyone shed any light on this?

lspci

02:00.1 Ethernet controller: Intel Corporation Platform Controller Hub EG20T Gigabit Ethernet Controller (rev 02)

        Subsystem: Device 1cc8:0001

        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+

        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-

        Latency: 0

        Interrupt: pin A routed to IRQ 47

        Region 0: I/O ports at 2020 [size=32]

        Region 1: Memory at a0028000 (32-bit, non-prefetchable) [size=512]

        Capabilities: [40] MSI: Enable+ Count=1/1 Maskable- 64bit-

                Address: fee0300c  Data: 4142

        Capabilities: [50] Power Management version 2

                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)

                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME+

        Kernel driver in use: pch_gbe

Bryan

[Hart, Darren]

The debian kernels lack the following upstream commit to support the NIC
on the MinnowBoard:

f1a26fd pch_gbe: Add MinnowBoard support

This commit landed in Linux 3.12.

Without those, the driver will not recognize the PHY and will not
perform the necessary actions to work with it. Specifically, setting up
the TX delay and waking it up in the event that it put itself to sleep
(this particular PHY is rather aggressive with it's sleeping habits).

--
Darren Hart

[Bryan Smith]

Hey Darren,

I can surely verify that the gigabit interface works like a champ with a 3.12.x kernel that I just tested.

Thanks,

Bryan

[Julian Hsiao]

Hi Darren,

I'm also running the 3.12 experimental kernel from Debian, and I'm seeing this in dmesg:

[ 2.794930] pch_gbe: EG20T PCH Gigabit Ethernet Driver - version 1.01
[ 2.795041] pch_gbe 0000:02:00.1: enabling device (0000 -> 0003)
[ 2.795403] pch_gbe 0000:02:00.1: setting latency timer to 64
[ 2.795456] pch_gbe 0000:02:00.1: ERR: Can't request PHY reset GPIO line '13'
[ 2.799045] pch_gbe 0000:02:00.1: Invalid MAC address, interface disabled.
[ 2.799090] pch_gbe 0000:02:00.1: MAC address : 00:00:00:00:00:00

I worked around the problem by adding the following to /etc/network/interfaces:

pre-up ip link set dev eth0 down
pre-up ip link set dev eth0 address <lladdr>

Do you know what's going on?  I've just updated the UEFI firmware to 1.0.0; could that have something to do with it?  Unfortunately I didn't try to use the built-in NIC until now, so I don't know if it would have worked before.

Thanks.

[Hart, Darren]

On Sun, 2013-12-15 at 10:23 -0800, Julian Hsiao wrote:
> Hi Darren,
>
>
> I'm also running the 3.12 experimental kernel from Debian, and I'm
> seeing this in dmesg:
>
> [ 2.794930] pch_gbe: EG20T PCH Gigabit Ethernet Driver - version 1.01
> [ 2.795041] pch_gbe 0000:02:00.1: enabling device (0000 -> 0003)
> [ 2.795403] pch_gbe 0000:02:00.1: setting latency timer to 64
> [ 2.795456] pch_gbe 0000:02:00.1: ERR: Can't request PHY reset GPIO
> line '13'

OK, so what this means is GPIO 13 either doesn't exist or is reserved by
another driver. Either way, the pch_gbe driver will not be able to reset
the PHY (and it will not wakeup).

1) Is the gpio-sch driver built-in or loaded?

I thought I had some KCONFIG dependency magic in place there, but I
don't see it upstream.

Try building in or loading gpio-sch prior to pch_gbe, and I think you'll
find this resolves the issue.

--
Darren

--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

[Bryan Smith]

Julian,

I have the same issue about the GPIO but my nic works, because my mac is valid. If you updated the UEFI then you need to make sure you assign your mac using the Firmwareupdate tool.

In the firmware zip archive is a directory named doc which has Using the MinnowBoard Flash.pdf. This pdf tells you have to update your mac, which it seems you have to on each firmware update(at least I've had to each time)

FirmwareUpdate -m <Ethernet MAC address>

My ethernet works like a champ albeit without GPIO 13 access, there is no gpio-sch prebuilt with this kernel but there is a gpio-pch which is loaded.

[  3.278415] pch_gbe: EG20T PCH Gigabit Ethernet Driver - version 1.01

[    3.452687] pch_gbe 0000:02:00.1: enabling device (0000 -> 0003)

[    3.453024] pch_gbe 0000:02:00.1: setting latency timer to 64

[    3.453070] pch_gbe 0000:02:00.1: ERR: Can't request PHY reset GPIO line '13'

[    3.456623] pch_gbe 0000:02:00.1: MAC address : 00:13:20:fe:2d:47

Ethernet works fine on Arch with a 3.11 kernel too...same GPIO 13 error too.

On Ubuntu with 3.13.x gpio-sch is loaded(ethernet works too) but I get the GPIO 13 error there too.

Bryan

[Hart, Darren]

The nic will work even with the gpio error if the board is powered on with an Ethernet cable attached and connected to a switch as the PHY will not go to sleep prior to the driver loading.