[eepro100] Receiver lock-up -- is this right??

[les Niles]

I'm trying to track down an eepro100 lock-up problem.  I don't know if 
this lock-up is the standard one for which the driver's work-around is 
intended, but in looking at the code I came across something that doesn't 
look quite right.   In the initialization routine speedo_found1() there are 
two references to the lock-up workaround.  The first, in the kernel_bloat
section, tests "if (eeprom[3] & 0x03)" and prints a KERN_INFO message.  
The second, almost at the end of speedo_found1(), sets the rx_bug flag to 
"(eeprom[3] & 0x03) == 3 ? 0 : 1" and prints another KERN_INFO message if 
rx_bug is set.  This is the same in all the versions of eepro100.c that 
I've looked at, from v1.06 to v1.17.

I don't get it.  The first test says the work-around is "enabled" if either
of 
the low-order bits is set.  The second test -- the one that counts --
"activates" 
work-around if either of the low-order bits is *not* set.  Is that right? 
Why the conflicting messages?  Am I missing something?  Have I gone stupid
from 
staring at this problem too long?  

(At startup, the first message appears and the second one doesn't, which is 
consistent with the 0x0503 that eepro100-diag reports for eeprom[3] -- which

means the work-around doesn't get run.)

  -les  lniles@narus.com