From owner-cvs-src@FreeBSD.ORG Tue Oct 21 08:28:43 2003 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F0D2816A4B3; Tue, 21 Oct 2003 08:28:43 -0700 (PDT) Received: from brian.webcom.it (brianlap.inet.it [213.92.1.190]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA54043F75; Tue, 21 Oct 2003 08:28:42 -0700 (PDT) (envelope-from andrea@webcom.it) Received: by brian.webcom.it (Postfix, from userid 1000) id B7190F; Tue, 21 Oct 2003 17:28:41 +0200 (CEST) Date: Tue, 21 Oct 2003 17:28:41 +0200 From: Andrea Campi To: "M. Warner Losh" Message-ID: <20031021152841.GA899@webcom.it> References: <200310181522.h9IFMhrS025003@repoman.freebsd.org> <20031021074238.GA1182@webcom.it> <20031021.083720.19538611.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031021.083720.19538611.imp@bsdimp.com> X-Echelon: BND CIA NSA Mossad KGB MI6 IRA detonator nuclear assault strike User-Agent: Mutt/1.5.4i cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org 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 X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2003 15:28:44 -0000 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: port 0x1820-0x183f irq 11 at device 6.2 on pci0 wi0: 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!