* [RFC] tulip VLAN support
@ 2005-01-05 19:34 Johannes Erdfelt
2005-01-05 22:12 ` Jeff Garzik
0 siblings, 1 reply; 6+ messages in thread
From: Johannes Erdfelt @ 2005-01-05 19:34 UTC (permalink / raw)
To: netdev
I recently upgraded a system running a 2.4 kernel to a 2.6 based
distribution (Fedora Core 2, 2.6.9-1.6_FC2 kernel) and ran into a
problem using NFS. After spending some tracking it down, I found out it
was an MTU problem and then remembered I had the same problem a couple
of years ago with the 2.4 kernels I was running.
The problem is that the tulip driver doesn't handle 802.1q tags
correctly. Since the VLAN tagging adds 4 bytes to the beginning of the
frame, this can cause frame sizes to be too large for the driver (chip?)
and the packets get dropped.
I've taken the 2.4 patch I found (I forget who developed it, sorry) and
ported it to the 2.6 driver. The patch is relative to the 2.6.9-1.6_FC2
kernel for FC2, but I suspect it will apply to other kernels relatively
cleanly.
Before I rediff the patch against the BK tree and double check all of
the tulip variants are updated correctly as well, is there any interest
in accepting a patch like this?
The 2.4 patch worked for a couple of years for me with no problems and
this 2.6 patch has worked for over a week now with no problems. However,
I'm worried that there is a reason why a similar patch has not been
applied already.
JE
diff -ur linux-2.6.9.orig/drivers/net/tulip/interrupt.c linux-2.6.9/drivers/net/tulip/interrupt.c
--- linux-2.6.9.orig/drivers/net/tulip/interrupt.c 2004-10-18 14:55:36.000000000 -0700
+++ linux-2.6.9/drivers/net/tulip/interrupt.c 2004-12-30 15:23:51.085876693 -0800
@@ -155,9 +155,9 @@
if (--rx_work_limit < 0)
goto not_done;
- if ((status & 0x38008300) != 0x0300) {
- if ((status & 0x38000300) != 0x0300) {
- /* Ingore earlier buffers. */
+ if ((status & (0x38000000 | RxDescFatalErr | RxWholePkt)) != RxWholePkt) {
+ if ((status & (0x38000000 | RxWholePkt)) != RxWholePkt) {
+ /* Ignore earlier buffers. */
if ((status & 0xffff) != 0x7fff) {
if (tulip_debug > 1)
printk(KERN_WARNING "%s: Oversized Ethernet frame "
@@ -182,10 +182,10 @@
struct sk_buff *skb;
#ifndef final_version
- if (pkt_len > 1518) {
+ if (pkt_len > 1522) {
printk(KERN_WARNING "%s: Bogus packet size of %d (%#x).\n",
dev->name, pkt_len, pkt_len);
- pkt_len = 1518;
+ pkt_len = 1522;
tp->stats.rx_length_errors++;
}
#endif
@@ -378,9 +378,9 @@
dev->name, entry, status);
if (--rx_work_limit < 0)
break;
- if ((status & 0x38008300) != 0x0300) {
- if ((status & 0x38000300) != 0x0300) {
- /* Ingore earlier buffers. */
+ if ((status & (0x38000000 | RxDescFatalErr | RxWholePkt)) != RxWholePkt) {
+ if ((status & (0x38000000 | RxWholePkt)) != RxWholePkt) {
+ /* Ignore earlier buffers. */
if ((status & 0xffff) != 0x7fff) {
if (tulip_debug > 1)
printk(KERN_WARNING "%s: Oversized Ethernet frame "
@@ -405,10 +405,10 @@
struct sk_buff *skb;
#ifndef final_version
- if (pkt_len > 1518) {
+ if (pkt_len > 1522) {
printk(KERN_WARNING "%s: Bogus packet size of %d (%#x).\n",
dev->name, pkt_len, pkt_len);
- pkt_len = 1518;
+ pkt_len = 1522;
tp->stats.rx_length_errors++;
}
#endif
diff -ur linux-2.6.9.orig/drivers/net/tulip/tulip.h linux-2.6.9/drivers/net/tulip/tulip.h
--- linux-2.6.9.orig/drivers/net/tulip/tulip.h 2004-10-18 14:55:21.000000000 -0700
+++ linux-2.6.9/drivers/net/tulip/tulip.h 2004-12-30 15:20:21.432056171 -0800
@@ -191,7 +191,7 @@
enum desc_status_bits {
DescOwned = 0x80000000,
- RxDescFatalErr = 0x8000,
+ RxDescFatalErr = 0x4842,
RxWholePkt = 0x0300,
};
@@ -259,7 +259,7 @@
#define RX_RING_SIZE 128
#define MEDIA_MASK 31
-#define PKT_BUF_SZ 1536 /* Size of each temporary Rx buffer. */
+#define PKT_BUF_SZ 1540 /* Size of each temporary Rx buffer. */
#define TULIP_MIN_CACHE_LINE 8 /* in units of 32-bit words */
diff -ur linux-2.6.9.orig/drivers/net/tulip/tulip_core.c linux-2.6.9/drivers/net/tulip/tulip_core.c
--- linux-2.6.9.orig/drivers/net/tulip/tulip_core.c 2004-10-18 14:54:32.000000000 -0700
+++ linux-2.6.9/drivers/net/tulip/tulip_core.c 2004-12-30 15:19:42.424578510 -0800
@@ -70,7 +70,7 @@
#if defined(__alpha__) || defined(__arm__) || defined(__hppa__) \
|| defined(__sparc_) || defined(__ia64__) \
|| defined(__sh__) || defined(__mips__)
-static int rx_copybreak = 1518;
+static int rx_copybreak = 1522;
#else
static int rx_copybreak = 100;
#endif
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC] tulip VLAN support
2005-01-05 19:34 [RFC] tulip VLAN support Johannes Erdfelt
@ 2005-01-05 22:12 ` Jeff Garzik
2005-01-05 22:17 ` Ben Greear
2005-01-05 22:31 ` Johannes Erdfelt
0 siblings, 2 replies; 6+ messages in thread
From: Jeff Garzik @ 2005-01-05 22:12 UTC (permalink / raw)
To: Johannes Erdfelt; +Cc: netdev
Johannes Erdfelt wrote:
> @@ -259,7 +259,7 @@
> #define RX_RING_SIZE 128
> #define MEDIA_MASK 31
>
> -#define PKT_BUF_SZ 1536 /* Size of each temporary Rx buffer. */
> +#define PKT_BUF_SZ 1540 /* Size of each temporary Rx buffer. */
This is the reason why the tulip "vlan" patch is continually rejected.
You shouldn't need to increase this constant, but rather follow the
other "large MTU" driver conversions.
Donald Becker's tulip.c (on which the kernel tulip is based) supports
proper MTU changing: ftp://ftp.scyld.com/pub/network/
Jeff
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC] tulip VLAN support
2005-01-05 22:12 ` Jeff Garzik
@ 2005-01-05 22:17 ` Ben Greear
2005-01-05 22:31 ` Johannes Erdfelt
1 sibling, 0 replies; 6+ messages in thread
From: Ben Greear @ 2005-01-05 22:17 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Johannes Erdfelt, netdev
Jeff Garzik wrote:
> Johannes Erdfelt wrote:
>
>> @@ -259,7 +259,7 @@
>> #define RX_RING_SIZE 128 #define MEDIA_MASK 31
>>
>> -#define PKT_BUF_SZ 1536 /* Size of each temporary Rx
>> buffer. */
>> +#define PKT_BUF_SZ 1540 /* Size of each temporary Rx
>> buffer. */
>
>
>
> This is the reason why the tulip "vlan" patch is continually rejected.
> You shouldn't need to increase this constant, but rather follow the
> other "large MTU" driver conversions.
Has anyone tried just leaving this line as it was (but adding the rest
of the patch)? I believe the 1536 already has plenty of space and
can hold the extra 4 bytes w/out problem.
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC] tulip VLAN support
2005-01-05 22:12 ` Jeff Garzik
2005-01-05 22:17 ` Ben Greear
@ 2005-01-05 22:31 ` Johannes Erdfelt
2005-01-05 22:45 ` Jeff Garzik
1 sibling, 1 reply; 6+ messages in thread
From: Johannes Erdfelt @ 2005-01-05 22:31 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev
On Wed, Jan 05, 2005, Jeff Garzik <jgarzik@pobox.com> wrote:
> Johannes Erdfelt wrote:
> >@@ -259,7 +259,7 @@
> > #define RX_RING_SIZE 128
> > #define MEDIA_MASK 31
> >
> >-#define PKT_BUF_SZ 1536 /* Size of each temporary Rx buffer.
> >*/
> >+#define PKT_BUF_SZ 1540 /* Size of each temporary Rx buffer.
> >*/
>
> This is the reason why the tulip "vlan" patch is continually rejected.
> You shouldn't need to increase this constant, but rather follow the
> other "large MTU" driver conversions.
Donald replied to my privately with a number of reasons why similar
patches have been rejected and this one of the same points brought up.
I just copied the 2.4 patch that worked so well for me, but I was
curious about this part of the patch as well.
I asked Donald this, but I guess I'll ask on the list here too. If the
point of PKT_BUF_SZ is to keep a consistent buffer size between drivers
(for performance reasons), why isn't this value defined in a standard
header?
> Donald Becker's tulip.c (on which the kernel tulip is based) supports
> proper MTU changing: ftp://ftp.scyld.com/pub/network/
The problem isn't changing the MTU, it's that a full ethernet sized
packet along with the 802.1q tagging causes the size of the packet to
grow past the size the driver (and it looks like the chip) will allow.
The driver on Donald's site looks to have the same problem as the driver
in the kernel.
I'm still trying to find some specs on the tulip interface so I can
better understand the chip and the changes necessary to fix this
problem. Anyone have any pointers?
JE
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC] tulip VLAN support
2005-01-05 22:31 ` Johannes Erdfelt
@ 2005-01-05 22:45 ` Jeff Garzik
2005-01-05 22:56 ` Ben Greear
0 siblings, 1 reply; 6+ messages in thread
From: Jeff Garzik @ 2005-01-05 22:45 UTC (permalink / raw)
To: Johannes Erdfelt; +Cc: netdev
Johannes Erdfelt wrote:
> On Wed, Jan 05, 2005, Jeff Garzik <jgarzik@pobox.com> wrote:
>
>>Johannes Erdfelt wrote:
>>
>>>@@ -259,7 +259,7 @@
>>>#define RX_RING_SIZE 128
>>>#define MEDIA_MASK 31
>>>
>>>-#define PKT_BUF_SZ 1536 /* Size of each temporary Rx buffer.
>>>*/
>>>+#define PKT_BUF_SZ 1540 /* Size of each temporary Rx buffer.
>>>*/
>>
>>This is the reason why the tulip "vlan" patch is continually rejected.
>>You shouldn't need to increase this constant, but rather follow the
>>other "large MTU" driver conversions.
>
>
> Donald replied to my privately with a number of reasons why similar
> patches have been rejected and this one of the same points brought up.
>
> I just copied the 2.4 patch that worked so well for me, but I was
> curious about this part of the patch as well.
>
> I asked Donald this, but I guess I'll ask on the list here too. If the
> point of PKT_BUF_SZ is to keep a consistent buffer size between drivers
> (for performance reasons), why isn't this value defined in a standard
> header?
>
>
>>Donald Becker's tulip.c (on which the kernel tulip is based) supports
>>proper MTU changing: ftp://ftp.scyld.com/pub/network/
>
>
> The problem isn't changing the MTU, it's that a full ethernet sized
> packet along with the 802.1q tagging causes the size of the packet to
> grow past the size the driver (and it looks like the chip) will allow.
What size do you need? 1504 bytes, right?
> The driver on Donald's site looks to have the same problem as the driver
> in the kernel.
>
> I'm still trying to find some specs on the tulip interface so I can
> better understand the chip and the changes necessary to fix this
> problem. Anyone have any pointers?
They're available for free on the Intel site.
I mirror 21143:
http://gkernel.sourceforge.net/specs/intel/21143-hrm.pdf.bz2
Jeff
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC] tulip VLAN support
2005-01-05 22:45 ` Jeff Garzik
@ 2005-01-05 22:56 ` Ben Greear
0 siblings, 0 replies; 6+ messages in thread
From: Ben Greear @ 2005-01-05 22:56 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Johannes Erdfelt, netdev
> What size do you need? 1504 bytes, right?
1500 MTU + 14 for header + 4 for CRC + 4 for VLAN == 1522
Normally, you just have to tell the chip to accept slightly larger frames
and/or ignore the over-size frame flag. You do not actually need any ability
to set a larger than 1500 MTU.
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2005-01-05 22:56 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-01-05 19:34 [RFC] tulip VLAN support Johannes Erdfelt
2005-01-05 22:12 ` Jeff Garzik
2005-01-05 22:17 ` Ben Greear
2005-01-05 22:31 ` Johannes Erdfelt
2005-01-05 22:45 ` Jeff Garzik
2005-01-05 22:56 ` Ben Greear
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).