removal of certain net drivers coming soon: eepro100, xircom_tulip_cb, iph5526

(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.

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.

---

 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(-)

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

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.

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

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

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.

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

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

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

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])

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.

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

It's a file in the Documentation/ directory, feel free to just patch it, adding entries for these drivers.

thanks,

greg k-h

["Followup-To:" header set to gmane.linux.kernel.]

I have an intel eepro100 card in an old PII 266. With eepro100, it gets ~9Mbit, but e100 struggles to keep its head above 1Mbit, and is very erratic.

Also, drivers/net/Kconfig still claims that E100_NAPI exists, but the option to disable napi has long since been removed from the driver.

Jason

@@ -1435,23 +1435,6 @@
 	  <file:Documentation/networking/net-modules.txt>.  The module
 	  will be called e100.
 
-config E100_NAPI
-	bool "Use Rx Polling (NAPI)"
-	depends on E100
-	help
-	  NAPI is a new driver API designed to reduce CPU and interrupt load
-	  when the driver is receiving lots of packets from the card. It is
-	  still somewhat experimental and thus not yet enabled by default.
-
-	  If your estimated Rx load is 10kpps or more, or if the card will be
-	  deployed on potentially unfriendly networks (e.g. in a firewall),
-	  then say Y here.
-
-	  See <file:Documentation/networking/NAPI_HOWTO.txt> for more
-	  information.
-
-	  If in doubt, say N.
-
 config LNE390
 	tristate "Mylex EISA LNE390A/B support (EXPERIMENTAL)"
 	depends on NET_PCI && EISA && EXPERIMENTAL