More ata_piix spurious IRQs

More ata_piix spurious IRQs

[Ben Hutchings]

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

jeanseb reported this problem with a PATA PIIX controller:

> [    1.324685] irq 5: nobody cared (try booting with the "irqpoll" option)
> [    1.324730] Pid: 194, comm: scsi_eh_0 Not tainted 2.6.32-5-amd64 #1
> [    1.324732] Call Trace:
> [    1.324734]  <IRQ>  [<ffffffff810952cd>] ? __report_bad_irq+0x30/0x7d
> [    1.324745]  [<ffffffff8109541f>] ? note_interrupt+0x105/0x16e
> [    1.324749]  [<ffffffff81095b26>] ? handle_level_irq+0x80/0xc3
> [    1.324753]  [<ffffffff81013957>] ? handle_irq+0x17/0x1d
> [    1.324756]  [<ffffffff81012fb1>] ? do_IRQ+0x57/0xb6
> [    1.324759]  [<ffffffff810114d3>] ? ret_from_intr+0x0/0x11
> [    1.324762]  [<ffffffff81014fa3>] ? mask_and_ack_8259A+0x0/0xca
> [    1.324767]  [<ffffffff81053967>] ? __do_softirq+0x6e/0x19f
> [    1.324770]  [<ffffffff81011cac>] ? call_softirq+0x1c/0x30
> [    1.324773]  [<ffffffff81013903>] ? do_softirq+0x3f/0x7c
> [    1.324776]  [<ffffffff81053845>] ? irq_exit+0x36/0x76
> [    1.324779]  [<ffffffff81012ffa>] ? do_IRQ+0xa0/0xb6
> [    1.324782]  [<ffffffff810114d3>] ? ret_from_intr+0x0/0x11
> [    1.324784]  <EOI>  [<ffffffff812fa7f5>] ? _spin_unlock_irqrestore+0x8/0xe
> [    1.324798]  [<ffffffffa006bb64>] ? ata_exec_internal_sg+0x239/0x45b [libata]
> [    1.324802]  [<ffffffff8105a549>] ? del_timer_sync+0xc/0x16
> [    1.324807]  [<ffffffff811946c9>] ? delay_tsc+0x30/0x73
> [    1.324813]  [<ffffffffa006be09>] ? ata_exec_internal+0x83/0x92 [libata]
> [    1.324820]  [<ffffffffa007732c>] ? ata_sff_check_status+0x10/0x13 [libata]
> [    1.324827]  [<ffffffffa006c0d2>] ? ata_do_dev_read_id+0x21/0x23 [libata]
> [    1.324833]  [<ffffffffa006c1c8>] ? ata_dev_read_id+0xf4/0x3c2 [libata]
> [    1.324839]  [<ffffffffa007783c>] ? ata_sff_postreset+0x0/0x73 [libata]
> [    1.324846]  [<ffffffffa0074e1d>] ? ata_eh_schedule_probe+0xb3/0xe0 [libata]
> [    1.324852]  [<ffffffffa0075520>] ? ata_eh_recover+0x6d6/0xc2a [libata]
> [    1.324856]  [<ffffffff8103fe62>] ? update_curr+0xa6/0x147
> [    1.324862]  [<ffffffffa007783c>] ? ata_sff_postreset+0x0/0x73 [libata]
> [    1.324868]  [<ffffffffa007921c>] ? ata_sff_softreset+0x0/0x130 [libata]
> [    1.324873]  [<ffffffffa00d3578>] ? piix_pata_prereset+0x0/0x51 [ata_piix]
> [    1.324879]  [<ffffffffa007921c>] ? ata_sff_softreset+0x0/0x130 [libata]
> [    1.324885]  [<ffffffffa007783c>] ? ata_sff_postreset+0x0/0x73 [libata]
> [    1.324890]  [<ffffffffa007921c>] ? ata_sff_softreset+0x0/0x130 [libata]
> [    1.324894]  [<ffffffffa00d3578>] ? piix_pata_prereset+0x0/0x51 [ata_piix]
> [    1.324901]  [<ffffffffa0075bfc>] ? ata_do_eh+0x3b/0x82 [libata]
> [    1.324907]  [<ffffffffa007652b>] ? ata_scsi_error+0x342/0x67a [libata]
> [    1.324911]  [<ffffffff81047f57>] ? finish_task_switch+0x3a/0xa7
> [    1.324919]  [<ffffffffa00049dc>] ? scsi_error_handler+0x0/0x5b5 [scsi_mod]
> [    1.324925]  [<ffffffffa0004aea>] ? scsi_error_handler+0x10e/0x5b5 [scsi_mod]
> [    1.324931]  [<ffffffffa00049dc>] ? scsi_error_handler+0x0/0x5b5 [scsi_mod]
> [    1.324934]  [<ffffffff8106482d>] ? kthread+0x79/0x81
> [    1.324937]  [<ffffffff81011baa>] ? child_rip+0xa/0x20
> [    1.324940]  [<ffffffff810647b4>] ? kthread+0x0/0x81
> [    1.324943]  [<ffffffff81011ba0>] ? child_rip+0x0/0x20
> [    1.324944] handlers:
> [    1.324977] [<ffffffffa00d384e>] (piix_interrupt+0x0/0x192 [ata_piix])
> [    1.325076] Disabling IRQ #5
> [    1.347126] ata1.00: ATAPI: DVD-RW IDE1108, VER B018, max UDMA/66
> [    1.347150] ata1.00: limited to UDMA/33 due to 40-wire cable

(more details at <http://bugs.debian.org/585556>).

This is in Debian kernel version 2.6.32-15 which is based on stable
version 2.6.32.14 but has your backported spurious IRQ handling patch
taken from SLE11 (References: bnc#445872, bnc#589449).  Any idea what's
going wrong here?  Is there a piece missing from that fix?

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.

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

Re: More ata_piix spurious IRQs

[Tejun Heo]

Hello, Ben.

On 06/12/2010 01:13 AM, Ben Hutchings wrote:
> (more details at <http://bugs.debian.org/585556>).
> 
> This is in Debian kernel version 2.6.32-15 which is based on stable
> version 2.6.32.14 but has your backported spurious IRQ handling patch
> taken from SLE11 (References: bnc#445872, bnc#589449).  Any idea what's
> going wrong here?  Is there a piece missing from that fix?

One great thing about traditional IDE is that the IRQ line is not
really under the control of the controller so the device can assert
the IRQ whether the controller want or not and there's nothing much
the driver can do to prevent runaway IRQs if the device is crazy
enough (some devices seem to have problem with toggling nIEN for
example).  Ain't it just great?  :-)

As the spurious interrupt handling kicked in, the spurious interrupts
itself shouldn't cause problem.  It would be polling now, so it's
likely that the device is asserting interrupt and not responding to
commands properly.  Does the drive work in other environments?
e.g. Can the BIOS recognize it and boot from it?

Thanks.

-- 
tejun

Re: More ata_piix spurious IRQs

[jeanseb]

Hi,
the Drive is recognizes by bios and works (fine enough to install
debian).

thanks

Le Sat, 12 Jun 2010 19:33:09 +0200,
Tejun Heo <tj@kernel.org> a écrit :

> Hello, Ben.
> 
> On 06/12/2010 01:13 AM, Ben Hutchings wrote:
> > (more details at <http://bugs.debian.org/585556>).
> > 
> > This is in Debian kernel version 2.6.32-15 which is based on stable
> > version 2.6.32.14 but has your backported spurious IRQ handling
> > patch taken from SLE11 (References: bnc#445872, bnc#589449).  Any
> > idea what's going wrong here?  Is there a piece missing from that
> > fix?
> 
> One great thing about traditional IDE is that the IRQ line is not
> really under the control of the controller so the device can assert
> the IRQ whether the controller want or not and there's nothing much
> the driver can do to prevent runaway IRQs if the device is crazy
> enough (some devices seem to have problem with toggling nIEN for
> example).  Ain't it just great?  :-)
> 
> As the spurious interrupt handling kicked in, the spurious interrupts
> itself shouldn't cause problem.  It would be polling now, so it's
> likely that the device is asserting interrupt and not responding to
> commands properly.  Does the drive work in other environments?
> e.g. Can the BIOS d  it and boot from it?
> 
> Thanks.
> 

Re: Bug#585556: More ata_piix spurious IRQs

[maximilian attems]

On Sat, Jun 12, 2010 at 07:49:44PM +0200, jeanseb wrote:
> Hi,
> the Drive is recognizes by bios and works (fine enough to install
> debian).
> 
> thanks

could you post dmesg of install before reboot.
probably the installer still uses the old ide stack.

thanks

Re: More ata_piix spurious IRQs

[Ben Hutchings]

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

Le Sat, 12 Jun 2010 19:33:09 +0200,
Tejun Heo <tj@kernel.org> a écrit :

> Hello, Ben.
> 
> On 06/12/2010 01:13 AM, Ben Hutchings wrote:
> > (more details at <http://bugs.debian.org/585556>).
> > 
> > This is in Debian kernel version 2.6.32-15 which is based on stable
> > version 2.6.32.14 but has your backported spurious IRQ handling
> > patch taken from SLE11 (References: bnc#445872, bnc#589449).  Any
> > idea what's going wrong here?  Is there a piece missing from that
> > fix?
> 
> One great thing about traditional IDE is that the IRQ line is not
> really under the control of the controller so the device can assert
> the IRQ whether the controller want or not and there's nothing much
> the driver can do to prevent runaway IRQs if the device is crazy
> enough (some devices seem to have problem with toggling nIEN for
> example).  Ain't it just great?  :-)

I didn't realise that.  Of course it should be obvious, given that PATA
is based on extension of the ISA bus.

> As the spurious interrupt handling kicked in, the spurious interrupts
> itself shouldn't cause problem.  It would be polling now, so it's
> likely that the device is asserting interrupt and not responding to
> commands properly.  Does the drive work in other environments?
> e.g. Can the BIOS d  it and boot from it?

On Sat, 2010-06-12 at 19:49 +0200, jeanseb wrote:
> Hi,
> the Drive is recognizes by bios and works (fine enough to install
> debian).
 
But you originally complained that it was responding slowly.

It seems like this is really a hardware bug.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.

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