Re: r8169.c

Re: r8169.c

[Francois Romieu]

Dorn Hetzel <kernel@dorn.hetzel.org> :
[...]
> Thank you very much for the pointers.  I have been using Linux for
> ages (well, since 1993 anyway), but this is my first attempt at fixing
> something in the kernel.  (first time I've needed to :) )
> 
> I'm off to look for and try the -mm patchkit after I write this?
> Will it apply to 2.6.10-rc2?  (I had to get to rc2 to get my SATA controller
>  to work) :)

You have two options (or more) on top of 2.6.10-rc2:
- ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10-rc2/2.6.10-rc2-mm2/2.6.10-rc2-mm2.bz2
- http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.10-rc2-netdev1.patch.bz2

Once you have applied one of the patch above, the patch below will improve
your "transmit timed out" (please apply in order and enable NAPI):
http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.10-rc2-mm1/r8169-250.patch
http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.10-rc2-mm1/r8169-255.patch

If things perform better you may want to use bigger frames and apply as
well r8169-260.patch and r8169-265.patch.
http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.10-rc2-mm1/r8169-260.patch
http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.10-rc2-mm1/r8169-265.patch


[...]
> with regard to the "original" version shipping with 2.6.10-rc2
> (which seems to be identical to the version in 2.6.9)...

Yes.
I hope the current set of changes in -mm/-netdev will be merged in
early post-2.6.10.

> gcc version = 2.95.4  (happy to update that if you think it will help)

You will be welcome to upgrade.

[...]
> > - realize that the so called version number in 2.6.9 has no meaning.
> >
> By this, do you mean that the comment of version number in the r8169.c
> of 2.6.9 is no longer related to the version numbers at Realtek?

Exactly.

One year ago, Realtek's driver was split and merged in the kernel. That
and the contributions of many people took several months to achieve a
(imho) decently stable driver. At the same time, no change appeared on
Realtek's side. Still some months later Realtek issues a new driver with
a rev number bump (2.2). Its code suggests that it includes a partial
merge from some of the changes made to the in-kernel driver as well as
some internal experiments (hooks for missing code).

The drivers are now quite different. A change of version number is 
included in the -mm/-netdev driver to protect the innocent but it seems
I'll have to push weirder numbers. :o)

[...]
> Yeah, I noticed just one version and no history, but to the good, it
> does work for me, at least so far, after the minor patch :)

1 - netif_stop_queue() race between the Tx xmit and the Tx IRQ handler.
2 - "entry" can overflow in rtl8169_tx_interrupt() -> read of random
    status and early free of Tx buffer.

When the in-kernel version had similar code, it translated into "r8169
hangs under load".

--
Ueimor

Re: r8169.c

[Dorn Hetzel]

On Fri, Nov 19, 2004 at 09:12:03PM +0100, Francois Romieu wrote:
> Dorn Hetzel <kernel@dorn.hetzel.org> :
> [Abit AA8 experience]
> 
> Do something else:
> - take a look at the changes for the 8169 driver in Jeff Garzik's -netdev
>   patchkit (included in -mm). It may be interesting to know how it behaves;

Thank you very much for the pointers.  I have been using Linux for
ages (well, since 1993 anyway), but this is my first attempt at fixing
something in the kernel.  (first time I've needed to :) )

I'm off to look for and try the -mm patchkit after I write this?
Will it apply to 2.6.10-rc2?  (I had to get to rc2 to get my SATA controller
 to work) :)

> - less +/8169 MAINTAINERS;
> - provide a more elaborate description of the issue with your computer
>   (+ gcc version, lspci -vx, dmesg at boot, lsmod, /proc/interrupts, ifconfig);

with regard to the "original" version shipping with 2.6.10-rc2
(which seems to be identical to the version in 2.6.9)...

gcc version = 2.95.4  (happy to update that if you think it will help)

see   http://www.hetzel.org/8169/orig/lspci.txt   for the lspci -vx
see   http://www.hetzel.org/8169/orig/dmesg.txt   for the dmesg

lsmod returns empty because though I have module support enabled, I'm
building everything I'm using in directly...

see   http://www.hetzel.org/8169/orig/interrupts.txt   for the /proc/interrupts
see   http://www.hetzel.org/8169/orig/ifconfig.txt   for the ifconfig -a

"NETDEV WATCHDOG: eth0: transmit timed out" is one of the observed
errors.  "RX: no buffer available" (or similar, from memory) is another.

with regard to version "2.3" (my hacked version)...

gcc version = 2.95.4  (happy to update that if you think it will help)

see   http://www.hetzel.org/8169/v23/lspci.txt   for the lspci -vx
see   http://www.hetzel.org/8169/v23/dmesg.txt   for the dmesg

lsmod returns empty because though I have module support enabled, I'm
building everything I'm using in directly...

see   http://www.hetzel.org/8169/v23/interrupts.txt   for the /proc/interrupts
see   http://www.hetzel.org/8169/v23/ifconfig.txt   for the ifconfig -a


> - realize that the so called version number in 2.6.9 has no meaning.
>
By this, do you mean that the comment of version number in the r8169.c
of 2.6.9 is no longer related to the version numbers at Realtek?
 
> Last time I looked at Realtek's driver (linux-8169(220).zip), it still
> contained bugs which had been fixed in mainline (though it merges some
> part of it) and I did not find anything which should do a difference
> from a correctness POV. Intermediate versions of Realtek's code are
> not available and the datasheet has disappeared from their website.
> With due respect for Realtek's work (serious, really) it does not make
> my life fun _at all_ (and I guess that "my" is also accurate for anyone
> who tries to work with the 8169 driver on the long run).
>
Yeah, I noticed just one version and no history, but to the good, it
does work for me, at least so far, after the minor patch :)
 
> Btw merging a 20 megaton patch is not the way network drivers changes
> are submitted. People expect a serie of small changes whose effects
> are clearly explained (see http://linux.yyz.us/patch-format.html for
> the suggested format).
>
I was pretty sure the Godzilla patch was not the answer, I just couldn't
figure out what the answer was...  I had fixed *my* problem, for now,
but it would be nice to share it if it's worth sharing...
 
> Imho your issue is not completely specific to the 8169 hardware. With
> a wet finger in the wind, I'd suspect something related to timing or irq
> (duration of locking or such).
> 
> Please Cc: netdev@oss.sgi.com on further messages. Cc: jgarzik@pobox.com
> for network devices patches is also suggested.

Done.

-Dorn


----- End forwarded message -----

Re: r8169.c

[Dorn Hetzel]

On Sat, Nov 20, 2004 at 01:29:46AM +0100, Francois Romieu wrote:
> Dorn Hetzel <kernel@dorn.hetzel.org> :
> 
> You have two options (or more) on top of 2.6.10-rc2:
> - ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10-rc2/2.6.10-rc2-mm2/2.6.10-rc2-mm2.bz2
> - http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.10-rc2-netdev1.patch.bz2
>
I have gotten as far as rc2-mm2, which was a fairly complete failure.  After
just a couple of pings on the interface, the whole system started to freeze
up fairly hard.  Please see   http://www.hetzel.org/8169/rc2-mm2/   for a
set of information on the system state this time around.  The last two
lines in messages.txt are:

illyria kernel: NETDEV WATCHDOG: eth0: transmit timed out
illyria kernel: eth0: interrupt 0001 taken in poll

Then things go south pretty hard and fast...

I'll try the other patches on top of rc2-mm2 tonight and see if that turns
out any better :)

> Once you have applied one of the patch above, the patch below will improve
> your "transmit timed out" (please apply in order and enable NAPI):
> http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.10-rc2-mm1/r8169-250.patch
> http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.10-rc2-mm1/r8169-255.patch
> 
> If things perform better you may want to use bigger frames and apply as
> well r8169-260.patch and r8169-265.patch.
> http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.10-rc2-mm1/r8169-260.patch
> http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.10-rc2-mm1/r8169-265.patch
>

Thanks again for all your help!

-Dorn
 

Re: r8169.c

[Dorn Hetzel]

> On Sat, Nov 20, 2004 at 01:29:46AM +0100, Francois Romieu wrote:
>
> > Once you have applied one of the patch above, the patch below will improve
> > your "transmit timed out" (please apply in order and enable NAPI):
> > http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.10-rc2-mm1/r8169-250.patch
> > http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.10-rc2-mm1/r8169-255.patch
> > 
> > If things perform better you may want to use bigger frames and apply as
> > well r8169-260.patch and r8169-265.patch.
> > http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.10-rc2-mm1/r8169-260.patch
> > http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.10-rc2-mm1/r8169-265.patch
> >
>
Stacked on these 4 patches and things seem much better :)

This is on an Abit AA8 Duramax motherboard.

-Dorn
 

Re: r8169.c

[Francois Romieu]

Dorn Hetzel <kernel@dorn.hetzel.org> :
[...]
[...]
[...]
[...]
[...]
[...]
[...]
[...]
[...]
> Stacked on these 4 patches and things seem much better :)

Did you change the compiler as well ?

If yes, it would be nice to know if the system performs correctly when built with
the previous compiler (feel free to answer #1 only if you are busy :o) ).

--
Ueimor

Re: r8169.c

[Dorn Hetzel]

On Tue, Nov 23, 2004 at 08:47:40PM +0100, Francois Romieu wrote:
> Dorn Hetzel <kernel@dorn.hetzel.org> :
> [...]
> > Stacked on these 4 patches and things seem much better :)
> 
> Did you change the compiler as well ?
> 
> If yes, it would be nice to know if the system performs correctly when built with
> the previous compiler (feel free to answer #1 only if you are busy :o) ).
>

Yes, I moved to gcc 3.4.3.

I'm out of town for the Thanksgiving holiday, but I will revert the compiler
and test again as soon as I get home (early next week).

Do you know when the 250-265 patches will be merged and into which train?

Best Regards,

-Dorn
 
> --
> Ueimor
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: r8169.c

[Francois Romieu]

Dorn Hetzel <kernel@dorn.hetzel.org> :
[...]
> I went ahead and remotely rebuilt using gcc 2.95.4 and upon reboot it
> worked long enough to ssh in and then it failed.  So it sounds like the
> version of gcc DOES make a difference :)

Ok, I'll have to audit the driver for the typical inline assembler +
arithmetic ops which 2.95.x dislikes.

--
Ueimor

Re: r8169.c

[Dorn Hetzel]

On Tue, Nov 23, 2004 at 08:47:40PM +0100, Francois Romieu wrote:
> Dorn Hetzel <kernel@dorn.hetzel.org> :

> > Stacked on these 4 patches and things seem much better :)
> 
> Did you change the compiler as well ?
> 
> If yes, it would be nice to know if the system performs correctly when built with
> the previous compiler (feel free to answer #1 only if you are busy :o) ).
>

I went ahead and remotely rebuilt using gcc 2.95.4 and upon reboot it
worked long enough to ssh in and then it failed.  So it sounds like the
version of gcc DOES make a difference :)

I will report further details when I get home and can access the box
again ;)

-Dorn
 
> --
> Ueimor
> -

Re: r8169.c

[Dorn Hetzel]

It did *build* well enough not to blow up the kernel build with 2.95.4,
it just failed in use...

On Thu, Nov 25, 2004 at 09:54:11PM +0100, Francois Romieu wrote:
> Dorn Hetzel <kernel@dorn.hetzel.org> :
> [...]
> > I went ahead and remotely rebuilt using gcc 2.95.4 and upon reboot it
> > worked long enough to ssh in and then it failed.  So it sounds like the
> > version of gcc DOES make a difference :)
> 
> Ok, I'll have to audit the driver for the typical inline assembler +
> arithmetic ops which 2.95.x dislikes.
> 
> --
> Ueimor

Re: r8169.c

[Francois Romieu]

Dorn Hetzel <kernel@dorn.hetzel.org> :
[...]
> I was wondering if the above 4 patches have made it into one of the
> rc? releases, or at least a rc?-mm?  ?

They need to apply on top of -netdev which is included in -mm.
I'll send the patch for inclusion in -mm so there is no need for
Jeff to hurry.

--
Ueimor

Re: r8169.c

[Dorn Hetzel]

On Mon, Nov 22, 2004 at 01:13:07PM -0500, Dorn Hetzel wrote:
> On Sat, Nov 20, 2004 at 01:29:46AM +0100, Francois Romieu wrote:
> 
> > Once you have applied one of the patch above, the patch below will improve
> > your "transmit timed out" (please apply in order and enable NAPI):
> > http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.10-rc2-mm1/r8169-250.patch
> > http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.10-rc2-mm1/r8169-255.patch
> > 
> > If things perform better you may want to use bigger frames and apply as
> > well r8169-260.patch and r8169-265.patch.
> > http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.10-rc2-mm1/r8169-260.patch
> > http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.10-rc2-mm1/r8169-265.patch
> >

I was wondering if the above 4 patches have made it into one of the
rc? releases, or at least a rc?-mm?  ?

Regards,

-Dorn

[patch 1/5] r8169: missing netif_poll_enable and irq ack

[Francois Romieu]

- (noticed by Jon D. Mason) rtl8169_wait_for_quiescence() needs to disable
  the NAPI processing but it has no reason to lock any part of the driver
  which would try to do the same at a later time. Let's reenable NAPI
  processing as soon as possible.
- properly ack any aborted interruption: a reset of the device is not
  always enough.

Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>

diff -puN drivers/net/r8169.c~r8169-250 drivers/net/r8169.c
--- linux-2.6.10-rc2/drivers/net/r8169.c~r8169-250	2004-12-05 22:36:14.592843434 +0100
+++ linux-2.6.10-rc2-fr/drivers/net/r8169.c	2004-12-05 22:36:14.596842782 +0100
@@ -1742,10 +1742,19 @@ static void rtl8169_schedule_work(struct
 
 static void rtl8169_wait_for_quiescence(struct net_device *dev)
 {
+	struct rtl8169_private *tp = netdev_priv(dev);
+	void __iomem *ioaddr = tp->mmio_addr;
+
 	synchronize_irq(dev->irq);
 
 	/* Wait for any pending NAPI task to complete */
 	netif_poll_disable(dev);
+
+	RTL_W16(IntrMask, 0x0000);
+
+	RTL_W16(IntrStatus, 0xffff);
+
+	netif_poll_enable(dev);
 }
 
 static void rtl8169_reinit_task(void *_data)

_

[patch 2/5] r8169: C 101

[Francois Romieu]

Back to C101 and code which gives the expected result.

Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>

diff -puN drivers/net/r8169.c~r8169-255 drivers/net/r8169.c
--- linux-2.6.10-rc2/drivers/net/r8169.c~r8169-255	2004-12-05 22:36:19.717006983 +0100
+++ linux-2.6.10-rc2-fr/drivers/net/r8169.c	2004-12-05 22:36:19.721006330 +0100
@@ -1978,7 +1978,7 @@ static void rtl8169_pcierr_interrupt(str
 		PCI_STATUS_REC_TARGET_ABORT | PCI_STATUS_SIG_TARGET_ABORT));
 
 	/* The infamous DAC f*ckup only happens at boot time */
-	if ((tp->cp_cmd & PCIDAC) && (tp->dirty_rx == tp->cur_rx == 0)) {
+	if ((tp->cp_cmd & PCIDAC) && !tp->dirty_rx && !tp->cur_rx) {
 		printk(KERN_INFO PFX "%s: disabling PCI DAC.\n", dev->name);
 		tp->cp_cmd &= ~PCIDAC;
 		RTL_W16(CPlusCmd, tp->cp_cmd);

_

[patch 3/5] r8169: Large Send enablement

[Francois Romieu]

Large Send enablement.

Acked-by: Francois Romieu <romieu@fr.zoreil.com>
Signed-off-by: Jon Mason <jdmason@us.ibm.com>

diff -puN drivers/net/r8169.c~r8169-260 drivers/net/r8169.c
--- linux-2.6.10-rc2/drivers/net/r8169.c~r8169-260	2004-12-05 22:36:22.079621298 +0100
+++ linux-2.6.10-rc2-fr/drivers/net/r8169.c	2004-12-05 22:36:22.084620482 +0100
@@ -112,7 +112,7 @@ static int multicast_filter_limit = 32;
 #define RX_DMA_BURST	6	/* Maximum PCI burst, '6' is 1024 */
 #define TX_DMA_BURST	6	/* Maximum PCI burst, '6' is 1024 */
 #define EarlyTxThld 	0x3F	/* 0x3F means NO early transmit */
-#define RxPacketMaxSize	0x0800	/* Maximum size supported is 16K-1 */
+#define RxPacketMaxSize	0x3FE8	/* 16K - 1 - ETH_HLEN - VLAN - CRC */
 #define InterFrameGap	0x03	/* 3 means InterFrameGap = the shortest one */
 
 #define R8169_REGS_SIZE		256
@@ -426,6 +426,9 @@ static void rtl8169_tx_timeout(struct ne
 static struct net_device_stats *rtl8169_get_stats(struct net_device *netdev);
 static int rtl8169_rx_interrupt(struct net_device *, struct rtl8169_private *,
 				void __iomem *);
+static int rtl8169_change_mtu(struct net_device *netdev, int new_mtu);
+static void rtl8169_down(struct net_device *dev);
+
 #ifdef CONFIG_R8169_NAPI
 static int rtl8169_poll(struct net_device *dev, int *budget);
 #endif
@@ -1237,8 +1240,6 @@ rtl8169_init_board(struct pci_dev *pdev,
 	}
 	tp->chipset = i;
 
-	tp->rx_buf_sz = RX_BUF_SIZE;
-
 	*ioaddr_out = ioaddr;
 	*dev_out = dev;
 out:
@@ -1320,6 +1321,7 @@ rtl8169_init_one(struct pci_dev *pdev, c
 	dev->watchdog_timeo = RTL8169_TX_TIMEOUT;
 	dev->irq = pdev->irq;
 	dev->base_addr = (unsigned long) ioaddr;
+	dev->change_mtu = rtl8169_change_mtu;
 
 #ifdef CONFIG_R8169_NAPI
 	dev->poll = rtl8169_poll;
@@ -1448,13 +1450,22 @@ static int rtl8169_resume(struct pci_dev
                                                                                 
 #endif /* CONFIG_PM */
 
-static int
-rtl8169_open(struct net_device *dev)
+static void rtl8169_set_rxbufsize(struct rtl8169_private *tp,
+				  struct net_device *dev)
+{
+	unsigned int mtu = dev->mtu;
+
+	tp->rx_buf_sz = (mtu > RX_BUF_SIZE) ? mtu + ETH_HLEN + 8 : RX_BUF_SIZE;
+}
+
+static int rtl8169_open(struct net_device *dev)
 {
 	struct rtl8169_private *tp = netdev_priv(dev);
 	struct pci_dev *pdev = tp->pci_dev;
 	int retval;
 
+	rtl8169_set_rxbufsize(tp, dev);
+
 	retval =
 	    request_irq(dev->irq, rtl8169_interrupt, SA_SHIRQ, dev->name, dev);
 	if (retval < 0)
@@ -1534,8 +1545,8 @@ rtl8169_hw_start(struct net_device *dev)
 	RTL_W8(ChipCmd, CmdTxEnb | CmdRxEnb);
 	RTL_W8(EarlyTxThres, EarlyTxThld);
 
-	// For gigabit rtl8169
-	RTL_W16(RxMaxSize, RxPacketMaxSize);
+	// For gigabit rtl8169, MTU + header + CRC + VLAN
+	RTL_W16(RxMaxSize, tp->rx_buf_sz);
 
 	// Set Rx Config register
 	i = rtl8169_rx_config |
@@ -1576,6 +1587,37 @@ rtl8169_hw_start(struct net_device *dev)
 	netif_start_queue(dev);
 }
 
+static int rtl8169_change_mtu(struct net_device *dev, int new_mtu)
+{
+	struct rtl8169_private *tp = netdev_priv(dev);
+	int ret = 0;
+
+	if (new_mtu < ETH_ZLEN || new_mtu > RxPacketMaxSize)
+		return -EINVAL;
+	
+	dev->mtu = new_mtu;
+
+	if (!netif_running(dev)) 
+		goto out;
+
+	rtl8169_down(dev);
+	
+	rtl8169_set_rxbufsize(tp, dev);
+	
+	ret = rtl8169_init_ring(dev);
+	if (ret < 0)
+		goto out;
+
+	rtl8169_hw_start(dev);
+	
+	netif_poll_enable(dev);
+
+	rtl8169_request_timer(dev);
+
+out:
+	return ret;
+}
+
 static inline void rtl8169_make_unusable_by_asic(struct RxDesc *desc)
 {
 	desc->addr = 0x0badbadbadbadbadull;
@@ -2264,19 +2306,17 @@ static int rtl8169_poll(struct net_devic
 }
 #endif
 
-static int
-rtl8169_close(struct net_device *dev)
+static void rtl8169_down(struct net_device *dev)
 {
 	struct rtl8169_private *tp = netdev_priv(dev);
-	struct pci_dev *pdev = tp->pci_dev;
 	void __iomem *ioaddr = tp->mmio_addr;
 
+	rtl8169_delete_timer(dev);
+
 	netif_stop_queue(dev);
 
 	flush_scheduled_work();
 
-	rtl8169_delete_timer(dev);
-
 	spin_lock_irq(&tp->lock);
 
 	/* Stop the chip's Tx and Rx DMA processes. */
@@ -2291,13 +2331,27 @@ rtl8169_close(struct net_device *dev)
 
 	spin_unlock_irq(&tp->lock);
 
-	free_irq(dev->irq, dev);
+	synchronize_irq(dev->irq);
 
 	netif_poll_disable(dev);
 
+	/* Give a racing hard_start_xmit a few cycles to complete. */
+	set_current_state(TASK_UNINTERRUPTIBLE);
+	schedule_timeout(1);
+
 	rtl8169_tx_clear(tp);
 
 	rtl8169_rx_clear(tp);
+}
+
+static int rtl8169_close(struct net_device *dev)
+{
+	struct rtl8169_private *tp = netdev_priv(dev);
+	struct pci_dev *pdev = tp->pci_dev;
+
+	rtl8169_down(dev);
+	
+	free_irq(dev->irq, dev);
 
 	pci_free_consistent(pdev, R8169_RX_RING_BYTES, tp->RxDescArray,
 			    tp->RxPhyAddr);

_

[patch 4/5] r8169: reduce max MTU for large frames

[Francois Romieu]

The device does not support the whole mtu range it claims. Experimenting
with the Tx threshold and/or the PCI burst size does not seem to improve
the behavior.

Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>

diff -puN drivers/net/r8169.c~r8169-265 drivers/net/r8169.c
--- linux-2.6.10-rc2/drivers/net/r8169.c~r8169-265	2004-12-05 22:36:25.000000000 +0100
+++ linux-2.6.10-rc2-fr/drivers/net/r8169.c	2004-12-07 00:54:48.313082500 +0100
@@ -112,7 +112,8 @@ static int multicast_filter_limit = 32;
 #define RX_DMA_BURST	6	/* Maximum PCI burst, '6' is 1024 */
 #define TX_DMA_BURST	6	/* Maximum PCI burst, '6' is 1024 */
 #define EarlyTxThld 	0x3F	/* 0x3F means NO early transmit */
-#define RxPacketMaxSize	0x3FE8	/* 16K - 1 - ETH_HLEN - VLAN - CRC */
+#define RxPacketMaxSize	0x3FE8	/* 16K - 1 - ETH_HLEN - VLAN - CRC... */
+#define SafeMtu		0x1c20	/* ... actually life sucks beyond ~7k */
 #define InterFrameGap	0x03	/* 3 means InterFrameGap = the shortest one */
 
 #define R8169_REGS_SIZE		256
@@ -1592,9 +1593,9 @@ static int rtl8169_change_mtu(struct net
 	struct rtl8169_private *tp = netdev_priv(dev);
 	int ret = 0;
 
-	if (new_mtu < ETH_ZLEN || new_mtu > RxPacketMaxSize)
+	if (new_mtu < ETH_ZLEN || new_mtu > SafeMtu)
 		return -EINVAL;
-	
+
 	dev->mtu = new_mtu;
 
 	if (!netif_running(dev)) 

_

[patch 5/5] r8169: oversized driver field for ethtool

[Francois Romieu]

Reported by Richard Dawe <rich@phekda.gotadsl.co.uk>:
- RTL8169_DRIVER_NAME contains more than the 32 characters allowed for the
  driver field;
- remove RTL8169_DRIVER_NAME as it is only used once.

Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>

diff -puN drivers/net/r8169.c~r8169-280 drivers/net/r8169.c
--- linux-2.6.10-rc2/drivers/net/r8169.c~r8169-280	2004-12-07 00:56:46.864676094 +0100
+++ linux-2.6.10-rc2-fr/drivers/net/r8169.c	2004-12-07 00:57:11.031721347 +0100
@@ -63,7 +63,6 @@ VERSION 1.6LK	<2004/04/14>
 
 #define RTL8169_VERSION "1.6LK"
 #define MODULENAME "r8169"
-#define RTL8169_DRIVER_NAME   MODULENAME " Gigabit Ethernet driver " RTL8169_VERSION
 #define PFX MODULENAME ": "
 
 #ifdef RTL8169_DEBUG
@@ -564,8 +563,8 @@ static void rtl8169_get_drvinfo(struct n
 {
 	struct rtl8169_private *tp = netdev_priv(dev);
 
-	strcpy(info->driver, RTL8169_DRIVER_NAME);
-	strcpy(info->version, RTL8169_VERSION );
+	strcpy(info->driver, MODULENAME);
+	strcpy(info->version, RTL8169_VERSION);
 	strcpy(info->bus_info, pci_name(tp->pci_dev));
 }
 
@@ -1282,7 +1281,8 @@ rtl8169_init_one(struct pci_dev *pdev, c
 	board_idx++;
 
 	if (!printed_version) {
-		printk(KERN_INFO RTL8169_DRIVER_NAME " loaded\n");
+		printk(KERN_INFO "%s Gigabit Ethernet driver %s loaded\n",
+		       MODULENAME, RTL8169_VERSION);
 		printed_version = 1;
 	}
 

_