cvs commit: src/sys/dev/usb ehci.c ehci_pci.c ehcivar.h

[Juergen Lock]

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 at 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?