Re: [Xen-devel] BUG: scheduling while atomic: xenwatch

[Liwei <xieliwei@xxxxxxxxx>]

On 13 July 2011 03:54, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> wrote:
>
> Right now I think base wise we are the same. However we have two
> different patchqueues - Jeremy has some paravirt spinlock code and
> tracing code. I've some cleanups and new drivers.
>
> I am going to stick his patches in when he reposts them.
>

OK

>
> Of course. The #testing is what I am going to stick in #linux-next once
> they go through some testing. It also has some extra patches that
> are not yet ready for 3.1 but need testing.
>
> The #linux-next is what is queued up for 3.1 and it also has
> bugfixes for 3.0.
>
> The #master is .. oh, I should refresh it. It should have #linux-next
> + some patches for 3.2.
>
>

Yeah, I'm kind of confused with regards to which branch is which. That
clears it up!


Just to let you know, with your latest testing branch, the xenwatch
scheduling bug is effectively gone, so I guess the patch worked. =)


There are still some weird quirks around:
1. HVM Windows 7 with PCI passthrough refuses to shutdown, somehow
qemu treats it as a domain reboot. If I do a xl destroy, the whole
system reboots (not sure how I can find out what happens though since
my mainboard does not have a hardware serial port. Can xen log to a
file?)

2. With 16G of memory and Dom0 memory set to 1G, trying to start the
above 8G Windows 7 HVM while any other VM is running (I tried it with
one VM using 1G) causes some bug trace to occur (haven't had the
chance to copy that one down) and qemu starts but does nothing. Doing
xl destroy will cause 1. to occur.

3. On high (full) CPU and disk utilisation, the whole system will
sometimes reboot.

4. Somehow with this new kernel/xen combination, my pfSense domain
does not receive DHCP requests sent from other domains, requests from
other computers in the network outside of xen are received though. Non
broadcast traffic works though.

5. The network performance of this kernel/xen combination compared to
before is almost half.

6. The WAN bridge to my pfSense appliance goes down (pings suddenly
stop) after a while. Rebooting the pfSense domain restores it for a
while. Removing and re-adding the domain's tap interface to/from the
bridge solves it permanently for the domain session. This has always
been a problem, not sure where the bug is originating from though
since different versions and combinations of Debian/kernel/xen/pfSense
has never solved it. And no indication of the problem occurring except
all WAN traffic stops.

I'm just listing it here in case someone has any idea about what's
happening in each case. I'll do a proper bug report for each case when
I've collected enough information (not even sure if 1, 2 and 3 could
be my hardware problem; 4 and 6 could be pfSense or Debian's fault as
well).


Thanks for the great work so far!

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