Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 21 Apr 2012 04:17:00 -0400
From:      Arnaud Lacombe <lacombar@gmail.com>
To:        Attilio Rao <attilio@freebsd.org>
Cc:        FreeBSD Hackers <freebsd-hackers@freebsd.org>, FreeBSD Current <freebsd-current@freebsd.org>
Subject:   Re: Disabling an arbitrary device
Message-ID:  <CACqU3MX%2Bgbftz7QXXSFVXgZahJ1UFj9cD=PLPgy8-v-pjr54gw@mail.gmail.com>
In-Reply-To: <CAJ-FndDKTzsg2X1sAA%2Bw1%2BniCRsc_pN6DLg6MXfX%2BpMZteNPrA@mail.gmail.com>
References:  <CACqU3MWa%2BMxR_uHcOYd4qPFsPLV0acOhTAPLU6whBjw6N_muxg@mail.gmail.com> <CACqU3MXrORmEvdQsudG9sJvX2sj2=haZQ2QNxz%2Btfys4PsxA-Q@mail.gmail.com> <CAJ-FndDKTzsg2X1sAA%2Bw1%2BniCRsc_pN6DLg6MXfX%2BpMZteNPrA@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Hi,

On Fri, Apr 20, 2012 at 8:50 PM, Attilio Rao <attilio@freebsd.org> wrote:
> Il 20 aprile 2012 19:18, Arnaud Lacombe <lacombar@gmail.com> ha scritto:
>> Hi,
>>
>> On Fri, Apr 20, 2012 at 2:16 PM, Arnaud Lacombe <lacombar@gmail.com> wro=
te:
>>> 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 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0total =A0 =
=A0 =A0 rate
>>> irq4: sio0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A01328 =A0 =
=A0 =A0 =A0 =A02
>>> irq19: uhci1+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 63514509 =A0 =A0 =A09=
6380
>>> [...]
>>>
>>> generating useless load on one CPU:
>>>
>>> # top -SH
>>> last pid: =A05223; =A0load averages: =A00.00, =A00.00, =A00.00 =A0 =A0u=
p 0+00:17:21 =A013:10:35
>>> 117 processes: 14 running, 79 sleeping, 24 waiting
>>> CPU: =A00.2% user, =A00.0% nice, =A00.2% system, =A06.6% interrupt, 93.=
0% idle
>>> Mem: 33M Active, 9348K Inact, 67M Wired, 400K Cache, 29M Buf, 2892M Fre=
e
>>> [...]
>>> =A0 57 root =A0 =A0 =A0 =A0 =A0-64 =A0 =A0- =A0 =A0 0K =A0 =A0 8K CPU0 =
=A0 0 =A011:59 86.57% irq19: uhci1+
>>>
>>> I thought I could use an hint to forbid uhci(4) attachment, ala:
>>>
>>> hint.uhci.0.disabled=3D"1"
>>> hint.uhci.1.disabled=3D"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/30786d09b0cb441890cdc749ee524=
3238e81d2d8
>
> 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACqU3MX%2Bgbftz7QXXSFVXgZahJ1UFj9cD=PLPgy8-v-pjr54gw>