From dwmw2 at infradead.org  Fri Dec  1 02:01:26 2000
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 1 Dec 2000 07:01:26 +0000 (GMT)
Subject: blk_dev[93].request_fn == NULL bug is still there
In-Reply-To: <LAW-F91NtDEJmGzrLCC00005522@hotmail.com>
Message-ID: <Pine.LNX.4.30.0012010659220.20779-100000@imladris.demon.co.uk>

On Thu, 30 Nov 2000, Levi Khatskevitch wrote:

> Ok, I was wrong I used the old vmlinux file :-). Module use count is correct
> now.

Hehe. I did _exactly_ the same thing :)

> Now I've just reproduced the blk_dev[93].request_fn == NULL bug in the
> latest code. Here is how:

I thought we'd found that this was because we were initialising the MTD
code before device_setup(). So I moved init_mtd() down a couple of lines
in init/main.c.

I'll try to reproduce this myself as soon as I get into the office.


-- 
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From dwmw2 at infradead.org  Fri Dec  1 05:02:44 2000
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 01 Dec 2000 10:02:44 +0000
Subject: blk_dev[93].request_fn == NULL bug is still there 
In-Reply-To: <LAW-F91NtDEJmGzrLCC00005522@hotmail.com> 
References: <LAW-F91NtDEJmGzrLCC00005522@hotmail.com> 
Message-ID: <2160.975664964@redhat.com>


lkhatskevitch at hotmail.com said:
>  Now I've just reproduced the blk_dev[93].request_fn == NULL bug in
> the  latest code. Here is how:

Works for me now. Check you've rebuilt it all with the latest patch.

Note init/main.c should now look like this:


        /* Set up devices .. */
        device_setup();

#ifdef CONFIG_MTD
        init_mtd();
#endif


--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From dwmw2 at infradead.org  Fri Dec  1 09:40:32 2000
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 01 Dec 2000 14:40:32 +0000
Subject: DiskOnChip 2000/Millennium driver merge.
Message-ID: <8574.975681632@redhat.com>

I've now cleaned up some of the differences between the new combined 
doc200[01] driver and the doc2001-only driver, and enabled 
DOC_SINGLE_DRIVER in the docprobe code.

I haven't removed the conditional stuff for two reasons -
	1. Ollie wants to keep the separate doc2001 driver for easier
		development and testing
	2. The doc2000 driver doesn't actually _work_ for writing. It
		exhibits the same behaviour with both types of device -
		writes to NFTL just don't appear to _stay_ written.

If you need write support for the Millennium right now, just comment out
the definition of DOC_SINGLE_DRIVER in docprobe.c and continue to use 
the doc2001 module.

As the doc2001 driver is working fine, I'm fairly sure it's a hardware
driver problem, not an NFTL code problem. Writes to the main body of the
flash appear to work too, so I currently suspect that it's an OOB data write
problem. 

If anyone else with Millennium hardware could take a look at the 
differences between doc2000.c and doc2001.c, especially Ollie who actually 
knows what he's doing, that'd be very much appreciated.

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From lkhatskevitch at hotmail.com  Fri Dec  1 10:56:05 2000
From: lkhatskevitch at hotmail.com (Levi Khatskevitch)
Date: Fri, 01 Dec 2000 10:56:05 -0500
Subject: blk_dev[93].request_fn == NULL bug is still there
Message-ID: <LAW-F50uA8M6XQQez1e00006398@hotmail.com>

On Fri, 1 Dec 2000, David Woodhouse wrote:
>I thought we'd found that this was because we were initialising the MTD
>code before device_setup(). So I moved init_mtd() down a couple of lines
>in init/main.c.
>
>I'll try to reproduce this myself as soon as I get into the office.
>
>--
>dwmw2
>
>

BTW Initializing MTD before device_setup was different (actially worse), it 
caused blk_dev[xxx].plug_tq.routine == NULL, that contition is not checked 
by run_task_queue() and was causing kernel to crash.

- Levi
_____________________________________________________________________________________
Get more from the Web.  FREE MSN Explorer download : http://explorer.msn.com



To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From dwmw2 at infradead.org  Fri Dec  1 11:08:35 2000
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 01 Dec 2000 16:08:35 +0000
Subject: blk_dev[93].request_fn == NULL bug is still there 
In-Reply-To: <LAW-F50uA8M6XQQez1e00006398@hotmail.com> 
References: <LAW-F50uA8M6XQQez1e00006398@hotmail.com> 
Message-ID: <19732.975686915@redhat.com>


lkhatskevitch at hotmail.com said:
>  BTW Initializing MTD before device_setup was different (actially
> worse), it  caused blk_dev[xxx].plug_tq.routine == NULL, that
> contition is not checked  by run_task_queue() and was causing kernel
> to crash. 

Ah. Sorry, I'd misread it and hadn't noticed the difference. 
Now I'm confused. Did it not complain about failing to register the blkdev?


--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From dwmw2 at infradead.org  Fri Dec  1 12:45:56 2000
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 01 Dec 2000 17:45:56 +0000
Subject: DiskOnChip 2000/Millennium driver merge. 
In-Reply-To: <8574.975681632@redhat.com> 
References: <8574.975681632@redhat.com> 
Message-ID: <31230.975692756@redhat.com>


dwmw2 at infradead.org said:
>  If anyone else with Millennium hardware could take a look at the
> differences between doc2000.c and doc2001.c, especially Ollie who
> actually  knows what he's doing, that'd be very much appreciated.

I think it's fixed. It now works on the DiskOnChip2000 - the culprit was 
the change to make doc_write_ecc() actually write the ECC data rather than 
just putting it into a buffer for the caller to subsequently write out.

Just continuing to write bytes to the IO register got it working on the 
Millennium. Not on the 2000, though. I had to change it to store the data 
and call doc_write_oob() at the end of doc_write_ecc() in order to make it 
work on the 2000.

I expect that to continue to work on the Millennium, but unfortunately I 
seem to have blown mine up - docprobe can't even see it any more :(

The combined 2000/Millennium driver now ought to be completely working.


--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From dwmw2 at infradead.org  Fri Dec  1 12:50:32 2000
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 01 Dec 2000 17:50:32 +0000
Subject: DiskOnChip 2000/Millennium driver merge. 
In-Reply-To: <31230.975692756@redhat.com> 
References: <31230.975692756@redhat.com>  <8574.975681632@redhat.com> 
Message-ID: <32142.975693032@redhat.com>


dwmw2 at infradead.org said:
>  I expect that to continue to work on the Millennium, but
> unfortunately I  seem to have blown mine up - docprobe can't even see
> it any more :(

OK, I hereby declare myself to by Today's Official Mr F*** All Good.

Of course it works if I turn off CONFIG_MTD_DOCPROBE_55AA

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From lkhatskevitch at hotmail.com  Fri Dec  1 15:45:28 2000
From: lkhatskevitch at hotmail.com (Levi Khatskevitch)
Date: Fri, 01 Dec 2000 15:45:28 -0500
Subject: blk_dev[93].request_fn == NULL bug is gone
Message-ID: <LAW-F62tjnupAK6FGBV00006ece@hotmail.com>

>Ah. Sorry, I'd misread it and hadn't noticed the difference.
>Now I'm confused. Did it not complain about failing to register the blkdev?
>
>--
>dwmw2
>
>

David,

Good news! The bug was gone after I reloaded original 2.2.17 code, applied 
patches/mtd-patch-2.2.17-20001130 and replaced all mtd files with the latest 
ones from cvs. I still have the old kernel source tree and on Monday I'll 
try to diff them and see what was causing the problem. But good news is that 
the BUG IS GONE.

Thanks,
- Levi
_____________________________________________________________________________________
Get more from the Web.  FREE MSN Explorer download : http://explorer.msn.com



To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From ollie at sis.com.tw  Fri Dec  1 20:40:44 2000
From: ollie at sis.com.tw (Ollie Lho)
Date: Sat, 02 Dec 2000 09:40:44 +0800
Subject: DiskOnChip 2000/Millennium driver merge.
References: <8574.975681632@redhat.com>
Message-ID: <3A28531C.4F5C8E14@sis.com.tw>

David Woodhouse wrote:
> 
> I've now cleaned up some of the differences between the new combined
> doc200[01] driver and the doc2001-only driver, and enabled
> DOC_SINGLE_DRIVER in the docprobe code.
> 
> I haven't removed the conditional stuff for two reasons -
>         1. Ollie wants to keep the separate doc2001 driver for easier
>                 development and testing
>         2. The doc2000 driver doesn't actually _work_ for writing. It
>                 exhibits the same behaviour with both types of device -
>                 writes to NFTL just don't appear to _stay_ written.
> 
> If you need write support for the Millennium right now, just comment out
> the definition of DOC_SINGLE_DRIVER in docprobe.c and continue to use
> the doc2001 module.
> 
> As the doc2001 driver is working fine, I'm fairly sure it's a hardware
> driver problem, not an NFTL code problem. Writes to the main body of the
> flash appear to work too, so I currently suspect that it's an OOB data write
> problem.
> 
> If anyone else with Millennium hardware could take a look at the
> differences between doc2000.c and doc2001.c, especially Ollie who actually
> knows what he's doing, that'd be very much appreciated.
> 

David,
	I just tried the updated CVS version. The Millennium part of 
doc2000.c works for some extend. It has some bugs which will offset/lost
1 or 2 bytes at begin/end of each 512byte page. It is a common problem if
you are not programming the chip fully comply to M-Systems Spec (actually
you have to do some "undocumented" tricks too). I will review the new code
next week possiblly after you get the SiS 630 LinuxBIOS demo/devel platform.

Ollie


To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From dwmw2 at infradead.org  Sat Dec  2 06:10:14 2000
From: dwmw2 at infradead.org (David Woodhouse)
Date: Sat, 2 Dec 2000 11:10:14 +0000 (GMT)
Subject: DiskOnChip 2000/Millennium driver merge.
In-Reply-To: <3A28531C.4F5C8E14@sis.com.tw>
Message-ID: <Pine.LNX.4.30.0012021050140.22169-100000@imladris.demon.co.uk>

On Sat, 2 Dec 2000, Ollie Lho wrote:

> David,
> 	I just tried the updated CVS version. The Millennium part of
> doc2000.c works for some extend. It has some bugs which will offset/lost
> 1 or 2 bytes at begin/end of each 512byte page. It is a common problem if
> you are not programming the chip fully comply to M-Systems Spec (actually
> you have to do some "undocumented" tricks too). I will review the new code
> next week possiblly after you get the SiS 630 LinuxBIOS demo/devel platform.

Thanks. I'll go through the driver and look for the remaining differences.
Were these changes made in doc2001.c since the Millennium support was
merged into doc2000.c, or did they get lost in the merge? If the former,
do you remember the entry in the CVS log that I should be looking for?

I note you changed DoC_Command() so it no longer finishes with
DoC_WaitReady(). Is there a situation in which DoC_Command shouldn't wait
for FR_B after sending the command? Does it do any harm to do so, or is
the removal just an optimisation?

-- 
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From shane at agendacomputing.com  Sat Dec  2 00:01:32 2000
From: shane at agendacomputing.com (Shane Nay)
Date: Sat, 2 Dec 2000 05:01:32 +0000
Subject: Problems with cfi_cmdset_0001
Message-ID: <20001202050132.B4457@www.easysolutions.net>

Okay, I've been reading the PDF for Strataflash, by Intel.  And I've traced
my problems with the write routines in MTD down to two problems, the Block
address, and the word write problem.  The command address isn't properly
interpretted for this chip.  I'm not sure what the CFI spec is, but I
think:
cmd_adr=adr & ~(wbufsize-1);
is wrong.  (Well, maybe it's different chip to chip, but I know it's wrong
for this chip)

It should compute the top of the block via the erasesize and size.
cmd_adr=mtd->erasesize*((int)(adr/mtd->erasesize));

Now, this fixes the Block address.  The other problem though is
significantly nastier.

Okay, MTD seems to think that it can write twice as much data as it can to
a device at a time in write_buffer mode, which is all together wrong.  My
configuration is two x8 chips interleaved on a 16 bit bus.  Basically...,
its thinking we have two x16 chips on a 32 bit bus before streaming, but
then streams the data the right way, but twice as much as it said it would.
 (It says, I'm sending 16 words, then sends 32 of them instead, which as
you could imagine, is quite confusing to the poor flash chips)

In any event.  I've got the block address problem fixed up in the code with
the afore mentioned code.  The other problem I'm still working on. 
However, my code is so removed at this point from MTD base since I had too
many other things at play with MTD code to properly trace my problem, and
now I have a cleaner version of the code for XIP.  So I'm not sure I'm
going to roll all my changes into cfi_cmdset_0001.  Who is the maintainer
of this file BTW?  I'll try to make patches for him/her to fix these
problems.

Thanks,
Shane.

(Or maybe my extremely tired brain is mis-interpretting..., if I'm wrong,
tell me so :)



To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From shane at agendacomputing.com  Sat Dec  2 02:29:29 2000
From: shane at agendacomputing.com (Shane Nay)
Date: Sat, 2 Dec 2000 07:29:29 +0000
Subject: Problems with cfi_cmdset_0001 && XIP kernel w/MTD working
In-Reply-To: <20001202050132.B4457@www.easysolutions.net>; from shane@agendacomputing.com on Sat, Dec 02, 2000 at 05:01:32 +0000
References: <20001202050132.B4457@www.easysolutions.net>
Message-ID: <20001202072929.D4457@www.easysolutions.net>

Problem solved, and MTD write, read, and erase is now functioning with an
XIP kernel.  Now come my questions..., I realized that it was trying to
fill the write buffer, but wasn't signaling the right size to the flash
chip now.  I traced where it was doing that, and have come to a conclusion
about a particular line of code.  But it might be a special case, and if so
we'll need some logic to deal with it, but I think it might just be a
mistake.  Okay, here it is:

In cfi_cmdset_001.c, in the do_write_buffer code, when it is sending the
size to the cmd_adr after putting the flash chip in write mode.  The
calculation for size there seems to be wrong for interleaved chips.  The
old code reads:
cfi_write(map,CMD((len/(cfi->device_type + CFIDEV_INTERLEAVE))-1),cmd_adr);

However, in my case, when it used this calculation, it undershot the number
of "words" it was going to write.  I think this is really confusing,
because the flash chip I'm working with percieves the number you send there
as "The number of times you will fill the bus".  But in the PDF it says
that that is the number of "words" that you will send it.  I suppose their
definition of word in this case is the present used buswidth of the chip. 
In any event, the correct code in my situation is:
cfi_write(map,CMD((len/(cfi->device_type)-1),cmd_adr);

The interleave should not factor into the division of the number of "words"
you are going to send.  I don't know if this is "generally true", but I
imagine it to be.  Anyone else out there with interleaved intel flashchips?

Thanks,
Shane.

(Ugh, replied to my own thread, bad juju)




To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From nico at cam.org  Sat Dec  2 10:23:33 2000
From: nico at cam.org (Nicolas Pitre)
Date: Sat, 2 Dec 2000 10:23:33 -0500 (EST)
Subject: Problems with cfi_cmdset_0001
In-Reply-To: <20001202050132.B4457@www.easysolutions.net>
Message-ID: <Pine.LNX.4.30.0012021004200.16670-100000@xanadu.gn.com>



On Sat, 2 Dec 2000, Shane Nay wrote:

> Okay, I've been reading the PDF for Strataflash, by Intel.  And I've traced
> my problems with the write routines in MTD down to two problems, the Block
> address, and the word write problem.  The command address isn't properly
> interpretted for this chip.  I'm not sure what the CFI spec is, but I
> think:
> cmd_adr=adr & ~(wbufsize-1);
> is wrong.  (Well, maybe it's different chip to chip, but I know it's wrong
> for this chip)
>
> It should compute the top of the block via the erasesize and size.
> cmd_adr=mtd->erasesize*((int)(adr/mtd->erasesize));

Please consider using the following for better efficiency instead:

	cmd_adr = addr & ~(mtd->erasesize-1);

This produces the same result but omits the division which is best to avoid
on some CPUs which don't have a native instruction for it.

> Now, this fixes the Block address.  The other problem though is
> significantly nastier.
>
> Okay, MTD seems to think that it can write twice as much data as it can to
> a device at a time in write_buffer mode, which is all together wrong.  My
> configuration is two x8 chips interleaved on a 16 bit bus.  Basically...,
> its thinking we have two x16 chips on a 32 bit bus before streaming, but
> then streams the data the right way, but twice as much as it said it would.

What kind of arrangement do the probe function find?  Does it actually tell
you: "Found 2 x8 CFI devices at location 0 in 8 bit mode"?  If not, you'll
have to look at the probe code in cfi-probe.c.  Carefully reordering the
probe sequence might be required (I had to do it for the 32-bit buswidth
case).

> However, my code is so removed at this point from MTD base since I had too
> many other things at play with MTD code to properly trace my problem, and
> now I have a cleaner version of the code for XIP.  So I'm not sure I'm
> going to roll all my changes into cfi_cmdset_0001.

My impression is that it had better advantages to be separate just to keep
things as simple as possible.

> Who is the maintainer
> of this file BTW?  I'll try to make patches for him/her to fix these
> problems.

Well... I don't know who is the official maintainer, but I think I
contributed the largest mods recently.


Nicolas



To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From shane at agendacomputing.com  Sat Dec  2 03:54:19 2000
From: shane at agendacomputing.com (Shane Nay)
Date: Sat, 2 Dec 2000 08:54:19 +0000
Subject: Problems with cfi_cmdset_0001
In-Reply-To: <Pine.LNX.4.30.0012021004200.16670-100000@xanadu.gn.com>; from nico@cam.org on Sat, Dec 02, 2000 at 15:23:33 +0000
References: <20001202050132.B4457@www.easysolutions.net> <Pine.LNX.4.30.0012021004200.16670-100000@xanadu.gn.com>
Message-ID: <20001202085419.I4457@www.easysolutions.net>

Nicholas,
> Please consider using the following for better efficiency instead:
> 
> 	cmd_adr = addr & ~(mtd->erasesize-1);

Will do.  I was trying to think of the bit wise way to do it, but I was/am
kind of tired.

> 
> This produces the same result but omits the division which is best to
> avoid
> on some CPUs which don't have a native instruction for it.

Tell me about it..., working on FPU less MIPS processor.  So division in
general makes the hair on my neck stand out on end.

> 
> What kind of arrangement do the probe function find?  Does it actually
> tell
> you: "Found 2 x8 CFI devices at location 0 in 8 bit mode"?  If not,
> you'll
> have to look at the probe code in cfi-probe.c.  Carefully reordering the
> probe sequence might be required (I had to do it for the 32-bit buswidth
> case).

Ah, ic.  No, I think it found it correctly, here's the output:  (Paste
isn't working right now, have to turn on Emulate3Buttons again)
supports x8 and x16 via BYTE# with asynchronous interface


> 
> My impression is that it had better advantages to be separate just to
> keep
> things as simple as possible.

I happen to agree with your position now :-).  After a couple days of
drudging through stuff, I think simple is much better :).  I don't know
whether to contribut this stuff, and use a macro to re-probe for the
commandset_xip, and then write a commandset_xip.c file and contribute that
or what precisely.  It's pretty special purpose, so maybe just a patch
floating around for people to try out.  In any case, I have to maintain the
patch against linux-vr cvs repository for our device after we ship, so
it'll be floating around on the agenda computing pages starting Real Soon
Now, aka, as soon as I suck it into a kernel release for our device, which
is likely to be Monday or Tuesday.

> Well... I don't know who is the official maintainer, but I think I
> contributed the largest mods recently.

Cool, then I'll make the patch, post it on one of our pages and drop a link
here.  You guys can choose to include it in your stuff or not.  I
understand Daves philsophical issue on this..., RAM is cheaper than flash
:-).

Thanks,
Shane.



To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From agnew at glue.umd.edu  Sat Dec  2 22:42:14 2000
From: agnew at glue.umd.edu (Adam Agnew)
Date: Sat, 2 Dec 2000 22:42:14 -0500 (EST)
Subject: including doc2001 and docprobe into the kernel
In-Reply-To: <20001202085419.I4457@www.easysolutions.net>
Message-ID: <Pine.GSO.4.21.0012022229390.14865-100000@z.glue.umd.edu>

when I try to include the millenium code right into the kernel along with
the ntfl layer, etc i get errors 
drivers/mtd/mtdlink.o: In function `DoC_Probe':
drivers/mtd/mtdlink.o(.text+0x26da): undefined reference to
`inter_module_get_request'
drivers/mtd/mtdlink.o(.text+0x26f9): undefined reference to
`inter_module_put'
drivers/mtd/mtdlink.o: In function `init_doc2001':
drivers/mtd/mtdlink.o(.text.init+0x75): undefined reference to
`inter_module_register'
make: *** [vmlinux] Error 1

I included all the module support etc... any ideas? The error goes away
when i compile the millenium driver as a module of course.
- adam agnew



To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From LKhatskevitch at cachier.com  Sun Dec  3 00:52:34 2000
From: LKhatskevitch at cachier.com (Levi Khatskevitch)
Date: Sun, 3 Dec 2000 00:52:34 -0500
Subject: including doc2001 and docprobe into the kernel
In-Reply-To: <Pine.GSO.4.21.0012022229390.14865-100000@z.glue.umd.edu>
References: <Pine.GSO.4.21.0012022229390.14865-100000@z.glue.umd.edu>
Message-ID: <00120301032208.00983@itidev1>

Adam,

You can add inter_module_xxx support by applying
patches/inter-module-2.2.17.patch on 2.2.17 kernel source. But if you didn't
apply patches/mtd-patch-2.2.17-20001130 please do so *before* adding any mtd
code to kernel tree. If you do everything correctly you shouldn't need
inter-module-xxx-2.2.17.patch. And don't forget to drivers/mtd/*.[ch],
include/linux/jffs.h and include/linux/mtd/*.h with the fresh ones from mtd cvs
tree *after* you've applied mtd-patch-2.2.17-20001130.

- Levi

On Sat, 02 Dec 2000, Adam Agnew wrote:
> when I try to include the millenium code right into the kernel along with
> the ntfl layer, etc i get errors 
> drivers/mtd/mtdlink.o: In function `DoC_Probe':
> drivers/mtd/mtdlink.o(.text+0x26da): undefined reference to
> `inter_module_get_request'
> drivers/mtd/mtdlink.o(.text+0x26f9): undefined reference to
> `inter_module_put'
> drivers/mtd/mtdlink.o: In function `init_doc2001':
> drivers/mtd/mtdlink.o(.text.init+0x75): undefined reference to
> `inter_module_register'
> make: *** [vmlinux] Error 1
> 
> I included all the module support etc... any ideas? The error goes away
> when i compile the millenium driver as a module of course.
> - adam agnew
> 
> 
> 
> To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org
-- 
Levi Khatskevitch
CTO
Cachier, Corp
575 Grand St., Suite E306
New York, NY 10002


To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From Vadimk at m-sys.com  Sun Dec  3 04:45:59 2000
From: Vadimk at m-sys.com (Vadim Khamlinsky)
Date: Sun, 3 Dec 2000 11:45:59 +0200 
Subject: DiskOnChip 2000/Millennium driver merge. 
Message-ID: <61855DF64794D41185DF00508BEEF7070DBA57@pc3.msys.co.il>

>Of course it works if I turn off CONFIG_MTD_DOCPROBE_55AA

Diskonchip 2000  always has 55aa signature at the beginning of 
the DiskOnChip window . DiskOnChip Millennium does not .
I'm not going to get into the hardware differences between these two
products . From the software point of view it depends on the DiskOnChip
Millennium low-level format .
If it was formatted with the following command :
  dformat /win:d000 /s:docxxx.exb  , then you should find 55AA signature .
If it was formatted as follows :
   dformat /win:d000 /s:docxxx.exb 

or docxxx.exb was somehow removed from the DiskOnChip Millennium
you will not see 55AA .
In short, don't depend on the 55aa probe when you work with
DiskOnChip-Millennium .

Regards,
Vadim  
 
  


To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From dwmw2 at infradead.org  Sun Dec  3 11:32:41 2000
From: dwmw2 at infradead.org (David Woodhouse)
Date: Sun, 3 Dec 2000 16:32:41 +0000 (GMT)
Subject: including doc2001 and docprobe into the kernel
In-Reply-To: <00120301032208.00983@itidev1>
Message-ID: <Pine.LNX.4.30.0012031630220.8498-100000@imladris.demon.co.uk>

On Sun, 3 Dec 2000, Levi Khatskevitch wrote:

> Adam,
>
> You can add inter_module_xxx support by applying
> patches/inter-module-2.2.17.patch on 2.2.17 kernel source. But if you
> didn't apply patches/mtd-patch-2.2.17-20001130 please do so *before*
> adding any mtd code to kernel tree.

The patch is gone from CVS. It's now on the FTP site.

Also note that the latest CVS version of docprobe uses the doc2000.c
driver for _both_ 2000 and Millennium devices. So either build doc2000 and
docprobe into the kernel, not 'doc2001 and docprobe' as you say in
$subject, or comment out the #define DOC_SINGLE_DRIVER near the top of
docprobe.c.

The latter is probably the best option, given that the author of doc2001.c
thinks there are still bugs remaining in the Millennium support which is
merged into doc2000.c

-- 
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From LKhatskevitch at cachier.com  Sun Dec  3 12:19:14 2000
From: LKhatskevitch at cachier.com (Levi Khatskevitch)
Date: Sun, 3 Dec 2000 12:19:14 -0500
Subject: including doc2001 and docprobe into the kernel
In-Reply-To: <Pine.LNX.4.30.0012031630220.8498-100000@imladris.demon.co.uk>
References: <Pine.LNX.4.30.0012031630220.8498-100000@imladris.demon.co.uk>
Message-ID: <0012031229270A.00983@itidev1>

On Sun, 03 Dec 2000, David Woodhouse wrote:
> The patch is gone from CVS. It's now on the FTP site.

Hi,

If mtd-patch-* are gone from cvs what is the right procedure to bring the
latest mtd code into the kernel tree? Is is to apply a partial patch
mtd-*.infra.patch and then use patchin.sh? If that's so we need to have new
mtd-2.2.17.infra.patch and probably update or remove mtd-2.2.14.infra.patch and
mtd-2.2.16.infra.patch, they are way outdated.

BTW mtd-patch-2.2.17-20001130-1700GMT from ftp site still inserts
put_module_symbol even though it's not used anywhere in the source.

- Levi

-- 
Levi Khatskevitch
CTO
Cachier, Corp.
575 Grand St., Suite E306
New York, NY 10002


To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From dwmw2 at infradead.org  Sun Dec  3 13:13:54 2000
From: dwmw2 at infradead.org (David Woodhouse)
Date: Sun, 3 Dec 2000 18:13:54 +0000 (GMT)
Subject: including doc2001 and docprobe into the kernel
In-Reply-To: <0012031229270A.00983@itidev1>
Message-ID: <Pine.LNX.4.30.0012031735490.13316-100000@imladris.demon.co.uk>

On Sun, 3 Dec 2000, Levi Khatskevitch wrote:

> If mtd-patch-* are gone from cvs what is the right procedure to bring
> the latest mtd code into the kernel tree? Is is to apply a partial
> patch mtd-*.infra.patch and then use patchin.sh? If that's so we need
> to have new mtd-2.2.17.infra.patch and probably update or remove
> mtd-2.2.14.infra.patch and mtd-2.2.16.infra.patch, they are way
> outdated.

The patch still exists, and the procedure for applying it is just the same
- except that now you download it from the FTP site, rather than clogging
up the CVS tree with it.

I've removed all the extra files from the CVS tree, too.

> BTW mtd-patch-2.2.17-20001130-1700GMT from ftp site still inserts
> put_module_symbol even though it's not used anywhere in the source.

Thanks. I'll try to remember to remove that part next time I make a patch.

-- 
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From john at frumious.unidec.co.uk  Sun Dec  3 14:01:42 2000
From: john at frumious.unidec.co.uk (john halewood)
Date: Sun, 3 Dec 2000 19:01:42 GMT
Subject: M-System DOC Millennium with MTD.
Message-ID: <200012031901.eB3J1ge27396@frumious.unidec.co.uk>

David Woodhouse wrote, re misidentification/failure to identify DoC's
 with the M-Systems doc2.fff firmware:
>You can also work round this by disabling CONFIG_MTD_DOCPROBE_55AA

Yup. you also need to disable DOCPROBE_HIMEM as well, otherwise you just
get a lot of messages of the form "found possible Doc at XXXXX" and no
mtd device.
 I've been messing with these parameters so much recently I've sometimes
felt like hacking a /proc interface to them to avoid the reconfig -
recompile modules - rmmod /insmod cycle, which can be quite painful on a slow
processor. In the long run though i think pollution of the /proc space
is probably left to those who've done it so well in the past

john


To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From dwmw2 at infradead.org  Sun Dec  3 14:26:53 2000
From: dwmw2 at infradead.org (David Woodhouse)
Date: Sun, 3 Dec 2000 19:26:53 +0000 (GMT)
Subject: M-System DOC Millennium with MTD.
In-Reply-To: <200012031901.eB3J1ge27396@frumious.unidec.co.uk>
Message-ID: <Pine.LNX.4.30.0012031924220.13316-100000@imladris.demon.co.uk>

On Sun, 3 Dec 2000, john halewood wrote:

> David Woodhouse wrote, re misidentification/failure to identify DoC's
>  with the M-Systems doc2.fff firmware:
> >You can also work round this by disabling CONFIG_MTD_DOCPROBE_55AA
>
> Yup. you also need to disable DOCPROBE_HIMEM as well, otherwise you just
> get a lot of messages of the form "found possible Doc at XXXXX" and no
> mtd device.

Yep. Although I've now removed the annoying complaints if DOCPROBE_55AA
isn't defined.

>  I've been messing with these parameters so much recently I've sometimes
> felt like hacking a /proc interface to them to avoid the reconfig -
> recompile modules - rmmod /insmod cycle, which can be quite painful on a slow
> processor.

This is what MODULE_PARM was invented for :)

-- 
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From dwmw2 at infradead.org  Sun Dec  3 14:34:15 2000
From: dwmw2 at infradead.org (David Woodhouse)
Date: Sun, 3 Dec 2000 19:34:15 +0000 (GMT)
Subject: M-System DOC Millennium with MTD.
In-Reply-To: <200012031901.eB3J1ge27396@frumious.unidec.co.uk>
Message-ID: <Pine.LNX.4.30.0012031933180.13316-100000@imladris.demon.co.uk>

On Sun, 3 Dec 2000, john halewood wrote:

>  I've been messing with these parameters so much recently I've sometimes
> felt like hacking a /proc interface to them to avoid the reconfig -
> recompile modules - rmmod /insmod cycle, which can be quite painful on a slow
> processor.

cvs up and try again:

insmod docprobe.o doc_config_location=0xd0000

-- 
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From dwmw2 at infradead.org  Sun Dec  3 15:49:11 2000
From: dwmw2 at infradead.org (David Woodhouse)
Date: Sun, 3 Dec 2000 20:49:11 +0000 (GMT)
Subject: DiskOnChip support in Grub.
Message-ID: <Pine.LNX.4.30.0012032045160.13316-100000@imladris.demon.co.uk>


I've regenerated the patch to Grub which adds DiskOnChip 2000 support
(Millennium isn't yet included).

If anyone could dump the image from
ftp.infradead.org:/pub/mtd/grub/grub-image onto a floppy (dd of=/dev/fd0)
and boot it, then type

 root=(dc0,0)
 kernel=/<tab>

 root=(dc0,1)
 kernel=/<tab>

and let me know what happens (and if the tab-completion looks something
like the files you expect to be on nftla1 and nftla2 respectively), that'd
be much appreciated.

The pre_stage2 file is also there, in case you want to flash it into the
DiskOnChip in place of the existing firmware, using the grub loader from
CVS.

-- 
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From ollie at sis.com.tw  Sun Dec  3 21:08:02 2000
From: ollie at sis.com.tw (Ollie Lho)
Date: Mon, 04 Dec 2000 10:08:02 +0800
Subject: DiskOnChip 2000/Millennium driver merge.
References: <Pine.LNX.4.30.0012021050140.22169-100000@imladris.demon.co.uk>
Message-ID: <3A2AFC82.6E1521FD@sis.com.tw>

David Woodhouse wrote:
> 
> On Sat, 2 Dec 2000, Ollie Lho wrote:
> 
> > David,
> >       I just tried the updated CVS version. The Millennium part of
> > doc2000.c works for some extend. It has some bugs which will offset/lost
> > 1 or 2 bytes at begin/end of each 512byte page. It is a common problem if
> > you are not programming the chip fully comply to M-Systems Spec (actually
> > you have to do some "undocumented" tricks too). I will review the new code
> > next week possiblly after you get the SiS 630 LinuxBIOS demo/devel platform.
> 
> Thanks. I'll go through the driver and look for the remaining differences.
> Were these changes made in doc2001.c since the Millennium support was
> merged into doc2000.c, or did they get lost in the merge? If the former,
> do you remember the entry in the CVS log that I should be looking for?
> 
> I note you changed DoC_Command() so it no longer finishes with
> DoC_WaitReady(). Is there a situation in which DoC_Command shouldn't wait
> for FR_B after sending the command? Does it do any harm to do so, or is
> the removal just an optimisation?
> 

The reason that I removed DoC_WaitReady() for DoC_Command() is you are using
DoC_Command to find how many flash chip on a single DoC. If there is no more
chip, the ready bit will never get high. And the driver hangs.

Ollie


To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From miguel at cetuc.puc-rio.br  Mon Dec  4 13:44:57 2000
From: miguel at cetuc.puc-rio.br (Miguel Freitas)
Date: Mon, 4 Dec 2000 13:44:57 GMT-3
Subject: DiskOnChip 2000/Millennium driver merge.
Message-ID: <F1CBD81818@mamao.cetuc.puc-rio.br>

Ollie Lho wrote:

> > I note you changed DoC_Command() so it no longer finishes with
> > DoC_WaitReady(). Is there a situation in which DoC_Command shouldn't
> > wait for FR_B after sending the command? Does it do any harm to do
> > so, or is the removal just an optimisation?
> >
> 
> The reason that I removed DoC_WaitReady() for DoC_Command() is you are
> using DoC_Command to find how many flash chip on a single DoC. If
> there is no more chip, the ready bit will never get high. And the
> driver hangs.
> 
> Ollie

   Hummm, this is a little off-topic, but you have just explained me 
why my PIC routines to access DOC2000 were hanging!!! I saw 
exactly this with a logic analiser, but when using the same DOC on a 
PC it worked, don't ask me why...(and it never left the WaitReady by 
timeout)


Miguel Freitas



To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From dwmw2 at infradead.org  Mon Dec  4 10:53:11 2000
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 04 Dec 2000 15:53:11 +0000
Subject: DiskOnChip 2000/Millennium driver merge. 
In-Reply-To: <F1CBD81818@mamao.cetuc.puc-rio.br> 
References: <F1CBD81818@mamao.cetuc.puc-rio.br> 
Message-ID: <14168.975945191@redhat.com>


miguel at cetuc.puc-rio.br said:
> 
>    Hummm, this is a little off-topic, but you have just explained me
> why my PIC routines to access DOC2000 were hanging!!! I saw  exactly
> this with a logic analiser, but when using the same DOC on a  PC it
> worked, don't ask me why...(and it never left the WaitReady by
> timeout) 

On a reasonably fast PC, the WaitReady will timeout and you won't lock 
forever. I think we could just change the timeout to something more 
appropriate - rather than a fixed number of loops, repeat until jiffies has 
increased by a certain number of ticks.

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From mark.langsdorf at amd.com  Mon Dec  4 13:29:10 2000
From: mark.langsdorf at amd.com (mark.langsdorf at amd.com)
Date: Mon, 4 Dec 2000 12:29:10 -0600
Subject: Odd behavior of JFFS with AMD chips - kernel panic!
Message-ID: <0FA1031B65A9D111960900805F9FA8E103B9F20D@txexmta8.amd.com>

I'm still working on diagnosising what's causing my problems
with JFFS and MTD.

I built a version of the Dec 3rd MTD code for my device, and
booted the kernel.

As far as I can tell, my device works fine with the char interface,
and I was able to build a file system image and put it in flash
using 'cat Flash.img > /dev/mtd2'

mounting the flash system with 'mount -t jffs /dev/mtdblock2 /tst'
also seemed to work.

However, when I copied a file on the filesystem, using 'cp lilo.conf first',
it looks like the write failed and MTD/jffs decided to reorganize
the entire hard drive.  At least some of the writes don't work out,
and the new file on the drive is corrupt.  When I attempt 'more first',
the system reads the first 20 bytes of the file and then has a kernel
panic in flash_safe_read.  Not good.

I'm including my syslog output of the appropriate messages.  I think
some of them were lost to my terminal program's buffer, but I hope
there's enough here that someone can provide some suggestions for 
what I'm doing wrong.  I'll be more than happy to run any additional
tests to provide more information.

Mark Langsdorf
Advanced Micro Devices, Inc             Tel: 512.602.3756
5204 E. Ben White Blvd. M/S 590         Fax: 512.602.5051
Austin, TX 78741                        mark.langsdorf at amd.com

-------------- next part --------------
mount -t jffs /dev/mtdblock2 /tst
Dec  4 11:55:04 netlinux kernel:     fb3autodetect (ino: 81, highest_version: 1, size: 2)
Dec  4 11:55:04 netlinux kernel:     fd0u3520 (ino: 121, highest_version: 1, size: 2)
Dec  4 11:55:04 netlinux kernel:     hda (ino: 161, highest_version: 1, size: 2)
Dec  4 11:55:04 netlinux kernel:     hdb8 (ino: 201, highest_version: 1, size: 2)
Dec  4 11:55:04 netlinux kernel:     hdd6 (ino: 241, highest_version: 1, size: 2)
Dec  4 11:55:04 netlinux kernel:     nst1l (ino: 281, highest_version: 1, size: 2)
Dec  4 11:55:04 netlinux kernel:     ptybf (ino: 321, highest_version: 1, size: 2)
Dec  4 11:55:04 netlinux kernel:     ptye7 (ino: 361, highest_version: 1, size: 2)
Dec  4 11:55:04 netlinux kernel:     ptyqf (ino: 401, highest_version: 1, size: 2)
Dec  4 11:55:04 netlinux kernel:     ptyt7 (ino: 441, highest_version: 1, size: 2)
Dec  4 11:55:04 netlinux kernel:     ptyw0 (ino: 481, highest_version: 1, size: 2)
Dec  4 11:55:04 netlinux kernel:     ptyy8 (ino: 521, highest_version: 1, size: 2)
Dec  4 11:55:04 netlinux kernel:     ram8 (ino: 561, highest_version: 1, size: 2)
Dec  4 11:55:04 netlinux kernel:     sdb9 (ino: 601, highest_version: 1, size: 2)
Dec  4 11:55:04 netlinux kernel:     st0a (ino: 641, highest_version: 1, size: 2)
Dec  4 11:55:04 netlinux kernel:     tty35 (ino: 681, highest_version: 1, size: 2)
Dec  4 11:55:04 netlinux kernel:     ttya1 (ino: 721, highest_version: 1, size: 2)
Dec  4 11:55:04 netlinux kernel:     ttyc8 (ino: 761, highest_version: 1, size: 2)
Dec  4 11:55:04 netlinux kernel:     ttyp0 (ino: 801, highest_version: 1, size: 2)
Dec  4 11:55:04 netlinux kernel:     ttyr8 (ino: 841, highest_version: 1, size: 2)
Dec  4 11:55:04 netlinux kernel:     ttyu0 (ino: 881, highest_version: 1, size: 2)
Dec  4 11:55:04 netlinux kernel:     ttyw8 (ino: 921, highest_version: 1, size: 2)
Dec  4 11:55:04 netlinux kernel:     ttyz0 (ino: 961, highest_version: 1, size: 2)
Dec  4 11:55:04 netlinux kernel:     vcs29 (ino: 1001, highest_version: 1, size: 2)
Dec  4 11:55:04 netlinux kernel:     vcs8 (ino: 1041, highest_version: 1, size: 2)
Dec  4 11:55:04 netlinux kernel:     vcsa42 (ino: 1081, highest_version: 1, size: 2)
Dec  4 11:55:04 netlinux kernel:     xdb4 (ino: 1121, highest_version: 1, size: 2)
Dec  4 11:55:04 netlinux kernel:     mtdr0 (ino: 1161, highest_version: 1, size: 2)
Dec  4 11:55:04 netlinux kernel:     fb3 (ino: 80, highest_version: 1, size: 2)
Dec  4 11:55:04 netlinux kernel:     fd0u3200 (ino: 120, highest_version: 1, size: 2)
Dec  4 11:55:04 netlinux kernel:     full (ino: 160, highest_version: 1, size: 2)
Dec  4 11:55:04 netlinux kernel:     hdb7 (ino: 200, highest_version: 1, size: 2)
Dec  4 11:55:04 netlinux kernel:     hdd5 (ino: 240, highest_version: 1, size: 2)
Dec  4 11:55:04 netlinux kernel:     nst1a (ino: 280, highest_version: 1, size: 2)
Dec  4 11:55:04 netlinux kernel:     ptybe (ino: 320, highest_version: 1, size: 2)
Dec  4 11:55:04 netlinux kernel:     ptye6 (ino: 360, highest_version: 1, size: 2)
Dec  4 11:55:04 netlinux kernel:     ptyqe (ino: 400, highest_version: 1, size: 2)
Dec  4 11:55:04 netlinux kernel:     ptyt6 (ino: 440, highest_version: 1, size: 2)
Dec  4 11:55:04 netlinux kernel:     ptyvf (ino: 480, highest_version: 1, size: 2)
Dec  4 11:55:04 netlinux kernel:     ptyy7 (ino: 520, highest_version: 1, size: 2)
Dec  4 11:55:04 netlinux kernel:     ram7 (ino: 560, highest_version: 1, size: 2)
Dec  4 11:55:04 netlinux kernel:     sdb8 (ino: 600, highest_version: 1, size: 2)
Dec  4 11:55:04 netlinux kernel:     st0 (ino: 640, highest_version: 1, size: 2)
Dec  4 11:55:04 netlinux kernel:     tty34 (ino: 680, highest_version: 1, size: 2)
Dec  4 11:55:04 netlinux kernel:     ttya0 (ino: 720, highest_version: 1, size: 2)
Dec  4 11:55:04 netlinux kernel:     ttyc7 (ino: 760, highest_version: 1, size: 2)
Dec  4 11:55:04 netlinux kernel:     ttyef (ino: 800, highest_version: 1, size: 2)
Dec  4 11:55:04 netlinux kernel:     ttyr7 (ino: 840, highest_version: 1, size: 2)
Dec  4 11:55:04 netlinux kernel:     ttytf (ino: 880, highest_version: 1, size: 2)
Dec  4 11:55:04 netlinux kernel:     ttyw7 (ino: 920, highest_version: 1, size: 2)
Dec  4 11:55:04 netlinux kernel:     ttyyf (ino: 960, highest_version: 1, size: 2)
Dec  4 11:55:04 netlinux kernel:     vcs28 (ino: 1000, highest_version: 1, size: 2)
Dec  4 11:55:04 netlinux kernel:     vcs7 (ino: 1040, highest_version: 1, size: 2)
Dec  4 11:55:04 netlinux kernel:     vcsa41 (ino: 1080, highest_version: 1, size: 2)
Dec  4 11:55:04 netlinux kernel:     xdb3 (ino: 1120, highest_version: 1, size: 2)
Dec  4 11:55:04 netlinux kernel:     mtdblock9 (ino: 1160, highest_version: 1, size: 2)
Dec  4 11:55:04 netlinux kernel:   etc/ (ino: 1178, highest_version: 1, size: 0)
Dec  4 11:55:04 netlinux kernel:     group (ino: 1199, highest_version: 1, size: 259)
Dec  4 11:55:04 netlinux kernel:     nsswitch.conf (ino: 1198, highest_version: 1, size: 239)
Dec  4 11:55:04 netlinux kernel:     services (ino: 1197, highest_version: 1, size: 8377)
Dec  4 11:55:04 netlinux kernel:     resolv.conf (ino: 1196, highest_version: 1, size: 121)
Dec  4 11:55:04 netlinux kernel:     protocols (ino: 1195, highest_version: 1, size: 894)
Dec  4 11:55:08 netlinux kernel:     issue.net (ino: 1194, highest_version: 1, size: 58)
Dec  4 11:55:08 netlinux kernel:     rc.d/ (ino: 1182, highest_version: 1, size: 0)
Dec  4 11:55:08 netlinux kernel:       rcS (ino: 1193, highest_version: 1, size: 902)
Dec  4 11:55:08 netlinux kernel:       rc.serial (ino: 1192, highest_version: 1, size: 18)
Dec  4 11:55:08 netlinux kernel:       rc.rofilesys.example (ino: 1191, highest_version: 1, size: 3813)
Dec  4 11:55:08 netlinux kernel:       rc.modules (ino: 1190, highest_version: 1, size: 18)
Dec  4 11:55:08 netlinux kernel:       rc.local (ino: 1189, highest_version: 1, size: 18)
Dec  4 11:55:08 netlinux kernel:       init.d/ (ino: 1183, highest_version: 1, size: 0)
Dec  4 11:55:08 netlinux kernel:         S05syslog (ino: 1188, highest_version: 1, size: 1768)
Dec  4 11:55:08 netlinux kernel:         S20network (ino: 1187, highest_version: 1, size: 1690)
Dec  4 11:55:08 netlinux kernel:         S30telnet (ino: 1186, highest_version: 1, size: 692)
Dec  4 11:55:08 netlinux kernel:         S90thttpd (ino: 1185, highest_version: 1, size: 898)
Dec  4 11:55:08 netlinux kernel:         S25firewall (ino: 1184, highest_version: 1, size: 25054)
Dec  4 11:55:08 netlinux kernel:     mtab (ino: 1181, highest_version: 1, size: 12)
Dec  4 11:55:08 netlinux kernel:     inittab (ino: 1180, highest_version: 1, size: 390)
Dec  4 11:55:08 netlinux kernel:     fstab (ino: 1179, highest_version: 1, size: 104)
Dec  4 11:55:08 netlinux kernel:     lilo.conf (ino: 1206, highest_version: 1, size: 526)
Dec  4 11:55:08 netlinux kernel:     shadow- (ino: 1205, highest_version: 1, size: 336)
Dec  4 11:55:08 netlinux kernel:     ld.so.cache (ino: 1204, highest_version: 1, size: 562)
Dec  4 11:55:08 netlinux kernel:     syslog.conf (ino: 1203, highest_version: 1, size: 1011)
Dec  4 11:55:08 netlinux kernel:     shadow (ino: 1202, highest_version: 1, size: 348)
Dec  4 11:55:08 netlinux kernel:     securetty (ino: 1201, highest_version: 1, size: 88)
Dec  4 11:55:08 netlinux kernel:     passwd (ino: 1200, highest_version: 1, size: 448)
Dec  4 11:55:08 netlinux kernel:   sbin/ (ino: 1258, highest_version: 1, size: 0)
Dec  4 11:55:08 netlinux kernel:     swapon (ino: 1279, highest_version: 1, size: 12)
Dec  4 11:55:08 netlinux kernel:     swapoff (ino: 1278, highest_version: 1, size: 12)
Dec  4 11:55:08 netlinux kernel:     sfdisk (ino: 1277, highest_version: 1, size: 12)
Dec  4 11:55:08 netlinux kernel:     rmmod (ino: 1276, highest_version: 1, size: 12)
Dec  4 11:55:08 netlinux kernel:     reboot (ino: 1275, highest_version: 1, size: 12)
Dec  4 11:55:08 netlinux kernel:     poweroff (ino: 1274, highest_version: 1, size: 12)
Dec  4 11:55:08 netlinux kernel:     mkswap (ino: 1273, highest_version: 1, size: 12)
Dec  4 11:55:08 netlinux kernel:     mkfDec  4 11:55:08 netlinux kernel:     makedevs (ino: 1271, highest_version: 1, size: 12)
Dec  4 11:55:08 netlinux kernel:     lsmod (ino: 1270, highest_version: 1, size: 12)
Dec  4 11:55:08 netlinux kernel:     loadkmap (ino: 1269, highest_version: 1, size: 12)
Dec  4 11:55:08 netlinux kernel:     init (ino: 1268, highest_version: 1, size: 12)
Dec  4 11:55:08 netlinux kernel:     halt (ino: 1267, highest_version: 1, size: 12)
Dec  4 11:55:08 netlinux kernel:     fsck.minix (ino: 1266, highest_version: 1, size: 12)
Dec  4 11:55:08 netlinux kernel:     freeramdisk (ino: 1265, highest_version: 1, size: 12)
Dec  4 11:55:08 netlinux kernel:     getty (ino: 1264, highest_version: 1, size: 14)
Dec  4 11:55:08 netlinux kernel:     e2fsck (ino: 1263, highest_version: 13, size: 413624)
Dec  4 11:55:08 netlinux kernel:     fsck.ext2 (ino: 1262, highest_version: 13, size: 413624)
Dec  4 11:55:08 netlinux kernel:     fsck (ino: 1261, highest_version: 1, size: 10960)
Dec  4 11:55:10 netlinux kernel:     ip (ino: 1260, highest_version: 3, size: 84600)
Dec  4 11:55:10 netlinux kernel:     ipchains (ino: 1259, highest_version: 3, size: 80692)
Dec  4 11:55:10 netlinux kernel:   lib/ (ino: 1217, highest_version: 1, size: 0)
Dec  4 11:55:10 netlinux kernel:     libncurses.so.4 (ino: 1239, highest_version: 1, size: 17)
Dec  4 11:55:10 netlinux kernel:     libresolv.so.2 (ino: 1238, highest_version: 1, size: 18)
Dec  4 11:55:10 netlinux kernel:     libresolv-2.1.2.so (ino: 1237, highest_version: 2, size: 43545)
Dec  4 11:55:10 netlinux kernel:     libnss_files.so.2 (ino: 1236, highest_version: 1, size: 21)
Dec  4 11:55:10 netlinux kernel:     libnss_files-2.1.2.so (ino: 1235, highest_version: 2, size: 39571)
Dec  4 11:55:10 netlinux kernel:     libnss_dns.so.2 (ino: 1234, highest_version: 1, size: 19)
Dec  4 11:55:10 netlinux kernel:     libnss_dns-2.1.2.so (ino: 1233, highest_version: 1, size: 15077)
Dec  4 11:55:10 netlinux kernel:     libnss_compat.so.2 (ino: 1232, highest_version: 1, size: 22)
Dec  4 11:55:10 netlinux kernel:     libnss_compat-2.1.2.so (ino: 1231, highest_version: 2, size: 51384)
Dec  4 11:55:10 netlinux kernel:     libnsl.so.1 (ino: 1230, highest_version: 1, size: 15)
Dec  4 11:55:10 netlinux kernel:     libnsl-2.1.2.so (ino: 1229, highest_version: 3, size: 97618)
Dec  4 11:55:10 netlinux kernel:     libm.so.6 (ino: 1228, highest_version: 1, size: 13)
Dec  4 11:55:10 netlinux kernel:     libm-2.1.2.so (ino: 1227, highest_version: 1, size: 4521)
Dec  4 11:55:10 netlinux kernel:     libdl.so.2 (ino: 1226, highest_version: 1, size: 14)
Dec  4 11:55:10 netlinux kernel:     libdl-2.1.2.so (ino: 1225, highest_version: 1, size: 4641)
Dec  4 11:55:10 netlinux kernel:     libcrypt.so.1 (ino: 1224, highest_version: 1, size: 17)
Dec  4 11:55:10 netlinux kernel:     libcrypt-2.1.2.so (ino: 1223, highest_version: 1, size: 4431)
Dec  4 11:55:10 netlinux kernel:     libc.so.6 (ino: 1222, highest_version: 1, size: 13)
Dec  4 11:55:14 netlinux kernel:     libc-2.1.2.so (ino: 1221, highest_version: 19, size: 622255)
Dec  4 11:55:14 netlinux kernel:     ld-linux.so.2 (ino: 1220, highest_version: 1, size: 11)
Dec  4 11:55:14 netlinux kernel:     ld-2.1.2.so (ino: 1219, highest_version: 3, size: 95645)
Dec  4 11:55:14 netlinux kernel:     libncurses.so.4.2 (ino: 1218, highest_version: 9, size: 281191)
Dec  4 11:55:14 netlinux kernel:   boot/ (ino: 52, highest_version: 1, size: 0)
Dec  4 11:55:14 netlinux kernel:     map (ino: 58, highest_version: 1, size: 13824)
Dec  4 11:55:14 netlinux kernel:     boot.0308 (ino: 57, highest_version: 1, size: 512)
Dec  4 11:55:14 netlinux kernel:     vmlinuz.imp (ino: 56, highest_version: 14, size: 458295)
Dec  4 11:55:14 netlinux kernel:     vmlinuz.zimg (ino: 55, highest_version: 14, size: 458300)
Dec  4 11:55:14 netlinux kernel:     boot.b (ino: 54, highest_version: 1, size: 4580)
Dec  4 11:55:14 netlinux kernel:     bzembImage (ino: 53, highest_version: 12, size: 386982)
Dec  4 11:55:14 netlinux kernel:   home/ (ino: 1207, highest_version: 1, size: 0)
Dec  4 11:55:14 netlinux kernel:     mlangsdo/ (ino: 1213, highest_version: 1, size: 0)
Dec  4 11:55:14 netlinux kernel:       amd/ (ino: 1216, highest_version: 1, size: 0)
Dec  4 11:55:14 netlinux kernel:       ToOeE.txt (ino: 1215, highest_version: 1, size: 10326)
Dec  4 11:55:14 netlinux kernel:       offers (ino: 1214, highest_version: 1, size: 338)
Dec  4 11:55:14 netlinux kernel:     httpd/ (ino: 1208, highest_version: 1, size: 0)
Dec  4 11:55:14 netlinux kernel:       html/ (ino: 1209, highest_version: 1, size: 0)
Dec  4 11:55:14 netlinux kernel:         lineo.gif (ino: 1212, highest_version: 1, size: 1591)
Dec  4 11:55:14 netlinux kernel:         index.html (ino: 1211, highest_version: 1, size: 1106)
Dec  4 11:55:14 netlinux kernel:         cgi-bin/ (ino: 1210, highest_version: 1, size: 0)
Dec  4 11:55:14 netlinux kernel:   bin/ (ino: 3, highest_version: 1, size: 0)
Dec  4 11:55:14 netlinux kernel:     pwd (ino: 39, highest_version: 1, size: 12)
Dec  4 11:55:14 netlinux kernel:     ps (ino: 38, highest_version: 1, size: 12)
Dec  4 11:55:14 netlinux kernel:     ping (ino: 37, highest_version: 1, size: 12)
Dec  4 11:55:14 netlinux kernel:     mv (ino: 36, highest_version: 1, size: 12)
Dec  4 11:55:14 netlinux kernel:     mt (ino: 35, highest_version: 1, size: 12)
Dec  4 11:55:14 netlinux kernel:     mount (ino: 34, highest_version: 1, size: 12)
Dec  4 11:55:14 netlinux kernel:     more (ino: 33, highest_version: 1, size: 12)
Dec  4 11:55:14 netlinux kernel:     mknod (ino: 32, highest_version: 1, size: 12)
Dec  4 11:55:14 netlinux kernel:     mkdir (ino: 31, highest_version: 1, size: 12)
Dec  4 11:55:14 netlinux kernel:     ls (ino: 30, highest_version: 1, size: 12)
Dec  4 11:55:14 netlinux kernel:     ln (ino: 29, highest_version: 1, size: 12)
Dec  4 11:55:14 netlinux kernel:     kill (ino: 28, highest_version: 1, size: 12)
Dec  4 11:55:14 netlinux kernel:     gzip (ino: 27, highest_version: 1, size: 12)
Dec  4 11:55:14 netlinux kernel:     gunzip (ino: 26, highest_version: 1, size: 12)
Dec  4 11:55:14 netlinux kernel:     grep (ino: 25, highest_version: 1, size: 12)
Dec  4 11:55:14 netlinux kernel:     fdflush (ino: 24, highest_version: 1, size: 12)
Dec  4 11:55:14 netlinux kernel:     false (ino: 23, highest_version: 1, size: 12)
Dec  4 11:55:14 netlinux kernel:     echo (ino: 22, highest_version: 1, size: 12)
Dec  4 11:55:14 netlinux kernel:     du (ino: 21, highest_version: 1, size: 12)
Dec  4 11:55:14 netlinux kernel:     dmesg (ino: 20, highest_version: 1, size: 12)
Dec  4 11:55:18 netlinux kernel:     df (ino: 19, highest_version: 1, size: 12)
Dec  4 11:55:18 netlinux kernel:     dd (ino: 18, highest_version: 1, size: 12)
Dec  4 11:55:18 netlinux kernel:     date (ino: 17, highest_version: 1, size: 12)
Dec  4 11:55:18 netlinux kernel:     cp (ino: 16, highest_version: 1, size: 12)
Dec  4 11:55:18 netlinux kernel:     chown (ino: 15, highest_version: 1, size: 12)
Dec  4 11:55:18 netlinux kernel:     chmod (ino: 14, highest_version: 1, size: 12)
Dec  4 11:55:18 netlinux kernel:     chgrp (ino: 13, highest_version: 1, size: 12)
Dec  4 11:55:18 netlinux kernel:     cat (ino: 12, highest_version: 1, size: 12)
Dec  4 11:55:18 netlinux kernel:     busybox (ino: 11, highest_version: 6, size: 187280)
Dec  4 11:55:18 netlinux kernel:     sh (ino: 51, highest_version: 1, size: 3)
Dec  4 11:55:18 netlinux kernel:     tinylogin (ino: 10, highest_version: 2, size: 50576)
Dec  4 11:55:18 netlinux kernel:     ash (ino: 50, highest_version: 3, size: 95580)
Dec  4 11:55:18 netlinux kernel:     su (ino: 9, highest_version: 1, size: 14)
Dec  4 11:55:18 netlinux kernel:     zcat (ino: 49, highest_version: 1, size: 12)
Dec  4 11:55:18 netlinux kernel:     login (ino: 8, highest_version: 1, size: 14)
Dec  4 11:55:18 netlinux kernel:     uname (ino: 48, highest_version: 1, size: 12)
Dec  4 11:55:18 netlinux kernel:     deluser (ino: 7, highest_version: 1, size: 14)
Dec  4 11:55:18 netlinux kernel:     umount (ino: 47, highest_version: 1, size: 12)
Dec  4 11:55:18 netlinux kernel:     delgroup (ino: 6, highest_version: 1, size: 14)
Dec  4 11:55:18 netlinux kernel:     true (ino: 46, highest_version: 1, size: 12)
Dec  4 11:55:18 netlinux kernel:     adduser (ino: 5, highest_version: 1, size: 14)
Dec  4 11:55:18 netlinux kernel:     tar (ino: 45, highest_version: 1, size: 12)
Dec  4 11:55:18 netlinux kernel:     addgroup (ino: 4, highest_version: 1, size: 14)
Dec  4 11:55:18 netlinux kernel:     sync (ino: 44, highest_version: 1, size: 12)
Dec  4 11:55:18 netlinux kernel:     sleep (ino: 43, highest_version: 1, size: 12)
Dec  4 11:55:18 netlinux kernel:     sed (ino: 42, highest_version: 1, size: 12)
Dec  4 11:55:18 netlinux kernel:     rmdir (ino: 41, highest_version: 1, size: 12)
Dec  4 11:55:18 netlinux kernel:     rm (ino: 40, highest_version: 1, size: 12)
Dec  4 11:55:18 netlinux kernel:   root/ (ino: 1243, highest_version: 1, size: 0)
Dec  4 11:55:18 netlinux kernel:     d4test/ (ino: 1255, highest_version: 1, size: 0)
Dec  4 11:55:18 netlinux kernel:       thing (ino: 1257, highest_version: 1, size: 97)
Dec  4 11:55:18 netlinux kernel:       vmlinuz.wrks (ino: 1256, highest_version: 16, size: 494731)
Dec  4 11:55:18 netlinux kernel:     d3test/ (ino: 1252, highest_version: 1, size: 0)
Dec  4 11:55:18 netlinux kernel:       thing (ino: 1254, highest_version: 1, size: 97)
Dec  4 11:55:18 netlinux kernel:       vmlinuz.wrks (ino: 1253, highest_version: 16, size: 494731)
Dec  4 11:55:18 netlinux kernel:     d2test/ (ino: 1249, highest_version: 1, size: 0)
Dec  4 11:55:18 netlinux kernel:       thing (ino: 1251, highest_version: 1, size: 97)
Dec  4 11:55:18 netlinux kernel:       vmlinuz.wrks (ino: 1250, highest_version: 16, size: 494731)
Dec  4 11:55:18 netlinux kernel:     dtest/ (ino: 1246, highest_version: 1, size: 0)
Dec  4 11:55:18 netlinux kernel:       thing (ino: 1248, highest_version: 1, size: 97)
Dec  4 11:55:18 netlinux kernel:       vmlinuz.wrks (ino: 1247, highest_version: 16, size: 494731)
Dec  4 11:55:18 netlinux kernel:     lilo.conf (ino: 1245, highest_version: 1, size: 467)
Dec  4 11:55:18 netlinux kernel:     .profile (ino: 1244, highest_version: 1, size: 80)
Dec  4 11:55:18 netlinux kernel:   lost+found/ (ino: 2, highest_version: 1, size: 0)
Dec  4 11:55:18 netlinux kernel:   proc/ (ino: 1242, highest_version: 1, size: 0)
Dec  4 11:55:18 netlinux kernel:   tst/ (ino: 1362, highest_version: 1, size: 0)
Dec  4 11:55:22 netlinux kernel:   opt/ (ino: 1241, highest_version: 1, size: 0)
Dec  4 11:55:22 netlinux kernel:   usr/ (ino: 1281, highest_version: 1, size: 0)
Dec  4 11:55:22 netlinux kernel:     share/ (ino: 1318, highest_version: 1, size: 0)
Dec  4 11:55:22 netlinux kernel:       terminfo/ (ino: 1319, highest_version: 1, size: 0)
Dec  4 11:55:22 netlinux kernel:         x/ (ino: 1340, highest_version: 1, size: 0)
Dec  4 11:55:22 netlinux kernel:           xterm-xfree86 (ino: 1343, highest_version: 1, size: 1840)
Dec  4 11:55:22 netlinux kernel:           xterm-new (ino: 1342, highest_version: 1, size: 18)
Dec  4 11:55:22 netlinux kernel:           xterm (ino: 1341, highest_version: 1, size: 1366)
Dec  4 11:55:22 netlinux kernel:         v/ (ino: 1334, highest_version: 1, size: 0)
Dec  4 11:55:22 netlinux kernel:           vt52 (ino: 1339, highest_version: 1, size: 462)
Dec  4 11:55:22 netlinux kernel:           vt220 (ino: 1338, highest_version: 1, size: 975)
Dec  4 11:55:22 netlinux kernel:           vt200 (ino: 1337, highest_version: 1, size: 10)
Dec  4 11:55:22 netlinux kernel:           vt100-am (ino: 1336, highest_version: 1, size: 10)
Dec  4 11:55:22 netlinux kernel:           vt100 (ino: 1335, highest_version: 1, size: 1143)
Dec  4 11:55:22 netlinux kernel:         s/ (ino: 1328, highest_version: 1, size: 0)
Dec  4 11:55:22 netlinux kernel:           sun2 (ino: 1333, highest_version: 1, size: 8)
Dec  4 11:55:22 netlinux kernel:           sun1 (ino: 1332, highest_version: 1, size: 8)
Dec  4 11:55:22 netlinux kernel:           sun (ino: 1331, highest_version: 1, size: 1019)
Dec  4 11:55:22 netlinux kernel:           screen-w (ino: 1330, highest_version: 1, size: 1334)
Dec  4 11:55:22 netlinux kernel:           screen (ino: 1329, highest_version: 1, size: 1318)
Dec  4 11:55:22 netlinux kernel:         r/ (ino: 1326, highest_version: 1, size: 0)
Dec  4 11:55:22 netlinux kernel:           rxvt (ino: 1327, highest_version: 1, size: 1627)
Dec  4 11:55:22 netlinux kernel:         l/ (ino: 1324, highest_version: 1, size: 0)
Dec  4 11:55:22 netlinux kernel:           linux (ino: 1325, highest_version: 1, size: 1552)
Dec  4 11:55:22 netlinux kernel:         d/ (ino: 1322, highest_version: 1, size: 0)
Dec  4 11:55:22 netlinux kernel:           dumb (ino: 1323, highest_version: 1, size: 308)
Dec  4 11:55:22 netlinux kernel:         a/ (ino: 1320, highest_version: 1, size: 0)
Dec  4 11:55:22 netlinux kernel:           ansi (ino: 1321, highest_version: 1, size: 1450)
Dec  4 11:55:22 netlinux kernel:     lib/ (ino: 1344, highest_version: 1, size: 0)
Dec  4 11:55:22 netlinux kernel:       libslang.so.1 (ino: 1346, highest_version: 1, size: 17)
Dec  4 11:55:22 netlinux kernel:       libslang.so.1.3.7 (ino: 1345, highest_version: 12, size: 366280)
Dec  4 11:55:22 netlinux kernel:     bin/ (ino: 1289, highest_version: 1, size: 0)
Dec  4 11:55:22 netlinux kernel:       whoami (ino: 1317, highest_version: 1, size: 12)
Dec  4 11:55:22 netlinux kernel:       uptime (ino: 1316, highest_version: 1, size: 12)
Dec  4 11:55:22 netlinux kernel:       tty (ino: 1315, highest_version: 1, size: 12)
Dec  4 11:55:23 netlinux kernel:       tr (ino: 1314, highest_version: 1, size: 12)
Dec  4 11:55:23 netlinux kernel:       tail (ino: 1313, highest_version: 1, size: 12)
Dec  4 11:55:23 netlinux kernel:       printf (ino: 1312, highest_version: 1, size: 12)
Dec  4 11:55:23 netlinux kernel:       nslookup (ino: 1311, highest_version: 1, size: 12)
Dec  4 11:55:23 netlinux kernel:       mnc (ino: 1310, highest_version: 1, size: 12)
Dec  4 11:55:23 netlinux kernel:       mkfifo (ino: 1309, highest_version: 1, size: 12)
Dec  4 11:55:23 netlinux kernel:       math (ino: 1308, highest_version: 1, size: 12)
Dec  4 11:55:26 netlinux kernel:       logger (ino: 1307, highest_version: 1, size: 12)
Dec  4 11:55:27 netlinux kernel:       loadfont (ino: 1306, highest_version: 1, size: 12)
Dec  4 11:55:27 netlinux kernel:       loadacm (ino: 1305, highest_version: 1, size: 12)
Dec  4 11:55:27 netlinux kernel:       length (ino: 1304, highest_version: 1, size: 12)
Dec  4 11:55:27 netlinux kernel:       killall (ino: 1303, highest_version: 1, size: 12)
Dec  4 11:55:27 netlinux kernel:       hostid (ino: 1302, highest_version: 1, size: 12)
Dec  4 11:55:27 netlinux kernel:       free (ino: 1301, highest_version: 1, size: 12)
Dec  4 11:55:27 netlinux kernel:       find (ino: 1300, highest_version: 1, size: 12)
Dec  4 11:55:27 netlinux kernel:       dirname (ino: 1299, highest_version: 1, size: 12)
Dec  4 11:55:27 netlinux kernel:       clear (ino: 1298, highest_version: 1, size: 12)
Dec  4 11:55:27 netlinux kernel:       chvt (ino: 1297, highest_version: 1, size: 12)
Dec  4 11:55:27 netlinux kernel:       basename (ino: 1296, highest_version: 1, size: 12)
Dec  4 11:55:27 netlinux kernel:       passwd (ino: 1295, highest_version: 1, size: 14)
Dec  4 11:55:27 netlinux kernel:       strace (ino: 1294, highest_version: 4, size: 102188)
Dec  4 11:55:27 netlinux kernel:       ftp (ino: 1293, highest_version: 2, size: 64116)
Dec  4 11:55:27 netlinux kernel:       telnet (ino: 1292, highest_version: 4, size: 104796)
Dec  4 11:55:27 netlinux kernel:       vi (ino: 1291, highest_version: 1, size: 5)
Dec  4 11:55:27 netlinux kernel:       elvis (ino: 1290, highest_version: 3, size: 78130)
Dec  4 11:55:27 netlinux kernel:     sbin/ (ino: 1282, highest_version: 1, size: 0)
Dec  4 11:55:27 netlinux kernel:       syslogd (ino: 1288, highest_version: 1, size: 25916)
Dec  4 11:55:27 netlinux kernel:       klogd (ino: 1287, highest_version: 1, size: 19260)
Dec  4 11:55:27 netlinux kernel:       fbset (ino: 1286, highest_version: 1, size: 12)
Dec  4 11:55:27 netlinux kernel:       telnet_wrapper (ino: 1285, highest_version: 1, size: 164)
Dec  4 11:55:27 netlinux kernel:       in.telnetd (ino: 1284, highest_version: 2, size: 36596)
Dec  4 11:55:27 netlinux kernel:       thttpd (ino: 1283, highest_version: 3, size: 71828)
Dec  4 11:55:27 netlinux kernel:   mnt/ (ino: 1240, highest_version: 1, size: 0)
Dec  4 11:55:27 netlinux kernel:   tmp/ (ino: 1280, highest_version: 1, size: 0)
Dec  4 11:55:27 netlinux kernel: jffs_read_inode(): inode->i_ino == 1
Dec  4 11:55:27 netlinux kernel: jffs_find_file(): ino: 1
Dec  4 11:55:27 netlinux kernel: jffs_find_file(): Found file with ino 1. (name: "")

cd /tst/root/
Dec  4 11:55:59 netlinux kernel: jffs_readdir(): inode: 0xc0b0cdd0, filp: 0xc092ceb0
Dec  4 11:55:59 netlinux kernel: jffs_readdir(): "." 1
Dec  4 11:55:59 netlinux kernel: jffs_readdir(): ".." 1
Dec  4 11:55:59 netlinux kernel: jffs_readdir(): "var" ino: 1347
Dec  4 11:55:59 netlinux kernel: jffs_readdir(): "dev" ino: 59
Dec  4 11:55:59 netlinux kernel: jffs_readdir(): "etc" ino: 1178
Dec  4 11:55:59 netlinux kernel: jffs_readdir(): "sbin" ino: 1258
Dec  4 11:55:59 netlinux kernel: jffs_readdir(): "lib" ino: 1217
Dec  4 11:55:59 netlinux kernel: jffs_readdir(): "boot" ino: 52
Dec  4 11:55:59 netlinux kernel: jffs_readdir(): "home" ino: 1207
Dec  4 11:55:59 netlinux kernel: jffs_readdir(): "bin" ino: 3
Dec  4 11:55:59 netlinux kernel: jffs_readdir(): "root" ino: 1243
Dec  4 11:55:59 netlinux kernel: jffs_readdir(): "lost+found" ino: 2
Dec  4 11:55:59 netlinux kernel: jffs_readdir(): "proc" ino: 1242
Dec  4 11:55:59 netlinux kernel: jffs_readdir(): "tst" ino: 1362
Dec  4 11:55:59 netlinux kernel: jffs_readdir(): "opt" ino: 1241
Dec  4 11:55:59 netlinux kernel: jffs_readdir(): "usr" ino: 1281
Dec  4 11:55:59 netlinux kernel: jffs_readdir(): "mnt" ino: 1240
Dec  4 11:55:59 netlinux kernel: jffs_readdir(): "tmp" ino: 1280
Dec  4 11:55:59 netlinux kernel: jffs_readdir(): inode: 0xc0b0cdd0, filp: 0xc092ceb0
Dec  4 11:55:59 netlinux kernel: jffs_lookup(): dir: 0xc0b0cdd0, name: "root"
Dec  4 11:55:59 netlinux kernel: jffs_find_child()
Dec  4 11:55:59 netlinux kernel: jffs_find_child(): Found "root".
Dec  4 11:55:59 netlinux kernel: jffs_read_inode(): inode->i_ino == 1243
Dec  4 11:55:59 netlinux kernel: jffs_find_file(): ino: 1243
Dec  4 11:55:59 netlinux kernel: jffs_find_file(): Found file with ino 1243. (name: "root")

cp lilo.conf first (long delay)
Dec  4 11:59:14 netlinux kernel:         0x0000,     /* gid  */
Dec  4 11:59:14 netlinux kernel:         0x3a27f644, /* atime  */
Dec  4 11:59:14 netlinux kernel:         0x3a01980c, /* mtime  */
Dec  4 11:59:14 netlinux kernel:         0x3a01980c, /* ctime  */
Dec  4 11:59:18 netlinux kernel:         0x00000000, /* offset  */
Dec  4 11:59:18 netlinux kernel:         0x0000000e, /* dsize  */
Dec  4 11:59:18 netlinux kernel:         0x0000000e, /* rsize  */
Dec  4 11:59:18 netlinux kernel:         0x02,       /* nsize  */
Dec  4 11:59:18 netlinux kernel:         0x01,       /* nlink  */
Dec  4 11:59:18 netlinux kernel:         0x00,       /* spare  */
Dec  4 11:59:18 netlinux kernel:         0,          /* rename  */
Dec  4 11:59:18 netlinux kernel:         0,          /* deleted  */
Dec  4 11:59:18 netlinux kernel:         0xff,       /* accurate  */
Dec  4 11:59:18 netlinux kernel:         0x00000000, /* dchksum  */
Dec  4 11:59:18 netlinux kernel:         0x0000,     /* nchksum  */
Dec  4 11:59:18 netlinux kernel:         0x0000,     /* chksum  */
Dec  4 11:59:18 netlinux kernel: }
Dec  4 11:59:18 netlinux kernel: jffs_rewrite_data(): Writing name "su" to pos 0x7156572l.
Dec  4 11:59:18 netlinux kernel: , result: 0x000000e8
Dec  4 11:59:18 netlinux kernel: jffs_read_data(): file = "su", read_offset = 0, size = 14
Dec  4 11:59:18 netlinux kernel:   jffs_get_node_data(): file: "su", ino: 9, version: 1, node_offset: 0
Dec  4 11:59:18 netlinux kernel:   jffs_get_node_data(): Read 14 bytes.
Dec  4 11:59:18 netlinux kernel:   jffs_read_data(): Read 14 bytes.
Dec  4 11:59:18 netlinux kernel: , result: 0x00000574
Dec  4 11:59:18 netlinux kernel: , result: 0x0000075d
Dec  4 11:59:18 netlinux kernel: jffs_insert_node(): ino = 9, version = 2, name = "su", deleted = 0
Dec  4 11:59:18 netlinux kernel: jffs_insert_node(): ---------------------------------------------------------------------- 1
Dec  4 11:59:18 netlinux kernel: jffs_update_file(): ino: 9, version: 2
Dec  4 11:59:18 netlinux kernel: jffs_delete_data(): offset = 0, remove_size = 14
Dec  4 11:59:18 netlinux kernel: jffs_delete_data(): Removing node: ino: 9, version: 1
Dec  4 11:59:18 netlinux kernel: jffs_fmfree(): node->ino = 9, node->version = 1
Dec  4 11:59:18 netlinux kernel: jffs_delete_data(): f->size = 0
Dec  4 11:59:18 netlinux kernel: jffs_insert_data(): node->data_offset = 0, node->data_size = 14, f->size = 0
Dec  4 11:59:18 netlinux kernel: jffs_insert_data(): f->size = 14
Dec  4 11:59:18 netlinux kernel: jffs_remove_redundant_nodes(): ino: 9, name: "su", newest_type: 7
Dec  4 11:59:18 netlinux kernel: jffs_insert_node(): ---------------------------------------------------------------------- 2
Dec  4 11:59:18 netlinux kernel: jffs_rewrite_data(): Leaving...
Dec  4 11:59:18 netlinux kernel: jffs_garbage_collect_next: Leaving...
Dec  4 11:59:18 netlinux kernel: ***jffs_garbage_collect_thread(): round #10, fmc->dirty_size = 142500
Dec  4 11:59:18 netlinux kernel: struct jffs_fmcontrol: 0xc0818640
Dec  4 11:59:18 netlinux kernel: {
Dec  4 11:59:18 netlinux kernel:         0x00000000, /* flash_start  */
Dec  4 11:59:18 netlinux kernel:         15204352, /* flash_size  */
Dec  4 11:59:18 netlinux kernel:         7014092, /* used_size  */
Dec  4 11:59:18 netlinux kernel:         142500, /* dirty_size  */
Dec  4 11:59:18 netlinux kernel:         8047760, /* free_size  */
Dec  4 11:59:18 netlinux kernel:         131072, /* sector_size  */
Dec  4 11:59:18 netlinux kernel:         262144, /* min_free_size  */
Dec  4 11:59:18 netlinux kernel:         65536, /* max_chunk_size  */
Dec  4 11:59:18 netlinux kernel:         0xc0094980, /* mtd  */
Dec  4 11:59:18 netlinux kernel:         0xc06445c0, /* head  */    (head->offset = 0x00000000)
Dec  4 11:59:18 netlinux kernel:         0xc0644d10, /* tail  */    (tail->offset + tail->size = 0x006d3370)
Dec  4 11:59:18 netlinux kernel:         0x00000000, /* head_extra  */
Dec  4 11:59:18 netlinux kernel:         0x00000000, /* tail_extra  */
Dec  4 11:59:18 netlinux kernel: }
Dec  4 11:59:18 netlinux kernel: jffs_try_to_erase()
Dec  4 11:59:18 netlinux kernel: jffs_try_to_erase(): erase_size = 0
Dec  4 11:59:23 netlinux kernel: jffs_get_oldest_node(): ino = 10, version = 1
Dec  4 11:59:23 netlinux kernel: jffs_find_file(): ino: 10
Dec  4 11:59:23 netlinux kernel: jffs_find_file(): Found file with ino 10. (name: "tinylogin")
Dec  4 11:59:23 netlinux kernel: jffs_garbage_collect_next(): "tinylogin", ino: 10, version: 1, location 0x2b8, dsize 32768
Dec  4 11:59:23 netlinux kernel:   total_name_size: 12
Dec  4 11:59:23 netlinux kernel:   data_size: 50576
Dec  4 11:59:23 netlinux kernel:   size: 50648
Dec  4 11:59:23 netlinux kernel:   f->nsize: 9
Dec  4 11:59:23 netlinux kernel:   f->size: 50576
Dec  4 11:59:23 netlinux kernel:   node->data_offset: 0
Dec  4 11:59:23 netlinux kernel:   free_chunk_size1: 8047760
Dec  4 11:59:23 netlinux kernel:   free_chunk_size2: 0
Dec  4 11:59:23 netlinux kernel:   node->fm->offset: 0x000002b8
Dec  4 11:59:23 netlinux kernel: ***jffs_rewrite_data(): node: 10, name: "tinylogin", size: 50576
Dec  4 11:59:23 netlinux kernel: jffs_fmalloc(): fmc = 0xc0818640, size = 50648, node = 0xc0cea1c0
Dec  4 11:59:23 netlinux kernel: jffs_fmalloc(): free_chunk_size1 = 8047760, free_chunk_size2 = 0
Dec  4 11:59:23 netlinux kernel: struct jffs_fmcontrol: 0xc0818640
Dec  4 11:59:23 netlinux kernel: {
Dec  4 11:59:23 netlinux kernel:         0x00000000, /* flash_start  */
Dec  4 11:59:23 netlinux kernel:         15204352, /* flash_size  */
Dec  4 11:59:23 netlinux kernel:         7064740, /* used_size  */
Dec  4 11:59:23 netlinux kernel:         142500, /* dirty_size  */
Dec  4 11:59:23 netlinux kernel:         7997112, /* free_size  */
Dec  4 11:59:23 netlinux kernel:         131072, /* sector_size  */
Dec  4 11:59:23 netlinux kernel:         262144, /* min_free_size  */
Dec  4 11:59:23 netlinux kernel:         65536, /* max_chunk_size  */
Dec  4 11:59:23 netlinux kernel:         0xc0094980, /* mtd  */
Dec  4 11:59:23 netlinux kernel:         0xc06445c0, /* head  */    (head->offset = 0x00000000)
Dec  4 11:59:23 netlinux kernel:         0xc0644c80, /* tail  */    (tail->offset + tail->size = 0x006df948)
Dec  4 11:59:23 netlinux kernel:         0x00000000, /* head_extra  */
Dec  4 11:59:23 netlinux kernel:         0x00000000, /* tail_extra  */
Dec  4 11:59:23 netlinux kernel: }
Dec  4 11:59:23 netlinux kernel: struct jffs_fm: 0xc0644c80
Dec  4 11:59:23 netlinux kernel: {
Dec  4 11:59:23 netlinux kernel:        0x006d3370, /* offset  */
Dec  4 11:59:23 netlinux kernel:        50648, /* size  */
Dec  4 11:59:23 netlinux kernel:        0xc0644d10, /* prev  */
Dec  4 11:59:23 netlinux kernel:        0x00000000, /* next  */
Dec  4 11:59:23 netlinux kernel:        0xc0644cb0, /* nodes  */
Dec  4 11:59:23 netlinux kernel: }
Dec  4 11:59:23 netlinux kernel: jffs_rewrite_data(): Writing this raw inode to pos 0x7156592l.
Dec  4 11:59:23 netlinux kernel: jffs_raw_inode: inode number: 10
Dec  4 11:59:23 netlinux kernel: {
Dec  4 11:59:23 netlinux kernel:         0x34383931, /* magic  */
Dec  4 11:59:23 netlinux kernel:         0x0000000a, /* ino  */
Dec  4 11:59:23 netlinux kernel:         0x00000003, /* pino  */
Dec  4 11:59:23 netlinux kernel:         0x00000003, /* version  */
Dec  4 11:59:23 netlinux kernel:         0x000089ed, /* mode  */
Dec  4 11:59:23 netlinux kernel:         0x0000,     /* uid  */
Dec  4 11:59:23 netlinux kernel:         0x0000,     /* gid  */
Dec  4 11:59:23 netlinux kernel:         0x3a27f644, /* atime  */
Dec  4 11:59:23 netlinux kernel:         0x39f86ec6, /* mtime  */
Dec  4 11:59:23 netlinux kernel:         0x3a01980c, /* ctime  */
Dec  4 11:59:23 netlinux kernel:         0x00000000, /* offset  */
Dec  4 11:59:23 netlinux kernel:         0x0000c590, /* dsize  */
Dec  4 11:59:23 netlinux kernel:         0x0000c590, /* rsize  */
Dec  4 11:59:23 netlinux kernel:         0x09,       /* nsize  */
Dec  4 11:59:23 netlinux kernel:         0x01,       /* nlink  */
Dec  4 11:59:27 netlinux kernel:         0x00,       /* spare  */
Dec  4 11:59:27 netlinux kernel:         0,          /* rename  */
Dec  4 11:59:27 netlinux kernel:         0,          /* deleted  */
Dec  4 11:59:27 netlinux kernel:         0xff,       /* accurate  */
Dec  4 11:59:27 netlinux kernel:         0x00000000, /* dchksum  */
Dec  4 11:59:27 netlinux kernel:         0x0000,     /* nchksum  */
Dec  4 11:59:27 netlinux kernel:         0x0000,     /* chksum  */
Dec  4 11:59:27 netlinux kernel: }
Dec  4 11:59:27 netlinux kernel: jffs_rewrite_data(): Writing name "tinylogin" to pos 0x7156652l.
Dec  4 11:59:27 netlinux kernel: , result: 0x000003dd
Dec  4 11:59:27 netlinux kernel: jffs_read_data(): file = "tinylogin", read_offset = 0, size = 4096
Dec  4 11:59:27 netlinux kernel:   jffs_get_node_data(): file: "tinylogin", ino: 10, version: 1, node_offset: 0
Dec  4 11:59:27 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 11:59:27 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 11:59:27 netlinux kernel: , result: 0x0001bfb2
Dec  4 11:59:27 netlinux kernel: jffs_read_data(): file = "tinylogin", read_offset = 4096, size = 4096
Dec  4 11:59:27 netlinux kernel:   jffs_get_node_data(): file: "tinylogin", ino: 10, version: 1, node_offset: 4096
Dec  4 11:59:27 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 11:59:27 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 11:59:27 netlinux kernel: , result: 0x0005191c
Dec  4 11:59:27 netlinux kernel: jffs_read_data(): file = "tinylogin", read_offset = 8192, size = 4096
Dec  4 11:59:27 netlinux kernel:   jffs_get_node_data(): file: "tinylogin", ino: 10, version: 1, node_offset: 8192
Dec  4 11:59:27 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 11:59:27 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 11:59:27 netlinux kernel: , result: 0x00073fe4
Dec  4 11:59:27 netlinux kernel: jffs_read_data(): file = "tinylogin", read_offset = 12288, size = 4096
Dec  4 11:59:27 netlinux kernel:   jffs_get_node_data(): file: "tinylogin", ino: 10, version: 1, node_offset: 12288
Dec  4 11:59:27 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 11:59:27 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 11:59:27 netlinux kernel: , result: 0x0006e68b
Dec  4 11:59:27 netlinux kernel: jffs_read_data(): file = "tinylogin", read_offset = 16384, size = 4096
Dec  4 11:59:27 netlinux kernel:   jffs_get_node_data(): file: "tinylogin", ino: 10, version: 1, node_offset: 16384
Dec  4 11:59:27 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 11:59:27 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 11:59:27 netlinux kernel: , result: 0x00063c29
Dec  4 11:59:27 netlinux kernel: jffs_read_data(): file = "tinylogin", read_offset = 20480, size = 4096
Dec  4 11:59:27 netlinux kernel:   jffs_get_node_data(): file: "tinylogin", ino: 10, version: 1, node_offset: 20480
Dec  4 11:59:27 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 11:59:27 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 11:59:27 netlinux kernel: , result: 0x00073f79
Dec  4 11:59:27 netlinux kernel: jffs_read_data(): file = "tinylogin", read_offset = 24576, size = 4096
Dec  4 11:59:27 netlinux kernel:   jffs_get_node_data(): file: "tinylogin", ino: 10, version: 1, node_offset: 24576
Dec  4 11:59:27 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 11:59:27 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 11:59:27 netlinux kernel: , result: 0x00072b6c
Dec  4 11:59:27 netlinux kernel: jffs_read_data(): file = "tinylogin", read_offset = 28672, size = 4096
Dec  4 11:59:31 netlinux kernel:   jffs_get_node_data(): file: "tinylogin", ino: 10, version: 1, node_offset: 28672
Dec  4 11:59:31 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 11:59:31 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 11:59:31 netlinux kernel: , result: 0x0008396c
Dec  4 11:59:31 netlinux kernel: jffs_read_data(): file = "tinylogin", read_offset = 32768, size = 4096
Dec  4 11:59:31 netlinux kernel:   jffs_get_node_data(): file: "tinylogin", ino: 10, version: 2, node_offset: 0
Dec  4 11:59:31 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 11:59:31 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 11:59:31 netlinux kernel: , result: 0x00084c28
Dec  4 11:59:31 netlinux kernel: jffs_read_data(): file = "tinylogin", read_offset = 36864, size = 4096
Dec  4 11:59:31 netlinux kernel:   jffs_get_node_data(): file: "tinylogin", ino: 10, version: 2, node_offset: 4096
Dec  4 11:59:31 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 11:59:31 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 11:59:31 netlinux kernel: , result: 0x0004b4bc
Dec  4 11:59:31 netlinux kernel: jffs_read_data(): file = "tinylogin", read_offset = 40960, size = 4096
Dec  4 11:59:31 netlinux kernel:   jffs_get_node_data(): file: "tinylogin", ino: 10, version: 2, node_offset: 8192
Dec  4 11:59:31 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 11:59:31 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 11:59:31 netlinux kernel: , result: 0x000408e3
Dec  4 11:59:31 netlinux kernel: jffs_read_data(): file = "tinylogin", read_offset = 45056, size = 4096
Dec  4 11:59:31 netlinux kernel:   jffs_get_node_data(): file: "tinylogin", ino: 10, version: 2, node_offset: 12288
Dec  4 11:59:31 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 11:59:31 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 11:59:31 netlinux kernel: , result: 0x0000bbff
Dec  4 11:59:31 netlinux kernel: jffs_read_data(): file = "tinylogin", read_offset = 49152, size = 1424
Dec  4 11:59:31 netlinux kernel:   jffs_get_node_data(): file: "tinylogin", ino: 10, version: 2, node_offset: 16384
Dec  4 11:59:31 netlinux kernel:   jffs_get_node_data(): Read 1424 bytes.
Dec  4 11:59:31 netlinux kernel:   jffs_read_data(): Read 1424 bytes.
Dec  4 11:59:31 netlinux kernel: , result: 0x0000b54b
Dec  4 11:59:31 netlinux kernel: , result: 0x00000c35
Dec  4 11:59:31 netlinux kernel: jffs_insert_node(): ino = 10, version = 3, name = "tinylogin", deleted = 0
Dec  4 11:59:31 netlinux kernel: jffs_insert_node(): ---------------------------------------------------------------------- 1
Dec  4 11:59:31 netlinux kernel: jffs_update_file(): ino: 10, version: 3
Dec  4 11:59:31 netlinux kernel: jffs_delete_data(): offset = 0, remove_size = 50576
Dec  4 11:59:31 netlinux kernel: jffs_delete_data(): Removing node: ino: 10, version: 1
Dec  4 11:59:31 netlinux kernel: jffs_fmfree(): node->ino = 10, node->version = 1
Dec  4 11:59:31 netlinux kernel: jffs_delete_data(): Removing node: ino: 10, version: 2
Dec  4 11:59:31 netlinux kernel: jffs_fmfree(): node->ino = 10, node->version = 2
Dec  4 11:59:31 netlinux kernel: jffs_delete_data(): f->size = 0
Dec  4 11:59:31 netlinux kernel: jffs_insert_data(): node->data_offset = 0, node->data_size = 50576, f->size = 0
Dec  4 11:59:31 netlinux kernel: jffs_insert_data(): f->size = 50576
Dec  4 11:59:31 netlinux kernel: jffs_remove_redundant_nodes(): ino: 10, name: "tinylogin", newest_type: 7
Dec  4 11:59:31 netlinux kernel: jffs_insert_node(): ---------------------------------------------------------------------- 2
Dec  4 11:59:31 netlinux kernel: jffs_rewrite_data(): Leaving...
Dec  4 11:59:31 netlinux kernel: jffs_garbage_collect_next: Leaving...
Dec  4 11:59:35 netlinux kernel: jffs_insert_node(): ---------------------------------------------------------------------- 1
Dec  4 11:59:35 netlinux kernel: jffs_update_file(): ino: 621, version: 2
Dec  4 11:59:35 netlinux kernel: jffs_delete_data(): offset = 0, remove_size = 2
Dec  4 11:59:35 netlinux kernel: jffs_delete_data(): Removing node: ino: 621, version: 1
Dec  4 11:59:35 netlinux kernel: jffs_fmfree(): node->ino = 621, node->version = 1
Dec  4 11:59:35 netlinux kernel: jffs_delete_data(): f->size = 0
Dec  4 11:59:35 netlinux kernel: jffs_insert_data(): node->data_offset = 0, node->data_size = 2, f->size = 0
Dec  4 11:59:35 netlinux kernel: jffs_insert_data(): f->size = 2
Dec  4 11:59:35 netlinux kernel: jffs_remove_redundant_nodes(): ino: 621, name: "sdd11", newest_type: 7
Dec  4 11:59:35 netlinux kernel: jffs_insert_node(): ---------------------------------------------------------------------- 2
Dec  4 11:59:35 netlinux kernel: jffs_rewrite_data(): Leaving...
Dec  4 11:59:35 netlinux kernel: jffs_garbage_collect_next: Leaving...
Dec  4 11:59:35 netlinux kernel: ***jffs_garbage_collect_thread(): round #656, fmc->dirty_size = 272736
Dec  4 11:59:35 netlinux kernel: struct jffs_fmcontrol: 0xc0818640
Dec  4 11:59:35 netlinux kernel: {
Dec  4 11:59:35 netlinux kernel:         0x00000000, /* flash_start  */
Dec  4 11:59:35 netlinux kernel:         15204352, /* flash_size  */
Dec  4 11:59:35 netlinux kernel:         7012456, /* used_size  */
Dec  4 11:59:35 netlinux kernel:         272736, /* dirty_size  */
Dec  4 11:59:35 netlinux kernel:         7919160, /* free_size  */
Dec  4 11:59:35 netlinux kernel:         131072, /* sector_size  */
Dec  4 11:59:35 netlinux kernel:         262144, /* min_free_size  */
Dec  4 11:59:35 netlinux kernel:         65536, /* max_chunk_size  */
Dec  4 11:59:35 netlinux kernel:         0xc0094980, /* mtd  */
Dec  4 11:59:35 netlinux kernel:         0xc0cad960, /* head  */    (head->offset = 0x00180000)
Dec  4 11:59:35 netlinux kernel:         0xc0d45c40, /* tail  */    (tail->offset + tail->size = 0x008729c8)
Dec  4 11:59:35 netlinux kernel:         0x00000000, /* head_extra  */
Dec  4 11:59:35 netlinux kernel:         0x00000000, /* tail_extra  */
Dec  4 11:59:35 netlinux kernel: }
Dec  4 11:59:35 netlinux kernel: jffs_try_to_erase()
Dec  4 11:59:35 netlinux kernel: jffs_try_to_erase(): erase_size = 0
Dec  4 11:59:35 netlinux kernel: jffs_get_oldest_node(): ino = 622, version = 1
Dec  4 11:59:35 netlinux kernel: jffs_find_file(): ino: 622
Dec  4 11:59:35 netlinux kernel: jffs_find_file(): Found file with ino 622. (name: "sdd12")
Dec  4 11:59:35 netlinux kernel: jffs_garbage_collect_next(): "sdd12", ino: 622, version: 1, location 0x19ff30, dsize 2
Dec  4 11:59:35 netlinux kernel:   total_name_size: 8
Dec  4 11:59:35 netlinux kernel:   data_size: 2
Dec  4 11:59:35 netlinux kernel:   size: 72
Dec  4 11:59:35 netlinux kernel:   f->nsize: 5
Dec  4 11:59:35 netlinux kernel:   f->size: 2
Dec  4 11:59:35 netlinux kernel:   node->data_offset: 0
Dec  4 11:59:35 netlinux kernel:   free_chunk_size1: 6346296
Dec  4 11:59:35 netlinux kernel:   free_chunk_size2: 1572864
Dec  4 11:59:35 netlinux kernel:   node->fm->offset: 0x0019ff30
Dec  4 11:59:35 netlinux kernel: ***jffs_rewrite_data(): node: 622, name: "sdd12", size: 2
Dec  4 11:59:35 netlinux kernel: jffs_fmalloc(): fmc = 0xc0818640, size = 72, node = 0xc0d7f3c0
Dec  4 11:59:35 netlinux kernel: jffs_fmalloc(): free_chunk_size1 = 6346296, free_chunk_size2 = 1572864
Dec  4 11:59:35 netlinux kernel: struct jffs_fmcontrol: 0xc0818640
Dec  4 11:59:35 netlinux kernel: {
Dec  4 11:59:35 netlinux kernel:         0x00000000, /* flash_start  */
Dec  4 11:59:35 netlinux kernel:         15204352, /* flash_size  */
Dec  4 11:59:35 netlinux kernel:         7012528, /* used_size  */
Dec  4 11:59:35 netlinux kernel:         272736, /* dirty_size  */
Dec  4 11:59:35 netlinux kernel:         7919088, /* free_size  */
Dec  4 11:59:35 netlinux kernel:         131072, /* sector_size  */
Dec  4 11:59:35 netlinux kernel:         262144, /* min_free_size  */
Dec  4 11:59:35 netlinux kernel:         65536, /* max_chunk_size  */
Dec  4 11:59:35 netlinux kernel:         0xc0094980, /* mtd  */
Dec  4 11:59:35 netlinux kernel:         0xc0cad960, /* head  */    (head->offset = 0x00180000)
Dec  4 11:59:35 netlinux kernel:         0xc0d45cd0, /* tail  */    (tail->offset + tail->size = 0x00872a10)
Dec  4 11:59:39 netlinux kernel:         0x00000000, /* head_extra  */
Dec  4 11:59:39 netlinux kernel:         0x00000000, /* tail_extra  */
Dec  4 11:59:39 netlinux kernel: }
Dec  4 11:59:39 netlinux kernel: struct jffs_fm: 0xc0d45cd0
Dec  4 11:59:39 netlinux kernel: {
Dec  4 11:59:39 netlinux kernel:        0x008729c8, /* offset  */
Dec  4 11:59:39 netlinux kernel:        72, /* size  */
Dec  4 11:59:39 netlinux kernel:        0xc0d45c40, /* prev  */
Dec  4 11:59:39 netlinux kernel:        0x00000000, /* next  */
Dec  4 11:59:39 netlinux kernel:        0xc0d45d00, /* nodes  */
Dec  4 11:59:39 netlinux kernel: }
Dec  4 11:59:39 netlinux kernel: jffs_rewrite_data(): Writing this raw inode to pos 0x8858056l.
Dec  4 11:59:39 netlinux kernel: jffs_raw_inode: inode number: 622
Dec  4 11:59:39 netlinux kernel: {
Dec  4 11:59:39 netlinux kernel:         0x34383931, /* magic  */
Dec  4 11:59:39 netlinux kernel:         0x0000026e, /* ino  */
Dec  4 11:59:39 netlinux kernel:         0x0000003b, /* pino  */
Dec  4 11:59:39 netlinux kernel:         0x00000002, /* version  */
Dec  4 11:59:39 netlinux kernel:         0x000061a0, /* mode  */
Dec  4 11:59:39 netlinux kernel:         0x0000,     /* uid  */
Dec  4 11:59:39 netlinux kernel:         0x0000,     /* gid  */
Dec  4 11:59:39 netlinux kernel:         0x3a01980b, /* atime  */
Dec  4 11:59:39 netlinux kernel:         0x39f812cf, /* mtime  */
Dec  4 11:59:39 netlinux kernel:         0x3a019811, /* ctime  */
Dec  4 11:59:39 netlinux kernel:         0x00000000, /* offset  */
Dec  4 11:59:39 netlinux kernel:         0x00000002, /* dsize  */
Dec  4 11:59:39 netlinux kernel:         0x00000002, /* rsize  */
Dec  4 11:59:39 netlinux kernel:         0x05,       /* nsize  */
Dec  4 11:59:39 netlinux kernel:         0x01,       /* nlink  */
Dec  4 11:59:39 netlinux kernel:         0x00,       /* spare  */
Dec  4 11:59:39 netlinux kernel:         0,          /* rename  */
Dec  4 11:59:39 netlinux kernel:         0,          /* deleted  */
Dec  4 11:59:39 netlinux kernel:         0xff,       /* accurate  */
Dec  4 11:59:39 netlinux kernel:         0x00000000, /* dchksum  */
Dec  4 11:59:39 netlinux kernel:         0x0000,     /* nchksum  */
Dec  4 11:59:39 netlinux kernel:         0x0000,     /* chksum  */
Dec  4 11:59:39 netlinux kernel: }
Dec  4 11:59:39 netlinux kernel: jffs_rewrite_data(): Writing name "sdd12" to pos 0x8858116l.
Dec  4 11:59:39 netlinux kernel: , result: 0x0000019e
Dec  4 11:59:39 netlinux kernel: jffs_read_data(): file = "sdd12", read_offset = 0, size = 2
Dec  4 11:59:39 netlinux kernel:   jffs_get_node_data(): file: "sdd12", ino: 622, version: 1, node_offset: 0
Dec  4 11:59:39 netlinux kernel:   jffs_get_node_data(): Read 2 bytes.
Dec  4 11:59:39 netlinux kernel:   jffs_read_data(): Read 2 bytes.
Dec  4 11:59:39 netlinux kernel: , result: 0x00000044
Dec  4 11:59:39 netlinux kernel: , result: 0x00000745
Dec  4 11:59:39 netlinux kernel: jffs_insert_nDec  4 11:59:39 netlinux kernel: jffs_insert_node(): ---------------------------------
------------------------------------- 1
Dec  4 11:59:39 netlinux kernel: jffs_update_file(): ino: 622, version: 2
Dec  4 11:59:39 netlinux kernel: jffs_delete_data(): offset = 0, remove_size = 2
Dec  4 11:59:39 netlinux kernel: jffs_delete_data(): Removing node: ino: 622, version: 1
Dec  4 11:59:39 netlinux kernel: jffs_fmfree(): node->ino = 622, node->version = 1
Dec  4 11:59:39 netlinux kernel: jffs_delete_data(): f->size = 0
Dec  4 11:59:39 netlinux kernel: jffs_insert_data(): node->data_offset = 0, node->data_size = 2, f->size = 0
Dec  4 11:59:39 netlinux kernel: jffs_insert_data(): f->size = 2
Dec  4 11:59:39 netlinux kernel: jffs_remove_redundant_nodes(): ino: 622, name: "sdd12", newest_type: 7
Dec  4 11:59:39 netlinux kernel: jffs_insert_node(): ---------------------------------------------------------------------- 2
Dec  4 11:59:41 netlinux kernel: jffs_rewrite_data(): Leaving...
Dec  4 11:59:41 netlinux kernel: jffs_garbage_collect_next: Leaving...
Dec  4 11:59:41 netlinux kernel: ***jffs_garbage_collect_thread(): round #657, fmc->dirty_size = 272808
Dec  4 11:59:41 netlinux kernel: struct jffs_fmcontrol: 0xc0818640
Dec  4 11:59:41 netlinux kernel: {
Dec  4 11:59:41 netlinux kernel:         0x00000000, /* flash_start  */
Dec  4 11:59:41 netlinux kernel:         15204352, /* flash_size  */
Dec  4 11:59:41 netlinux kernel:         7012456, /* used_size  */
Dec  4 11:59:41 netlinux kernel:         272808, /* dirty_size  */
Dec  4 11:59:41 netlinux kernel:         7919088, /* free_size  */
Dec  4 11:59:41 netlinux kernel:         131072, /* sector_size  */
Dec  4 11:59:41 netlinux kernel:         262144, /* min_free_size  */
Dec  4 11:59:41 netlinux kernel:         65536, /* max_chunk_size  */
Dec  4 11:59:41 netlinux kernel:         0xc0094980, /* mtd  */
Dec  4 11:59:45 netlinux kernel:         0xc0cad960, /* head  */    (head->offset = 0x00180000)
Dec  4 11:59:45 netlinux kernel:         0xc0d45cd0, /* tail  */    (tail->offset + tail->size = 0x00872a10)
Dec  4 11:59:45 netlinux kernel:         0x00000000, /* head_extra  */
Dec  4 11:59:45 netlinux kernel:         0x00000000, /* tail_extra  */
Dec  4 11:59:45 netlinux kernel: }
Dec  4 11:59:45 netlinux kernel: jffs_try_to_erase()
Dec  4 11:59:45 netlinux kernel: jffs_try_to_erase(): erase_size = 0
Dec  4 11:59:45 netlinux kernel: jffs_get_oldest_node(): ino = 623, version = 1
Dec  4 11:59:45 netlinux kernel: jffs_find_file(): ino: 623
Dec  4 11:59:45 netlinux kernel: jffs_find_file(): Found file with ino 623. (name: "sdd13")
Dec  4 11:59:45 netlinux kernel: jffs_garbage_collect_next(): "sdd13", ino: 623, version: 1, location 0x19ff78, dsize 2
Dec  4 11:59:45 netlinux kernel:   total_name_size: 8
Dec  4 11:59:45 netlinux kernel:   data_size: 2
Dec  4 11:59:45 netlinux kernel:   size: 72
Dec  4 11:59:45 netlinux kernel:   f->nsize: 5
Dec  4 11:59:45 netlinux kernel:   f->size: 2
Dec  4 11:59:45 netlinux kernel:   node->data_offset: 0
Dec  4 11:59:45 netlinux kernel:   free_chunk_size1: 6346224
Dec  4 11:59:45 netlinux kernel:   free_chunk_size2: 1572864
Dec  4 11:59:45 netlinux kernel:   node->fm->offset: 0x0019ff78
Dec  4 11:59:45 netlinux kernel: ***jffs_rewrite_data(): node: 623, name: "sdd13", size: 2
Dec  4 11:59:45 netlinux kernel: jffs_fmalloc(): fmc = 0xc0818640, size = 72, node = 0xc0d7f410
Dec  4 11:59:45 netlinux kernel: jffs_fmalloc(): free_chunk_size1 = 6346224, free_chunk_size2 = 1572864
Dec  4 11:59:45 netlinux kernel: struct jffs_fmcontrol: 0xc0818640
Dec  4 11:59:45 netlinux kernel: {
Dec  4 11:59:45 netlinux kernel:         0x00000000, /* flash_start  */
Dec  4 11:59:45 netlinux kernel:         15204352, /* flash_size  */
Dec  4 11:59:45 netlinux kernel:         7012528, /* used_size  */
Dec  4 11:59:45 netlinux kernel:         272808, /* dirty_size  */
Dec  4 11:59:45 netlinux kernel:         7919016, /* free_size  */
Dec  4 11:59:45 netlinux kernel:         131072, /* sector_size  */
Dec  4 11:59:45 netlinux kernel:         262144, /* min_free_size  */
Dec  4 11:59:45 netlinux kernel:         65536, /* max_chunk_size  */
Dec  4 11:59:45 netlinux kernel:         0xc0094980, /* mtd  */
Dec  4 11:59:45 netlinux kernel:         0xc0cad960, /* head  */    (head->offset = 0x00180000)
Dec  4 11:59:45 netlinux kernel:         0xc0d45d60, /* tail  */    (tail->offset + tail->size = 0x00872a58)
Dec  4 11:59:45 netlinux kernel:         0x00000000, /* head_extra  */
Dec  4 11:59:45 netlinux kernel:         0x00000000, /* tail_extra  */
Dec  4 11:59:45 netlinux kernel: }
Dec  4 11:59:45 netlinux kernel: struct jffs_fm: 0xc0d45d60
Dec  4 11:59:45 netlinux kernel: {
Dec  4 11:59:45 netlinux kernel:        0x00872a10, /* offset  */
Dec  4 11:59:45 netlinux kernel:        72, /* size  */
Dec  4 11:59:45 netlinux kernel:        0xc0d45cd0, /* prev  */
Dec  4 11:59:45 netlinux kernel:        0x00000000, /* next  */
Dec  4 11:59:45 netlinux kernel:        0xc0d45d90, /* nodes  */
Dec  4 11:59:45 netlinux kernel: }
Dec  4 11:59:45 netlinux kernel: jffs_rewrite_data(): Writing this raw inode to pos 0x8858128l.
Dec  4 11:59:45 netlinux kernel: jffs_raw_inode: inode number: 623
Dec  4 11:59:45 netlinux kernel: {
Dec  4 11:59:45 netlinux kernel:         0x34383931, /* magic  */
Dec  4 11:59:45 netlinux kernel:         0x0000026f, /* ino  */
Dec  4 11:59:45 netlinux kernel:         0x0000003b, /* pino  */
Dec  4 11:59:45 netlinux kernel:         0x00000002, /* version  */
Dec  4 11:59:45 netlinux kernel:         0x000061a0, /* mode  */
Dec  4 11:59:45 netlinux kernel:         0x0000,     /* uid  */
Dec  4 11:59:45 netlinux kernel:         0x0000,     /* gid  */
Dec  4 11:59:45 netlinux kernel:         0x3a01980b, /* atime  */
Dec  4 11:59:45 netlinux kernel:         0x39f812cf, /* mtime  */
Dec  4 11:59:45 netlinux kernel:         0x3a019811, /* ctime  */
Dec  4 11:59:45 netlinux kernel:         0x00000000, /* offset  */
Dec  4 11:59:49 netlinux kernel:         0x00000002, /* dsize  */
Dec  4 11:59:49 netlinux kernel:         0x00000002, /* rsize  */
Dec  4 11:59:49 netlinux kernel:         0x05,       /* nsize  */
Dec  4 11:59:49 netlinux kernel:         0x01,       /* nlink  */
Dec  4 11:59:49 netlinux kernel:         0x00,       /* spare  */
Dec  4 11:59:49 netlinux kernel:         0,          /* rename  */
Dec  4 11:59:49 netlinux kernel:         0,          /* deleted  */
Dec  4 11:59:49 netlinux kernel:         0xff,       /* accurate  */
Dec  4 11:59:49 netlinux kernel:         0x00000000, /* dchksum  */
Dec  4 11:59:49 netlinux kernel:         0x0000,     /* nchksum  */
Dec  4 11:59:49 netlinux kernel:         0x0000,     /* chksum  */
Dec  4 11:59:49 netlinux kernel: }
Dec  4 11:59:49 netlinux kernel: jffs_rewrite_data(): Writing name "sdd13" to pos 0x8858188l.
Dec  4 11:59:49 netlinux kernel: , result: 0x0000019f
Dec  4 11:59:49 netlinux kernel: jffs_read_data(): file = "sdd13", read_offset = 0, size = 2
Dec  4 11:59:49 netlinux kernel:   jffs_get_node_data(): file: "sdd13", ino: 623, version: 1, node_offset: 0
Dec  4 11:59:49 netlinux kernel:   jffs_get_node_data(): Read 2 bytes.
Dec  4 11:59:49 netlinux kernel:   jffs_read_data(): Read 2 bytes.
Dec  4 11:59:49 netlinux kernel: , result: 0x00000045
Dec  4 11:59:49 netlinux kernel: , result: 0x00000748
Dec  4 11:59:49 netlinux kernel: jffs_insert_node(): ino = 623, version = 2, name = "sdd13", deleted = 0
Dec  4 11:59:49 netlinux kernel: jffs_insert_node(): ---------------------------------------------------------------------- 1
Dec  4 11:59:49 netlinux kernel: jffs_update_file(): ino: 623, version: 2
Dec  4 11:59:49 netlinux kernel: jffs_delete_data(): offset = 0, remove_size = 2
Dec  4 11:59:49 netlinux kernel: jffs_delete_data(): Removing node: ino: 623, version: 1
Dec  4 11:59:49 netlinux kernel: jffs_fmfree(): node->ino = 623, node->version = 1
Dec  4 11:59:49 netlinux kernel: jffs_delete_data(): f->size = 0
Dec  4 11:59:49 netlinux kernel: jffs_insert_data(): node->data_offset = 0, node->data_size = 2, f->size = 0
Dec  4 11:59:49 netlinux kernel: jffs_insert_data(): f->size = 2
Dec  4 11:59:49 netlinux kernel: jffs_remove_redundant_nodes(): ino: 623, name: "sdd13", newest_type: 7
Dec  4 11:59:49 netlinux kernel: jffs_insert_node(): ---------------------------------------------------------------------- 2
Dec  4 11:59:49 netlinux kernel: jffs_rewrite_data(): Leaving...
Dec  4 11:59:49 netlinux kernel: jffs_garbage_collect_next: Leaving...
Dec  4 11:59:49 netlinux kernel: ***jffs_garbage_collect_thread(): round #658, fmc->dirty_size = 272880
Dec  4 11:59:49 netlinux kernel: struct jffs_fmcontrol: 0xc0818640
Dec  4 11:59:49 netlinux kernel: {
Dec  4 11:59:49 netlinux kernel:         0x00000000, /* flash_start  */
Dec  4 11:59:49 netlinux kernel:         15204352, /* flash_size  */
Dec  4 11:59:49 netlinux kernel:         7012456, /* used_size  */
Dec  4 11:59:49 netlinux kernel:         272880, /* dirty_size  */
Dec  4 11:59:49 netlinux kernel:         7919016, /* free_size  */
Dec  4 11:59:49 netlinux kernel:         131072, /* sector_size  */
Dec  4 11:59:49 netlinux kernel:         262144, /* min_free_size  */
Dec  4 11:59:49 netlinux kernel:         65536, /* max_chunk_size  */
Dec  4 11:59:49 netlinux kernel:         0xc0094980, /* mtd  */
Dec  4 11:59:49 netlinux kernel:         0xc0cad960, /* head  */    (head->offset = 0x00180000)
Dec  4 11:59:49 netlinux kernel:         0xc0d45d60, /* tail  */    (tail->offset + tail->size = 0x00872a58)
Dec  4 11:59:49 netlinux kernel:         0x00000000, /* head_extra  */
Dec  4 11:59:49 netlinux kernel:         0x00000000, /* tail_extra  */
Dec  4 11:59:49 netlinux kernel: }
Dec  4 11:59:49 netlinux kernel: jffs_try_to_erase()
Dec  4 11:59:49 netlinux kernel: jffs_try_to_erase(): erase_size = 0
Dec  4 11:59:49 netlinux kernel: jffs_get_oldest_node(): ino = 624, version = 1
Dec  4 11:59:49 netlinux kernel: jffs_find_file(): ino: 624
Dec  4 11:59:49 netlinux kernel: jffs_find_file(): Found file with ino 624. (name: "sdd14")
Dec  4 11:59:49 netlinux kernel: jffs_garbage_collect_next(): "sdd14", ino: 624, version: 1, location 0x19ffc0, dsize 2
Dec  4 11:59:54 netlinux kernel:   total_name_size: 8
Dec  4 11:59:54 netlinux kernel:   data_size: 2
Dec  4 11:59:54 netlinux kernel:   size: 72
Dec  4 11:59:54 netlinux kernel:   f->nsize: 5
Dec  4 11:59:54 netlinux kernel:   f->size: 2
Dec  4 11:59:54 netlinux kernel:   node->data_offset: 0
Dec  4 11:59:54 netlinux kernel:   free_chunk_size1: 6346152
Dec  4 11:59:54 netlinux kernel:   free_chunk_size2: 1572864
Dec  4 11:59:54 netlinux kernel:   node->fm->offset: 0x0019ffc0
Dec  4 11:59:54 netlinux kernel: ***jffs_rewrite_data(): node: 624, name: "sdd14", size: 2
Dec  4 11:59:54 netlinux kernel: jffs_fmalloc(): fmc = 0xc0818640, size = 72, node = 0xc0d7f460
Dec  4 11:59:54 netlinux kernel: jffs_fmalloc(): free_chunk_size1 = 6346152, free_chunk_size2 = 1572864
Dec  4 11:59:54 netlinux kernel: struct jffs_fmcontrol: 0xc0818640
Dec  4 11:59:54 netlinux kernel: {
Dec  4 11:59:54 netlinux kernel:         0x00000000, /* flash_start  */
Dec  4 11:59:54 netlinux kernel:         15204352, /* flash_size  */
Dec  4 11:59:54 netlinux kernel:         7012528, /* used_size  */
Dec  4 11:59:54 netlinux kernel:         272880, /* dirty_size  */
Dec  4 11:59:54 netlinux kernel:         7918944, /* free_size  */
Dec  4 11:59:54 netlinux kernel:         131072, /* sector_size  */
Dec  4 11:59:54 netlinux kernel:         262144, /* min_free_size  */
Dec  4 11:59:54 netlinux kernel:         65536, /* max_chunk_size  */
Dec  4 11:59:54 netlinux kernel:         0xc0094980, /* mtd  */
Dec  4 11:59:54 netlinux kernel:         0xc0cad960, /* head  */    (head->offset = 0x00180000)
Dec  4 11:59:54 netlinux kernel:         0xc0d45df0, /* tail  */    (tail->offset + tail->size = 0x00872aa0)
Dec  4 11:59:54 netlinux kernel:         0x00000000, /* head_extra  */
Dec  4 11:59:54 netlinux kernel:         0x00000000, /* tail_extra  */
Dec  4 11:59:54 netlinux kernel: }
Dec  4 11:59:54 netlinux kernel: struct jffs_fm: 0xc0d45df0
Dec  4 11:59:54 netlinux kernel: {
Dec  4 11:59:54 netlinux kernel:        0x00872a58, /* offset  */
Dec  4 11:59:54 netlinux kernel:        72, /* size  */
Dec  4 11:59:54 netlinux kernel:        0xc0d45d60, /* prev  */
Dec  4 11:59:54 netlinux kernel:        0x00000000, /* next  */
Dec  4 11:59:54 netlinux kernel:        0xc0d45e20, /* nodes  */
Dec  4 11:59:54 netlinux kernel: }
Dec  4 11:59:54 netlinux kernel: jffs_rewrite_data(): Writing this raw inode to pos 0x8858200l.
Dec  4 11:59:54 netlinux kernel: jffs_raw_inode: inode number: 624
Dec  4 11:59:54 netlinux kernel: {
Dec  4 11:59:54 netlinux kernel:         0x34383931, /* magic  */
Dec  4 11:59:54 netlinux kernel:         0x00000270, /* ino  */
Dec  4 11:59:54 netlinux kernel:         0x0000003b, /* pino  */
Dec  4 11:59:54 netlinux kernel:         0x00000002, /* version  */
Dec  4 11:59:54 netlinux kernel:         0x000061a0, /* mode  */
Dec  4 11:59:54 netlinux kernel:         0x0000,     /* uid  */
Dec  4 11:59:54 netlinux kernel:         0x0000,     /* gid  */
Dec  4 11:59:54 netlinux kernel:         0x3a01980b, /* atime  */
Dec  4 11:59:54 netlinux kernel:         0x39f812cf, /* mtime  */
Dec  4 11:59:54 netlinux kernel:         0x3a019811, /* ctime  */
Dec  4 11:59:54 netlinux kernel:         0x00000000, /* offset  */
Dec  4 11:59:54 netlinux kernel:         0x00000002, /* dsize  */
Dec  4 11:59:54 netlinux kernel:         0x00000002, /* rsize  */
Dec  4 11:59:54 netlinux kernel:         0x05,       /* nsize  */
Dec  4 11:59:54 netlinux kernel:         0x01,       /* nlink  */
Dec  4 11:59:54 netlinux kernel:         0x00,       /* spare  */
Dec  4 11:59:54 netlinux kernel:         0,          /* rename  */
Dec  4 11:59:54 netlinux kernel:         0,          /* deleted  */
Dec  4 11:59:54 netlinux kernel:         0xff,       /* accurate  */
Dec  4 11:59:54 netlinux kernel:         0x00000000, /* dchksum  */
Dec  4 11:59:58 netlinux kernel:         0x0000,     /* nchksum  */
Dec  4 11:59:58 netlinux kernel:         0x0000,     /* chksum  */
Dec  4 11:59:58 netlinux kernel: }
Dec  4 11:59:58 netlinux kernel: jffs_rewrite_data(): Writing name "sdd14" to pos 0x8858260l.
Dec  4 11:59:58 netlinux kernel: , result: 0x000001a0
Dec  4 11:59:58 netlinux kernel: jffs_read_data(): file = "sdd14", read_offset = 0, size = 2
Dec  4 11:59:58 netlinux kernel:   jffs_get_node_data(): file: "sdd14", ino: 624, version: 1, node_offset: 0
Dec  4 11:59:58 netlinux kernel:   jffs_get_node_data(): Read 2 bytes.
Dec  4 11:59:58 netlinux kernel:   jffs_read_data(): Read 2 bytes.
Dec  4 11:59:58 netlinux kernel: , result: 0x00000046
Dec  4 11:59:58 netlinux kernel: , result: 0x0000074b
Dec  4 11:59:58 netlinux kernel: jffs_insert_node(): ino = 624, version = 2, name = "sdd14", deleted = 0
Dec  4 11:59:58 netlinux kernel: jffs_insert_node(): ---------------------------------------------------------------------- 1
Dec  4 11:59:58 netlinux kernel: jffs_update_file(): ino: 624, version: 2
Dec  4 11:59:58 netlinux kernel: jffs_delete_data(): offset = 0, remove_size = 2
Dec  4 11:59:58 netlinux kernel: jffs_delete_data(): Removing node: ino: 624, version: 1
Dec  4 11:59:58 netlinux kernel: jffs_fmfree(): node->ino = 624, node->version = 1
Dec  4 11:59:58 netlinux kernel: jffs_delete_data(): f->size = 0
Dec  4 11:59:58 netlinux kernel: jffs_insert_data(): node->data_offset = 0, node->data_size = 2, f->size = 0
Dec  4 11:59:58 netlinux kernel: jffs_insert_data(): f->size = 2
Dec  4 11:59:58 netlinux kernel: jffs_remove_redundant_nodes(): ino: 624, name: "sdd14", newest_type: 7
Dec  4 11:59:58 netlinux kernel: jffs_insert_node(): ---------------------------------------------------------------------- 2
Dec  4 11:59:58 netlinux kernel: jffs_rewrite_data(): Leaving...
Dec  4 11:59:58 netlinux kernel: jffs_garbage_collect_next: Leaving...
Dec  4 11:59:58 netlinux kernel: ***jffs_garbage_collect_thread(): round #659, fmc->dirty_size = 272952
Dec  4 11:59:58 netlinux kernel: struct jffs_fmcontrol: 0xc0818640
Dec  4 11:59:58 netlinux kernel: {
Dec  4 11:59:58 netlinux kernel:         0x00000000, /* flash_start  */
Dec  4 11:59:58 netlinux kernel:         15204352, /* flash_size  */
Dec  4 11:59:58 netlinux kernel:         7012456, /* used_size  */
Dec  4 11:59:58 netlinux kernel:         272952, /* dirty_size  */
Dec  4 11:59:58 netlinux kernel:         7918944, /* free_size  */
Dec  4 11:59:58 netlinux kernel:         131072, /* sector_size  */
Dec  4 11:59:58 netlinux kernel:         262144, /* min_free_size  */
Dec  4 11:59:58 netlinux kernel:         65536, /* max_chunk_size  */
Dec  4 11:59:58 netlinux kernel:         0xc0094980, /* mtd  */
Dec  4 11:59:58 netlinux kernel:         0xc0cad960, /* head  */    (head->offset = 0x00180000)
Dec  4 11:59:58 netlinux kernel:         0xc0d45df0, /* tail  */    (tail->offset + tail->size = 0x00872aa0)
Dec  4 11:59:58 netlinux kernel:         0x00000000, /* head_extra  */
Dec  4 11:59:58 netlinux kernel:         0x00000000, /* tail_extra  */
Dec  4 11:59:58 netlinux kernel: }
Dec  4 11:59:58 netlinux kernel: jffs_try_to_erase()
Dec  4 11:59:58 netlinux kernel: jffs_try_to_erase(): erase_size = 131072
Dec  4 12:00:03 netlinux kernel: ***jffs_garbage_collect_thread(): round #1313, fmc->dirty_size = 168700
Dec  4 12:00:03 netlinux kernel: struct jffs_fmcontrol: 0xc0818640
Dec  4 12:00:03 netlinux kernel: {
Dec  4 12:00:03 netlinux kernel:         0x00000000, /* flash_start  */
Dec  4 12:00:03 netlinux kernel:         15204352, /* flash_size  */
Dec  4 12:00:03 netlinux kernel:         7043320, /* used_size  */
Dec  4 12:00:03 netlinux kernel:         168700, /* dirty_size  */
Dec  4 12:00:03 netlinux kernel:         7992332, /* free_size  */
Dec  4 12:00:03 netlinux kernel:         131072, /* sector_size  */
Dec  4 12:00:03 netlinux kernel:         262144, /* min_free_size  */
Dec  4 12:00:03 netlinux kernel:         65536, /* max_chunk_size  */
Dec  4 12:00:03 netlinux kernel:         0xc0094980, /* mtd  */
Dec  4 12:00:03 netlinux kernel:         0xc0e351c0, /* head  */    (head->offset = 0x00320000)
Dec  4 12:00:03 netlinux kernel:         0xc0e35100, /* tail  */    (tail->offset + tail->size = 0x00a00bf4)
Dec  4 12:00:03 netlinux kernel:         0x00000000, /* head_extra  */
Dec  4 12:00:03 netlinux kernel:         0x00000000, /* tail_extra  */
Dec  4 12:00:03 netlinux kernel: }
Dec  4 12:00:03 netlinux kernel: jffs_try_to_erase()
Dec  4 12:00:03 netlinux kernel: jffs_try_to_erase(): erase_size = 0
Dec  4 12:00:03 netlinux kernel: jffs_get_oldest_node(): ino = 1247, version = 8
Dec  4 12:00:03 netlinux kernel: jffs_find_file(): ino: 1247
Dec  4 12:00:03 netlinux kernel: jffs_find_file(): Found file with ino 1247. (name: "vmlinuz.wrks")
Dec  4 12:00:03 netlinux kernel: jffs_garbage_collect_next(): "vmlinuz.wrks", ino: 1247, version: 8, location 0x3268cc, dsize 288
Dec  4 12:00:03 netlinux kernel:   total_name_size: 12
Dec  4 12:00:03 netlinux kernel:   data_size: 65464
Dec  4 12:00:03 netlinux kernel:   size: 65536
Dec  4 12:00:03 netlinux kernel:   f->nsize: 12
Dec  4 12:00:03 netlinux kernel:   f->size: 494731
Dec  4 12:00:03 netlinux kernel:   node->data_offset: 261856
Dec  4 12:00:03 netlinux kernel:   free_chunk_size1: 4715532
Dec  4 12:00:03 netlinux kernel:   free_chunk_size2: 3276800
Dec  4 12:00:03 netlinux kernel:   node->fm->offset: 0x003268cc
Dec  4 12:00:03 netlinux kernel: ***jffs_rewrite_data(): node: 1247, name: "vmlinuz.wrks", size: 65464
Dec  4 12:00:03 netlinux kernel: jffs_fmalloc(): fmc = 0xc0818640, size = 65536, node = 0xc0e3f890
Dec  4 12:00:03 netlinux kernel: jffs_fmalloc(): free_chunk_size1 = 4715532, free_chunk_size2 = 3276800
Dec  4 12:00:03 netlinux kernel: struct jffs_fmcontrol: 0xc0818640
Dec  4 12:00:03 netlinux kernel: {
Dec  4 12:00:03 netlinux kernel:         0x00000000, /* flash_start  */
Dec  4 12:00:03 netlinux kernel:         15204352, /* flash_size  */
Dec  4 12:00:03 netlinux kernel:         7108856, /* used_size  */
Dec  4 12:00:03 netlinux kernel:         168700, /* dirty_size  */
Dec  4 12:00:03 netlinux kernel:         7926796, /* free_size  */
Dec  4 12:00:03 netlinux kernel:         131072, /* sector_size  */
Dec  4 12:00:03 netlinux kernel:         262144, /* min_free_size  */
Dec  4 12:00:04 netlinux kernel:         65536, /* max_chunk_size  */
Dec  4 12:00:04 netlinux kernel:         0xc0094980, /* mtd  */
Dec  4 12:00:04 netlinux kernel:         0xc0e351c0, /* head  */    (head->offset = 0x00320000)
Dec  4 12:00:04 netlinux kernel:         0xc0e35160, /* tail  */    (tail->offset + tail->size = 0x00a10bf4)
Dec  4 12:00:04 netlinux kernel:         0x00000000, /* head_extra  */
Dec  4 12:00:04 netlinux kernel:         0x00000000, /* tail_extra  */
Dec  4 12:00:04 netlinux kernel: }
Dec  4 12:00:04 netlinux kernel: struct jffs_fm: 0xc0e35160
Dec  4 12:00:04 netlinux kernel: {
Dec  4 12:00:04 netlinux kernel:        0x00a00bf4, /* offset  */
Dec  4 12:00:04 netlinux kernel:        65536, /* size  */
Dec  4 12:00:04 netlinux kernel:        0xc0e35100, /* prev  */
Dec  4 12:00:04 netlinux kernel:        0x00000000, /* next  */
Dec  4 12:00:04 netlinux kernel:        0xc0e35040, /* nodes  */
Dec  4 12:00:04 netlinux kernel: }
Dec  4 12:00:04 netlinux kernel: jffs_rewrite_data(): Writing this raw inode to pos 0x10488820l.
Dec  4 12:00:04 netlinux kernel: jffs_raw_inode: inode number: 1247
Dec  4 12:00:04 netlinux kernel: {
Dec  4 12:00:04 netlinux kernel:         0x34383931, /* magic  */
Dec  4 12:00:04 netlinux kernel:         0x000004df, /* ino  */
Dec  4 12:00:04 netlinux kernel:         0x000004de, /* pino  */
Dec  4 12:00:04 netlinux kernel:         0x00000015, /* version  */
Dec  4 12:00:04 netlinux kernel:         0x000081a4, /* mode  */
Dec  4 12:00:04 netlinux kernel:         0x0000,     /* uid  */
Dec  4 12:00:04 netlinux kernel:         0x0000,     /* gid  */
Dec  4 12:00:04 netlinux kernel:         0x3a27f64a, /* atime  */
Dec  4 12:00:04 netlinux kernel:         0x3a01b73a, /* mtime  */
Dec  4 12:00:08 netlinux kernel:         0x3a01b73a, /* ctime  */
Dec  4 12:00:08 netlinux kernel:         0x0003fee0, /* offset  */
Dec  4 12:00:08 netlinux kernel:         0x0000ffb8, /* dsize  */
Dec  4 12:00:08 netlinux kernel:         0x0000ffb8, /* rsize  */
Dec  4 12:00:08 netlinux kernel:         0x0c,       /* nsize  */
Dec  4 12:00:08 netlinux kernel:         0x01,       /* nlink  */
Dec  4 12:00:08 netlinux kernel:         0x00,       /* spare  */
Dec  4 12:00:08 netlinux kernel:         0,          /* rename  */
Dec  4 12:00:08 netlinux kernel:         0,          /* deleted  */
Dec  4 12:00:08 netlinux kernel:         0xff,       /* accurate  */
Dec  4 12:00:08 netlinux kernel:         0x00000000, /* dchksum  */
Dec  4 12:00:08 netlinux kernel:         0x0000,     /* nchksum  */
Dec  4 12:00:08 netlinux kernel:         0x0000,     /* chksum  */
Dec  4 12:00:08 netlinux kernel: }
Dec  4 12:00:08 netlinux kernel: jffs_rewrite_data(): Writing name "vmlinuz.wrks" to pos 0x10488880l.
Dec  4 12:00:08 netlinux kernel: , result: 0x0000050a
Dec  4 12:00:08 netlinux kernel: jffs_read_data(): file = "vmlinuz.wrks", read_offset = 261856, size = 4096
Dec  4 12:00:08 netlinux kernel:   jffs_get_node_data(): file: "vmlinuz.wrks", ino: 1247, version: 8, node_offset: 0
Dec  4 12:00:08 netlinux kernel:   jffs_get_node_data(): Read 288 bytes.
Dec  4 12:00:08 netlinux kernel:   jffs_get_node_data(): file: "vmlinuz.wrks", ino: 1247, version: 9, node_offset: 0
Dec  4 12:00:08 netlinux kernel:   jffs_get_node_data(): Read 3808 bytes.
Dec  4 12:00:08 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:00:08 netlinux kernel: , result: 0x00081d71
Dec  4 12:00:08 netlinux kernel: jffs_read_data(): file = "vmlinuz.wrks", read_offset = 265952, size = 4096
Dec  4 12:00:08 netlinux kernel:   jffs_get_node_data(): file: "vmlinuz.wrks", ino: 1247, version: 9, node_offset: 3808
Dec  4 12:00:08 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 12:00:08 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:00:08 netlinux kernel: , result: 0x00080a38
Dec  4 12:00:08 netlinux kernel: jffs_read_data(): file = "vmlinuz.wrks", read_offset = 270048, size = 4096
Dec  4 12:00:08 netlinux kernel:   jffs_get_node_data(): file: "vmlinuz.wrks", ino: 1247, version: 9, node_offset: 7904
Dec  4 12:00:08 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 12:00:08 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:00:08 netlinux kernel: , result: 0x00081374
Dec  4 12:00:08 netlinux kernel: jffs_read_data(): file = "vmlinuz.wrks", read_offset = 274144, size = 4096
Dec  4 12:00:08 netlinux kernel:   jffs_get_node_data(): file: "vmlinuz.wrks", ino: 1247, version: 9, node_offset: 12000
Dec  4 12:00:08 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 12:00:08 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:00:08 netlinux kernel: , result: 0x00081602
Dec  4 12:00:08 netlinux kernel: jffs_read_data(): file = "vmlinuz.wrks", read_offset = 278240, size = 4096
Dec  4 12:00:08 netlinux kernel:   jffs_get_node_data(): file: "vmlinuz.Dec  4 12:00:08 netlinux kernel:   jffs_get_node_data(): Rea
d 4096 bytes.
Dec  4 12:00:08 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:00:08 netlinux kernel: , result: 0x000821a8
Dec  4 12:00:08 netlinux kernel: jffs_read_data(): file = "vmlinuz.wrks", read_offset = 282336, size = 4096
Dec  4 12:00:08 netlinux kernel:   jffs_get_node_data(): file: "vmlinuz.wrks", ino: 1247, version: 9, node_offset: 20192
Dec  4 12:00:08 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 12:00:11 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:00:11 netlinux kernel: , result: 0x00081d2d
Dec  4 12:00:11 netlinux kernel: jffs_read_data(): file = "vmlinuz.wrks", read_offset = 286432, size = 4096
Dec  4 12:00:11 netlinux kernel:   jffs_get_node_data(): file: "vmlinuz.wrks", ino: 1247, version: 9, node_offset: 24288
Dec  4 12:00:11 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 12:00:11 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:00:11 netlinux kernel: , result: 0x0008178e
Dec  4 12:00:11 netlinux kernel: jffs_read_data(): file = "vmlinuz.wrks", read_offset = 290528, size = 4096
Dec  4 12:00:11 netlinux kernel:   jffs_get_node_data(): file: "vmlinuz.wrks", ino: 1247, version: 9, node_offset: 28384
Dec  4 12:00:11 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 12:00:11 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:00:11 netlinux kernel: , result: 0x00081751
Dec  4 12:00:11 netlinux kernel: jffs_read_data(): file = "vmlinuz.wrks", read_offset = 294624, size = 4096
Dec  4 12:00:11 netlinux kernel:   jffs_get_node_data(): file: "vmlinuz.wrks", ino: 1247, version: 9, node_offset: 32480
Dec  4 12:00:11 netlinux kernel:   jffs_get_node_data(): Read 288 bytes.
Dec  4 12:00:11 netlinux kernel:   jffs_get_node_data(): file: "vmlinuz.wrks", ino: 1247, version: 10, node_offset: 0
Dec  4 12:00:11 netlinux kernel:   jffs_get_node_data(): Read 3808 bytes.
Dec  4 12:00:11 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:00:11 netlinux kernel: , result: 0x00086001
Dec  4 12:00:11 netlinux kernel: jffs_read_data(): file = "vmlinuz.wrks", read_offset = 298720, size = 4096
Dec  4 12:00:11 netlinux kernel:   jffs_get_node_data(): file: "vmlinuz.wrks", ino: 1247, version: 10, node_offset: 3808
Dec  4 12:00:11 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 12:00:11 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:00:11 netlinux kernel: , result: 0x000814fc
Dec  4 12:00:11 netlinux kernel: jffs_read_data(): file = "vmlinuz.wrks", read_offset = 302816, size = 4096
Dec  4 12:00:11 netlinux kernel:   jffs_get_node_data(): file: "vmlinuz.wrks", ino: 1247, version: 10, node_offset: 7904
Dec  4 12:00:11 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 12:00:11 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:00:11 netlinux kernel: , result: 0x00081658
Dec  4 12:00:11 netlinux kernel: jffs_read_data(): file = "vmlinuz.wrks", read_offset = 306912, size = 4096
Dec  4 12:00:11 netlinux kernel:   jffs_get_node_data(): file: "vmlinuz.wrks", ino: 1247, version: 10, node_offset: 12000
Dec  4 12:00:11 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 12:00:15 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:00:15 netlinux kernel: , result: 0x000832f6
Dec  4 12:00:15 netlinux kernel: jffs_read_data(): file = "vmlinuz.wrks", read_offset = 311008, size = 4096
Dec  4 12:00:15 netlinux kernel:   jffs_get_node_data(): file: "vmlinuz.wrks", ino: 1247, version: 10, node_offset: 16096
Dec  4 12:00:15 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 12:00:15 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:00:15 netlinux kernel: , result: 0x0008350e
Dec  4 12:00:15 netlinux kernel: jffs_read_data(): file = "vmlinuz.wrks", read_offset = 315104, size = 4096
Dec  4 12:00:15 netlinux kernel:   jffs_get_node_data(): file: "vmlinuz.wrks", ino: 1247, version: 10, node_offset: 20192
Dec  4 12:00:15 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 12:00:15 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:00:15 netlinux kernel: , result: 0x00085d47
Dec  4 12:00:15 netlinux kernel: jffs_read_data(): file = "vmlinuz.wrks", read_offset = 319200, size = 4096
Dec  4 12:00:15 netlinux kernel:   jffs_get_node_data(): file: "vmlinuz.wrks", ino: 1247, version: 10, node_offset: 24288
Dec  4 12:00:15 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 12:00:15 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:00:15 netlinux kernel: , result: 0x000818b9
Dec  4 12:00:15 netlinux kernel: jffs_read_data(): file = "vmlinuz.wrks", read_offset = 323296, size = 4024
Dec  4 12:00:15 netlinux kernel:   jffs_get_node_data(): file: "vmlinuz.wrks", ino: 1247, version: 10, node_offset: 28384
Dec  4 12:00:15 netlinux kernel:   jffs_get_node_data(): Read 4024 bytes.
Dec  4 12:00:15 netlinux kernel:   jffs_read_data(): Read 4024 bytes.
Dec  4 12:00:15 netlinux kernel: , result: 0x0007c858
Dec  4 12:00:15 netlinux kernel: , result: 0x00000f2e
Dec  4 12:00:15 netlinux kernel: jffs_insert_node(): ino = 1247, version = 21, name = "vmlinuz.wrks", deleted = 0
Dec  4 12:00:15 netlinux kernel: jffs_insert_node(): ---------------------------------------------------------------------- 1
Dec  4 12:00:15 netlinux kernel: jffs_update_file(): ino: 1247, version: 21
Dec  4 12:00:15 netlinux kernel: jffs_delete_data(): offset = 261856, remove_size = 65464
Dec  4 12:00:15 netlinux kernel: jffs_delete_data(): Removing node: ino: 1247, version: 8
Dec  4 12:00:15 netlinux kernel: jffs_fmfree(): node->ino = 1247, node->version = 8
Dec  4 12:00:15 netlinux kernel: jffs_delete_data(): Removing node: ino: 1247, version: 9
Dec  4 12:00:15 netlinux kernel: jffs_fmfree(): node->ino = 1247, node->version = 9
Dec  4 12:00:15 netlinux kernel: jffs_delete_data(): f->size = 429267
Dec  4 12:00:15 netlinux kernel: jffs_insert_data(): node->data_offset = 261856, node->data_size = 65464, f->size = 429267
Dec  4 12:00:15 netlinux kernel: Cool stuff's happening!
Dec  4 12:00:15 netlinux last message repeated 4 times
Dec  4 12:00:15 netlinux kernel: jffs_insert_data(): f->size = 494731
Dec  4 12:00:15 netlinux kernel: jffs_remove_redundant_nodes(): ino: 1247, name: "vmlinuz.wrks", newest_type: 7
Dec  4 12:00:15 netlinux kernel: jffs_insert_node(): ---------------------------------------------------------------------- 2
Dec  4 12:00:15 netlinux kernel: jffs_rewrite_data(): Leaving...
Dec  4 12:00:15 netlinux kernel: jffs_garbage_collect_next: Leaving...
Dec  4 12:00:15 netlinux kernel:         0x0c,       /* nsize  */
Dec  4 12:00:15 netlinux kernel:         0x01,       /* nlink  */
Dec  4 12:00:15 netlinux kernel:         0x00,       /* spare  */
Dec  4 12:00:15 netlinux kernel:         0,          /* rename  */
Dec  4 12:00:15 netlinux kernel:         0,          /* deleted  */
Dec  4 12:00:15 netlinux kernel:         0xff,       /* accurate  */
Dec  4 12:00:15 netlinux kernel:         0x00000000, /* dchksum  */
Dec  4 12:00:15 netlinux kernel:         0x0000,     /* nchksum  */
Dec  4 12:00:15 netlinux kernel:         0x0000,     /* chksum  */
Dec  4 12:00:15 netlinux kernel: }
Dec  4 12:00:15 netlinux kernel: jffs_rewrite_data(): Writing name "vmlinuz.wrks" to pos 0x11181032l.
Dec  4 12:00:19 netlinux kernel: , result: 0x0000050a
Dec  4 12:00:19 netlinux kernel: jffs_read_data(): file = "vmlinuz.wrks", read_offset = 458248, size = 4096
Dec  4 12:00:19 netlinux kernel:   jffs_get_node_data(): file: "vmlinuz.wrks", ino: 1250, version: 14, node_offset: 0
Dec  4 12:00:19 netlinux kernel:   jffs_get_node_data(): Read 504 bytes.
Dec  4 12:00:19 netlinux kernel:   jffs_get_node_data(): file: "vmlinuz.wrks", ino: 1250, version: 15, node_offset: 0
Dec  4 12:00:19 netlinux kernel:   jffs_get_node_data(): Read 3592 bytes.
Dec  4 12:00:19 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:00:19 netlinux kernel: , result: 0x0008bff4
Dec  4 12:00:19 netlinux kernel: jffs_read_data(): file = "vmlinuz.wrks", read_offset = 462344, size = 4096
Dec  4 12:00:19 netlinux kernel:   jffs_get_node_data(): file: "vmlinuz.wrks", ino: 1250, version: 15, node_offset: 3592
Dec  4 12:00:19 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 12:00:19 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:00:19 netlinux kernel: , result: 0x00088356
Dec  4 12:00:19 netlinux kernel: jffs_read_data(): file = "vmlinuz.wrks", read_offset = 466440, size = 4096
Dec  4 12:00:19 netlinux kernel:   jffs_get_node_data(): file: "vmlinuz.wrks", ino: 1250, version: 15, node_offset: 7688
Dec  4 12:00:19 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 12:00:19 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:00:19 netlinux kernel: , result: 0x00084f1f
Dec  4 12:00:19 netlinux kernel: jffs_read_data(): file = "vmlinuz.wrks", read_offset = 470536, size = 4096
Dec  4 12:00:19 netlinux kernel:   jffs_get_node_data(): file: "vmlinuz.wrks", ino: 1250, version: 15, node_offset: 11784
Dec  4 12:00:19 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 12:00:19 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:00:19 netlinux kernel: , result: 0x0007ee81
Dec  4 12:00:19 netlinux kernel: jffs_read_data(): file = "vmlinuz.wrks", read_offset = 474632, size = 4096
Dec  4 12:00:19 netlinux kernel:   jffs_get_node_data(): file: "vmlinuz.wrks", ino: 1250, version: 15, node_offset: 15880
Dec  4 12:00:19 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 12:00:19 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:00:19 netlinux kernel: , result: 0x00082568
Dec  4 12:00:19 netlinux kernel: jffs_read_data(): file = "vmlinuz.wrks", read_offset = 478728, size = 4096
Dec  4 12:00:19 netlinux kernel:   jffs_get_node_data(): file: "vmlinuz.wrks", ino: 1250, version: 15, node_offset: 19976
Dec  4 12:00:19 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 12:00:19 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:00:19 netlinux kernel: , result: 0x00082643
Dec  4 12:00:19 netlinux kernel: jffs_read_data(): file = "vmlinuz.wrks", read_offset = 482824, size = 4096
Dec  4 12:00:19 netlinux kernel:   jffs_get_node_data(): file: "vmlinuz.wrks", ino: 1250, version: 15, node_offset: 24072
Dec  4 12:00:19 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 12:00:19 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:00:19 netlinux kernel: , result: 0x0008526e
Dec  4 12:00:19 netlinux kernel: jffs_read_data(): file = "vmlinuz.wrks", read_offset = 486920, size = 4096
Dec  4 12:00:19 netlinux kernel:   jffs_get_node_data(): file: "vmlinuz.wrks", ino: 1250, version: 15, node_offset: 28168
Dec  4 12:00:19 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 12:00:19 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:00:19 netlinux kernel: , result: 0x0008237c
Dec  4 12:00:19 netlinux kernel: jffs_read_data(): file = "vmlinuz.wrks", read_offset = 491016, size = 3715
Dec  4 12:00:19 netlinux kernel:   jffs_get_node_data(): file: "vmlinuz.wrks", ino: 1250, version: 15, node_offset: 32264
Dec  4 12:00:19 netlinux kernel:   jffs_get_node_data(): Read 504 bytes.
Dec  4 12:00:23 netlinux kernel:   jffs_get_node_data(): file: "vmlinuz.wrks", ino: 1250, version: 16, node_offset: 0
Dec  4 12:00:23 netlinux kernel:   jffs_get_node_data(): Read 3211 bytes.
Dec  4 12:00:23 netlinux kernel:   jffs_read_data(): Read 3715 bytes.
Dec  4 12:00:23 netlinux kernel: , result: 0x0007a59d
Dec  4 12:00:23 netlinux kernel: , result: 0x00000c87
Dec  4 12:00:23 netlinux kernel: jffs_insert_node(): ino = 1250, version = 24, name = "vmlinuz.wrks", deleted = 0
Dec  4 12:00:23 netlinux kernel: jffs_insert_node(): ---------------------------------------------------------------------- 1
Dec  4 12:00:23 netlinux kernel: jffs_update_file(): ino: 1250, version: 24
Dec  4 12:00:23 netlinux kernel: jffs_delete_data(): offset = 458248, remove_size = 36483
Dec  4 12:00:23 netlinux kernel: jffs_delete_data(): Removing node: ino: 1250, version: 14
Dec  4 12:00:23 netlinux kernel: jffs_fmfree(): node->ino = 1250, node->version = 14
Dec  4 12:00:23 netlinux kernel: jffs_delete_data(): Removing node: ino: 1250, version: 15
Dec  4 12:00:23 netlinux kernel: jffs_fmfree(): node->ino = 1250, node->version = 15
Dec  4 12:00:23 netlinux kernel: jffs_delete_data(): Removing node: ino: 1250, version: 16
Dec  4 12:00:23 netlinux kernel: jffs_fmfree(): node->ino = 1250, node->version = 16
Dec  4 12:00:23 netlinux kernel: jffs_delete_data(): f->size = 458248
Dec  4 12:00:23 netlinux kernel: jffs_insert_data(): node->data_offset = 458248, node->data_size = 36483, f->size = 458248
Dec  4 12:00:23 netlinux kernel: jffs_insert_data(): f->size = 494731
Dec  4 12:00:23 netlinux kernel: jffs_remove_redundant_nodes(): ino: 1250, name: "vmlinuz.wrks", newest_type: 7
Dec  4 12:00:23 netlinux kernel: jffs_insert_node(): ---------------------------------------------------------------------- 2
Dec  4 12:00:23 netlinux kernel: jffs_rewrite_data(): Leaving...
Dec  4 12:00:23 netlinux kernel: jffs_garbage_collect_next: Leaving...
Dec  4 12:00:23 netlinux kernel: ***jffs_garbage_collect_thread(): round #1332, fmc->dirty_size = 275464
Dec  4 12:00:23 netlinux kernel: struct jffs_fmcontrol: 0xc0818640
Dec  4 12:00:23 netlinux kernel: {
Dec  4 12:00:23 netlinux kernel:         0x00000000, /* flash_start  */
Dec  4 12:00:23 netlinux kernel:         15204352, /* flash_size  */
Dec  4 12:00:23 netlinux kernel:         7009904, /* used_size  */
Dec  4 12:00:23 netlinux kernel:         275464, /* dirty_size  */
Dec  4 12:00:23 netlinux kernel:         7918984, /* free_size  */
Dec  4 12:00:23 netlinux kernel:         131072, /* sector_size  */
Dec  4 12:00:23 netlinux kernel:         262144, /* min_free_size  */
Dec  4 12:00:23 netlinux kernel:         65536, /* max_chunk_size  */
Dec  4 12:00:23 netlinux kernel:         0xc0094980, /* mtd  */
Dec  4 12:00:23 netlinux kernel:         0xc0e35af0, /* head  */    (head->offset = 0x003c0000)
Dec  4 12:00:23 netlinux kernel:         0xc0e35b50, /* tail  */    (tail->offset + tail->size = 0x00ab2a78)
Dec  4 12:00:23 netlinux kernel:         0x00000000, /* head_extra  */
Dec  4 12:00:23 netlinux kernel:         0x00000000, /* tail_extra  */
Dec  4 12:00:23 netlinux kernel: }
Dec  4 12:00:23 netlinux kernel: jffs_try_to_erase()
Dec  4 12:00:23 netlinux kernel: jffs_try_to_erase(): erase_size = 131072
Dec  4 12:00:28 netlinux kernel: ***jffs_garbage_collect_thread(): round #1359, fmc->dirty_size = 150164
Dec  4 12:00:28 netlinux kernel: struct jffs_fmcontrol: 0xc0818640
Dec  4 12:00:28 netlinux kernel: {
Dec  4 12:00:28 netlinux kernel:         0x00000000, /* flash_start  */
Dec  4 12:00:28 netlinux kernel:         15204352, /* flash_size  */
Dec  4 12:00:28 netlinux kernel:         7041160, /* used_size  */
Dec  4 12:00:28 netlinux kernel:         150164, /* dirty_size  */
Dec  4 12:00:28 netlinux kernel:         8013028, /* free_size  */
Dec  4 12:00:28 netlinux kernel:         131072, /* sector_size  */
Dec  4 12:00:28 netlinux kernel:         262144, /* min_free_size  */
Dec  4 12:00:28 netlinux kernel:         65536, /* max_chunk_size  */
Dec  4 12:00:28 netlinux kernel:         0xc0094980, /* mtd  */
Dec  4 12:00:28 netlinux kernel:         0xc0e30a20, /* head  */    (head->offset = 0x004c0000)
Dec  4 12:00:28 netlinux kernel:         0xc0e30960, /* tail  */    (tail->offset + tail->size = 0x00b9bb1c)
Dec  4 12:00:28 netlinux kernel:         0x00000000, /* head_extra  */
Dec  4 12:00:28 netlinux kernel:         0x00000000, /* tail_extra  */
Dec  4 12:00:28 netlinux kernel: }
Dec  4 12:00:28 netlinux kernel: jffs_try_to_erase()
Dec  4 12:00:28 netlinux kernel: jffs_try_to_erase(): erase_size = 0
Dec  4 12:00:28 netlinux kernel: jffs_get_oldest_node(): ino = 1256, version = 14
Dec  4 12:00:28 netlinux kernel: jffs_find_file(): ino: 1256
Dec  4 12:00:28 netlinux kernel: jffs_find_file(): Found file with ino 1256. (name: "vmlinuz.wrks")
Dec  4 12:00:28 netlinux kernel: jffs_garbage_collect_next(): "vmlinuz.wrks", ino: 1256, version: 14, location 0x4c2064, dsize 504
Dec  4 12:00:28 netlinux kernel:   total_name_size: 12
Dec  4 12:00:28 netlinux kernel:   data_size: 36483
Dec  4 12:00:28 netlinux kernel:   size: 36556
Dec  4 12:00:28 netlinux kernel:   f->nsize: 12
Dec  4 12:00:28 netlinux kernel:   f->size: 494731
Dec  4 12:00:28 netlinux kernel:   node->data_offset: 458248
Dec  4 12:00:28 netlinux kernel:   free_chunk_size1: 3032292
Dec  4 12:00:28 netlinux kernel:   free_chunk_size2: 4980736
Dec  4 12:00:28 netlinux kernel:   node->fm->offset: 0x004c2064
Dec  4 12:00:28 netlinux kernel: ***jffs_rewrite_data(): node: 1256, name: "vmlinuz.wrks", size: 36483
Dec  4 12:00:28 netlinux kernel: jffs_fmalloc(): fmc = 0xc0818640, size = 36556, node = 0xc0e33ba0
Dec  4 12:00:28 netlinux kernel: jffs_fmalloc(): free_chunk_size1 = 3032292, free_chunk_size2 = 4980736
Dec  4 12:00:28 netlinux kernel: struct jffs_fmcontrol: 0xc0818640
Dec  4 12:00:28 netlinux kernel: {
Dec  4 12:00:28 netlinux kernel:         0x00000000, /* flash_start  */
Dec  4 12:00:28 netlinux kernel:         15204352, /* flash_size  */
Dec  4 12:00:28 netlinux kernel:         7077716, /* used_size  */
Dec  4 12:00:28 netlinux kernel:         150164, /* dirty_size  */
Dec  4 12:00:28 netlinux kernel:         7976472, /* free_size  */
Dec  4 12:00:28 netlinux kernel:         131072, /* sector_size  */
Dec  4 12:00:28 netlinux kernel:         262144, /* min_free_size  */
Dec  4 12:00:28 netlinux kernel:         65536, /* max_chunk_size  */
Dec  4 12:00:28 netlinux kernel:         0xc0094980, /* mtd  */
Dec  4 12:00:28 netlinux kernel:         0xc0e30a20, /* head  */    (head->offset = 0x004c0000)
Dec  4 12:00:28 netlinux kernel:         0xc0e309c0, /* tail  */    (tail->offset + tail->size = 0x00ba49e8)
Dec  4 12:00:28 netlinux kernel:         0x00000000, /* head_extra  */
Dec  4 12:00:28 netlinux kernel:         0x00000000, /* tail_extra  */
Dec  4 12:00:28 netlinux kernel: }
Dec  4 12:00:28 netlinux kernel: struct jffs_fm: 0xc0e309c0
Dec  4 12:00:28 netlinux kernel: {
Dec  4 12:00:28 netlinux kernel:        0x00b9bb1c, /* offset  */
Dec  4 12:00:28 netlinux kernel:        36556, /* size  */
Dec  4 12:00:28 netlinux kernel:        0xc0e30960, /* prev  */
Dec  4 12:00:28 netlinux kernel:        0x00000000, /* next  */
Dec  4 12:00:28 netlinux kernel:        0xc0e308a0, /* nodes  */
Dec  4 12:00:28 netlinux kernel: }
Dec  4 12:00:28 netlinux kernel: jffs_rewrite_data(): Writing this raw inode to pos 0x12172060l.
Dec  4 12:00:28 netlinux kernel: jffs_raw_inode: inode number: 1256
Dec  4 12:00:28 netlinux kernel: {
Dec  4 12:00:28 netlinux kernel:         0x34383931, /* magic  */
Dec  4 12:00:28 netlinux kernel:         0x000004e8, /* ino  */
Dec  4 12:00:28 netlinux kernel:         0x000004e7, /* pino  */
Dec  4 12:00:28 netlinux kernel:         0x00000018, /* version  */
Dec  4 12:00:28 netlinux kernel:         0x000081a4, /* mode  */
Dec  4 12:00:28 netlinux kernel:         0x0000,     /* uid  */
Dec  4 12:00:28 netlinux kernel:         0x0000,     /* gid  */
Dec  4 12:00:28 netlinux kernel:         0x3a27f64c, /* atime  */
Dec  4 12:00:28 netlinux kernel:         0x3a01b750, /* mtime  */
Dec  4 12:00:32 netlinux kernel:         0x3a01b750, /* ctime  */
Dec  4 12:00:32 netlinux kernel:         0x0006fe08, /* offset  */
Dec  4 12:00:32 netlinux kernel:         0x00008e83, /* dsize  */
Dec  4 12:00:32 netlinux kernel:         0x00008e83, /* rsize  */
Dec  4 12:00:32 netlinux kernel:         0x0c,       /* nsize  */
Dec  4 12:00:32 netlinux kernel:         0x01,       /* nlink  */
Dec  4 12:00:32 netlinux kernel:         0x00,       /* spare  */
Dec  4 12:00:32 netlinux kernel:         0,          /* rename  */
Dec  4 12:00:32 netlinux kernel:         0,          /* deleted  */
Dec  4 12:00:32 netlinux kernel:         0xff,       /* accurate  */
Dec  4 12:00:32 netlinux kernel:         0x00000000, /* dchksum  */
Dec  4 12:00:32 netlinux kernel:         0x0000,     /* nchksum  */
Dec  4 12:00:32 netlinux kernel:         0x0000,     /* chksum  */
Dec  4 12:00:32 netlinux kernel: }
Dec  4 12:00:32 netlinux kernel: jffs_rewrite_data(): Writing name "vmlinuz.wrks" to pos 0x12172120l.
Dec  4 12:00:32 netlinux kernel: , result: 0x0000050a
Dec  4 12:00:32 netlinux kernel: jffs_read_data(): file = "vmlinuz.wrks", read_offset = 458248, size = 4096
Dec  4 12:00:32 netlinux kernel:   jffs_get_node_data(): file: "vmlinuz.wrks", ino: 1256, version: 14, node_offset: 0
Dec  4 12:00:32 netlinux kernel:   jffs_get_node_data(): Read 504 bytes.
Dec  4 12:00:32 netlinux kernel:   jffs_get_node_data(): file: "vmlinuz.wrks", ino: 1256, version: 15, node_offset: 0
Dec  4 12:00:32 netlinux kernel:   jffs_get_node_data(): Read 3592 bytes.
Dec  4 12:00:32 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:00:32 netlinux kernel: , result: 0x0008bff4
Dec  4 12:00:32 netlinux kernel: jffs_read_data(): file = "vmlinuz.wrks", read_offset = 462344, size = 4096
Dec  4 12:00:32 netlinux kernel:   jffs_get_node_data(): file: "vmlinuz.wrks", ino: 1256, version: 15, node_offset: 3592
Dec  4 12:00:32 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 12:00:32 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:00:32 netlinux kernel: , result: 0x00088356
Dec  4 12:00:32 netlinux kernel: jffs_read_data(): file = "vmlinuz.wrks", read_offset = 466440, size = 4096
Dec  4 12:00:32 netlinux kernel:   jffs_get_node_data(): file: "vmlinuz.wrks", ino: 1256, version: 15, node_offset: 7688
Dec  4 12:00:32 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 12:00:32 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:00:32 netlinux kernel: , result: 0x00084f1f
Dec  4 12:00:32 netlinux kernel: jffs_read_data(): file = "vmlinuz.wrks", read_offset = 470536, size = 4096
Dec  4 12:00:32 netlinux kernel:   jffs_get_node_data(): file: "vmlinuz.wrks", ino: 1256, version: 15, node_offset: 11784
Dec  4 12:00:32 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 12:00:32 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:00:32 netlinux kernel: , result: 0x0007ee81
Dec  4 12:00:32 netlinux kernel: jffs_read_data(): file = "vmlinuz.wrks", read_offset = 474632, size = 4096
Dec  4 12:00:32 netlinux kernel:   jffs_get_node_data(): file: "vmlinuz.wrks", ino: 1256, version: 15, node_offset: 15880
Dec  4 12:00:32 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 12:00:32 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:00:32 netlinux kernel: , result: 0x00082568
Dec  4 12:00:32 netlinux kernel: jffs_read_data(): file = "vmlinuz.wrks", read_offset = 478728, size = 4096
Dec  4 12:00:32 netlinux kernel:   jffs_get_node_data(): file: "vmlinuz.wrks", ino: 1256, version: 15, node_offset: 19976
Dec  4 12:00:36 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 12:00:36 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:00:36 netlinux kernel: , result: 0x00082643
Dec  4 12:00:36 netlinux kernel: jffs_read_data(): file = "vmlinuz.wrks", read_offset = 482824, size = 4096
Dec  4 12:00:36 netlinux kernel:   jffs_get_node_data(): file: "vmlinuz.wrks", ino: 1256, version: 15, node_offset: 24072
Dec  4 12:00:36 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 12:00:36 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:00:36 netlinux kernel: , result: 0x0008526e
Dec  4 12:00:36 netlinux kernel: jffs_read_data(): file = "vmlinuz.wrks", read_offset = 486920, size = 4096
Dec  4 12:00:36 netlinux kernel:   jffs_get_node_data(): file: "vmlinuz.wrks", ino: 1256, version: 15, node_offset: 28168
Dec  4 12:00:36 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 12:00:36 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:00:36 netlinux kernel: , result: 0x0008237c
Dec  4 12:00:36 netlinux kernel: jffs_read_data(): file = "vmlinuz.wrks", read_offset = 491016, size = 3715
Dec  4 12:00:36 netlinux kernel:   jffs_get_node_data(): file: "vmlinuz.wrks", ino: 1256, version: 15, node_offset: 32264
Dec  4 12:00:36 netlinux kernel:   jffs_get_node_data(): Read 504 bytes.
Dec  4 12:00:36 netlinux kernel:   jffs_get_node_data(): file: "vmlinuz.wrks", ino: 1256, version: 16, node_offset: 0
Dec  4 12:00:36 netlinux kernel:   jffs_get_node_data(): Read 3211 bytes.
Dec  4 12:00:36 netlinux kernel:   jffs_read_data(): Read 3715 bytes.
Dec  4 12:00:36 netlinux kernel: , result: 0x0007a59d
Dec  4 12:00:36 netlinux kernel: , result: 0x00000ca8
Dec  4 12:00:36 netlinux kernel: jffs_insert_node(): ino = 1256, version = 24, name = "vmlinuz.wrks", deleted = 0
Dec  4 12:00:36 netlinux kernel: jffs_insert_node(): ---------------------------------------------------------------------- 1
Dec  4 12:00:36 netlinux kernel: jffs_update_file(): ino: 1256, version: 24
Dec  4 12:00:36 netlinux kernel: jffs_delete_data(): offset = 458248, remove_size = 36483
Dec  4 12:00:36 netlinux kernel: jffs_delete_data(): Removing node: ino: 1256, version: 14
Dec  4 12:00:36 netlinux kernel: jffs_fmfree(): node->ino = 1256, node->version = 14
Dec  4 12:00:36 netlinux kernel: jffs_delete_data(): Removing node: ino: 1256, version: 15
Dec  4 12:00:36 netlinux kernel: jffs_fmfree(): node->ino = 1256, node->version = 15
Dec  4 12:00:37 netlinux kernel: jffs_delete_data(): Removing node: ino: 1256, version: 16
Dec  4 12:00:37 netlinux kernel: jffs_fmfree(): node->ino = 1256, node->version = 16
Dec  4 12:00:37 netlinux kernel: jffs_delete_data(): f->size = 458248
Dec  4 12:00:37 netlinux kernel: jffs_insert_data(): node->data_offset = 458248, node->data_size = 36483, f->size = 458248
Dec  4 12:00:37 netlinux kernel: jffs_insert_data(): f->size = 494731
Dec  4 12:00:37 netlinux kernel: jffs_remove_redundant_nodes(): ino: 1256, name: "vmlinuz.wrks", newest_type: 7
Dec  4 12:00:37 netlinux kernel: jffs_insert_node(): ---------------------------------------------------------------------- 2
Dec  4 12:00:37 netlinux kernel: jffs_rewrite_data(): Leaving...
Dec  4 12:00:37 netlinux kernel: jffs_garbage_collect_next: Leaving...
Dec  4 12:00:42 netlinux kernel: ***jffs_garbage_collect_thread(): round #1383, fmc->dirty_size = 188380
Dec  4 12:00:42 netlinux kernel: struct jffs_fmcontrol: 0xc0818640
Dec  4 12:00:42 netlinux kernel: {
Dec  4 12:00:42 netlinux kernel:         0x00000000, /* flash_start  */
Dec  4 12:00:42 netlinux kernel:         15204352, /* flash_size  */
Dec  4 12:00:42 netlinux kernel:         7040616, /* used_size  */
Dec  4 12:00:42 netlinux kernel:         188380, /* dirty_size  */
Dec  4 12:00:42 netlinux kernel:         7975356, /* free_size  */
Dec  4 12:00:42 netlinux kernel:         131072, /* sector_size  */
Dec  4 12:00:42 netlinux kernel:         262144, /* min_free_size  */
Dec  4 12:00:42 netlinux kernel:         65536, /* max_chunk_size  */
Dec  4 12:00:42 netlinux kernel:         0xc0094980, /* mtd  */
Dec  4 12:00:42 netlinux kernel:         0xc0e286b0, /* head  */    (head->offset = 0x00580000)
Dec  4 12:00:42 netlinux kernel:         0xc0e28650, /* tail  */    (tail->offset + tail->size = 0x00c64e44)
Dec  4 12:00:42 netlinux kernel:         0x00000000, /* head_extra  */
Dec  4 12:00:42 netlinux kernel:         0x00000000, /* tail_extra  */
Dec  4 12:00:42 netlinux kernel: }
Dec  4 12:00:42 netlinux kernel: jffs_try_to_erase()
Dec  4 12:00:42 netlinux kernel: jffs_try_to_erase(): erase_size = 0
Dec  4 12:00:42 netlinux kernel: jffs_get_oldest_node(): ino = 1263, version = 6
Dec  4 12:00:42 netlinux kernel: jffs_find_file(): ino: 1263
Dec  4 12:00:42 netlinux kernel: jffs_find_file(): Found file with ino 1263. (name: "e2fsck")
Dec  4 12:00:42 netlinux kernel: jffs_garbage_collect_next(): "e2fsck", ino: 1263, version: 6, location 0x58b5ac, dsize 204
Dec  4 12:00:42 netlinux kernel:   total_name_size: 8
Dec  4 12:00:42 netlinux kernel:   data_size: 65468
Dec  4 12:00:42 netlinux kernel:   size: 65536
Dec  4 12:00:42 netlinux kernel:   f->nsize: 6
Dec  4 12:00:42 netlinux kernel:   f->size: 413624
Dec  4 12:00:42 netlinux kernel:   node->data_offset: 196404
Dec  4 12:00:42 netlinux kernel:   free_chunk_size1: 2208188
Dec  4 12:00:42 netlinux kernel:   free_chunk_size2: 5767168
Dec  4 12:00:42 netlinux kernel:   node->fm->offset: 0x0058b5ac
Dec  4 12:00:42 netlinux kernel: ***jffs_rewrite_data(): node: 1263, name: "e2fsck", size: 65468
Dec  4 12:00:42 netlinux kernel: jffs_fmalloc(): fmc = 0xc0818640, size = 65536, node = 0xc0e25550
Dec  4 12:00:42 netlinux kernel: jffs_fmalloc(): free_chunk_size1 = 2208188, free_chunk_size2 = 5767168
Dec  4 12:00:42 netlinux kernel: struct jffs_fmcontrol: 0xc0818640
Dec  4 12:00:42 netlinux kernel: {
Dec  4 12:00:42 netlinux kernel:         0x00000000, /* flash_start  */
Dec  4 12:00:42 netlinux kernel:         15204352, /* flash_size  */
Dec  4 12:00:42 netlinux kernel:         7106152, /* used_size  */
Dec  4 12:00:42 netlinux kernel:         188380, /* dirty_size  */
Dec  4 12:00:42 netlinux kernel:         7909820, /* free_size  */
Dec  4 12:00:42 netlinux kernel:         131072, /* sector_size  */
Dec  4 12:00:42 netlinux kernel:         262144, /* min_free_size  */
Dec  4 12:00:42 netlinux kernel:         65536, /* max_chunk_size  */
Dec  4 12:00:42 netlinux kernel:         0xc0094980, /* mtd  */
Dec  4 12:00:42 netlinux kernel:         0xc0e286b0, /* head  */    (head->offset = 0x00580000)
Dec  4 12:00:42 netlinux kernel:         0xc0e28710, /* tail  */    (tail->offset + tail->size = 0x00c74e44)
Dec  4 12:00:42 netlinux kernel:         0x00000000, /* head_extra  */
Dec  4 12:00:42 netlinux kernel:         0x00000000, /* tail_extra  */
Dec  4 12:00:42 netlinux kernel: }
Dec  4 12:00:42 netlinux kernel: struct jffs_fm: 0xc0e28710
Dec  4 12:00:42 netlinux kernel: {
Dec  4 12:00:42 netlinux kernel:        0x00c64e44, /* offset  */
Dec  4 12:00:42 netlinux kernel:        65536, /* size  */
Dec  4 12:00:42 netlinux kernel:        0xc0e28650, /* prev  */
Dec  4 12:00:42 netlinux kernel:        0x00000000, /* next  */
Dec  4 12:00:42 netlinux kernel:        0xc0e28500, /* nodes  */
Dec  4 12:00:42 netlinux kernel: }
Dec  4 12:00:42 netlinux kernel: jffs_rewrite_data(): Writing this raw inode to pos 0x12996164l.
Dec  4 12:00:42 netlinux kernel: jffs_raw_inode: inode number: 1263
Dec  4 12:00:42 netlinux kernel: {
Dec  4 12:00:42 netlinux kernel:         0x34383931, /* magic  */
Dec  4 12:00:42 netlinux kernel:         0x000004ef, /* ino  */
Dec  4 12:00:42 netlinux kernel:         0x000004ea, /* pino  */
Dec  4 12:00:42 netlinux kernel:         0x00000011, /* version  */
Dec  4 12:00:42 netlinux kernel:         0x000081ed, /* mode  */
Dec  4 12:00:42 netlinux kernel:         0x0000,     /* uid  */
Dec  4 12:00:42 netlinux kernel:         0x0000,     /* gid  */
Dec  4 12:00:42 netlinux kernel:         0x3a2a9077, /* atime  */
Dec  4 12:00:42 netlinux kernel:         0x39f812ca, /* mtime  */
Dec  4 12:00:42 netlinux kernel:         0x3a019817, /* ctime  */
Dec  4 12:00:42 netlinux kernel:         0x0002ff34, /* offset  */
Dec  4 12:00:42 netlinux kernel:         0x0000ffbc, /* dsize  */
Dec  4 12:00:42 netlinux kernel:         0x0000ffbc, /* rsize  */
Dec  4 12:00:42 netlinux kernel:         0x06,       /* nsize  */
Dec  4 12:00:46 netlinux kernel:         0x01,       /* nlink  */
Dec  4 12:00:46 netlinux kernel:         0x00,       /* spare  */
Dec  4 12:00:46 netlinux kernel:         0,          /* rename  */
Dec  4 12:00:46 netlinux kernel:         0,          /* deleted  */
Dec  4 12:00:46 netlinux kernel:         0xff,       /* accurate  */
Dec  4 12:00:46 netlinux kernel:         0x00000000, /* dchksum  */
Dec  4 12:00:46 netlinux kernel:         0x0000,     /* nchksum  */
Dec  4 12:00:46 netlinux kernel:         0x0000,     /* chksum  */
Dec  4 12:00:46 netlinux kernel: }
Dec  4 12:00:46 netlinux kernel: jffs_rewrite_data(): Writing name "e2fsck" to pos 0x12996224l.
Dec  4 12:00:46 netlinux kernel: , result: 0x0000023e
Dec  4 12:00:46 netlinux kernel: jffs_read_data(): file = "e2fsck", read_offset = 196404, size = 4096
Dec  4 12:00:46 netlinux kernel:   jffs_get_node_data(): file: "e2fsck", ino: 1263, version: 6, node_offset: 0
Dec  4 12:00:46 netlinux kernel:   jffs_get_node_data(): Read 204 bytes.
Dec  4 12:00:46 netlinux kernel:   jffs_get_node_data(): file: "e2fsck", ino: 1263, version: 7, node_offset: 0
Dec  4 12:00:46 netlinux kernel:   jffs_get_node_data(): Read 3892 bytes.
Dec  4 12:00:46 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:00:46 netlinux kernel: , result: 0x00071aec
Dec  4 12:00:46 netlinux kernel: jffs_read_data(): file = "e2fsck", read_offset = 200500, size = 4096
Dec  4 12:00:46 netlinux kernel:   jffs_get_node_data(): file: "e2fsck", ino: 1263, version: 7, node_offset: 3892
Dec  4 12:00:46 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 12:00:46 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:00:46 netlinux kernel: , result: 0x0007576a
Dec  4 12:00:46 netlinux kernel: jffs_read_data(): file = "e2fsck", read_offset = 204596, size = 4096
Dec  4 12:00:46 netlinux kernel:   jffs_get_node_data(): file: "e2fsck", ino: 1263, version: 7, node_offset: 7988
Dec  4 12:00:46 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 12:00:46 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:00:46 netlinux kernel: , result: 0x00074eaf
Dec  4 12:00:46 netlinux kernel: jffs_read_data(): file = "e2fsck", read_offset = 208692, size = 4096
Dec  4 12:00:46 netlinux kernel:   jffs_get_node_data(): file: "e2fsck", ino: 1263, version: 7, node_offset: 12084
Dec  4 12:00:46 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 12:00:46 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:00:46 netlinux kernel: , result: 0x00078dd7
Dec  4 12:00:46 netlinux kernel: jffs_read_data(): file = "e2fsck", read_offset = 212788, size = 4096
Dec  4 12:00:46 netlinux kernel:   jffs_get_node_data(): file: "e2fsck", ino: 1263, version: 7, node_offset: 16180
Dec  4 12:00:46 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 12:00:46 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:00:46 netlinux kernel: , result: 0x00073924
Dec  4 12:00:46 netlinux kernel: jffs_read_data(): file = "e2fsck", read_offset = 216884, size = 4096
Dec  4 12:00:46 netlinux kernel:   jffs_get_node_data(): file: "e2fsck", ino: 1263, version: 7, node_offset: 20276
Dec  4 12:00:46 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 12:00:46 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:00:46 netlinux kernel: , result: 0x000816bc
Dec  4 12:00:46 netlinux kernel: jffs_read_data(): file = "e2fsck", read_offset = 220980, size = 4096
Dec  4 12:00:46 netlinux kernel:   jffs_get_node_data(): file: "e2fsck", ino: 1263, version: 7, node_offset: 24372
Dec  4 12:00:50 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 12:00:50 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:00:50 netlinux kernel: , result: 0x0008feb6
Dec  4 12:00:50 netlinux kernel: jffs_read_data(): file = "e2fsck", read_offset = 225076, size = 4096
Dec  4 12:00:50 netlinux kernel:   jffs_get_node_data(): file: "e2fsck", ino: 1263, version: 7, node_offset: 28468
Dec  4 12:00:50 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 12:00:50 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:00:50 netlinux kernel: , result: 0x0008ecc4
Dec  4 12:00:50 netlinux kernel: jffs_read_data(): file = "e2fsck", read_offset = 229172, size = 4096
Dec  4 12:00:50 netlinux kernel:   jffs_get_node_data(): file: "e2fsck", ino: 1263, version: 7, node_offset: 32564
Dec  4 12:00:50 netlinux kernel:   jffs_get_node_data(): Read 204 bytes.
Dec  4 12:00:50 netlinux kernel:   jffs_get_node_data(): file: "e2fsck", ino: 1263, version: 8, node_offset: 0
Dec  4 12:00:50 netlinux kernel:   jffs_get_node_data(): Read 3892 bytes.
Dec  4 12:00:50 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:00:50 netlinux kernel: , result: 0x0007de87
Dec  4 12:00:50 netlinux kernel: jffs_read_data(): file = "e2fsck", read_offset = 233268, size = 4096
Dec  4 12:00:50 netlinux kernel:   jffs_get_node_data(): file: "e2fsck", ino: 1263, version: 8, node_offset: 3892
Dec  4 12:00:50 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 12:00:50 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:00:50 netlinux kernel: , result: 0x0006ccd9
Dec  4 12:00:50 netlinux kernel: jffs_read_data(): file = "e2fsck", read_offset = 237364, size = 4096
Dec  4 12:00:50 netlinux kernel:   jffs_get_node_data(): file: "e2fsck", ino: 1263, version: 8, node_offset: 7988
Dec  4 12:00:50 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 12:00:50 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:00:50 netlinux kernel: , result: 0x0007f885
Dec  4 12:00:50 netlinux kernel: jffs_read_data(): file = "e2fsck", read_offset = 241460, size = 4096
Dec  4 12:00:50 netlinux kernel:   jffs_get_node_data(): file: "e2fsck", ino: 1263, version: 8, node_offset: 12084
Dec  4 12:00:50 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 12:00:50 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:00:50 netlinux kernel: , result: 0x0006fa96
Dec  4 12:00:50 netlinux kernel: jffs_read_data(): file = "e2fsck", read_offset = 245556, size = 4096
Dec  4 12:00:50 netlinux kernel:   jffs_get_node_data(): file: "e2fsck", ino: 1263, version: 8, node_offset: 16180
Dec  4 12:00:50 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 12:00:50 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:00:50 netlinux kernel: , result: 0x000761fb
Dec  4 12:00:50 netlinux kernel: jffs_read_data(): file = "e2fsck", read_offset = 249652, size = 4096
Dec  4 12:00:50 netlinux kernel:   jffs_get_node_data(): file: "e2fsck", ino: 1263, version: 8, node_offset: 20276
Dec  4 12:00:50 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 12:00:50 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:00:50 netlinux kernel: , result: 0x0006e513
Dec  4 12:00:50 netlinux kernel: jffs_read_data(): file = "e2fsck", read_offset = 253748, size = 4096
Dec  4 12:00:50 netlinux kernel:   jffs_get_node_data(): file: "e2fsck", ino: 1263, version: 8, node_offset: 24372
Dec  4 12:00:50 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 12:00:50 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:00:50 netlinux kernel: , result: 0x0007702e
Dec  4 12:00:50 netlinux kernel: jffs_read_data(): file = "e2fsck", read_offset = 257844, size = 4028
Dec  4 12:00:50 netlinux kernel:   jffs_get_node_data(): file: "e2fsck", ino: 1263, version: 8, node_offset: 28468
Dec  4 12:00:55 netlinux kernel:   jffs_get_node_data(): Read 4028 bytes.
Dec  4 12:00:55 netlinux kernel:   jffs_read_data(): Read 4028 bytes.
Dec  4 12:00:55 netlinux kernel: , result: 0x0007069a
Dec  4 12:00:55 netlinux kernel: , result: 0x00000f6f
Dec  4 12:00:55 netlinux kernel: jffs_insert_node(): ino = 1263, version = 17, name = "e2fsck", deleted = 0
Dec  4 12:00:55 netlinux kernel: jffs_insert_node(): ---------------------------------------------------------------------- 1
Dec  4 12:00:55 netlinux kernel: jffs_update_file(): ino: 1263, version: 17
Dec  4 12:00:55 netlinux kernel: jffs_delete_data(): offset = 196404, remove_size = 65468
Dec  4 12:00:55 netlinux kernel: jffs_delete_data(): Removing node: ino: 1263, version: 6
Dec  4 12:00:55 netlinux kernel: jffs_fmfree(): node->ino = 1263, node->version = 6
Dec  4 12:00:55 netlinux kernel: jffs_delete_data(): Removing node: ino: 1263, version: 7
Dec  4 12:00:55 netlinux kernel: jffs_fmfree(): node->ino = 1263, node->version = 7
Dec  4 12:00:55 netlinux kernel: jffs_delete_data(): f->size = 348156
Dec  4 12:00:55 netlinux kernel: jffs_insert_data(): node->data_offset = 196404, node->data_size = 65468, f->size = 348156
Dec  4 12:00:55 netlinux kernel: Cool stuff's happening!
Dec  4 12:00:55 netlinux last message repeated 3 times
Dec  4 12:00:55 netlinux kernel: jffs_insert_data(): f->size = 413624
Dec  4 12:00:55 netlinux kernel: jffs_remove_redundant_nodes(): ino: 1263, name: "e2fsck", newest_type: 7
Dec  4 12:00:55 netlinux kernel: jffs_insert_node(): ---------------------------------------------------------------------- 2
Dec  4 12:00:55 netlinux kernel: jffs_rewrite_data(): Leaving...
Dec  4 12:00:55 netlinux kernel: jffs_garbage_collect_next: Leaving...
Dec  4 12:00:55 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 12:00:55 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:00:55 netlinux kernel: , result: 0x00027126
Dec  4 12:00:55 netlinux kernel: jffs_read_data(): file = "libslang.so.1.3.7", read_offset = 36864, size = 4096
Dec  4 12:00:55 netlinux kernel:   jffs_get_node_data(): file: "libslang.so.1.3.7", ino: 1345, version: 2, node_offset: 4096
Dec  4 12:00:55 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 12:00:55 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:00:55 netlinux kernel: , result: 0x0003f818
Dec  4 12:00:55 netlinux kernel: jffs_read_data(): file = "libslang.so.1.3.7", read_offset = 40960, size = 4096
Dec  4 12:00:55 netlinux kernel:   jffs_get_node_data(): file: "libslang.so.1.3.7", ino: 1345, version: 2, node_offset: 8192
Dec  4 12:00:55 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 12:00:55 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:00:55 netlinux kernel: , result: 0x00075ed0
Dec  4 12:00:55 netlinux kernel: jffs_read_data(): file = "libslang.so.1.3.7", read_offset = 45056, size = 4096
Dec  4 12:00:55 netlinux kernel:   jffs_get_node_data(): file: "libslang.so.1.3.7", ino: 1345, version: 2, node_offset: 12288
Dec  4 12:00:55 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 12:00:55 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:00:55 netlinux kernel: , result: 0x000801ab
Dec  4 12:00:55 netlinux kernel: jffs_read_data(): file = "libslang.so.1.3.7", read_offset = 49152, size = 4096
Dec  4 12:00:55 netlinux kernel:   jffs_get_node_data(): file: "libslang.so.1.3.7", ino: 1345, version: 2, node_offset: 16384
Dec  4 12:00:55 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 12:00:55 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:00:55 netlinux kernel: , result: 0x0007969f
Dec  4 12:00:55 netlinux kernel: jffs_read_data(): file = "libslang.so.1.3.7", read_offset = 53248, size = 4096
Dec  4 12:00:55 netlinux kernel:   jffs_get_node_data(): file: "libslang.so.1.3.7", ino: 1345, version: 2, node_offset: 20480
Dec  4 12:00:55 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 12:00:55 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:00:55 netlinux kernel: , result: 0x00079d21
Dec  4 12:00:59 netlinux kernel: jffs_read_data(): file = "libslang.so.1.3.7", read_offset = 57344, size = 4096
Dec  4 12:00:59 netlinux kernel:   jffs_get_node_data(): file: "libslang.so.1.3.7", ino: 1345, version: 2, node_offset: 24576
Dec  4 12:00:59 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 12:00:59 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:00:59 netlinux kernel: , result: 0x000818a6
Dec  4 12:00:59 netlinux kernel: jffs_read_data(): file = "libslang.so.1.3.7", read_offset = 61440, size = 4016
Dec  4 12:00:59 netlinux kernel:   jffs_get_node_data(): file: "libslang.so.1.3.7", ino: 1345, version: 2, node_offset: 28672
Dec  4 12:00:59 netlinux kernel:   jffs_get_node_data(): Read 4016 bytes.
Dec  4 12:00:59 netlinux kernel:   jffs_read_data(): Read 4016 bytes.
Dec  4 12:00:59 netlinux kernel: , result: 0x00077fc2
Dec  4 12:00:59 netlinux kernel: , result: 0x00000bf9
Dec  4 12:00:59 netlinux kernel: jffs_insert_node(): ino = 1345, version = 13, name = "libslang.so.1.3.7", deleted = 0
Dec  4 12:00:59 netlinux kernel: jffs_insert_node(): ---------------------------------------------------------------------- 1
Dec  4 12:00:59 netlinux kernel: jffs_update_file(): ino: 1345, version: 13
Dec  4 12:00:59 netlinux kernel: jffs_delete_data(): offset = 0, remove_size = 65456
Dec  4 12:00:59 netlinux kernel: jffs_delete_data(): Removing node: ino: 1345, version: 1
Dec  4 12:00:59 netlinux kernel: jffs_fmfree(): node->ino = 1345, node->version = 1
Dec  4 12:00:59 netlinux kernel: jffs_delete_data(): f->size = 300824
Dec  4 12:00:59 netlinux kernel: jffs_insert_data(): node->data_offset = 0, node->data_size = 65456, f->size = 300824
Dec  4 12:00:59 netlinux kernel: Cool stuff's happening!
Dec  4 12:00:59 netlinux kernel: jffs_insert_data(): f->size = 366280
Dec  4 12:00:59 netlinux kernel: jffs_remove_redundant_nodes(): ino: 1345, name: "libslang.so.1.3.7", newest_type: 7
Dec  4 12:00:59 netlinux kernel: jffs_insert_node(): ---------------------------------------------------------------------- 2
Dec  4 12:00:59 netlinux kernel: jffs_rewrite_data(): Leaving...
Dec  4 12:00:59 netlinux kernel: jffs_garbage_collect_next: Leaving...
Dec  4 12:00:59 netlinux kernel: ***jffs_garbage_collect_thread(): round #1479, fmc->dirty_size = 209320
Dec  4 12:00:59 netlinux kernel: struct jffs_fmcontrol: 0xc0818640
Dec  4 12:00:59 netlinux kernel: {
Dec  4 12:00:59 netlinux kernel:         0x00000000, /* flash_start  */
Dec  4 12:00:59 netlinux kernel:         15204352, /* flash_size  */
Dec  4 12:00:59 netlinux kernel:         7039924, /* used_size  */
Dec  4 12:00:59 netlinux kernel:         209320, /* dirty_size  */
Dec  4 12:00:59 netlinux kernel:         7955108, /* free_size  */
Dec  4 12:00:59 netlinux kernel:         131072, /* sector_size  */
Dec  4 12:00:59 netlinux kernel:         262144, /* min_free_size  */
Dec  4 12:00:59 netlinux kernel:         65536, /* max_chunk_size  */
Dec  4 12:00:59 netlinux kernel:         0xc0094980, /* mtd  */
Dec  4 12:00:59 netlinux kernel:         0xc0e13000, /* head  */    (head->offset = 0x00640000)
Dec  4 12:00:59 netlinux kernel:         0xc0e0dcb0, /* tail  */    (tail->offset + tail->size = 0x00d29d5c)
Dec  4 12:00:59 netlinux kernel:         0x00000000, /* head_extra  */
Dec  4 12:00:59 netlinux kernel:         0x00000000, /* tail_extra  */
Dec  4 12:00:59 netlinux kernel: }
Dec  4 12:00:59 netlinux kernel: jffs_try_to_erase()
Dec  4 12:00:59 netlinux kernel: jffs_try_to_erase(): erase_size = 0
Dec  4 12:00:59 netlinux kernel: jffs_get_oldest_node(): ino = 1345, version = 2
Dec  4 12:00:59 netlinux kernel: jffs_find_file(): ino: 1345
Dec  4 12:00:59 netlinux kernel: jffs_find_file(): Found file with ino 1345. (name: "libslang.so.1.3.7")
Dec  4 12:00:59 netlinux kernel: jffs_garbage_collect_next(): "libslang.so.1.3.7", ino: 1345, version: 2, location 0x650778, dsize 8
0
Dec  4 12:00:59 netlinux kernel:   total_name_size: 20
Dec  4 12:00:59 netlinux kernel:   data_size: 65456
Dec  4 12:00:59 netlinux kernel:   size: 65536
Dec  4 12:01:03 netlinux kernel:   f->nsize: 17
Dec  4 12:01:03 netlinux kernel:   f->size: 366280
Dec  4 12:01:03 netlinux kernel:   node->data_offset: 65456
Dec  4 12:01:03 netlinux kernel:   free_chunk_size1: 1401508
Dec  4 12:01:03 netlinux kernel:   free_chunk_size2: 6553600
Dec  4 12:01:03 netlinux kernel:   node->fm->offset: 0x00650778
Dec  4 12:01:03 netlinux kernel: ***jffs_rewrite_data(): node: 1345, name: "libslang.so.1.3.7", size: 65456
Dec  4 12:01:03 netlinux kernel: jffs_fmalloc(): fmc = 0xc0818640, size = 65536, node = 0xc0df5620
Dec  4 12:01:03 netlinux kernel: jffs_fmalloc(): free_chunk_size1 = 1401508, free_chunk_size2 = 6553600
Dec  4 12:01:03 netlinux kernel: struct jffs_fmcontrol: 0xc0818640
Dec  4 12:01:03 netlinux kernel: {
Dec  4 12:01:03 netlinux kernel:         0x00000000, /* flash_start  */
Dec  4 12:01:03 netlinux kernel:         15204352, /* flash_size  */
Dec  4 12:01:03 netlinux kernel:         7105460, /* used_size  */
Dec  4 12:01:03 netlinux kernel:         209320, /* dirty_size  */
Dec  4 12:01:03 netlinux kernel:         7889572, /* free_size  */
Dec  4 12:01:03 netlinux kernel:         131072, /* sector_size  */
Dec  4 12:01:03 netlinux kernel:         262144, /* min_free_size  */
Dec  4 12:01:03 netlinux kernel:         65536, /* max_chunk_size  */
Dec  4 12:01:03 netlinux kernel:         0xc0094980, /* mtd  */
Dec  4 12:01:03 netlinux kernel:         0xc0e13000, /* head  */    (head->offset = 0x00640000)
Dec  4 12:01:03 netlinux kernel:         0xc0e0dd40, /* tail  */    (tail->offset + tail->size = 0x00d39d5c)
Dec  4 12:01:03 netlinux kernel:         0x00000000, /* head_extra  */
Dec  4 12:01:03 netlinux kernel:         0x00000000, /* tail_extra  */
Dec  4 12:01:03 netlinux kernel: }
Dec  4 12:01:03 netlinux kernel: struct jffs_fm: 0xc0e0dd40
Dec  4 12:01:03 netlinux kernel: {
Dec  4 12:01:03 netlinux kernel:        0x00d29d5c, /* offset  */
Dec  4 12:01:03 netlinux kernel:        65536, /* size  */
Dec  4 12:01:03 netlinux kernel:        0xc0e0dcb0, /* prev  */
Dec  4 12:01:03 netlinux kernel:        0x00000000, /* next  */
Dec  4 12:01:03 netlinux kernel:        0xc0e0dd70, /* nodes  */
Dec  4 12:01:03 netlinux kernel: }
Dec  4 12:01:03 netlinux kernel: jffs_rewrite_data(): Writing this raw inode to pos 0x13802844l.
Dec  4 12:01:03 netlinux kernel: jffs_raw_inode: inode number: 1345
Dec  4 12:01:03 netlinux kernel: {
Dec  4 12:01:03 netlinux kernel:         0x34383931, /* magic  */
Dec  4 12:01:03 netlinux kernel:         0x00000541, /* ino  */
Dec  4 12:01:03 netlinux kernel:         0x00000540, /* pino  */
Dec  4 12:01:03 netlinux kernel:         0x0000000e, /* version  */
Dec  4 12:01:03 netlinux kernel:         0x000081a4, /* mode  */
Dec  4 12:01:03 netlinux kernel:         0x0000,     /* uid  */
Dec  4 12:01:03 netlinux kernel:         0x0000,     /* gid  */
Dec  4 12:01:03 netlinux kernel:         0x3a27f64f, /* atime  */
Dec  4 12:01:03 netlinux kernel:         0x39f812cb, /* mtime  */
Dec  4 12:01:03 netlinux kernel:         0x3a019819, /* ctime  */
Dec  4 12:01:03 netlinux kernel:         0x0000ffb0, /* offset  */
Dec  4 12:01:03 netlinux kernel:         0x0000ffb0, /* dsize  */
Dec  4 12:01:03 netlinux kernel:         0x0000ffb0, /* rsize  */
Dec  4 12:01:03 netlinux kernel:         0x11,       /* nsize  */
Dec  4 12:01:03 netlinux kernel:         0x01,       /* nlink  */
Dec  4 12:01:03 netlinux kernel:         0x00,       /* spare  */
Dec  4 12:01:03 netlinux kernel:         0,          /* rename  */
Dec  4 12:01:03 netlinux kernel:         0,          /* deleted  */
Dec  4 12:01:03 netlinux kernel:         0xff,       /* accurate  */
Dec  4 12:01:03 netlinux kernel:         0x00000000, /* dchksum  */
Dec  4 12:01:03 netlinux kernel:         0x0000,     /* nchksum  */
Dec  4 12:01:07 netlinux kernel:         0x0000,     /* chksum  */
Dec  4 12:01:07 netlinux kernel: }
Dec  4 12:01:07 netlinux kernel: jffs_rewrite_data(): Writing name "libslang.so.1.3.7" to pos 0x13802904l.
Dec  4 12:01:07 netlinux kernel: , result: 0x00000581
Dec  4 12:01:07 netlinux kernel: jffs_read_data(): file = "libslang.so.1.3.7", read_offset = 65456, size = 4096
Dec  4 12:01:07 netlinux kernel:   jffs_get_node_data(): file: "libslang.so.1.3.7", ino: 1345, version: 2, node_offset: 0
Dec  4 12:01:07 netlinux kernel:   jffs_get_node_data(): Read 80 bytes.
Dec  4 12:01:07 netlinux kernel:   jffs_get_node_data(): file: "libslang.so.1.3.7", ino: 1345, version: 3, node_offset: 0
Dec  4 12:01:07 netlinux kernel:   jffs_get_node_data(): Read 4016 bytes.
Dec  4 12:01:07 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:01:07 netlinux kernel: , result: 0x00078416
Dec  4 12:01:07 netlinux kernel: jffs_read_data(): file = "libslang.so.1.3.7", read_offset = 69552, size = 4096
Dec  4 12:01:07 netlinux kernel:   jffs_get_node_data(): file: "libslang.so.1.3.7", ino: 1345, version: 3, node_offset: 4016
Dec  4 12:01:07 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 12:01:07 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:01:07 netlinux kernel: , result: 0x0007d581
Dec  4 12:01:07 netlinux kernel: jffs_read_data(): file = "libslang.so.1.3.7", read_offset = 73648, size = 4096
Dec  4 12:01:07 netlinux kernel:   jffs_get_node_data(): file: "libslang.so.1.3.7", ino: 1345, version: 3, node_offset: 8112
Dec  4 12:01:07 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 12:01:07 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:01:07 netlinux kernel: , result: 0x00072e32
Dec  4 12:01:07 netlinux kernel: jffs_read_data(): file = "libslang.so.1.3.7", read_offset = 77744, size = 4096
Dec  4 12:01:07 netlinux kernel:   jffs_get_node_data(): file: "libslang.so.1.3.7", ino: 1345, version: 3, node_offset: 12208
Dec  4 12:01:07 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 12:01:07 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:01:07 netlinux kernel: , result: 0x0006c0eb
Dec  4 12:01:07 netlinux kernel: jffs_read_data(): file = "libslang.so.1.3.7", read_offset = 81840, size = 4096
Dec  4 12:01:07 netlinux kernel:   jffs_get_node_data(): file: "libslang.so.1.3.7", ino: 1345, version: 3, node_offset: 16304
Dec  4 12:01:07 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 12:01:07 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:01:07 netlinux kernel: , result: 0x00072919
Dec  4 12:01:07 netlinux kernel: jffs_read_data(): file = "libslang.so.1.3.7", read_offset = 85936, size = 4096
Dec  4 12:01:07 netlinux kernel:   jffs_get_node_data(): file: "libslang.so.1.3.7", ino: 1345, version: 3, node_offset: 20400
Dec  4 12:01:07 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 12:01:07 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:01:07 netlinux kernel: ,Dec  4 12:01:07 netlinux kernel: jffs_read_data(): file = "libslang.so.1.3.7", read_offset = 90032
, size = 4096
Dec  4 12:01:07 netlinux kernel:   jffs_get_node_data(): file: "libslang.so.1.3.7", ino: 1345, version: 3, node_offset: 24496
Dec  4 12:01:07 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 12:01:07 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:01:07 netlinux kernel: , result: 0x0005d2f1
Dec  4 12:01:07 netlinux kernel: jffs_read_data(): file = "libslang.so.1.3.7", read_offset = 94128, size = 4096
Dec  4 12:01:07 netlinux kernel:   jffs_get_node_data(): file: "libslang.so.1.3.7", ino: 1345, version: 3, node_offset: 28592
Dec  4 12:01:11 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 12:01:11 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:01:11 netlinux kernel: , result: 0x000729da
Dec  4 12:01:11 netlinux kernel: jffs_read_data(): file = "libslang.so.1.3.7", read_offset = 98224, size = 4096
Dec  4 12:01:11 netlinux kernel:   jffs_get_node_data(): file: "libslang.so.1.3.7", ino: 1345, version: 3, node_offset: 32688
Dec  4 12:01:11 netlinux kernel:   jffs_get_node_data(): Read 80 bytes.
Dec  4 12:01:11 netlinux kernel:   jffs_get_node_data(): file: "libslang.so.1.3.7", ino: 1345, version: 4, node_offset: 0
Dec  4 12:01:11 netlinux kernel:   jffs_get_node_data(): Read 4016 bytes.
Dec  4 12:01:11 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:01:11 netlinux kernel: , result: 0x0007b529
Dec  4 12:01:11 netlinux kernel: jffs_read_data(): file = "libslang.so.1.3.7", read_offset = 102320, size = 4096
Dec  4 12:01:11 netlinux kernel:   jffs_get_node_data(): file: "libslang.so.1.3.7", ino: 1345, version: 4, node_offset: 4016
Dec  4 12:01:11 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 12:01:11 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:01:11 netlinux kernel: , result: 0x0007c155
Dec  4 12:01:11 netlinux kernel: jffs_read_data(): file = "libslang.so.1.3.7", read_offset = 106416, size = 4096
Dec  4 12:01:11 netlinux kernel:   jffs_get_node_data(): file: "libslang.so.1.3.7", ino: 1345, version: 4, node_offset: 8112
Dec  4 12:01:11 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 12:01:11 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:01:11 netlinux kernel: , result: 0x0007bffa
Dec  4 12:01:11 netlinux kernel: jffs_read_data(): file = "libslang.so.1.3.7", read_offset = 110512, size = 4096
Dec  4 12:01:11 netlinux kernel:   jffs_get_node_data(): file: "libslang.so.1.3.7", ino: 1345, version: 4, node_offset: 12208
Dec  4 12:01:11 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 12:01:11 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:01:11 netlinux kernel: , result: 0x0007d78f
Dec  4 12:01:11 netlinux kernel: jffs_read_data(): file = "libslang.so.1.3.7", read_offset = 114608, size = 4096
Dec  4 12:01:11 netlinux kernel:   jffs_get_node_data(): file: "libslang.so.1.3.7", ino: 1345, version: 4, node_offset: 16304
Dec  4 12:01:11 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 12:01:11 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:01:11 netlinux kernel: , result: 0x00079c73
Dec  4 12:01:11 netlinux kernel: jffs_read_data(): file = "libslang.so.1.3.7", read_offset = 118704, size = 4096
Dec  4 12:01:11 netlinux kernel:   jffs_get_node_data(): file: "libslang.so.1.3.7", ino: 1345, version: 4, node_offset: 20400
Dec  4 12:01:11 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 12:01:11 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:01:11 netlinux kernel: , result: 0x00077453
Dec  4 12:01:11 netlinux kernel: jffs_read_data(): file = "libslang.so.1.3.7", read_offset = 122800, size = 4096
Dec  4 12:01:11 netlinux kernel:   jffs_get_node_data(): file: "libslang.so.1.3.7", ino: 1345, version: 4, node_offset: 24496
Dec  4 12:01:11 netlinux kernel:   jffs_get_node_data(): Read 4096 bytes.
Dec  4 12:01:11 netlinux kernel:   jffs_read_data(): Read 4096 bytes.
Dec  4 12:01:11 netlinux kernel: , result: 0x00077c26
Dec  4 12:01:15 netlinux kernel: jffs_read_data(): file = "libslang.so.1.3.7", read_offset = 126896, size = 4016
Dec  4 12:01:15 netlinux kernel:   jffs_get_node_data(): file: "libslang.so.1.3.7", ino: 1345, version: 4, node_offset: 28592
Dec  4 12:01:15 netlinux kernel:   jffs_get_node_data(): Read 4016 bytes.
Dec  4 12:01:15 netlinux kernel:   jffs_read_data(): Read 4016 bytes.
Dec  4 12:01:15 netlinux kernel: , result: 0x00069119
Dec  4 12:01:15 netlinux kernel: , result: 0x00000f08
Dec  4 12:01:15 netlinux kernel: jffs_insert_node(): ino = 1345, version = 14, name = "libslang.so.1.3.7", deleted = 0
Dec  4 12:01:15 netlinux kernel: jffs_insert_node(): ---------------------------------------------------------------------- 1
Dec  4 12:01:15 netlinux kernel: jffs_update_file(): ino: 1345, version: 14
Dec  4 12:01:15 netlinux kernel: jffs_delete_data(): offset = 65456, remove_size = 65456
Dec  4 12:01:15 netlinux kernel: jffs_delete_data(): Removing node: ino: 1345, version: 2
Dec  4 12:01:15 netlinux kernel: jffs_fmfree(): node->ino = 1345, node->version = 2
Dec  4 12:01:15 netlinux kernel: jffs_delete_data(): Removing node: ino: 1345, version: 3
Dec  4 12:01:15 netlinux kernel: jffs_fmfree(): node->ino = 1345, node->version = 3
Dec  4 12:01:15 netlinux kernel: jffs_delete_data(): f->size = 300824
Dec  4 12:01:15 netlinux kernel: jffs_insert_data(): node->data_offset = 65456, node->data_size = 65456, f->size = 300824
Dec  4 12:01:15 netlinux kernel: Cool stuff's happening!
Dec  4 12:01:15 netlinux kernel: Cool stuff's happening!
Dec  4 12:01:15 netlinux kernel: jffs_insert_data(): f->size = 366280
Dec  4 12:01:15 netlinux kernel: jffs_remove_redundant_nodes(): ino: 1345, name: "libslang.so.1.3.7", newest_type: 7
Dec  4 12:01:15 netlinux kernel: jffs_insert_node(): ---------------------------------------------------------------------- 2
Dec  4 12:01:15 netlinux kernel: jffs_rewrite_data(): Leaving...
Dec  4 12:01:15 netlinux kernel: jffs_garbage_collect_next: Leaving...
Dec  4 12:01:15 netlinux kernel:         0x000081a4, /* mode  */
Dec  4 12:01:15 netlinux kernel:         0x0000,     /* uid  */
Dec  4 12:01:15 netlinux kernel:         0x0000,     /* gid  */
Dec  4 12:01:15 netlinux kernel:         0x3a27f650, /* atime  */
Dec  4 12:01:15 netlinux kernel:         0x3a01372c, /* mtime  */
Dec  4 12:01:15 netlinux kernel:         0x3a019819, /* ctime  */
Dec  4 12:01:15 netlinux kernel:         0x00000000, /* offset  */
Dec  4 12:01:15 netlinux kernel:         0x00000003, /* dsize  */
Dec  4 12:01:15 netlinux kernel:         0x00000003, /* rsize  */
Dec  4 12:01:15 netlinux kernel:         0x0a,       /* nsize  */
Dec  4 12:01:15 netlinux kernel:         0x01,       /* nlink  */
Dec  4 12:01:15 netlinux kernel:         0x00,       /* spare  */
Dec  4 12:01:15 netlinux kernel:         0,          /* rename  */
Dec  4 12:01:15 netlinux kernel:         0,          /* deleted  */
Dec  4 12:01:15 netlinux kernel:         0xff,       /* accurate  */
Dec  4 12:01:15 netlinux kernel:         0x00000000, /* dchksum  */
Dec  4 12:01:15 netlinux kernel:         0x0000,     /* nchksum  */
Dec  4 12:01:15 netlinux kernel:         0x0000,     /* chksum  */
Dec  4 12:01:15 netlinux kernel: }
Dec  4 12:01:15 netlinux kernel: jffs_rewrite_data(): Writing name "thttpd.pid" to pos 0x14162508l.
Dec  4 12:01:15 netlinux kernel: , result: 0x00000403
Dec  4 12:01:15 netlinux kernel: jffs_read_data(): file = "thttpd.pid", read_offset = 0, size = 3
Dec  4 12:01:15 netlinux kernel:   jffs_get_node_data(): file: "thttpd.pid", ino: 1359, version: 1, node_offset: 0
Dec  4 12:01:15 netlinux kernel:   jffs_get_node_data(): Read 3 bytes.
Dec  4 12:01:15 netlinux kernel:   jffs_read_data(): Read 3 bytes.
Dec  4 12:01:15 netlinux kernel: , result: 0x00000076
Dec  4 12:01:15 netlinux kernel: , result: 0x00000662
Dec  4 12:01:19 netlinux kernel: jffs_insert_node(): ino = 1359, version = 2, name = "thttpd.pid", deleted = 0
Dec  4 12:01:19 netlinux kernel: jffs_insert_node(): ---------------------------------------------------------------------- 1
Dec  4 12:01:19 netlinux kernel: jffs_update_file(): ino: 1359, version: 2
Dec  4 12:01:19 netlinux kernel: jffs_delete_data(): offset = 0, remove_size = 3
Dec  4 12:01:19 netlinux kernel: jffs_delete_data(): Removing node: ino: 1359, version: 1
Dec  4 12:01:19 netlinux kernel: jffs_fmfree(): node->ino = 1359, node->version = 1
Dec  4 12:01:19 netlinux kernel: jffs_delete_data(): f->size = 0
Dec  4 12:01:19 netlinux kernel: jffs_insert_data(): node->data_offset = 0, node->data_size = 3, f->size = 0
Dec  4 12:01:19 netlinux kernel: jffs_insert_data(): f->size = 3
Dec  4 12:01:19 netlinux kernel: jffs_remove_redundant_nodes(): ino: 1359, name: "thttpd.pid", newest_type: 7
Dec  4 12:01:19 netlinux kernel: jffs_insert_node(): ---------------------------------------------------------------------- 2
Dec  4 12:01:19 netlinux kernel: jffs_rewrite_data(): Leaving...
Dec  4 12:01:19 netlinux kernel: jffs_garbage_collect_next: Leaving...
Dec  4 12:01:19 netlinux kernel: ***jffs_garbage_collect_thread(): round #1501, fmc->dirty_size = 208952
Dec  4 12:01:19 netlinux kernel: struct jffs_fmcontrol: 0xc0818640
Dec  4 12:01:19 netlinux kernel: {
Dec  4 12:01:19 netlinux kernel:         0x00000000, /* flash_start  */
Dec  4 12:01:19 netlinux kernel:         15204352, /* flash_size  */
Dec  4 12:01:19 netlinux kernel:         7006756, /* used_size  */
Dec  4 12:01:19 netlinux kernel:         208952, /* dirty_size  */
Dec  4 12:01:19 netlinux kernel:         7988644, /* free_size  */
Dec  4 12:01:19 netlinux kernel:         131072, /* sector_size  */
Dec  4 12:01:19 netlinux kernel:         262144, /* min_free_size  */
Dec  4 12:01:19 netlinux kernel:         65536, /* max_chunk_size  */
Dec  4 12:01:19 netlinux kernel:         0xc0094980, /* mtd  */
Dec  4 12:01:19 netlinux kernel:         0xc0e39160, /* head  */    (head->offset = 0x006a0000)
Dec  4 12:01:19 netlinux kernel:         0xc0e398e0, /* tail  */    (tail->offset + tail->size = 0x00d81a5c)
Dec  4 12:01:19 netlinux kernel:         0x00000000, /* head_extra  */
Dec  4 12:01:19 netlinux kernel:         0x00000000, /* tail_extra  */
Dec  4 12:01:19 netlinux kernel: }
Dec  4 12:01:19 netlinux kernel: jffs_try_to_erase()
Dec  4 12:01:19 netlinux kernel: jffs_try_to_erase(): erase_size = 0
Dec  4 12:01:19 netlinux kernel: jffs_get_oldest_node(): ino = 1360, version = 1
Dec  4 12:01:19 netlinux kernel: jffs_find_file(): ino: 1360
Dec  4 12:01:19 netlinux kernel: jffs_find_file(): Found file with ino 1360. (name: "spool")
Dec  4 12:01:19 netlinux kernel: jffs_garbage_collect_next(): "spool", ino: 1360, version: 1, location 0x6b0608, dsize 0
Dec  4 12:01:19 netlinux kernel:   total_name_size: 8
Dec  4 12:01:19 netlinux kernel:   data_size: 0
Dec  4 12:01:19 netlinux kernel:   size: 68
Dec  4 12:01:19 netlinux kernel:   f->nsize: 5
Dec  4 12:01:19 netlinux kernel:   f->size: 0
Dec  4 12:01:19 netlinux kernel:   node->data_offset: 0
Dec  4 12:01:19 netlinux kernel:   free_chunk_size1: 1041828
Dec  4 12:01:19 netlinux kernel:   free_chunk_size2: 6946816
Dec  4 12:01:19 netlinux kernel:   node->fm->offset: 0x006b0608
Dec  4 12:01:19 netlinux kernel: ***jffs_rewrite_data(): node: 1360, name: "spool", size: 0
Dec  4 12:01:19 netlinux kernel: jffs_fmalloc(): fmc = 0xc0818640, size = 68, node = 0xc0df5df0
Dec  4 12:01:19 netlinux kernel: jffs_fmalloc(): free_chunk_size1 = 1041828, free_chunk_size2 = 6946816
Dec  4 12:01:19 netlinux kernel: struct jffs_fmcontrol: 0xc0818640
Dec  4 12:01:19 netlinux kernel: {
Dec  4 12:01:19 netlinux kernel:         0x00000000, /* flash_start  */
Dec  4 12:01:19 netlinux kernel:         15204352, /* flash_size  */
Dec  4 12:01:19 netlinux kernel:         7006824, /* used_size  */
Dec  4 12:01:19 netlinux kernel:         208952, /* dirty_size  */
Dec  4 12:01:19 netlinux kernel:         7988576, /* free_size  */
Dec  4 12:01:23 netlinux kernel:         131072, /* sector_size  */
Dec  4 12:01:23 netlinux kernel:         262144, /* min_free_size  */
Dec  4 12:01:23 netlinux kernel:         65536, /* max_chunk_size  */
Dec  4 12:01:23 netlinux kernel:         0xc0094980, /* mtd  */
Dec  4 12:01:23 netlinux kernel:         0xc0e39160, /* head  */    (head->offset = 0x006a0000)
Dec  4 12:01:23 netlinux kernel:         0xc0e39970, /* tail  */    (tail->offset + tail->size = 0x00d81aa0)
Dec  4 12:01:23 netlinux kernel:         0x00000000, /* head_extra  */
Dec  4 12:01:23 netlinux kernel:         0x00000000, /* tail_extra  */
Dec  4 12:01:23 netlinux kernel: }
Dec  4 12:01:23 netlinux kernel: struct jffs_fm: 0xc0e39970
Dec  4 12:01:23 netlinux kernel: {
Dec  4 12:01:23 netlinux kernel:        0x00d81a5c, /* offset  */
Dec  4 12:01:23 netlinux kernel:        68, /* size  */
Dec  4 12:01:23 netlinux kernel:        0xc0e398e0, /* prev  */
Dec  4 12:01:23 netlinux kernel:        0x00000000, /* next  */
Dec  4 12:01:23 netlinux kernel:        0xc0e399a0, /* nodes  */
Dec  4 12:01:23 netlinux kernel: }
Dec  4 12:01:23 netlinux kernel: jffs_rewrite_data(): Writing this raw inode to pos 0x14162524l.
Dec  4 12:01:23 netlinux kernel: jffs_raw_inode: inode number: 1360
Dec  4 12:01:23 netlinux kernel: {
Dec  4 12:01:23 netlinux kernel:         0x34383931, /* magic  */
Dec  4 12:01:23 netlinux kernel:         0x00000550, /* ino  */
Dec  4 12:01:23 netlinux kernel:         0x00000543, /* pino  */
Dec  4 12:01:23 netlinux kernel:         0x00000002, /* version  */
Dec  4 12:01:23 netlinux kernel:         0x000041ed, /* mode  */
Dec  4 12:01:23 netlinux kernel:         0x0000,     /* uid  */
Dec  4 12:01:23 netlinux kernel:         0x0000,     /* gid  */
Dec  4 12:01:23 netlinux kernel:         0x3a27f650, /* atime  */
Dec  4 12:01:23 netlinux kernel:         0x39f812c6, /* mtime  */
Dec  4 12:01:23 netlinux kernel:         0x3a019819, /* ctime  */
Dec  4 12:01:23 netlinux kernel:         0x00000000, /* offset  */
Dec  4 12:01:23 netlinux kernel:         0x00000000, /* dsize  */
Dec  4 12:01:23 netlinux kernel:         0x00000000, /* rsize  */
Dec  4 12:01:23 netlinux kernel:         0x05,       /* nsize  */
Dec  4 12:01:23 netlinux kernel:         0x01,       /* nlink  */
Dec  4 12:01:23 netlinux kernel:         0x00,       /* spare  */
Dec  4 12:01:23 netlinux kernel:         0,          /* rename  */
Dec  4 12:01:23 netlinux kernel:         0,          /* deleted  */
Dec  4 12:01:23 netlinux kernel:         0xff,       /* accurate  */
Dec  4 12:01:23 netlinux kernel:         0x00000000, /* dchksum  */
Dec  4 12:01:23 netlinux kernel:         0x0000,     /* nchksum  */
Dec  4 12:01:23 netlinux kernel:         0x0000,     /* chksum  */
Dec  4 12:01:23 netlinux kernel: }
Dec  4 12:01:23 netlinux kernel: jffs_rewrite_data(): Writing name "spool" to pos 0x14162584l.
Dec  4 12:01:23 netlinux kernel: , result: 0x0000022d
Dec  4 12:01:23 netlinux kernel: , result: 0x00000774
Dec  4 12:01:23 netlinux kernel: jffs_insert_node(): ino = 1360, version = 2, name = "spool", deleted = 0
Dec  4 12:01:23 netlinux kernel: jffs_insert_node(): ---------------------------------------------------------------------- 1
Dec  4 12:01:23 netlinux kernel: jffs_remove_redundant_nodes(): ino: 1360, name: "spool", newest_type: 3
Dec  4 12:01:23 netlinux kernel: jffs_remove_redundant_nodes(): Removing node: ino: 1360, version: 1, mod_type: 3
Dec  4 12:01:23 netlinux kernel: jffs_fmfree(): node->ino = 1360, node->version = 1
Dec  4 12:01:23 netlinux kernel: jffs_insert_node(): ---------------------------------------------------------------------- 2
Dec  4 12:01:23 netlinux kernel: jffs_rewrite_data(): Leaving...
Dec  4 12:01:23 netlinux kernel: jffs_garbage_collect_next: Leaving...
Dec  4 12:01:27 netlinux kernel: ***jffs_garbage_collect_thread(): round #1502, fmc->dirty_size = 209020
Dec  4 12:01:27 netlinux kernel: struct jffs_fmcontrol: 0xc0818640
Dec  4 12:01:27 netlinux kernel: {
Dec  4 12:01:27 netlinux kernel:         0x00000000, /* flash_start  */
Dec  4 12:01:27 netlinux kernel:         15204352, /* flash_size  */
Dec  4 12:01:27 netlinux kernel:         7006756, /* used_size  */
Dec  4 12:01:27 netlinux kernel:         209020, /* dirty_size  */
Dec  4 12:01:27 netlinux kernel:         7988576, /* free_size  */
Dec  4 12:01:27 netlinux kernel:         131072, /* sector_size  */
Dec  4 12:01:27 netlinux kernel:         262144, /* min_free_size  */
Dec  4 12:01:27 netlinux kernel:         65536, /* max_chunk_size  */
Dec  4 12:01:27 netlinux kernel:         0xc0094980, /* mtd  */
Dec  4 12:01:27 netlinux kernel:         0xc0e39160, /* head  */    (head->offset = 0x006a0000)
Dec  4 12:01:27 netlinux kernel:         0xc0e39970, /* tail  */    (tail->offset + tail->size = 0x00d81aa0)
Dec  4 12:01:27 netlinux kernel:         0x00000000, /* head_extra  */
Dec  4 12:01:27 netlinux kernel:         0x00000000, /* tail_extra  */
Dec  4 12:01:27 netlinux kernel: }
Dec  4 12:01:27 netlinux kernel: jffs_try_to_erase()
Dec  4 12:01:27 netlinux kernel: jffs_try_to_erase(): erase_size = 0
Dec  4 12:01:27 netlinux kernel: jffs_get_oldest_node(): ino = 1361, version = 1
Dec  4 12:01:27 netlinux kernel: jffs_find_file(): ino: 1361
Dec  4 12:01:27 netlinux kernel: jffs_find_file(): Found file with ino 1361. (name: "tmp")
Dec  4 12:01:27 netlinux kernel: jffs_garbage_collect_next(): "tmp", ino: 1361, version: 1, location 0x6b064c, dsize 0
Dec  4 12:01:27 netlinux kernel:   total_name_size: 4
Dec  4 12:01:27 netlinux kernel:   data_size: 0
Dec  4 12:01:27 netlinux kernel:   size: 64
Dec  4 12:01:27 netlinux kernel:   f->nsize: 3
Dec  4 12:01:27 netlinux kernel:   f->size: 0
Dec  4 12:01:27 netlinux kernel:   node->data_offset: 0
Dec  4 12:01:27 netlinux kernel:   free_chunk_size1: 1041760
Dec  4 12:01:27 netlinux kernel:   free_chunk_size2: 6946816
Dec  4 12:01:27 netlinux kernel:   node->fm->offset: 0x006b064c
Dec  4 12:01:27 netlinux kernel: ***jffs_rewrite_data(): node: 1361, name: "tmp", size: 0
Dec  4 12:01:27 netlinux kernel: jffs_fmalloc(): fmc = 0xc0818640, size = 64, node = 0xc0df5e40
Dec  4 12:01:27 netlinux kernel: jffs_fmalloc(): free_chunk_size1 = 1041760, free_chunk_size2 = 6946816
Dec  4 12:01:27 netlinux kernel: struct jffs_fmcontrol: 0xc0818640
Dec  4 12:01:27 netlinux kernel: {
Dec  4 12:01:27 netlinux kernel:         0x00000000, /* flash_start  */
Dec  4 12:01:27 netlinux kernel:         15204352, /* flash_size  */
Dec  4 12:01:27 netlinux kernel:         7006820, /* used_size  */
Dec  4 12:01:27 netlinux kernel:         209020, /* dirty_size  */
Dec  4 12:01:27 netlinux kernel:         7988512, /* free_size  */
Dec  4 12:01:27 netlinux kernel:         131072, /* sector_size  */
Dec  4 12:01:27 netlinux kernel:         262144, /* min_free_size  */
Dec  4 12:01:27 netlinux kernel:         65536, /* max_chunk_size  */
Dec  4 12:01:27 netlinux kernel:         0xc0094980, /* mtd  */
Dec  4 12:01:27 netlinux kernel:         0xc0e39160, /* head  */    (head->offset = 0x006a0000)
Dec  4 12:01:27 netlinux kernel:         0xc0e39a00, /* tail  */    (tail->offset + tail->size = 0x00d81ae0)
Dec  4 12:01:27 netlinux kernel:         0x00000000, /* head_extra  */
Dec  4 12:01:27 netlinux kernel:         0x00000000, /* tail_extra  */
Dec  4 12:01:27 netlinux kernel: }
Dec  4 12:01:27 netlinux kernel: struct jffs_fm: 0xc0e39a00
Dec  4 12:01:27 netlinux kernel: {
Dec  4 12:01:27 netlinux kernel:        0x00d81aa0, /* offset  */
Dec  4 12:01:27 netlinux kernel:        64, /* size  */
Dec  4 12:01:31 netlinux kernel:        0xc0e39970, /* prev  */
Dec  4 12:01:31 netlinux kernel:        0x00000000, /* next  */
Dec  4 12:01:31 netlinux kernel:        0xc0e39a30, /* nodes  */
Dec  4 12:01:31 netlinux kernel: }
Dec  4 12:01:31 netlinux kernel: jffs_rewrite_data(): Writing this raw inode to pos 0x14162592l.
Dec  4 12:01:31 netlinux kernel: jffs_raw_inode: inode number: 1361
Dec  4 12:01:31 netlinux kernel: {
Dec  4 12:01:31 netlinux kernel:         0x34383931, /* magic  */
Dec  4 12:01:31 netlinux kernel:         0x00000551, /* ino  */
Dec  4 12:01:31 netlinux kernel:         0x00000543, /* pino  */
Dec  4 12:01:31 netlinux kernel:         0x00000002, /* version  */
Dec  4 12:01:31 netlinux kernel:         0x000041ed, /* mode  */
Dec  4 12:01:31 netlinux kernel:         0x0000,     /* uid  */
Dec  4 12:01:31 netlinux kernel:         0x0000,     /* gid  */
Dec  4 12:01:31 netlinux kernel:         0x3a27f650, /* atime  */
Dec  4 12:01:31 netlinux kernel:         0x39f812c6, /* mtime  */
Dec  4 12:01:31 netlinux kernel:         0x3a019819, /* ctime  */
Dec  4 12:01:31 netlinux kernel:         0x00000000, /* offset  */
Dec  4 12:01:31 netlinux kernel:         0x00000000, /* dsize  */
Dec  4 12:01:31 netlinux kernel:         0x00000000, /* rsize  */
Dec  4 12:01:31 netlinux kernel:         0x03,       /* nsize  */
Dec  4 12:01:31 netlinux kernel:         0x01,       /* nlink  */
Dec  4 12:01:31 netlinux kernel:         0x00,       /* spare  */
Dec  4 12:01:31 netlinux kernel:         0,          /* rename  */
Dec  4 12:01:31 netlinux kernel:         0,          /* deleted  */
Dec  4 12:01:31 netlinux kernel:         0xff,       /* accurate  */
Dec  4 12:01:31 netlinux kernel:         0x00000000, /* dchksum  */
Dec  4 12:01:31 netlinux kernel:         0x0000,     /* nchksum  */
Dec  4 12:01:31 netlinux kernel:         0x0000,     /* chksum  */
Dec  4 12:01:31 netlinux kernel: }
Dec  4 12:01:31 netlinux kernel: jffs_rewrite_data(): Writing name "tmp" to pos 0x14162652l.
Dec  4 12:01:31 netlinux kernel: , result: 0x00000151
Dec  4 12:01:31 netlinux kernel: , result: 0x00000796
Dec  4 12:01:31 netlinux kernel: jffs_insert_node(): ino = 1361, version = 2, name = "tmp", deleted = 0
Dec  4 12:01:31 netlinux kernel: jffs_insert_node(): ---------------------------------------------------------------------- 1
Dec  4 12:01:31 netlinux kernel: jffs_remove_redundant_nodes(): ino: 1361, name: "tmp", newest_type: 3
Dec  4 12:01:31 netlinux kernel: jffs_remove_redundant_nodes(): Removing node: ino: 1361, version: 1, mod_type: 3
Dec  4 12:01:31 netlinux kernel: jffs_fmfree(): node->ino = 1361, node->version = 1
Dec  4 12:01:31 netlinux kernel: jffs_insert_node(): ---------------------------------------------------------------------- 2
Dec  4 12:01:31 netlinux kernel: jffs_rewrite_data(): Leaving...
Dec  4 12:01:31 netlinux kernel: jffs_garbage_collect_next: Leaving...
Dec  4 12:01:31 netlinux kernel: ***jffs_garbage_collect_thread(): round #1503, fmc->dirty_size = 209084
Dec  4 12:01:31 netlinux kernel: struct jffs_fmcontrol: 0xc0818640
Dec  4 12:01:31 netlinux kernel: {
Dec  4 12:01:31 netlinux kernel:         0x00000000, /* flash_start  */
Dec  4 12:01:31 netlinux kernel:         15204352, /* flash_size  */
Dec  4 12:01:31 netlinux kernel:         7006756, /* used_size  */
Dec  4 12:01:31 netlinux kernel:         209084, /* dirty_size  */
Dec  4 12:01:31 netlinux kernel:         7988512, /* free_size  */
Dec  4 12:01:31 netlinux kernel:         131072, /* sector_size  */
Dec  4 12:01:31 netlinux kernel:         262144, /* min_free_size  */
Dec  4 12:01:31 netlinux kernel:         65536, /* max_chunk_size  */
Dec  4 12:01:31 netlinux kernel:         0xc0094980, /* mtd  */
Dec  4 12:01:31 netlinux kernel:         0xc0e39160, /* head  */    (head->offset = 0x006a0000)
Dec  4 12:01:35 netlinux kernel:         0xc0e39a00, /* tail  */    (tail->offset + tail->size = 0x00d81ae0)
Dec  4 12:01:35 netlinux kernel:         0x00000000, /* head_extra  */
Dec  4 12:01:35 netlinux kernel:         0x00000000, /* tail_extra  */
Dec  4 12:01:35 netlinux kernel: }
Dec  4 12:01:35 netlinux kernel: jffs_try_to_erase()
Dec  4 12:01:35 netlinux kernel: jffs_try_to_erase(): erase_size = 0
Dec  4 12:01:35 netlinux kernel: jffs_get_oldest_node(): ino = 1362, version = 1
Dec  4 12:01:35 netlinux kernel: jffs_find_file(): ino: 1362
Dec  4 12:01:35 netlinux kernel: jffs_find_file(): Found file with ino 1362. (name: "tst")
Dec  4 12:01:35 netlinux kernel: jffs_garbage_collect_next(): "tst", ino: 1362, version: 1, location 0x6b068c, dsize 0
Dec  4 12:01:35 netlinux kernel:   total_name_size: 4
Dec  4 12:01:35 netlinux kernel:   data_size: 0
Dec  4 12:01:35 netlinux kernel:   size: 64
Dec  4 12:01:35 netlinux kernel:   f->nsize: 3
Dec  4 12:01:35 netlinux kernel:   f->size: 0
Dec  4 12:01:35 netlinux kernel:   node->data_offset: 0
Dec  4 12:01:35 netlinux kernel:   free_chunk_size1: 1041696
Dec  4 12:01:35 netlinux kernel:   free_chunk_size2: 6946816
Dec  4 12:01:35 netlinux kernel:   node->fm->offset: 0x006b068c
Dec  4 12:01:35 netlinux kernel: ***jffs_rewrite_data(): node: 1362, name: "tst", size: 0
Dec  4 12:01:35 netlinux kernel: jffs_fmalloc(): fmc = 0xc0818640, size = 64, node = 0xc0df5e90
Dec  4 12:01:35 netlinux kernel: jffs_fmalloc(): free_chunk_size1 = 1041696, free_chunk_size2 = 6946816
Dec  4 12:01:35 netlinux kernel: struct jffs_fmcontrol: 0xc0818640
Dec  4 12:01:35 netlinux kernel: {
Dec  4 12:01:35 netlinux kernel:         0x00000000, /* flash_start  */
Dec  4 12:01:35 netlinux kernel:         15204352, /* flash_size  */
Dec  4 12:01:35 netlinux kernel:         7006820, /* used_size  */
Dec  4 12:01:35 netlinux kernel:         209084, /* dirty_size  */
Dec  4 12:01:35 netlinux kernel:         7988448, /* free_size  */
Dec  4 12:01:35 netlinux kernel:         131072, /* sector_size  */
Dec  4 12:01:35 netlinux kernel:         262144, /* min_free_size  */
Dec  4 12:01:35 netlinux kernel:         65536, /* max_chunk_size  */
Dec  4 12:01:35 netlinux kernel:         0xc0094980, /* mtd  */
Dec  4 12:01:35 netlinux kernel:         0xc0e39160, /* head  */    (head->offset = 0x006a0000)
Dec  4 12:01:35 netlinux kernel:         0xc0e39a90, /* tail  */    (tail->offset + tail->size = 0x00d81b20)
Dec  4 12:01:35 netlinux kernel:         0x00000000, /* head_extra  */
Dec  4 12:01:35 netlinux kernel:         0x00000000, /* tail_extra  */
Dec  4 12:01:35 netlinux kernel: }
Dec  4 12:01:35 netlinux kernel: struct jffs_fm: 0xc0e39a90
Dec  4 12:01:35 netlinux kernel: {
Dec  4 12:01:35 netlinux kernel:        0x00d81ae0, /* offset  */
Dec  4 12:01:35 netlinux kernel:        64, /* size  */
Dec  4 12:01:35 netlinux kernel:        0xc0e39a00, /* prev  */
Dec  4 12:01:35 netlinux kernel:        0x00000000, /* next  */
Dec  4 12:01:35 netlinux kernel:        0xc0e39ac0, /* nodes  */
Dec  4 12:01:35 netlinux kernel: }
Dec  4 12:01:35 netlinux kernel: jffs_rewrite_data(): Writing this raw inode to pos 0x14162656l.
Dec  4 12:01:35 netlinux kernel: jffs_raw_inode: inode number: 1362
Dec  4 12:01:35 netlinux kernel: {
Dec  4 12:01:35 netlinux kernel:         0x34383931, /* magic  */
Dec  4 12:01:35 netlinux kernel:         0x00000552, /* ino  */
Dec  4 12:01:35 netlinux kernel:         0x00000001, /* pino  */
Dec  4 12:01:35 netlinux kernel:         0x00000002, /* version  */
Dec  4 12:01:35 netlinux kernel:         0x000041ed, /* mode  */
Dec  4 12:01:35 netlinux kernel:         0x0000,     /* uid  */
Dec  4 12:01:35 netlinux kernel:         0x0000,     /* gid  */
Dec  4 12:01:39 netlinux kernel:         0x3a27f650, /* atime  */
Dec  4 12:01:39 netlinux kernel:         0x39f95ce9, /* mtime  */
Dec  4 12:01:39 netlinux kernel:         0x3a019819, /* ctime  */
Dec  4 12:01:39 netlinux kernel:         0x00000000, /* offset  */
Dec  4 12:01:39 netlinux kernel:         0x00000000, /* dsize  */
Dec  4 12:01:39 netlinux kernel:         0x00000000, /* rsize  */
Dec  4 12:01:39 netlinux kernel:         0x03,       /* nsize  */
Dec  4 12:01:39 netlinux kernel:         0x01,       /* nlink  */
Dec  4 12:01:39 netlinux kernel:         0x00,       /* spare  */
Dec  4 12:01:39 netlinux kernel:         0,          /* rename  */
Dec  4 12:01:39 netlinux kernel:         0,          /* deleted  */
Dec  4 12:01:39 netlinux kernel:         0xff,       /* accurate  */
Dec  4 12:01:39 netlinux kernel:         0x00000000, /* dchksum  */
Dec  4 12:01:39 netlinux kernel:         0x0000,     /* nchksum  */
Dec  4 12:01:39 netlinux kernel:         0x0000,     /* chksum  */
Dec  4 12:01:39 netlinux kernel: }
Dec  4 12:01:39 netlinux kernel: jffs_rewrite_data(): Writing name "tst" to pos 0x14162716l.
Dec  4 12:01:39 netlinux kernel: , result: 0x0000015b
Dec  4 12:01:39 netlinux kernel: , result: 0x000007c8
Dec  4 12:01:39 netlinux kernel: jffs_insert_node(): ino = 1362, version = 2, name = "tst", deleted = 0
Dec  4 12:01:39 netlinux kernel: jffs_insert_node(): ---------------------------------------------------------------------- 1
Dec  4 12:01:39 netlinux kernel: jffs_remove_redundant_nodes(): ino: 1362, name: "tst", newest_type: 3
Dec  4 12:01:39 netlinux kernel: jffs_remove_redundant_nodes(): Removing node: ino: 1362, version: 1, mod_type: 3
Dec  4 12:01:39 netlinux kernel: jffs_fmfree(): node->ino = 1362, node->version = 1
Dec  4 12:01:39 netlinux kernel: jffs_insert_node(): ---------------------------------------------------------------------- 2
Dec  4 12:01:39 netlinux kernel: jffs_rewrite_data(): Leaving...
Dec  4 12:01:39 netlinux kernel: jffs_garbage_collect_next: Leaving...
Dec  4 12:01:39 netlinux kernel: ***jffs_garbage_collect_thread(): round #1504, fmc->dirty_size = 209148
Dec  4 12:01:39 netlinux kernel: struct jffs_fmcontrol: 0xc0818640
Dec  4 12:01:39 netlinux kernel: {
Dec  4 12:01:39 netlinux kernel:         0x00000000, /* flash_start  */
Dec  4 12:01:39 netlinux kernel:         15204352, /* flash_size  */
Dec  4 12:01:39 netlinux kernel:         7006756, /* used_size  */
Dec  4 12:01:39 netlinux kernel:         209148, /* dirty_size  */
Dec  4 12:01:39 netlinux kernel:         7988448, /* free_size  */
Dec  4 12:01:39 netlinux kernel:         131072, /* sector_size  */
Dec  4 12:01:39 netlinux kernel:         262144, /* min_free_size  */
Dec  4 12:01:39 netlinux kernel:         65536, /* max_chunk_size  */
Dec  4 12:01:39 netlinux kernel:         0xc0094980, /* mtd  */
Dec  4 12:01:39 netlinux kernel:         0xc0e39160, /* head  */    (head->offset = 0x006a0000)
Dec  4 12:01:39 netlinux kernel:         0xc0e39a90, /* tail  */    (tail->offset + tail->size = 0x00d81b20)
Dec  4 12:01:39 netlinux kernDec  4 12:01:39 netlinux kernel:         0x00000000, /* tail_extra  */
Dec  4 12:01:39 netlinux kernel: }
Dec  4 12:01:39 netlinux kernel: jffs_try_to_erase()
Dec  4 12:01:39 netlinux kernel: jffs_try_to_erase(): erase_size = 131072

more first
Dec  4 12:16:27 netlinux kernel: jffs_readdir(): inode: 0xc0b0ccc0, filp: 0xc092ceb0
Dec  4 12:16:27 netlinux kernel: jffs_readdir(): "." 1243
Dec  4 12:16:27 netlinux kernel: jffs_readdir(): ".." 1
Dec  4 12:16:27 netlinux kernel: jffs_readdir(): "first" ino: 1363
Dec  4 12:16:27 netlinux kernel: jffs_readdir(): "d4test" ino: 1255
Dec  4 12:16:27 netlinux kernel: jffs_readdir(): "d3test" ino: 1252
Dec  4 12:16:27 netlinux kernel: jffs_readdir(): "d2test" ino: 1249
Dec  4 12:16:27 netlinux kernel: jffs_readdir(): "dtest" ino: 1246
Dec  4 12:16:27 netlinux kernel: jffs_readdir(): "lilo.conf" ino: 1245
Dec  4 12:16:27 netlinux kernel: jffs_readdir(): ".profile" ino: 1244
Dec  4 12:16:27 netlinux kernel: jffs_readdir(): inode: 0xc0b0ccc0, filp: 0xc092ceb0
Dec  4 12:16:28 netlinux kernel: ***jffs_readpage(): file = "first", page->offset = 0
Dec  4 12:16:28 netlinux kernel: jffs_read_data(): file = "first", read_offset = 0, size = 467
Dec  4 12:16:28 netlinux kernel:   jffs_get_node_data(): file: "first", ino: 1363, version: 2, node_offset: 0
Dec  4 12:16:28 netlinux kernel:   jffs_get_node_data(): Read 1 byte.
Dec  4 12:16:28 netlinux kernel:   jffs_get_node_data(): file: "first", ino: 1363, version: 3, node_offset: 0
Dec  4 12:16:28 netlinux kernel:   jffs_get_node_data(): Read 1 byte.
Dec  4 12:16:28 netlinux kernel:   jffs_get_node_data(): file: "first", ino: 1363, version: 4, node_offset: 0
Dec  4 12:16:28 netlinux kernel:   jffs_get_node_data(): Read 1 byte.
Dec  4 12:16:28 netlinux kernel:   jffs_get_node_data(): file: "first", ino: 1363, version: 5, node_offset: 0
Dec  4 12:16:28 netlinux kernel:   jffs_get_node_data(): Read 1 byte.
Dec  4 12:16:28 netlinux kernel:   jffs_get_node_data(): file: "first", ino: 1363, version: 6, node_offset: 0
Dec  4 12:16:28 netlinux kernel:   jffs_get_node_data(): Read 1 byte.
Dec  4 12:16:28 netlinux kernel:   jffs_get_node_data(): file: "first", ino: 1363, version: 7, node_offset: 0
Dec  4 12:16:28 netlinux kernel:   jffs_get_node_data(): Read 1 byte.
Dec  4 12:16:28 netlinux kernel:   jffs_get_node_data(): file: "first", ino: 1363, version: 8, node_offset: 0
Dec  4 12:16:28 netlinux kernel:   jffs_get_node_data(): Read 1 byte.
Dec  4 12:16:28 netlinux kernel:   jffs_get_node_data(): file: "first", ino: 1363, version: 9, node_offset: 0
Dec  4 12:16:28 netlinux kernel:   jffs_get_node_data(): Read 1 byte.
Dec  4 12:16:28 netlinux kernel:   jffs_get_node_data(): file: "first", ino: 1363, version: 10, node_offset: 0
Dec  4 12:16:28 netlinux kernel:   jffs_get_node_data(): Read 1 byte.
Dec  4 12:16:28 netlinux kernel:   jffs_get_node_data(): file: "first", ino: 1363, version: 11, node_offset: 0
Dec  4 12:16:28 netlinux kernel:   jffs_get_node_data(): Read 1 byte.
Dec  4 12:16:28 netlinux kernel:   jffs_get_node_data(): file: "first", ino: 1363, version: 12, node_offset: 0
Dec  4 12:16:28 netlinux kernel:   jffs_get_node_data(): Read 1 byte.
Dec  4 12:16:28 netlinux kernel:   jffs_get_node_data(): file: "first", ino: 1363, version: 13, node_offset: 0
Dec  4 12:16:28 netlinux kernel:   jffs_get_node_data(): Read 1 byte.
Dec  4 12:16:28 netlinux kernel:   jffs_get_node_data(): file: "first", ino: 1363, version: 14, node_offset: 0
Dec  4 12:16:28 netlinux kernel:   jffs_get_node_data(): Read 1 byte.
Dec  4 12:16:28 netlinux kernel:   jffs_get_node_data(): file: "first", ino: 1363, version: 15, node_offset: 0
Dec  4 12:16:28 netlinux kernel:   jffs_get_node_data(): Read 1 byte.
Dec  4 12:16:28 netlinux kernel:   jffs_get_node_data(): file: "first", ino: 1363, version: 16, node_offset: 0
Dec  4 12:16:28 netlinux kernel:   jffs_get_node_data(): Read 1 byte.
Dec  4 12:16:28 netlinux kernel:   jffs_get_node_data(): file: "first", ino: 1363, version: 17, node_offset: 0
Dec  4 12:16:28 netlinux kernel:   jffs_get_node_data(): Read 1 byte.
Dec  4 12:16:28 netlinux kernel:   jffs_get_node_data(): file: "first", ino: 1363, version: 18, node_offset: 0
Dec  4 12:16:28 netlinux kernel:   jffs_get_node_data(): Read 1 byte.
Dec  4 12:16:28 netlinux kernel:   jffs_get_node_data(): file: "first", ino: 1363, version: 19, node_offset: 0
Dec  4 12:16:28 netlinux kernel:   jffs_get_node_data(): Read 1 byte.
Dec  4 12:16:28 netlinux kernel:   jffs_get_node_data(): file: "first", ino: 1363, version: 20, node_offset: 0
Dec  4 12:16:28 netlinux kernel: Kernel panic: Didn't read all bytes in flash_safe_read(). Returned 0
Dec  4 12:16:28 netlinux kernel:


From LKhatskevitch at cachier.com  Mon Dec  4 14:52:34 2000
From: LKhatskevitch at cachier.com (Levi Khatskevitch)
Date: Mon, 4 Dec 2000 14:52:34 -0500
Subject: nftl/DoC Mill. root fs question
Message-ID: <00120414560502.15102@itidev1>

Hi,

My kernel mounts /dev/nftla1 as root with no problems however when I do

# mount

it reports that / is /dev/root device and not /dev/nftla1 what did I miss?
- Levi

-- 
Levi Khatskevitch
CTO
Cachier, Corp.
575 Grand St., Suite E306
New York, NY 10002


To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From nico at cam.org  Mon Dec  4 15:32:59 2000
From: nico at cam.org (Nicolas Pitre)
Date: Mon, 4 Dec 2000 15:32:59 -0500 (EST)
Subject: Odd behavior of JFFS with AMD chips - kernel panic!
In-Reply-To: <0FA1031B65A9D111960900805F9FA8E103B9F20D@txexmta8.amd.com>
Message-ID: <Pine.LNX.4.30.0012041525460.16670-100000@xanadu.gn.com>



On Mon, 4 Dec 2000 mark.langsdorf at amd.com wrote:

> I'm still working on diagnosising what's causing my problems
> with JFFS and MTD.
>
> I built a version of the Dec 3rd MTD code for my device, and
> booted the kernel.
>
> As far as I can tell, my device works fine with the char interface,
> and I was able to build a file system image and put it in flash
> using 'cat Flash.img > /dev/mtd2'
>
> mounting the flash system with 'mount -t jffs /dev/mtdblock2 /tst'
> also seemed to work.

Beware that /dev/mtd2 (char 90:2) and /dev/mtdblock2 (block 31:2) aren't
pointing to the same MTD object...

David --> This is really really misleading and non-intuitive.  Is there a
good reason to have a separate device node only for read-only access?


Nicolas



To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From rminnich at lanl.gov  Mon Dec  4 16:36:55 2000
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Mon, 4 Dec 2000 14:36:55 -0700 (MST)
Subject: nftl/DoC Mill. root fs question
In-Reply-To: <00120414560502.15102@itidev1>
Message-ID: <Pine.LNX.4.21.0012041436200.16124-100000@mini.acl.lanl.gov>

On Mon, 4 Dec 2000, Levi Khatskevitch wrote:

> it reports that / is /dev/root device and not /dev/nftla1 what did I miss?

This is unix foolishness. Mounts are kept in /etc/mtab. Since the file
system is readonly, this won't get fixed, since you can't update files in
/etc. 

ron



To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From tyson at rwii.com  Mon Dec  4 16:40:16 2000
From: tyson at rwii.com (tyson at rwii.com)
Date: Mon, 4 Dec 2000 16:40:16 -0500 (EST)
Subject: nftl/DoC Mill. root fs question
In-Reply-To: <Pine.LNX.4.21.0012041436200.16124-100000@mini.acl.lanl.gov>
Message-ID: <200012042140.QAA08601@server.rwii.com>

On  4 Dec, Ronald G Minnich wrote:
> On Mon, 4 Dec 2000, Levi Khatskevitch wrote:
> 
>> it reports that / is /dev/root device and not /dev/nftla1 what did I miss?
> 
> This is unix foolishness. Mounts are kept in /etc/mtab. Since the file
> system is readonly, this won't get fixed, since you can't update files in
> /etc. 
> 
> ron

I run systems with read-only file systems.  Among other thigs, we
symlink /etc/mtab to /proc/mounts.

Cheers!
Ty

-- 
Tyson D Sawyer                             iRobot Corporation
Senior Systems Engineer                    Real World Interface Div.
tsawyer at irobot.com                         Robots for the Real World
603-532-6900 ext 206                       http://www.irobot.com



To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From jan at cendio.se  Mon Dec  4 16:51:10 2000
From: jan at cendio.se (Jan Danielsson)
Date: Mon, 4 Dec 2000 22:51:10 +0100
Subject: nftl/DoC Mill. root fs question
In-Reply-To: <Pine.LNX.4.21.0012041436200.16124-100000@mini.acl.lanl.gov>
	(message from Ronald G Minnich on Mon, 4 Dec 2000 14:36:55 -0700
	(MST))
References: <Pine.LNX.4.21.0012041436200.16124-100000@mini.acl.lanl.gov>
Message-ID: <200012042151.WAA13296@localhost.localdomain>

If you use the proc filesystem: try to let "/etc/mtab" be a soft-link
to "/proc/mounts".

  --Jan


To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From nico at cam.org  Mon Dec  4 16:49:36 2000
From: nico at cam.org (Nicolas Pitre)
Date: Mon, 4 Dec 2000 16:49:36 -0500 (EST)
Subject: Odd behavior of JFFS with AMD chips - kernel panic!
In-Reply-To: <Pine.LNX.4.30.0012041525460.16670-100000@xanadu.gn.com>
Message-ID: <Pine.LNX.4.30.0012041646241.16670-100000@xanadu.gn.com>



On Mon, 4 Dec 2000, Nicolas Pitre wrote:

> Beware that /dev/mtd2 (char 90:2) and /dev/mtdblock2 (block 31:2) aren't
> pointing to the same MTD object...

I'm apparently on drugs...

I just discovered mtd/util/MAKEDEV, and it apparently contains:

for a in `seq 0 16` ; do
        mknod /dev/mtd$a c 90 `expr $a + $a`
        mknod /dev/mtdr$a c 90 `expr $a + $a + 1`
        mknod /dev/mtdblock$a b 31 $a
done

Sorry for being stupid.


Nicolas



To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From LKhatskevitch at cachier.com  Mon Dec  4 17:05:49 2000
From: LKhatskevitch at cachier.com (Levi Khatskevitch)
Date: Mon, 4 Dec 2000 17:05:49 -0500
Subject: nftl/DoC Mill. root fs question
In-Reply-To: <200012042140.QAA08601@server.rwii.com>
References: <200012042140.QAA08601@server.rwii.com>
Message-ID: <00120417072203.15102@mrserver>

On Mon, 04 Dec 2000, tyson at rwii.com wrote:
> On  4 Dec, Ronald G Minnich wrote:
> > On Mon, 4 Dec 2000, Levi Khatskevitch wrote:
> > 
> >> it reports that / is /dev/root device and not /dev/nftla1 what did I miss?
> > 
> > This is unix foolishness. Mounts are kept in /etc/mtab. Since the file
> > system is readonly, this won't get fixed, since you can't update files in
> > /etc. 
> > 
> > ron
> 
> I run systems with read-only file systems.  Among other thigs, we
> symlink /etc/mtab to /proc/mounts.
> 
> Cheers!
> Ty
> 

tried that, doesn't change anything
- Levi

-- 
Levi Khatskevitch
CTO
Cachier, Corp.
575 Grand St., Suite E306
New York, NY 10002


To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From LKhatskevitch at cachier.com  Mon Dec  4 17:08:11 2000
From: LKhatskevitch at cachier.com (Levi Khatskevitch)
Date: Mon, 4 Dec 2000 17:08:11 -0500
Subject: nftl/DoC Mill. root fs question
In-Reply-To: <200012042151.WAA13296@localhost.localdomain>
References: <Pine.LNX.4.21.0012041436200.16124-100000@mini.acl.lanl.gov> <200012042151.WAA13296@localhost.localdomain>
Message-ID: <00120417114204.15102@mrserver>

On Mon, 04 Dec 2000, Jan Danielsson wrote:
> If you use the proc filesystem: try to let "/etc/mtab" be a soft-link
> to "/proc/mounts".
> 
>   --Jan

/proc/mounts says the same thing (/dev/root)
- Levi

-- 
Levi Khatskevitch
CTO
Cachier, Corp.
575 Grand St., Suite E306
New York, NY 10002


To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From Relativity at HumanHeuristic.com  Mon Dec  4 17:36:59 2000
From: Relativity at HumanHeuristic.com (Ian)
Date: Tue, 5 Dec 2000 08:36:59 +1000
Subject: Problems with r/w on mtdblock0
Message-ID: <200012042236.IAA16219@singularity.tronunltd.com>



  Have I done something wrong to get this error?

    bash# dd if=/dev/zero of=/dev/mtdblock0 bs=512 count=1
    end_request: I/O error, dev 1f:00 (mtdblock), sector 0
    dd: /dev/mtdblock0: Input/output error
    1+0 records in
    0+0 records out

    bash# /bin/dd if=/dev/mtdblock0 of=/dev/null bs=512 count=1
    end_request: I/O error, dev 1f:00 (mtdblock), sector 0
    /bin/dd: /dev/mtdblock0: Input/output error
    0+0 records in
    0+0 records out


  I have no problems reading and writing to nftla on my DoC Millennium ... just
not the block device.

  NB: I'm trying to use the block device, because dd'ing to the first and second
512bytes of the character device, while appearing successful,  does not "stick".
A hexdump immediately after a dd shows no sign of the dd data.

  Note, too, that dd'ing to a non existent DoC yields a different error;
    bash# /bin/dd if=/dev/mtdblock1 of=/dev/null bs=512 count=1
    /bin/dd: /dev/mtdblock1: No such device

    brw-r--r--   1 root     root      31,   0 Dec  4 20:14 /dev/mtdblock0
    brw-r--r--   1 root     root      31,   1 Dec  4 20:14 /dev/mtdblock1


Erm;
    bash# cat  /proc/mtd
    mtd0: 00800000 "DiskOnChip Millennium"

is that supposed to be the memory location for the DoC ?


Boot process  (My DoC drivers are compiled internally to the kernel, *not* as modules)
    Initializing MTD Layer
    M-Systems DiskOnChip driver. (C) 1999 Machine Vision Holdings, Inc.
    DiskOnChip Millennium found at address 0xDC000
    Flash chip found: Manufacture ID: 98, Chip ID: E6 (Toshiba TC58V64AFT/DC)
    1 flash chips found. Total DiskOnChip size: 8 Mbytes




--
http://HumanHeuristic.com/
"Bringing people together in a world full of computers"



To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From Relativity at HumanHeuristic.com  Mon Dec  4 19:42:34 2000
From: Relativity at HumanHeuristic.com (Ian)
Date: Tue, 5 Dec 2000 10:42:34 +1000
Subject: Problems with r/w on mtdblock0
Message-ID: <200012050042.KAA16622@singularity.tronunltd.com>




I can also confirm that this problem exists when compiled as modules (and also with
the #define DOC_SINGLE_DRIVER commented out).


It isn't recent.  Before this mornings attempts I was using a CVS from about 4-5days 
ago and it was in that bundle that I noticed it (I'm pretty sure it was pre the combo
mods that Ollie did)



  ----- Original Message -----
>From: "Ian" <Relativity at humanheuristic.com>
>To: <mtd at infradead.org>
>Subject:  Problems with r/w on mtdblock0
>Date: Tue, 05 Dec 2000 08:36:59 +1000
>
> 
> 
>   Have I done something wrong to get this error?
> 
>     bash# dd if=/dev/zero of=/dev/mtdblock0 bs=512 count=1
>     end_request: I/O error, dev 1f:00 (mtdblock), sector 0
>     dd: /dev/mtdblock0: Input/output error
>     1+0 records in
>     0+0 records out
> 
>     bash# /bin/dd if=/dev/mtdblock0 of=/dev/null bs=512 count=1
>     end_request: I/O error, dev 1f:00 (mtdblock), sector 0
>     /bin/dd: /dev/mtdblock0: Input/output error
>     0+0 records in
>     0+0 records out
> 
> 
>   I have no problems reading and writing to nftla on my DoC Millennium ... just
> not the block device.
> 
>   NB: I'm trying to use the block device, because dd'ing to the first and second
> 512bytes of the character device, while appearing successful,  does not "stick".
> A hexdump immediately after a dd shows no sign of the dd data.
> 
>   Note, too, that dd'ing to a non existent DoC yields a different error;
>     bash# /bin/dd if=/dev/mtdblock1 of=/dev/null bs=512 count=1
>     /bin/dd: /dev/mtdblock1: No such device
> 
>     brw-r--r--   1 root     root      31,   0 Dec  4 20:14 /dev/mtdblock0
>     brw-r--r--   1 root     root      31,   1 Dec  4 20:14 /dev/mtdblock1
> 
> 
> Erm;
>     bash# cat  /proc/mtd
>     mtd0: 00800000 "DiskOnChip Millennium"
> 
> is that supposed to be the memory location for the DoC ?
> 
> 
> Boot process  (My DoC drivers are compiled internally to the kernel, *not* as modules)
>     Initializing MTD Layer
>     M-Systems DiskOnChip driver. (C) 1999 Machine Vision Holdings, Inc.
>     DiskOnChip Millennium found at address 0xDC000
>     Flash chip found: Manufacture ID: 98, Chip ID: E6 (Toshiba TC58V64AFT/DC)
>     1 flash chips found. Total DiskOnChip size: 8 Mbytes
> 
> 
> 
> 
> --
> http://HumanHeuristic.com/
> "Bringing people together in a world full of computers"
> 
> 
> 
> To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org
> 

--
http://HumanHeuristic.com/
"Bringing people together in a world full of computers"



To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From ollie at sis.com.tw  Mon Dec  4 20:10:11 2000
From: ollie at sis.com.tw (Ollie Lho)
Date: Tue, 05 Dec 2000 09:10:11 +0800
Subject: Problems with r/w on mtdblock0
References: <200012042236.IAA16219@singularity.tronunltd.com>
Message-ID: <3A2C4073.8AA079B3@sis.com.tw>

Ian wrote:
> 
>   Have I done something wrong to get this error?
> 
>     bash# dd if=/dev/zero of=/dev/mtdblock0 bs=512 count=1
>     end_request: I/O error, dev 1f:00 (mtdblock), sector 0
>     dd: /dev/mtdblock0: Input/output error
>     1+0 records in
>     0+0 records out
> 
>     bash# /bin/dd if=/dev/mtdblock0 of=/dev/null bs=512 count=1
>     end_request: I/O error, dev 1f:00 (mtdblock), sector 0
>     /bin/dd: /dev/mtdblock0: Input/output error
>     0+0 records in
>     0+0 records out
> 
>   I have no problems reading and writing to nftla on my DoC Millennium ... just
> not the block device.
> 

Ian,
	The /dev/mtdblockN device the the "block device" node for MTD devices.
In the DoC case, it can only read/write data in 8KB block (the erase size).
You can not read/write 512B on itm it will get "cached" by the driver. If
you are playing with the IPL stuff, WRITE TO /dev/mtd0.

Ollie


To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From Relativity at HumanHeuristic.com  Mon Dec  4 20:54:44 2000
From: Relativity at HumanHeuristic.com (Ian)
Date: Tue, 5 Dec 2000 11:54:44 +1000
Subject: Problems with r/w on mtdblock0
Message-ID: <200012050154.LAA16910@singularity.tronunltd.com>



I am a scumbag.  I have just re-run it up as modules and redone my test, and the data *is* 
sticking .. and *is* surviving reboots.  I have no idea how it failed my previous test 
(considering I'm using the same test scripts and configs).


I apologise profusely for this tripe .. and will retest my "inbuilt" scenario aswell ...  


<whipping back with rosaries>
 I will not post to public mailling lists after 18hours of programming ..
 I will not post to public mailling lists after 18hours of programming ..
 I will not post to public mailling lists after 18hours of programming ..
  <etc ad nauseum>


If the inbuilt stuff isn't problematic, then I'll go back to Hamish's suggestions ..

'night.


  ----- Original Message -----
>From: "Ian" <Relativity at humanheuristic.com>
>To: <mtd at infradead.org>
>Subject:  Re: Problems with r/w on mtdblock0
>Date: Tue, 05 Dec 2000 10:42:34 +1000
>
> 
> 
> 
> I can also confirm that this problem exists when compiled as modules (and also with
> the #define DOC_SINGLE_DRIVER commented out).
> 
> 
> It isn't recent.  Before this mornings attempts I was using a CVS from about 4-5days 
> ago and it was in that bundle that I noticed it (I'm pretty sure it was pre the combo
> mods that Ollie did)
> 
> 
> 
>   ----- Original Message -----
> >From: "Ian" <Relativity at humanheuristic.com>
> >To: <mtd at infradead.org>
> >Subject:  Problems with r/w on mtdblock0
> >Date: Tue, 05 Dec 2000 08:36:59 +1000
> >
> > 
> > 
> >   Have I done something wrong to get this error?
> > 
> >     bash# dd if=/dev/zero of=/dev/mtdblock0 bs=512 count=1
> >     end_request: I/O error, dev 1f:00 (mtdblock), sector 0
> >     dd: /dev/mtdblock0: Input/output error
> >     1+0 records in
> >     0+0 records out
> > 
> >     bash# /bin/dd if=/dev/mtdblock0 of=/dev/null bs=512 count=1
> >     end_request: I/O error, dev 1f:00 (mtdblock), sector 0
> >     /bin/dd: /dev/mtdblock0: Input/output error
> >     0+0 records in
> >     0+0 records out
> > 
> > 
> >   I have no problems reading and writing to nftla on my DoC Millennium ... just
> > not the block device.
> > 
> >   NB: I'm trying to use the block device, because dd'ing to the first and second
> > 512bytes of the character device, while appearing successful,  does not "stick".
> > A hexdump immediately after a dd shows no sign of the dd data.
> > 
> >   Note, too, that dd'ing to a non existent DoC yields a different error;
> >     bash# /bin/dd if=/dev/mtdblock1 of=/dev/null bs=512 count=1
> >     /bin/dd: /dev/mtdblock1: No such device
> > 
> >     brw-r--r--   1 root     root      31,   0 Dec  4 20:14 /dev/mtdblock0
> >     brw-r--r--   1 root     root      31,   1 Dec  4 20:14 /dev/mtdblock1
> > 
> > 
> > Erm;
> >     bash# cat  /proc/mtd
> >     mtd0: 00800000 "DiskOnChip Millennium"
> > 
> > is that supposed to be the memory location for the DoC ?
> > 
> > 
> > Boot process  (My DoC drivers are compiled internally to the kernel, *not* as modules)
> >     Initializing MTD Layer
> >     M-Systems DiskOnChip driver. (C) 1999 Machine Vision Holdings, Inc.
> >     DiskOnChip Millennium found at address 0xDC000
> >     Flash chip found: Manufacture ID: 98, Chip ID: E6 (Toshiba TC58V64AFT/DC)
> >     1 flash chips found. Total DiskOnChip size: 8 Mbytes
> > 
> > 
> > 
> > 
> > --
> > http://HumanHeuristic.com/
> > "Bringing people together in a world full of computers"
> > 
> > 
> > 
> > To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org
> > 
> 
> --
> http://HumanHeuristic.com/
> "Bringing people together in a world full of computers"
> 
> 
> 
> To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org
> 

--
http://HumanHeuristic.com/
"Bringing people together in a world full of computers"



To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From dwmw2 at infradead.org  Tue Dec  5 04:03:04 2000
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 05 Dec 2000 09:03:04 +0000
Subject: Odd behavior of JFFS with AMD chips - kernel panic! 
In-Reply-To: <Pine.LNX.4.30.0012041525460.16670-100000@xanadu.gn.com> 
References: <Pine.LNX.4.30.0012041525460.16670-100000@xanadu.gn.com> 
Message-ID: <5734.976006984@redhat.com>


nico at cam.org said:
>  David --> This is really really misleading and non-intuitive.  Is
> there a good reason to have a separate device node only for read-only
> access?

No good reason. I inherited the device nodes from a previous driver - as
they're already been registered, it made sense at the time to use them as
they were.

I'm reluctant to change them now unless we register a new major number for
them, to prevent confusion. Changing them but keeping the same major# would
even bite the people who _did_ bother to read the documentation and/or run
the provided MAKEDEV script. :)

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From dwmw2 at infradead.org  Tue Dec  5 04:15:44 2000
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 05 Dec 2000 09:15:44 +0000
Subject: Problems with r/w on mtdblock0 
In-Reply-To: <200012050154.LAA16910@singularity.tronunltd.com> 
References: <200012050154.LAA16910@singularity.tronunltd.com> 
Message-ID: <7809.976007744@redhat.com>


Relativity at HumanHeuristic.com said:
> I am a scumbag.  I have just re-run it up as modules and redone my
> test, and the data *is*  sticking .. and *is* surviving reboots.  I
> have no idea how it failed my previous test  (considering I'm using
> the same test scripts and configs).

The way I normally program stuff into the DiskOnChip is with the 
'doc_loadbios' program - which uses the character device, does MEMERASE 
ioctls to make room for the image you tell it to load, then writes the 
image.



--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From nico at cam.org  Tue Dec  5 09:43:13 2000
From: nico at cam.org (Nicolas Pitre)
Date: Tue, 5 Dec 2000 09:43:13 -0500 (EST)
Subject: Odd behavior of JFFS with AMD chips - kernel panic! 
In-Reply-To: <5734.976006984@redhat.com>
Message-ID: <Pine.LNX.4.30.0012050937380.2601-100000@xanadu.gn.com>



On Tue, 5 Dec 2000, David Woodhouse wrote:

>
> nico at cam.org said:
> >  David --> This is really really misleading and non-intuitive.  Is
> > there a good reason to have a separate device node only for read-only
> > access?
>
> No good reason. I inherited the device nodes from a previous driver - as
> they're already been registered, it made sense at the time to use them as
> they were.

Well... At the time of my original inquiry my device nodes were as follows:
crw-rw-r--   1 root     root      90,   0 Dec  1 17:21 /dev/mtd0
crw-rw-r--   1 root     root      90,   1 Dec  1 17:21 /dev/mtd1
crw-rw-r--   1 root     root      90,   2 Dec  1 17:21 /dev/mtd2
crw-rw-r--   1 root     root      90,   3 Dec  1 17:21 /dev/mtd3
crw-rw-r--   1 root     root      90,   4 Dec  1 17:21 /dev/mtd4
crw-rw-r--   1 root     root      90,   5 Dec  1 17:21 /dev/mtd5

Now having discovered mtd/util/MAKEDEV things aren't as bad as before.

;-)


Nicolas



To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From rminnich at lanl.gov  Tue Dec  5 09:50:12 2000
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Tue, 5 Dec 2000 07:50:12 -0700 (MST)
Subject: Problems with r/w on mtdblock0
In-Reply-To: <200012050154.LAA16910@singularity.tronunltd.com>
Message-ID: <Pine.LNX.4.21.0012050749450.20717-100000@mini.acl.lanl.gov>

On Tue, 5 Dec 2000, Ian wrote:

> I have just re-run it up as modules and redone my test, and the data
> *is* sticking .. and *is* surviving reboots.  I have no idea how it
> failed my previous test (considering I'm using the same test scripts
> and configs).

I've had this happen. Don't worry about it. 

ron



To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From dwmw2 at infradead.org  Tue Dec  5 09:54:23 2000
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 05 Dec 2000 14:54:23 +0000
Subject: Problems with r/w on mtdblock0 
In-Reply-To: <Pine.LNX.4.21.0012050749450.20717-100000@mini.acl.lanl.gov> 
References: <Pine.LNX.4.21.0012050749450.20717-100000@mini.acl.lanl.gov> 
Message-ID: <32011.976028063@redhat.com>


rminnich at lanl.gov said:
>  I've had this happen. Don't worry about it.  

If you writing stuff to the mtdblock device and then reboot immediately, 
you may be rebooting before the kernel thread actually completes the write.
I'm not sure if it makes you wait on close() or not. P'raps it should.

Using doc_loadbios on the chardevice should be reliable.

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From nico at cam.org  Tue Dec  5 10:34:41 2000
From: nico at cam.org (Nicolas Pitre)
Date: Tue, 5 Dec 2000 10:34:41 -0500 (EST)
Subject: Problems with r/w on mtdblock0 
In-Reply-To: <32011.976028063@redhat.com>
Message-ID: <Pine.LNX.4.30.0012051034220.2601-100000@xanadu.gn.com>



On Tue, 5 Dec 2000, David Woodhouse wrote:

>
> rminnich at lanl.gov said:
> >  I've had this happen. Don't worry about it.
>
> If you writing stuff to the mtdblock device and then reboot immediately,
> you may be rebooting before the kernel thread actually completes the write.
> I'm not sure if it makes you wait on close() or not. P'raps it should.

It does.


Nicolas



To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From dwmw2 at infradead.org  Tue Dec  5 10:36:33 2000
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 05 Dec 2000 15:36:33 +0000
Subject: Problems with r/w on mtdblock0 
In-Reply-To: <Pine.LNX.4.30.0012051034220.2601-100000@xanadu.gn.com> 
References: <Pine.LNX.4.30.0012051034220.2601-100000@xanadu.gn.com> 
Message-ID: <8609.976030593@redhat.com>


nico at cam.org said:
>  It does.

OK, I revert to my previous stance of having no clue then :)

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From ian.nelson at echostar.com  Tue Dec  5 12:24:37 2000
From: ian.nelson at echostar.com (Ian S. Nelson)
Date: Tue, 05 Dec 2000 10:24:37 -0700
Subject: Possibly a FAQ or stupid question
Message-ID: <3A2D24D4.FC82D90D@echostar.com>

but is there an MTD how-to or anything?

I'm talking about a real idiot's guide, I'm just kind of hacking my way
through a project and I am rapidly approaching the time when I will need
a flash burner program.

Can I just dd to the flash?  Assuming that my AMD flash works with
CFI...

I've also skimmed the archives on JFFS,  any pros and cons vs. an initrd
and burning it in there linearly?  Right now my boot loader will boot
strap a kernel out of flash and then I hacked the kernel to scan for my
initrd in flash and it will decompress it and run, works like a champ
but I need a way to put a new initrd in there now.  Is JFFS compressed?
Can I set aside a few K at the end of flash for my boot loader and then
a few hundred at the beginning for my kernel and use JFFS in the middle?



thanks,
Ian



To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From dwmw2 at infradead.org  Tue Dec  5 12:30:03 2000
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 05 Dec 2000 17:30:03 +0000
Subject: Possibly a FAQ or stupid question 
In-Reply-To: <3A2D24D4.FC82D90D@echostar.com> 
References: <3A2D24D4.FC82D90D@echostar.com> 
Message-ID: <8883.976037403@redhat.com>


ian.nelson at echostar.com said:
> Can I just dd to the flash?  Assuming that my AMD flash works with CFI... 

No. you have to use the MEMERASE ioctl first. The doc_loadbios program in 
the utils directory of the CVS tree will do this for you. Ignore the name, 
which I should probably change - it's not just for the DiskOnChip.


ian.nelson at echostar.com said:
>  Right now my boot loader will boot strap a kernel out of flash and
> then I hacked the kernel to scan for my initrd in flash and it will
> decompress it and run, works like a champ but I need a way to put a
> new initrd in there now. 

That works. As RAM is cheaper than flash, it makes a lot of sense to do 
that, in the absence of a compressed writable flash filesystem.

> Is JFFS compressed? 

Not yet. Soon. Watch this space.

> Can I set aside a few K at the end of flash for my boot loader and then a
> few hundred at the beginning for my kernel and use JFFS in the middle?

Yep. You can muck about with the partitioning all you like.


--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From mpanetta at applianceware.com  Tue Dec  5 12:26:57 2000
From: mpanetta at applianceware.com (Mike Panetta)
Date: Tue, 5 Dec 2000 12:26:57 -0500
Subject: CVS MTD drivers -> latest devel kernel.
Message-ID: <20001205122657.A11201@tetsuo.applianceware.com>

If I want to use the latest CVS MTD drivers in the
latest (or not so latest 2.4.0-test10) kernel can
I just copy the kernel dir in cvs to linux/drivers/mtd?
I would of course move the old dir out of the way first
to save it...  The reason I ask is because if I
currently try to compile CVS MTD it complains
about the index field not being in struct mtd_info.
It is not in that struct, in the old kernel driver
but it obviously is in the new one (I checked).  
So it looks like the search path finds mtd.h from
my kernel instead of the include dir in the cvs
tree. 


TIA
Mike
-- 


To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From nico at cam.org  Tue Dec  5 13:42:42 2000
From: nico at cam.org (Nicolas Pitre)
Date: Tue, 5 Dec 2000 13:42:42 -0500 (EST)
Subject: Possibly a FAQ or stupid question 
In-Reply-To: <8883.976037403@redhat.com>
Message-ID: <Pine.LNX.4.30.0012051340230.2601-100000@xanadu.gn.com>



On Tue, 5 Dec 2000, David Woodhouse wrote:

>
> ian.nelson at echostar.com said:
> > Can I just dd to the flash?  Assuming that my AMD flash works with CFI...
>
> No. you have to use the MEMERASE ioctl first.

Well...  not if using /dev/mtdblock.

To update my kernel in flash I simply use

	cp zImage /dev/mtdblock1


Nicolas



To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From rminnich at lanl.gov  Tue Dec  5 14:38:58 2000
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Tue, 5 Dec 2000 12:38:58 -0700 (MST)
Subject: Problems with r/w on mtdblock0 
In-Reply-To: <8609.976030593@redhat.com>
Message-ID: <Pine.LNX.4.21.0012051238300.20717-100000@mini.acl.lanl.gov>

On Tue, 5 Dec 2000, David Woodhouse wrote:

> 
> nico at cam.org said:
> >  It does.
> 
> OK, I revert to my previous stance of having no clue then :)

I was confused too. All I can tell you is I have seen cases where the
write doesn't "stick".

ron



To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From Relativity at HumanHeuristic.com  Tue Dec  5 19:19:30 2000
From: Relativity at HumanHeuristic.com (Ian)
Date: Wed, 6 Dec 2000 10:19:30 +1000
Subject: Problems with r/w on mtdblock0
Message-ID: <200012060019.KAA19472@singularity.tronunltd.com>




Ok - I have more info (and I retract my self-scumbagging from yesterday :-)

  In the cases where you can "dd if=any_file of=/dev/mtd0 bs=512 count=1" and
get *no* change in the DoC content (verified with a "hexdump -v /dec/mtd0") ..
If you, instead, try a "doc_loadbios /dev/mtd0 any_file" you should see your 
"any_file" contents stick to /dev/mtd0's content.  See here, result of;

 #cat crt0.bin crt0.bin > bios
 #doc_loadbios /dev/mtd0 bios
 #hdexdump -v /dev/mtd0 | more
  0000000 69b0 80e6 0000 0000 0000 0000 0000 0000
  0000010 0000 0000 0000 0000 0000 0000 0000 0000
  0000020 0000 0000 0000 0000 0000 0000 0000 0000
  0000030 0000 0000 0000 0000 0000 0000 0000 0000
  0000040 0000 0000 0000 0000 0000 0000 0000 0000 
  0000050 0000 0000 0000 0000 0000 0000 0000 0000
  0000060 0000 0000 0000 0000 0000 0000 0000 0000
  0000070 0000 0000 0000 0000 0000 0000 0000 0000
  0000080 0000 0000 0000 0000 0000 0000 0000 0000
  0000090 0000 0000 0000 0000 0000 0000 0000 0000
  00000a0 0000 0000 0000 0000 0000 0000 0000 0000
  00000b0 0000 0000 0000 0000 0000 0000 0000 0000
  00000c0 0000 0000 0000 0000 0000 0000 0000 0000
  00000d0 0000 0000 0000 0000 0000 0000 0000 0000
  00000e0 0000 0000 0000 0000 0000 0000 0000 0000
  00000f0 0000 0000 0000 0000 0000 0000 0000 0000
  0000100 0000 0000 0000 0000 0000 0000 0000 0000
  0000110 0000 0000 0000 0000 0000 0000 0000 0000
  0000120 0000 0000 0000 0000 0000 0000 0000 0000
  0000130 0000 0000 0000 0000 0000 0000 0000 0000
  0000140 0000 0000 0000 0000 0000 0000 0000 0000
  0000150 0000 0000 0000 0000 0000 0000 0000 0000
  0000160 0000 0000 0000 0000 0000 0000 0000 0000
  0000170 0000 0000 0000 0000 0000 0000 0000 0000
  0000180 0000 0000 0000 0000 0000 0000 0000 0000
  0000190 0000 0000 0000 0000 0000 0000 0000 0000
  00001a0 0000 0000 0000 0000 0000 0000 0000 0000
  00001b0 0000 0000 0000 0000 0000 0000 0000 0000
  00001c0 0000 0000 0000 0000 0000 0000 0000 0000
  00001d0 0000 0000 0000 0000 0000 0000 0000 0000
  00001e0 0000 0000 0000 0000 0000 0000 0000 0000
  00001f0 00ea 0000 f4fe 0000 0000 0000 0000 ffff
  0000200 69b0 80e6 0000 0000 0000 0000 0000 0000
  0000210 0000 0000 0000 0000 0000 0000 0000 0000
  0000220 0000 0000 0000 0000 0000 0000 0000 0000
  0000230 0000 0000 0000 0000 0000 0000 0000 0000
  0000240 0000 0000 0000 0000 0000 0000 0000 0000
  0000250 0000 0000 0000 0000 0000 0000 0000 0000
  0000260 0000 0000 0000 0000 0000 0000 0000 0000
  0000270 0000 0000 0000 0000 0000 0000 0000 0000
  0000280 0000 0000 0000 0000 0000 0000 0000 0000
  0000290 0000 0000 0000 0000 0000 0000 0000 0000
  00002a0 0000 0000 0000 0000 0000 0000 0000 0000
  00002b0 0000 0000 0000 0000 0000 0000 0000 0000
  00002c0 0000 0000 0000 0000 0000 0000 0000 0000
  00002d0 0000 0000 0000 0000 0000 0000 0000 0000
  00002e0 0000 0000 0000 0000 0000 0000 0000 0000
  00002f0 0000 0000 0000 0000 0000 0000 0000 0000
  0000300 0000 0000 0000 0000 0000 0000 0000 0000
  0000310 0000 0000 0000 0000 0000 0000 0000 0000
  0000320 0000 0000 0000 0000 0000 0000 0000 0000
  0000330 0000 0000 0000 0000 0000 0000 0000 0000
  0000340 0000 0000 0000 0000 0000 0000 0000 0000
  0000350 0000 0000 0000 0000 0000 0000 0000 0000
  0000360 0000 0000 0000 0000 0000 0000 0000 0000
  0000370 0000 0000 0000 0000 0000 0000 0000 0000
  0000380 0000 0000 0000 0000 0000 0000 0000 0000
  0000390 0000 0000 0000 0000 0000 0000 0000 0000
  00003a0 0000 0000 0000 0000 0000 0000 0000 0000
  00003b0 0000 0000 0000 0000 0000 0000 0000 0000
  00003c0 0000 0000 0000 0000 0000 0000 0000 0000
  00003d0 0000 0000 0000 0000 0000 0000 0000 0000
  00003e0 0000 0000 0000 0000 0000 0000 0000 0000
  00003f0 00ea 0000 f4fe 0000 0000 0000 0000 ffff


However!  If you *then* do a dd and transfer any_other_file
into /dev/mtd0,  the new contents are logically "and"ed with
the old contents of /dev/mtd0.  Ie;


  #dd if=doc_loadbios of=/dev/mtd0 bs=512 count=2
  #hexdump -v /dev/mtd0 | more
  0000000 4130 0044 0000 0000 0000 0000 0000 0000
  0000010 0000 0000 0000 0000 0000 0000 0000 0000
  0000020 0000 0000 0000 0000 0000 0000 0000 0000
  0000030 0000 0000 0000 0000 0000 0000 0000 0000
  0000040 0000 0000 0000 0000 0000 0000 0000 0000
  0000050 0000 0000 0000 0000 0000 0000 0000 0000
  0000060 0000 0000 0000 0000 0000 0000 0000 0000
  0000070 0000 0000 0000 0000 0000 0000 0000 0000
  0000080 0000 0000 0000 0000 0000 0000 0000 0000
  0000090 0000 0000 0000 0000 0000 0000 0000 0000
  00000a0 0000 0000 0000 0000 0000 0000 0000 0000
  00000b0 0000 0000 0000 0000 0000 0000 0000 0000
  00000c0 0000 0000 0000 0000 0000 0000 0000 0000
  00000d0 0000 0000 0000 0000 0000 0000 0000 0000
  00000e0 0000 0000 0000 0000 0000 0000 0000 0000
  00000f0 0000 0000 0000 0000 0000 0000 0000 0000
  0000100 0000 0000 0000 0000 0000 0000 0000 0000
  0000110 0000 0000 0000 0000 0000 0000 0000 0000
  0000120 0000 0000 0000 0000 0000 0000 0000 0000
  0000130 0000 0000 0000 0000 0000 0000 0000 0000
  0000140 0000 0000 0000 0000 0000 0000 0000 0000
  0000150 0000 0000 0000 0000 0000 0000 0000 0000
  0000160 0000 0000 0000 0000 0000 0000 0000 0000
  0000170 0000 0000 0000 0000 0000 0000 0000 0000
  0000180 0000 0000 0000 0000 0000 0000 0000 0000
  0000190 0000 0000 0000 0000 0000 0000 0000 0000
  00001a0 0000 0000 0000 0000 0000 0000 0000 0000
  00001b0 0000 0000 0000 0000 0000 0000 0000 0000
  00001c0 0000 0000 0000 0000 0000 0000 0000 0000
  00001d0 0000 0000 0000 0000 0000 0000 0000 0000
  00001e0 0000 0000 0000 0000 0000 0000 0000 0000
  00001f0 0022 0000 0012 0000 0000 0000 0000 0804
  0000200 0020 0000 0000 0000 0000 0000 0000 0000
  0000210 0000 0000 0000 0000 0000 0000 0000 0000
  0000220 0000 0000 0000 0000 0000 0000 0000 0000
  0000230 0000 0000 0000 0000 0000 0000 0000 0000
  0000240 0000 0000 0000 0000 0000 0000 0000 0000
  0000250 0000 0000 0000 0000 0000 0000 0000 0000
  0000260 0000 0000 0000 0000 0000 0000 0000 0000
  0000270 0000 0000 0000 0000 0000 0000 0000 0000
  0000280 0000 0000 0000 0000 0000 0000 0000 0000
  0000290 0000 0000 0000 0000 0000 0000 0000 0000
  00002a0 0000 0000 0000 0000 0000 0000 0000 0000
  00002b0 0000 0000 0000 0000 0000 0000 0000 0000
  00002c0 0000 0000 0000 0000 0000 0000 0000 0000
  00002d0 0000 0000 0000 0000 0000 0000 0000 0000
  00002e0 0000 0000 0000 0000 0000 0000 0000 0000
  00002f0 0000 0000 0000 0000 0000 0000 0000 0000
  0000300 0000 0000 0000 0000 0000 0000 0000 0000
  0000310 0000 0000 0000 0000 0000 0000 0000 0000
  0000320 0000 0000 0000 0000 0000 0000 0000 0000
  0000330 0000 0000 0000 0000 0000 0000 0000 0000
  0000340 0000 0000 0000 0000 0000 0000 0000 0000
  0000350 0000 0000 0000 0000 0000 0000 0000 0000
  0000360 0000 0000 0000 0000 0000 0000 0000 0000
  0000370 0000 0000 0000 0000 0000 0000 0000 0000
  0000380 0000 0000 0000 0000 0000 0000 0000 0000
  0000390 0000 0000 0000 0000 0000 0000 0000 0000
  00003a0 0000 0000 0000 0000 0000 0000 0000 0000
  00003b0 0000 0000 0000 0000 0000 0000 0000 0000
  00003c0 0000 0000 0000 0000 0000 0000 0000 0000
  00003d0 0000 0000 0000 0000 0000 0000 0000 0000
  00003e0 0000 0000 0000 0000 0000 0000 0000 0000
  00003f0 0028 0000 0406 0000 0000 0000 0000 0000


So if I take a hexdump of the first line of the "doc_loadbios" binary;
  #hexdump -v doc_loadbios | more
  0000000 457f 464c 0101 0001 0000 0000 0000 0000

..  the first line of my bios image;
  #hdexdump -v bios | more
  0000000 69b0 80e6 0000 0000 0000 0000 0000 0000

.. and  "and" the two;
  0110100110110000  = 69b0h
  0100010101111111  = 4575h
  ================
  0100000100110000

... I get the first word displayed by /dev/mtd0 after the dd (see above)
  0100000100110000  = 4130h



Is /dev/mtd0 supposed to behave like this, or have I just rediscovered a
deliberate "feature" ... ?


> I was confused too. All I can tell you is I have seen cases where the
> write doesn't "stick".
> 
> ron
 

--
http://HumanHeuristic.com/
"Bringing people together in a world full of computers"



To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From ollie at sis.com.tw  Tue Dec  5 19:41:50 2000
From: ollie at sis.com.tw (Ollie Lho)
Date: Wed, 06 Dec 2000 08:41:50 +0800
Subject: Problems with r/w on mtdblock0
References: <200012060019.KAA19472@singularity.tronunltd.com>
Message-ID: <3A2D8B4E.BBF15715@sis.com.tw>

Ian wrote:
> 

> However!  If you *then* do a dd and transfer any_other_file
> into /dev/mtd0,  the new contents are logically "and"ed with
> the old contents of /dev/mtd0.  Ie;
> 
> 
> So if I take a hexdump of the first line of the "doc_loadbios" binary;
>   #hexdump -v doc_loadbios | more
>   0000000 457f 464c 0101 0001 0000 0000 0000 0000
> 
> ..  the first line of my bios image;
>   #hdexdump -v bios | more
>   0000000 69b0 80e6 0000 0000 0000 0000 0000 0000
> 
> .. and  "and" the two;
>   0110100110110000  = 69b0h
>   0100010101111111  = 4575h
>   ================
>   0100000100110000
> 
> ... I get the first word displayed by /dev/mtd0 after the dd (see above)
>   0100000100110000  = 4130h
> 
> Is /dev/mtd0 supposed to behave like this, or have I just rediscovered a
> deliberate "feature" ... ?
> 


Of course it WILL BEHAVIOR THIS WAY !!!!

The DoC has an NAND flash chip in side. For NAND flash chip
you can only turn each bit form 1 to 0 by WRITE operation,
not the other way around. The only way to turn a 0 bit to 1
is by a ERASE operation. This is why I have to erase the first
few Erase Blocks befor writing the DoC in my loaddoc script.

# Erase the first 128 pages of the DoC,
# 128 pages == 128 page * 512 bytes per page == 1 MB
./erase /dev/mtd0 0 128

# Use dd to (zero) pad linuxbios.strip to 63 KB
dd conv=sync bs=63k if=$LINUXBIOS/util/config/winfast/linuxbios.strip \
of=linuxbios.block

# Use dd to wrtie IPL to the first and second pages (page 0, 1) on the DoC
# N.B. if you are using 2.4.0-test10 and later kernel, the conv=notrunc
# is neceressary.
dd if=$LINUXBIOS/util/config/winfast/docipl of=/dev/mtd0 conv=notrunc
dd if=$LINUXBIOS/util/config/winfast/docipl of=/dev/mtd0 seek=1 conv=notrunc


Ollie


To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From nico at cam.org  Tue Dec  5 21:18:44 2000
From: nico at cam.org (Nicolas Pitre)
Date: Tue, 5 Dec 2000 21:18:44 -0500 (EST)
Subject: Problems with r/w on mtdblock0
In-Reply-To: <3A2D8B4E.BBF15715@sis.com.tw>
Message-ID: <Pine.LNX.4.30.0012052103210.2601-100000@xanadu.gn.com>



On Wed, 6 Dec 2000, Ollie Lho wrote:

> Ian wrote:
> >
>
> > However!  If you *then* do a dd and transfer any_other_file
> > into /dev/mtd0,  the new contents are logically "and"ed with
> > the old contents of /dev/mtd0.  Ie;
> >
> >
> > So if I take a hexdump of the first line of the "doc_loadbios" binary;
> >   #hexdump -v doc_loadbios | more
> >   0000000 457f 464c 0101 0001 0000 0000 0000 0000
> >
> > ..  the first line of my bios image;
> >   #hdexdump -v bios | more
> >   0000000 69b0 80e6 0000 0000 0000 0000 0000 0000
> >
> > .. and  "and" the two;
> >   0110100110110000  = 69b0h
> >   0100010101111111  = 4575h
> >   ================
> >   0100000100110000
> >
> > ... I get the first word displayed by /dev/mtd0 after the dd (see above)
> >   0100000100110000  = 4130h
> >
> > Is /dev/mtd0 supposed to behave like this, or have I just rediscovered a
> > deliberate "feature" ... ?
> >
>
>
> Of course it WILL BEHAVIOR THIS WAY !!!!
>
> The DoC has an NAND flash chip in side. For NAND flash chip
> you can only turn each bit form 1 to 0 by WRITE operation,
> not the other way around. The only way to turn a 0 bit to 1
> is by a ERASE operation.

However using /dev/mtdblock0 should produce the same result as if you wrote
to a disk partition or a file.  The latest MTD block interface always erase
the flash region it is going to write to.  Even for large erase sectors the
code is backing the entire sector, patching the data to write into it and
eventually rewriting the whole sector back.

So doing

	dd if=some_file of=/dev/mtdblock0 bs=512 count=1

or even

	cp foobar.fs /dev/mtdblock1

should just work.  If it doesn't then there is a bug.  It actually works
just fine with NOR flash devices.


Nicolas



To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From Relativity at HumanHeuristic.com  Tue Dec  5 21:28:19 2000
From: Relativity at HumanHeuristic.com (Ian)
Date: Wed, 6 Dec 2000 12:28:19 +1000
Subject: Problems with r/w on mtdblock0
Message-ID: <200012060228.MAA20125@singularity.tronunltd.com>


Well, that's how this started;


 >    bash# dd if=/dev/zero of=/dev/mtdblock0 bs=512 count=1 
 >    end_request: I/O error, dev 1f:00 (mtdblock), sector 0 
 >    dd: /dev/mtdblock0: Input/output error 
 >    1+0 records in 
 >    0+0 records out 
 > 
 >    bash# /bin/dd if=/dev/mtdblock0 of=/dev/null bs=512 count=1 
 >    end_request: I/O error, dev 1f:00 (mtdblock), sector 0 
 >    /bin/dd: /dev/mtdblock0: Input/output error 
 >    0+0 records in 
 >    0+0 records out 

.. and Ollie said ...

 >        The /dev/mtdblockN device the the "block device" node for MTD devices. 
 >  In the DoC case, it can only read/write data in 8KB block (the erase size). 
 >  You can not read/write 512B on itm it will get "cached" by the driver. If 
 >  you are playing with the IPL stuff, WRITE TO /dev/mtd0. 
 
... which then started a series of questions about whether or not its being cached
and I'm just rebooting too soon, if that's possible.  *BUT* .. as above .. I'm getting
errors to that device (that I didn't used to).

See my next message (I'm currently writing) re access level via /dev/mtd0 ...

.. but then all of this thread is irrelevant (to me) if I can get my BIOS warez onto
the chip at the right location (which it appears the doc_loadbios has done), but
I still don't get my BIOS app touched  ... so something still isn't sitting right ...
I'm doing testing at the moment ... there *shouldn't* be a driver error ... I'm
stickin' with the Wookie defence ... ;)



> However using /dev/mtdblock0 should produce the same result as if you wrote
> to a disk partition or a file.  The latest MTD block interface always erase
> the flash region it is going to write to.  Even for large erase sectors the
> code is backing the entire sector, patching the data to write into it and
> eventually rewriting the whole sector back.
> 
> So doing
> 
> 	dd if=some_file of=/dev/mtdblock0 bs=512 count=1
> 
> or even
> 
> 	cp foobar.fs /dev/mtdblock1
> 
> should just work.  If it doesn't then there is a bug.  It actually works
> just fine with NOR flash devices.
> 
> 
> Nicolas
> 
 

--
http://HumanHeuristic.com/
"Bringing people together in a world full of computers"



To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From Relativity at HumanHeuristic.com  Tue Dec  5 21:45:36 2000
From: Relativity at HumanHeuristic.com (Ian)
Date: Wed, 6 Dec 2000 12:45:36 +1000
Subject: Problems with r/w on mtdblock0
Message-ID: <200012060245.MAA20187@singularity.tronunltd.com>


> Of course it WILL BEHAVIOR THIS WAY !!!!
What is /dev/mtd0 ?


Is it a "raw" device ... do I see unhindered access to the DoC Millennium, or am
I being processed in some way (maybe address mapped) .. ?



 
> The DoC has an NAND flash chip in side. For NAND flash chip
> you can only turn each bit form 1 to 0 by WRITE operation,
> not the other way around. The only way to turn a 0 bit to 1
> is by a ERASE operation. This is why I have to erase the first
> few Erase Blocks befor writing the DoC in my loaddoc script.
> 
> # Erase the first 128 pages of the DoC,
> # 128 pages == 128 page * 512 bytes per page == 1 MB
> ./erase /dev/mtd0 0 128
> 
> # Use dd to (zero) pad linuxbios.strip to 63 KB
> dd conv=sync bs=63k if=$LINUXBIOS/util/config/winfast/linuxbios.strip 
> of=linuxbios.block
> 
> # Use dd to wrtie IPL to the first and second pages (page 0, 1) on the DoC
> # N.B. if you are using 2.4.0-test10 and later kernel, the conv=notrunc
> # is neceressary.
> dd if=$LINUXBIOS/util/config/winfast/docipl of=/dev/mtd0 conv=notrunc
> dd if=$LINUXBIOS/util/config/winfast/docipl of=/dev/mtd0 seek=1 conv=notrunc
> 
> 
> Ollie
> 
> 
> To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org
> 

--
http://HumanHeuristic.com/
"Bringing people together in a world full of computers"



To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From nico at cam.org  Tue Dec  5 21:52:37 2000
From: nico at cam.org (Nicolas Pitre)
Date: Tue, 5 Dec 2000 21:52:37 -0500 (EST)
Subject: Problems with r/w on mtdblock0
In-Reply-To: <200012060228.MAA20125@singularity.tronunltd.com>
Message-ID: <Pine.LNX.4.30.0012052137370.2601-100000@xanadu.gn.com>



On Wed, 6 Dec 2000, Ian wrote:

>
> Well, that's how this started;
>
>
>  >    bash# dd if=/dev/zero of=/dev/mtdblock0 bs=512 count=1
>  >    end_request: I/O error, dev 1f:00 (mtdblock), sector 0
>  >    dd: /dev/mtdblock0: Input/output error
>  >    1+0 records in
>  >    0+0 records out
>  >
>  >    bash# /bin/dd if=/dev/mtdblock0 of=/dev/null bs=512 count=1
>  >    end_request: I/O error, dev 1f:00 (mtdblock), sector 0
>  >    /bin/dd: /dev/mtdblock0: Input/output error
>  >    0+0 records in
>  >    0+0 records out

The above should be considered as a mtdblock bug IMHO.

> .. and Ollie said ...
>
>  >        The /dev/mtdblockN device the the "block device" node for MTD devices.
>  >  In the DoC case, it can only read/write data in 8KB block (the erase size).
>  >  You can not read/write 512B on itm it will get "cached" by the driver. If

It shouldn't matter.  The driver will actually write 8k if that's the erase
size regardless of the size of your access.

>  >  you are playing with the IPL stuff, WRITE TO /dev/mtd0.

Hmmm....  What's IPL?

> ... which then started a series of questions about whether or not its being cached
> and I'm just rebooting too soon, if that's possible.

No it's not, unless you actually reboot before dd return to the shell
prompt.

> *BUT* .. as above .. I'm getting
> errors to that device (that I didn't used to).

... and that you shouldn't.

I just don't have any hardware with DiskOnChip or NAND flash to test and fix
the problem... therefore I'm not aware of the difference with NOR flash as
far as the block interface is concerned.

Any hints someone?



Nicolas



To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From Relativity at HumanHeuristic.com  Tue Dec  5 22:07:36 2000
From: Relativity at HumanHeuristic.com (Ian)
Date: Wed, 6 Dec 2000 13:07:36 +1000
Subject: Problems with r/w on mtdblock0
Message-ID: <200012060307.NAA20262@singularity.tronunltd.com>


> The above should be considered as a mtdblock bug IMHO.
As long as its not my own doofusness ... but I can't see how ...


> It shouldn't matter.  The driver will actually write 8k if that's the erase
> size regardless of the size of your access.
Yeah ... that's what I reckon too ... but Ollie's part of (if not all of) the DoC
writing team ... so I try not to doubt it (the software's) ability :)
 
> >  >  you are playing with the IPL stuff, WRITE TO /dev/mtd0.
> Hmmm....  What's IPL?
Initial program loader ... there's a bunch of us @ linuxBIOS taking these things
and sticking them into the Motherboard's BIOS socket, then booting linux off of
it.  Unfortunately, I'm the only guy *not* doing that at night .. because mines 
broken :-(   


> No it's not, unless you actually reboot before dd return to the shell
> prompt.
Yeah .. that's what I would've thought .. (after yesterday's thread).

 
> ... and that you shouldn't.
> 
> I just don't have any hardware with DiskOnChip or NAND flash to test and fix
> the problem... therefore I'm not aware of the difference with NOR flash as
> far as the block interface is concerned.
> 
> Any hints someone?
If you want me to try things and send you results, I'm cool with that.  I'd *rather* be 
writing to the block device (at least you should be able to "sync" it).

 

--
http://HumanHeuristic.com/
"Bringing people together in a world full of computers"



To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From Relativity at HumanHeuristic.com  Tue Dec  5 23:33:05 2000
From: Relativity at HumanHeuristic.com (Ian)
Date: Wed, 6 Dec 2000 14:33:05 +1000
Subject: Problems with r/w on mtdblock0
Message-ID: <200012060433.OAA20620@singularity.tronunltd.com>



Check this out ...

  bash# dd if=/dev/mtdblock0 of=crap count=1 bs=16384
  end_request: I/O error, dev 1f:00 (mtdblock), sector 0
  end_request: I/O error, dev 1f:00 (mtdblock), sector 8
  end_request: I/O error, dev 1f:00 (mtdblock), sector 16
  end_request: I/O error, dev 1f:00 (mtdblock), sector 24
  dd: /dev/mtdblock0: Input/output error
  0+0 records in
  0+0 records out
  bash#



.. thoughts?


  ----- Original Message -----
>From: "Nicolas Pitre" <nico at cam.org>
>To: "Ian" <Relativity at HumanHeuristic.com>
>Subject:  Re: Problems with r/w on mtdblock0
>Date: Tue, 05 Dec 2000 21:52:37 -0500
>
> 
> 
> On Wed, 6 Dec 2000, Ian wrote:
> 
> >
> > Well, that's how this started;
> >
> >
> >  >    bash# dd if=/dev/zero of=/dev/mtdblock0 bs=512 count=1
> >  >    end_request: I/O error, dev 1f:00 (mtdblock), sector 0
> >  >    dd: /dev/mtdblock0: Input/output error
> >  >    1+0 records in
> >  >    0+0 records out
> >  >
> >  >    bash# /bin/dd if=/dev/mtdblock0 of=/dev/null bs=512 count=1
> >  >    end_request: I/O error, dev 1f:00 (mtdblock), sector 0
> >  >    /bin/dd: /dev/mtdblock0: Input/output error
> >  >    0+0 records in
> >  >    0+0 records out
> 
> The above should be considered as a mtdblock bug IMHO.
> 
> > .. and Ollie said ...
> >
> >  >        The /dev/mtdblockN device the the "block device" node for MTD devices.
> >  >  In the DoC case, it can only read/write data in 8KB block (the erase size).
> >  >  You can not read/write 512B on itm it will get "cached" by the driver. If
> 
> It shouldn't matter.  The driver will actually write 8k if that's the erase
> size regardless of the size of your access.
> 
> >  >  you are playing with the IPL stuff, WRITE TO /dev/mtd0.
> 
> Hmmm....  What's IPL?
> 
> > ... which then started a series of questions about whether or not its being cached
> > and I'm just rebooting too soon, if that's possible.
> 
> No it's not, unless you actually reboot before dd return to the shell
> prompt.
> 
> > *BUT* .. as above .. I'm getting
> > errors to that device (that I didn't used to).
> 
> ... and that you shouldn't.
> 
> I just don't have any hardware with DiskOnChip or NAND flash to test and fix
> the problem... therefore I'm not aware of the difference with NOR flash as
> far as the block interface is concerned.
> 
> Any hints someone?
> 
> 
> 
> Nicolas
> 
> 

--
http://HumanHeuristic.com/
"Bringing people together in a world full of computers"



To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From Relativity at HumanHeuristic.com  Tue Dec  5 23:45:59 2000
From: Relativity at HumanHeuristic.com (Ian)
Date: Wed, 6 Dec 2000 14:45:59 +1000
Subject: Millennium
Message-ID: <200012060445.OAA20682@singularity.tronunltd.com>


Is there any firmware required on the DoC2001 to make it perform its 8 x bootblock 
memory magic?  .. or is it all done in glue logic?

If the answer to that is an overwhelmingly loud "Well DUH .. of course it requires firmware 
to do its bootblock magic", then Q2 is;

  Isn't that firmware going to be blown away whenever I go to write over the first 1024
bytes .? .. ie .. "doc_loadbios", and the "erase /dev/mtd0 0 128" are both wiping out 8k
of DoC from its origin ...


Thanks in advance ...

--
http://HumanHeuristic.com/
"Bringing people together in a world full of computers"



To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From LKhatskevitch at cachier.com  Wed Dec  6 00:30:26 2000
From: LKhatskevitch at cachier.com (Levi Khatskevitch)
Date: Wed, 6 Dec 2000 00:30:26 -0500
Subject: Millennium
In-Reply-To: <200012060445.OAA20682@singularity.tronunltd.com>
References: <200012060445.OAA20682@singularity.tronunltd.com>
Message-ID: <00120600343401.02531@mrserver>

On Tue, 05 Dec 2000, Ian wrote:
> Is there any firmware required on the DoC2001 to make it perform its 8 x bootblock 
> memory magic?  .. or is it all done in glue logic?
> 

No, it's in glue logic tied initially to DoC reset pin. I'm 99.99% certain
about that. If anyone says otherwise I'd be VERY surprised. My sources
M-Systems docs & mtd code.

- Levi

-- 
Levi Khatskevitch
CTO
Cachier, Corp.
575 Grand St., Suite E306
New York, NY 10002


To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From Relativity at HumanHeuristic.com  Wed Dec  6 01:38:25 2000
From: Relativity at HumanHeuristic.com (Ian)
Date: Wed, 6 Dec 2000 16:38:25 +1000
Subject: Millennium
Message-ID: <200012060638.QAA21084@singularity.tronunltd.com>


> No, it's in glue logic tied initially to DoC reset pin. I'm 99.99% certain
> about that. If anyone says otherwise I'd be VERY surprised. My sources
> M-Systems docs & mtd code.
Actually .. as much as I thought that would make me feel better ... it makes
me suspect the hardware ... I'll have to order another one in the morning ..
something simple and stupid is causing me a lot of extra heartache ... I'm
left with very little to check ...
 

--
http://HumanHeuristic.com/
"Bringing people together in a world full of computers"



To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From LKhatskevitch at cachier.com  Wed Dec  6 02:33:00 2000
From: LKhatskevitch at cachier.com (Levi Khatskevitch)
Date: Wed, 6 Dec 2000 02:33:00 -0500
Subject: nftl/DoC Mill. root fs question
In-Reply-To: <Pine.LNX.3.96.1001206074454.1800T-100000@mail.perspex.com>
References: <Pine.LNX.3.96.1001206074454.1800T-100000@mail.perspex.com>
Message-ID: <00120602385104.02531@mrserver>

On Wed, 06 Dec 2000, Tripp Lilley wrote:
> While researching this whole /etc/mtab vs. /proc/mounts issue, I came
> across the following post:
> 
> 	http://www.uwsg.iu.edu/hypermail/linux/kernel/0010.3/0243.html
> 
> which points out some of the "dangers" in using /proc/mounts, and
> specifically mentions the /dev/root issue. Not sure if it's 100%
> applicable, but it might be a good starting point :)
> 
> 
> On Mon, 4 Dec 2000 tyson at rwii.com wrote:
> 

Thanks,
I'm not yet sure how applicable this is because I'm using busybox mount that as
I have discovered recently doesn't keep mtab at all. It always looks into
/proc/mounts. Since proce/mounts reports /dev/root mounteds on / too I'm
confused, mounting root fs rw doesn't change anything but if I'm using /dev/ram0
as root /proc/mounts and mount both report it correctly. At this point I'm at
loss to explain this.

- Levi

-- 
Levi Khatskevitch
CTO
Cachier, Corp.
575 Grand St., Suite E306
New York, NY 10002


To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From dwmw2 at infradead.org  Wed Dec  6 05:40:06 2000
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 06 Dec 2000 10:40:06 +0000
Subject: CVS MTD drivers -> latest devel kernel. 
In-Reply-To: <20001205122657.A11201@tetsuo.applianceware.com> 
References: <20001205122657.A11201@tetsuo.applianceware.com> 
Message-ID: <11923.976099206@redhat.com>


mpanetta at applianceware.com said:
>  If I want to use the latest CVS MTD drivers in the latest (or not so
> latest 2.4.0-test10) kernel can I just copy the kernel dir in cvs to
> linux/drivers/mtd?

Also copy the contents of the include/linux/mtd/ directory into the 
appropriate place in your kernel tree.

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From dwmw2 at infradead.org  Wed Dec  6 05:44:19 2000
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 06 Dec 2000 10:44:19 +0000
Subject: Millennium 
In-Reply-To: <200012060445.OAA20682@singularity.tronunltd.com> 
References: <200012060445.OAA20682@singularity.tronunltd.com> 
Message-ID: <12499.976099459@redhat.com>


Relativity at HumanHeuristic.com said:
>  Is there any firmware required on the DoC2001 to make it perform its
> 8 x bootblock  memory magic?  .. or is it all done in glue logic?

Note that writing new stuff into the flash doesn't automatically update the 
IPL RAM. You need to power cycle the device before your new code actually 
appears in the RAM - resetting the host board doesn't necessarily work.

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From Relativity at HumanHeuristic.com  Wed Dec  6 06:04:11 2000
From: Relativity at HumanHeuristic.com (Ian)
Date: Wed, 6 Dec 2000 21:04:11 +1000
Subject: Millennium
Message-ID: <200012061104.VAA22134@singularity.tronunltd.com>



Yep - that's cool.  That was in the AppNote Ollie referred me to (and I think it mentions 
that somewhere on their utils disk ... or the notes that go with it).



  ----- Original Message -----
>From: "David Woodhouse" <dwmw2 at infradead.org>
>To: "Ian" <Relativity at humanheuristic.com>
>Subject:  Re: Millennium
>Date: Wed, 06 Dec 2000 10:44:19 +0000
>
> 
> Relativity at HumanHeuristic.com said:
> >  Is there any firmware required on the DoC2001 to make it perform its
> > 8 x bootblock  memory magic?  .. or is it all done in glue logic?
> 
> Note that writing new stuff into the flash doesn't automatically update the 
> IPL RAM. You need to power cycle the device before your new code actually 
> appears in the RAM - resetting the host board doesn't necessarily work.
> 
> --
> dwmw2
> 
> 
> 

--
http://HumanHeuristic.com/
"Bringing people together in a world full of computers"



To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From ian.nelson at echostar.com  Wed Dec  6 18:59:06 2000
From: ian.nelson at echostar.com (Ian S. Nelson)
Date: Wed, 06 Dec 2000 16:59:06 -0700
Subject: CFI Physical Mapped working?
Message-ID: <3A2ED2CA.14522213@echostar.com>

I've been trying to get either the CFI AMD or CFI Physical Mapping to
work with no luck.  Are there any tricks to making it work?  It doesn't
look like any of that code is ever called.  I can load the modules but
nothing ever happens.  I've put some printks in the init_module function
and nothing ever prints.

I'm running with the code in  the 2.4.0test10 tree,  I'm going to try
the CVS code here shortly though.

Also, what are the differences between the physical mapped interface and
CFI?  I'm using an AMD 2MB flash, it's the low power one AM29LV160, I
believe is the part number.  AMD says it's CFI compliant so I'm hoping
it works.    I can read it in physical memory as it is now so I know
that it is visible that way, if nothing else.  I'm working on a National
Semi based product, it has a MediaGX1 and the CS5530A in it if that
makes any difference, I'm under the impression that it shouldn't.  I'm
using their "Centaurus"  test board but I have custom "pizza boards"
too,  the Centaurus is a bit tricky as it has a 256K flash, a 2MB flash
and a 5 or 8 MB DoC and there is a chip select that determines which one
you're running, if that makes any difference.

thanks,
Ian



To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From dwmw2 at infradead.org  Thu Dec  7 03:02:18 2000
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 07 Dec 2000 08:02:18 +0000
Subject: CFI Physical Mapped working? 
In-Reply-To: <3A2ED2CA.14522213@echostar.com> 
References: <3A2ED2CA.14522213@echostar.com> 
Message-ID: <2963.976176138@redhat.com>


ian.nelson at echostar.com said:
> I've been trying to get either the CFI AMD or CFI Physical Mapping to
> work with no luck.  Are there any tricks to making it work?  It
> doesn't look like any of that code is ever called.  I can load the
> modules but nothing ever happens.  I've put some printks in the
> init_module function and nothing ever prints. 

There's no known reason why it shouldn't work. 

init_physmap() ought to autoload the cfi_probe module, which in turn will 
autoload the cfi_cmdset_0002 module if it finds an appropriate chip. 

You may find it's best to write a custom map driver instead of the physmap 
driver, which handles the chip select line for you.

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From dvrabel at arcom.co.uk  Thu Dec  7 07:51:18 2000
From: dvrabel at arcom.co.uk (David Vrabel)
Date: Thu, 07 Dec 2000 12:51:18 +0000
Subject: CVS + separate kernel => missing patch?
Message-ID: <3A2F87C6.D1376DAD@arcom.co.uk>

Hi,

You used to be able to check out MTD from CVS apply a patch to the main
kernel tree and run mtd/patches/patchin.sh and everything would work.

Is it still possible to do this?  If so where is the patch to do this?
(I've already applied the inter-module patch).

David Vrabel.



To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From dwmw2 at infradead.org  Thu Dec  7 07:49:48 2000
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 07 Dec 2000 12:49:48 +0000
Subject: CVS + separate kernel => missing patch? 
In-Reply-To: <3A2F87C6.D1376DAD@arcom.co.uk> 
References: <3A2F87C6.D1376DAD@arcom.co.uk> 
Message-ID: <18043.976193388@redhat.com>


dvrabel at arcom.co.uk said:
>  You used to be able to check out MTD from CVS apply a patch to the
> main kernel tree and run mtd/patches/patchin.sh and everything would
> work.

> Is it still possible to do this?  If so where is the patch to do this?

It was out of date and was removed. There's a complete patch on the ftp 
site (the mtd-patch-README file says where).

If you feel like putting an infrastructure-only patch into CVS or on the 
ftp site again, go for it.

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From michealk at thegravitywell.dhs.org  Thu Dec  7 12:34:30 2000
From: michealk at thegravitywell.dhs.org (Micheal Kelly)
Date: Thu, 7 Dec 2000 12:34:30 -0500
Subject: MTD & JFFS on Arcom SBC
Message-ID: <0012071234300I.24907@morpheus.espial.com>

Hi all,

I've got an Arcom MediaGX board here that I'm trying to get working w/Linux 
2.4-test12pre7 ...  Has anyone else tried the latest MTD source from CVS with 
this board?

It boots, loads the kernel, and it *does* identify the onboard flash - it 
even seems able to *read* from the flash (a JFFS filesystem)... but when a 
write occurs, the screen fills with errors - they go scrolling by too quickly 
to see, but they're something along the lines of:

Chip not ready for buffer write ...  XStatus = 30  bstatus = 0

and

flash_safe_write returned 5

After a few seconds, the screen fills with:

jffs_garbage_collect_thread():  free size == 0 This is BAD.

:)

Also,
I inadvertently compiled the latest MTD sources from CVS with the JFFS 
included in the 2.4 sources and while I still couldn't write to the flash, I 
wouldn't get clobbered by 1000's of errors - I'd get one "Chip not ready", 
and then get the # prompt back....

Anyone have this working with 2.4?


To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From mark.langsdorf at amd.com  Thu Dec  7 12:57:53 2000
From: mark.langsdorf at amd.com (mark.langsdorf at amd.com)
Date: Thu, 7 Dec 2000 11:57:53 -0600
Subject: MTD & JFFS on Arcom SBC
Message-ID: <0FA1031B65A9D111960900805F9FA8E103B9F22D@txexmta8.amd.com>

I'm getting a similar set of error messages with
my AMD flash chips.

I posted a partial message list (for some reason, the
MTD printks weren't being collected properly) under the
title "Odd behavior of JFFS with AMD chips - kernel panic!"
on Monday.

-Mark Langsdorf
AMD, Inc.

> -----Original Message-----
> From: Micheal Kelly [mailto:michealk at thegravitywell.dhs.org]
> Sent: Thursday, December 07, 2000 11:35 AM
> To: mtd at infradead.org
> Subject: MTD & JFFS on Arcom SBC
> 
> 
> Hi all,
> 
> I've got an Arcom MediaGX board here that I'm trying to get 
> working w/Linux 
> 2.4-test12pre7 ...  Has anyone else tried the latest MTD 
> source from CVS with 
> this board?
> 
> It boots, loads the kernel, and it *does* identify the 
> onboard flash - it 
> even seems able to *read* from the flash (a JFFS 
> filesystem)... but when a 
> write occurs, the screen fills with errors - they go 
> scrolling by too quickly 
> to see, but they're something along the lines of:
> 
> Chip not ready for buffer write ...  XStatus = 30  bstatus = 0
> 
> and
> 
> flash_safe_write returned 5
> 
> After a few seconds, the screen fills with:
> 
> jffs_garbage_collect_thread():  free size == 0 This is BAD.
> 
> :)
> 
> Also,
> I inadvertently compiled the latest MTD sources from CVS with 
> the JFFS 
> included in the 2.4 sources and while I still couldn't write 
> to the flash, I 
> wouldn't get clobbered by 1000's of errors - I'd get one 
> "Chip not ready", 
> and then get the # prompt back....
> 
> Anyone have this working with 2.4?
> 
> 
> To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org
> 



To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From Michiel.Ronsse at rug.ac.be  Thu Dec  7 13:08:14 2000
From: Michiel.Ronsse at rug.ac.be (Michiel Ronsse)
Date: Thu, 07 Dec 2000 19:08:14 +0100
Subject: MTD & JFFS on Arcom SBC
References: <0012071234300I.24907@morpheus.espial.com>
Message-ID: <3A2FD20E.733446C@rug.ac.be>

Micheal Kelly wrote:
> 
> Hi all,
> 
> I've got an Arcom MediaGX board here that I'm trying to get working w/Linux
> 2.4-test12pre7 ...  Has anyone else tried the latest MTD source from CVS with
> this board?

We are using several Arcom MediaGX boards quite sucessfully with
2.4-test8.
We are quite happy with this kernel, so I never bothered trying one of
the later
kernels. What amount of flash are you using (we have 16MB)?


Michiel Ronsse.


+-- Michiel Ronsse ------- michiel at ronsse.com --+
| Parallel Information Systems Group            |
| ELIS - Ghent University  - Ghent, Belgium     |
| Phone: +32/9/264.33.67   Fax: +32/9/264.35.94 |
+-------- http://www.michiel.ronsse.com --------+

In a train station the train stops, in a work station ...


To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From michealk at thegravitywell.dhs.org  Thu Dec  7 13:55:44 2000
From: michealk at thegravitywell.dhs.org (Micheal Kelly)
Date: Thu, 7 Dec 2000 13:55:44 -0500
Subject: MTD & JFFS on Arcom SBC
In-Reply-To: <3A2FD20E.733446C@rug.ac.be>
References: <0012071234300I.24907@morpheus.espial.com> <3A2FD20E.733446C@rug.ac.be>
Message-ID: <00120713554403.04734@morpheus.espial.com>


Hello Michiel,

We are using 16 MB also - I'm curious - what version of MTD are you using?  
Something fairly recent from CVS, or an earlier release?  

On Thursday 07 December 2000 13:08, Michiel Ronsse wrote:
> Micheal Kelly wrote:
> > Hi all,
> >
> > I've got an Arcom MediaGX board here that I'm trying to get working
> > w/Linux 2.4-test12pre7 ...  Has anyone else tried the latest MTD source
> > from CVS with this board?
>
> We are using several Arcom MediaGX boards quite sucessfully with
> 2.4-test8.
> We are quite happy with this kernel, so I never bothered trying one of
> the later
> kernels. What amount of flash are you using (we have 16MB)?
>
>
> Michiel Ronsse.


To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From bushi at mizi.com  Thu Dec  7 23:49:40 2000
From: bushi at mizi.com (SeonKon Choi)
Date: Fri, 8 Dec 2000 13:49:40 +0900
Subject: DOC2K & mtd/util/nftl_format.c
Message-ID: <20001208134940.A14241@mizi.com>

hi,

mtd/util/nftl_format.c

    157 
    158     if (meminfo.erasesize != 0x2000) {
    159         printf("Erase size not 8Kb - I'm confused\n");
    160         close(fd);
    161         return 1;
    162     }
    163

It's 0x4000 (16kb) on my DOC2K 16 Mbytes (MD2202-D16, 1.23).

Is there anyone who solve this problem ?

M-System says,
              MD220( )
                    0 - Low profile (16,24,32,48 Mbytes)
                    1 - High profile (72,80,112,144 Mbytes)
                    2 - Low profile (64,96 Mbytes)
                    3 - High profile (160,192,288 MBytes)




To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From dvrabel at arcom.co.uk  Fri Dec  8 04:31:02 2000
From: dvrabel at arcom.co.uk (David Vrabel)
Date: Fri, 08 Dec 2000 09:31:02 +0000
Subject: Requesting module even when it's compiled in
Message-ID: <3A30AA56.AEFBBF6E@arcom.co.uk>

Hi,

I've patched a 2.2.17 kernel with the latest mtd-patch-2.2.17 however
the MTD code is from yesterday's CVS.

Compiled into the kernel
	MTD
	CFI support
	Intel Ext suport
	SBC-MediaGX
The SBC-MediaGX driver starts but fails with
	request_module[cfi_probe]: Root fs is not mounted

It shouldn't be looking for a module should it (since it is compiled
into the kernel)?

CONFIG_MODULES is defined. (don't know if this is relevant)

David Vrabel



To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From dwmw2 at infradead.org  Fri Dec  8 06:47:40 2000
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 08 Dec 2000 11:47:40 +0000
Subject: Requesting module even when it's compiled in 
In-Reply-To: <3A30AA56.AEFBBF6E@arcom.co.uk> 
References: <3A30AA56.AEFBBF6E@arcom.co.uk> 
Message-ID: <8785.976276060@redhat.com>


dvrabel at arcom.co.uk said:
> 	request_module[cfi_probe]: Root fs is not mounted
> It shouldn't be looking for a module should it (since it is compiled
> into the kernel)?

The new inter_module_xxx stuff means the command set drivers need 
initialisation - just exporting a symbol is no longer enough.

I've just added the necessary initcalls to mtdcore.c


--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From dvrabel at arcom.co.uk  Fri Dec  8 07:10:35 2000
From: dvrabel at arcom.co.uk (David Vrabel)
Date: Fri, 08 Dec 2000 12:10:35 +0000
Subject: Requesting module even when it's compiled in
References: <3A30AA56.AEFBBF6E@arcom.co.uk> <8785.976276060@redhat.com>
Message-ID: <3A30CFBB.E13F8F0@arcom.co.uk>

David Woodhouse wrote:
> 
> dvrabel at arcom.co.uk said:
> >       request_module[cfi_probe]: Root fs is not mounted
> > It shouldn't be looking for a module should it (since it is compiled
> > into the kernel)?
> 
> The new inter_module_xxx stuff means the command set drivers need
> initialisation - just exporting a symbol is no longer enough.
> 
> I've just added the necessary initcalls to mtdcore.c

It works provided the init functions changed from static to extern.

David Vrabel



To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From dwmw2 at infradead.org  Fri Dec  8 07:10:25 2000
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 08 Dec 2000 12:10:25 +0000
Subject: Requesting module even when it's compiled in 
In-Reply-To: <3A30CFBB.E13F8F0@arcom.co.uk> 
References: <3A30CFBB.E13F8F0@arcom.co.uk>  <3A30AA56.AEFBBF6E@arcom.co.uk> <8785.976276060@redhat.com> 
Message-ID: <11621.976277425@redhat.com>


dvrabel at arcom.co.uk said:
>  It works provided the init functions changed from static to extern. 

argh. Wanna commit that then?

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From quarantine at arcom.co.uk  Fri Dec  8 07:23:16 2000
From: quarantine at arcom.co.uk (Quarantine)
Date: Fri, 8 Dec 2000 12:23:16 -0000
Subject: FW: Requesting module even when it's compiled in
Message-ID: <NDBBKECCCEBFFCBPNEGIIECDDDAA.quarantine@arcom.co.uk>



-----Original Message-----
From: owner-mtd at infradead.org [mailto:owner-mtd at infradead.org]On Behalf
Of David Vrabel
Sent: Friday, December 08, 2000 9:31 AM
To: mtd at infradead.org
Subject: Requesting module even when it's compiled in


Hi,

I've patched a 2.2.17 kernel with the latest mtd-patch-2.2.17 however
the MTD code is from yesterday's CVS.

Compiled into the kernel
	MTD
	CFI support
	Intel Ext suport
	SBC-MediaGX
The SBC-MediaGX driver starts but fails with
	request_module[cfi_probe]: Root fs is not mounted

It shouldn't be looking for a module should it (since it is compiled
into the kernel)?

CONFIG_MODULES is defined. (don't know if this is relevant)

David Vrabel



To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org





To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From quarantine at arcom.co.uk  Fri Dec  8 07:23:06 2000
From: quarantine at arcom.co.uk (Quarantine)
Date: Fri, 8 Dec 2000 12:23:06 -0000
Subject: FW: Requesting module even when it's compiled in
Message-ID: <NDBBKECCCEBFFCBPNEGIEECDDDAA.quarantine@arcom.co.uk>

-----Original Message-----
From: owner-mtd at infradead.org [mailto:owner-mtd at infradead.org]On Behalf
Of David Vrabel
Sent: Friday, December 08, 2000 9:31 AM
To: mtd at infradead.org
Subject: Requesting module even when it's compiled in


Hi,

I've patched a 2.2.17 kernel with the latest mtd-patch-2.2.17 however
the MTD code is from yesterday's CVS.

Compiled into the kernel
	MTD
	CFI support
	Intel Ext suport
	SBC-MediaGX
The SBC-MediaGX driver starts but fails with
	request_module[cfi_probe]: Root fs is not mounted

It shouldn't be looking for a module should it (since it is compiled
into the kernel)?

CONFIG_MODULES is defined. (don't know if this is relevant)

David Vrabel



To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org





To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From dvrabel at arcom.co.uk  Fri Dec  8 09:45:18 2000
From: dvrabel at arcom.co.uk (David Vrabel)
Date: Fri, 08 Dec 2000 14:45:18 +0000
Subject: cfi_cmdset_0001.c: do_write_buffer: wrong length
Message-ID: <3A30F3FE.5C9781CD@arcom.co.uk>

Hi,

In cfi_cmdset_0001.c do_write_buffer writes an incorrect length to the
chip

    cfi_write(map, CMD((len/(cfi->device_type*CFIDEV_INTERLEAVE))-1),
cmd_adr);

which with 1 x16 chip in x8 mode eg on the SBC-MediaGX (buswidth == 1;
interleave == 1; 
devicetype == 2) works out as

    cfi_write(map, CMD(len/2-1), cmd_adr); <-- Fails

When it should be

    cfi_write(map, CMD(len-1), cmd_adr); <-- Works

Should it it be?
    cfi_write(map, CMD(len/map->buswidth-1), cmd_adr);

David Vrabel



To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From sjhill at cotw.com  Fri Dec  8 10:18:23 2000
From: sjhill at cotw.com (Steven J. Hill)
Date: Fri, 08 Dec 2000 09:18:23 -0600
Subject: Requesting module even when it's compiled in
References: <3A30CFBB.E13F8F0@arcom.co.uk>  <3A30AA56.AEFBBF6E@arcom.co.uk> <8785.976276060@redhat.com> <11621.976277425@redhat.com>
Message-ID: <3A30FBBF.6E659327@cotw.com>

David Woodhouse wrote:
> 
> dvrabel at arcom.co.uk said:
> >  It works provided the init functions changed from static to extern.
> 
> argh. Wanna commit that then?
> 
I will rebuild the patches for 2.2.17 and the latest 2.4.0-x after
you do that.

-Steve

-- 
 Steven J. Hill - Embedded SW Engineer
 Public Key: 'finger sjhill at mail.cotw.com'
 FPR1: E124 6E1C AF8E 7802 A815
 FPR2: 7D72 829C 3386 4C4A E17D


To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From dv207 at cam.ac.uk  Fri Dec  8 14:56:23 2000
From: dv207 at cam.ac.uk (D. Vrabel)
Date: Fri, 08 Dec 2000 19:56:23 +0000
Subject: cfi_cmdset_0001.c: do_write_buffer: wrong length
References: <Pine.LNX.4.30.0012081303110.6716-100000@xanadu.gn.com>
Message-ID: <3A313CE7.DFF1BC4E@cam.ac.uk>

Hi,

Nicolas Pitre wrote:
> 
> On Fri, 8 Dec 2000, David Vrabel wrote:
> >
> > In cfi_cmdset_0001.c do_write_buffer writes an incorrect length to the
> > chip
> >
> >     cfi_write(map, CMD((len/(cfi->device_type*CFIDEV_INTERLEAVE))-1),
> >         cmd_adr);
> >
> > Should it it be?
> >     cfi_write(map, CMD(len/map->buswidth-1), cmd_adr);
> 
> No.  This will break the case where the interleave isn't 1.
> 
> Hmmm... Will it?
> 
> Euh...  Each time I get around this question I get confused...
> 
> Does someone have the data sheet nearby? (I don't ATM)...  What should the
> lenght be if a x16 chip is used in x8 mode?  bytes/sizeof(char) or
> bytes/sizeof(short)?
> 
> On a 2 x16 arrangement you have buswidth=4, interleave=2, devicetype=2.  In
> that case it should be len/4 - 1.
> 
> Maybe you are right after all.

Time to compile a big list of all the arrangements of chips and the
resultant buffer write length...

So far we have:

device type  interleave  bus width    buf write len
2 (x16)      1           1 (x8)       len/1-1
2 (x16)      1           2 (x16)      len/2-1
2 (x16)      2           4 (x32)      len/4-1

So far it len/buswidth-1...

David Vrabel


To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From nico at cam.org  Fri Dec  8 13:21:43 2000
From: nico at cam.org (Nicolas Pitre)
Date: Fri, 8 Dec 2000 13:21:43 -0500 (EST)
Subject: cfi_cmdset_0001.c: do_write_buffer: wrong length
In-Reply-To: <3A30F3FE.5C9781CD@arcom.co.uk>
Message-ID: <Pine.LNX.4.30.0012081303110.6716-100000@xanadu.gn.com>



On Fri, 8 Dec 2000, David Vrabel wrote:

> Hi,
>
> In cfi_cmdset_0001.c do_write_buffer writes an incorrect length to the
> chip
>
>     cfi_write(map, CMD((len/(cfi->device_type*CFIDEV_INTERLEAVE))-1),
> cmd_adr);
>
> which with 1 x16 chip in x8 mode eg on the SBC-MediaGX (buswidth == 1;
> interleave == 1;
> devicetype == 2) works out as
>
>     cfi_write(map, CMD(len/2-1), cmd_adr); <-- Fails
>
> When it should be
>
>     cfi_write(map, CMD(len-1), cmd_adr); <-- Works
>
> Should it it be?
>     cfi_write(map, CMD(len/map->buswidth-1), cmd_adr);

No.  This will break the case where the interleave isn't 1.

Hmmm... Will it?

Euh...  Each time I get around this question I get confused...

Does someone have the data sheet nearby? (I don't ATM)...  What should the
lenght be if a x16 chip is used in x8 mode?  bytes/sizeof(char) or
bytes/sizeof(short)?

On a 2 x16 arrangement you have buswidth=4, interleave=2, devicetype=2.  In
that case it should be len/4 - 1.

Maybe you are right after all.


Nicolas



To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From Michiel.Ronsse at rug.ac.be  Tue Dec 12 04:24:06 2000
From: Michiel.Ronsse at rug.ac.be (Michiel Ronsse)
Date: Tue, 12 Dec 2000 10:24:06 +0100
Subject: MTD & JFFS on Arcom SBC
References: <0012071234300I.24907@morpheus.espial.com> <3A2FD20E.733446C@rug.ac.be> <00120713554403.04734@morpheus.espial.com>
Message-ID: <3A35EEB6.A5D9EC03@rug.ac.be>

Micheal Kelly wrote:
> 
> Hello Michiel,
> 
> We are using 16 MB also - I'm curious - what version of MTD are you using?
> Something fairly recent from CVS, or an earlier release?
> 


We are using kernel 2.4.0-test7 with the MTD patches mtd-patch-2.4.x and
mtd-patch-2.4.0-test2.

Michiel.

-- 
+-- Michiel Ronsse ------- michiel at ronsse.com --+
| Parallel Information Systems Group            |
| ELIS - Ghent University  - Ghent, Belgium     |
| Phone: +32/9/264.33.67   Fax: +32/9/264.35.94 |
+-------- http://www.michiel.ronsse.com --------+

In a train station the train stops, in a work station ...


To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From dvrabel at arcom.co.uk  Tue Dec 12 05:35:35 2000
From: dvrabel at arcom.co.uk (David Vrabel)
Date: Tue, 12 Dec 2000 10:35:35 +0000
Subject: MTD & JFFS on Arcom SBC
References: <0012071234300I.24907@morpheus.espial.com> <3A2FD20E.733446C@rug.ac.be> <00120713554403.04734@morpheus.espial.com> <3A35EEB6.A5D9EC03@rug.ac.be>
Message-ID: <3A35FF77.7D4C9550@arcom.co.uk>

Hi,

[snip: MTD not working on SBC-MediaGX]

I think you'll find that the latest MTD CVS now works on the
SBC-MediaGX.  (At least with 2.2.17 kernels...)

David Vrabel



To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From dvrabel at arcom.co.uk  Tue Dec 12 06:51:15 2000
From: dvrabel at arcom.co.uk (David Vrabel)
Date: Tue, 12 Dec 2000 11:51:15 +0000
Subject: MTD + kernel 2.2.18
Message-ID: <3A361133.1E32268A@arcom.co.uk>

Hi,

I'm trying out MTD with kernel 2.2.18 and there appear to be some
problems with include/linux/mtd/compatmac.h.  I wasn't entirely sure
what was required so find a patch attached to review.

Also some of the init functions (eg in cfi_probe.c) are incorrect.  Are
they supposed to look like the ones in mtdcore.c?

David Vrabel
-------------- next part --------------
Index: compatmac.h
===================================================================
RCS file: /home/cvs/mtd/include/linux/mtd/compatmac.h,v
retrieving revision 1.10
diff -u -r1.10 compatmac.h
--- compatmac.h	2000/11/30 16:39:19	1.10
+++ compatmac.h	2000/12/12 11:40:38
@@ -221,9 +221,12 @@
 #include <linux/init.h>
 #endif
 
-#if LINUX_VERSION_CODE < 0x20300
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,2,18)
 #define init_MUTEX(x) do {*(x) = MUTEX;} while (0)
 #define init_MUTEX_LOCKED(x) do {*(x) = MUTEX_LOCKED;} while (0)
+#endif /* ERM? */
+
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,3,0)
 #define RQFUNC_ARG void
 #define blkdev_dequeue_request(req) do {CURRENT = req->next;} while (0)
 #else
@@ -244,11 +247,15 @@
 
 
 
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,3,0)
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,2,18)
 
 #define DECLARE_WAIT_QUEUE_HEAD(x) struct wait_queue *x = NULL
 #define init_waitqueue_head init_waitqueue
 
+#endif
+
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,3,0)
+
 static inline int try_inc_mod_count(struct module *mod)
 {
 #ifdef CONFIG_MODULES
@@ -329,7 +336,7 @@
 #include <linux/spinlock.h>
 #endif
 
-#if LINUX_VERSION_CODE < 0x20300
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,2,18)
 #define set_current_state(state_value)                        \
         do { current->state = (state_value); } while (0)
 #endif

From dvrabel at arcom.co.uk  Tue Dec 12 06:51:15 2000
From: dvrabel at arcom.co.uk (David Vrabel)
Date: Tue, 12 Dec 2000 11:51:15 +0000
Subject: MTD + kernel 2.2.18
Message-ID: <3A361133.1E32268A@arcom.co.uk>

Hi,

I'm trying out MTD with kernel 2.2.18 and there appear to be some
problems with include/linux/mtd/compatmac.h.  I wasn't entirely sure
what was required so find a patch attached to review.

Also some of the init functions (eg in cfi_probe.c) are incorrect.  Are
they supposed to look like the ones in mtdcore.c?

David Vrabel
-------------- next part --------------
Index: compatmac.h
===================================================================
RCS file: /home/cvs/mtd/include/linux/mtd/compatmac.h,v
retrieving revision 1.10
diff -u -r1.10 compatmac.h
--- compatmac.h	2000/11/30 16:39:19	1.10
+++ compatmac.h	2000/12/12 11:40:38
@@ -221,9 +221,12 @@
 #include <linux/init.h>
 #endif
 
-#if LINUX_VERSION_CODE < 0x20300
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,2,18)
 #define init_MUTEX(x) do {*(x) = MUTEX;} while (0)
 #define init_MUTEX_LOCKED(x) do {*(x) = MUTEX_LOCKED;} while (0)
+#endif /* ERM? */
+
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,3,0)
 #define RQFUNC_ARG void
 #define blkdev_dequeue_request(req) do {CURRENT = req->next;} while (0)
 #else
@@ -244,11 +247,15 @@
 
 
 
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,3,0)
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,2,18)
 
 #define DECLARE_WAIT_QUEUE_HEAD(x) struct wait_queue *x = NULL
 #define init_waitqueue_head init_waitqueue
 
+#endif
+
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,3,0)
+
 static inline int try_inc_mod_count(struct module *mod)
 {
 #ifdef CONFIG_MODULES
@@ -329,7 +336,7 @@
 #include <linux/spinlock.h>
 #endif
 
-#if LINUX_VERSION_CODE < 0x20300
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,2,18)
 #define set_current_state(state_value)                        \
         do { current->state = (state_value); } while (0)
 #endif

From dvrabel at arcom.co.uk  Tue Dec 12 05:35:35 2000
From: dvrabel at arcom.co.uk (David Vrabel)
Date: Tue, 12 Dec 2000 10:35:35 +0000
Subject: MTD & JFFS on Arcom SBC
References: <0012071234300I.24907@morpheus.espial.com> <3A2FD20E.733446C@rug.ac.be> <00120713554403.04734@morpheus.espial.com> <3A35EEB6.A5D9EC03@rug.ac.be>
Message-ID: <3A35FF77.7D4C9550@arcom.co.uk>

Hi,

[snip: MTD not working on SBC-MediaGX]

I think you'll find that the latest MTD CVS now works on the
SBC-MediaGX.  (At least with 2.2.17 kernels...)

David Vrabel



To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org




To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From dwmw2 at infradead.org  Tue Dec 12 08:24:18 2000
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 12 Dec 2000 13:24:18 +0000
Subject: 2.4 stuff. 
In-Reply-To: <Pine.LNX.4.30.0011210948200.12336-100000@xanadu.gn.com> 
References: <Pine.LNX.4.30.0011210948200.12336-100000@xanadu.gn.com> 
Message-ID: <11858.976627458@redhat.com>


nico at cam.org said (Re CFI code):
>  IMHO this is a must.  Since I'm probably the one who made it break
> for your board please don't hesitate to bother me with that so we
> could fix it.

OK, I've just given Linus a fairly large update for 2.4.0-test12. It's at 
ftp.uk.linux.org:/pub/people/dwmw2/forlinus/mtd-patch-whole

It's got everything in it that I said I was going to send except

1. New CFI code. That's not because I'm intending to leave the CFI code out,
but before I do it, because I wanted to let the discussion about block write
sizes settle, and test the AMD command set code on the new toy that landed
on my desk on Friday.

2. New map drivers. I haven't decided which ones to add yet, if any.



--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From nico at cam.org  Tue Dec 12 15:12:00 2000
From: nico at cam.org (Nicolas Pitre)
Date: Tue, 12 Dec 2000 15:12:00 -0500 (EST)
Subject: 2.4 stuff. 
In-Reply-To: <11858.976627458@redhat.com>
Message-ID: <Pine.LNX.4.30.0012121508290.3311-100000@xanadu.gn.com>



On Tue, 12 Dec 2000, David Woodhouse wrote:

> 1. New CFI code. That's not because I'm intending to leave the CFI code out,
> but before I do it, because I wanted to let the discussion about block write
> sizes settle, and test the AMD command set code on the new toy that landed
> on my desk on Friday.

I think the block write discussion has settled on the current code.


Nicolas



To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From dwmw2 at infradead.org  Wed Dec 13 05:24:58 2000
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 13 Dec 2000 10:24:58 +0000
Subject: 2.4 stuff. 
In-Reply-To: <Pine.LNX.4.30.0012121508290.3311-100000@xanadu.gn.com> 
References: <Pine.LNX.4.30.0012121508290.3311-100000@xanadu.gn.com> 
Message-ID: <15785.976703098@redhat.com>


nico at cam.org said:
>  I think the block write discussion has settled on the current code.

Cool. I'll get the AMD code up and running on the new toy on my desk and
send it off to Linus then.

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From michaelstumpf at yahoo.com  Wed Dec 13 11:48:07 2000
From: michaelstumpf at yahoo.com (Michael Stumpf)
Date: Wed, 13 Dec 2000 08:48:07 -0800 (PST)
Subject: MTD, generic physmap memory, MTD_BLOCK
Message-ID: <20001213164807.18924.qmail@web2104.mail.yahoo.com>


I'm working in embedded LinuxPPC on a system with low RAM and ROM -- 6 meg RAM,
8 meg flash ROM.  It seems like that MTD may provide (or almost so) a method
for mapping memory space in as a block device.  It already appears to sort-of
do that, but I was wondering if full support for booting off of non-CFI
compliant, but transparently mapped in, memories is either in place now
(doesn't seem to be there) or is planned for the future.

It's a trivial driver, and I'll write it / modify existing MTD code if
desired/needed, but it really seems important to have so that I can
execute-in-place from a cramfs partition in ROM (and also have this as my root
partition).

Thoughts?  Am I way off the mark here?

Regards-
Michael Stumpf



=====
=====================================================================
Michael J. Stumpf                              
LinuxPPC enablement
IBM-Austin, TX     512.838.1524 [lab]  512.838.5335 [work]   
http://www.pobox.com/~mstumpf

__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/


To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From nico at cam.org  Wed Dec 13 14:02:16 2000
From: nico at cam.org (Nicolas Pitre)
Date: Wed, 13 Dec 2000 14:02:16 -0500 (EST)
Subject: MTD, generic physmap memory, MTD_BLOCK
In-Reply-To: <20001213164807.18924.qmail@web2104.mail.yahoo.com>
Message-ID: <Pine.LNX.4.30.0012131359200.3311-100000@xanadu.gn.com>



On Wed, 13 Dec 2000, Michael Stumpf wrote:

>
> I'm working in embedded LinuxPPC on a system with low RAM and ROM -- 6 meg RAM,
> 8 meg flash ROM.  It seems like that MTD may provide (or almost so) a method
> for mapping memory space in as a block device.  It already appears to sort-of
> do that, but I was wondering if full support for booting off of non-CFI
> compliant, but transparently mapped in, memories is either in place now
> (doesn't seem to be there) or is planned for the future.

Look at mtdram.c.  It might require verylittle modifications to do just what
you want.

> It's a trivial driver, and I'll write it / modify existing MTD code if
> desired/needed, but it really seems important to have so that I can
> execute-in-place from a cramfs partition in ROM (and also have this as my root
> partition).

It's impossible to execute_in_place from a cramfs partition since the
in-place code is compressed.


Nicolas



To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From nico at cam.org  Tue Dec 12 15:12:00 2000
From: nico at cam.org (Nicolas Pitre)
Date: Tue, 12 Dec 2000 15:12:00 -0500 (EST)
Subject: 2.4 stuff. 
In-Reply-To: <11858.976627458@redhat.com>
Message-ID: <Pine.LNX.4.30.0012121508290.3311-100000@xanadu.gn.com>



On Tue, 12 Dec 2000, David Woodhouse wrote:

> 1. New CFI code. That's not because I'm intending to leave the CFI code out,
> but before I do it, because I wanted to let the discussion about block write
> sizes settle, and test the AMD command set code on the new toy that landed
> on my desk on Friday.

I think the block write discussion has settled on the current code.


Nicolas



To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org



To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From dwmw2 at infradead.org  Tue Dec 12 08:24:18 2000
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 12 Dec 2000 13:24:18 +0000
Subject: 2.4 stuff. 
In-Reply-To: <Pine.LNX.4.30.0011210948200.12336-100000@xanadu.gn.com> 
References: <Pine.LNX.4.30.0011210948200.12336-100000@xanadu.gn.com> 
Message-ID: <11858.976627458@redhat.com>


nico at cam.org said (Re CFI code):
>  IMHO this is a must.  Since I'm probably the one who made it break
> for your board please don't hesitate to bother me with that so we
> could fix it.

OK, I've just given Linus a fairly large update for 2.4.0-test12. It's at 
ftp.uk.linux.org:/pub/people/dwmw2/forlinus/mtd-patch-whole

It's got everything in it that I said I was going to send except

1. New CFI code. That's not because I'm intending to leave the CFI code out,
but before I do it, because I wanted to let the discussion about block write
sizes settle, and test the AMD command set code on the new toy that landed
on my desk on Friday.

2. New map drivers. I haven't decided which ones to add yet, if any.



--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org



To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From dvrabel at arcom.co.uk  Tue Dec 12 05:35:35 2000
From: dvrabel at arcom.co.uk (David Vrabel)
Date: Tue, 12 Dec 2000 10:35:35 +0000
Subject: MTD & JFFS on Arcom SBC
References: <0012071234300I.24907@morpheus.espial.com> <3A2FD20E.733446C@rug.ac.be> <00120713554403.04734@morpheus.espial.com> <3A35EEB6.A5D9EC03@rug.ac.be>
Message-ID: <3A35FF77.7D4C9550@arcom.co.uk>

Hi,

[snip: MTD not working on SBC-MediaGX]

I think you'll find that the latest MTD CVS now works on the
SBC-MediaGX.  (At least with 2.2.17 kernels...)

David Vrabel



To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org




To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org



To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From dvrabel at arcom.co.uk  Tue Dec 12 06:51:15 2000
From: dvrabel at arcom.co.uk (David Vrabel)
Date: Tue, 12 Dec 2000 11:51:15 +0000
Subject: MTD + kernel 2.2.18
Message-ID: <3A361133.1E32268A@arcom.co.uk>

Hi,

I'm trying out MTD with kernel 2.2.18 and there appear to be some
problems with include/linux/mtd/compatmac.h.  I wasn't entirely sure
what was required so find a patch attached to review.

Also some of the init functions (eg in cfi_probe.c) are incorrect.  Are
they supposed to look like the ones in mtdcore.c?

David Vrabel
-------------- next part --------------
Index: compatmac.h
===================================================================
RCS file: /home/cvs/mtd/include/linux/mtd/compatmac.h,v
retrieving revision 1.10
diff -u -r1.10 compatmac.h
--- compatmac.h	2000/11/30 16:39:19	1.10
+++ compatmac.h	2000/12/12 11:40:38
@@ -221,9 +221,12 @@
 #include <linux/init.h>
 #endif
 
-#if LINUX_VERSION_CODE < 0x20300
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,2,18)
 #define init_MUTEX(x) do {*(x) = MUTEX;} while (0)
 #define init_MUTEX_LOCKED(x) do {*(x) = MUTEX_LOCKED;} while (0)
+#endif /* ERM? */
+
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,3,0)
 #define RQFUNC_ARG void
 #define blkdev_dequeue_request(req) do {CURRENT = req->next;} while (0)
 #else
@@ -244,11 +247,15 @@
 
 
 
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,3,0)
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,2,18)
 
 #define DECLARE_WAIT_QUEUE_HEAD(x) struct wait_queue *x = NULL
 #define init_waitqueue_head init_waitqueue
 
+#endif
+
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,3,0)
+
 static inline int try_inc_mod_count(struct module *mod)
 {
 #ifdef CONFIG_MODULES
@@ -329,7 +336,7 @@
 #include <linux/spinlock.h>
 #endif
 
-#if LINUX_VERSION_CODE < 0x20300
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,2,18)
 #define set_current_state(state_value)                        \
         do { current->state = (state_value); } while (0)
 #endif

From dwmw2 at infradead.org  Wed Dec 13 05:24:58 2000
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 13 Dec 2000 10:24:58 +0000
Subject: 2.4 stuff. 
In-Reply-To: <Pine.LNX.4.30.0012121508290.3311-100000@xanadu.gn.com> 
References: <Pine.LNX.4.30.0012121508290.3311-100000@xanadu.gn.com> 
Message-ID: <15785.976703098@redhat.com>


nico at cam.org said:
>  I think the block write discussion has settled on the current code.

Cool. I'll get the AMD code up and running on the new toy on my desk and
send it off to Linus then.

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org



To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From postmaster at infradead.org  Thu Dec 14 06:35:45 2000
From: postmaster at infradead.org (David Woodhouse)
Date: Thu, 14 Dec 2000 11:35:45 +0000
Subject: Mail loops.
Message-ID: <21717.976793745@redhat.com>


Argh. This one appears to have been looped back to the list _twice_, by 
different people.

Sort it out. The offenders have been unsubscribed. Please fix it before 
resubscribing.

--
dwmw2

------- Forwarded Message

>From owner-mtd at infradead.org  Thu Dec 14 10:30:54 2000
Return-Path: <owner-mtd at infradead.org>
Delivered-To: dwmw2 at newmail.cygnus
Received: from tantra.cygnus.co.uk (dell-paw-3-eth0.cambridge.redhat.com [172.16.18.254])
	by executor.cambridge.redhat.com (Postfix) with ESMTP id 26324ABAAD
	for <dwmw2 at newmail.cygnus>; Thu, 14 Dec 2000 10:30:53 +0000 (GMT)
Received: from infradead.org (IDENT:root at imladris.infradead.org [194.205.184.45])
	by tantra.cygnus.co.uk (8.11.0/8.11.0) with ESMTP id eBEAV1w03669
	for <dwmw2 at cygnus.co.uk>; Thu, 14 Dec 2000 10:31:01 GMT
Received: from majordomo by infradead.org with local (Exim 3.16 #2)
	id 146Vcv-0002Rw-00
	for mtd-list at infradead.org; Thu, 14 Dec 2000 10:28:41 +0000
Received: from chiara.dei.unipd.it ([147.162.2.19] ident=postfix)
	by infradead.org with esmtp (Exim 3.16 #2)
	id 146Vct-0002RS-00
	for mtd at infradead.org; Thu, 14 Dec 2000 10:28:40 +0000
Received: by chiara.dei.unipd.it (Postfix, from userid 1935)
	id B300743EFF; Thu, 14 Dec 2000 11:29:42 +0100 (CET)
Delivered-To: gremlin at mail.sctrade.it
Received: from kara.sctrade.it
	by localhost with POP3 (fetchmail-5.3.3)
	for gremlin at localhost (single-drop); Thu, 14 Dec 2000 11:29:42 +0100 (CET)
Received: from infradead.org (imladris.infradead.org [194.205.184.45])
	by mail.sctrade.it (Postfix on SuSE Linux 7.0 (i386)) with ESMTP id E65B811350
	for <gremlin at gremlin.it>; Tue, 12 Dec 2000 21:22:40 +0100 (CET)
Received: from majordomo by infradead.org with local (Exim 3.16 #2)
	id 145tsB-0002J7-00
	for mtd-list at infradead.org; Tue, 12 Dec 2000 18:09:55 +0000
Received: from amdext2.amd.com ([163.181.251.1])
	by infradead.org with esmtp (Exim 3.16 #2)
	id 145ts9-0002J1-00
	for mtd at infradead.org; Tue, 12 Dec 2000 18:09:53 +0000
Received: from odyssey.amd.com (odyssey.amd.com [163.181.250.8])
	by amdext2.amd.com (8.9.3/8.9.3/AMD) with SMTP id MAA12565
	for <mtd at infradead.org>; Tue, 12 Dec 2000 12:09:20 -0600 (CST)
Received: from 163.181.250.7 by odyssey.amd.com
          with SMTP (Tumbleweed MMS SMTP Relay (MMS v4.7));
          Tue, 12 Dec 2000 12:09:20 -0600
Received: from 163.181.251.1 by iliad.amd.com
          with ESMTP (Tumbleweed MMS SMTP Relay (MMS v4.7));
          Tue, 12 Dec 2000 04:58:27 -0600
X-Server-Uuid: d47a4d65-b66d-11d4-9a3a-00508be35655
Received: from infradead.org (imladris.infradead.org [194.205.184.45])
	by amdext2.amd.com (8.9.3/8.9.3/AMD) with ESMTP id EAA16819
	for <mark.langsdorf at amd.com>; Tue, 12 Dec 2000 04:58:26 -0600 (CST)
Received: from majordomo by infradead.org with local (Exim 3.16 #2)
	id 145mgW-0000Pk-00
	for mtd-list at infradead.org; Tue, 12 Dec 2000 10:29:24 +0000
Received: from [194.200.159.162] (helo=mailserver.arcom.co.uk)
	by infradead.org with esmtp (Exim 3.16 #2)
	id 145mgU-0000Pe-00
	for mtd at infradead.org; Tue, 12 Dec 2000 10:29:23 +0000
Received: from SMTP [194.200.159.162] by mailserver.arcom.co.uk
  (SMTPD32-6.05) id ADD3C8AE0204; Tue, 12 Dec 2000 10:28:35 +0000
Received: from arcom.co.uk ([10.2.23.1]) by 194.200.159.162
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Tue, 12 Dec 2000 10:28:35 0000 (GMT)
Message-ID: <3A35FF77.7D4C9550 at arcom.co.uk>
Date: Tue, 12 Dec 2000 10:35:35 +0000
From: David Vrabel <dvrabel at arcom.co.uk>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: mtd at infradead.org
Subject: Re: MTD & JFFS on Arcom SBC
References: <0012071234300I.24907 at morpheus.espial.com> <3A2FD20E.733446C at rug.ac.be> <00120713554403.04734 at morpheus.espial.com> <3A35EEB6.A5D9EC03 at rug.ac.be>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-UIDL: 7199ac3673e3633048f7f6630d594173
Status: RO
Sender: owner-mtd at infradead.org
Precedence: bulk

Hi,

[snip: MTD not working on SBC-MediaGX]

I think you'll find that the latest MTD CVS now works on the
SBC-MediaGX.  (At least with 2.2.17 kernels...)

David Vrabel



To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org




To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org



To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


------- End of Forwarded Message





To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From dvrabel at arcom.co.uk  Thu Dec 14 10:50:00 2000
From: dvrabel at arcom.co.uk (David Vrabel)
Date: Thu, 14 Dec 2000 15:50:00 +0000
Subject: JFFS: deleted files still appear in directory
Message-ID: <3A38EC28.9EDC59BF@arcom.co.uk>

Hi,

I'm using the lastest CVS MTD+JFFS with kernel 2.2.18 with the following
result:

# ls
# touch j
# rm j
# ls
ls: ./j: No such file or directory

It appears that readdir() (?) thinks the files exists put stat(), open()
etc. do not.

David Vrabel



To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From michealk at thegravitywell.dhs.org  Thu Dec 14 14:28:43 2000
From: michealk at thegravitywell.dhs.org (Micheal Kelly)
Date: Thu, 14 Dec 2000 14:28:43 -0500
Subject: JFFS: deleted files still appear in directory
In-Reply-To: <3A38EC28.9EDC59BF@arcom.co.uk>
References: <3A38EC28.9EDC59BF@arcom.co.uk>
Message-ID: <00121414284302.01222@morpheus.espial.com>

Hi David,

I'm seeing the same thing with kernel 2.4.0-test12-pre7.  I haven't dug into 
the code yet, as I've gotten sidetracked on other things...  I'll probably 
get around to looking at it on Monday.


- Mike K.

--------------------------------------------------
Micheal Kelly
Espial Inc.

On Thursday 14 December 2000 10:50, David Vrabel wrote:
> Hi,
>
> I'm using the lastest CVS MTD+JFFS with kernel 2.2.18 with the following
> result:
>
> # ls
> # touch j
> # rm j
> # ls
> ls: ./j: No such file or directory
>
> It appears that readdir() (?) thinks the files exists put stat(), open()
> etc. do not.
>
> David Vrabel
>
>
>
> To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From nico at cam.org  Thu Dec 14 16:25:50 2000
From: nico at cam.org (Nicolas Pitre)
Date: Thu, 14 Dec 2000 16:25:50 -0500 (EST)
Subject: 2.4 stuff. 
In-Reply-To: <15785.976703098@redhat.com>
Message-ID: <Pine.LNX.4.30.0012141454510.3311-100000@xanadu.gn.com>



On Wed, 13 Dec 2000, David Woodhouse wrote:

>
> nico at cam.org said:
> >  I think the block write discussion has settled on the current code.
>
> Cool. I'll get the AMD code up and running on the new toy on my desk and
> send it off to Linus then.

I just looked at the cfi_cmdset_0002.c code. This will goof on big endian as
far as I can see.  A major cleanup, like what happened for
cfi_cmdset_0001.c, would be welcome there as well.

First, those functions could be cleaned out:

amd_send_cmd_at()
-----------------
- referenced only once;
- it applies cpu_to_le() on values which have already been correctly
  converted in cfi_build_cmd()... oops!;
- it should use cfi_write() instead of the current
  switch(map->buswidth) {...};
- probably diserve to be killed anyway.

amd_write_val()
---------------
- cfi_write() already does the same.

amd_read_val()
--------------
- cfi-read() already does the same.

Next, cfi_amdstd_write_byte_16() and cfi_amdstd_write_bytes_32() could
greatly benefit from being generalized i.e. merged together and even folded
into cfi_amdstd_write().  The code in cfi-cmdset-001.c should be a great
example for that.  It also removes all the #ifdef noise while still
preserving the ability for the compiler to optimize away the unused code
when a specific bus geometry is selected. In addition, such code as

	tmp = map->read32(map, ofs);
	tmp = be32_to_cpu(tmp);
	memcpy((u_char *)&tmp, buf, len);
	tmp = cpu_to_be32(tmp);

or ...

	tmp = map->read32(map, ofs - 1);
	tmp = (be32_to_cpu(tmp) & 0xFF000000) | buf[2] | (buf[1]  << 8) | buf[0] << 16;
	tmp = cpu_to_be32(tmp);

looks quite awful and suspicious to me.

Next, all calls to udelay() should be combined with a test on
current->need_resched and call schedule() instead of udelay() when true.
Otherwise kiss goodbye to your system's low latency when writes occur.

The last observation is the difference between cmdset-0001 and cmdset-002
for the state in which the task is put while waiting for the chip.  For
cmdset-001 the task is set to TASK_UNINTERRUPTIBLE for some reasons which
are surely valuable for cmdset-002 as well.

So enough criticism for now.  I would have been happy to clean this up
myself, however I don't have any toys with AMD flash in it so couldn't test
the changes at all which lower my motivation to do such work...


Nicolas



To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From ahennessy at mvista.com  Fri Dec 15 12:57:20 2000
From: ahennessy at mvista.com (Alice Hennessy)
Date: Fri, 15 Dec 2000 09:57:20 -0800
Subject: 2.4 stuff.
References: <Pine.LNX.4.30.0012141454510.3311-100000@xanadu.gn.com>
Message-ID: <3A3A5B80.1B8A2C06@mvista.com>

Nicolas Pitre wrote:

> On Wed, 13 Dec 2000, David Woodhouse wrote:
>
> >
> > nico at cam.org said:
> > >  I think the block write discussion has settled on the current code.
> >
> > Cool. I'll get the AMD code up and running on the new toy on my desk and
> > send it off to Linus then.
>
> I just looked at the cfi_cmdset_0002.c code. This will goof on big endian as
> far as I can see.  A major cleanup, like what happened for
> cfi_cmdset_0001.c, would be welcome there as well.
>
> First, those functions could be cleaned out:
>
> amd_send_cmd_at()
> -----------------
> - referenced only once;
> - it applies cpu_to_le() on values which have already been correctly
>   converted in cfi_build_cmd()... oops!;
> - it should use cfi_write() instead of the current
>   switch(map->buswidth) {...};
> - probably diserve to be killed anyway.
>
> amd_write_val()
> ---------------
> - cfi_write() already does the same.
>
> amd_read_val()
> --------------
> - cfi-read() already does the same.
>
> Next, cfi_amdstd_write_byte_16() and cfi_amdstd_write_bytes_32() could
> greatly benefit from being generalized i.e. merged together and even folded
> into cfi_amdstd_write().  The code in cfi-cmdset-001.c should be a great
> example for that.  It also removes all the #ifdef noise while still
> preserving the ability for the compiler to optimize away the unused code
> when a specific bus geometry is selected. In addition, such code as
>
>         tmp = map->read32(map, ofs);
>         tmp = be32_to_cpu(tmp);
>         memcpy((u_char *)&tmp, buf, len);
>         tmp = cpu_to_be32(tmp);
>
> or ...
>
>         tmp = map->read32(map, ofs - 1);
>         tmp = (be32_to_cpu(tmp) & 0xFF000000) | buf[2] | (buf[1]  << 8) | buf[0] << 16;
>         tmp = cpu_to_be32(tmp);
>
> looks quite awful and suspicious to me.
>
> Next, all calls to udelay() should be combined with a test on
> current->need_resched and call schedule() instead of udelay() when true.
> Otherwise kiss goodbye to your system's low latency when writes occur.
>
> The last observation is the difference between cmdset-0001 and cmdset-002
> for the state in which the task is put while waiting for the chip.  For
> cmdset-001 the task is set to TASK_UNINTERRUPTIBLE for some reasons which
> are surely valuable for cmdset-002 as well.
>
> So enough criticism for now.  I would have been happy to clean this up
> myself, however I don't have any toys with AMD flash in it so couldn't test
> the changes at all which lower my motivation to do such work...
>
> Nicolas
>
> To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org

I've made some  minor local changes so that both cfi_cmdset_0002.c and
cfi_probe.c work for my big endian, 4 byte AMD flash board.   I can carry it further
by making it more like cfi_cmdset_0001.c  if you need a volunteer and don't need
it by tomorrow  :-)

Alice



To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From dwmw2 at infradead.org  Fri Dec 15 12:59:41 2000
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 15 Dec 2000 17:59:41 +0000
Subject: 2.4 stuff. 
In-Reply-To: <3A3A5B80.1B8A2C06@mvista.com> 
References: <3A3A5B80.1B8A2C06@mvista.com>  <Pine.LNX.4.30.0012141454510.3311-100000@xanadu.gn.com> 
Message-ID: <21490.976903181@redhat.com>


ahennessy at mvista.com said:
>  I've made some  minor local changes so that both cfi_cmdset_0002.c
> and cfi_probe.c work for my big endian, 4 byte AMD flash board.   I
> can carry it further by making it more like cfi_cmdset_0001.c  if you
> need a volunteer and don't need it by tomorrow  :-) 

Thanks, that'll be useful. I'll be looking at it soon, but I haven't 
managed to get this board to respond to the CFI probe yet, so I'm not sure 
when I'll get to do it. Hopefully soon.

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From mark.langsdorf at amd.com  Fri Dec 15 14:06:43 2000
From: mark.langsdorf at amd.com (mark.langsdorf at amd.com)
Date: Fri, 15 Dec 2000 13:06:43 -0600
Subject: OOPS on AMD CFI chips
Message-ID: <0FA1031B65A9D111960900805F9FA8E103B9F243@txexmta8.amd.com>

	I generated an oops by copying a file.  Here's the oops
itself, followed by the assembly code immediately proceeding
the crash (from cfi_amdstd_write_bytes_32 in cfi_cmdset_0002.c).
	It looks to me like the crash is caused by edi being
0xC1000000.  Am I misinterpreting or should I follow up on this
more?

CPU:    0
EIP:    0010:[<c01a27fb>]
EFLAGS: 00010217
eax: 3fffffff   ebx: fffffffe   ecx: 3ffa2774   edx: 00000003
esi: c03445ec   edi: c1000000   ebp: 005cbd14   esp: c0e89dc8
ds: 0018   es: 0018   ss: 0018
Process cp (pid: 231, process nr: 35, stackpage=c0e89000)
Stack: 00000001 c003dad0 c0e89dd4 00ffffff 00000000 00000000 00000000
00000000
       00000000 00000000 00000000 00000000 c011b680 c014d760 00000000
00000000
       c014dbd0 c014ddd0 00000000 00000000 00000000 c014de00 00000000
00000000
Call Trace: [<c011b680>] [<c014d760>] [<c014dbd0>] [<c014ddd0>] [<c014de00>]
[<c014c1f0>] [<c014c490>]
       [<c014bff0>] [<c014d4f0>] [<c014c1f0>] [<c014c960>] [<c014cf90>]
[<c014c650>] [<c014c8f0>] [<c014ccd0>]
       [<c014bca0>] [<c014d2a0>] [<c014d3d0>] [<c014de10>] [<c014dff0>]
[<c014b790>] [<c014b710>] [<c014e050>]
       [<c014bbe0>] [<c01b4cea>] [<c014b590>] [<c014e090>]
Code: f3 a5 f6 c3 02 74 02 66 a5 f6 c3 01 74 01 a4 8b 74 24 2c e9
Unable to handle kernel paging request at virtual address 83d0ff28
current->tss.cr3 = 008e7000, %cr3 = 008e7000
*pde = 00000000


7ee:	movl		0x10(%esp, 1), %edi
7f2:  movl		0x28(%esp, 1), %esi
7f6:  movl		0x2c(%esp, 1), %ebx
7fa:  cld
7fb:  repz movsl	%ds:(%esi), %es(%edi)

Mark Langsdorf
Advanced Micro Devices, Inc             Tel: 512.602.3756
5204 E. Ben White Blvd. M/S 590         Fax: 512.602.5051
Austin, TX 78741                        mark.langsdorf at amd.com


To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From shane at agendacomputing.com  Fri Dec 15 20:04:04 2000
From: shane at agendacomputing.com (Shane Nay)
Date: Sat, 16 Dec 2000 01:04:04 +0000
Subject: MTD, generic physmap memory, MTD_BLOCK
In-Reply-To: <Pine.LNX.4.30.0012131359200.3311-100000@xanadu.gn.com>
References: <Pine.LNX.4.30.0012131359200.3311-100000@xanadu.gn.com>
Message-ID: <0012160104041B.11759@www.easysolutions.net>


> > It's a trivial driver, and I'll write it / modify existing MTD code if
> > desired/needed, but it really seems important to have so that I can
> > execute-in-place from a cramfs partition in ROM (and also have this as my
> > root partition).
>
> It's impossible to execute_in_place from a cramfs partition since the
> in-place code is compressed.

Unless you expand the inode and mark things as uncompressed and aligned and 
others as compressed.  Attached is a patch to cramfs that allows it to access 
the memory locations that are mapped in directly rather than buffering 
compressed data..., which is a big fat waste and is a "first step" towards 
XIPable cramfs.  We're working on a cramfs that is XIPable, but only for 
MIPs.  The increased performance of a linearly addressed cramfs partition is 
pretty decent..., although I haven't figured out a smart way to bootstrap 
right into the cramfs stuff...  (I'm thinking init.c or around there is where 
I should be looking)

Thanks,
Shane.

Oh, BTW, I finished "a version" of mtd for XIP kernel writable for 
cfi_cmdset_0001.c, and cfi_probe.  I haven't figured out a smart way to deal 
with having two versions of stuff yet..., because most of the code is the 
same.  You can find it on 
ftp.agendacomputing.com/pub/kernel/*someversion*/patches .  Once I figure out 
a smart way to do this, and forward port to CVS I'll put it in the mainline 
MTD code unless there are any nay-sayers.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cramfs-linear-addressing.patch
Type: text/english
Size: 2826 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20001216/baf6b5ef/attachment.bin 

From dwmw2 at infradead.org  Sun Dec 17 17:24:52 2000
From: dwmw2 at infradead.org (David Woodhouse)
Date: Sun, 17 Dec 2000 22:24:52 +0000 (GMT)
Subject: MTD, generic physmap memory, MTD_BLOCK
In-Reply-To: <0012160104041B.11759@www.easysolutions.net>
Message-ID: <Pine.LNX.4.30.0012172223230.15911-100000@imladris.demon.co.uk>


Unless there's something missing (or I'm being dim) that code doesn't do
XIP. It still copies from the cramfs into the page provided to
cramfs_readpage.

What you want to do is make up some struct pages to represent the pages
of the ROM chip and pre-populate the page cache with those pages directly
- marked readonly, of course.

-- 
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From dwmw2 at infradead.org  Sun Dec 17 19:29:19 2000
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 18 Dec 2000 00:29:19 +0000 (GMT)
Subject: module registration changes
Message-ID: <Pine.LNX.4.30.0012180026320.18907-100000@imladris.demon.co.uk>


Please could people test the new stuff I've just committed to bypass the
inter_module_get code by using weakly-linked symbols? Especially on 2.0.

This should also fix the dependency on link order which was introduced by
the removal of get_module_symbol().

-- 
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From dvrabel at arcom.co.uk  Mon Dec 18 07:08:25 2000
From: dvrabel at arcom.co.uk (David Vrabel)
Date: Mon, 18 Dec 2000 12:08:25 +0000
Subject: JFFS: deleted files still appear in directory
References: <Pine.LNX.4.30.0012180937270.21997-100000@imladris.demon.co.uk>
Message-ID: <3A3DFE39.2FC5303E@arcom.co.uk>

Hi,

I think this problem is fixed by this patch.

David Vrabel.

Index: inode-v22.c
===================================================================
RCS file: /home/cvs/mtd/fs/jffs/inode-v22.c,v
retrieving revision 1.54
diff -u -r1.54 inode-v22.c
--- inode-v22.c	2000/12/05 16:03:41	1.54
+++ inode-v22.c	2000/12/18 11:59:42
@@ -575,6 +575,7 @@
 	struct jffs_control *c = (struct jffs_control
*)inode->i_sb->u.generic_sbp;
 	int j;
 	int ddino;
+
 	D3(printk (KERN_NOTICE "readdir(): down biglock\n"));
 	down(&c->fmc->biglock);
 
@@ -604,10 +605,13 @@
 		filp->f_pos++;
 	}
 	f = ((struct jffs_file *)inode->u.generic_ip)->children;
-	for (j = 2; (j < filp->f_pos) && f; j++) {
-	        f = f->sibling_next;
+
+	j=2;
+	while(f && (f->deleted || j++ < filp->f_pos )) {
+		f = f->sibling_next;
 	}
-	for (; f ; f = f->sibling_next) {
+
+	while (f) {
 		D3(printk("jffs_readdir(): \"%s\" ino: %u\n",
 			  (f->name ? f->name : ""), f->ino));
 		if (filldir(dirent, f->name, f->nsize,
@@ -617,6 +621,9 @@
 			return 0;
 		}
 		filp->f_pos++;
+		do {
+			f = f->sibling_next;
+		} while(f && f->deleted);
 	}
 	D3(printk (KERN_NOTICE "readdir(): up biglock\n"));
 	up(&c->fmc->biglock);
Index: inode-v23.c
===================================================================
RCS file: /home/cvs/mtd/fs/jffs/inode-v23.c,v
retrieving revision 1.51
diff -u -r1.51 inode-v23.c
--- inode-v23.c	2000/12/05 16:03:41	1.51
+++ inode-v23.c	2000/12/18 11:59:47
@@ -598,10 +598,13 @@
 		filp->f_pos++;
 	}
 	f = ((struct jffs_file *)inode->u.generic_ip)->children;
-	for (j = 2; (j < filp->f_pos) && f; j++) {
-	        f = f->sibling_next;
+
+	j=2;
+	while(f && (f->deleted || j++ < filp->f_pos )) {
+		f = f->sibling_next;
 	}
-	for (; f ; f = f->sibling_next) {
+
+	while (f) {
 		D3(printk("jffs_readdir(): \"%s\" ino: %u\n",
 			  (f->name ? f->name : ""), f->ino));
 		if (filldir(dirent, f->name, f->nsize,
@@ -611,6 +614,9 @@
 			return 0;
 		}
 		filp->f_pos++;
+		do {
+			f = f->sibling_next;
+		} while(f && f->deleted);
 	}
 	D3(printk (KERN_NOTICE "readdir(): up biglock\n"));
 	up(&c->fmc->biglock);
Index: intrep.c
===================================================================
RCS file: /home/cvs/mtd/fs/jffs/intrep.c,v
retrieving revision 1.82
diff -u -r1.82 intrep.c
--- intrep.c	2000/12/09 03:29:36	1.82
+++ intrep.c	2000/12/18 11:59:56
@@ -1059,12 +1059,11 @@
 		f->atime = raw_inode->atime;
 		f->mtime = raw_inode->mtime;
 		f->ctime = raw_inode->ctime;
-		f->deleted = raw_inode->deleted;
 	}
 	else if ((f->highest_version < node->version)
 		 || (node->version == 0)) {
 		/* Insert at the end of the list.  I.e. this node is the
-		   oldest one so far.  */
+		   newest one so far.  */
 		node->version_prev = f->version_tail;
 		node->version_next = 0;
 		f->version_tail->version_next = node;
@@ -1078,7 +1077,6 @@
 		f->atime = raw_inode->atime;
 		f->mtime = raw_inode->mtime;
 		f->ctime = raw_inode->ctime;
-		f->deleted = raw_inode->deleted;
 	}
 	else if (f->version_head->version > node->version) {
 		/* Insert at the bottom of the list.  */
@@ -1089,9 +1087,6 @@
 		if (!f->name) {
 			update_name = 1;
 		}
-		if (raw_inode->deleted) {
-			f->deleted = raw_inode->deleted;
-		}
 	}
 	else {
 		struct jffs_node *n;
@@ -1115,6 +1110,12 @@
 		}
 	}
 
+	/* Deletion is irreversible. If any 'deleted' node is ever
+	   written, the file is deleted */
+	if (raw_inode->deleted) {
+		f->deleted = raw_inode->deleted;
+	}
+
 	/* Perhaps update the name.  */
 	if (raw_inode->nsize && update_name && name && *name && (name !=
f->name)) {
 		if (f->name) {
@@ -1647,6 +1648,9 @@
 		printk(KERN_ERR "JFFS: jffs_write_node: Failed to write, "
 		       "requested %i, wrote %i\n", total_size, err);
 		goto retry;
+	}
+	if (raw_inode->deleted) {
+		f->deleted = 1;
 	}
 
 	jffs_fm_write_unlock(fmc);



To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From dvrabel at arcom.co.uk  Mon Dec 18 07:49:08 2000
From: dvrabel at arcom.co.uk (David Vrabel)
Date: Mon, 18 Dec 2000 12:49:08 +0000
Subject: JFFS: rmdir wierdness 
Message-ID: <3A3E07C4.22A3F127@arcom.co.uk>

Hi,

# mkdir a
# ls
a
# rmdir a
# ls
# mkdir a
mkdir: a: File exists

Also

# mkdir b
# touch b/a
# rm b/a
# rmdir b
rmdir: b: Directory not empty

rmdir() thinks `b' still has children (I think).

This was done with the latest CVS with kernel 2.2.18.

David Vrabel.



To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From dvrabel at arcom.co.uk  Mon Dec 18 08:04:47 2000
From: dvrabel at arcom.co.uk (David Vrabel)
Date: Mon, 18 Dec 2000 13:04:47 +0000
Subject: JFFS: rmdir wierdness
References: <3A3E07C4.22A3F127@arcom.co.uk>
Message-ID: <3A3E0B6F.DAC1D46A@arcom.co.uk>

Hi,

Are these problems anything to do with jffs_find_child() not ignoring
deleted files?

David Vrabel



To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From Simon.Munton at m4data.co.uk  Mon Dec 18 08:01:53 2000
From: Simon.Munton at m4data.co.uk (Simon Munton)
Date: Mon, 18 Dec 2000 13:01:53 -0000
Subject: JFFS: deleted files still appear in directory
Message-ID: <52AF3CB987C7D41183CD0090271F67C3184C@m4eng.m4data.co.uk>

There's still a problem with the following sequence of commands:

# touch foo
# touch bar
# mv foo bar
# rm bar
rm: cannot unlink `bar': Input/output error

JFFS debug output:
jffs_create(): dir: 0xc0f20144, name: "foo"
jffs_write_node(): filename = "foo", ino = 2, total_size = 64
jffs_fmalloc(): fmc = 0xc0f873f0, size = 64, node = 0xc000b720
jffs_insert_node(): ino = 2, version = 1, name = "foo", deleted = 0
thread_should_wake(): free=8257472, dirty=0, blocksize=131072.
jffs_create(): dir: 0xc0f20144, name: "bar"
jffs_write_node(): filename = "bar", ino = 3, total_size = 64
jffs_fmalloc(): fmc = 0xc0f873f0, size = 64, node = 0xc000b630
jffs_insert_node(): ino = 3, version = 1, name = "bar", deleted = 0
thread_should_wake(): free=8257408, dirty=0, blocksize=131072.
***jffs_rename()
jffs_rename(): old_dir: 0xc0f20144, old name: 0xc0f1e760, new_dir:
0xc0f20144, new name: 0xc0f1e860
jffs_write_node(): filename = "bar", ino = 2, total_size = 68
jffs_fmalloc(): fmc = 0xc0f873f0, size = 68, node = 0xc000b770
jffs_write_node(): setting version of foo to 2
***jffs_remove(): file = "bar", ino = 3
jffs_write_node(): filename = "", ino = 3, total_size = 60
jffs_fmalloc(): fmc = 0xc0f873f0, size = 60, node = 0xc000b590
jffs_write_node(): setting version of bar to 2
jffs_insert_node(): ino = 3, version = 2, name = "", deleted = 1
thread_should_wake(): free=8257280, dirty=0, blocksize=131072.
jffs_insert_node(): ino = 2, version = 2, name = "bar", deleted = 0
jffs_remove_redundant_nodes(): Removing node: ino: 2, version: 1, mod_type:
3
jffs_fmfree(): node->ino = 2, node->version = 1
thread_should_wake(): free=8257280, dirty=64, blocksize=131072.
***jffs_remove(): file = "bar", ino = 2
jffs_remove(): wrong inodes


Simon

========================================================
Simon Munton	simonm at m4data.co.uk
M4 Data Ltd	Tel: 44-1749-683800
Mendip Court, Bath Rd, Wells	Fax: 44-1749-673928
Somerset, BA5 3DG, England


> -----Original Message-----
> From: David Vrabel [mailto:dvrabel at arcom.co.uk]
> Sent: 18 December 2000 12:08 pm
> To: David Woodhouse
> Cc: mtd at infradead.org
> Subject: Re: JFFS: deleted files still appear in directory
> 
> 
> Hi,
> 
> I think this problem is fixed by this patch.
> 
> David Vrabel.


To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From dwmw2 at infradead.org  Mon Dec 18 08:02:56 2000
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 18 Dec 2000 13:02:56 +0000
Subject: JFFS: rmdir wierdness 
In-Reply-To: <3A3E07C4.22A3F127@arcom.co.uk> 
References: <3A3E07C4.22A3F127@arcom.co.uk> 
Message-ID: <23862.977144576@redhat.com>


dvrabel at arcom.co.uk said:
> # mkdir a
> # ls
> a
> # rmdir a
> # ls
> # mkdir a
> mkdir: a: File exists
> 
> Also
> 
> # mkdir b
> # touch b/a
> # rm b/a
> # rmdir b
> rmdir: b: Directory not empty
> 
> rmdir() thinks `b' still has children (I think).

More problems with the deletion code since I did the use counts.
Hmmm. This was sort of why I didn't want to commit it immediately, till I'd 
had time to do some sanity checks on it.

Try this:

Index: intrep.c
===================================================================
RCS file: /home/cvs/mtd/fs/jffs/intrep.c,v
retrieving revision 1.84
diff -u -r1.84 intrep.c
--- intrep.c	2000/12/18 13:00:23	1.84
+++ intrep.c	2000/12/18 13:02:30
@@ -1387,7 +1387,7 @@
 	D3(printk("jffs_find_child()\n"));
 
 	for (f = dir->children; f; f = f->sibling_next) {
-		if (f->name
+		if (!f->deleted && f->name
 		    && !strncmp(f->name, name, len)
 		    && f->name[len] == '\0') {
 			break;


--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From eauth at softsys.co.at  Mon Dec 18 08:04:37 2000
From: eauth at softsys.co.at (Erwin Authried)
Date: Mon, 18 Dec 2000 14:04:37 +0100
Subject: module registration changes
References: <Pine.LNX.4.30.0012180026320.18907-100000@imladris.demon.co.uk>
Message-ID: <000e01c068f3$13881180$5201a8c0@home.at>

there were a couple of small changes necessary to compile on 2.0.
Here are some other changes that I would like to commit too, please let me
know if its ok.:

* Use #ifdef NO_MM in mtdchar.c to avoid vmalloc if no MMU is used
(uClinux).

* "list.h" is missing in the 2.0 kernel source. The best thing that I could
think of is to simply add it
to MTD in linux/mtd/list.h.

* Somehow initcalls.c must be used for 2.0 kernels conditionally. Either in
the Makefile, or just
#include from mtdcore.c? I don't know how to do that in the Makefile nicely.

Regards,

Erwin

----- Original Message -----
From: David Woodhouse <dwmw2 at infradead.org>
To: <eauth at softsys.co.at>
Cc: <mtd at infradead.org>
Sent: Monday, December 18, 2000 1:29 AM
Subject: module registration changes


>
> Please could people test the new stuff I've just committed to bypass the
> inter_module_get code by using weakly-linked symbols? Especially on 2.0.
>
> This should also fix the dependency on link order which was introduced by
> the removal of get_module_symbol().
>
> --
> dwmw2
>
>
>



To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From Simon.Munton at m4data.co.uk  Mon Dec 18 08:13:44 2000
From: Simon.Munton at m4data.co.uk (Simon Munton)
Date: Mon, 18 Dec 2000 13:13:44 -0000
Subject: JFFS: deleted files still appear in directory 
Message-ID: <52AF3CB987C7D41183CD0090271F67C3184D@m4eng.m4data.co.uk>

Yep, that fixed it. I'll try and break something else now.

Simon

> -----Original Message-----
> From: David Woodhouse [mailto:dwmw2 at infradead.org]
> Sent: 18 December 2000 01:06 pm
> To: Simon Munton; jffs-dev at axis.com
> Subject: Re: JFFS: deleted files still appear in directory 
> 
> 
> 
> Simon.Munton at m4data.co.uk said:
> > There's still a problem with the following sequence of commands:
> > # touch foo 
> > # touch bar
> > # mv foo bar
> > # rm bar
> > rm: cannot unlink `bar': Input/output error 
> 
> Hopefully that's fixed by the change to jffs_find_child() 
> which I just 
> committed.
> 
> 
> --
> dwmw2
> 
> 


To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From dwmw2 at infradead.org  Mon Dec 18 08:17:33 2000
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 18 Dec 2000 13:17:33 +0000
Subject: JFFS: deleted files still appear in directory 
In-Reply-To: <52AF3CB987C7D41183CD0090271F67C3184D@m4eng.m4data.co.uk> 
References: <52AF3CB987C7D41183CD0090271F67C3184D@m4eng.m4data.co.uk> 
Message-ID: <25546.977145453@redhat.com>


Simon.Munton at m4data.co.uk said:
> Yep, that fixed it. I'll try and break something else now. 

Yeah - you're definitely slacking if you're finding bugs I've already fixed 
:)

Concentrate on bugs centred around unlink(). There's probably something we 
haven't considered yet.

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From dvrabel at arcom.co.uk  Mon Dec 18 09:18:28 2000
From: dvrabel at arcom.co.uk (David Vrabel)
Date: Mon, 18 Dec 2000 14:18:28 +0000
Subject: JFFS: rmdir wierdness
References: <3A3E07C4.22A3F127@arcom.co.uk>
Message-ID: <3A3E1CB4.F4BF34DB@arcom.co.uk>

Hi,

> # mkdir a
> # ls
> a
> # rmdir a
> # ls
> # mkdir a
> mkdir: a: File exists

This one has been fixed.

> # mkdir b
> # touch b/a
> # rm b/a
> # rmdir b
> rmdir: b: Directory not empty

This one is still broken.

In jffs_remove():
	if (S_ISDIR(type)) {
		/* ... */
		if (del_f->children) {
			result = -ENOTEMPTY;
			goto jffs_remove_end;
		}
	}

As I understand it del_f->children is the head of a list of the
directory's children.  If this is the case then won't you have to go
through the list checking that all the children have been deleted?  Find
a patch that does just this (it works too).

David Vrabel.

Index: inode-v22.c
===================================================================
RCS file: /home/cvs/mtd/fs/jffs/inode-v22.c,v
retrieving revision 1.55
diff -u -r1.55 inode-v22.c
--- inode-v22.c 2000/12/18 12:11:08     1.55
+++ inode-v22.c 2000/12/18 14:05:50
@@ -960,14 +960,20 @@
        }
 
        if (S_ISDIR(type)) {
+               struct jffs_file *child=del_f->children;
+
                result = -ENOTDIR;
                if (!S_ISDIR(del_f->mode)) { /* Is this really needed
for 2.2? */
                        D(printk("jffs_remove(): S_ISDIR but isn't\n"));
                        goto jffs_remove_end;
                }
-               if (del_f->children) {
-                       result = -ENOTEMPTY;
-                       goto jffs_remove_end;
+
+               while(child) {
+                       if( !child->deleted ) {
+                               result = -ENOTEMPTY;
+                               goto jffs_remove_end;
+                       }
+                       child = child->sibling_next;
                }
        }
        else if (S_ISDIR(del_f->mode)) {
Index: inode-v23.c
===================================================================
RCS file: /home/cvs/mtd/fs/jffs/inode-v23.c,v
retrieving revision 1.52
diff -u -r1.52 inode-v23.c
--- inode-v23.c 2000/12/18 12:11:08     1.52
+++ inode-v23.c 2000/12/18 14:05:56
@@ -956,11 +956,15 @@
        }
 
        if (S_ISDIR(type)) {
-               if (del_f->children) {
-                       result = -ENOTEMPTY;
-                       goto jffs_remove_end;
+               struct jffs_file *child=del_f->children;
+               while(child) {
+                       if( !child->deleted ) {
+                               result = -ENOTEMPTY;
+                               goto jffs_remove_end;
+                       }
+                       child = child->sibling_next;
                }
-       }
+       }
        else if (S_ISDIR(del_f->mode)) {
                D(printk("jffs_remove(): node is a directory "
                         "but it shouldn't be.\n"));



To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From nico at cam.org  Mon Dec 18 10:50:56 2000
From: nico at cam.org (Nicolas Pitre)
Date: Mon, 18 Dec 2000 10:50:56 -0500 (EST)
Subject: module registration changes
In-Reply-To: <000e01c068f3$13881180$5201a8c0@home.at>
Message-ID: <Pine.LNX.4.30.0012181049550.997-100000@xanadu.gn.com>



On Mon, 18 Dec 2000, Erwin Authried wrote:

> there were a couple of small changes necessary to compile on 2.0.
> Here are some other changes that I would like to commit too, please let me
> know if its ok.:
>
> * Use #ifdef NO_MM in mtdchar.c to avoid vmalloc if no MMU is used
> (uClinux).
>
> * "list.h" is missing in the 2.0 kernel source. The best thing that I could
> think of is to simply add it
> to MTD in linux/mtd/list.h.

Well...  I would suggest you add it where it belongs i.e.
include/linux/list.h.


Nicolas



To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From eauth at softsys.co.at  Mon Dec 18 12:05:32 2000
From: eauth at softsys.co.at (Erwin Authried)
Date: Mon, 18 Dec 2000 18:05:32 +0100
Subject: module registration changes
References: <Pine.LNX.4.30.0012181049550.997-100000@xanadu.gn.com>
Message-ID: <001001c06914$bb3be160$5201a8c0@home.at>

Currently, I have two seperate directory trees for mtd and for the linux
kernel. With a link
to the mtd sources in the drivers directory, and a second link in
includes/linux to the includes/linux/mtd directory, both trees can
maintained with CVS completely seperately. This wouldn't be possible that
easy with files in the include/linux subdir.

-Erwin

----- Original Message -----
From: Nicolas Pitre <nico at cam.org>
To: Erwin Authried <eauth at softsys.co.at>
Cc: David Woodhouse <dwmw2 at infradead.org>; <mtd at infradead.org>
Sent: Monday, December 18, 2000 4:50 PM
Subject: Re: module registration changes


>
>
> On Mon, 18 Dec 2000, Erwin Authried wrote:
>
> > there were a couple of small changes necessary to compile on 2.0.
> > Here are some other changes that I would like to commit too, please let
me
> > know if its ok.:
> >
> > * Use #ifdef NO_MM in mtdchar.c to avoid vmalloc if no MMU is used
> > (uClinux).
> >
> > * "list.h" is missing in the 2.0 kernel source. The best thing that I
could
> > think of is to simply add it
> > to MTD in linux/mtd/list.h.
>
> Well...  I would suggest you add it where it belongs i.e.
> include/linux/list.h.
>
>
> Nicolas
>
>



To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From sjhill at cotw.com  Mon Dec 18 17:46:45 2000
From: sjhill at cotw.com (Steven J. Hill)
Date: Mon, 18 Dec 2000 16:46:45 -0600
Subject: New patches available for MTD and JFFS...
Message-ID: <3A3E93D5.A92FF5BB@cotw.com>

Greetings.

I have created new kernel patches using the latest MTF/JFFS
CVS snapshot as of Dec 18, 2000 at 22:30 GMT which was just
a few minutes ago. The patches are against 2.2.17, 2.2.18,
2.4.0-test10, 2.4.0-test11 and 2.4.0-test12 . I hope someone
finds them of use. They can be found at the FTP path shown
below. Cheers.

-Steve

ftp://ftp.infradead.org/pub/mtd/patches/

-- 
 Steven J. Hill - Embedded SW Engineer
 Public Key: 'finger sjhill at mail.cotw.com'
 FPR1: E124 6E1C AF8E 7802 A815
 FPR2: 7D72 829C 3386 4C4A E17D


To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From shane at agendacomputing.com  Mon Dec 18 16:31:43 2000
From: shane at agendacomputing.com (Shane Nay)
Date: Mon, 18 Dec 2000 21:31:43 +0000
Subject: MTD, generic physmap memory, MTD_BLOCK
In-Reply-To: <Pine.LNX.4.30.0012172223230.15911-100000@imladris.demon.co.uk>
References: <Pine.LNX.4.30.0012172223230.15911-100000@imladris.demon.co.uk>
Message-ID: <0012182131432A.11759@www.easysolutions.net>

On Sunday 17 December 2000 22:24, David Woodhouse wrote:
> Unless there's something missing (or I'm being dim) that code doesn't do
> XIP. It still copies from the cramfs into the page provided to
> cramfs_readpage.
>
> What you want to do is make up some struct pages to represent the pages
> of the ROM chip and pre-populate the page cache with those pages directly
> - marked readonly, of course.


Hehe, no, it's not an XIP implementation.  I think I mentioned in my message, 
even if I didn't make it clear (probably not) that this only made cramfs read 
directly off of the flash, taking one layer of abstraction out.  It kills the 
buffer, and the copy to buffer that would usually be associated with a dev 
device, so it speeds up performance of cramfs on a flash device.  It's _only_ 
a performance hack at this point.

But we are working on XIP for cramfs.  But this requires either expanding the 
inode, or stealing a bit or two away from GIDS, or UIDs.  This is only a 
"linear addressing" patch.

Thanks,
Shane.


To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From shane at agendacomputing.com  Mon Dec 18 17:13:46 2000
From: shane at agendacomputing.com (Shane Nay)
Date: Mon, 18 Dec 2000 22:13:46 +0000
Subject: cfi_cmdset_0001.c: do_write_buffer: wrong length
In-Reply-To: <3A313CE7.DFF1BC4E@cam.ac.uk>
References: <Pine.LNX.4.30.0012081303110.6716-100000@xanadu.gn.com> <3A313CE7.DFF1BC4E@cam.ac.uk>
Message-ID: <0012182213462I.11759@www.easysolutions.net>

On Friday 08 December 2000 19:56, D. Vrabel wrote:
> Hi,
>
> Nicolas Pitre wrote:
> > On Fri, 8 Dec 2000, David Vrabel wrote:
> > > In cfi_cmdset_0001.c do_write_buffer writes an incorrect length to the
> > > chip
> > >
> > >     cfi_write(map, CMD((len/(cfi->device_type*CFIDEV_INTERLEAVE))-1),
> > >         cmd_adr);
> > >
> > > Should it it be?
> > >     cfi_write(map, CMD(len/map->buswidth-1), cmd_adr);
> >
> > No.  This will break the case where the interleave isn't 1.
> >
> > Hmmm... Will it?
> >
> > Euh...  Each time I get around this question I get confused...
> >
> > Does someone have the data sheet nearby? (I don't ATM)...  What should
> > the lenght be if a x16 chip is used in x8 mode?  bytes/sizeof(char) or
> > bytes/sizeof(short)?
> >
> > On a 2 x16 arrangement you have buswidth=4, interleave=2, devicetype=2. 
> > In that case it should be len/4 - 1.
> >
> > Maybe you are right after all.
>
> Time to compile a big list of all the arrangements of chips and the
> resultant buffer write length...
>
> So far we have:
>
> device type  interleave  bus width    buf write len
> 2 (x16)      1           1 (x8)       len/1-1
> 2 (x16)      1           2 (x16)      len/2-1
> 2 (x16)      2           4 (x32)      len/4-1
>
> So far it len/buswidth-1...


Yea..., this is what I was _trying_ to say, but communicated very poorly 
about 2 weeks ago.  It's fixed in the patches I posted to the agenda site.

Thanks,
Shane.


To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From shane at agendacomputing.com  Mon Dec 18 17:24:16 2000
From: shane at agendacomputing.com (Shane Nay)
Date: Mon, 18 Dec 2000 22:24:16 +0000
Subject: cfi_cmdset_0001.c: do_write_buffer: wrong length
In-Reply-To: <3A313CE7.DFF1BC4E@cam.ac.uk>
References: <Pine.LNX.4.30.0012081303110.6716-100000@xanadu.gn.com> <3A313CE7.DFF1BC4E@cam.ac.uk>
Message-ID: <0012182224162J.11759@www.easysolutions.net>

Okay, last message was way cryptic again..., I'm not a master communicator.  
Anyway, I have succesfully tested the following change on two interleaves.  
First device:
two x16 devices in x8 mode interleaved
Second device:
one x16 device in x16 mode

It's only one change... cfi_cmdset_0001.c:
/* Write length of data to come */
-cfi_write(map,CMD((len/(cfi->device_type*CFIDEV_INTERLEAVE))-1),cmd_adr);
+cfi_write(map,CMD((len/(cfi->device_type))-1),cmd_adr);

Dividing by CFIDEV_INTERLEAVE there I think is wrong.  The interleave 
_increases_ not decreases the number of bytes/words you are going to write.

Thanks,
Shane.


To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From dwmw2 at infradead.org  Tue Dec 19 04:24:18 2000
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 19 Dec 2000 09:24:18 +0000
Subject: MTD, generic physmap memory, MTD_BLOCK 
In-Reply-To: <0012182131432A.11759@www.easysolutions.net> 
References: <0012182131432A.11759@www.easysolutions.net>  <Pine.LNX.4.30.0012172223230.15911-100000@imladris.demon.co.uk> 
Message-ID: <29168.977217858@redhat.com>


shane at agendacomputing.com said:
>  But we are working on XIP for cramfs.  But this requires either
> expanding the  inode, or stealing a bit or two away from GIDS, or
> UIDs.  This is only a  "linear addressing" patch. 

I was looking at doing it in romfs. You can't have compression anyway, for 
obvious reasons, and it looked a little easier. But I suppose that wouldn't 
allow you to mix XIP-able and compressed files in the same fs.

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From shane at agendacomputing.com  Mon Dec 18 17:35:40 2000
From: shane at agendacomputing.com (Shane Nay)
Date: Mon, 18 Dec 2000 22:35:40 +0000
Subject: MTD, generic physmap memory, MTD_BLOCK
In-Reply-To: <29168.977217858@redhat.com>
References: <0012182131432A.11759@www.easysolutions.net> <Pine.LNX.4.30.0012172223230.15911-100000@imladris.demon.co.uk> <29168.977217858@redhat.com>
Message-ID: <0012182235402K.11759@www.easysolutions.net>


> I was looking at doing it in romfs. You can't have compression anyway, for
> obvious reasons, and it looked a little easier. But I suppose that wouldn't
> allow you to mix XIP-able and compressed files in the same fs.

We *should* have it done this week in romfs.  That's our testbed for the 
first implementation.  I'm going on vacation on Wednesday, but if it's done 
before that I'll point folks to patches on this list.  If not I should have 
them for the next Thursday..., bug me if I don't send it out by then.

Thanks,
Shane.


To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From dv207 at hermes.cam.ac.uk  Tue Dec 19 04:41:15 2000
From: dv207 at hermes.cam.ac.uk (David Vrabel)
Date: Tue, 19 Dec 2000 09:41:15 +0000 (GMT)
Subject: cfi_cmdset_0001.c: do_write_buffer: wrong length
In-Reply-To: <0012182224162J.11759@www.easysolutions.net>
Message-ID: <Pine.HPX.4.21L.0012190929510.12642-100000@punch.eng.cam.ac.uk>

On Mon, 18 Dec 2000, Shane Nay wrote:

> Okay, last message was way cryptic again..., I'm not a master communicator.  
> Anyway, I have succesfully tested the following change on two interleaves.  
> First device:
> two x16 devices in x8 mode interleaved
> Second device:
> one x16 device in x16 mode
> 
> It's only one change... cfi_cmdset_0001.c:
> /* Write length of data to come */
> -cfi_write(map,CMD((len/(cfi->device_type*CFIDEV_INTERLEAVE))-1),cmd_adr);
> +cfi_write(map,CMD((len/(cfi->device_type))-1),cmd_adr);

However this would break the case 1 in the table below.  Whereas 
    cfi_write(map, CMD(len/CFIDEV_BUSWIDTH-1), cmd_adr);
would work.

To add to the table...

device type  interleave  bus width  buf write len
2 (x16)      1           1 (x8)     len/1-1
2 (x16)      1           2 (x16)    len/2-1
2 (x16)      2           4 (x32)    len/4-1
2 (x16)      2           2 (x16)    len/2-1

It's still len/buswidth-1.

David Vrabel



To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From shane at agendacomputing.com  Mon Dec 18 18:07:47 2000
From: shane at agendacomputing.com (Shane Nay)
Date: Mon, 18 Dec 2000 23:07:47 +0000
Subject: cfi_cmdset_0001.c: do_write_buffer: wrong length
In-Reply-To: <Pine.HPX.4.21L.0012190929510.12642-100000@punch.eng.cam.ac.uk>
References: <Pine.HPX.4.21L.0012190929510.12642-100000@punch.eng.cam.ac.uk>
Message-ID: <0012182307472P.11759@www.easysolutions.net>

On Tuesday 19 December 2000 09:41, David Vrabel wrote:
> On Mon, 18 Dec 2000, Shane Nay wrote:
> > Okay, last message was way cryptic again..., I'm not a master
> > communicator. Anyway, I have succesfully tested the following change on
> > two interleaves. First device:
> > two x16 devices in x8 mode interleaved
> > Second device:
> > one x16 device in x16 mode
> >
> > It's only one change... cfi_cmdset_0001.c:
> > /* Write length of data to come */
> > -cfi_write(map,CMD((len/(cfi->device_type*CFIDEV_INTERLEAVE))-1),cmd_adr)
> >; +cfi_write(map,CMD((len/(cfi->device_type))-1),cmd_adr);
>
> However this would break the case 1 in the table below.  Whereas
>     cfi_write(map, CMD(len/CFIDEV_BUSWIDTH-1), cmd_adr);
> would work.
>
> To add to the table...
>
> device type  interleave  bus width  buf write len
> 2 (x16)      1           1 (x8)     len/1-1
> 2 (x16)      1           2 (x16)    len/2-1
> 2 (x16)      2           4 (x32)    len/4-1
> 2 (x16)      2           2 (x16)    len/2-1
>
> It's still len/buswidth-1.
>

Hmm..., good point.  But what about interleaved x8 devices?  Would they be 
fine?  (Brains not functioning at the moment, but my instinct says it would 
be divided by 2 when it should be divided by 1, but I might be messing up the 
"len" calculation that happens before this.  I initially did it the way you 
mention here, but thought I found a flaw, but could definetly be wrong.)

Thanks,
Shane.


To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From michaelstumpf at yahoo.com  Tue Dec 19 08:32:39 2000
From: michaelstumpf at yahoo.com (Michael Stumpf)
Date: Tue, 19 Dec 2000 05:32:39 -0800 (PST)
Subject: MTD, generic physmap memory, MTD_BLOCK 
Message-ID: <20001219133239.24180.qmail@web2103.mail.yahoo.com>


> >  But we are working on XIP for cramfs.  But this requires either
> > expanding the  inode, or stealing a bit or two away from GIDS, or
> > UIDs.  This is only a  "linear addressing" patch. 
> 
> I was looking at doing it in romfs. You can't have compression anyway, for 
> obvious reasons, and it looked a little easier. But I suppose that wouldn't 
> allow you to mix XIP-able and compressed files in the same fs.

I did some work in the direction suggested by (thanks!) Nicolas--modified
mtdram.c to act as a conduit device for plain memory.  I did get a successful
boot from a cramfs rootdisk.  

When I said XIP, I didn't realize that this crowd had a very "serious"
definition of it.  I simply meant I was trying to get around the initrd
buffering issue:  As far as I can tell, up until now the only mechanism that a
CPU (with only RAM and ROM visibility) has at its disposal to boot from is
initrd, that would copy all the ROM image into RAM buffer cache.. and only
understand three file systems (cramfs is not one of them).  I don't mind cramfs
using a buffer page (4k, LinuxPPC) or two to do its work--I was trying to slay
the complete-image-copy daemon.  (My embedded system is 6 meg RAM, 8 meg ROM..
and I want shared libraries, etc)

It seems to me that for the time being and the immediate future, XIP as we're
talking about it would be overkill.  The streamlining and elegance gained in
the operation of XIP is probably offset by the ugliness of implementation and
the potential loss of compression that seems so crucial in embedded devices,
the primary target (right?) of MTD.  I like XIP but I don't think I'd ever use
it.

One very relevant topic that I'd like to discuss is where a generic memory
conduit device belongs.  I would suspect it belongs as a fallback default if
CFI devices can't be probed (I forget the file), but it also might make sense
to give it a separate file for "neatness" sake.  

Cheers,
Michael




=====
=====================================================================
Michael J. Stumpf                              
LinuxPPC enablement
IBM-Austin, TX     512.838.1524 [lab]  512.838.5335 [work]   
http://www.pobox.com/~mstumpf

__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/


To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From shane at agendacomputing.com  Mon Dec 18 21:51:42 2000
From: shane at agendacomputing.com (Shane Nay)
Date: Tue, 19 Dec 2000 02:51:42 +0000
Subject: MTD, generic physmap memory, MTD_BLOCK
In-Reply-To: <20001219133239.24180.qmail@web2103.mail.yahoo.com>
References: <20001219133239.24180.qmail@web2103.mail.yahoo.com>
Message-ID: <0012190251422T.11759@www.easysolutions.net>


> I did some work in the direction suggested by (thanks!) Nicolas--modified
> mtdram.c to act as a conduit device for plain memory.  I did get a
> successful boot from a cramfs rootdisk.
>
> When I said XIP, I didn't realize that this crowd had a very "serious"
> definition of it.  I simply meant I was trying to get around the initrd
> buffering issue:  As far as I can tell, up until now the only mechanism
> that a CPU (with only RAM and ROM visibility) has at its disposal to boot
> from is initrd, that would copy all the ROM image into RAM buffer cache..
> and only understand three file systems (cramfs is not one of them).  I
> don't mind cramfs using a buffer page (4k, LinuxPPC) or two to do its
> work--I was trying to slay the complete-image-copy daemon.  (My embedded
> system is 6 meg RAM, 8 meg ROM.. and I want shared libraries, etc)

It's 32k BTW.  Boot from initrd?..., initial romdisk?..., nope.  Try this 
instead..., /dev/rom.  Patches are on ftp.agendacomputing.com site.  Make a 
cramfs partition with the headers necessary to tag it as a cramfs partition 
(in the scripts/ directory on linux-vr.org ..., mkromfs I think applied to a 
cramfs filesystem)  Then enable /dev/rom, and set it's address at the start 
of the rom.  Then root=/dev/rom as the boot options.

> It seems to me that for the time being and the immediate future, XIP as
> we're talking about it would be overkill.  The streamlining and elegance
> gained in the operation of XIP is probably offset by the ugliness of
> implementation and the potential loss of compression that seems so crucial
> in embedded devices, the primary target (right?) of MTD.  I like XIP but I
> don't think I'd ever use it.

With only 6MB of ram..., it might be a good thing for your device, but I 
don't know what you're planning on running on it.

> One very relevant topic that I'd like to discuss is where a generic memory
> conduit device belongs.  I would suspect it belongs as a fallback default
> if CFI devices can't be probed (I forget the file), but it also might make
> sense to give it a separate file for "neatness" sake.
Thanks,
Shane.


To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From john at frumious.unidec.co.uk  Tue Dec 19 09:20:12 2000
From: john at frumious.unidec.co.uk (dr john halewood)
Date: Tue, 19 Dec 2000 14:20:12 +0000
Subject: MTD module compilation (was: [PATCH] link time error in drivers/mtd (240t13p2))
In-Reply-To: <Pine.LNX.4.30.0012171158140.14423-100000@imladris.demon.co.uk>
References: <Pine.LNX.4.30.0012171158140.14423-100000@imladris.demon.co.uk>
Message-ID: <00121914201204.01244@frumious.unidec.co.uk>

On Sunday 17 December 2000 12:04, David Woodhouse wrote to linux-kernel:
> On Sun, 17 Dec 2000, Keith Owens wrote:
> > Your choice.  Just bear in mind that if CONFIG_MODULES=y but mtd
> > objects are built into the kernel then mtd _must_ have a correct link
> > order.  Consider a config with CONFIG_MODULES=y but every mtd option is
> > set to 'y', link order is critical.
>
> Yep, I'd just noticed that one. The patch was actually put in by someone
> to fix 2.0 compilation - and I noticed that it made the link order
> problem go away for certain configs.
>
[cc'ed to mtd list as it might help a few people there]
heh. 
  I'm glad this has come up as I think I got bitten by this a couple of weeks 
ago, but didn't realise it at the time. For various reasons to do with 
avoiding using initrd's I'd built a kernel that was modular, but had doc2000 
and nftl loaded statically - other mtd stuff was loaded as modules. My 
Millenium chip behaved like the proverbial stick - data wouldn't stick to it, 
certainly not across reboots. Then I came in one morning to find the screen 
slowly scolling the following message:
NFTL - writeblock(): Cannot find block to write to
end_request: I/O error, dev 5d:01 (unknown), sector 256
Tell Dave he fucked up. LastFreeEUN = 1023, FirstEUN=10765
No Virtual Unit Chains available for folding. Failing request.
[This will teach me not to run mke2fs from 5 miles away!]

I guess this must have been caused by incorrect ordering of the modules, as a 
recompilation of the kernel and linking everything as modular has left it 
working fine [This was using 2.2.17 + the merged doc2000 w/Millenium support 
from the 30/11 snapshot and from cvs since, although I've now jumped to 
2.4.0-test12 without any problems]

If anyone else has had this problem I would suggest this as a solution

cheers
john


To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From dwmw2 at infradead.org  Tue Dec 19 09:25:02 2000
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 19 Dec 2000 14:25:02 +0000
Subject: MTD module compilation (was: [PATCH] link time error in drivers/mtd (240t13p2)) 
In-Reply-To: <00121914201204.01244@frumious.unidec.co.uk> 
References: <00121914201204.01244@frumious.unidec.co.uk>  <Pine.LNX.4.30.0012171158140.14423-100000@imladris.demon.co.uk> 
Message-ID: <2006.977235902@redhat.com>


john at frumious.unidec.co.uk said:
> Tell Dave he fucked up. LastFreeEUN = 1023, FirstEUN=10765 
> No Virtual Unit Chains available for folding. Failing request. 

That probably wasn't an init order problem. That was just broken code. It
should now be fixed, and the printk has been sanitised too - it wasn't
really supposed to get past the proof of concept stage with that precise
wording in it.

Regardless of the wording used, that error shouldn't ever happen in the new 
code, if your NFTL has been reformatted since you broke it. If it does, we 
need to know about it.



--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From dwmw2 at infradead.org  Tue Dec 19 09:34:28 2000
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 19 Dec 2000 14:34:28 +0000
Subject: Return of ifdefs in cfi_probe.c
Message-ID: <3041.977236468@redhat.com>


The use of weak symbols was intended to render the ifdefs which you 
restored unnecessary. Are you sure it didn't work right in 2.0 the way I 
left it?

--- cfi_probe.c	2000/12/18 00:03:26	1.30
+++ cfi_probe.c	2000/12/18 16:14:51	1.31
@@ -1,7 +1,7 @@
 /* 
    Common Flash Interface probe code.
    (C) 2000 Red Hat. GPL'd.
-   $Id: cfi_probe.c,v 1.30 2000/12/18 00:03:26 dwmw2 Exp $
+   $Id: cfi_probe.c,v 1.31 2000/12/18 16:14:51 eauth Exp $
 */
 
 #include <linux/config.h>
@@ -741,21 +741,23 @@
 		return;
 
 	switch(type){
+#ifdef CONFIG_MTD_CFI_INTELEXT
 	case 0x0001:
 		probe_function = cfi_cmdset_0001;
 		break;
-
+#endif
+#ifdef CONFIG_MTD_CFI_AMDSTD 
 	case 0x0002:
 		probe_function = cfi_cmdset_0002;
 		break;
+#endif

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From dwmw2 at infradead.org  Tue Dec 19 09:52:21 2000
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 19 Dec 2000 14:52:21 +0000
Subject: module registration changes 
In-Reply-To: <Pine.LNX.4.30.0012181049550.997-100000@xanadu.gn.com> 
References: <Pine.LNX.4.30.0012181049550.997-100000@xanadu.gn.com> 
Message-ID: <4742.977237541@redhat.com>


nico at cam.org said:
>  Well...  I would suggest you add it where it belongs i.e. include/
> linux/list.h. 

I agree. We need to patch 2.0 anyway to make the initcalls &c work. We 
might as well add list.h in the right place in the same patch.

At this stage, I'd like to keep the main code as clean as possible for 2.4. 
I want it to _work_ on 2.0, but I want it to be _pretty_ in 2.4, because I 
have to justify it to Linus for 2.4, and I don't for 2.0 :)

Feel free to add an 'infrastructure' patch for 2.0 which does everything 
you need and lets you just drop the contents of the drivers/mtd and 
include/linux/mtd directories in place from CVS.

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From dwmw2 at infradead.org  Fri Dec 22 11:12:30 2000
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 22 Dec 2000 16:12:30 +0000
Subject: CFI ident problems with AMD chips.
Message-ID: <4883.977501550@redhat.com>

Hi,

I've now started using AMD chips. I have a chip which I believe to be a 
4MiB part with TOP boot blocks. Should be 63*64KiB erase regions followed by 
8*8KiB erase regions.

However, the CFI "Erase Block Region" information reports them in the wrong 
order - the 8*8KiB blocks _before_ the 63*64KiB.

Is there some way to tell the top-boot parts apart from the bottom-boot 
parts?

--
dwmw2






To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From nick at auriga.ru  Mon Dec 25 06:44:02 2000
From: nick at auriga.ru (Nick Ivanter)
Date: Mon, 25 Dec 2000 14:44:02 +0300
Subject: CFI ident problems with AMD chips.
References: <4883.977501550@redhat.com>
Message-ID: <3A473302.74DD6A6B@auriga.ru>

They surely have differnet Device ID's which can be found in a datasheet
and compared with the reported ones.

Nick

David Woodhouse wrote:

> Hi,
>
> I've now started using AMD chips. I have a chip which I believe to be a
> 4MiB part with TOP boot blocks. Should be 63*64KiB erase regions followed by
> 8*8KiB erase regions.
>
> However, the CFI "Erase Block Region" information reports them in the wrong
> order - the 8*8KiB blocks _before_ the 63*64KiB.
>
> Is there some way to tell the top-boot parts apart from the bottom-boot
> parts?
>
> --
> dwmw2
>
> To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org



To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


From dwmw2 at infradead.org  Mon Dec 25 06:59:01 2000
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 25 Dec 2000 11:59:01 +0000 (GMT)
Subject: CFI ident problems with AMD chips.
In-Reply-To: <3A473302.74DD6A6B@auriga.ru>
Message-ID: <Pine.LNX.4.30.0012251158200.3604-100000@imladris.demon.co.uk>

On Mon, 25 Dec 2000, Nick Ivanter wrote:

> They surely have differnet Device ID's which can be found in a datasheet
> and compared with the reported ones.

My code to report JEDEC ID for them was returning {0,0}. I'll poke at that
again when I go back to work next week.

-- 
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org


