All of lore.kernel.org
 help / color / mirror / Atom feed
From: Keir Fraser <keir.fraser@eu.citrix.com>
To: John McCullough <jmccullo@cs.ucsd.edu>
Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>,
	Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Yuvraj Agarwal <yuvraj@cs.ucsd.edu>
Subject: Re: XEN 4.0 + 2.6.31.13 pvops kernel : system crashes on starting 155th domU
Date: Wed, 28 Apr 2010 04:53:54 +0100	[thread overview]
Message-ID: <C7FD6FE2.10D9D%keir.fraser@eu.citrix.com> (raw)
In-Reply-To: <4BD7DA02.3030107@cs.ucsd.edu>

Cc'ing Ian and Jeremy -- one of them should be able to answer definitively
on this. I'm *pretty* sure there's an easy way to bump the irq limit you're
hitting, on the pv_ops kernels, but 'nr_irqs=' on dom0 cmdline clearly isn't
it as it had no effect at all!

 -- Keir

On 28/04/2010 07:47, "John McCullough" <jmccullo@cs.ucsd.edu> wrote:

> I did a little testing.
> 
> With no kernel option:
> # dmesg | grep -i nr_irqs
> [    0.000000] nr_irqs_gsi: 88
> [    0.000000] NR_IRQS:4352 nr_irqs:256
> 
> w/nr_irqs=65536:
> # dmesg | grep -i nr_irqs
> [    0.000000] Command line: root=/dev/sda1 ro quiet console=hvc0
> nr_irqs=65536
> [    0.000000] nr_irqs_gsi: 88
> [    0.000000] Kernel command line: root=/dev/sda1 ro quiet console=hvc0
> nr_irqs=65536
> [    0.000000] NR_IRQS:4352 nr_irqs:256
> 
> tweaking the NR_IRQS macro in the kernel will change the NR_IRQS output,
> but unfortunately that doesn't change nr_irqs and I run into the same
> limit (36 domus on a less-beefy dual core machine).
> 
> I did find this:
> http://blogs.sun.com/fvdl/entry/a_million_vms
> which references NR_DYNIRQS, which is in 2.6.18, but not in the pvops
> kernel.
> 
> Watching /proc/interrupts, the domain irqs seem to be getting allocated
> from 248 downward until they hit some other limit:
> ...
>   64:      59104  xen-pirq-ioapic-level  ioc0
>   89:          1   xen-dyn-event     evtchn:xenconsoled
>   90:          1   xen-dyn-event     evtchn:xenstored
>   91:          6   xen-dyn-event     vif36.0
>   92:        140   xen-dyn-event     blkif-backend
>   93:         97   xen-dyn-event     evtchn:xenconsoled
>   94:        139   xen-dyn-event     evtchn:xenstored
>   95:          7   xen-dyn-event     vif35.0
>   96:        301   xen-dyn-event     blkif-backend
>   97:        261   xen-dyn-event     evtchn:xenconsoled
>   98:        145   xen-dyn-event     evtchn:xenstored
>   99:          7   xen-dyn-event     vif34.0
> ...
> Perhaps the xen irqs are getting allocated out of the nr_irqs pool,
> while they could be allocated from the NR_IRQS pool?
> 
> -John
> 
> 
> 
> 
> On 04/27/2010 08:45 PM, Keir Fraser wrote:
>> I think nr_irqs is specifiable on the command line on newer kernels. You may
>> be able to do nr_irqs=65536 as a kernel boot parameter, or something like
>> that, without needing to rebuild the kernel.
>> 
>>   -- Keir
>> 
>> On 28/04/2010 02:02, "Yuvraj Agarwal"<yuvraj@cs.ucsd.edu>  wrote:
>> 
>>    
>>> Actually, I did identify the problem (don’t know the fix) at least from
>>> the console logs. Its related to running out of nr_irq's  (attached JPG
>>> for the console log).
>>> 
>>> 
>>> -----Original Message-----
>>> From: xen-devel-bounces@lists.xensource.com
>>> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Keir Fraser
>>> Sent: Tuesday, April 27, 2010 5:44 PM
>>> To: Yuvraj Agarwal; xen-devel@lists.xensource.com
>>> Subject: Re: [Xen-devel] XEN 4.0 + 2.6.31.13 pvops kernel : system crashes
>>> on starting 155th domU
>>> 
>>> On 27/04/2010 08:41, "Yuvraj Agarwal"<yuvraj@cs.ucsd.edu>  wrote:
>>> 
>>>      
>>>> Attached is the output of /var/log/daemon.log and /var/log/xen/xend.log,
>>>>        
>>> but
>>>      
>>>> as far as we can see we don¹t quite know what might be going causing the
>>>> system to crash (no console access anymore and system becomes
>>>>        
>>> unresponsive and
>>>      
>>>> needs to be power-cycled).  I have pasted only the relevant bits of
>>>> information (the last domU that did successfully start and the next one
>>>>        
>>> that
>>>      
>>>> failed). It may be the case that all the log messages weren¹t flushed
>>>>        
>>> before
>>>      
>>>> the system crashedŠ
>>>> 
>>>> Does anyone know where this limit of 155 domU is coming from and how we
>>>>        
>>> can
>>>      
>>>> fix/increase it?
>>>>        
>>> Get a serial line on a test box, and capture Xen logging output on it. You
>>> can both see if any crash messages come from Xen when the 155th domain is
>>> created, and also try the serial debug keys (e.g., try 'h' to get help to
>>> start with) to see whether Xen itself is still alive.
>>> 
>>>   -- Keir
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com
>>> http://lists.xensource.com/xen-devel
>>>      
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>>    
> 

  reply	other threads:[~2010-04-28  3:53 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-27  7:41 XEN 4.0 + 2.6.31.13 pvops kernel : system crashes on starting 155th domU Yuvraj Agarwal
2010-04-27  9:02 ` Pasi Kärkkäinen
2010-04-27 17:14   ` Yuvraj Agarwal
2010-04-27 17:18     ` Pasi Kärkkäinen
2010-04-27 18:58       ` Yuvraj Agarwal
2010-04-27 19:29         ` Pasi Kärkkäinen
2010-04-27 13:59 ` Konrad Rzeszutek Wilk
2010-04-27 17:18   ` Yuvraj Agarwal
2010-04-27 18:51 ` Jeremy Fitzhardinge
2010-04-27 19:10   ` Yuvraj Agarwal
2010-04-27 19:27     ` Jeremy Fitzhardinge
2010-04-27 19:38       ` Yuvraj Agarwal
2010-04-28  0:43 ` Keir Fraser
2010-04-28  1:02   ` Yuvraj Agarwal
2010-04-28  3:45     ` Keir Fraser
2010-04-28  6:47       ` John McCullough
2010-04-28  3:53         ` Keir Fraser [this message]
2010-04-28 14:04         ` Konrad Rzeszutek Wilk
2010-04-28 16:57           ` Ian Campbell
2010-04-28 18:18             ` Jeremy Fitzhardinge
2010-04-28 22:51           ` Yuvraj Agarwal
2010-04-29 14:56             ` Konrad Rzeszutek Wilk
2010-04-30  3:12               ` Yuvraj Agarwal
2010-04-28 18:13         ` Jeremy Fitzhardinge

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=C7FD6FE2.10D9D%keir.fraser@eu.citrix.com \
    --to=keir.fraser@eu.citrix.com \
    --cc=Ian.Campbell@eu.citrix.com \
    --cc=jeremy@goop.org \
    --cc=jmccullo@cs.ucsd.edu \
    --cc=xen-devel@lists.xensource.com \
    --cc=yuvraj@cs.ucsd.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.