From: ebiederm@xmission.com (Eric W. Biederman)
To: "Christian Schaubschläger" <christian.schaubschlaeger@gmx.at>
Cc: Khalid Aziz <khalid.aziz@hp.com>, kexec@lists.infradead.org
Subject: Re: Problem with kexec on i386, linux-3.5
Date: Thu, 16 Aug 2012 12:22:46 -0700 [thread overview]
Message-ID: <877gsy4p6h.fsf@xmission.com> (raw)
In-Reply-To: <502CEA93.7090808@gmx.at> ("Christian \=\?utf-8\?Q\?Schaubschl\?\= \=\?utf-8\?Q\?\=C3\=A4ger\=22's\?\= message of "Thu, 16 Aug 2012 14:41:55 +0200")
Christian Schaubschläger <christian.schaubschlaeger@gmx.at> writes:
>> That is a tricky issue. Sometimes the slightest things can set
>> something like this off.
>>
>> Somewhere someone changed something in one of the drivers that made it
>> so that the hardware winds up in a state the int 13 disk driver does not
>> like it after kexec.
>> .
>> If you want to track this down I would recommend a bisect between 3.4
>> and 3.5-rc1 to see which change breaks your setup.
>
> I bistcted that down to this patch:
>
> commit b566a22c23327f18ce941ffad0ca907e50a53d41
> Author: Khalid Aziz <khalid.aziz@hp.com>
> Date: Fri Apr 27 13:00:33 2012 -0600
>
> PCI: disable Bus Master on PCI device shutdown
>
> Disable Bus Master bit on the device in pci_device_shutdown() to ensure PCI
> devices do not continue to DMA data after shutdown. This can cause memory
> corruption in case of a kexec where the current kernel shuts down and
> transfers control to a new kernel while a PCI device continues to DMA to
> memory that does not belong to it any more in the new kernel.
>
> I have tested this code on two laptops, two workstations and a 16-socket
> server. kexec worked correctly on all of them.
>
> Signed-off-by: Khalid Aziz <khalid.aziz@hp.com>
> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
>
>
> Without this patch, int13 works fine here! If anyone needs more
> information, just let me know!
Which leads to an interesting conundrum.
kexec appears to be more reliable for booting another kernel with this
patch applied. This patch does kill the entier use case of making BIOS
calls, and I suspect it also does nasty things to alpha bootloaders.
My gut feel is that the trampoline code should reenable bus mastering
on the devices that lie behind int13, but I don't know how practical
that suggestion is in reality.
Eric
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2012-08-16 19:23 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-24 17:49 Problem with kexec on i386, linux-3.5 Christian Schaubschläger
2012-08-14 3:31 ` Eric W. Biederman
2012-08-16 12:41 ` Christian Schaubschläger
2012-08-16 19:22 ` Eric W. Biederman [this message]
2012-08-17 6:58 ` Christian Schaubschläger
2012-09-07 15:16 ` Khalid Aziz
2012-09-07 20:29 ` Khalid Aziz
2012-09-10 6:00 ` Christian Schaubschläger
2012-09-10 16:29 ` Khalid Aziz
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=877gsy4p6h.fsf@xmission.com \
--to=ebiederm@xmission.com \
--cc=christian.schaubschlaeger@gmx.at \
--cc=kexec@lists.infradead.org \
--cc=khalid.aziz@hp.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox