(GregKH cc'd for his deprecated list)
Though this has already been mentioned, I thought I would send out a
reminder. The following net drivers are slated for removal "soon", in
the next kernel version or so:
1) iphase (iph5526 a.k.a. drivers/net/fc/*)
Been broken since 2.3 or 2.4. Only janitors have kept it compiling.
2) xircom_tulip_cb
Unmaintained, and does not work for all xircom 32bit cards. xircom_cb,
on the other hand, works for ALL xircom 32bit cards.
3) eepro100
Unmaintained; users should use e100.
When I last mentioned eepro100 was going away, I got a few private
emails saying complaining about issues not yet taken care of in e100.
eepro100 will not be removed until these issues are resolved.
On Thu, Jan 27, 2005 at 03:45:40PM -0500, Jeff Garzik wrote:
> 1) iphase (iph5526 a.k.a. drivers/net/fc/*)
>
> Been broken since 2.3 or 2.4. Only janitors have kept it compiling.
No, it doesn't even compile, and didn't so for more than two years.
On Thu, Jan 27, 2005 at 03:45:40PM -0500, Jeff Garzik wrote:
> 3) eepro100
>
> Unmaintained; users should use e100.
>
> When I last mentioned eepro100 was going away, I got a few private
> emails saying complaining about issues not yet taken care of in e100.
> eepro100 will not be removed until these issues are resolved.
Has e100 actually been fixed to use the PCI DMA API correctly yet?
Looking at it, it doesn't look like it, so until it does, eepro100
is the far better bet for platforms needing working DMA API.
What I'm talking about is e100's apparant belief that it can modify
rfd's in the receive ring on a non-cache coherent architecture and
expect the data around it to remain unaffected (see e100_rx_alloc_skb):
struct rfd {
u16 status;
u16 command;
u32 link;
u32 rbd;
u16 actual_size;
u16 size;
};
it touches command and link. This means that the whole rfd plus
maybe the following or preceding 16 bytes get loaded into a cache
line (assuming cache lines of 32 bytes), and that data written
out again at sync. However, it does this on what seems to be an
active receive chain.
So, both the CPU _and_ the device own the same data. Which is a
violation of the DMA API.
So, eepro100 works. e100 is a dead loss for non-cache coherent
architectures. Therefore, I say eepro100 stays until e100 is
fixed.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
On Thu, 27 Jan 2005 22:57:25 +0000
Russell King <[email protected]> wrote:
> Has e100 actually been fixed to use the PCI DMA API correctly yet?
It seems to be doing the right thing. I see the DMA sync calls
(properly using cpu vs. device syncing variants) at the right
spots, and the only thing the chip really relies upon is ordering
of visibility and this is achieved via a combination of cpu memory
barriers and the correct DMA sync calls.
For example, a pci_dma_sync_single_for_cpu() is always performed before
peeking at the descriptors at RX interrupt time (see e100_rx_indicate).
When new descriptors are written to, then linked into the chain it
memory barriers the cpu writes then DMA syncs the previous descriptor
to the device. This is occuring in e100_alloc_skb().
Therefore the only missing sync would be of the new RX descriptor
when linking things in like that, ie. at the end of e100_rx_alloc_skb()
if rx->prev->skb is non-NULL.
On Thu, Jan 27, 2005 at 03:31:14PM -0800, David S. Miller wrote:
> Therefore the only missing sync would be of the new RX descriptor
> when linking things in like that, ie. at the end of e100_rx_alloc_skb()
> if rx->prev->skb is non-NULL.
And that is inherently unsafe, since the chip may be modifying the RFD
while the CPU is accessing it. Adding extra sync calls does not fix
it because as far as I can see, there's nothing to tell the chip "don't
write to this RFD because any changes the CPU is making right now will
overwrite the chips own changes."
The fact of the matter is that eepro100.c works on ARM, e100.c doesn't.
There's a message from me back on 30th June 2004 at about 10:30 BST on
this very list which generated almost no interest from anyone...
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
On Fri, Jan 28, 2005 at 12:14:30AM +0000, Russell King wrote:
> The fact of the matter is that eepro100.c works on ARM, e100.c doesn't.
Hmmm, I recall e100 working fine on a Radisys ENP-2611, which has a
IXP2400 (xscale) in big-endian mode, running 2.6. This particular
board had its root fs NFS-mounted and pumped several hundreds of
gigabytes through the NIC during a period of at least a few months,
and I never saw any problems.
Something tells me that the next time I try it, it won't work at all.
--L
On Fri, 28 Jan 2005 00:14:30 +0000
Russell King <[email protected]> wrote:
> The fact of the matter is that eepro100.c works on ARM, e100.c doesn't.
> There's a message from me back on 30th June 2004 at about 10:30 BST on
> this very list which generated almost no interest from anyone...
I see. Since eepro100 just uses a fixed set of RX buffers in the
ring (ie. the DMA links are never changed) it works.
This adapter was definitely developed for a system that has to have
PCI device DMA and CPU cached data accesses in the same coherency
space in order to use their weird RX chaining thing.
So essentially, e100 needs to have it's RX logic rewritten so that
it uses a static RX descriptor set of buffers and skb_copy()'s them
to push the packets into the stack.
On Thu, 2005-01-27 at 16:48, David S. Miller wrote:
> On Fri, 28 Jan 2005 00:14:30 +0000
> Russell King <[email protected]> wrote:
>
> > The fact of the matter is that eepro100.c works on ARM, e100.c doesn't.
> > There's a message from me back on 30th June 2004 at about 10:30 BST on
> > this very list which generated almost no interest from anyone...
>
> I see. Since eepro100 just uses a fixed set of RX buffers in the
> ring (ie. the DMA links are never changed) it works.
eepro100 does a copy if pkt_len < rx_copybreak, otherwise it send up the
skb and allocates and links a new one in it's place (see
speedo_rx_link).
So I would say e100 and eepro100 are the same for >= rx_copybreak. Why
does one work and not the other? Is it because the RFD is aligned in
eepro100?
Russell, what happens with modprobe eepro100 rx_copybreak=0?
-scott
On Thu, 27 Jan 2005 17:58:37 -0800
Scott Feldman <[email protected]> wrote:
> eepro100 does a copy if pkt_len < rx_copybreak, otherwise it send up the
> skb and allocates and links a new one in it's place (see
> speedo_rx_link).
My bad, you're right. So I wonder too what the difference
is that makes it work on ARM et al.
eepro100 also drives 82556-based cards. I have a couple of EtherExpress
PRO/100 Smart cards, Intel identifier is PILA8485, PCI ID is 8086:1228.
e100 doesn't support them, I'm told eepro100 works (I have not verified
it myself). I can probably get a card or to for testing with Linux.
--
Meelis Roos
On Fri, 2005-01-28 at 01:33, Meelis Roos wrote:
> eepro100 also drives 82556-based cards. I have a couple of EtherExpress
> PRO/100 Smart cards, Intel identifier is PILA8485, PCI ID is 8086:1228.
> e100 doesn't support them, I'm told eepro100 works (I have not verified
> it myself). I can probably get a card or to for testing with Linux.
See if eepro100 works on your 82556 cards. I would be surprised if it
does. If it does, maybe it's not that much trouble to add support to
e100. Let us know.
-scott
On Thu, Jan 27, 2005 at 03:45:40PM -0500, Jeff Garzik wrote:
>
> (GregKH cc'd for his deprecated list)
It's a file in the Documentation/ directory, feel free to just patch it,
adding entries for these drivers.
thanks,
greg k-h
> See if eepro100 works on your 82556 cards. I would be surprised if it
> does. If it does, maybe it's not that much trouble to add support to
> e100. Let us know.
I did add the PCI ID to e100 to to try it with both drivers.
In short: both eepro100 and e100 have problems loading the eeprom and
don't work at least out of the box.
Here is the dmesg, first card is onboard e100, 0000:01:0c.0 and
0000:01:0d.0 are the 82556's.
e100: Intel(R) PRO/100 Network Driver, 3.3.6-k2-NAPI
e100: Copyright(c) 1999-2004 Intel Corporation
ACPI: PCI Interrupt Link [LNKE] enabled at IRQ 11
PCI: setting IRQ 11 as level-triggered
ACPI: PCI interrupt 0000:01:08.0[A] -> GSI 11 (level, low) -> IRQ 11
e100: eth0: e100_probe: addr 0xff8fe000, irq 11, MAC addr 00:03:47:A4:64:D5
ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 9
PCI: setting IRQ 9 as level-triggered
ACPI: PCI interrupt 0000:01:0c.0[A] -> GSI 9 (level, low) -> IRQ 9
e100: 0000:01:0c.0: e100_eeprom_load: EEPROM corrupted
e100: probe of 0000:01:0c.0 failed with error -11
ACPI: PCI Interrupt Link [LNKF] enabled at IRQ 11
ACPI: PCI interrupt 0000:01:0d.0[A] -> GSI 11 (level, low) -> IRQ 11
e100: 0000:01:0d.0: e100_eeprom_load: EEPROM corrupted
e100: probe of 0000:01:0d.0 failed with error -11
[...]
eepro100.c:v1.09j-t 9/29/99 Donald Becker
http://www.scyld.com/network/eepro100.html
eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin <[email protected]> and others
ACPI: PCI interrupt 0000:01:0c.0[A] -> GSI 9 (level, low) -> IRQ 9
eth1: Invalid EEPROM checksum 0x0000, check settings before activating this device!
eth1: 0000:01:0c.0, 00:00:00:00:00:00, IRQ 9.
Receiver lock-up bug exists -- enabling work-around.
Board assembly 000000-000, Physical connectors present:
Primary interface chip None PHY #0.
Self test failed, status ffffffff:
Failure to initialize the i82557.
Verify that the card is a bus-master capable slot.
Receiver lock-up workaround activated.
ACPI: PCI interrupt 0000:01:0d.0[A] -> GSI 11 (level, low) -> IRQ 11
eth2: Invalid EEPROM checksum 0x0000, check settings before activating this device!
eth2: 0000:01:0d.0, 00:00:00:00:00:00, IRQ 11.
Receiver lock-up bug exists -- enabling work-around.
Board assembly 000000-000, Physical connectors present:
Primary interface chip None PHY #0.
Self test failed, status ffffffff:
Failure to initialize the i82557.
Verify that the card is a bus-master capable slot.
Receiver lock-up workaround activated.
mdio_read() timed out with val = 00000028.
mdio_read() timed out with val = 00000028.
mdio_read() timed out with val = 00000028.
mdio_read() timed out with val = 00000028.
mdio_read() timed out with val = 00000028.
mdio_read() timed out with val = 00000028.
mdio_read() timed out with val = 00000028.
mdio_read() timed out with val = 00000028.
mdio_read() timed out with val = 00000028.
mdio_read() timed out with val = 00000028.
--
Meelis Roos ([email protected])
On Tue, 2005-02-01 at 04:48, Meelis Roos wrote:
> > See if eepro100 works on your 82556 cards. I would be surprised if it
> > does. If it does, maybe it's not that much trouble to add support to
> > e100. Let us know.
>
> I did add the PCI ID to e100 to to try it with both drivers.
>
> In short: both eepro100 and e100 have problems loading the eeprom and
> don't work at least out of the box.
Thanks Meelis.
I'll send a patch to Jeff to remove 82556 support from eepro100 for now,
just in case eepro100 sticks around longer. I believe it was a mistake
to add it in the first place. 82556 support should not be in there.
-scott
On Tue, 1 Feb 2005, Scott Feldman wrote:
> On Tue, 2005-02-01 at 04:48, Meelis Roos wrote:
>>> See if eepro100 works on your 82556 cards. I would be surprised if it
>>> does. If it does, maybe it's not that much trouble to add support to
>>> e100. Let us know.
>>
>> I did add the PCI ID to e100 to to try it with both drivers.
>>
>> In short: both eepro100 and e100 have problems loading the eeprom and
>> don't work at least out of the box.
>
> Thanks Meelis.
>
> I'll send a patch to Jeff to remove 82556 support from eepro100 for now,
> just in case eepro100 sticks around longer. I believe it was a mistake
> to add it in the first place. 82556 support should not be in there.
>
> -scott
You just need to load mii first. Both of these drivers are working
fine on 2.6.10.
Module Size Used by
HeavyLink 42756 0
parport_pc 28740 1
lp 14092 0
parport 37192 2 parport_pc,lp
autofs4 20612 0
rfcomm 38040 0
l2cap 26496 5 rfcomm
bluetooth 48516 4 rfcomm,l2cap
sunrpc 134756 1
e100 36224 0 <-------!
mii 8192 1 e100 <-------!
ipt_REJECT 9856 1
[Snipped...]
Cheers,
Dick Johnson
Penguin : Linux version 2.6.10 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by Dictator Bush.
98.36% of all statistics are fiction.
On Tue, 2005-02-01 at 11:09, linux-os wrote:
> You just need to load mii first. Both of these drivers are working
> fine on 2.6.10.
Huh? You have 82556 cards working with eepro100 or e100 on 2.6.10?
Neither driver will work on any card without mii loaded.
-scott
On Thu, Jan 27, 2005 at 09:07:31PM +0000, Christoph Hellwig wrote:
> On Thu, Jan 27, 2005 at 03:45:40PM -0500, Jeff Garzik wrote:
> > 1) iphase (iph5526 a.k.a. drivers/net/fc/*)
> >
> > Been broken since 2.3 or 2.4. Only janitors have kept it compiling.
>
> No, it doesn't even compile, and didn't so for more than two years.
A patch to remove it is attached.
<-- snip -->
iph5526 does no longer compile since 2.5 wand was therefore marked as
broken. This patch removes it.
Signed-off-by: Adrian Bunk <[email protected]>
---
drivers/net/Kconfig | 9
drivers/net/Makefile | 1
drivers/net/fc/Makefile | 8
drivers/net/fc/iph5526.c | 4645 --------------------------------
drivers/net/fc/iph5526_ip.h | 24
drivers/net/fc/iph5526_novram.c | 278 -
drivers/net/fc/iph5526_scsi.h | 31
drivers/net/fc/tach.h | 475 ---
drivers/net/fc/tach_structs.h | 428 --
9 files changed, 5899 deletions(-)