[Bugme-new] [Bug 4380] New: via_velocity: receiver hang after setting mtu >1500

bugme-daemon at osdl.org bugme-daemon at osdl.org
Mon Mar 21 07:23:53 PST 2005


http://bugme.osdl.org/show_bug.cgi?id=4380

           Summary: via_velocity: receiver hang after setting mtu >1500
    Kernel Version: 2.6.8
            Status: NEW
          Severity: normal
             Owner: jgarzik at pobox.com
         Submitter: anders at netinsight.se


Distribution: 

Debian testing

Hardware Environment:

A normal PC with Pentium M and a VT6122 PCI board.

lspci -vv:

0000:02:04.0 Ethernet controller: VIA Technologies, Inc. VT6120/VT6121/VT6122
Gigabit Ethernet Adapter (rev 11)
        Subsystem: VIA Technologies, Inc.: Unknown device 0110
        Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV+ VGASnoop- ParErr-
Stepping- SERR+ FastB2B-
        Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Interrupt: pin A routed to IRQ 201
        Region 0: I/O ports at 4000 [size=256]
        Region 1: Memory at e0201000 (32-bit, non-prefetchable) [size=256]
        Capabilities: [50] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D3 PME-Enable- DSel=0 DScale=0 PME-

Software Environment:

Debian testing with 2.6.8 or 2.6.10 kernel.

Problem Description:

The via velocity GE-driver isn't working after setting MTU to higher
then 1500 (and setting it to lower than 1500 isn't allowed by the
driver, see bug 4001).

Only a few frames go through after setting the mtu to higher then 1500
(ifconfig ethX mtu 1600), and in some cases no frames at all. The size
of the frames don't seem to make any difference. Ethereal indicates
that the receiver stops working. Sending of frames still works.

When this has occured must the interface be taken down and then up in
order to get it working again. Just setting the mtu to 1500 again do
not solve the problem. Also, the kernel load was 0.67 when this
occured, on an idle system. The load went down to <0.05 after taking
the interface down.

One oddity in the driver code is this:

--------------------------------------------------------------------------
static int velocity_open(struct net_device *dev)
{
        struct velocity_info *vptr = dev->priv;
        int ret;

        vptr->rx_buf_sz = (dev->mtu <= 1504 ? PKT_BUF_SZ : dev->mtu + 32);

        ret = velocity_init_rings(vptr);
--------------------------------------------------------------------------
static int velocity_change_mtu(struct net_device *dev, int new_mtu)
{
        struct velocity_info *vptr = dev->priv;
        unsigned long flags;
        int oldmtu = dev->mtu;
        int ret = 0;

        if ((new_mtu < VELOCITY_MIN_MTU) || new_mtu > (VELOCITY_MAX_MTU)) {
                VELOCITY_PRT(MSG_LEVEL_ERR, KERN_NOTICE "%s: Invalid MTU.\n", 
                                vptr->dev->name);
                return -EINVAL;
        }

        if (new_mtu != oldmtu) {
                spin_lock_irqsave(&vptr->lock, flags);

                netif_stop_queue(dev);
                velocity_shutdown(vptr);

                velocity_free_td_ring(vptr);
                velocity_free_rd_ring(vptr);

                dev->mtu = new_mtu;
                if (new_mtu > 8192)
                        vptr->rx_buf_sz = 9 * 1024;
                else if (new_mtu > 4096)
                        vptr->rx_buf_sz = 8192;
                else
                        vptr->rx_buf_sz = 4 * 1024;

                ret = velocity_init_rd_ring(vptr);
--------------------------------------------------------------------------

And PKT_BUF_SZ is set to 1540. The resulting size of the rd's isn't
the same after changing the mtu to first 1600 and then back to 1500 as
when set to 1500 in open.

Steps to reproduce:

# ifconfig eth0 mtu 1600
Then run ping.

/ Anders

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.



More information about the Bugme-new mailing list