Re: Disabling an arbitrary device

Hi,

On Fri, Apr 20, 2012 at 8:50 PM, Attilio Rao <attilio_at_freebsd.org> wrote:
> Il 20 aprile 2012 19:18, Arnaud Lacombe <lacombar_at_gmail.com> ha scritto:
>> Hi,
>>
>> On Fri, Apr 20, 2012 at 2:16 PM, Arnaud Lacombe <lacombar_at_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_at_?
>
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