Re: BUG: scheduling while atomic: xenwatch

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Thu, Jul 14, 2011 at 11:44:11PM +0800, Liwei wrote:
> On 13 July 2011 03:54, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> 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!