Date: Sat, 9 Jul 2011 09:40:10 GMT From: Hans Petter Selasky <hselasky@c2i.net> To: freebsd-usb@FreeBSD.org Subject: Re: usb/156596: [ehci] Extremely high interrupt rate on ehci/uhci IRQ16 80% cpu utilization on CPU0 Message-ID: <201107090940.p699eAdQ017546@freefall.freebsd.org>
index | next in thread | raw e-mail
The following reply was made to PR usb/156596; it has been noted by GNATS. From: Hans Petter Selasky <hselasky@c2i.net> To: Colin Percival <cperciva@freebsd.org> Cc: "bug-followup@FreeBSD.org" <bug-followup@freebsd.org> Subject: Re: usb/156596: [ehci] Extremely high interrupt rate on ehci/uhci IRQ16 80% cpu utilization on CPU0 Date: Sat, 9 Jul 2011 11:33:40 +0200 On Saturday 09 July 2011 02:26:37 Colin Percival wrote: > Hi again, > > The attached patch seems to fix the problem while not breaking anything on > my laptop. It makes handles the case of EHCI_REMOVE_QH(sqh, last) with > sqh == last and sqh->prev == NULL by setting last = NULL -- the idea being > that if sqh is the only entry in the queue, we still ought to delete it > even though it doesn't have a predecessor. > > I have no idea if this is correct, since I don't know the rest of the code > in this file. Maybe we should also delete the first entry in a queue even > when it isn't also the last entry; maybe the problem lies somewhere else > entirely. I'm hoping that someone who knows this code will be able to > figure out the right fix easily now that I have an apparently-working > hack. Hi, The last element should always be there. If it is NULL I would like to see a backtrace from that. KASSERT(last != NULL) in both add and remove. If you clear that the USB queue will stop working I believe. Anyway, I think your clue might give some hints what is wrong. It appears that the EHCI is spinning on the IDLE queue somehow producing a lot of IRQ's. --HPShome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201107090940.p699eAdQ017546>