From: Vivek Goyal <vgoyal@redhat.com>
To: Bernhard Walle <bwalle@suse.de>
Cc: Dave Hansen <dave@linux.vnet.ibm.com>,
Stephen Rothwell <sfr@canb.auug.org.au>,
Vegard Nossum <vegard.nossum@gmail.com>,
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
Subject: Re: linux-next: Tree for July 18: warning at kernel/lockdep.c:2068 trace_hardirqs_on_caller
Date: Mon, 21 Jul 2008 09:39:37 -0400 [thread overview]
Message-ID: <20080721133937.GC4451@redhat.com> (raw)
In-Reply-To: <20080721152539.3d8684f9@halley.suse.de>
On Mon, Jul 21, 2008 at 03:25:39PM +0200, Bernhard Walle wrote:
> * Vivek Goyal [2008-07-21 09:17]:
> >
> > Is /proc/iomem updated upon memory hotplug event.
>
> Yes. I just checked that (yesterday).
>
> I think it would make sense to extend /sys/firmware/memmap on
> hot-plugging. Just because on reboot, the firmware will see that
> memory, too, and report it. However, we need a way to discriminate the
> originally firmware-provided memory map with later added memory. I'm
> not sure how that can be done, I have to think about it.
Probably use another type of RAM identifier (System RAM (hotplug)).
But the point is, if /sys/devices/system/memory also represents all
the physical memory present in the system then it might be not be
justified to create another similar interface. (Until and unless there
is something unique about /sys/firmware/memmap).
Thanks
Vivek
WARNING: multiple messages have this Message-ID (diff)
From: Vivek Goyal <vgoyal@redhat.com>
To: Bernhard Walle <bwalle@suse.de>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
Vegard Nossum <vegard.nossum@gmail.com>, Greg KH <gregkh@suse.de>,
kexec <kexec@lists.infradead.org>,
LKML <linux-kernel@vger.kernel.org>,
Dave Hansen <dave@linux.vnet.ibm.com>,
Mariusz Kozlowski <m.kozlowski@tuxland.pl>,
Pekka Enberg <penberg@cs.helsinki.fi>,
linux-next@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
kernel-testers@vger.kernel.org
Subject: Re: linux-next: Tree for July 18: warning at kernel/lockdep.c:2068 trace_hardirqs_on_caller
Date: Mon, 21 Jul 2008 09:39:37 -0400 [thread overview]
Message-ID: <20080721133937.GC4451@redhat.com> (raw)
In-Reply-To: <20080721152539.3d8684f9@halley.suse.de>
On Mon, Jul 21, 2008 at 03:25:39PM +0200, Bernhard Walle wrote:
> * Vivek Goyal [2008-07-21 09:17]:
> >
> > Is /proc/iomem updated upon memory hotplug event.
>
> Yes. I just checked that (yesterday).
>
> I think it would make sense to extend /sys/firmware/memmap on
> hot-plugging. Just because on reboot, the firmware will see that
> memory, too, and report it. However, we need a way to discriminate the
> originally firmware-provided memory map with later added memory. I'm
> not sure how that can be done, I have to think about it.
Probably use another type of RAM identifier (System RAM (hotplug)).
But the point is, if /sys/devices/system/memory also represents all
the physical memory present in the system then it might be not be
justified to create another similar interface. (Until and unless there
is something unique about /sys/firmware/memmap).
Thanks
Vivek
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2008-07-21 13:39 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
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 [this message]
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=20080721133937.GC4451@redhat.com \
--to=vgoyal@redhat.com \
--cc=bwalle@suse.de \
--cc=dave@linux.vnet.ibm.com \
--cc=gregkh@suse.de \
--cc=kernel-testers@vger.kernel.org \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=m.kozlowski@tuxland.pl \
--cc=mingo@elte.hu \
--cc=penberg@cs.helsinki.fi \
--cc=sfr@canb.auug.org.au \
--cc=vegard.nossum@gmail.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 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.