From: Ben Guthro <ben.guthro@gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Ben Guthro <ben@guthro.net>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: 4.3 regression in booting on a particular platform
Date: Wed, 10 Jul 2013 06:17:56 -0400 [thread overview]
Message-ID: <1638737482981250100@unknownmsgid> (raw)
In-Reply-To: <51DD40D202000078000E3C51@nat28.tlf.novell.com>
On Jul 10, 2013, at 5:09 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 09.07.13 at 18:34, Ben Guthro <ben@guthro.net> wrote:
>> On Tue, Jul 9, 2013 at 9:18 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>> On 09.07.13 at 14:55, Ben Guthro <ben@guthro.net> wrote:
>>>> While this is pre-release hardware from an OEM, it did work on 4.2, so
>>>> I am not (yet) inclined to blame it on being pre-release hardware.
>>>>
>>>> This is very early in boot, and so does not have a proper stack.
>>>> Do you have any thoughts as to where this might be going awry?
>>>
>>> If you could make the xen-syms available matching the xen.gz that
>>> was used when the below log was obtained, I could try to take a
>>> look.
>>>
>>> Perhaps repeating the attempt with "iommu=debug" could reveal
>>> further useful details.
>>
>> I have put xen.gz, the xen-syms, and an updated boot log, with
>> iommu=debug at the following location that you may download:
>> https://citrix.sharefile.com/d/safbf0b05aac4233a
>
> This
>
> (XEN) [VT-D]dmar.c:767: Host address width 39
> (XEN) [VT-D]dmar.c:781: found ACPI_DMAR_DRHD:
> (XEN) [VT-D]dmar.c:461: dmaru->address = 0
>
> is clearly a BIOS bug, and I don't see how 4.2 would get along
> with that. It may fail in different ways, but that's not directly
> related to how ioremap() is implemented.
>
> That said, the changeset you pointed at uncovered an always
> existing bug in the VT-d code: The mapping of the IOMMU MMIO
> register space is being established through map_to_nocache_virt()
> (resolving to set_fixmap_nocache()), but iommu_free() calls
> iounmap() to undo it (which prior to said changeset wasn't
> doing anything).
>
> Bottom line - this box wants to be booted with "iommu=off" until
> you have a fixed BIOS.
It would be better if we could detect such a buggy bios, and continue
to boot without iommu capability, rather than crash, no?
Thank you for the analysis. Is there a wiki page, or the like that
might give me a pointer on how to do this analysis for myself in the
future, so as not to bother you? (Eg, how to work with Xen-syms)
>
> Jan
>
next prev parent reply other threads:[~2013-07-10 10:17 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-09 12:55 4.3 regression in booting on a particular platform Ben Guthro
2013-07-09 13:18 ` Jan Beulich
2013-07-09 16:34 ` Ben Guthro
2013-07-09 16:44 ` Ben Guthro
2013-07-10 9:09 ` Jan Beulich
2013-07-10 10:17 ` Ben Guthro [this message]
2013-07-10 10:28 ` 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=1638737482981250100@unknownmsgid \
--to=ben.guthro@gmail.com \
--cc=JBeulich@suse.com \
--cc=ben@guthro.net \
--cc=xen-devel@lists.xen.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 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.