Re: Bug#590327: linux-image-2.6.32-5-amd64: Unbalanced enable for IRQ 19

Re: Bug#590327: linux-image-2.6.32-5-amd64: Unbalanced enable for IRQ 19

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 1796 bytes --]

Jan Echternach reported that on his system it8213 provokes the warning
"Unbalanced enable for IRQ 19" when probed at boot time.

The previous messages are logged at <http://bugs.debian.org/590327>.

On Sun, 2011-07-31 at 20:49 +0200, Jan Echternach wrote:
> On Fri, Jul 29, 2011 at 05:18:48PM +0200, Moritz Mühlenhoff wrote:
> > Does this still occur with current kernels?
> 
> Yes.  Here's a warning from kernel version 3.0.0-1:
> 
> [    1.984004] ------------[ cut here ]------------
> [    1.984009] WARNING: at /build/buildd-linux-2.6_3.0.0-1-i386-ML66CU/linux-2.6-3.0.0/debian/build/source_i386_none/kernel/irq/manage.c:421 enable_irq+0x50/0x69()
> [    1.984011] Hardware name: EP45T-EXTREME
> [    1.984012] Unbalanced enable for IRQ 19
[...]

In the the list of PCI devices in the original report, I see:

> 00:1d.1 USB Controller [0c03]: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #2 [8086:3a35] (prog-if 00 [UHCI])
[...]
> 	Interrupt: pin B routed to IRQ 19
[...]
> 05:07.0 IDE interface [0101]: Integrated Technology Express, Inc. IT8213 IDE Controller [1283:8213] (prog-if 85 [Master SecO PriO])
[...]
> 	Interrupt: pin A routed to IRQ 19

This is somewhat unusual in that the IDE controller will be sharing its
IRQ, but that's supposed to work.

However, the IDE core attempts to disable and enable the IRQ *before* it
allocates it.  If the UHCI driver then allocates the IRQ in the middle
of this, the IRQ manager will reset the disable count since the IRQ is
not yet shared!

This might be fixable by changing the IDE core to allocate the IRQ with
a dummy interrupt handler while probing.

Aside from that, maybe pata_it8213 is ready as a replacement for it8213
now?  (Kconfig still labels it as EXPERIMENTAL.)

Ben.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: Bug#590327: linux-image-2.6.32-5-amd64: Unbalanced enable for IRQ 19

[David Miller]

From: Ben Hutchings <ben@decadent.org.uk>
Date: Wed, 07 Sep 2011 05:16:01 +0100

> This is somewhat unusual in that the IDE controller will be sharing its
> IRQ, but that's supposed to work.
> 
> However, the IDE core attempts to disable and enable the IRQ *before* it
> allocates it.  If the UHCI driver then allocates the IRQ in the middle
> of this, the IRQ manager will reset the disable count since the IRQ is
> not yet shared!
> 
> This might be fixable by changing the IDE core to allocate the IRQ with
> a dummy interrupt handler while probing.
> 
> Aside from that, maybe pata_it8213 is ready as a replacement for it8213
> now?  (Kconfig still labels it as EXPERIMENTAL.)

I've known about this IDE layer problem for at least a year and any
fix is too risky to consider seriously.

Use the PATA drivers on modern systems, don't use the deprecated IDE
layer.

Re: Bug#590327: linux-image-2.6.32-5-amd64: Unbalanced enable for IRQ 19

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 1781 bytes --]

On Wed, 2011-09-07 at 00:39 -0400, David Miller wrote:
> From: Ben Hutchings <ben@decadent.org.uk>
> Date: Wed, 07 Sep 2011 05:16:01 +0100
> 
> > This is somewhat unusual in that the IDE controller will be sharing its
> > IRQ, but that's supposed to work.
> > 
> > However, the IDE core attempts to disable and enable the IRQ *before* it
> > allocates it.  If the UHCI driver then allocates the IRQ in the middle
> > of this, the IRQ manager will reset the disable count since the IRQ is
> > not yet shared!
> > 
> > This might be fixable by changing the IDE core to allocate the IRQ with
> > a dummy interrupt handler while probing.
> > 
> > Aside from that, maybe pata_it8213 is ready as a replacement for it8213
> > now?  (Kconfig still labels it as EXPERIMENTAL.)
> 
> I've known about this IDE layer problem for at least a year and any
> fix is too risky to consider seriously.

I had a suspicion that was the case.

> Use the PATA drivers on modern systems, don't use the deprecated IDE
> layer.

Well, I'm concerned with what to do in distro configurations which
aren't just for 'modern systems'.  We already swapped over all the
drivers not labelled as experimental.  With the rest, I worry that we'd
be exchanging obscure IDE drivers that mostly work for obscure libata
drivers that have had little if any testing.  That strikes me as being
even more risky for the users with the old controllers.

I suppose that for those controllers where the libata driver is
experimental we could build both drivers, blacklist the IDE drivers and
let people override that if necessary.  (And hope that most of the bugs
get shaken out of the libata drivers before we do a stable release,
because that is too ugly to keep doing for long.)

Ben.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: Bug#590327: linux-image-2.6.32-5-amd64: Unbalanced enable for IRQ 19

[David Miller]

From: Ben Hutchings <ben@decadent.org.uk>
Date: Wed, 07 Sep 2011 05:58:33 +0100

> Well, I'm concerned with what to do in distro configurations which
> aren't just for 'modern systems'.  We already swapped over all the
> drivers not labelled as experimental.  With the rest, I worry that we'd
> be exchanging obscure IDE drivers that mostly work for obscure libata
> drivers that have had little if any testing.  That strikes me as being
> even more risky for the users with the old controllers.
> 
> I suppose that for those controllers where the libata driver is
> experimental we could build both drivers, blacklist the IDE drivers and
> let people override that if necessary.  (And hope that most of the bugs
> get shaken out of the libata drivers before we do a stable release,
> because that is too ugly to keep doing for long.)

But for the cases these bugs are hitting these are systems the old
drivers never could have worked on, because of the IRQ sharing issue
with things like USB controllers.

I think your blacklisting idea probably makes the most sense.