Date: Mon, 17 Jan 2000 08:24:20 -0800 (PST) From: Frank Mayhar <frank@exit.com> To: jon@spock.org (Jonathan Chen) Cc: imp@village.org (Warner Losh), grog@lemis.com (Greg Lehey), current@FreeBSD.ORG Subject: Re: 3C589 problems (was: 4.0 code freeze scheduled for Jan 15th) Message-ID: <200001171624.IAA71114@realtime.exit.com> In-Reply-To: <A7D0177343GZ7J8374.A1728B0F840@msidl.d0.localhost> from Jonathan Chen at "Jan 10, 2000 01:02:40 am"
next in thread | previous in thread | raw e-mail | index | archive | help
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. -- Frank Mayhar frank@exit.com 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?200001171624.IAA71114>