From owner-freebsd-current Mon Jan 17 8:24:40 2000 Delivered-To: freebsd-current@freebsd.org Received: from tinker.exit.com (exit-gw.power.net [207.151.46.196]) by hub.freebsd.org (Postfix) with ESMTP id 6E93914F75 for ; Mon, 17 Jan 2000 08:24:33 -0800 (PST) (envelope-from frank@exit.com) Received: from realtime.exit.com (realtime.exit.com [206.223.0.5]) by tinker.exit.com (8.9.3/8.9.3) with ESMTP id IAA47366; Mon, 17 Jan 2000 08:24:25 -0800 (PST) (envelope-from frank@exit.com) Received: (from frank@localhost) by realtime.exit.com (8.9.3/8.9.3) id IAA71114; Mon, 17 Jan 2000 08:24:20 -0800 (PST) (envelope-from frank) From: Frank Mayhar Message-Id: <200001171624.IAA71114@realtime.exit.com> Subject: Re: 3C589 problems (was: 4.0 code freeze scheduled for Jan 15th) In-Reply-To: from Jonathan Chen at "Jan 10, 2000 01:02:40 am" To: jon@spock.org (Jonathan Chen) Date: Mon, 17 Jan 2000 08:24:20 -0800 (PST) Cc: imp@village.org (Warner Losh), grog@lemis.com (Greg Lehey), current@FreeBSD.ORG Reply-To: frank@exit.com X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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