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

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


  • To: bderzhavets@xxxxxxxxx
  • From: Andrew Lyon <andrew.lyon@xxxxxxxxx>
  • Date: Mon, 16 Mar 2009 18:44:37 +0000
  • Cc: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Mon, 16 Mar 2009 11:45:09 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=VrzuFFUNeQkoXV1N9AfIkDnzTZJyYdHJiCaw6v5eyUqMQdEPfdHvY7ZEJU88+iUP54 KhZGNMOHrwofCLrdaFqhGMD9pVlesmqCMKu2fRZ+HWHG8sqUf97evp9spZxPrCj5ovF4 5xNcTqbbJLdjq5xniN5cE5ENmuL3qBxUiA81U=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

2009/3/16 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

I often use serial over ethernet devices to gain remote access to a
serial console, I've used several different devices:

Tibbo www.tibbo.com they use a proprietary protocol and require client
side software to be loaded on the client (linux or windows), not sure
if data can be encrypted.

Portbox http://www.hw-group.com/products/converter/index_en.html very
good , uses RFC2217 NVT protocol, client software is windows only but
can also be configured as tcp server, supports encryption, quite
expensive.

eNET http://www.audon.co.uk/enet100.html I think they use a
proprietary protocol but they can also be configured as tcp server, no
encryption.

When the device is configured as a tcp server I simply use netcat as a
client, its sufficient for logging and sending sysrq keys.

One worry might be that some do not support encryption, so its
possible for data to be sniffed.

You can also get large devices with many serial ports, some hosting
providers offer this as a service.

Andy

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

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


 


Rackspace

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