Re: [Xen-devel] irq 17: nobody cared (try booting with the "irqpoll" option)

[Hans-Christian Armingeon <mog.johnny@gmx.net>]

Hi,

thank you for your reply.

Well, irqpoll didn't fix it.

I switched to nonsmp in dom0.

I am doing dirty things: I export 2 USB controllers into a domU. I plugged an AVM FritzCard DSL USB into the domU. ANd I am sending faxes via capi4hylafax and hylafax. And things periodically break.

cat /proc/interrupts
[...]
 17:    1008938        Phys-irq  libata
[...]

The interesting thin is, that lsmod |grep ata says:
sata_sil               12424  0
libata                 67096  1 sata_sil
scsi_mod              156696  6 sg,sd_mod,3w_xxxx,aic79xx,scsi_transport_spi,libata

I have no harddisks plugged on the onboard sil S-ATA.
dmesg says

[...]
[    5.887645] SCSI subsystem initialized
[    5.893963] libata version 1.20 loaded.
[    5.894782] sata_sil 0000:03:05.0: version 0.9
[    5.894806] ACPI: PCI Interrupt 0000:03:05.0[A] -> GSI 19 (level, low) -> IRQ 17
[    5.901894] ata1: SATA max UDMA/100 cmd 0xFFFFC20000006C80 ctl 0xFFFFC20000006C8A bmdma 0xFFFFC20000006C00 irq 17
[    5.907356] ata2: SATA max UDMA/100 cmd 0xFFFFC20000006CC0 ctl 0xFFFFC20000006CCA bmdma 0xFFFFC20000006C08 irq 17
[    5.912833] ata3: SATA max UDMA/100 cmd 0xFFFFC20000006E80 ctl 0xFFFFC20000006E8A bmdma 0xFFFFC20000006E00 irq 17
[    5.918288] ata4: SATA max UDMA/100 cmd 0xFFFFC20000006EC0 ctl 0xFFFFC20000006ECA bmdma 0xFFFFC20000006E08 irq 17
[    6.124116] ata1: SATA link down (SStatus 0)
[    6.126847] scsi0 : sata_sil
[    6.328113] ata2: SATA link down (SStatus 0)
[    6.330829] scsi1 : sata_sil
[    6.532113] ata3: SATA link down (SStatus 0)
[    6.534839] scsi2 : sata_sil
[    6.736113] ata4: SATA link down (SStatus 0)
[    6.738813] scsi3 : sata_sil

Maybe, unloading of sata_sil fixes this problem?

But I would like to have a clean solution.

Rebooting without xen is no solution - this box is in a production environment.


[read on]

Am Sonntag, 4. Juni 2006 10:03 schrieb Keir Fraser:
> 
> On 3 Jun 2006, at 13:51, Hans-Christian Armingeon wrote:
> 
> > [ 1199.028108] irq 17: nobody cared (try booting with the "irqpoll" 
> > option)
> > [ 1199.031054]
> > [ 1199.031055] Call Trace: <IRQ> 
> > <ffffffff8014d754>{__report_bad_irq+48}
> > [ 1199.034294]        <ffffffff8014d9bc>{note_interrupt+539} 
> > <ffffffff8014d2ab>{__do_IRQ+190}
> > [ 1199.040504]        <ffffffff8010c934>{do_IRQ+62} 
> > <ffffffff802d0034>{evtchn_do_upcall+132}
> > [ 1199.046403]        <ffffffff8010b152>{do_hypervisor_callback+30} 
> > <EOI>
> > [ 1199.052363] handlers:
> > [ 1199.055141] [<ffffffff880354ab>] (ata_interrupt+0x0/0x166 [libata])
> > [ 1199.058267] Disabling IRQ #17
> >
> > So I rebooted with irqpoll option.
> >
> > Is this a bug, or what's the cause of this error message?
> 
> It's caused by receiving lots of spurious interrupts on that IRQ. If 
> you don't see similar on native then post boot output from Xen and 
> native Linux and we can look for differences.

What do you mean? dmesg? cat proc/interrupts ?

> 
>   -- Keir

Johnny