NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

port-sparc64/46260: gem0 driver fails to recover after RX overflow

>Number:         46260
>Category:       port-sparc64
>Synopsis:       gem0 driver fails to recover after RX overflow
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    port-sparc64-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Mar 26 22:25:00 +0000 2012
>Originator:     Havard Eidnes
>Release:        NetBSD 6.0_BETA
System: NetBSD 6.0_BETA NetBSD 6.0_BETA (GENERIC) #1: 
Mon Mar 26 20:41:19 UTC 2012
Architecture: sparc64
Machine: sparc64
        I've currently been upgrading a SunFire V120 from 4.0 via 5.1
        to 6.0_BETA.  The host sometimes gets significant traffic over
        gem0.  With the code in 4.0, it has been rock solid.

        However, both with 5.1 and 6.0_BETA, the gem(4) Ethernet interface
        tends to lock up.  Adding some debugging printf()s reveals that
        the errors which occur right before the interface seizes up is
        an RX overflow, the modified code is:

        if (status & GEM_INTR_RX_MAC) {
                int rxstat = bus_space_read_4(t, h, GEM_MAC_RX_STATUS);
                 * At least with GEM_SUN_GEM and some GEM_SUN_ERI
                 * revisions GEM_MAC_RX_OVERFLOW happen often due to a
                 * silicon bug so handle them silently. Moreover, it's
                 * likely that the receiver has hung so we reset it.
                if (rxstat & GEM_MAC_RX_OVERFLOW) {
                            "receive error: RX overflow");

        And this printf() is triggered.

        Push lots of traffic through gem0 with either 5.1 or 6.0_BETA.
        Watch it seize up.

        Doing an "ifconfig gem0 down; ifconfig gem0 up" resets the
        interface so that it works again for a while.

Home | Main Index | Thread Index | Old Index