Date: Wed, 09 Jul 2003 12:08:07 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: mark@grondar.org Cc: current@freebsd.org Subject: Re: Broken ep0 Message-ID: <20030709.120807.103131596.imp@bsdimp.com> In-Reply-To: <200307091711.h69HBHbN083840@grimreaper.grondar.org> References: <20030709.105424.94551681.imp@bsdimp.com> <200307091711.h69HBHbN083840@grimreaper.grondar.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <200307091711.h69HBHbN083840@grimreaper.grondar.org>
Mark Murray <mark@grondar.org> writes:
: If I were to start instrumenting ep(4) with debug printf's, where is
: the best place to start?
I'm not sure that printf is the right way to track this down. You are
seeing, iirc, that ep0 "works" for a period of time, typically very
short, it hangs up. These sorts of things are hard to find with a
printf. My first suggestion would be to enable WITNESS to see if it
tells you about any LoR which might be a clue. The MPSAFE changes I
made to pccbb just move up the tree one level where the Giant lock is
taken out in this case.
If the failure is early enough in the process, you might want to put
printfs into pccbb_intr to see if they will show you what they tell
you the order of the first few interrupts for the card are. maybe
we're having a race with some interrupt before ep is really ready to
field interrupts or something that the giant lock being held before
protected against...
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030709.120807.103131596.imp>