Date: Thu, 13 Aug 1998 18:29:42 -0400 (EDT) From: Bill Paul <wpaul@skynet.ctr.columbia.edu> To: hackers@FreeBSD.ORG Subject: Yet another XL driver update Message-ID: <199808132229.SAA28536@skynet.ctr.columbia.edu>
next in thread | raw e-mail | index | archive | help
Grrr. Okay, I've uploaded another XL driver update to www.freebsd.org/~wpaul. This update deals with the following issues: - Counting 'FramesDeferred' from the stats registers as interface output errors isn't quite correct (I think if a frame gets deferred a certain number of times, it counts as a collision, but collisions are counted using separate stats registers anyway). Now, output errors are only counted if a 'TxComplete' interrupt is generated, and in the watchdog timeout handler (the way the driver initializes things, TxComplete interrupts are never delivered unless there's a transmission error). - While I tested 10Mbps performace on a 3c905B and a 3c900, I did not test it on a 3c905. At 10Mbps/half-duplex I observed watchdog timeout errors and spotty performance. I'm not sure why, but setting the RxEarly threshold seems to fix this (I observed that the RX FIFO was filling up in these cases, which was the only unusual condition I could find when the errors occurred). The new driver sets this in xl_init(). I've had one person report this problem with a 3c905 operating in 10Mbps mode. 100Mbps mode seems to work fine. The 3c905B seems to work well in either mode, and the 3c900 uses its internal 10baseT transceiver for 10Mbps mode whereas the 3c905 uses an external NS83840A PHY so it doesn't behave the same. - I tweaked the packet transmission routines a little in order to try reducing the amount of interrupts delivered. Previously, the code would set the 'download indicate' bit in the status word of every transmit descriptor, which means that a 'download complete' interrupt would be generated each time a packet was successfully transfered into the NIC's memory. Now, the 'download indicate' bit is only set in the last descriptor of a chain. If only one packet is queued, then the behavior is basically the same as before. But if several packets are queued all at once, there will only be an interrupt generated for the last packet in the queue. - An update on the problem with the Dell Latitude laptop. First of all, the NIC is actually in the laptop docking station, not the laptop itself. Second of all, it's not a 3c905B but is instead a 3c905-TX. (The owner of the laptop thought it was a 3c905B-TX and told me that by mistake.) The 3c905 NICs don't load the media options word from the EEPROM: instead, the media bits are latched from pins on the ASIC, which I suppose are tied either to ground or Vcc when the board is manufactured. The value e100 makes a little more sense in this case; the upper three bits represent a test mode indicator, with 0xe actually signifying 'normal mode.' The 0x100 could indicate that the internal VCO is being used. However, the fact that the lower byte is 0x00 is totally bogus: it should be set to 0x40 (external PHY attached to MII) instead. The owner of the laptop and docking station told me that he tried another docking station and got the same results, so it's not a defect in this one unit. This means that either Dell has some perverted reason for wiring the chip this way, or else this is a manufacturing defect in this run of devices. Why it doesn't trip up the Lose95/98/NT driver I have no idea. In any case, I have added code to the driver to detect the condition where none of the media type bits are set and try to guess what it should be depending on the PCI device ID (which can be read from the EEPROM as well as from the PCI device ID register. So. If you have a 3c905-TX, please test this version of the driver in low speed modes. Hopefully you should not see any timeouts or card lockups. -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" ============================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199808132229.SAA28536>