Date: Sat, 21 Apr 2012 01:50:07 +0100 From: Attilio Rao <attilio@freebsd.org> To: Arnaud Lacombe <lacombar@gmail.com> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org>, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: Disabling an arbitrary device Message-ID: <CAJ-FndDKTzsg2X1sAA%2Bw1%2BniCRsc_pN6DLg6MXfX%2BpMZteNPrA@mail.gmail.com> In-Reply-To: <CACqU3MXrORmEvdQsudG9sJvX2sj2=haZQ2QNxz%2Btfys4PsxA-Q@mail.gmail.com> References: <CACqU3MWa%2BMxR_uHcOYd4qPFsPLV0acOhTAPLU6whBjw6N_muxg@mail.gmail.com> <CACqU3MXrORmEvdQsudG9sJvX2sj2=haZQ2QNxz%2Btfys4PsxA-Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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> 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(). When you have a tested patch against -CURRENT, can you please send to freebsd-newbus@? 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? Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-FndDKTzsg2X1sAA%2Bw1%2BniCRsc_pN6DLg6MXfX%2BpMZteNPrA>