> > Both de4x5 (either from 2.2.16-3 or the one from 2.2.17pre12) and tulip
> > fail to work properly in forced full duplex, 100Mb environment.
> ...
> > With tulip, you get no warnings but it just won't work. I tried both
> > options=5,5,5,5 and options=14,14,14,14 arguments.
>
> Hmmm, read the boot message. '5' only works only when using the SYM
> transceiver, not a MII transceiver.
It doesn't work with your 0.92 driver and options=14,14,14,14 out of the
box. With fiddling w/ mii-diag, it begins to work, but TCP performance
(measured with ttcp) is poor.
2.2.16 driver (w/ RHL 2.2.16-3) shows all the same symptoms, except it
won't work at all, even with mii-diag forcing. Only output is:
--- kernel: eth1: Tx hung, 13 vs. 7. --- Someone fix this? :)Some output: ---- tulip.c:v0.92 4/17/2000 Written by Donald Becker <becker@scyld.com> http://www.scyld.com/network/tulip.html eth1: Digital DS21143 Tulip rev 65 at 0xc6840c00, 00:80:C8:C9:B8:14, IRQ 10. eth1: EEPROM default media type Autosense. eth1: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block. eth1: MII transceiver #1 config 3100 status 7849 advertising 0100. [ ... ] eth1: Using user-specified media MII 100baseTx-FDX. ---- No frames are received (ifconfig) through the NIC.
The switch is configured to Autonegotiation disable, 100Mb FDX.
However, mii-diag appears to show that the NIC is still autonegotiating: ---- Basic registers of MII PHY #1: 3100 7849 2000 5c10 0100 0081 0016 2001. Basic mode control register 0x3100: Auto-negotiation enabled. Basic mode status register 0x7849 ... 7849. Link status: not established. Your link partner is generating 100baseTx link beat (no autonegotiation). ----
After 'mii-diag -F 100baseTx-FD eth1' it appears to work: ---- Basic registers of MII PHY #1: 2100 784d 2000 5c10 0100 0081 0004 2001. Basic mode control register 0x2100: Auto-negotiation disabled, with Speed fixed at 100 mbps, full-duplex. You have link beat, and everything is working OK. Your link partner is generating 100baseTx link beat (no autonegotiation). ---
But shouldn't the driver do this job for you?
I also noticed that P166 can't really handle 100mbit (w/ ttcp). When the card was on the receiving side, it could only handle 55 Mbit/s until CPU hit 100%. As a sender, it could go as far as 71Mbit/s. UDP wasn't so CPU-intensive (94Mbit/s with CPU to spare).
> > Tulip drivers on Donald Becker's site seemed significantly different, but > > I wasn't able to test with them; all I got was: > > --- > > tulip.o: unresolved symbol pci_drv_unregister > > tulip.o: unresolved symbol pci_drv_register > > You need to load 'pci-scan.o' first. > This has the PCI, hot-swap and ACPI power control support.
Thanks for the pointers. I grabbed the header files, but didn't realize you had to compile and load a module too. Well, now I know :)
-- Pekka Savola "Tell me of difficulties surmounted, Pekka.Savola@netcore.fi not those you stumble over and fall"
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Jul 23 2000 - 21:00:12 EST