WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] radeon in dom0/ivtv in domU: irq 16 nobody cared

To: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Subject: Re: [Xen-devel] radeon in dom0/ivtv in domU: irq 16 nobody cared
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Thu, 08 Apr 2010 11:45:37 -0700
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Mark Hurenkamp <mark.hurenkamp@xxxxxxxxx>
Delivery-date: Thu, 08 Apr 2010 11:46:06 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20100408173700.GB26343@xxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <AEB83A1C-247E-4B52-AB14-977664379FDE@xxxxxxxxx> <20100408001916.GA10840@xxxxxxxxxxxxxxxxxxx> <20100408173700.GB26343@xxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.4
On 04/08/2010 10:37 AM, Konrad Rzeszutek Wilk wrote:
>> Yes,
>>
>> Please e-mail your full serial log output, your cat /proc/interrupts,
>> and 'lspci -vvv' output. This is to say, for both Dom0 and DomU.
>>     
> I think I am able to reproduce this with one device (in DomU) that shares the 
> IRQ
> (17) with another device that is in Dom0. In Dom0 I get:
>   

For the "nobody cared" message to trigger, then there must either have
been no interrupt handlers at all, or they all returned IRQ_NONE.

So in theory, if irq 17 has an active driver on it, then its irq handler
should see the interrupt, poke the device, go "huh, nothing for me to
do, must be a spurious interrupt from something else sharing the irq",
and I guess return IRQ_NONE.

So what stops this?  If the irq isn't being shared with anything in
dom0, we should be careful not even map the interrupt into dom0 (though
I suspect we only ever map, never unmap, interrupts).

But if the interrupt is being shared, I think we need a proxy interrupt
handler installed by pciback (pcistub?)to absorb apparently spurious
interrupts, which always returns IRQ_HANDLED (and perhaps have some of
its own screaming interrupt logic in case something has gone awry)?

Or if not that, what?  How has this problem been avoided before?


> -sh-3.1# 
> -sh-3.1# [ 2349.534294] irq 17: nobody cared (try booting with the
> "irqpoll" option)
> [ 2349.534477] Pid: 0, comm: swapper Not tainted 2Trace:
> [ 2349.534728]  <IRQ>  [<ffffffff810ea3c7>] __report_bad_irq+0x54/0xe2
> [ 2349.534887]  [<ffffffff810ea6a2>] note_interrupt+0x24d/0x2b8
> [ 2349.535019]  [<ffffffff810eb95d>] handle_level_irq+0xef/0x17b
> [ 2349.535151]  [<ffffffff81370257>] xen_evtchn_do_upcall+0x156/0x254
> [ 2349.535282]  [<ffffffff81017e7e>]
> xen_do_hypervisor_callback+0x1e/0x30
> [ 2349.535282]  <EOI>  [<ffffffff810093aa>] ?
> hypercall_page+0x3aa/0x1000
> [ 2349.535282]  [<ffffffff810093aa>] ? hypercall_page+0x3aa/0x1000
> [ 2349.535282]  [<ffffffff810093aa>] ? hypercall_page+0x3aa/0x1000
> [ 2349.535282]  [<ffffffff81010f3b>] ? xen_safe_halt+0x1e/0x3d
> [ 2349.535282]  [<ffffffff8100cb87>] ? xen_idle+0x10b/0x130
> [ 2349.535282]  [<ffffffff81015887>] ? cpu_idle+0x167/0x1d5
> [ 2349.535282]  [<ffffffff816641e1>] ? rest_init+0xb5/0xbe
> [ 2349.535282]  [<ffffffff81a447a5>] ? start_kernel+0x777/0x78a
> [ 2349.535282]  [<ffffffff81a43326>] ?
> x86_64_start_reservations+0x111/0x11c
> [ 2349.535282]  [<ffffffff81a48e25>] ? xen_start_kernel+0x678/0x686
> [ 2349.535282] handlers:
> [ 2349.535282] [<ffffffffa00c2420>] (lpfc_sli_intr_handler+0x0/0x22a
> [lpfc])
> [ 2349.535282] [<ffffffffa00240a5>] (tg3_interrupt_tagged+0x0/0xe6
> [tg3])
> [ 2349.535282] Disabling IRQ #17
> [ 2382.845061] lpfc 0000:05:04.0: 0:0459 Adapter heartbeat failure,
> taking this port offline.
> [ 2397.052375] device-mapper: multipath: Failing path 8:0.
> [ 2397.053041] ata3: lost interrupt (Status 0x50)
> [ 2397.053275] [ 2398.054372] device-mapper: multipath: Failing path
> 8:16.
> [ 2398.055179] ata4: lost interrupt (Status 0x50)
> [ 2398.055413][ 2447.701115] ata3: lost interrupt (Status 0x50)
> [ 2447.701389] sd 2:0:0:0: [sda] Unhandled error code
> [ 2447.701515] sd 2:0
>
>
> .. and it also kills the ata_piix controller which is not on the same
> IRQ (??)
>   

That's very strange, but I suspect there's a lot of mysterious magic
around piix ide controller interrupts relating to backwards compat, etc.

    J

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel