Andrew Morton:
o s2io.h: gcc-3.5 build fix
Christoph Hellwig:
o convert acenic to pci_driver API
o kill acient compat cruft from acenic
Daniel Ritz:
o netdev_priv for xirc2ps_cs, nmclan_cs
Domen Puncer:
o lmc header file not needed
Don Fry:
o pcnet32 add led blink capability
o pcnet32 correct name display
o pcnet32 all printk under netif_msg
o pcnet32.c add support for 79C976
Fran?ois Romieu:
o [netdrvr r8169] TX irq handler looping fix
o [netdrvr r8169] DAC changes
o [netdrvr r8169] Barrier against compiler optimization
o [netdrvr r8169] ethtool driver info
o [netdrvr r8169] DMA api resync
o [netdrvr sis190] more RX path work
o [netdrvr sis190] don't use one huge buffer for all RX skb's
o [netdrvr sis190] add dirty_rx to private structure
o [netdrvr sis190] separate out RX skb alloc, fill
o [netdrvr sis190] add helpers
o [netdrvr sis190] sis190_open() fixes/updates
o [netdrvr sis190] add pci-disable-device
o [netdrvr sis190] fix endianness issues
o [netdrvr epic100] napi fixes
o [netdrvr epic100] napi 3/3 - transmit path
o [netdrvr epic100] napi 2/3 - receive path
o [netdrvr epic100] napi 1/3 - just shuffle some code around
o [netdrvr epic100] minor cleanups
o [netdrvr r8169] Rx wrap bug
o [netdrvr r8169] fix TX race
o [netdrvr r8169] fix phy initialization loop init
o [netdrvr r8169] fix rx counter masking bug
o [netdrvr r8169] fix oops by removing __devinitdata marker
o 2.6.1-rc1-mm1 - typo of death in the r8169 driver
o [netdrvr r8169] Stats fix (Fernando Alencar Marótica <[email protected]>)
o [netdrvr r8169] Endianness update (original idea from Alexandra N. Kossovsky)
o [netdrvr r8169] fix RX
o [netdrvr r8169] Suspend/resume code (Fernando Alencar Marótica)
o [netdrvr r8169] Modification of the interrupt mask (RealTek)
o [netdrvr r8169] Driver forgot to update the transmitted bytes counter
o [netdrvr r8169] Merge of changes from Realtek
o [netdrvr r8169] Merge of timer related changes from Realtek
o [netdrvr r8169] Merge of changes done by Realtek to rtl8169_init_one()
o [netdrvr r8169] Add {mac/phy}_version
o [netdrvr r8169] Rx copybreak for small packets
o [netdrvr r8169] Conversion of Tx data buffers to PCI DMA
o [netdrvr r8169] rtl8169_start_xmit fixes
o [netdrvr r8169] Conversion of Rx data buffers to PCI DMA
o [netdrvr r8169] Conversion of Rx/Tx descriptors to consistent DMA
Hirofumi Ogawa:
o 8139too: more useful debug info for tx_timeout
Jeff Garzik:
o [netdrvr natsemi] correct DP83816 IntrHoldoff register offset
o [netdrvr 8139cp] better dev->close() handling, and misc related stuff
o [netdrvr 8139cp] complete 64-bit DMA (PCI DAC) support
o [netdrvr 8139cp] use netdev_priv()
o [netdrvr 8139cp] minor cleanups
o [NET] define HAVE_NETDEV_PRIV back-compat hook
o [netdrvr 8139cp] locking cleanups
o [netdrvr s2io] NAPI build fixes
o [netdrvr 8139cp] rearrange priv struct, add cacheline-align markers
o [net/fc iph5526] s/rx_dropped/tx_dropped/ in TX routines
o [netdrvr s2io] correct an incorrect cleanup I made
o [netdrvr] Add S2IO 10gige network driver
o Remove unused compatibility-defines include wan/lmc/lmc_ver.h
o Manually merge with upstream
Jeff Muizelaar:
o tc35815 cleanup
Leana Ogasawara:
o dgrs: add missing iounmaps
Luiz Fernando N. Capitulino:
o com20020-isa.c warning fix
Pavel Machek:
o Support newer revisions of broadcoms in b44.c
Randy Dunlap:
o remove magic '31' for netdev priv. alignment
Scott Feldman:
o Update MAINTAINERS with new e100/e1000/ixgb maintainers
On 06.04.2004, at 17:30, Jeff Garzik wrote:
> * Francois work on r8169, epic100, sis190: PCI DMA, NAPI, other minor
> fixes and cleanups
r8169 seems to work though it is not even a tad bit faster
than plain 2.6.5.
Those cards are really driving me nuts. Between two r8169 cards, one
on Athlon with kernel 2.4.24, one on Athlon with 2.6.5 or 2.4.24, I
get 90Mbit/s in one direction and 39Mbit/s in the other using iperf and
TCP. With iperf and UDP they deliver 100Mbit/s resp. 230Mbit/s depending
on the direction. Crosschecking with my PowerBook (OS X) shows that I
can
get 844Mbit/s (UDP) or 572Mbit/s (TCP) to one host and 844Mbit/s (UDP)
but
only 88Mbit/s (TCP) to the other.
The environment is switched and changing cables and/or ports doesn't
improve the results.
Ideas? (Yeah, I'll get Intel NICs RSN...)
Servus,
Daniel
Daniel Egger wrote:
> On 06.04.2004, at 17:30, Jeff Garzik wrote:
>
>> * Francois work on r8169, epic100, sis190: PCI DMA, NAPI, other minor
>> fixes and cleanups
>
>
> r8169 seems to work though it is not even a tad bit faster
> than plain 2.6.5.
Francois is still trying to fix all the vendor-created bugs, so
performance is a secondary consideration.
RTL8169 is a nice chipset, though. Robert Ollsson had some nice pktgen
numbers for it, IIRC.
> Those cards are really driving me nuts. Between two r8169 cards, one
> on Athlon with kernel 2.4.24, one on Athlon with 2.6.5 or 2.4.24, I
> get 90Mbit/s in one direction and 39Mbit/s in the other using iperf and
> TCP. With iperf and UDP they deliver 100Mbit/s resp. 230Mbit/s depending
> on the direction. Crosschecking with my PowerBook (OS X) shows that I can
> get 844Mbit/s (UDP) or 572Mbit/s (TCP) to one host and 844Mbit/s (UDP) but
> only 88Mbit/s (TCP) to the other.
>
> The environment is switched and changing cables and/or ports doesn't
> improve the results.
>
> Ideas? (Yeah, I'll get Intel NICs RSN...)
Yeah -- I plan to kill r8169, and use 8139cp.c to drive it instead :)
Jeff
Jeff Garzik <[email protected]> :
[...]
> Francois is still trying to fix all the vendor-created bugs, so
> performance is a secondary consideration.
With due respect to Realtek and others, some pesky bugs in the driver
were really (c) by me.
The issues related to 64 bit host and/or link recovery seem to be gone.
If people experience issues with the r8169 driver in -mm/-netdev whereas
the vanilla driver works fine, I am interested to hear from them.
Preferably now.
--
Ueimor
On 13.04.2004, at 20:31, Jeff Garzik wrote:
> RTL8169 is a nice chipset, though. Robert Ollsson had some nice
> pktgen numbers for it, IIRC.
You gotta be kidding. I've not seen a single OS where
this cheapass chipset was fast. It's always the last in
line but maybe that's just because Realtek wrote the
drivers themselves. :)
3Com/Marvell and Broadcom are much better though and I
intend to try Intel, they are said to be the best.
Servus,
Daniel
Daniel Egger <[email protected]> :
> On 13.04.2004, at 20:31, Jeff Garzik wrote:
>
> > RTL8169 is a nice chipset, though. Robert Ollsson had some nice
> > pktgen numbers for it, IIRC.
>
> You gotta be kidding. I've not seen a single OS where
> this cheapass chipset was fast. It's always the last in
> line but maybe that's just because Realtek wrote the
> drivers themselves. :)
http://oss.sgi.com/projects/netdev/archive/2003-11/msg00399.html
Coming soon :o)
--
Ueimor