Prev: [PATCH] Staging: asus_oled: Remove space character mixed in with tab indentation.
Next: madness, was Re: [PATCH 2/2] Macintosh: fix coding style issues in adb.c This is a patch to the adb.c file that cleans up many warnings found by the checkpatch.pl tool
From: Jamie Lokier on 12 Mar 2010 18:40
Andrew Morton wrote:
> > I meant with the "classic" use of mtdoops, therefore with a flash
> > partition without use MTD_RAM. Using MTD_RAM, it's more or less the
> > same thing, with the exception of "where" you want deploy the log. For
> > example: if in your system you have got a nvram you can use it without
> > problem, you need to specify the address of the nvram to the module.
> > Very simple. I think it's a small driver but very useful, feedback
> > from other embedded guys are welcome.
>
> Seems sensible to me. If you have a machine whose memory is persistent
> across reboots then you reserve an arbitrary 4k hunk of memory for
> collecting oops traces, yes?

Me too, I think it's a great idea which sounds simpler to use than MTD-RAM.

> What tools are used for displaying that memory on the next boot? How
> do those tools distinguish between "valid oops trace" and "garbage
> because it was just powered on"? A magic signature?
>
> Should the kernel provide the 4k of memory rather than (or in addition
> to) requiring that the system administrator reserve it and tell the
> kernel about it? That'd be a matter of creating a linker section which
> isn't cleared out by the startup code.

It's good if there's an option to make the location not vary between
kernels, and be known to the bootloader.

Then you can debug kernels which always crash during boot, by either
booting into another kernel which works and looking at the oops, or by
a bootloader command to dump it.

That'd be fine if the kernel link scripts choose the address, as long
as it's consistent between different compiles and similar
configurations. That'd be a bit simpler than the admin having to know
the memory map well enough to choose an address.

-- Jamie
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Marco Stornelli on 13 Mar 2010 04:00
Il 12/03/2010 23:48, Andrew Morton ha scritto:
> On Wed, 10 Mar 2010 13:15:25 +0100
> Marco Stornelli <marco.stornelli(a)gmail.com> wrote:
>
>> 2010/3/10 Yuasa Yoichi <yuasa(a)linux-mips.org>:
>>> 2010/3/10 Marco Stornelli <marco.stornelli(a)gmail.com>:
>>>> 2010/3/10 Yuasa Yoichi <yuasa(a)linux-mips.org>:
>> I meant with the "classic" use of mtdoops, therefore with a flash
>> partition without use MTD_RAM. Using MTD_RAM, it's more or less the
>> same thing, with the exception of "where" you want deploy the log. For
>> example: if in your system you have got a nvram you can use it without
>> problem, you need to specify the address of the nvram to the module.
>> Very simple. I think it's a small driver but very useful, feedback
>> from other embedded guys are welcome.
>
> Seems sensible to me. If you have a machine whose memory is persistent
> across reboots then you reserve an arbitrary 4k hunk of memory for
> collecting oops traces, yes?

Yes.

>
> What tools are used for displaying that memory on the next boot? How
> do those tools distinguish between "valid oops trace" and "garbage
> because it was just powered on"? A magic signature?

For my test I used the program devmem2 to dump the log. In general, you
can read the memory via /dev/mem. There's an header plus a timestamp of
the log. The memory is initialized with blank spaces and the size of the
record is fixed at 4k, so if a program/script doesn't find the header at
next 4k, it means there's garbage and it can stop the read operation.

>
> Should the kernel provide the 4k of memory rather than (or in addition
> to) requiring that the system administrator reserve it and tell the
> kernel about it? That'd be a matter of creating a linker section which
> isn't cleared out by the startup code.
>
>

Yes, it can be an option. My first idea was to write a "general" driver,
with an address in input that it can be related to the reserved RAM as
an NVRAM in the system, however it can be a good idea, why not.

Marco
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Marco Stornelli on 13 Mar 2010 04:00
Il 13/03/2010 00:31, Jamie Lokier ha scritto:
> That'd be fine if the kernel link scripts choose the address, as long
> as it's consistent between different compiles and similar
> configurations. That'd be a bit simpler than the admin having to know
> the memory map well enough to choose an address.
>
> -- Jamie
>

I agree, but the bootloader should be aware of it. I mean, usually
bootloaders at boot, reset the RAM, so you have to tell to the
bootloader that you are using a piece of RAM as persistent RAM, for
example U-Boot has got a specific option CONFIG_PRAM. I don't know if
all the process can be completely transparent to the admin in all
situations.

Marco
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Geert Uytterhoeven on 13 Mar 2010 10:00
On Fri, Mar 12, 2010 at 23:48, Andrew Morton <akpm(a)linux-foundation.org> wrote:
> On Wed, 10 Mar 2010 13:15:25 +0100
> Marco Stornelli <marco.stornelli(a)gmail.com> wrote:
>
>> 2010/3/10 Yuasa Yoichi <yuasa(a)linux-mips.org>:
>> > 2010/3/10 Marco Stornelli <marco.stornelli(a)gmail.com>:
>> >> 2010/3/10 Yuasa Yoichi <yuasa(a)linux-mips.org>:
>> >>> Hi,
>> >>>
>> >>> 2010/3/10 Marco Stornelli <marco.stornelli(a)gmail.com>:
>> >>>> Ramoops, like mtdoops, can log oops/panic information but in RAM.
>> >>>
>> >>> What is different from mtdoops + mtd-ram?
>> >>>
>> >>> Yoichi
>> >>>
>> >>
>> >> It can be used in a very easy way with persistent RAM for systems
>> >> without flash support. For this systems, with this driver, it's no
>> >> more needed add to the kernel the mtd subsystem with advantage in
>> >> footprint as I said in the description.
>> >
>> > right.
>> > But,
>> >
>> >> In addition, you can save
>> >> flash space and store this information only in RAM. I think it's very
>> >> useful for embedded systems.
>> >
>> > CONFIG_MTD_RAM uses only RAM.
>> > I think there's no big difference about this point.
>> >
>>
>> I meant with the "classic" use of mtdoops, therefore with a flash
>> partition without use MTD_RAM. Using MTD_RAM, it's more or less the
>> same thing, with the exception of "where" you want deploy the log. For
>> example: if in your system you have got a nvram you can use it without
>> problem, you need to specify the address of the nvram to the module.
>> Very simple. I  think it's a small driver but very useful, feedback
>> from other embedded guys are welcome.
>
> Seems sensible to me.  If you have a machine whose memory is persistent
> across reboots then you reserve an arbitrary 4k hunk of memory for
> collecting oops traces, yes?
>
> What tools are used for displaying that memory on the next boot?  How
> do those tools distinguish between "valid oops trace" and "garbage
> because it was just powered on"?  A magic signature?

On Amiga, `debug=mem' enables something like that, cfr. git grep dmesg
arch/m68k.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert(a)linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Jamie Lokier on 14 Mar 2010 23:10
Marco Stornelli wrote:
> Il 13/03/2010 00:31, Jamie Lokier ha scritto:
> > That'd be fine if the kernel link scripts choose the address, as long
> > as it's consistent between different compiles and similar
> > configurations. That'd be a bit simpler than the admin having to know
> > the memory map well enough to choose an address.
> >
> > -- Jamie
> >
>
> I agree, but the bootloader should be aware of it. I mean, usually
> bootloaders at boot, reset the RAM, so you have to tell to the
> bootloader that you are using a piece of RAM as persistent RAM, for
> example U-Boot has got a specific option CONFIG_PRAM. I don't know if
> all the process can be completely transparent to the admin in all
> situations.

Sometimes you can't change the bootloader (they don't always come with
source code). Or you could, but you don't want to risk it (there
isn't always a way to recover if you break it).

Obviously then the feature is only useful when the bootloader doesn't
clear all the RAM :-)

On slow boards in consumer devices, they sometimes avoid clearing the
RAM because that adds measurable boot time.

-- Jamie
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: [PATCH] Staging: asus_oled: Remove space character mixed in with tab indentation.
Next: madness, was Re: [PATCH 2/2] Macintosh: fix coding style issues in adb.c This is a patch to the adb.c file that cleans up many warnings found by the checkpatch.pl tool