Jan Beulich
2006-Apr-07 09:00 UTC
[Xen-devel] noirqdebug_setup() in arch/i386/kernel/setup-xen.c
Can anyone explain why i386 calls noirqdebug_setup() unconditionally, while x86-64 doesn''t? I believe this is the reason why we have been seeing spurious interrupt reports only on 64-bits so far. What was this supposed to suppress originally? Is this still applicable? It would seem to me that hiding problems in this area is rather undesirable... Thanks, Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2006-Apr-07 09:59 UTC
Re: [Xen-devel] noirqdebug_setup() in arch/i386/kernel/setup-xen.c
On 7 Apr 2006, at 10:00, Jan Beulich wrote:> Can anyone explain why i386 calls noirqdebug_setup() unconditionally, > while x86-64 doesn''t? I believe this is the reason > why we have been seeing spurious interrupt reports only on 64-bits so > far. > > What was this supposed to suppress originally? Is this still > applicable? It would seem to me that hiding problems in > this area is rather undesirable...It''s disabled to handle the case where a shared IRQ line is shared across multiple driver domains. In that case, if one domain''s device is busy then both domains will get interrupt notifications, but the non-busy driver domain will think that it''s receiving spurious interrupts (since it doesn''t see IRQ_HANDLED from the busy device driver ISR, since it''s running in a different driver domain). The above scenario is reasonably rare, and especially if there are currently irq problems I think we should stop asserting noirqdebug automatically, at least for now in xen-unstable. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jan Beulich
2006-Apr-07 10:15 UTC
Re: [Xen-devel] noirqdebug_setup() in arch/i386/kernel/setup-xen.c
>>> Keir Fraser <Keir.Fraser@cl.cam.ac.uk> 07.04.06 11:59:51 >>> > >On 7 Apr 2006, at 10:00, Jan Beulich wrote: > >> Can anyone explain why i386 calls noirqdebug_setup() unconditionally, >> while x86-64 doesn''t? I believe this is the reason >> why we have been seeing spurious interrupt reports only on 64-bits so >> far. >> >> What was this supposed to suppress originally? Is this still >> applicable? It would seem to me that hiding problems in >> this area is rather undesirable... > >It''s disabled to handle the case where a shared IRQ line is shared >across multiple driver domains. In that case, if one domain''s device is >busy then both domains will get interrupt notifications, but the >non-busy driver domain will think that it''s receiving spurious >interrupts (since it doesn''t see IRQ_HANDLED from the busy device >driver ISR, since it''s running in a different driver domain).Then, once we are able to figure the interrupt problems we currently have, this should probably be re-enabled temporarily and for *all* architectures, but be replaced by proper logic (i.e. Xen informing the domain e.g. by means of a flag passed with the injected IRQ that it should expect the interrupt to not getting handled; Xen should then also expect some notification back from the domain that the IRQ was handled, so it can combine this from all involved domains and still report and act on problems similar to the way Linux does). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2006-Apr-07 11:16 UTC
Re: [Xen-devel] noirqdebug_setup() in arch/i386/kernel/setup-xen.c
On 7 Apr 2006, at 11:15, Jan Beulich wrote:> Then, once we are able to figure the interrupt problems we currently > have, this should probably be re-enabled > temporarily and for *all* architectures, but be replaced by proper > logic (i.e. Xen informing the domain e.g. by means of > a flag passed with the injected IRQ that it should expect the > interrupt to not getting handled; Xen should then also > expect some notification back from the domain that the IRQ was > handled, so it can combine this from all involved domains > and still report and act on problems similar to the way Linux does).That would be better, yes. :-) -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel