Hi, On Fri, Apr 20, 2012 at 8:50 PM, Attilio Rao <atti...@freebsd.org> wrote: > Il 20 aprile 2012 19:18, Arnaud Lacombe <lacom...@gmail.com> ha scritto: >> Hi, >> >> On Fri, Apr 20, 2012 at 2:16 PM, Arnaud Lacombe <lacom...@gmail.com> wrote: >>> Hi, >>> >>> I will be bringing up an old thread there, but it would seem the >>> situation did not evolve in the past 9 years. I have a machine running >>> 7.1 whose UHCI controller is generating some interrupt storm: >>> >>> # vmstat -i >>> interrupt total rate >>> irq4: sio0 1328 2 >>> irq19: uhci1+ 63514509 96380 >>> [...] >>> >>> generating useless load on one CPU: >>> >>> # top -SH >>> last pid: 5223; load averages: 0.00, 0.00, 0.00 up 0+00:17:21 >>> 13:10:35 >>> 117 processes: 14 running, 79 sleeping, 24 waiting >>> CPU: 0.2% user, 0.0% nice, 0.2% system, 6.6% interrupt, 93.0% idle >>> Mem: 33M Active, 9348K Inact, 67M Wired, 400K Cache, 29M Buf, 2892M Free >>> [...] >>> 57 root -64 - 0K 8K CPU0 0 11:59 86.57% irq19: >>> uhci1+ >>> >>> I thought I could use an hint to forbid uhci(4) attachment, ala: >>> >>> hint.uhci.0.disabled="1" >>> hint.uhci.1.disabled="1" >>> >>> in /boot/loader.conf. However, it would seem that what should be >>> usable with any arbitrary devices, ie. be an integral part of >>> device(9), has to be hardcoded in every driver, sad. >>> >> as for the usual "if you're not happy, please provide a patch": >> >> https://github.com/lacombar/freebsd/commit/30786d09b0cb441890cdc749ee5243238e81d2d8 > > I think a generalized kludge should really belong to > device_probe_child() rather than device_add_child_ordered(). > suit me.
> When you have a tested patch against -CURRENT, can you please send to > freebsd-newbus@? > will give it a try, eventually. > BTW, IIRC 7.x doesn't have the new USB stack, which means that you can > have caught easilly a driver bug there, did you consider switching at > least to 8.x kernel? > That is unfortunately not a decision for me to make, though a switch to 9.x will be more likely. That said, it seems that it is not a USB specific issue, but an IRQ19's issue. I did not had a chance to investigate that further, but with uhci(4) disabled, atapci(4) is now IRQ-storming. This is a known issue relatively widely encountered, with various workarounds possible. - Arnaud _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"