Date: Tue, 31 Jan 2006 20:42:44 +0100 From: Juergen Lock <nox@jelal.kn-bremen.de> To: Ian Dowse <iedowse@iedowse.com> Cc: freebsd-usb@freebsd.org Subject: Re: cvs commit: src/sys/dev/usb ehci.c ehci_pci.c ehcivar.h Message-ID: <20060131194244.GA75983@saturn.kn-bremen.de> In-Reply-To: <20060131182045.GA47403@saturn.kn-bremen.de> References: <20060130223413.GA11711@saturn.kn-bremen.de> <200601310112.aa34663@nowhere.iedowse.com> <20060131182045.GA47403@saturn.kn-bremen.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jan 31, 2006 at 07:20:46PM +0100, Juergen Lock wrote: > On Tue, Jan 31, 2006 at 01:12:35AM +0000, Ian Dowse wrote: > > In message <20060130223413.GA11711@saturn.kn-bremen.de>, Juergen Lock writes: > > > Alright, here comes that: > > > > > intr_context = 3, > > > > Interesting - this actually suggests that two threads might be in > > the the interrupt service routine at the same time, which should > > not be possible unless there is a bug causing a callback to sleep. > > > > Could you see if you can find the EHCI interrupt thread in the output of: > > > > ps -axl -M vmcore -N kernel | grep irq > > > > It might show up like "[irq3: ehci" but if there are other interrupts > > shared with it you might need to look through dmesg output to find the > > IRQ number used by ehci and then look for that thread instead. > > Had to look at dmesg, ehci is sharing irq 11 with the promise sata > card and the symbios scsi card. > > > > Then from gdb, use 'info threads' to find the gdb thread ID for it > > (look for the PID=XX then read the first column). Finally, "thread > > TID" followed by "bt" should show what that thread is doing. e.g. > > if you see > > > > 7 Thread 100002 (PID=14: irq3: ehci0) 0xc050bb23 in ... > > > > then use "thread 7" and "bt". > > Alright, looks like it was paging: (usb_block_allocmem ending up > calling contigmalloc... which makes me wonder what would happen > there if someone had swap on a umass device? swap here is on > ad4s2b which is on the sata card.) Ah, seems the actual problem is that it is sleeping although bus_dmamem_alloc is called with BUS_DMA_NOWAIT, and there even is a pr for that: http://www.freebsd.org/cgi/query-pr.cgi?pr=78179 The pr is still open so i guess there is no fix yet?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060131194244.GA75983>