[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Status of FLR in Xen 4.4



Friday, September 27, 2013, 9:48:39 PM, you wrote:

> Yes, running the most recent xen-unstable-staging tree, but I have these 
> issues at least since february with xen-unstable, so I don't suspect recent 
> changes to be the issue in my case.

> I will do some testing with switching from tickless-idle to non-tickless and 
> after you mentioned hpet issues maybe changing the clocksource, will see what 
> happens..

I'm now running with tickless-idle, so i suspect it will make no difference.
So i think trying to make it boot by pressing a key on the keyboard when it 
doesn't make progress on boot (see if that works) and if it does .. provide the 
output of "xl dmesg"
would be the best shot.

( BTW there were 2 seperate issues ..  see threads:
http://lists.xen.org/archives/html/xen-devel/2013-03/msg01796.html
http://lists.xen.org/archives/html/xen-devel/2013-08/msg00201.html
)



> 2013/9/27 Sander Eikelenboom <linux@xxxxxxxxxxxxxx>

>   

>  Friday, September 27, 2013, 9:19:14 PM, you wrote:
>  
 >> Hi Sander,
>  
 >> thanks for the advice, I have actually no rcu stalls when i use the 
 >> no-cpuidle function. Do you have a little more insight on what is actually 
 >> causing this behaviour and if there is a better solution then this option, 
 >> cause I don't want to sacrifice my C-states (I would assume this makes the 
 >> overall server more power hungry?).
>    
 >> Does this has something to do with the new tickless-kernel options in the 
 >> newer kernel, or is this really only an apci incompatibility with xen?
>  
 >> Thanks!
>  
>   Are you running xen-unstable ?
>   Some patches went in lately
>  
>   You also seem to have a motherboard with a AMD 890fx chipset, i suspect 
> your bios also has issues around the HPET as mine had.
>   I was also seeing RCU stalls on boot (and only on boot) .. hitting any key 
> on the console when it appears to stall during boot made it continue in my 
> case (happens several times).
>   Took a while to find the problems, Jan Beulich has made and commited some 
> patches that went in xen-unstable recently.
>  
>   Are you running xen-unstable ?
>   If not, could you give it a try and provide the xl dmesg / serial log ?
>  
>   --
>   Sander
>  

>  
>  
>  
>  
>  
>  
>  
 >>   2013/9/27 Sander Eikelenboom <linux@xxxxxxxxxxxxxx>
>  
 >>   Hi Matthias,
 >>
 >>  Have you tried adding "no-cpuidle" on the xen/hypervisor commandline in 
 >> grub ?
 >>
 >>  --
 >>  Sander
 >>
>  
 >>  Friday, September 27, 2013, 7:07:33 PM, you wrote:
 >>
  >>> Hi Konrad,
 >>
  >>> good call! I was able to reproduce the error with the 3.12-rc2 kernel, got
  >>> a lot of information with the new NMI traces (log attached), but since I'm
  >>> not a xen hacker I don't really know how to continue from here. So I might
  >>> add this to the original post and maybe someone can help me. After all the
  >>> error persists for half a year now and besides 2 kernel version / .config
  >>> Combinations (a 3.8.2 and a 3.6.something) I could never trace this issue
  >>> back (even with bisecting the .config because at some point it seemed
  >>> random).
 >>
 >>
  >>> 2013/9/27 Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
 >>
  >>>> On Thu, Sep 26, 2013 at 07:59:40PM +0200, Matthias wrote:
  >>>> > I'm currently on a vanilla 3.8.2 kernel because this is the only >3.4
  >>>> > kernel I found which doesn't give me this issue:
  >>>> > http://lists.xen.org/archives/html/xen-users/2013-02/msg00114.html
  >>>>
  >>>> So v3.12 (or rather the latest and greaters of the Linus) has the 
mechanism
  >>>> for the NMI - so you can actually see what is causing the stall.
  >>>>
 >>
 >>
>  
>  
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.