From: Paul Durrant <Paul.Durrant@citrix.com>
To: 'Jan Beulich' <JBeulich@suse.com>
Cc: 'Juergen Gross' <jgross@suse.com>,
Andrew Cooper <Andrew.Cooper3@citrix.com>,
"'Julien Grall (julien.grall@arm.com)'" <julien.grall@arm.com>,
'Boris Ostrovsky' <boris.ostrovsky@oracle.com>,
"'xen-devel(xen-devel@lists.xenproject.org)'"
<xen-devel@lists.xenproject.org>
Subject: Re: debian stretch dom0 + xen 4.9 fails to boot
Date: Mon, 12 Jun 2017 12:25:13 +0000 [thread overview]
Message-ID: <719344fa1fb54ebb8e89566ea615275e@AMSPEX02CL03.citrite.net> (raw)
In-Reply-To: <9bcb4f836ef547c1b4870d0ec08f0aba@AMSPEX02CL03.citrite.net>
> -----Original Message-----
> From: Paul Durrant
> Sent: 12 June 2017 13:06
> To: 'Jan Beulich' <JBeulich@suse.com>
> Cc: Julien Grall (julien.grall@arm.com) <julien.grall@arm.com>; Andrew
> Cooper <Andrew.Cooper3@citrix.com>; xen-devel(xen-
> devel@lists.xenproject.org) <xen-devel@lists.xenproject.org>; 'Boris
> Ostrovsky' <boris.ostrovsky@oracle.com>; Juergen Gross
> <jgross@suse.com>
> Subject: RE: [Xen-devel] debian stretch dom0 + xen 4.9 fails to boot
>
> > -----Original Message-----
> > From: Jan Beulich [mailto:JBeulich@suse.com]
> > Sent: 12 June 2017 12:12
> > To: Paul Durrant <Paul.Durrant@citrix.com>
> > Cc: Julien Grall (julien.grall@arm.com) <julien.grall@arm.com>; Andrew
> > Cooper <Andrew.Cooper3@citrix.com>; xen-devel(xen-
> > devel@lists.xenproject.org) <xen-devel@lists.xenproject.org>; 'Boris
> > Ostrovsky' <boris.ostrovsky@oracle.com>; Juergen Gross
> > <jgross@suse.com>
> > Subject: RE: [Xen-devel] debian stretch dom0 + xen 4.9 fails to boot
> >
> > >>> On 12.06.17 at 12:53, <Paul.Durrant@citrix.com> wrote:
> > >> -----Original Message-----
> > > [snip]
> > >> > >
> > >> > > What do you think it best to do for Xen 4.9? Hardcoding a 4k
> alignment
> > is
> > >> > > clearly easy and would work around this BIOS issue but, as you say, it
> > >> does
> > >> > > grow the image. Reverting Juergen's patch also works round the
> issue,
> > >> but
> > >> > > that is more by luck. Re-working the code is preferable, but I guess
> it's
> > >> too
> > >> > > late to introduce such code-churn in 4.9.
> > >> >
> > >> > Reverting Jürgen's code is out of question with all the information
> > >> > you've gathered by now. I think re-working the EDD code slightly
> > >> > is the best option. Would you mind giving the attached patch a
> > >> > try? This still slightly grows the trampoline due to a few more
> > >> > instructions being needed, but should still be far better than
> > >> > embedding a whole 4k buffer (and then later finding a BIOS/disk
> > >> > combination which wants even more). Note that I've left a tiny
> > >> > bit of debugging code in there.
> > >> >
> > >>
> > >> Sure, I'll give that a go now.
> > >>
> > >
> > > That worked fine:
> > >
> > > (XEN) MBR[80] @ 85e0 (86000)
> >
> > But that's contrary to your earlier findings: Didn't you say simply
> > avoiding a 4k-boundary wasn't enough? And it certainly tells us
> > that this isn't a 4k drive (or at least the BIOS doesn't surface 4k
> > sectors) - I was really expecting a larger gap between the two
> > logged values.
> >
>
> I'll go dump out the edd and double check what it is saying.
>
I dumped a bit of the info:
(XEN) device 0x80 version 0x30
(XEN) number_of_sectors = 0x1dcf32b0
(XEN) sectors_per_track = 0x3f
(XEN) bytes_per_sector = 0x200
So it is indeed advertising a 512 byte sector. It is an SSD though so it'll be something much bigger underneath.
Paul
> My findings indicated that the problem seemed to be doing a read that
> spanned a 4k boundary caused a problem, so using 0x85e00 would be safe.
> The anomaly was that simply aligning the edd_info buffer and a 512 byte
> boundary and continuing to use that for reading did not work.
>
> > > so you can add my Tested-by to that.
> >
> > I.e. I'm not sure about this, as I'm still uncertain whether some
> > corruption didn't again occur. Of course APs coming up properly
> > would already be a relatively good sign (as now the permanent
> > part of the trampoline would be the predestined area for
> > corruption to occur in).
> >
>
> None of my findings ever indicated memory corruption (although there, of
> course, may have been some that I happened to miss), but rather
> misbehaviour of the int13 handler itself - either locking up, having odd
> effects (e.g. black screen), or both.
>
> Paul
>
> > Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2017-06-12 12:26 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-06 14:32 debian stretch dom0 + xen 4.9 fails to boot Paul Durrant
2017-06-06 15:11 ` Jan Beulich
2017-06-06 15:51 ` Paul Durrant
2017-06-06 16:28 ` Paul Durrant
2017-06-06 17:00 ` Boris Ostrovsky
2017-06-07 8:07 ` Jan Beulich
2017-06-07 8:09 ` Paul Durrant
2017-06-07 8:19 ` Paul Durrant
2017-06-07 14:05 ` Boris Ostrovsky
2017-06-07 8:07 ` Paul Durrant
2017-06-07 8:27 ` Jan Beulich
[not found] ` <5937D4FF02000078001602F6@suse.com>
2017-06-07 9:03 ` Juergen Gross
2017-06-07 9:05 ` Paul Durrant
2017-06-07 9:09 ` Andrew Cooper
2017-06-07 10:36 ` Paul Durrant
2017-06-07 11:06 ` Paul Durrant
2017-06-07 11:57 ` Juergen Gross
2017-06-07 12:02 ` Paul Durrant
2017-06-07 12:13 ` Juergen Gross
2017-06-07 12:19 ` Jan Beulich
2017-06-07 12:26 ` Paul Durrant
2017-06-07 12:34 ` Jan Beulich
2017-06-07 11:50 ` Jan Beulich
2017-06-07 11:55 ` Paul Durrant
2017-06-07 12:00 ` Jan Beulich
2017-06-07 12:46 ` Paul Durrant
2017-06-07 12:55 ` Jan Beulich
2017-06-07 15:06 ` Paul Durrant
2017-06-07 15:33 ` Jan Beulich
2017-06-07 15:40 ` Paul Durrant
2017-06-07 15:52 ` Jan Beulich
2017-06-08 12:42 ` Paul Durrant
2017-06-08 12:46 ` Juergen Gross
2017-06-08 13:18 ` Jan Beulich
2017-06-08 13:24 ` Paul Durrant
2017-06-09 12:19 ` Paul Durrant
2017-06-09 13:05 ` Jan Beulich
2017-06-09 13:52 ` Boris Ostrovsky
2017-06-09 15:14 ` Paul Durrant
2017-06-09 15:41 ` Jan Beulich
2017-06-09 15:47 ` Paul Durrant
2017-06-09 15:58 ` Jan Beulich
2017-06-12 8:14 ` Paul Durrant
2017-06-12 10:40 ` Jan Beulich
2017-06-12 10:44 ` Paul Durrant
2017-06-12 10:53 ` Paul Durrant
2017-06-12 11:12 ` Jan Beulich
2017-06-12 12:05 ` Paul Durrant
2017-06-12 12:25 ` Paul Durrant [this message]
2017-06-12 13:54 ` Jan Beulich
2017-06-12 14:28 ` Paul Durrant
2017-06-12 14:43 ` Paul Durrant
2017-06-12 15:03 ` Paul Durrant
2017-06-12 15:07 ` Jan Beulich
2017-06-12 15:21 ` Paul Durrant
2017-06-06 17:40 ` Julien Grall
2017-06-07 8:05 ` Paul Durrant
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=719344fa1fb54ebb8e89566ea615275e@AMSPEX02CL03.citrite.net \
--to=paul.durrant@citrix.com \
--cc=Andrew.Cooper3@citrix.com \
--cc=JBeulich@suse.com \
--cc=boris.ostrovsky@oracle.com \
--cc=jgross@suse.com \
--cc=julien.grall@arm.com \
--cc=xen-devel@lists.xenproject.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).