Bug 6495

Begin forwarded message:

Date: Thu, 4 May 2006 23:15:56 -0700
From: bugme-daemon@bugzilla.kernel.org
To: bugme-new@lists.osdl.org
Subject: [Bugme-new] [Bug 6495] New: Vlan MTU Fragmentation


http://bugzilla.kernel.org/show_bug.cgi?id=6495

           Summary: Vlan MTU Fragmentation
    Kernel Version: 2.6.16.12
            Status: NEW
          Severity: normal
             Owner: shemminger@osdl.org
         Submitter: slavon@bigtelecom.ru


Steps to reproduce:

ifconfing eth0 mtu 1500
ifconfing eth0.100 mtu 1500

ping www.ru -s 2000
-- BAD --

----------------

ifconfing eth0 mtu 1500
ifconfing eth0.100 mtu 1496

ping www.ru -s 2000
--NORMAL--

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

Andrew Morton wrote:
> 
> Begin forwarded message:
> 
> Date: Thu, 4 May 2006 23:15:56 -0700
> From: bugme-daemon@bugzilla.kernel.org
> To: bugme-new@lists.osdl.org
> Subject: [Bugme-new] [Bug 6495] New: Vlan MTU Fragmentation
> 
> 
> http://bugzilla.kernel.org/show_bug.cgi?id=6495
> 
>            Summary: Vlan MTU Fragmentation
>     Kernel Version: 2.6.16.12
>             Status: NEW
>           Severity: normal
>              Owner: shemminger@osdl.org
>          Submitter: slavon@bigtelecom.ru
> 
> 
> Steps to reproduce:
> 
> ifconfing eth0 mtu 1500
> ifconfing eth0.100 mtu 1500
> 
> ping www.ru -s 2000
> -- BAD --
> 
> ----------------
> 
> ifconfing eth0 mtu 1500
> ifconfing eth0.100 mtu 1496
> 
> ping www.ru -s 2000
> --NORMAL--

This is almost definately a bug in the ethernet driver.  The driver needs
to be modified so that it can send/receive pkts that are MTU + 4 bytes for the
VLAN header.

We need to know what NIC/driver this user is using...

Ben


> 
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug, or are watching someone who is.
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

05:0a.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 78)
        Subsystem: 3Com Corporation 3C905C-TX Fast Etherlink for PC Management NIC
        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-
        Latency: 32 (2500ns min, 2500ns max), Cache Line Size 08
        Interrupt: pin A routed to IRQ 7
        Region 0: I/O ports at 9c00 [size=128]
        Region 1: Memory at feafe000 (32-bit, non-prefetchable) [size=128]
        [virtual] Expansion ROM at fe900000 [disabled] [size=128K]
        Capabilities: <access denied>

Also try Realtek network adapter (if need - i say chipset tomorow)

slavon@dmitry ~ $ /sbin/lsmod 
8021q                  14856  0
...
3c59x                  36200  0
mii                     4160  1 3c59x

On Fri, 05 May 2006 08:57:06 -0700
Ben Greear <greearb@candelatech.com> wrote:

> Andrew Morton wrote:
> > 
> > Begin forwarded message:
> > 
> > Date: Thu, 4 May 2006 23:15:56 -0700
> > From: bugme-daemon@bugzilla.kernel.org
> > To: bugme-new@lists.osdl.org
> > Subject: [Bugme-new] [Bug 6495] New: Vlan MTU Fragmentation
> > 
> > 
> > http://bugzilla.kernel.org/show_bug.cgi?id=6495
> > 
> >            Summary: Vlan MTU Fragmentation
> >     Kernel Version: 2.6.16.12
> >             Status: NEW
> >           Severity: normal
> >              Owner: shemminger@osdl.org
> >          Submitter: slavon@bigtelecom.ru
> > 
> > 
> > Steps to reproduce:
> > 
> > ifconfing eth0 mtu 1500
> > ifconfing eth0.100 mtu 1500
> > 
> > ping www.ru -s 2000
> > -- BAD --
> > 
> > ----------------
> > 
> > ifconfing eth0 mtu 1500
> > ifconfing eth0.100 mtu 1496
> > 
> > ping www.ru -s 2000
> > --NORMAL--
> 
> This is almost definately a bug in the ethernet driver.  The driver needs
> to be modified so that it can send/receive pkts that are MTU + 4 bytes for the
> VLAN header.
> 
> We need to know what NIC/driver this user is using...
> 
> Ben
> 

Sorry, I should have added Badalian to Cc:.  He's using 3c905C (3c59x.c,
allegedly maintained by myself).

(Badalian, please use emailed reply-to-all rather than the bugzilla
interface for the remainder of this discussion, thanks).

Andrew Morton wrote:

> Sorry, I should have added Badalian to Cc:.  He's using 3c905C (3c59x.c,
> allegedly maintained by myself).
> 
> (Badalian, please use emailed reply-to-all rather than the bugzilla
> interface for the remainder of this discussion, thanks).
> 

There is an ancient patch on this page:

http://www.bewley.net/linux/vlan/patches/

I have no idea if this would apply or if it has already been put into the
kernel.  I also don't have any 3com nics to test with, but there are probably
folks on the vlan mailing list that could try patches...

Thanks,
Ben

On Fri, 05 May 2006 21:39:14 -0700
Ben Greear <greearb@candelatech.com> wrote:

> Andrew Morton wrote:
> 
> > Sorry, I should have added Badalian to Cc:.  He's using 3c905C (3c59x.c,
> > allegedly maintained by myself).
> > 
> > (Badalian, please use emailed reply-to-all rather than the bugzilla
> > interface for the remainder of this discussion, thanks).
> > 
> 
> There is an ancient patch on this page:
> 
> http://www.bewley.net/linux/vlan/patches/
> 
> I have no idea if this would apply or if it has already been put into the
> kernel.  I also don't have any 3com nics to test with, but there are probably
> folks on the vlan mailing list that could try patches...
> 

Yeah, that was merged ages ago.

I guess I can type simple commands and add printks.  Do you have time to
take a look at the driver and suggest what I should be looking for?

Andrew Morton wrote:

> I guess I can type simple commands and add printks.  Do you have time to
> take a look at the driver and suggest what I should be looking for?

I can only offer vague hints:

TX usually works, but RX often has isues.  There is usually a bit
or two that needs setting to enable the larger than MTU pkt RX.

It seems some older chipsets had issues with doing checksum offload
for VLAN packets, so could try disabling the UDP/TCP checksum logic
and see if that helps.

Thanks,
Ben

This appears to be a bug with the 3com NIC driver.  I do not own
this hardware or know the driver, so it is unlikely I will ever
be able to fix this problem.

Assigning to the 3com driver maintainer.

If the driver is not going to be fixed, then I will update
my VLAN page with a note that the 3c905 driver can only run
VLANs with MTU of 1496, and that users needing 1500 MTU vlans
must use a different piece of harder.

If no objections, this bug should be closed as Documented.
Thanks.