Date: Tue, 14 Aug 2001 13:05:01 +0200 From: "Jose M. Alcaide" <jose@we.lc.ehu.es> To: Scott Mitchell <scott.mitchell@mail.com> Cc: Jamie Bowden <ragnar@sysabend.org>, mobile@FreeBSD.ORG Subject: Re: xe0 and ifconfig Message-ID: <3B7905DD.A9F935B7@we.lc.ehu.es> References: <Pine.BSF.4.10.10108130417440.28030-100000@moo.sysabend.org> <20010814001013.A268@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
Scott Mitchell wrote: > > Strangely enough, someone else did report a similar problem a few weeks > ago. As I recall, they had two (supposedly) identical cards, one of which > started behaving differently after it had been using Win2K or FreeBSD (I > forget which). I am who reported that similar problem. The other "OS" ;-) is WinMe. The odd thing here is that we have two Xircom RE-100 (CE3-10/100) cards with different behavior: the old card (~18 months old) works fine under both Windows (Xircom driver version 2.05) and FreeBSD; however, the new card suffers from negotiation problems under FreeBSD (even when rebooted after Windows). We did a small test, installing another (older) version of the Xircom's Windows driver, and surprisingly the card showed a different behavior under FreeBSD (in fact, the negotiation problems went worse). Then, we reinstalled the latest Xircom's Windows driver (v2.05), rebooted FreeBSD, and we saw the original negotiation problems. Conclusion: the Xircom's Windows driver does "something" with the card which survives the initialization perfomed by xe(4). I told the owner of the problem card that he should define XE_DEBUG, but now he is on vacation. > AFAIK, the Intel & Compaq xe cards are just a Xircom in a different wrapper > so the same behaviour should exist with all of them. However, I didn't > think there was any configurable state in there that would survive power > cycling... except maybe the MAC address, I guess. How long did you eject > it for? I read the Xircom technical docs, and according to that information almost nothing should survive a hardware reset. And the xe driver _does_ a hardware reset. Weird. > I'm starting to be convinced - from other conversations I've had lately - > that there's some fundamental flaw in the way the xe driver initialises the > card. This could be the real reason that autonegotiation doesn't always > work, it could explain these really weird behaviours too -- perhaps the > flawed init procedure is screwing up the card in some way such that it's > really hard to unscrew it :-) > > I've been talking to a few other people who are looking at various prblems > with the xe driver, including this intialisation thing; hopefully there > will be some answers soon. If you want some testers, don't hesitate to contact me. Cheers, -- JMA ****** Jose M. Alcaide // jose@we.lc.ehu.es // jmas@FreeBSD.org ****** ** "Beware of Programmers who carry screwdrivers" -- Leonard Brandwein ** To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3B7905DD.A9F935B7>