Re: linux-next: Tree for July 18: warning at kernel/lockdep.c:2068 trace_hardirqs_on_caller

Re: linux-next: Tree for July 18: warning at kernel/lockdep.c:2068 trace_hardirqs_on_caller

[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...

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

Re: linux-next: Tree for July 18: warning at kernel/lockdep.c:2068 trace_hardirqs_on_caller

[Thomas Meyer]

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/2008/7/15/108




_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: linux-next: Tree for July 18: warning at kernel/lockdep.c:2068 trace_hardirqs_on_caller

[Bernhard Walle]

* Dave Hansen <dave@linux.vnet.ibm.com> [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/firmware/memmap
> 
> is really being done at the wrong level.

I posted that patches multiple times. They were reviewed by the kdump
maintainer and by the kexec maintainer. Why didn't you mention it
*there* that this is the wrong way?

> I don't, for instance, see
> *any* reference to memory hotplug in these patches.

Right. The idea was to add memory hotplugging later. I decided to
create the patch series, get some review, and then fix the rest of the
systems that use memory hot-plugging. So, do you see a problem (in
theory) to add memory and remove memory in that sysfs interface? Of
course the code must be extended to handle modifications in the linked
list afterwards. Yes, I should have made that extension just after the
patch went into tip. Unfortunately, I didn't have time so far.

> Secondly, why don't we just modify the existing /sys/devices/system/memory

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?

Does that interface export the *used* memory or just export the memory
that is available? Because exactly that was the reason why I made that
modification -- because kexec needs to know the *available* memory even
if that memory is disabled via 'memmap' or 'mem' command line
parameters.



Bernhard
-- 
Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: linux-next: Tree for July 18: warning at kernel/lockdep.c:2068 trace_hardirqs_on_caller

[Bernhard Walle]

* Bernhard Walle <bwalle@suse.de> [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 given to that
dependency list,

128 config MEMORY_HOTPLUG
129         bool "Allow for memory hot-add"
130         depends on SPARSEMEM || X86_64_ACPI_NUMA
131         depends on HOTPLUG && !HIBERNATION && ARCH_ENABLE_MEMORY_HOTPLUG
132         depends on (IA64 || X86 || PPC64 || SUPERH || S390)

that interface is off on *many* systems (i386, x86_64), so we can't rely
on that interface in kexec. I think on POWER it's much more common than
on PC architectures.



Bernhard
-- 
Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: linux-next: Tree for July 18: warning at kernel/lockdep.c:2068 trace_hardirqs_on_caller

[Vivek Goyal]

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.  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.

If memory is just being added and not being removed then kexec will
continue to work. Just that newly added memory will not be visible to
second kernel. (Unless we start modifying /sys/firmware/memmap upon 
memory hotplug event).

Is /proc/iomem updated upon memory hotplug event. All these years, kexec
has been using that interace.

> 
> 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.  

As bernhard mentioned that above interface has got long dependeny list
and will not work for kexec until and unless we get rid of those 
dependencies.

What does /sys/devices/system/memory represent? All the physical memory
present in the system or all the physical memory being used by kernel
(for example, memory limited by command line options mem=).

If it represents all the physical memory present in the system then it
might make sense to not create another interface but to use this one for
kexec. (But we shall have to get rid of long list of dependencies so that
it can gel wil more universal appeal of kexec).

Do you think that we can decouple /sys/devices/system/memory interface with
CONFIG_MEMORY_HOTPLUG?

Thanks
Vivek

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: linux-next: Tree for July 18: warning at kernel/lockdep.c:2068 trace_hardirqs_on_caller

[Bernhard Walle]

* 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.


Bernhard
-- 
Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: linux-next: Tree for July 18: warning at kernel/lockdep.c:2068 trace_hardirqs_on_caller

[Vivek Goyal]

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

Re: linux-next: Tree for July 18: warning at kernel/lockdep.c:2068 trace_hardirqs_on_caller

[Bernhard Walle]

* Vivek Goyal [2008-07-21 09:39]:
> 
> 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).

But I don't see anything like a physical address there:

  /sys/devices/system/memory/memory2:
  -r--r--r-- 1 root root 4096 2008-07-21 15:45 phys_device
  -r--r--r-- 1 root root 4096 2008-07-21 15:45 phys_index
  -rw-r--r-- 1 root root 4096 2008-07-21 15:45 state

(on a PPC64 machine where SUSE kernel has that interface enabled by
default).


Bernhard
-- 
Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: linux-next: Tree for July 18: warning at kernel/lockdep.c:2068 trace_hardirqs_on_caller

[Vivek Goyal]

On Mon, Jul 21, 2008 at 03:47:33PM +0200, Bernhard Walle wrote:
> * Vivek Goyal [2008-07-21 09:39]:
> > 
> > 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).
> 
> But I don't see anything like a physical address there:
> 
>   /sys/devices/system/memory/memory2:
>   -r--r--r-- 1 root root 4096 2008-07-21 15:45 phys_device
>   -r--r--r-- 1 root root 4096 2008-07-21 15:45 phys_index
>   -rw-r--r-- 1 root root 4096 2008-07-21 15:45 state
> 
> (on a PPC64 machine where SUSE kernel has that interface enabled by
> default).
> 
> 
Do you want to respond to lkml and to dave hansen so that he can respond
back. In this mail only kexec mailing list is there.

Thanks
Vivek

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: linux-next: Tree for July 18: warning at kernel/lockdep.c:2068 trace_hardirqs_on_caller

[Bernhard Walle]

* Vivek Goyal [2008-07-21 10:54]:
>
> On Mon, Jul 21, 2008 at 03:47:33PM +0200, Bernhard Walle wrote:
> > * Vivek Goyal [2008-07-21 09:39]:
> > > 
> > > 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).
> > 
> > But I don't see anything like a physical address there:
> > 
> >   /sys/devices/system/memory/memory2:
> >   -r--r--r-- 1 root root 4096 2008-07-21 15:45 phys_device
> >   -r--r--r-- 1 root root 4096 2008-07-21 15:45 phys_index
> >   -rw-r--r-- 1 root root 4096 2008-07-21 15:45 state
> > 
> > (on a PPC64 machine where SUSE kernel has that interface enabled by
> > default).
> > 
> > 
> Do you want to respond to lkml and to dave hansen so that he can respond
> back. In this mail only kexec mailing list is there.

Group reply vs. reply. Thanks for noticing. :)



Bernhard
-- 
Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: linux-next: Tree for July 18: warning at kernel/lockdep.c:2068 trace_hardirqs_on_caller

[Bernhard Walle]

* 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 /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).

But I don't see anything like a physical address there:

  /sys/devices/system/memory/memory2:
  -r--r--r-- 1 root root 4096 2008-07-21 15:45 phys_device
  -r--r--r-- 1 root root 4096 2008-07-21 15:45 phys_index
  -rw-r--r-- 1 root root 4096 2008-07-21 15:45 state

(on a PPC64 machine where SUSE kernel has that interface enabled by
default).


Bernhard
-- 
Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: linux-next: Tree for July 18: warning at kernel/lockdep.c:2068 trace_hardirqs_on_caller

[Yasunori Goto]

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. 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).
> 
> But I don't see anything like a physical address there:
> 
>   /sys/devices/system/memory/memory2:
>   -r--r--r-- 1 root root 4096 2008-07-21 15:45 phys_device
>   -r--r--r-- 1 root root 4096 2008-07-21 15:45 phys_index
>   -rw-r--r-- 1 root root 4096 2008-07-21 15:45 state
> 
> (on a PPC64 machine where SUSE kernel has that interface enabled by
> default).

I wrote about them Documentation/memory-hotplug.txt. Please see it.

But I think /sys/firmware/memmap is better for kexec than using them.
They are made for each sections whose size is fixed on each architecture.
There is no information about areas which are occupied by firmware, and
its fixed size directories are not suitable to show them.


BTW, does kexec needs the information about not only hot-added normal memory
but also "hot-added occupied (reserved) memory by firmware"?
Fujitsu has ia64 box which can add memory. The information about memory
area is notified via _CRS method of ACPI. Our firmware team said that
there was no interface to notify the area which was occupied by firmware.
So, _CRS shows only normal (not-reserved) memory area. It means OS can't know
reserved memory which is hot-added.

If kexec has to know those reserved area, then it is very bad news for me. :-(


Thanks.

-- 
Yasunori Goto 



_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec