From: Dave Hansen <dave-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
To: Vegard Nossum <vegard.nossum-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Greg KH <gregkh-l3A5Bk7waGM@public.gmane.org>,
Mariusz Kozlowski
<m.kozlowski-NWF1p15JEu3VItvQsEIGlw@public.gmane.org>,
Stephen Rothwell <sfr-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org>,
kernel-testers-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-next-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Pekka Enberg <penberg-bbCR+/B0CizivPeTLB3BmA@public.gmane.org>,
Bernhard Walle <bwalle-l3A5Bk7waGM@public.gmane.org>,
Ingo Molnar <mingo-X9Un+BFzKDI@public.gmane.org>,
Vivek Goyal <vgoyal-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
kexec <kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: linux-next: Tree for July 18: warning at kernel/lockdep.c:2068 trace_hardirqs_on_caller
Date: Sun, 20 Jul 2008 02:01:02 -0700 [thread overview]
Message-ID: <1216544462.9311.20.camel@nimitz> (raw)
In-Reply-To: <19f34abd0807191611y7cabf405iad307ba79591e04f-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Sun, 2008-07-20 at 01:11 +0200, Vegard Nossum wrote:
> Maybe the firmware memmap code can simply run a little later in the
> boot sequence?
Heh, I'm catching up on this thread...
It is possible that it could run later. But, I do know that there are
at least a couple of these tables (on various arches) that we toss out
of memory or become unavailable later in boot.
I do this this:
sysfs: add /sys/firmware/memmap
is really being done at the wrong level. I don't, for instance, see
*any* reference to memory hotplug in these patches. That's because
they're done against firmware structures, and memory hotplug doesn't
update firmware structures on the two architectures that I can remember
(ppc64 and x86).
In other words, kexec using this probably won't work on a memory hotplug
machine.
Secondly, why don't we just modify the
existing /sys/devices/system/memory things to properly export what exec
needs? They're already cross-platform *and* they're updated with memory
hotplug events.
-- Dave
WARNING: multiple messages have this Message-ID (diff)
From: Dave Hansen <dave@linux.vnet.ibm.com>
To: Vegard Nossum <vegard.nossum@gmail.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
Pekka Enberg <penberg@cs.helsinki.fi>, Greg KH <gregkh@suse.de>,
kexec <kexec@lists.infradead.org>,
LKML <linux-kernel@vger.kernel.org>,
Mariusz Kozlowski <m.kozlowski@tuxland.pl>,
linux-next@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
kernel-testers@vger.kernel.org, Bernhard Walle <bwalle@suse.de>,
Vivek Goyal <vgoyal@redhat.com>
Subject: Re: linux-next: Tree for July 18: warning at kernel/lockdep.c:2068 trace_hardirqs_on_caller
Date: Sun, 20 Jul 2008 02:01:02 -0700 [thread overview]
Message-ID: <1216544462.9311.20.camel@nimitz> (raw)
In-Reply-To: <19f34abd0807191611y7cabf405iad307ba79591e04f@mail.gmail.com>
On Sun, 2008-07-20 at 01:11 +0200, Vegard Nossum wrote:
> Maybe the firmware memmap code can simply run a little later in the
> boot sequence?
Heh, I'm catching up on this thread...
It is possible that it could run later. But, I do know that there are
at least a couple of these tables (on various arches) that we toss out
of memory or become unavailable later in boot.
I do this this:
sysfs: add /sys/firmware/memmap
is really being done at the wrong level. I don't, for instance, see
*any* reference to memory hotplug in these patches. That's because
they're done against firmware structures, and memory hotplug doesn't
update firmware structures on the two architectures that I can remember
(ppc64 and x86).
In other words, kexec using this probably won't work on a memory hotplug
machine.
Secondly, why don't we just modify the
existing /sys/devices/system/memory things to properly export what exec
needs? They're already cross-platform *and* they're updated with memory
hotplug events.
-- Dave
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: Dave Hansen <dave@linux.vnet.ibm.com>
To: Vegard Nossum <vegard.nossum@gmail.com>
Cc: Greg KH <gregkh@suse.de>,
Mariusz Kozlowski <m.kozlowski@tuxland.pl>,
Stephen Rothwell <sfr@canb.auug.org.au>,
kernel-testers@vger.kernel.org, linux-next@vger.kernel.org,
LKML <linux-kernel@vger.kernel.org>,
Pekka Enberg <penberg@cs.helsinki.fi>,
Bernhard Walle <bwalle@suse.de>, Ingo Molnar <mingo@elte.hu>,
Vivek Goyal <vgoyal@redhat.com>,
kexec <kexec@lists.infradead.org>
Subject: Re: linux-next: Tree for July 18: warning at kernel/lockdep.c:2068 trace_hardirqs_on_caller
Date: Sun, 20 Jul 2008 02:01:02 -0700 [thread overview]
Message-ID: <1216544462.9311.20.camel@nimitz> (raw)
In-Reply-To: <19f34abd0807191611y7cabf405iad307ba79591e04f@mail.gmail.com>
On Sun, 2008-07-20 at 01:11 +0200, Vegard Nossum wrote:
> Maybe the firmware memmap code can simply run a little later in the
> boot sequence?
Heh, I'm catching up on this thread...
It is possible that it could run later. But, I do know that there are
at least a couple of these tables (on various arches) that we toss out
of memory or become unavailable later in boot.
I do this this:
sysfs: add /sys/firmware/memmap
is really being done at the wrong level. I don't, for instance, see
*any* reference to memory hotplug in these patches. That's because
they're done against firmware structures, and memory hotplug doesn't
update firmware structures on the two architectures that I can remember
(ppc64 and x86).
In other words, kexec using this probably won't work on a memory hotplug
machine.
Secondly, why don't we just modify the
existing /sys/devices/system/memory things to properly export what exec
needs? They're already cross-platform *and* they're updated with memory
hotplug events.
-- Dave
next prev parent reply other threads:[~2008-07-20 9:01 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-18 9:53 linux-next: Tree for July 18 Stephen Rothwell
2008-07-19 7:28 ` linux-next: Tree for July 18: warning at kernel/lockdep.c:2068 trace_hardirqs_on_caller Mariusz Kozlowski
2008-07-19 9:55 ` Vegard Nossum
[not found] ` <19f34abd0807190255x304173d4wf2bfabb2d5bce511-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-07-19 12:56 ` Pekka Enberg
2008-07-19 12:56 ` Pekka Enberg
2008-07-19 12:59 ` Vegard Nossum
[not found] ` <19f34abd0807190559y2fe5ebf9h7095793e82de3122-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-07-19 13:22 ` Stephen Rothwell
2008-07-19 13:22 ` Stephen Rothwell
2008-07-19 22:17 ` Greg KH
2008-07-19 22:17 ` Greg KH
2008-07-19 22:27 ` Vegard Nossum
[not found] ` <19f34abd0807191527u61c5ed61kffe2279c8d46915d-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-07-19 22:41 ` Greg KH
2008-07-19 22:41 ` Greg KH
2008-07-19 22:44 ` Vegard Nossum
[not found] ` <19f34abd0807191544nfd73be5nf7dde4b61992a7e8-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-07-19 22:58 ` Greg KH
2008-07-19 22:58 ` Greg KH
2008-07-19 23:11 ` Vegard Nossum
[not found] ` <19f34abd0807191611y7cabf405iad307ba79591e04f-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-07-19 23:20 ` Greg KH
2008-07-19 23:20 ` Greg KH
2008-07-20 12:51 ` Bernhard Walle
2008-07-20 9:01 ` Dave Hansen [this message]
2008-07-20 9:01 ` Dave Hansen
2008-07-20 9:01 ` Dave Hansen
2008-07-20 9:35 ` Thomas Meyer
2008-07-20 9:35 ` Thomas Meyer
2008-07-20 9:35 ` Thomas Meyer
2008-07-20 13:03 ` Bernhard Walle
2008-07-20 13:03 ` Bernhard Walle
[not found] ` <20080720150341.7cd381c2-Hxm9IJOWyO+kWa+peg0mPg@public.gmane.org>
2008-07-20 15:44 ` Bernhard Walle
2008-07-20 15:44 ` Bernhard Walle
2008-07-20 15:44 ` Bernhard Walle
2008-07-21 13:17 ` Vivek Goyal
2008-07-21 13:17 ` Vivek Goyal
2008-07-21 13:17 ` Vivek Goyal
[not found] ` <20080721131721.GB4451-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2008-07-21 13:25 ` Bernhard Walle
2008-07-21 13:25 ` Bernhard Walle
2008-07-21 13:25 ` Bernhard Walle
2008-07-21 13:39 ` Vivek Goyal
2008-07-21 13:39 ` Vivek Goyal
2008-07-21 13:47 ` Bernhard Walle
2008-07-21 14:54 ` Vivek Goyal
2008-07-21 15:00 ` Bernhard Walle
[not found] ` <20080721133937.GC4451-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2008-07-21 15:00 ` Bernhard Walle
2008-07-21 15:00 ` Bernhard Walle
2008-07-21 15:00 ` Bernhard Walle
[not found] ` <20080721170037.1a0046b1-oJhqVyG5NZ9bpigZmTR7Iw@public.gmane.org>
2008-07-22 6:15 ` Yasunori Goto
2008-07-22 6:15 ` Yasunori Goto
2008-07-22 6:15 ` Yasunori Goto
2008-07-20 12:48 ` Bernhard Walle
2008-07-20 12:48 ` Bernhard Walle
[not found] ` <20080718195352.e562a00f.sfr-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org>
2008-07-19 7:39 ` linux-next: Tree for July 18: nfs problems Mariusz Kozlowski
2008-07-19 7:39 ` Mariusz Kozlowski
2008-07-19 9:35 ` linux-next: Tree for July 18: powerpc g3 hangs Mariusz Kozlowski
2008-07-19 15:31 ` linux-next: Tree for July 18 (very early crash on x86_32) Bartlomiej Zolnierkiewicz
2008-07-20 0:20 ` linux-next: Tree for July 18: sky2 WOL broken Rafael J. Wysocki
2008-07-20 4:58 ` Stephen Hemminger
2008-07-20 15:39 ` Rafael J. Wysocki
[not found] ` <200807201739.22919.rjw-KKrjLPT3xs0@public.gmane.org>
2008-07-21 0:53 ` Rafael J. Wysocki
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=1216544462.9311.20.camel@nimitz \
--to=dave-23vcf4htsmix0ybbhkvfkdbpr1lh4cv8@public.gmane.org \
--cc=bwalle-l3A5Bk7waGM@public.gmane.org \
--cc=gregkh-l3A5Bk7waGM@public.gmane.org \
--cc=kernel-testers-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-next-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=m.kozlowski-NWF1p15JEu3VItvQsEIGlw@public.gmane.org \
--cc=mingo-X9Un+BFzKDI@public.gmane.org \
--cc=penberg-bbCR+/B0CizivPeTLB3BmA@public.gmane.org \
--cc=sfr-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org \
--cc=vegard.nossum-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=vgoyal-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.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.