Bug 4380 - (net via_velocity) receiver hang after setting mtu >1500
Summary: (net via_velocity) receiver hang after setting mtu >1500
Status: CLOSED CODE_FIX
Alias: None
Product: Drivers
Classification: Unclassified
Component: Network (show other bugs)
Hardware: i386 Linux
: P2 normal
Assignee: Jeff Garzik
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-03-21 07:23 UTC by Anders Bostr
Modified: 2006-07-14 17:20 UTC (History)
4 users (show)

See Also:
Kernel Version: 2.6.8
Subsystem:
Regression: ---
Bisected commit-id:


Attachments
Patch to get velocityget 1.19 driver to compile on linux 2.6.12 (226 bytes, patch)
2005-08-25 14:53 UTC, Jyrki Muukkonen
Details | Diff
fix memory corruption when changing the mtu (449 bytes, patch)
2006-02-28 14:14 UTC, Francois Romieu
Details | Diff

Description Anders Bostr 2005-03-21 07:23:49 UTC
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
Comment 1 Andrew Morton 2005-03-21 11:50:05 UTC
Does the same problem exist in 2.6.12-rc1?
Comment 2 Anders Bostr 2005-03-22 02:31:23 UTC
Yes, the problem persists with 2.6.12-rc1.
Comment 3 Anders Bostr 2005-05-10 02:02:19 UTC
VIA has released an updated velocity-driver, version 1.19. That driver works
with jumbo-frames (mtu>1500)! I've tested this with 2.6.8. It won't compile with
2.6.10  due to changed PCI-API.

In order to download the new velocity-driver for linux, go to
http://www.viaarena.com/default.aspx?PageID=2, select Windows XP (not linux!),
Ethernet and then download version 23 of the combo-driver.
Comment 4 Andrew Morton 2005-05-25 16:44:57 UTC
Does the driver in 2.6.12-rc5 still have this problem?
Comment 5 Anders Bostr 2005-05-26 00:05:21 UTC
I can't test this at the moment, but the velocity-driver is unchanged between
2.6.12-rc1 and 2.6.12-rc5 and rc1 has the bug.
Comment 6 Jyrki Muukkonen 2005-08-25 14:51:37 UTC
I'm having similar problems with the via-velocity driver too. Also, there seems
to be some problems with ipv6 connectivity as well. Sometimes the device is able
to get the ipv6 router advertisement and autoconfigure itself - sometimes not.
Moreover, all tcp traffic just seem to disappear. ICMP (ping6, tracepath6) works
just fine.

BTW, the velocityget 1.19 driver compiles on 2.6.12 with a few fixes, attaching
the patch (can also be found at http://www.kruu.org/jvtm/via-velocity/ ).

Velocityget doesn't work with pre-empt. Other than that it "seems to work" since
I'm writing this report.
Comment 7 Jyrki Muukkonen 2005-08-25 14:53:02 UTC
Created attachment 5765 [details]
Patch to get velocityget 1.19 driver to compile on linux 2.6.12
Comment 8 Jyrki Muukkonen 2005-08-25 14:56:26 UTC
Comment on attachment 5765 [details]
Patch to get velocityget 1.19 driver to compile on linux 2.6.12 

2005-08-24 Jyrki Muukkonen <jyrki_kruu_org>

Patch for getting VIA's own Velocity gigabit ethernet drivers to compile on
linux-2.6.12. The in-kernel via-velocity.c driver seems to be br0ken (MTU
and IPV6 issues, see http://bugzilla.kernel.org/show_bug.cgi?id=4380)

Notes:
 - suspend/resume is _not_ tested
 - pre-empt needs to be disabled (who wants that crap anyways ;)

diff -ur 1.19/velocity_main.c 1.19-hack/velocity_main.c
--- 1.19/velocity_main.c	2005-01-14 11:19:18.000000000 +0200
+++ 1.19-hack/velocity_main.c	2005-08-24 18:35:05.276710224 +0300
@@ -2329,7 +2329,7 @@
	     struct ethtool_drvinfo info={ETHTOOL_GDRVINFO};
	     strcpy(info.driver, VELOCITY_NAME);
	     strcpy(info.version, VELOCITY_VERSION);
-	     strcpy(info.bus_info,pInfo->pcid->slot_name);
+	     strcpy(info.bus_info, pci_name(pInfo->pcid));
	     if (copy_to_user(ifr->ifr_data, &info, sizeof(info)))
		 return -EFAULT;
	 }
@@ -2500,7 +2500,7 @@
     netif_stop_queue(dev);
     spin_lock_irqsave(&pInfo->lock, flags);

-    pci_save_state(pcid, pInfo->pci_state);
+    pci_save_state(pcid);

 #ifdef ETHTOOL_GWOL

@@ -2536,7 +2536,7 @@

     pci_set_power_state(pcid, 0);
     pci_enable_wake(pcid, 0, 0);
-    pci_restore_state(pcid, pInfo->pci_state);
+    pci_restore_state(pcid);

     mac_wol_reset(pInfo->pMacRegs);
Comment 9 Adrian Bunk 2006-01-02 16:41:09 UTC
Is this problem still present in 2.6.14.5/2.6.15-rc7?
Comment 10 Anders Bostr 2006-01-03 01:54:05 UTC
I haven't tested with anything newer than 2.6.12-rc1, but the changes to the
driver after 2.6.12-rc1 seems unrelated.

Version 1.21 of Via's own driver is available with source-code under GPL from
www.viaarena.com. It is much faster and works fine. It just needs a module-param
patch for the latest kernels.
Comment 11 Francois Romieu 2006-02-28 14:14:36 UTC
Created attachment 7486 [details]
fix memory corruption when changing the mtu

Anders, can you try the attached patch against 2.6.16-rc5 ?

-- 
Ueimor
Comment 12 Adrian Bunk 2006-07-14 17:20:03 UTC
I'm assuming the patch from comment #11 (that is already included in 2.6.17)
fixed this issue.

Please reopen this bug if it's still present in kernel 2.6.17.

Note You need to log in before you can comment on or make changes to this bug.