Date: Tue, 18 Jan 2000 08:56:05 +0530 From: Greg Lehey <grog@lemis.com> To: Frank Mayhar <frank@exit.com> Cc: Jonathan Chen <jon@spock.org>, Warner Losh <imp@village.org>, current@FreeBSD.ORG Subject: Re: 3C589 problems (was: 4.0 code freeze scheduled for Jan 15th) Message-ID: <20000118085605.E482@mojave.worldwide.lemis.com> In-Reply-To: <200001171624.IAA71114@realtime.exit.com>; from frank@exit.com on Mon, Jan 17, 2000 at 08:24:20AM -0800 References: <A7D0177343GZ7J8374.A1728B0F840@msidl.d0.localhost> <200001171624.IAA71114@realtime.exit.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday, 17 January 2000 at 8:24:20 -0800, Frank Mayhar wrote: > Sorry for the delay on this reply; I was going over some old email and > came across this only a week late. > > Jonathan Chen wrote: >> With what little pccard/ethernet programming experiences I've had, this >> problem seems to be caused by the interrupt for the card getting lost >> somewhere before getting processed by the handler. The reason you still >> get traffic is because of the watchdog. (Try uncommenting the commented >> out lines in sys/dev/ep/if_ep.c in the function ep_if_watchdog(), you >> should start seeing lots of kernel messages saying "ep: watchdog".) After >> looking briefly at the ep files, I saw something that doesn't seem right. >> In sys/dev/ep/if_ep_pccard.c around line 176, there's a comment that says >> "Fake IRQ must be 3". Now maybe the card requires it, or maybe the >> original author just didn't have anything on IRQ 3, I don't know. So, I'd >> suggest turning off com2 or whatever you have on irq3, -or- change the >> "fake irq" to something else you do have free on the next line (ie, >> 0x3000-> 0xa000 if you have IRQ10 free). If this works, great... if not, I >> hope Warner gets some more free time. ;) > > According to the docs, this "Fake IRQ must be 3" is legitimate. The IRQ > programmed into the resource config register in window 0 _must_ be 3: > "any other value will disable the IRQ line drivers." (Quoted from the > doc. > >> As for the other problem with collisions, I did a search on the word >> collision on sys/dev/ep/if_ep.c, and found only one mention at around line >> 620. The comment says "TXS_MAX_COLLISION - we shouldn't get here". I >> suspect it does get there, so I suggest putting a printf there to find out. >> I also suspect that the card may require a reset or some other stuff if and >> when it "gets there". If that's the case, someone else with the specs on >> the 589 cards can look that up and do it. > > I can state pretty categorically that, at least in my case, we're _not_ > getting here. > > As I said in an earlier email, I'm still having interrupt problems with > the 589 (I have a 3C589D) and the 574BT. I haven't tracked it down yet, > but I'm hunting. I do know, at least, that I'm not receiving _any_ > interrupts from either card. So far I don't know why. The fact it's appearing with two different cards which work for other people tends to point away from the cards and towards some common factor, such as your laptop. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000118085605.E482>