>>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
|
