Most recent kernel where this bug did not occur: N/A Distribution: Debian 4.0r1 (Etch) Hardware Environment: Sun Netra T1 105 Software Environment: Problem Description: sunhme requires lower MTU to handle 802.1q frames - even though the PCI driver supported VLAN tagging, you cannot do full MTU @ 1500 because the driver doesn't set the card to transfer more the extra bytes for a 802.1q frame at 1500 MTU. Steps to reproduce: modprobe 8021q modprobe sunhme ifconfig eth0 up vconfig set_name_type DEV_PLUS_VID_NO_PAD vconfig add eth0 10 ifconfig eth0.10 192.l68.0.1 netmask 255.255.255.252 broadcast 192.168.0.3 up # IP pkt size = 1496, Ethernet frame size = 1514 ping -s 1468 -c 1 -w 1 192.168.0.2 # IP pkt size = 1500, Ethernet frame size = 1518 ping -s 1472 -c 1 -w 1 192.168.0.2
Had a custom patch that will program the NIC to receive bigger frames
Created attachment 13363 [details] Program NIC to receive bigger frame
Reply-To: akpm@linux-foundation.org On Wed, 31 Oct 2007 14:54:06 -0700 (PDT) bugme-daemon@bugzilla.kernel.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=9270 > > Summary: sunhme requires lower MTU to handle 802.1q frames > Product: Drivers > Version: 2.5 > KernelVersion: 2.6.18-3 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: Network > AssignedTo: jgarzik@pobox.com > ReportedBy: dev-null@telus.net > > > Most recent kernel where this bug did not occur: N/A > Distribution: Debian 4.0r1 (Etch) > Hardware Environment: Sun Netra T1 105 > Software Environment: > Problem Description: > sunhme requires lower MTU to handle 802.1q frames - even though the PCI > driver supported VLAN tagging, you cannot do full MTU @ 1500 because the > driver doesn't set the card to transfer more the extra bytes for a 802.1q > frame at 1500 MTU. > > Steps to reproduce: > modprobe 8021q > modprobe sunhme > ifconfig eth0 up > vconfig set_name_type DEV_PLUS_VID_NO_PAD > vconfig add eth0 10 > ifconfig eth0.10 192.l68.0.1 netmask 255.255.255.252 broadcast 192.168.0.3 up > # IP pkt size = 1496, Ethernet frame size = 1514 > ping -s 1468 -c 1 -w 1 192.168.0.2 > # IP pkt size = 1500, Ethernet frame size = 1518 > ping -s 1472 -c 1 -w 1 192.168.0.2
From: Andrew Morton <akpm@linux-foundation.org> Date: Wed, 31 Oct 2007 15:43:01 -0700 > > sunhme requires lower MTU to handle 802.1q frames - even though the PCI > > driver supported VLAN tagging, you cannot do full MTU @ 1500 because the > > driver doesn't set the card to transfer more the extra bytes for a 802.1q > > frame at 1500 MTU. It supports VLAN tagging by accident, the NETIF_F_VLAN_CHALLENGED flag should be set both in the PCI and non-PCI cases. Jeff, please apply, thanks: [SUNHME]: Fix missing NETIF_F_VLAN_CHALLENGED on PCI happy meals. No HME parts can do VLANs correctly. Signed-off-by: David S. Miller <davem@davemloft.net> diff --git a/drivers/net/sunhme.c b/drivers/net/sunhme.c index 120c8af..c20a3bd 100644 --- a/drivers/net/sunhme.c +++ b/drivers/net/sunhme.c @@ -3143,8 +3143,8 @@ static int __devinit happy_meal_pci_probe(struct pci_dev *pdev, dev->irq = pdev->irq; dev->dma = 0; - /* Happy Meal can do it all... */ - dev->features |= NETIF_F_SG | NETIF_F_HW_CSUM; + /* Happy Meal can do it all... except VLAN. */ + dev->features |= NETIF_F_SG | NETIF_F_HW_CSUM | NETIF_F_VLAN_CHALLENGED; #if defined(CONFIG_SBUS) && defined(CONFIG_PCI) /* Hook up PCI register/dma accessors. */
Even though it appears to work after I bumped the BMAC_TXMAX / BMAC_RXMAX?
Reply-To: akpm@linux-foundation.org On Wed, 31 Oct 2007 16:35:57 -0700 (PDT) David Miller <davem@davemloft.net> wrote: > From: Andrew Morton <akpm@linux-foundation.org> > Date: Wed, 31 Oct 2007 15:43:01 -0700 > > > > sunhme requires lower MTU to handle 802.1q frames - even though the PCI > > > driver supported VLAN tagging, you cannot do full MTU @ 1500 because the > > > driver doesn't set the card to transfer more the extra bytes for a 802.1q > > > frame at 1500 MTU. > > It supports VLAN tagging by accident, the NETIF_F_VLAN_CHALLENGED > flag should be set both in the PCI and non-PCI cases. > > Jeff, please apply, thanks: > > [SUNHME]: Fix missing NETIF_F_VLAN_CHALLENGED on PCI happy meals. > > No HME parts can do VLANs correctly. > > Signed-off-by: David S. Miller <davem@davemloft.net> > > diff --git a/drivers/net/sunhme.c b/drivers/net/sunhme.c > index 120c8af..c20a3bd 100644 > --- a/drivers/net/sunhme.c > +++ b/drivers/net/sunhme.c > @@ -3143,8 +3143,8 @@ static int __devinit happy_meal_pci_probe(struct > pci_dev *pdev, > dev->irq = pdev->irq; > dev->dma = 0; > > - /* Happy Meal can do it all... */ > - dev->features |= NETIF_F_SG | NETIF_F_HW_CSUM; > + /* Happy Meal can do it all... except VLAN. */ > + dev->features |= NETIF_F_SG | NETIF_F_HW_CSUM | > NETIF_F_VLAN_CHALLENGED; > > #if defined(CONFIG_SBUS) && defined(CONFIG_PCI) > /* Hook up PCI register/dma accessors. */ I forgot to add my standard "please reply via emailed reply-to-all, not via the bugzilla web interface", so Chris has gone and attempted to communicate with us via the bugzilla UI (sigh). He asked "Even though it appears to work after I bumped the BMAC_TXMAX / BMAC_RXMAX?"
Forgot to add that only changing BMAC_TXMAX & BMAC_RXMAX wouldn't work for me, until I changed 2 skb_put as well (which is in the patch that I submitted in bugzilla). Dug up some really old threads on the net and found out that this was reported before Quoting Andrew Morton <akpm@linux-foundation.org>: > On Wed, 31 Oct 2007 16:35:57 -0700 (PDT) > David Miller <davem@davemloft.net> wrote: > > > From: Andrew Morton <akpm@linux-foundation.org> > > Date: Wed, 31 Oct 2007 15:43:01 -0700 > > > > > > sunhme requires lower MTU to handle 802.1q frames - even though the > PCI > > > > driver supported VLAN tagging, you cannot do full MTU @ 1500 because > the > > > > driver doesn't set the card to transfer more the extra bytes for a > 802.1q > > > > frame at 1500 MTU. > > > > It supports VLAN tagging by accident, the NETIF_F_VLAN_CHALLENGED > > flag should be set both in the PCI and non-PCI cases. > > > > Jeff, please apply, thanks: > > > > [SUNHME]: Fix missing NETIF_F_VLAN_CHALLENGED on PCI happy meals. > > > > No HME parts can do VLANs correctly. > > > > Signed-off-by: David S. Miller <davem@davemloft.net> > > > > diff --git a/drivers/net/sunhme.c b/drivers/net/sunhme.c > > index 120c8af..c20a3bd 100644 > > --- a/drivers/net/sunhme.c > > +++ b/drivers/net/sunhme.c > > @@ -3143,8 +3143,8 @@ static int __devinit happy_meal_pci_probe(struct > pci_dev *pdev, > > dev->irq = pdev->irq; > > dev->dma = 0; > > > > - /* Happy Meal can do it all... */ > > - dev->features |= NETIF_F_SG | NETIF_F_HW_CSUM; > > + /* Happy Meal can do it all... except VLAN. */ > > + dev->features |= NETIF_F_SG | NETIF_F_HW_CSUM | > NETIF_F_VLAN_CHALLENGED; > > > > #if defined(CONFIG_SBUS) && defined(CONFIG_PCI) > > /* Hook up PCI register/dma accessors. */ > > I forgot to add my standard "please reply via emailed reply-to-all, not via > the bugzilla web interface", so Chris has gone and attempted to communicate > with us via the bugzilla UI (sigh). > > He asked > > "Even though it appears to work after I bumped the BMAC_TXMAX / BMAC_RXMAX?" > > >
can someone confirm this is fixed in recent kernels, so maybe this can be closed? i had some conversation with andrea shepard about another bug and also pointed to this one - and apparently this bug may have been fixed. >> >The latter is a different VLAN bug that has been fixed in the current >> >kernel; >> you don`t (by chance) probably know what was the fix or who did it? >> i would like to put that in bugzilla and ask it to be closed then. > >No, but I know the current version of the driver works with 1522-byte >buffers. >-- >Andrea Shepard