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] NR_PIRQS vs. NR_IRQS

>>> Keir Fraser <keir.fraser@xxxxxxxxxxxxx> 14.11.08 09:00 >>>
>On 14/11/08 07:54, "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx> wrote:
>
>>>> I agree with keeping this naming distinction of course, although I think
>>>> allowing NR_IRQS > NR_VECTORS right now is not very useful. But maybe you
>>>> have a box in mind that needs it?
>>> 
>>> I had sent a mail a few days ago on this, where IBM was testing 96 CPU
>>> support (4-node system), and it crashing because of a PIRQ ending up in
>>> DYNIRQ space (kernel perspective), because there being 300+ IO-APIC
>>> pins. While the crash ought to be fixed with the subsequent patch, it's
>>> clear that none of the devices with an accumulated pin number greater
>>> than 255 will actually work on that system.
>> 
>> Oh dear. :-D
>
>Is fixing this actually any harder than just bumping NR_IRQS/NR_PIRQS in Xen
>and NR_PIRQS in Linux? Have IRQS and VECTORS got somehow accidentally tied
>together in Xen?

Unfortunately there was some mix-up. But I think I got this fixed (running
a NR_IRQS=1024 hypervisor at the moment). I'd prefer to submit these
patches only after your NR_PIRQS -> NR_IRQS change comes out of the
staging tree though, to make sure it applies (and works) correctly on top
of it.

>These parameters should probably be build-time configurable.

This too.

Jan


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