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/
Home Products Support Community News


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

On Thu, Jul 14, 2011 at 11:44:11PM +0800, Liwei wrote:
> 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. =)

For the bugs you outlined, you might want to try 4.1.1 just to double-check.

I've had some strange issues with  Xen-Unstable that I hadn't tracked down.
> 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?)

You can buy a PCI/PCIe type serial card. That is what I am using for
the non-serial supplied boxes.
> 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.

This is with PCI passthrough or without?
> 3. On high (full) CPU and disk utilisation, the whole system will
> sometimes reboot.

That is .. not good. I think you need to buy that PCI card so
we can get to the bottom of this.
> 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.

What is "before" ?
> 6. The WAN bridge to my pfSense appliance goes down (pings suddenly
> stop) after a while. Rebooting the pfSense domain restores it for a

Do you see any messages in Dom0 about the NIC going offline? IF you run
udevadm monitor --kernel --udev --property do you see anything showing
up when the bridge goes down?

> 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