Re: [Xen-changelog] Fix VCPU locking in sched_adjdom for multi-VCPU guests

Re: [Xen-changelog] Fix VCPU locking in sched_adjdom for multi-VCPU guests

[Matt Ayres]

Does this commit in way way affect bug id # 502?

Re: Re: [Xen-changelog] Fix VCPU locking in sched_adjdom for multi-VCPU guests

[Keir Fraser]

No chance. But noone will be able to tell what BUG you are talking 
about, since you provide many attachments but no output from the BUGing 
kernel.

  -- Keir

On 31 Jan 2006, at 20:30, Matt Ayres wrote:

> Does this commit in way way affect bug id # 502?
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: Re: [Xen-changelog] Fix VCPU locking in sched_adjdom for multi-VCPU guests

[Matt Ayres]

<puts on dunce hat>

I've created a comment with the BUG. I remember I was going to have 
xen-bugtool include /var/log/messages, but later decided I didn't want 
so many system details put out in public.

Thank you,
Matt Ayres

Keir Fraser wrote:
> 
> No chance. But noone will be able to tell what BUG you are talking 
> about, since you provide many attachments but no output from the BUGing 
> kernel.
> 
>  -- Keir
> 
> On 31 Jan 2006, at 20:30, Matt Ayres wrote:
> 
>> Does this commit in way way affect bug id # 502?
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
> 

Re: Re: [Xen-changelog] Fix VCPU locking in sched_adjdom for multi-VCPU guests

[Keir Fraser]

On 31 Jan 2006, at 22:42, Matt Ayres wrote:

> <puts on dunce hat>
>
> I've created a comment with the BUG. I remember I was going to have 
> xen-bugtool include /var/log/messages, but later decided I didn't want 
> so many system details put out in public.

How tight on memory are you running the system? The BUG is probably 
happening because the guest is failing to allocate a page of memory 
below 4GB. Since Xen tries to give out memory below 4GB last, that 
probably means there is very little available memory.

Obviously we need a better fallback strategy than BUG(). :-)

  -- Keir

Re: Linux 2.6 guest BUG(). (was: Re: Re: [Xen-changelog] Fix VCPU locking in sched_adjdom for multi-VCPU guests)

[Matt Ayres]

Keir Fraser wrote:
> 
> On 31 Jan 2006, at 22:42, Matt Ayres wrote:
> 
>> <puts on dunce hat>
>>
>> I've created a comment with the BUG. I remember I was going to have 
>> xen-bugtool include /var/log/messages, but later decided I didn't want 
>> so many system details put out in public.
> 
> How tight on memory are you running the system? The BUG is probably 
> happening because the guest is failing to allocate a page of memory 
> below 4GB. Since Xen tries to give out memory below 4GB last, that 
> probably means there is very little available memory.
>

I can provide dozens of BUG()'s if required.  It just happened again on 
a host in dom0 to the sshd daemon and now that port is locked (netstat 
-nlp reports "-" as the process name).  I am able to access the server 
via the console.

I assume you mean Xen's memory usage. I am showing 141MB free out of 
8112MB total.  Our scripts to add accounts don't allow adding more 
accounts then there is memory for, we actually leave about 128MB as a 
buffer.

> Obviously we need a better fallback strategy than BUG(). :-)
> 

Alright captain, what do I need to do on my end? Grepping 
/var/log/messages for "syscall" grants about 20+ results so something is 
going very wrong.

Thank you,
Matt Ayres

Re: Linux 2.6 guest BUG(). (was: Re: Re: [Xen-changelog] Fix VCPU locking in sched_adjdom for multi-VCPU guests)

[Keir Fraser]

On 1 Feb 2006, at 16:08, Matt Ayres wrote:

> I can provide dozens of BUG()'s if required.  It just happened again 
> on a host in dom0 to the sshd daemon and now that port is locked 
> (netstat -nlp reports "-" as the process name).  I am able to access 
> the server via the console.
>
> I assume you mean Xen's memory usage. I am showing 141MB free out of 
> 8112MB total.  Our scripts to add accounts don't allow adding more 
> accounts then there is memory for, we actually leave about 128MB as a 
> buffer.

That's a bit odd then. If you don't explicitly specify dom0's memory 
allocation at boot time then you should end up with 128MB 'slack' left 
unallocated. And that should all be <4GB.

If you are giving dom0 all of memory on boot, and then reducing it 
later, that could be a problem (dom0 may end up giving back only memory 
 >4GB).

  -- Keir

Re: Linux 2.6 guest BUG().

[Matt Ayres]

Keir Fraser wrote:
> 
> On 1 Feb 2006, at 16:08, Matt Ayres wrote:
>
>>
>> I assume you mean Xen's memory usage. I am showing 141MB free out of 
>> 8112MB total.  Our scripts to add accounts don't allow adding more 
>> accounts then there is memory for, we actually leave about 128MB as a 
>> buffer.
> 
> That's a bit odd then. If you don't explicitly specify dom0's memory 
> allocation at boot time then you should end up with 128MB 'slack' left 
> unallocated. And that should all be <4GB.
> 
> If you are giving dom0 all of memory on boot, and then reducing it 
> later, that could be a problem (dom0 may end up giving back only memory 
>  >4GB).

I am allocating 256MB of RAM to dom0.  I am running Fedora Core 4.  On 
this particular server I am running httpd/mysqld on the host with a fair 
amount of activity to it, but I have extended swap space to 1GB and 
tuned both apps for low memory usage.  The memory is set statically via 
kernel line in grub.  (dom0-min-mem 262144) is set in xend-config.sxp to 
ensure it keeps the memory allocated to it.

Thank you,
Matt Ayres

Re: Linux 2.6 guest BUG().

[Matt Ayres]

Keir Fraser wrote:
> 
> On 1 Feb 2006, at 16:08, Matt Ayres wrote:
> 
>> I can provide dozens of BUG()'s if required.  It just happened again 
>> on a host in dom0 to the sshd daemon and now that port is locked 
>> (netstat -nlp reports "-" as the process name).  I am able to access 
>> the server via the console.
>>
>> I assume you mean Xen's memory usage. I am showing 141MB free out of 
>> 8112MB total.  Our scripts to add accounts don't allow adding more 
>> accounts then there is memory for, we actually leave about 128MB as a 
>> buffer.
> 
> That's a bit odd then. If you don't explicitly specify dom0's memory 
> allocation at boot time then you should end up with 128MB 'slack' left 
> unallocated. And that should all be <4GB.
> 
> If you are giving dom0 all of memory on boot, and then reducing it 
> later, that could be a problem (dom0 may end up giving back only memory 
>  >4GB).
> 

Just as an update, I just "upgraded" this specific host from -unstable 
to 3.0-testing (3.0.1) and I will report back if I still receive these 
BUG()'s.