Fw: Re: [Xen-devel] tip.git regression from "vsprintf: unify the format decoding layer for its 3 users"

[Boris Derzhavets <bderzhavets@xxxxxxxxx>]

>>Boris Derzhavets wrote:
> >Performed:-
> >
> >root@ServerIntrepid:/usr/src/linux-2.6-xen# git reset --hard remotes/origin/xen/dom0/hackery
> HEAD is now at a38db50 Merge commit 'tip/core/printk' into xen/dom0/hackery
> >make clean
> >make
>> make modules_install install
> >mkinitramfs -o /boot/initrd-2.6.29-rc7-tip.img 2.6.29-rc7-tip
> >
> >Booted with new kernel under Xen (19355) and get same bug in place.
>> Cannot shutdown any PV DomU . Xen Host dies.
>
>OK, so we're talking about a new bug now, right?

>When you say "Xen Host dies", do you mean that Xen itself crashes?  Or that >the dom0 kernel crashes?  Hangs?  Non-responsive?
*******************************************
It stops responding at all as 3 days ago.
Just the same picture :-

PV DomU CentOS 5.2 has been tested with new kernel
During shutdown mentioned DomU usual sequence of daemon's messages drops into stack trace with following messages at the end:-

xenbus_dev_shutdown:   device/vif/0 timeout closing device
xenbus_dev_shutdown:   device/vbd/51712 timeout closing device
System halted.

*******************************************
> Do you have a serial console?

 >  J

Jeremy,

Bellow follows my message to you sent on 3/14/09
The bug is old.
I do have null modem cable ( 2 m.) . Setting up serial is quite possible,
but not right now. Boxes are located in different places.

Boris

--- On Sat, 3/14/09, Boris Derzhavets <bderzhavets@xxxxxxxxx> wrote:

From: Boris Derzhavets <bderzhavets@xxxxxxxxx>
Subject: Re: [Xen-devel] tip.git regression from "vsprintf: unify the format decoding layer for its 3 users"
To: "Jeremy Fitzhardinge" <jeremy@xxxxxxxx>
Cc: "Xen-devel" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Date: Saturday, March 14, 2009, 5:43 AM

Two PV DomUs (CentOS 5.2 , F10) have been tested with new kernel
During shutdown of any one of mentioned DomUs usual sequence of daemon's messages drops into stack trace with following messages at the end:-

xenbus_dev_shutdown:   device/vif/0 timeout closing device
xenbus_dev_shutdown:   device/vbd/51712 timeout closing device
System halted.

After that Xen Host stop responding at all, just dies.

Boris


--- On Sat, 3/14/09, Jeremy Fitzhardinge <jeremy@xxxxxxxx> wrote:

From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: [Xen-devel] tip.git regression from "vsprintf: unify the format decoding layer for its 3 users"
To: "Frederic Weisbecker" <fweisbec@xxxxxxxxx>
Cc: "Xen-devel" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Ingo Molnar" <mingo@xxxxxxx>, "the arch/x86 maintainers" <x86@xxxxxxxxxx>, "Linux Kernel Mailing List" <linux-kernel@xxxxxxxxxxxxxxx>
Date: Saturday, March 14, 2009, 3:04 AM

Change fef20d9c1380f04ba9492d6463148db07b413708, "vsprintf: unify the
format decoding layer for its 3 users", causes a regression in xenbus which
results in no devices getting attached to a new domain.  Reverting
fef20d9c1380f04ba9492d6463148db07b413708 and
39e874f8afbdb3745e2406ce4ecbde9ac4cbaa78 fixes the problem.

I haven't identified what format string is being handled wrongly, so I
don't know what the precise bug is.  The most complex looking format in use
seems to be %.*s; there's also "%s/%s", "%i" and
"%lX".

   J

_______________________________________________
Xen-devel mailing

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

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

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