Xircom Ethernet driver patch for CE2 & CEM33

Scott Mitchell

unread,

Nov 18, 2001, 7:21:51 PM11/18/01

to

Hi all,

The attached patch (against -STABLE or anything close to it; these files
haven't changed for ages) is hopefully a long-overdue fix to the support
for CE2, CEM28 and CEM33 cards in the xe driver. Specifically:

- Most, if not all, CE2 cards should now be probed correctly
- Some changes supplied by Peter Fürst to prevent the driver becoming
confused about the number of bytes to send, and not sending any
- A few other minor tweaks

Peter also informed me of some restrictions in the memory ranges and I/O
addresses supported by the CEM33 (this may be true for the CE2 and CEM28 as
well). He says:

>There are restrictions on IO addresses and memory range, as
>the Xircom CEM33 readme, Release 1.21, July 9, 1998 says:
>
> -The CreditCard Ethernet+Modem 33.6 does not support the memory
> range D000-D0FF.
>
> -On some machines D600-D6FF is not supported.
>
> -The CreditCard Ethernet+Modem 33.6 supports only "even" IO addresses
> (example: 240, 260, 280, 300, 320, 340, 360). If you use an "odd" IO
> address (example: 310, 330, 250), the adapter will fail to initialize.

It may be worthwhile fixing your pccard.conf to match these restrictions if
your card isn't being configured correctly.

Question: is there any way to enforce these restrictions from within the
driver? The CIS on these cards doesn't appear to give any indication that
these addresses are not allowed.

To apply the patch:

patch -p < xe_drv-20011118.patch

Then rebuild your kernel, reboot and see what happens. The patch turns on
some more debugging output from the driver, so expect more verbose messages
than usual. It may also be worthwhile running pccardd manually with the -d
flag if there are problems configuring the card.

I don't have a CE2 card, so I can't verify that these changes will do any
good at all... however, it still works with my CE3 so I don't think I've
made anything worse :-)

Please let me know if this works or not, whatever variety of Xircom card
you're using. If it doesn't work, please include relevant messages,
'pccardc dumpcis' output and pccard.conf file.

A fix for the broken xe multicast code is coming soon...

Scott

xe_drv-20011118.patch

Warner Losh

unread,

Nov 18, 2001, 9:34:02 PM11/18/01

to

In message <20011119002035.B30992@localhost> Scott Mitchell writes:
: - Some changes supplied by Peter Fürst to prevent the driver becoming

: confused about the number of bytes to send, and not sending any
: - A few other minor tweaks

Any what?

: Question: is there any way to enforce these restrictions from within the

: driver? The CIS on these cards doesn't appear to give any indication that
: these addresses are not allowed.

The bus picks address 0xd0000 for memory, and the driver wants to say
"get bent, I can't use that, give me a different one"? I don't think
so.

: I don't have a CE2 card, so I can't verify that these changes will do any

: good at all... however, it still works with my CE3 so I don't think I've
: made anything worse :-)

I keep meaning to send you a CE2 card. I'll give these tests a try.

Warner

P.S. Here's patch for the bad CIS addresses, relative to -stable.
I've not had a chance to port it to -current yet, but it causes at
least one of the DELL laptops that a local user has to start working
again.

Index: if_xe.c
===================================================================
RCS file: /cache/ncvs/src/sys/dev/xe/if_xe.c,v
retrieving revision 1.13.2.5
diff -u -r1.13.2.5 if_xe.c
--- if_xe.c 21 Jul 2000 22:38:24 -0000 1.13.2.5
+++ if_xe.c 19 Nov 2001 02:31:43 -0000
@@ -226,10 +226,8 @@
struct xe_softc *sc = (struct xe_softc *) device_get_softc(dev);
bus_space_tag_t bst;
bus_space_handle_t bsh;
- struct resource *r;
- int rid;
+ struct resource *r; int rid;
int ioport;
-
#ifdef XE_DEBUG
device_printf(dev, "Hacking your Realport, master\n");
#endif
@@ -244,11 +242,10 @@
r = bus_alloc_resource(dev, SYS_RES_MEMORY, &rid, 0, ~0, 4 << 10, RF_ACTIVE);
if (!r) {
#if XE_DEBUG > 0
- device_printf(dev, "Can't map in attribute memory\n");
+ device_printf(dev, "Can't map in attribute memory\n");
#endif
- return -1;
+ return -1;
}
-
bsh = rman_get_bushandle(r);
bst = rman_get_bustag(r);

@@ -291,7 +288,7 @@
int buf;
u_char ver_str[CISTPL_BUFSIZE>>1];
off_t offs;
- int success, rc, i;
+ int success, rc = 0, i;
int rid;
struct resource *r;

@@ -360,6 +357,7 @@
#if XE_DEBUG > 1
device_printf(dev, "Not a PCMCIA Ethernet card!\n");
#endif
+ success--;
rc = ENODEV; /* Not a PCMCIA Ethernet device */
} else {
if (media & 0x10) { /* Ethernet/modem cards */
@@ -388,6 +386,7 @@
scp->dingo = 1;
scp->card_type = "CEM56"; break;
default:
+ success--;
rc = ENODEV;
}
} else { /* Ethernet-only cards */
@@ -404,6 +403,7 @@
scp->mohawk = 1;
scp->card_type = "CE3"; break;
default:
+ success--;
rc = ENODEV;
}
}
@@ -440,6 +440,8 @@
/* Die now if something went wrong above */
if (success < 3)
return ENXIO;
+ if (rc != 0)
+ return (rc);

/* Check for certain strange CE2's that look like CE's */
if (strcmp(scp->card_type, "CE") == 0) {

To Unsubscribe: send mail to majo...@FreeBSD.org
with "unsubscribe freebsd-mobile" in the body of the message

Jamie Bowden

unread,

Nov 19, 2001, 7:45:09 AM11/19/01

to

On Sun, 18 Nov 2001, Warner Losh wrote:

:P.S. Here's patch for the bad CIS addresses, relative to -stable.

:I've not had a chance to port it to -current yet, but it causes at
:least one of the DELL laptops that a local user has to start working
:again.

Cool. How soon do you expect to merge this stuff into -STABLE? I'm still
running 4.3-R on my Latitude for various reasons mostly related to pcmcia
and xe0.

Jamie Bowden

--
"It was half way to Rivendell when the drugs began to take hold"
Hunter S Tolkien "Fear and Loathing in Barad Dur"
Iain Bowen <ala...@alaric.org.uk>

Warner Losh

unread,

Nov 19, 2001, 11:25:39 AM11/19/01

to

In message <Pine.BSF.4.10.101111...@moo.sysabend.org> Jamie Bowden writes:

: On Sun, 18 Nov 2001, Warner Losh wrote:
:
: :P.S. Here's patch for the bad CIS addresses, relative to -stable.
: :I've not had a chance to port it to -current yet, but it causes at
: :least one of the DELL laptops that a local user has to start working
: :again.
:
: Cool. How soon do you expect to merge this stuff into -STABLE? I'm still
: running 4.3-R on my Latitude for various reasons mostly related to pcmcia
: and xe0.

A few weeks, I'd wager.

Did you see my workaround?

sysctl -w machdep.pccard.mem_start=0xd00000

Warner

Scott Mitchell

unread,

Nov 19, 2001, 4:33:57 PM11/19/01

to

On Sun, Nov 18, 2001 at 07:33:51PM -0700, Warner Losh wrote:
> In message <20011119002035.B30992@localhost> Scott Mitchell writes:

> : - Some changes supplied by Peter Fürst to prevent the driver becoming

> : confused about the number of bytes to send, and not sending any
> : - A few other minor tweaks
>

> Any what?

Anything at all. It was an off-by-one error -- it seems the CE2 doesn't
like to send odd-sized packets, so if you feed the transmitter one less
byte than it expects it doesn't send any of them. The CE3 doesn't have
this particular behaviour so I hadn't picked up on it.

> : Question: is there any way to enforce these restrictions from within the

> : driver? The CIS on these cards doesn't appear to give any indication that
> : these addresses are not allowed.
>

> The bus picks address 0xd0000 for memory, and the driver wants to say
> "get bent, I can't use that, give me a different one"? I don't think
> so.

I figured as much... I can come up with some comments to go in pccard.conf
above the CE2 entries explaining these restrictions, if that's the best
place for them to be.

> : I don't have a CE2 card, so I can't verify that these changes will do any

> : good at all... however, it still works with my CE3 so I don't think I've
> : made anything worse :-)
>

> I keep meaning to send you a CE2 card. I'll give these tests a try.

Cool, and thanks for the patch.

Scott

To Unsubscribe: send mail to majo...@FreeBSD.org