Subject: re: pcmcia problems with Thinkpad 560 and 3c589
To: David Brownlee <abs@anim.dreamworks.com>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
List: port-i386
Date: 03/25/1998 01:23:52
>        Trying to bring up 1.3.1 on an IBM Thinkpad 560, and encountering
>        problems with my 3c589 (which works fine in my old Hinote Ultra,
>        but the screen is dead on that, rendering it less than ideal :)
>
>        On the (working) Hinote, the card configures as:
>
>ep0 at pcmcia0 function 0 port 0x330-0x33f: 3Com 3C589 Ethernet
>ep0: MAC address 00:20:af:c7:48:f7
>ep0: 8KB byte-wide FIFO, 5:3 Rx:Tx split, utp/aui/bnc (default bnc)
>
>        On the Thinkpad it fails with:
>
>ep0 at pcmcia0 function 0 port 0x330-0x33f: 3Com 3C589 Ethernet
>ep0: MAC address 00:20:af:c7:48:f7
>ep0: wrote 0x7ff to TX_AVAIL_THRESH, read back 0xfffc. Interface disabled
>
>        Interestingly, if I pull and replace the card it will
>        successfully configure, but I can't see any traffic from this
>        (This happens even if I swap to the other port)
>
>ep1 at pcmcia0 function 0 port 0x340-0x34f: 3Com 3C589 Ethernet
>ep1: MAC address 00:20:af:c7:48:f7
>ep1: 8KB byte-wide FIFO, 5:3 Rx:Tx split, utp/aui/bnc (default bnc)
>
>        Does anyone have any ideas on how I can debug this - in
>        particular is upgrading to -current liable to help, and
>        how can I control the available port and IRQ ranges?

hi,

What's going on here is that the driver is trying to ascertain whether
the card has an old chipset, or a new chipset (vortex, boomerang, etc)
which supports large packets.  The large-packet cards implicitly shift
the command field that contains packet length (because commands only
have 12 bits and large packets can be bigger than 4k).

So the drive writes a large packet-length to the transmit-threshold
register, and then reads back the actual vaule from an onboard
register.  If, when read back, the value is shifted from what's
expected (due to giant-packet support), the driver knows it needs to
shift accordingly.

What's going on here is that the first time, your card is returning a
value the driver thinks is impossible.  This might just be due to
improperly configuring the PCMCIA chipset for 16-bit addressing if it
only has 12-bit addressing, but I dont see how, offhand.  Do you
possibly have some other device (non-PnP, non-PCMCIA) at those ioport
addresses?

What it does the second time (when you get a recogniszed value) I have
no idea, but if it's matching the shifted value (large packet support)
and the card really doesn thave large-packet support, then the driver
wont ever recieve packets properly.

If all the PCMCIA stuff checks out, I would try changing
sys/dev/ic/elink3.c around line 279, adding a delay after the
SET_TX_AVAIL_THRESH command, and maybe settnig the threshold twice, usw.

Is it worth adding yet more output to the driver, to show whether
large-packet support was detected or not?