Hello.
> > > > 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. Ho
* Vivek Goyal [2008-07-21 09:39]:
>
> 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 /s
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 o
* 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 nee
On Sun, Jul 20, 2008 at 02:01:02AM -0700, Dave Hansen wrote:
> 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.
* Bernhard Walle <[EMAIL PROTECTED]> [2008-07-20 15:03]:
>
> Because I didn't know that interface. And because I don't see that
> interface on my two systems that I just checked. i386 and x86-64. What
> do I have to do to enable that interface?
That interface depends on CONFIG_MEMORY_HOTPLUG. But
* Dave Hansen <[EMAIL PROTECTED]> [2008-07-20 02:01]:
>
> 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/
* Greg KH <[EMAIL PROTECTED]> [2008-07-19 16:20]:
>
> > Maybe the firmware memmap code can simply run a little later in the
> > boot sequence?
>
> Possibly. I wonder why this is only a problem on your machine and not
> on anything that Ingo tested?
It also was on my machine when I tested it on
* "Vegard Nossum" <[EMAIL PROTECTED]> [2008-07-20 00:44]:
>
> On Sun, Jul 20, 2008 at 12:27 AM, Vegard Nossum <[EMAIL PROTECTED]> wrote:
> >>> commit 0e3638d1e04040121af00195f7e4628078246489
> >>> Author: Dave Hansen <[EMAIL PROTECTED]>
> >>> Date: Thu Mar 16 17:30:16 2006 -0800
> >>>
> >>> w
Am Sonntag, den 20.07.2008, 02:01 -0700 schrieb Dave Hansen:
> 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...
>
On that thread?
http://lkml.org/lkml/200
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 variou
On Sun, Jul 20, 2008 at 01:11:36AM +0200, Vegard Nossum wrote:
> On Sun, Jul 20, 2008 at 12:58 AM, Greg KH <[EMAIL PROTECTED]> wrote:
> >> firmware_map_add_early() is using bootmem for the allocation. So yes,
> >> I guess it should possible to use kobjects here. That said, this code
> >> is in fact
On Sun, Jul 20, 2008 at 12:58 AM, Greg KH <[EMAIL PROTECTED]> wrote:
>> firmware_map_add_early() is using bootmem for the allocation. So yes,
>> I guess it should possible to use kobjects here. That said, this code
>> is in fact fairly recent:
>>
>> commit 69ac9cd629ca96e59f34eb4ccd12d00b2c8276a7
>
On Sun, Jul 20, 2008 at 12:44:38AM +0200, Vegard Nossum wrote:
> On Sun, Jul 20, 2008 at 12:27 AM, Vegard Nossum <[EMAIL PROTECTED]> wrote:
> >>> commit 0e3638d1e04040121af00195f7e4628078246489
> >>> Author: Dave Hansen <[EMAIL PROTECTED]>
> >>> Date: Thu Mar 16 17:30:16 2006 -0800
> >>>
> >>>
On Sun, Jul 20, 2008 at 12:27 AM, Vegard Nossum <[EMAIL PROTECTED]> wrote:
>>> commit 0e3638d1e04040121af00195f7e4628078246489
>>> Author: Dave Hansen <[EMAIL PROTECTED]>
>>> Date: Thu Mar 16 17:30:16 2006 -0800
>>>
>>> warn when statically-allocated kobjects are used
>>>
>>> ..which only exi
On Sun, Jul 20, 2008 at 12:27:26AM +0200, Vegard Nossum wrote:
> On Sun, Jul 20, 2008 at 12:17 AM, Greg KH <[EMAIL PROTECTED]> wrote:
> > On Sat, Jul 19, 2008 at 02:59:12PM +0200, Vegard Nossum wrote:
> >> On Sat, Jul 19, 2008 at 11:55 AM, Vegard Nossum <[EMAIL PROTECTED]> wrote:
> >> > What I don'
On Sun, Jul 20, 2008 at 12:17 AM, Greg KH <[EMAIL PROTECTED]> wrote:
> On Sat, Jul 19, 2008 at 02:59:12PM +0200, Vegard Nossum wrote:
>> On Sat, Jul 19, 2008 at 11:55 AM, Vegard Nossum <[EMAIL PROTECTED]> wrote:
>> > What I don't get here is how SLUB can be used this early in the boot
>> > process.
On Sat, Jul 19, 2008 at 02:59:12PM +0200, Vegard Nossum wrote:
> On Sat, Jul 19, 2008 at 11:55 AM, Vegard Nossum <[EMAIL PROTECTED]> wrote:
> > What I don't get here is how SLUB can be used this early in the boot
> > process. Notice that this is still miles away from the
> >
> >SLUB: Genslabs=1
Hi Vegard,
On Sat, 19 Jul 2008 14:59:12 +0200 "Vegard Nossum" <[EMAIL PROTECTED]> wrote:
>
> Ehe... and this is the reason why: The code was added by this patch:
>
> commit 0e3638d1e04040121af00195f7e4628078246489
> Author: Dave Hansen <[EMAIL PROTECTED]>
> Date: Thu Mar 16 17:30:16 2006 -0800
On Sat, Jul 19, 2008 at 11:55 AM, Vegard Nossum <[EMAIL PROTECTED]> wrote:
> What I don't get here is how SLUB can be used this early in the boot
> process. Notice that this is still miles away from the
>
>SLUB: Genslabs=12, HWalign=128, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
>
> line, which
On Sat, 2008-07-19 at 11:55 +0200, Vegard Nossum wrote:
> On Sat, Jul 19, 2008 at 9:28 AM, Mariusz Kozlowski
> <[EMAIL PROTECTED]> wrote:
> > Hello,
> >
> >I get this on my x86_32 laptop.
> >
> > [ cut here ]
> > WARNING: at /home/mako/linux/lkt/sources/linux-next/ke
On Sat, Jul 19, 2008 at 9:28 AM, Mariusz Kozlowski
<[EMAIL PROTECTED]> wrote:
> Hello,
>
>I get this on my x86_32 laptop.
>
> [ cut here ]
> WARNING: at /home/mako/linux/lkt/sources/linux-next/kernel/lockdep.c:2068
> trace_hardirqs_on_caller+0xdc/0x128()
> Modules l
22 matches
Mail list logo
