From: ebiederm@xmission.com (Eric W. Biederman)
To: Andrew Morton <akpm@osdl.org>
Cc: Yinghai Lu <yinghai.lu@amd.com>,
vgoyal@in.ibm.com, ak@muc.de, fastboot@lists.osdl.org,
linux-kernel@vger.kernel.org, discuss@x86-64.org,
linuxbios@openbios.org
Subject: Re: Inclusion of x86_64 memorize ioapic at bootup patch
Date: Fri, 06 Jan 2006 01:02:16 -0700 [thread overview]
Message-ID: <m164ox6ayf.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <20060105163848.3275a220.akpm@osdl.org> (Andrew Morton's message of "Thu, 5 Jan 2006 16:38:48 -0800")
Andrew Morton <akpm@osdl.org> writes:
>
> Please don't top-post.
>
>>
>> On 1/2/06, Vivek Goyal <vgoyal@in.ibm.com> wrote:
>> > Hi Andi,
>> >
>> > Can you please include the following patch. This patch has already been
> pushed
>> > by Andrew.
>> >
>> >
> http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15-rc5-mm3/broken-out/x86_64-io_apicc-memorize-at-bootup-where-the-i8259-is.patch
>
> IIRC, I dropped this patch because of discouraging noises from Andi and
> because underlying x86_64 changes broke it in ugly ways.
Ok. I just as extensively as I could and I can't find the under laying
x86_64 changes that Andi mentioned he was working on. I have looked
in current -mm and in Andi merge and experimental quilt trees. It
could be that I'm blind but I looked and I did not see them.
Even in the discussion where this was mentioned there never was a
semantic conflict. But rather two patches passing so close they
touched the same or neighboring lines of code.
> It needs to be
> redone and Andi's objections (whatever they were) need to be addressed or
> argued about.
The difference was one of approach. Andi wanted us to treat the apics
as black boxes and save and restore register values with no regard as
to what the registers did. This is theoretically more future proof,
but it looses flexibility.
My approach is to treat the apics as something we understand, and
simply save off the one small piece of information from the boot
time state that we can't discover any other way.
The x86_64-ioapic-virtual-wire-mode-fix.patch in 2.6.15-mm1 actually
takes advantage of the fact we understand what the apics are doing
to change the destination cpu, in the kexec on panic case. This
is something that cannot be done if we simply saved off the registers.
> Right now the patch is rather dead.
Current the referred to patch applies just fine, to 2.6.15,
and except for a conflict with the above mentioned patch which
applies fine to 2.6.15-mm1 as well.
Putting the apics in a state where we can use them if fundamental
so to booting a kernel so this is something we need to resolve
if we want kexec to be usable.
A revived version of the patch that applies without patch
follows.
Eric
next prev parent reply other threads:[~2006-01-06 8:03 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-03 4:46 Inclusion of x86_64 memorize ioapic at bootup patch Vivek Goyal
2006-01-06 0:30 ` Yinghai Lu
2006-01-06 0:38 ` Andrew Morton
2006-01-06 4:50 ` Vivek Goyal
2006-01-06 8:02 ` Eric W. Biederman [this message]
2006-01-06 15:26 ` [LinuxBIOS] " Ronald G Minnich
2006-01-06 18:59 ` Andi Kleen
2006-01-06 8:14 ` [PATCH] i386 io_apic: Use correct index variable when computing the apic that is in ExtInt mode Eric W. Biederman
2006-01-06 8:20 ` [PATCH] x86_64 io_apic: memorize at bootup where the i8259 is Eric W. Biederman
2006-01-07 0:44 ` Yinghai Lu
2006-01-07 1:29 ` [PATCH] x86_64 io_apic: memorize at bootup where the i8259 is (typo fix) Eric W. Biederman
2006-01-06 8:24 ` Inclusion of x86_64 memorize ioapic at bootup patch Eric W. Biederman
2006-01-06 23:48 ` Andi Kleen
2006-01-07 0:00 ` Yinghai Lu
2006-01-07 0:29 ` Eric W. Biederman
-- strict thread matches above, loose matches on Subject: below --
2006-01-07 0:35 Lu, Yinghai
2006-01-07 1:14 ` Eric W. Biederman
2006-01-07 1:32 Lu, Yinghai
2006-01-07 2:32 ` yhlu
2006-01-07 6:38 ` yhlu
2006-01-07 7:20 ` yhlu
2006-01-07 9:43 ` yhlu
2006-01-07 12:46 ` Eric W. Biederman
2006-01-07 19:36 ` yhlu
2006-01-07 19:44 ` Eric W. Biederman
2006-01-07 21:35 ` yhlu
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=m164ox6ayf.fsf@ebiederm.dsl.xmission.com \
--to=ebiederm@xmission.com \
--cc=ak@muc.de \
--cc=akpm@osdl.org \
--cc=discuss@x86-64.org \
--cc=fastboot@lists.osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxbios@openbios.org \
--cc=vgoyal@in.ibm.com \
--cc=yinghai.lu@amd.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