Date: Tue, 21 Oct 2003 17:28:41 +0200 From: Andrea Campi <andrea@webcom.it> To: "M. Warner Losh" <imp@bsdimp.com> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/ep if_ep.c if_ep_isa.c if_ep_pccard.c if_epreg.h if_epvar.h Message-ID: <20031021152841.GA899@webcom.it> In-Reply-To: <20031021.083720.19538611.imp@bsdimp.com> References: <200310181522.h9IFMhrS025003@repoman.freebsd.org> <20031021074238.GA1182@webcom.it> <20031021.083720.19538611.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Oct 21, 2003 at 08:37:20AM -0600, M. Warner Losh wrote:
> : I am quite sure it's this group of commits, as I cvsup'ed immediately
> : before and immediately after in order to verify this.
>
> I'm pretty sure it is too. Some others have reported this, but I've
> not seen it on my machine. I'm rebuilding and trying again with a
> wider selection of cards today. I'd tested it on two different pcmcia
> cards before the commit, but I saw no issues at all.
Ok, please let me know if you have anything I can test, or if you need
any more info.
> Hmmm. I've not seen this, but others have. I've done buildworlds
> over nfs even. So it may be related to other interrupts on that same
> irq. i say related, not to point fingers, but to try to understand
> how the 'deadlocks' appear to happen. I'm suspecting a giant leak of
Uhm. Nice idea, I might try putting a printf, a breakpoint or something in
other handlers on the same IRQ. I do have:
pcib0: slot 5 INTA is routed to irq 11
pcib0: slot 6 INTD is routed to irq 11
pcib0: slot 7 INTA is routed to irq 11
pcib0: slot 2 INTA is routed to irq 11
pcib0: slot 2 INTB is routed to irq 11
uhci0: <Intel 82371AB/EB (PIIX4) USB controller> port 0x1820-0x183f irq 11 at device 6.2 on pci0
wi0: <NETGEAR MA401RA Wireless PC Card> at port 0x100-0x13f irq 11 function 0 config 1 on pccard0
ep0: <3Com Corporation 3C589D> at port 0x140-0x14f irq 11 function 0 config 1 on pccard1
Even though no other device is in use at the time that happens, it might
be worth triple checking this. The wi0 looks suspicious, I know, but the
same happened before I bought it, so a conflict there would be, erm,
unlikely... ;-)
> some kind, but haven't been able to track it down. The real solution
> is, of course, to lock ep, ed, sn, and all the other drivers that have
> issues similar.
Yep. Until that happens, however, it might be good to have a tunable
or a sysctl to turn off MPSAFE-ness of pccbb, for those affected. I'm
sure I could come up with a patch, but I'm also sure it would take
somebody with more clue than I have less than 5 minutes to write and
commit... Not implying that should be you, I swear ;-)
Bye,
Andrea
--
Intel: where Quality is job number 0.9998782345!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031021152841.GA899>