* Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem
From: Jamie Lokier @ 2009-06-24 17:47 UTC (permalink / raw)
To: Pavel Machek
Cc: Marco, Tim Bird, Linux Embedded, Linux Kernel, Linux FS Devel,
Daniel Walker
In-Reply-To: <20090623182941.GA2045@elf.ucw.cz>
Pavel Machek wrote:
> On Tue 2009-06-23 20:07:23, Marco wrote:
> > You are talked about journaling. This schema works well for a disk, but
> > what about a piece of ram? What about a crazy kernel that write in that
> > area for a bug? Do you remember for example the e1000e bug? It's not
>
> I believe you need both journaling *and* write protection. How do you
> handle power fault while writing data?
I think this is basically right.
write protection for the crazy kernels, and journalling for
powerfail/crash during updates.
Journalling can be extremely simple. It can be just one memory block
at a fixed location, double-buffering all writes.
Pramfs already has checksums, which makes that easier. You just write
to the buffer area first, with checksum, then write to the final area.
Mount looks at the buffer area, and if the checksum is fine, copies
the contents to the destination block.
That's all it takes to be resistant against power failures and crashes
during writes. Probably <100 lines of code.
-- Jamie
^ permalink raw reply
* Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem
From: Pavel Machek @ 2009-06-24 17:46 UTC (permalink / raw)
To: Marco
Cc: tim.bird, jamie, Linux Embedded, Linux Kernel, Linux FS Devel,
Daniel Walker
In-Reply-To: <4A425907.2060105@gmail.com>
On Wed 2009-06-24 18:49:11, Marco wrote:
> >> Pavel Machek wrote:
> >>> On Mon 2009-06-22 14:50:01, Tim Bird wrote:
> >>>> Pavel Machek wrote:
> >>>>>> block of fast non-volatile RAM that need to access data on it using a
> >>>>>> standard filesytem interface."
> >>>>> Turns a block of fast RAM into 13MB/sec disk. Hmm. I believe you are
> >>>>> better with ext2.
> >>>> Not if you want the RAM-based filesystem to persist over a kernel
> >>>> invocation.
> >>> Yes, you'll need to code Persistent, RAM-based _block_device_.
> >> First of all I have to say that I'd like to update the site and make it
> >> clearer but at the moment it's not possible because I'm not the admin
> >> and I've already asked to the sourceforge support to have this possibility.
> >>
> >> About the comments: sincerely I don't understand the comments. We have
> >> *already* a fs that takes care to remap a piace of ram (ram, sram,
> >> nvram, etc.), takes care of caching problems, takes care of write
> >
> > Well, it looks pramfs design is confused. 13MB/sec shows that caching
> > _is_ useful for pramfs. So...?
>
> caching problems means to avoid filesystem corruption, so dirty pages in
> the page cache are not allowed to be written back to the backing-store
> RAM. It's clear that there is a performance penalty. This penalty should
> be reduced by the access speed of the RAM, however the performance are
> not important for this special fs as Tim Bird said, so this question is
> not relevant for me. If this issue is not clear enough on the web site,
> I hope I can update the information in the future.
Yes, please update the pages...
> >> You are talked about journaling. This schema works well for a disk, but
> >> what about a piece of ram? What about a crazy kernel that write in that
> >> area for a bug? Do you remember for example the e1000e bug? It's not
> >
> > I believe you need both journaling *and* write protection. How do you
> > handle power fault while writing data?
>
> Ah now the write protection is a "needed feature", in your previous
> comment you talked about why not use ext2/3.......
write protection should be handled at block device layer, not
filesystem layer. So yes, use ext2.
You still did not explain how you avoid the need for journalling...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem
From: Jamie Lokier @ 2009-06-24 17:41 UTC (permalink / raw)
To: Marco; +Cc: Linux Embedded, Linux Kernel, Linux FS Devel, Daniel Walker
In-Reply-To: <4A37EF4A.1080006@gmail.com>
Marco wrote:
> > Second question: what happens if the system crashing _during_ a write
> > to a file. Does it mean that file will fail it's checksum when it's
> > read at the next boot?
> >
> > Maybe files aren't so important. What about when you write a file,
> > and then rename it over an existing file to replace it. (E.g. a
> > config file), and the system crashes _during_ the rename? At the next
> > boot, is it guaranteed to see either the old or the new file, or can
> > the directory be corrupt / fail it's checksum?
>
> First of all I have to explain better the current policy: the checksum
> works at inode and superblock level and currently there isn't a recovery
> function as the journaling. About the superblock it's easy to use a
> redundant policy to be more robust.
To be honest, superblock robustness is less of a concern. The real
concern is losing file or directory contents, so it can't be used to
store persistent configuration data, only debugging logs.
> About the inode, at the moment when the checksum doesn't match the
> inode it's marked as bad calling the function make_bad_inode().
Let's see if I understand right.
If it lose power when writing to a file, after boot the file is likely
to be marked bad and so return -EIO instead of any file contents?
If it loses power when doing atomic rename (to replace config files,
for example), it's likely that the whole /pramfs/configs/ directory
will be corrupt, because the rename is writing to the directory inode,
so you lose access to all names in that directory?
That sounds like it can't be used for persistent configuration data.
If a directory is marked as bad, or a file-inode in it is marked bad,
can you even rmdir it to clean up and start again?
Thanks,
-- Jamie
^ permalink raw reply
* Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem
From: Marco @ 2009-06-24 17:38 UTC (permalink / raw)
To: pavel
Cc: tim.bird, jamie, Linux Embedded, Linux Kernel, Linux FS Devel,
Daniel Walker
In-Reply-To: <4A425907.2060105@gmail.com>
>>> Pavel Machek wrote:
>>>> On Mon 2009-06-22 14:50:01, Tim Bird wrote:
>>>>> Pavel Machek wrote:
>>>>>>> block of fast non-volatile RAM that need to access data on it using a
>>>>>>> standard filesytem interface."
>>>>>> Turns a block of fast RAM into 13MB/sec disk. Hmm. I believe you are
>>>>>> better with ext2.
>>>>> Not if you want the RAM-based filesystem to persist over a kernel
>>>>> invocation.
>>>> Yes, you'll need to code Persistent, RAM-based _block_device_.
>>> First of all I have to say that I'd like to update the site and make it
>>> clearer but at the moment it's not possible because I'm not the admin
>>> and I've already asked to the sourceforge support to have this possibility.
>>>
>>> About the comments: sincerely I don't understand the comments. We have
>>> *already* a fs that takes care to remap a piace of ram (ram, sram,
>>> nvram, etc.), takes care of caching problems, takes care of write
>> Well, it looks pramfs design is confused. 13MB/sec shows that caching
>> _is_ useful for pramfs. So...?
>
> caching problems means to avoid filesystem corruption, so dirty pages in
> the page cache are not allowed to be written back to the backing-store
> RAM. It's clear that there is a performance penalty. This penalty should
> be reduced by the access speed of the RAM, however the performance are
> not important for this special fs as Tim Bird said, so this question is
> not relevant for me. If this issue is not clear enough on the web site,
> I hope I can update the information in the future.
>
>>> You are talked about journaling. This schema works well for a disk, but
>>> what about a piece of ram? What about a crazy kernel that write in that
>>> area for a bug? Do you remember for example the e1000e bug? It's not
>> I believe you need both journaling *and* write protection. How do you
>> handle power fault while writing data?
>> Pavel
>
> Ah now the write protection is a "needed feature", in your previous
> comment you talked about why not use ext2/3.......
>
> Marco
>
Just for your information I tried the same test with pc in a virtual machine with 32MB of RAM:
Version 1.03e ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size:chnk K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
hostname 15M:1k 14156 99 128779 100 92240 100 11669 100 166242 99 80058 82
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
4 2842 99 133506 104 45088 101 2787 99 79581 101 58212 102
These data are the proof of the importance of the environment, workload and so on when we talk
about benchmark. Your consideration are really superficial.
Marco
^ permalink raw reply
* Re: [PATCH 06/14] Pramfs: Include files
From: Marco @ 2009-06-24 16:49 UTC (permalink / raw)
To: Arnd Bergmann
Cc: David Woodhouse, Jörn Engel, Sam Ravnborg, Tim Bird,
Chris Simmonds, Linux FS Devel, Linux Embedded, Linux Kernel
In-Reply-To: <200906241730.37151.arnd@arndb.de>
Arnd Bergmann wrote:
> On Wednesday 24 June 2009, Marco Stornelli wrote:
>>> Actually, reading from /dev/mem is only valid on real RAM. If the nvram
>>> is part of an IO memory mapping, you have to do mmap()+memcpy() rather
>>> than read(). So dd won't do it, but it's still easy to read from user
>>> space.
>> For "security" reasons pram reserve the region of memory with
>> reserve_mem_region_exclusive().....
>
> That will only prevent other device drivers from stepping on it,
> /dev/mem does not care about mem_region reservations.
>
> Arnd <><
>
Userland may not map this resource, so /dev/mem and the sysfs MMIO
access will not be allowed. This restriction depends on STRICT_DEVMEM
option. It's true that currently is only implemented in the x86 world.
Marco
^ permalink raw reply
* Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem
From: Marco @ 2009-06-24 16:49 UTC (permalink / raw)
To: pavel
Cc: tim.bird, jamie, Linux Embedded, Linux Kernel, Linux FS Devel,
Daniel Walker
In-Reply-To: <4a4254e2.09c5660a.109d.46f8@mx.google.com>
>> Pavel Machek wrote:
>>> On Mon 2009-06-22 14:50:01, Tim Bird wrote:
>>>> Pavel Machek wrote:
>>>>>> block of fast non-volatile RAM that need to access data on it using a
>>>>>> standard filesytem interface."
>>>>> Turns a block of fast RAM into 13MB/sec disk. Hmm. I believe you are
>>>>> better with ext2.
>>>> Not if you want the RAM-based filesystem to persist over a kernel
>>>> invocation.
>>> Yes, you'll need to code Persistent, RAM-based _block_device_.
>> First of all I have to say that I'd like to update the site and make it
>> clearer but at the moment it's not possible because I'm not the admin
>> and I've already asked to the sourceforge support to have this possibility.
>>
>> About the comments: sincerely I don't understand the comments. We have
>> *already* a fs that takes care to remap a piace of ram (ram, sram,
>> nvram, etc.), takes care of caching problems, takes care of write
>
> Well, it looks pramfs design is confused. 13MB/sec shows that caching
> _is_ useful for pramfs. So...?
caching problems means to avoid filesystem corruption, so dirty pages in
the page cache are not allowed to be written back to the backing-store
RAM. It's clear that there is a performance penalty. This penalty should
be reduced by the access speed of the RAM, however the performance are
not important for this special fs as Tim Bird said, so this question is
not relevant for me. If this issue is not clear enough on the web site,
I hope I can update the information in the future.
>
>> You are talked about journaling. This schema works well for a disk, but
>> what about a piece of ram? What about a crazy kernel that write in that
>> area for a bug? Do you remember for example the e1000e bug? It's not
>
> I believe you need both journaling *and* write protection. How do you
> handle power fault while writing data?
> Pavel
Ah now the write protection is a "needed feature", in your previous
comment you talked about why not use ext2/3.......
Marco
^ permalink raw reply
* Re: [PATCH 06/14] Pramfs: Include files
From: Arnd Bergmann @ 2009-06-24 15:30 UTC (permalink / raw)
To: Marco Stornelli
Cc: David Woodhouse, Jörn Engel, Sam Ravnborg, Tim Bird,
Chris Simmonds, Linux FS Devel, Linux Embedded, Linux Kernel
In-Reply-To: <2ea1731b0906232332n2488d452p27419eac7edab7e4@mail.gmail.com>
On Wednesday 24 June 2009, Marco Stornelli wrote:
> > Actually, reading from /dev/mem is only valid on real RAM. If the nvram
> > is part of an IO memory mapping, you have to do mmap()+memcpy() rather
> > than read(). So dd won't do it, but it's still easy to read from user
> > space.
>
> For "security" reasons pram reserve the region of memory with
> reserve_mem_region_exclusive().....
That will only prevent other device drivers from stepping on it,
/dev/mem does not care about mem_region reservations.
Arnd <><
^ permalink raw reply
* Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem
From: Pavel Machek @ 2009-06-24 14:21 UTC (permalink / raw)
To: Marco
Cc: Jamie Lokier, Linux Embedded, Linux Kernel, Linux FS Devel,
Daniel Walker
In-Reply-To: <4A44FDDB.1000902@gmail.com>
> >>> If it loses power when doing atomic rename (to replace config files,
> >>> for example), it's likely that the whole /pramfs/configs/ directory
> >>> will be corrupt, because the rename is writing to the directory inode,
> >>> so you lose access to all names in that directory?
> >>>
> >>> That sounds like it can't be used for persistent configuration data.
> >> It's true from this point of view currently there is a lack for this
> >> and it needs a bit of effort to resolve this problem. >From this
> >> point of view I'd like to point out that I know that there was some
> >> aspects to study in a deeper way, so I'll need of more then one
> >> review :) but since this fs has been abandoned since 2004 and it
> >> hadn't ever reviewed, it was important to do a serious review with
> >> the kernel community to understand all the problems.
> >
> > That's reasonable.
> >
> > What do you think of my suggestion to double-buffer writes using a
> > single fixed position block, as explained elsewhere in this thread?
> >
> > It should give the power fail safety with very little code. I don't
> > know how much it would slwo down writing. That probably depends on
> > whether it's the checksum which is slow (which only needs to be done
> > once when double-buffering), or the writing.
>
> Yeah it can be a choice. For this fs it's important to use "simple" but
> useful mechanism. What do you exactly mean with "fixed position block"?
> A fixed position in the fs? For example superblock+inodetable+in-use
> bitmap+blocks+"double-buffering block"? Using a temp block of the same
> size of blocks used, isn't it? I agree, but I think it needs more then
> 100 lines of code. Even with this simple schema it needs a mechanism
> with a timeout to do the "commit" of the temp block, it needs a
> mechanism to read the temp block instead of the "old" block or a
> mechanism to write-back the temp block. So it can be implemented but it
> needs a bit of effort. I think I'll implement it in the next release.
I think you should really use ext3 over special block device.
Initially this filesystem was presented as fast (it is not) then you
claim it is reliable (it is not). If you want it to get reliable
you'll need journalling+fsck. Good luck.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: Using UART in kernel driver code on AT91SAM9260
From: Stefan Schoenleitner @ 2009-06-24 9:59 UTC (permalink / raw)
To: linux-embedded
In-Reply-To: <8763em3qsp.fsf@macbook.be.48ers.dk>
Hi,
Peter Korsgaard wrote:
> The input layer has serio infrastructure for this (E.G. for serial
> mice/touchscreens). Now, a speech codec doesn't have much to do with
> input devices, but it atleast clearly seperates the lowlevel uart
> communication from the speech codec handling.
>
> Have a look in drivers/input/{serio,touchscreen}.
thanks for the tip !
I'm looking to find some more serio documentation now.
If it won't work out, I guess I still have the possibility to write a
line discipline.
However, using serio seems to be more comfortable (also from a useeland
perspective).
cheers,
stefan
^ permalink raw reply
* Re: Using UART in kernel driver code on AT91SAM9260
From: Stefan Schoenleitner @ 2009-06-24 9:49 UTC (permalink / raw)
To: linux-embedded
In-Reply-To: <4A41EA93.2070904@gmail.com>
Stefan Schoenleitner wrote:
> It would be great if you could provide some links to documentation and
> example code.
I just found out that there are other kernel drivers using the serial
port as well (e.g. the SLIP or PPP drivers).
It seems that what I want to do (which is accessing the serial port from
kernel space) is called a "line discipline".
I found an article "Writing a Kernel Line Discipline" with code snippets
on http://www.linux-mag.com/id/1891
(You can find a login to this page here: http://www.bugmenot.com)
Is this the right way to go ?
^ permalink raw reply
* Re: Using UART in kernel driver code on AT91SAM9260
From: Peter Korsgaard @ 2009-06-24 9:49 UTC (permalink / raw)
To: Stefan Schoenleitner; +Cc: linux-embedded
In-Reply-To: <4A41EA93.2070904@gmail.com>
>>>>> "Stefan" == Stefan Schoenleitner <dev.c0debabe@gmail.com> writes:
Hi,
Stefan> There is the linux/drivers/char/atmel_serial.c driver which I
Stefan> could modify, so that it also includes the driver code for
Stefan> the speech codec. However, obviously that would be a really
Stefan> bad idea since it would duplicate code and completely bypass
Stefan> the linux serial port abstraction layer.
Stefan> It would be better to somehow write a speech codec driver
Stefan> that depends on the UART driver. Thus on the speech codec
Stefan> serial port no ttySn device should be created by the UART
Stefan> driver, but instead the speech codec driver should create the
Stefan> device (e.g. /dev/speechcodec0). Since the speech codec
Stefan> driver should only do speech codec specific tasks, it should
Stefan> use the UART driver to send and receive data over the serial
Stefan> port.
The input layer has serio infrastructure for this (E.G. for serial
mice/touchscreens). Now, a speech codec doesn't have much to do with
input devices, but it atleast clearly seperates the lowlevel uart
communication from the speech codec handling.
Have a look in drivers/input/{serio,touchscreen}.
--
Bye, Peter Korsgaard
^ permalink raw reply
* Using UART in kernel driver code on AT91SAM9260
From: Stefan Schoenleitner @ 2009-06-24 8:57 UTC (permalink / raw)
To: linux-embedded
Hi,
I have a speech codec chip which uses SPI for high-speed PCM data and
UART for control/compressed speech packet transfer.
While I could write a userland device driver that just uses the ttySn
serial device, I would prefer to do that in kernel space since this is
where device drivers belong.
This way a device could be created where compressed speech packets can
be read and written.
Possible device setup functions could be done with IOCTLs.
Now what is the best way to implement this ?
There is the linux/drivers/char/atmel_serial.c driver which I could
modify, so that it also includes the driver code for the speech codec.
However, obviously that would be a really bad idea since it would
duplicate code and completely bypass the linux serial port abstraction
layer.
It would be better to somehow write a speech codec driver that depends
on the UART driver.
Thus on the speech codec serial port no ttySn device should be created
by the UART driver, but instead the speech codec driver should create
the device (e.g. /dev/speechcodec0).
Since the speech codec driver should only do speech codec specific
tasks, it should use the UART driver to send and receive data over the
serial port.
I suppose this it is a common problem that higher level kernel driver
code would like to use lower level driver code.
For example there is the GPIO driver which enables high level kernel
code to use GPIO pins.
It's the same for other communication interfaces like I2C or SPI.
However, these drivers usually do not create a device, but they rather
export kernel symbols which can then be used by higher level kernel code.
Unfortunately, it doesn't seem like the relevant serial port function
symbols are exported ?
On mach-at91 it seems like the UART can be registered by calling the
relevant setup function in
linux/arch/arm/mach-at91/at91sam9260_devices.c which is
at91_register_uart().
However, once I register an uart port, also a ttySn device is created
(which I do not want).
By looking at linux/documentation/serial/driver it seems like bypassing
linux/drivers/serial/serial_core.c seems to be the right way since the
low level linux/drivers/serial/atmel_serial.c already provides the
necessary UART ops in struct uart_ops.
However, these uart_ops are not exported, so I don't know how to access
them.
Is this the right way to go ?
How could I use the low level driver but bypass serial_core ?
It would be great if you could provide some links to documentation and
example code.
cheers,
Stefan
^ permalink raw reply
* Re: [PATCH 06/14] Pramfs: Include files
From: Marco Stornelli @ 2009-06-24 6:32 UTC (permalink / raw)
To: Arnd Bergmann
Cc: David Woodhouse, Jörn Engel, Sam Ravnborg, Tim Bird,
Chris Simmonds, Linux FS Devel, Linux Embedded, Linux Kernel
In-Reply-To: <200906232355.34134.arnd@arndb.de>
2009/6/23 Arnd Bergmann <arnd@arndb.de>:
> On Tuesday 23 June 2009, David Woodhouse wrote:
>> And dd on /dev/mem would work, surely?
>
> Actually, reading from /dev/mem is only valid on real RAM. If the nvram
> is part of an IO memory mapping, you have to do mmap()+memcpy() rather
> than read(). So dd won't do it, but it's still easy to read from user
> space.
For "security" reasons pram reserve the region of memory with
reserve_mem_region_exclusive().....
>
>> I'd definitely recommend making it fixed-endian. Not doing so for JFFS2
>> was a mistake I frequently regretted.
>
> Right.
>
> Arnd <><
>
^ permalink raw reply
* Re: I:Re: [PATCH 06/14] Pramfs: Include files
From: Marco Stornelli @ 2009-06-24 6:30 UTC (permalink / raw)
To: joern
Cc: sam, tim.bird, Arnd Bergmann, linux-fsdevel, linux-embedded,
linux-kernel
In-Reply-To: <4a4130db.0af6660a.48a9.ffffdace@mx.google.com>
> On Tue, 23 June 2009 19:38:33 +0200, Marco wrote:
>>
>> dd? You haven't got any device file to have a dump. I think we're going
>> a bit out of scope. I had some doubt to support rootfs in pram and after
>> some feedback and the comments of this review I think I'll remove it
>> from the next release (to understand some aspects of this fs with the
>> kernel community was my main goal for this review). I agree to use the
>> native endian. As I said the important thing is that if an user want to
>> use it in a 64bit environment then the fs must work well and then it
>> must be designed to support even this situation, I think it's obvious.
>
> Glancing at the discussion with Pawel, I see two paths to follow. One
> is to turn pramfs into a full-features all-round general-purpose
> filesystem with mkfs, fsck, xattr and any number of additional features.
> That way lies doom, as you would compete against ext2+xip and have
> little new to offer.
>
> The other path is to make/keep pramfs as simple as possible for
> comparatively specialized purposes, like flight recorder data and dump
> information. Main selling point here is the amount of vulnerable code
> in the total package. ext2 + block layer + vfs helpers is relatively
> large and many things may go wrong in a panic situation.
>
> So I agree with you that many things expected from general purpose
> filesystems simply don't apply to pramfs. Moving mkfs into the kernel
> is a fair tradeoff, when the required code is small. Endianness is a
> different case imo. dd may not work, but a jtag probe will happily get
> you the dump to your development machine.
>
I quite agree, but I'd like to say that it was _not_ my intention to
submit a general-purpose fs comparable with ext2 or ext3.
> And even within the same box you can have more than one architecture and
> endianness. http://www.top500.org/system/9707 will show you one such
> beast, which happens to have the top bragging rights at the moment. I
> don't want to endorse such strange beasts, but there is no good reason
> not to support reading the ppc-written fs from the opteron. In fact,
> there is no reason full stop.
>
> Jörn
>
Mmm....Jtag dump makes more sense, ok in the next release I rework the
layout to have an independent endianess layout.
Marco
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: How the kernel printk works before do console_setup.
From: Tim Bird @ 2009-06-24 5:03 UTC (permalink / raw)
To: Johnny Hung; +Cc: linux-kernel, linuxppc-dev, linux-embedded
In-Reply-To: <cb9ecdfa0906232050n6fcfee31ubeee4bcd9b8c0dfe@mail.gmail.com>
Johnny Hung wrote:
> Hi All:
> I have a powerpc arch platform. The default console is ttyS1 not
> ttyS0 in the platform. My question is how the kernel print debug
> message
> like DBG before parse kernel command line and do console_setup
> function. The command line passed to kernel about console info is
> console=ttyS1.
> So kernel can not print anything before parse cmd line and initial
> console but the result is against. Anyone point me or give me a clue
> is appreciate.
Before the console is set up, the printk data is formatted
and put into the kernel log buffer, but not sent to any console.
Any messages printk'ed before that are buffered but do not
appear. When the console is initialized, then all buffered
messages are sent to the console, and subsequent printks cause
the message to go to the log buffer, but then immediately
get sent from there to the console.
Under certain conditions you can examine the log buffer of
a kernel that failed to initialize it's console, after a
warm reset of the machine, using the firmware memory dump
command.
See http://elinux.org/Kernel_Debugging_Tips#Accessing_the_printk_buffer_after_a_silent_hang_on_boot
for some tips on accessing the log buffer of a previous boot.
Note also, that if the serial console does not come up,
but the kernel successfully boots, and you can get a network
login on the machine, you can always print out the kernel log
buffer messages using 'dmesg' at a user-space shell prompt.
Hope this helps!
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
^ permalink raw reply
* How the kernel printk works before do console_setup.
From: Johnny Hung @ 2009-06-24 3:50 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev, linux-embedded
Hi All:
I have a powerpc arch platform. The default console is ttyS1 not
ttyS0 in the platform. My question is how the kernel print debug
message
like DBG before parse kernel command line and do console_setup
function. The command line passed to kernel about console info is
console=ttyS1.
So kernel can not print anything before parse cmd line and initial
console but the result is against. Anyone point me or give me a clue
is appreciate.
BR, H. Johnny
^ permalink raw reply
* Re: [PATCH 06/14] Pramfs: Include files
From: Arnd Bergmann @ 2009-06-23 21:55 UTC (permalink / raw)
To: David Woodhouse
Cc: Jörn Engel, Marco, Sam Ravnborg, Tim Bird, Chris Simmonds,
Linux FS Devel, Linux Embedded, Linux Kernel
In-Reply-To: <1245791743.25547.3517.camel@macbook.infradead.org>
On Tuesday 23 June 2009, David Woodhouse wrote:
> And dd on /dev/mem would work, surely?
Actually, reading from /dev/mem is only valid on real RAM. If the nvram
is part of an IO memory mapping, you have to do mmap()+memcpy() rather
than read(). So dd won't do it, but it's still easy to read from user
space.
> I'd definitely recommend making it fixed-endian. Not doing so for JFFS2
> was a mistake I frequently regretted.
Right.
Arnd <><
^ permalink raw reply
* Re: [PATCH 06/14] Pramfs: Include files
From: David Woodhouse @ 2009-06-23 21:15 UTC (permalink / raw)
To: Jörn Engel
Cc: Marco, Sam Ravnborg, Tim Bird, Chris Simmonds, Arnd Bergmann,
Linux FS Devel, Linux Embedded, Linux Kernel
In-Reply-To: <20090623192648.GB23119@logfs.org>
On Tue, 2009-06-23 at 21:26 +0200, Jörn Engel wrote:
> Endianness is a
> different case imo. dd may not work, but a jtag probe will happily get
> you the dump to your development machine.
And dd on /dev/mem would work, surely?
I'd definitely recommend making it fixed-endian. Not doing so for JFFS2
was a mistake I frequently regretted.
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation
^ permalink raw reply
* Re: [PATCH 06/14] Pramfs: Include files
From: Jörn Engel @ 2009-06-23 19:26 UTC (permalink / raw)
To: Marco
Cc: Sam Ravnborg, Tim Bird, Chris Simmonds, Arnd Bergmann,
Linux FS Devel, Linux Embedded, Linux Kernel
In-Reply-To: <4A411319.4020108@gmail.com>
On Tue, 23 June 2009 19:38:33 +0200, Marco wrote:
>
> dd? You haven't got any device file to have a dump. I think we're going
> a bit out of scope. I had some doubt to support rootfs in pram and after
> some feedback and the comments of this review I think I'll remove it
> from the next release (to understand some aspects of this fs with the
> kernel community was my main goal for this review). I agree to use the
> native endian. As I said the important thing is that if an user want to
> use it in a 64bit environment then the fs must work well and then it
> must be designed to support even this situation, I think it's obvious.
Glancing at the discussion with Pawel, I see two paths to follow. One
is to turn pramfs into a full-features all-round general-purpose
filesystem with mkfs, fsck, xattr and any number of additional features.
That way lies doom, as you would compete against ext2+xip and have
little new to offer.
The other path is to make/keep pramfs as simple as possible for
comparatively specialized purposes, like flight recorder data and dump
information. Main selling point here is the amount of vulnerable code
in the total package. ext2 + block layer + vfs helpers is relatively
large and many things may go wrong in a panic situation.
So I agree with you that many things expected from general purpose
filesystems simply don't apply to pramfs. Moving mkfs into the kernel
is a fair tradeoff, when the required code is small. Endianness is a
different case imo. dd may not work, but a jtag probe will happily get
you the dump to your development machine.
And even within the same box you can have more than one architecture and
endianness. http://www.top500.org/system/9707 will show you one such
beast, which happens to have the top bragging rights at the moment. I
don't want to endorse such strange beasts, but there is no good reason
not to support reading the ppc-written fs from the opteron. In fact,
there is no reason full stop.
Jörn
--
Beware of bugs in the above code; I have only proved it correct, but
not tried it.
-- Donald Knuth
^ permalink raw reply
* Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem
From: Pavel Machek @ 2009-06-23 18:29 UTC (permalink / raw)
To: Marco
Cc: Tim Bird, Jamie Lokier, Linux Embedded, Linux Kernel,
Linux FS Devel, Daniel Walker
In-Reply-To: <4A4119DB.4030203@gmail.com>
On Tue 2009-06-23 20:07:23, Marco wrote:
> Pavel Machek wrote:
> > On Mon 2009-06-22 14:50:01, Tim Bird wrote:
> >> Pavel Machek wrote:
> >>>> block of fast non-volatile RAM that need to access data on it using a
> >>>> standard filesytem interface."
> >>> Turns a block of fast RAM into 13MB/sec disk. Hmm. I believe you are
> >>> better with ext2.
> >> Not if you want the RAM-based filesystem to persist over a kernel
> >> invocation.
> >
> > Yes, you'll need to code Persistent, RAM-based _block_device_.
>
> First of all I have to say that I'd like to update the site and make it
> clearer but at the moment it's not possible because I'm not the admin
> and I've already asked to the sourceforge support to have this possibility.
>
> About the comments: sincerely I don't understand the comments. We have
> *already* a fs that takes care to remap a piace of ram (ram, sram,
> nvram, etc.), takes care of caching problems, takes care of write
Well, it looks pramfs design is confused. 13MB/sec shows that caching
_is_ useful for pramfs. So...?
> You are talked about journaling. This schema works well for a disk, but
> what about a piece of ram? What about a crazy kernel that write in that
> area for a bug? Do you remember for example the e1000e bug? It's not
I believe you need both journaling *and* write protection. How do you
handle power fault while writing data?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem
From: Marco @ 2009-06-23 18:07 UTC (permalink / raw)
To: Pavel Machek
Cc: Tim Bird, Jamie Lokier, Linux Embedded, Linux Kernel,
Linux FS Devel, Daniel Walker
In-Reply-To: <20090622215753.GA25434@elf.ucw.cz>
Pavel Machek wrote:
> On Mon 2009-06-22 14:50:01, Tim Bird wrote:
>> Pavel Machek wrote:
>>>> block of fast non-volatile RAM that need to access data on it using a
>>>> standard filesytem interface."
>>> Turns a block of fast RAM into 13MB/sec disk. Hmm. I believe you are
>>> better with ext2.
>> Not if you want the RAM-based filesystem to persist over a kernel
>> invocation.
>
> Yes, you'll need to code Persistent, RAM-based _block_device_.
> Pavel
First of all I have to say that I'd like to update the site and make it
clearer but at the moment it's not possible because I'm not the admin
and I've already asked to the sourceforge support to have this possibility.
About the comments: sincerely I don't understand the comments. We have
*already* a fs that takes care to remap a piace of ram (ram, sram,
nvram, etc.), takes care of caching problems, takes care of write
protection, takes care to be "persistent", can use xip and it's my
intention to add in the next future other features like acl, xattr and
so on.
You are talked about journaling. This schema works well for a disk, but
what about a piece of ram? What about a crazy kernel that write in that
area for a bug? Do you remember for example the e1000e bug? It's not
casual that this fs use an hw protection schema. I mean, this fs is not
only a "yet another fs", but a fs born with a specific target. So I
think modifying a ramdisk to have these behaviors isn't a little
modification.
Marco
^ permalink raw reply
* Re: [PATCH 06/14] Pramfs: Include files
From: Marco @ 2009-06-23 17:38 UTC (permalink / raw)
To: Sam Ravnborg
Cc: Tim Bird, Chris Simmonds, Arnd Bergmann, Linux FS Devel,
Linux Embedded, Linux Kernel
In-Reply-To: <20090623042106.GA17159@uranus.ravnborg.org>
Sam Ravnborg wrote:
>>> It should be possible to read a file-system on your x86 64bit
>>> box that you wrote with your small powerpc target.
>> For a (NV)RAM-based filesystem?? WTH???
>
> dd the full image - dig into it.
> Usefull is you have post-mortem info there.
>
> Sam
>
dd? You haven't got any device file to have a dump. I think we're going
a bit out of scope. I had some doubt to support rootfs in pram and after
some feedback and the comments of this review I think I'll remove it
from the next release (to understand some aspects of this fs with the
kernel community was my main goal for this review). I agree to use the
native endian. As I said the important thing is that if an user want to
use it in a 64bit environment then the fs must work well and then it
must be designed to support even this situation, I think it's obvious.
Marco
^ permalink raw reply
* Re: [PATCH 06/14] Pramfs: Include files
From: David Woodhouse @ 2009-06-23 8:31 UTC (permalink / raw)
To: Jörn Engel
Cc: Chris Simmonds, Arnd Bergmann, Marco, Sam Ravnborg,
Linux FS Devel, Linux Embedded, Linux Kernel
In-Reply-To: <20090623055735.GA23119@logfs.org>
On Tue, 2009-06-23 at 07:57 +0200, Jörn Engel wrote:
>
> Feel free to improve the test. It is admittedly crap and designed to
> support Chris' argument. But seeing that it still fails to do so and
> Arnd has already shown one improvement that weakened Chris' argument,
> I
> guess we can all agree that further improvments won't change the
> conclusion, can we? ;)
True. At this point, I'm actually more interested in just how crap the
kernel code is, that's generated by your test. We don't have a portable
way to store a wrong-endian number. Using st_le32() on PowerPC we can
get it down to something like this...
le32: 27777875 cycles
be32: 26564494 cycles
loops: 100000000
le32: 21739926 cycles
be32: 20289854 cycles
loops: 100000000
le32: 25206069 cycles
be32: 20289854 cycles
loops: 100000000
le32: 21739435 cycles
be32: 17391303 cycles
loops: 100000000
le32: 22197744 cycles
be32: 17391305 cycles
loops: 100000000
le32: 22195411 cycles
be32: 21946167 cycles
loops: 100000000
a0: 7f 4c 42 e6 mftbl r26
a4: 2c 1a 00 00 cmpwi r26,0
a8: 41 a2 ff f8 beq- a0 <.init_module+0x54>
ac: 3c 00 05 f5 lis r0,1525
b0: 3b 7f 00 70 addi r27,r31,112
b4: 60 00 e1 00 ori r0,r0,57600
b8: 7d 20 dc 2c lwbrx r9,0,r27
bc: 39 29 00 01 addi r9,r9,1
c0: 79 29 00 20 clrldi r9,r9,32
c4: 7d 20 dd 2c stwbrx r9,0,r27
c8: 34 00 ff ff addic. r0,r0,-1
cc: 40 82 ff ec bne+ b8 <.init_module+0x6c>
d0: 7f ac 42 e6 mftbl r29
d4: 2c 1d 00 00 cmpwi r29,0
d8: 41 a2 ff f8 beq- d0 <.init_module+0x84>
dc: 3c 00 05 f5 lis r0,1525
e0: 60 00 e1 00 ori r0,r0,57600
e4: 81 3f 00 74 lwz r9,116(r31)
e8: 39 29 00 01 addi r9,r9,1
ec: 91 3f 00 74 stw r9,116(r31)
f0: 34 00 ff ff addic. r0,r0,-1
f4: 40 82 ff f0 bne+ e4 <.init_module+0x98>
f8: 7f 8c 42 e6 mftbl r28
Interestingly, if we get rid of the (gratuitous, afaict) clrldi at 0xc0,
the little-endian version goes _faster_:
le32: 18839472 cycles
be32: 21946166 cycles
loops: 100000000
le32: 25923621 cycles
be32: 29629625 cycles
loops: 100000000
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 06/14] Pramfs: Include files
From: Marco Stornelli @ 2009-06-23 6:40 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Sam Ravnborg, Linux FS Devel, Linux Embedded, Linux Kernel
In-Reply-To: <200906222033.20883.arnd@arndb.de>
2009/6/22 Arnd Bergmann <arnd@arndb.de>:
> On Monday 22 June 2009, Marco wrote:
>>
>> Sorry, I meant it's not currently possible. At the moment the only way
>> to use it as rootfs it's to copy all the data in an already mounted
>> (empty) ram partition and reboot. However it's not my first item on my
>> todo list because I think that it's possible to use it as rootfs but it
>> isn't the standard use for this fs.
>
> Well, it doesn't have to work right away. What I'm asking to
> define the data structures in a way that keeps the layout stable
> across kernel updates. Since a future version of the file system
> might support cross-endian image creation, it would be good to
> define the data structures in a fixed endian mode already, so
> you don't have to change it in the future.
>
> Arnd <><
>
I was refering to create a tool "mkpramfs".
Marco
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 06/14] Pramfs: Include files
From: Jörn Engel @ 2009-06-23 5:57 UTC (permalink / raw)
To: David Woodhouse
Cc: Chris Simmonds, Arnd Bergmann, Marco, Sam Ravnborg,
Linux FS Devel, Linux Embedded, Linux Kernel
In-Reply-To: <1245709239.25547.394.camel@macbook.infradead.org>
On Mon, 22 June 2009 23:20:39 +0100, David Woodhouse wrote:
> On Mon, 2009-06-22 at 23:41 +0200, Jörn Engel wrote:
> > Four loops doing the same increment with different data types: long,
> > u64, we32 (wrong-endian) and we64. Compile with _no_ optimizations.
>
> That's a bit of a poor test then. Especially on architectures with a
> load-and-swap instruction where it really shouldn't be any slower at
> all.
>
> (Although since GCC doesn't have an __attribute__((littleendian)) I'm
> not entirely sure how to entice it into _using_ said instruction for the
> purpose of the test... I think the kernel does manage somehow though, if
> you get the sources _just_ right.)
Feel free to improve the test. It is admittedly crap and designed to
support Chris' argument. But seeing that it still fails to do so and
Arnd has already shown one improvement that weakened Chris' argument, I
guess we can all agree that further improvments won't change the
conclusion, can we? ;)
Jörn
--
It's just what we asked for, but not what we want!
-- anonymous
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox