From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
xen devel <xen-devel@lists.xensource.com>,
Keir Fraser <keir@xen.org>
Subject: Re: Xen 4 serial hangs during boot
Date: Thu, 26 Jul 2012 09:50:01 -0400 [thread overview]
Message-ID: <20120726135001.GA28024@phenom.dumpdata.com> (raw)
In-Reply-To: <500E95D30200007800090218@nat28.tlf.novell.com>
On Tue, Jul 24, 2012 at 11:32:19AM +0100, Jan Beulich wrote:
> >>> On 23.07.12 at 22:53, "Christopher S. Aker" <caker@theshore.net> wrote:
> > On 7/20/12 3:59 PM, Keir Fraser wrote:
> >> Then it is Xen doing something to kill the serial interrupt. ;-) I haven't
> >> seen anything like this reported before. Not sure what to suggest really...
> >> Gather debug output from interrupt-related debug keys (via the xl debug-keys
> >> interface) I suppose. I think that would be 'i' and 'z' keys. That plus Xen
> >> and dom0 boot logs... something might become apparent.
> >
> > We hit this again today, and I grabbed boot and debug-keys output:
> >
> > http://theshore.net/~caker/xen/BUGS/serial/log.txt
>
> This isn't even 8k that make it over, whereas the transmit buffer
> is 16k, and dropping of characters would only start when it first
> got full.
>
> The part of the data that didn't make it out isn't big enough to
> overflow the buffer - to check whether that would actually
> happen, could you increase the log level of both hypervisor and
> Dom0 kernel? To me this all (particularly the fact that you can
> make the data appear combined with the amount of data not
> being big enough to fill the buffer) looks as if there was some
> buffering happening outside of the control of Xen. Did you check
> whether this is possibly a problem with the remote end?
This got me thinking - I've one particular AMD machine (prototype) that
seems to hang often - but if I use 'sync_console' it works fine.
This issue started oooh, I can't remember when but I do have some logs
that could shed some light on the about date. I guess I was
too quick to blame the prototype for being at fault here :-(
Then recently (yesterday?) the upstream kernel started doing something
wonky on this card:
01:05.0 Serial controller: NetMos Technology PCI 9835 Multi-I/O Controller (rev 01)
Under Xen, when it boots it hits right here:
[ 1.240774] pci 0000:01:05.0: [9710:9835] type 00 class 0x070002
and then stops [note: I hadn't really done any investigation to see
if the machine is dead or if it continues on, but with the serial port just
wedged hard].
On baremetal it can actually read the IO bars:
[ 1.240774] pci 0000:01:05.0: [9710:9835] type 00 class 0x070002
[ 1.247075] pci 0000:01:05.0: reg 10: [io 0xe050-0xe057]
[ 1.252734] pci 0000:01:05.0: reg 14: [io 0xe040-0xe047]
[ 1.258394] pci 0000:01:05.0: reg 18: [io 0xe030-0xe037]
[ 1.264054] pci 0000:01:05.0: reg 1c: [io 0xe020-0xe027]
[ 1.269713] pci 0000:01:05.0: reg 20: [io 0xe010-0xe017]
[ 1.275372] pci 0000:01:05.0: reg 24: [io 0xe000-0xe00f]
so I am wondering if the back-ports in Xen 4.1 for dealing with
PCI have something to do with this?
>
> Does this also happen with "sync_console"? Did you check
> whether disabling the use of the associated IRQ makes any
> difference, as suggested by Konrad (I think)?
>
> Does the port work flawlessly on native Linux?
>
> Jan
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2012-07-26 13:50 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-12 19:34 Xen 4 occasionally hangs during boot Christopher S. Aker
2011-10-13 7:04 ` Jan Beulich
2011-10-13 10:46 ` Tim Deegan
2012-07-20 17:48 ` Xen 4 serial " Christopher S. Aker
2012-07-20 17:49 ` Andrew Cooper
2012-07-20 17:58 ` Christopher S. Aker
2012-07-20 18:05 ` Andrew Cooper
2012-07-20 19:10 ` Christopher S. Aker
2012-07-20 19:25 ` Andrew Cooper
2012-07-20 19:31 ` Keir Fraser
2012-07-20 19:44 ` Christopher S. Aker
2012-07-20 19:59 ` Keir Fraser
2012-07-23 14:13 ` Konrad Rzeszutek Wilk
2012-07-23 15:26 ` Keir Fraser
2012-07-23 20:53 ` Christopher S. Aker
2012-07-23 22:03 ` Malcolm Crossley
2012-07-23 22:45 ` Malcolm Crossley
2012-07-24 9:40 ` Andrew Cooper
2012-07-24 10:32 ` Jan Beulich
2012-07-26 13:50 ` Konrad Rzeszutek Wilk [this message]
2012-07-26 14:10 ` Jan Beulich
2012-07-26 14:36 ` Konrad Rzeszutek Wilk
2012-07-24 10:46 ` Jan Beulich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120726135001.GA28024@phenom.dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=keir@xen.org \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.