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?

Perhaps not, but I only started checking (on the Xen side - the kernel side
has no issues, already bumped the value there). I'll continue as time permits.

>These parameters should probably be build-time configurable.

That'd certainly be nice for NR_IRQS (it seems we agreed to get rid of
NR_PIRQS). I can't the same being valid for NR_VECTORS, though.

Jan


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