Tue Apr 13 11:50:25 1999
On Tue, 13 Apr 1999, Ning Ye wrote:
> When compiling the new driver, I found in line 168:
> #if LINUX_VERSION_CODE < 0x20155 || defined(CARDBUS)
> the compiler reports a warning about pci bus. As my kernel version is 2.2.3, I
> think maybe && is more better? So with the new include files?
Argggg. The header files changed again.
In 2.1.85+ the pci.h file was broken and unusable, and the driver had to use
the old bios32.h.
I see that pci.h has been fixed, but the old brokenness has been moved to
bios32.h. The changed code is an attempt to patch-up IRQ mapping for
little-used hardware, and once again breaks things for CardBus drivers.
Grrrr, Martin doesn't seem to understand the idea of not gratuitously
breaking working code. This could have been written in a way that worked
for existing code.
> The new driver still has some problem about MII. Please take a look at my
> log file and tulip-diag's output in the attached file.
> Do MII PHY #x transceiver registers seem normal? Why the values almost the
> same? And using this interface cause the transmit time out and the driver tries
> another mode.
You card was designed incorrectly. The idle level of the of the MII serial
mangement line is suppose to be '1', and a missing transceiver should show
up as a read of 0xffff. The driver also supports an idle level of '0',
which results in a read of 0x0000. What it can't handle is a floating line
that slowly floats from 1 to 0, resulting in reads such as 0x8000 or 0xC000
on the odd numbered registers.
These are potentially valid values, and they driver decides that it has
detected a MII transceiver.
In a better world, without other broken cards, I could work around this
problem in many ways:
- I wouldn't search for MII transceivers unless the EEPROM indicated one
existed. But many cards have bogus EEPROMs, using the Digital
symbol-mode example while actually having an MII transceiver.
- The MII read routine would look for a initial 0 transition, designed so
that you could still detect that a register read of 0xffff was valid.
But some transceivers don't generate this transition.
- The MII transceiver detect routine would read an even-addressed register
and check for 0x0000. I used to do this, but had to change because one
bogus version of the D-Link boards returned 0x0000 for the control
register setting. (Forcing 10baseT half duplex non-autonegotiate.)
I haven't *yet* come up with a simple detection scheme that would work around
the hardware bug on your card. Ideally it would happen with a single MII
read checking for two always-clear and two always-set bits.
I'm continuing to thinks about this problem.
> In this version, it reports "+ ioctl: Operation not supported", but in the
> source, I see a ioctl interface is defined. What's wrong there?
No obvious problem.. I'll check it out.
> And a little more about the document. Now the note IVb. References should
> have some changes. We may search Intel for "21*4*" and
> http://www.national.com/pf/DP/DP83840a.html from national.com.
Checked, "840A", not "840a". Corrected in the source code.
Donald Becker email@example.com
USRA-CESDIS, Center of Excellence in Space Data and Information Sciences.
Code 930.5, Goddard Space Flight Center, Greenbelt, MD. 20771