The problem here is the io address 0x4300, you need to track down where it
comes from.  On the PC architecture, ISA bus devices only decode the bottom
10 bits of the IO address space.  So your card at address 0x300 will respond
to address 0x4300 as well.  Addresses 0x0 to 0x1ff are (effectively)
reserved form the motherboard IO, and 0x200 to 0x3ff for expansion cards.

All aliases of the range 0x200 to 0x3ff have to be kept unused - unless
the corresponding hardware is known to actually be on the motherboard -
because ISA cards won't do a full decode.

Moderm systems (since EISA) decode the top 4 bits as a 'slot' address,
with slot 0 being the motherboard (the 'slot select' line is actually on
the 16bit ISA connecter).  EISA cards and PCI cards are allocated IO
addresses that are aliases of motherboard IO addresses.

Now that helps a lot....

    David

----- Original Message ----- 
From: Patrick Welche <prlw1@newn.cam.ac.uk>
To: <tech-kern@netbsd.org>
Sent: Saturday, January 19, 2002 8:03 PM
Subject: Kingmax KEN0100-AF


> Removing
> 
>    965          if ((last_liobase == psc->sc_pcioh.addr)
>    966              || (last_liobase != new_liobase))
> 
> from if_ne_pcmcia.c,v 1.85 allows a Kingmax KEN0100-AF ethernet card to
> work:
> 
> pcmcia0: CIS version unknown (major=1, minor=0)
> pcmcia0: CIS info: PCMCIA, 10/100 Ethernet Card, , 
> pcmcia0: Manufacturer code 0x8a01, product 0xc1ab
> pcmcia0: function 0: network adapter, ccr addr 3c0 mask 63
> pcmcia0: function 0, config table entry 7: I/O card; irq mask ffff; iomask a, iospace 300-31f; mwait_required io16 irqlevel
> ne0 at pcmcia0 function 0
> ne0: LAN iobase 0x300 (0x4300) -> 0x300
> ne0: Melco LPC3-TX (AX88190) Ethernet
> ne0: Ethernet address 00:a0:0c:46:c1:79
> ukphy0 at ne0 phy 1: Generic IEEE 802.3u media interface
> ukphy0: OUI 0x0008bb, model 0x0002, rev. 1
> ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
> 
> What did that check do?
> 
> It fails because
>                last_liobase   psc->sc_pcioh.addr   new_liobase
> ne0: LAN iobase   0x300          (0x4300)       ->    0x300
> last_liobase==new_liobase
> 
> 
> 
> Now for a lesson please - it's my first time in these files..
> 
> According to ken-100a_oem.h from
> http://www.kingmax.com.tw/support/download/driver/pccard/update/EN0100-A%20V1.8.zip
> 
> Kingmax GENERIC_KEN0100A 10/100 Ethernet PC Card
> Kingmax GENERIC_KEN0100B 10/100 Ethernet PC Card
> Legend-easy 10/100M Ethernet PC Card
> MELCO LPC3-TX
> 
> all have the same (vendor,product) id. (For that matter according to our
> pcmciadevs, Compex, Melco and Zonet all have the same vendor id.) We already
> had support for the Melco, which is why the Kingmax "just worked". The bit
> that bothers me is that if that card where a NE2000DVF_DL10019 rather than a
> NE2000DVF_AX88190, the enaddr[0-2] would have been read off the card and
> compared with the vendor's OUI. Obviously the Kingmax card above has
> 00:a0:0c which is Kingmax. According to the ne2000devs entry for Melco:
> 
>    261      { PCMCIA_STR_MELCO_LPC2_TX,
>    262        PCMCIA_VENDOR_LINKSYS, PCMCIA_PRODUCT_LINKSYS_ETHERFAST,
>    263        PCMCIA_CIS_MELCO_LPC2_TX,
>    264        0, -1, { 0x00, 0x40, 0x26 }, NE2000DVF_DL10019 },
> 
> Melco's OUI is 00:40:26. If that check were enforced the Kingmax would still
> not match.
> 
> The syntax in pcmciadevs seems to be
> 
> product VENDORIDDEF PRODUCTDEF productid comment
> 
>   *OR*
> 
> product VENDORIDDEF PRODUCTDEF CISINFO comment
> 
> and accordingly the ne2000_match macro just checks productid or cisinfo => I
> don't see a way of being able to differentiate between the Melco and the
> Kingmax. It isn't necessary to do so, but if that OUI check were enforced, it
> would be. Have I missed something?
> 
> Cheers,
> 
> Patrick
> (telneting with the Kingmax)