Re: kern/37723: ne* AX88190 Fast Ethernet 16-bit PC Card: where did the card go? problem

[David Holland <dholland-bugs%netbsd.org@localhost>]

The following reply was made to PR kern/37723; it has been noted by GNATS.

From: David Holland <dholland-bugs%netbsd.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: kern-bug-people%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
        netbsd-bugs%netbsd.org@localhost
Subject: Re: kern/37723: ne* AX88190 Fast Ethernet 16-bit PC Card: where did 
the card go?  problem
Date: Sun, 9 Mar 2008 20:15:43 +0000

 On Tue, Jan 08, 2008 at 06:55:00PM +0000, comfooc%gmail.com@localhost wrote:
  > I have Micronet Fast Ethernet card and it doesn't work since 2.0
  > Release. 1.6 Release worked fine with it but latest releases don't.
  > 
  > This is my problem:
  > 
  > ne2 at pcmcia0 function 0: <Fast Ethernet, 16-bit PC Card, 3.0, AX88190>
  > ne2: where did the card go?
  > 
  > (under it is linux seen as AX88790)
 
 The issue, I think, is that the ne driver reruns the match logic (that
 finds the card) when it goes to actually attach the driver. But it
 adds a couple of extra conditions. If one of those fails, it keeps
 looking through the list of card types for another match. So (if I
 understand everything correctly, which I may not) the card type that
 prints may not be the card type that it actually tries to attach and
 run under.
 
 This seems itself like a bug, though perhaps not a serious one if the
 card list is complete and accurate.
 
 What I think is happening, though, is that the card initially matches
 the AX88190 entry (the one in if_ne_pcmcia.c that contains
 PCMCIA_CIS_LANTECH_FASTNETTX), so it prints as an AX88190, but then
 when it goes to attach one of the extra tests fails. So then the
 driver keeps looking for another card type, and while no other type in
 the list matches the CIS strings, it might match one by manufacturer
 and product. And it finds one, so it doesn't error out at that point,
 but that card type doesn't have the I-am-an-AX88190 flag set, so it
 doesn't run the code that sets nsc->sc_type accordingly; this causes
 it to try the generic ne2000 identification code inside ne2000_attach
 and that fails, leading to the error message.
 
 The two extra tests that might apply are (1) the one marked "XXX This
 is highly bogus" at line 675 of if_ne_pcmcia.c, and also (2) the
 prefix of the ethernet address.
 
 Since 1.6 also checked the hardware address, and the diff from 1.6 to
 2.0 doesn't *look* like the stuff pertaining to (1) would have changed
 with your card (it does some extra things if it thinks it has an
 88790, but it doesn't look like it would think your card is one) my
 guess is that one of the new card definitions in 2.0 matches your card
 and comes before some *other* card definition that also matches your
 card but *is* tagged as an AX88190.
 
 Or at least that's the only explanation that makes sense, even though
 it doesn't seem that plausible. Maybe something else in my analysis is
 wrong.
 
 In any case, it would probably be helpful if you could find out the
 PCMCIA vendor and product IDs for your card, and also the CIS
 strings. I'm not sure how one is supposed to get this stuff (is there
 a PCMCIA equivalent of lspci?) but with luck if you don't know someone
 else can tell you...
 
 It might also be helpful to have the prefix (the first three bytes) of
 the card's ethernet address.
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost