> > 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" - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.rutgers.edu
