* Again 2.6.18-RC6 XScale P30 issues
@ 2006-09-08 15:27 Nils Faerber
2006-09-09 11:16 ` Justin Clacherty
0 siblings, 1 reply; 5+ messages in thread
From: Nils Faerber @ 2006-09-08 15:27 UTC (permalink / raw)
To: linux-mtd
Hi, me again ...
I am sorry to bother you again, but I still have issues withe the P30
flashes.
Now that I can write to the chips I tested it a little more. After a
fresh write of a clean rootfs I can create and delete files almost fine
(I just get very few CRC errors but everything else works OK, also the
files are intact).
But after creating and deleting files and a reboot I get:
----------
[42949375.760000] Write of 68 bytes at 0x00cf91d0 failed. returned -30,
retlen 0
[42949375.770000] Not marking the space at 0x00cf91d0 as dirty because
the flash driver returned retlen zero
[42949375.780000] Write of 68 bytes at 0x00cf91d0 failed. returned -30,
retlen 0
[42949375.780000] Not marking the space at 0x00cf91d0 as dirty because
the flash driver returned retlen zero
ifup: /var/run/ifstate: Read-only file system
............
Starting telnetd...
Starting slideshow with images from the internal flash...
Starting pid 695, console /dev/ttyS0: '/bin/sh'
Processing /etc/profile... Done
[@colineator /]#cd
[@colineator /root]#ls -l
-rw-r--r-- 1 0 0 5242880 Jan 1 00:14 blub
[@colineator /root]#rm blub
[42949387.590000] Write of 44 bytes at 0x00cf91d0 failed. returned -30,
retlen 0
[42949387.600000] Not marking the space at 0x00cf91d0 as dirty because
the flash driver returned retlen zero
[42949387.610000] Write of 44 bytes at 0x00cf91d0 failed. returned -30,
retlen 0
[42949387.620000] Not marking the space at 0x00cf91d0 as dirty because
the flash driver returned retlen zero
rm: unable to remove `blub': Read-only file system
----------------
So something is still wrong. At runtime the filesystem seems to be OK
but after a reboot it seems to be defect. Only way to recover is to
reflash the rootfs.
I am quite desperate right now.
For the new approach I took the Mainstone MTD mapping driver and
modified it for the single two-chip configuration. But I did not change
anything beyond that.
Cheers
nils faerber
--
kernel concepts GbR Tel: +49-271-771091-12
Dreisbachstr. 24 Fax: +49-271-771091-19
D-57250 Netphen Mob: +49-176-21024535
--
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Again 2.6.18-RC6 XScale P30 issues
2006-09-08 15:27 Again 2.6.18-RC6 XScale P30 issues Nils Faerber
@ 2006-09-09 11:16 ` Justin Clacherty
2006-09-09 12:16 ` Nils Faerber
0 siblings, 1 reply; 5+ messages in thread
From: Justin Clacherty @ 2006-09-09 11:16 UTC (permalink / raw)
To: Nils Faerber; +Cc: linux-mtd
Nils Faerber wrote:
> So something is still wrong. At runtime the filesystem seems to be OK
> but after a reboot it seems to be defect. Only way to recover is to
> reflash the rootfs.
>
Is the bootup process writing to flash before you unlock it? syslogd
might be a culprit...
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Again 2.6.18-RC6 XScale P30 issues
2006-09-09 11:16 ` Justin Clacherty
@ 2006-09-09 12:16 ` Nils Faerber
2006-09-09 14:10 ` Josh Boyer
2006-09-09 22:00 ` Justin Clacherty
0 siblings, 2 replies; 5+ messages in thread
From: Nils Faerber @ 2006-09-09 12:16 UTC (permalink / raw)
To: Justin Clacherty; +Cc: linux-mtd
Justin Clacherty schrieb:
> Nils Faerber wrote:
>> So something is still wrong. At runtime the filesystem seems to be OK
>> but after a reboot it seems to be defect. Only way to recover is to
>> reflash the rootfs.
> Is the bootup process writing to flash before you unlock it? syslogd
> might be a culprit...
Well, yes, there are some scripts that touch the fs, but that is IMHO
not the issue here. If it would be I would get the other "unable to
write to locked sector" error.
Instead the fs gets permanently corrupted, i.e. data is written and the
written data is wrong.
Last night I found that the JFFS2 write cache is configured. I will
disable that now and see if that helps - I have the impression that the
fs may contain half-baked stuff after a write. On the other hand, the
JFFS2 write cache is not marked as an experimental feature so I thought
I should be safe...
Well, that like poking with a long pole in the mist, I have to admit.
Very nasty to debug...
If I find something new I'll let you know ;)
But many thanks for your (all of you) help so far!
Cheers
nils faerber
--
kernel concepts GbR Tel: +49-271-771091-12
Dreisbachstr. 24 Fax: +49-271-771091-19
D-57250 Netphen Mob: +49-176-21024535
--
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Again 2.6.18-RC6 XScale P30 issues
2006-09-09 12:16 ` Nils Faerber
@ 2006-09-09 14:10 ` Josh Boyer
2006-09-09 22:00 ` Justin Clacherty
1 sibling, 0 replies; 5+ messages in thread
From: Josh Boyer @ 2006-09-09 14:10 UTC (permalink / raw)
To: Nils Faerber; +Cc: Justin Clacherty, linux-mtd
On 9/9/06, Nils Faerber <nils.faerber@kernelconcepts.de> wrote:
> Justin Clacherty schrieb:
> > Nils Faerber wrote:
> >> So something is still wrong. At runtime the filesystem seems to be OK
> >> but after a reboot it seems to be defect. Only way to recover is to
> >> reflash the rootfs.
> > Is the bootup process writing to flash before you unlock it? syslogd
> > might be a culprit...
>
> Well, yes, there are some scripts that touch the fs, but that is IMHO
> not the issue here. If it would be I would get the other "unable to
> write to locked sector" error.
> Instead the fs gets permanently corrupted, i.e. data is written and the
> written data is wrong.
How are you resetting the board?
> Last night I found that the JFFS2 write cache is configured. I will
> disable that now and see if that helps - I have the impression that the
> fs may contain half-baked stuff after a write. On the other hand, the
> JFFS2 write cache is not marked as an experimental feature so I thought
> I should be safe...
It typically is if you do things correctly. You should remount the
filesystem as read-only or at the very least sync it before resetting.
The writecache gets flushed every 5 seconds or so. Depending on the
amount of data in there, if you reset without it being flushed you'll
loose data or even whole files.
josh
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Again 2.6.18-RC6 XScale P30 issues
2006-09-09 12:16 ` Nils Faerber
2006-09-09 14:10 ` Josh Boyer
@ 2006-09-09 22:00 ` Justin Clacherty
1 sibling, 0 replies; 5+ messages in thread
From: Justin Clacherty @ 2006-09-09 22:00 UTC (permalink / raw)
To: Nils Faerber; +Cc: linux-mtd
Nils Faerber wrote:
> not the issue here. If it would be I would get the other "unable to
> write to locked sector" error.
>
Yes, you're probably right about that.
> Instead the fs gets permanently corrupted, i.e. data is written and the
> written data is wrong.
>
hmmm,,,didn't realise it was getting permanently corrupted.
> Last night I found that the JFFS2 write cache is configured. I will
> disable that now and see if that helps - I have the impression that the
> fs may contain half-baked stuff after a write. On the other hand, the
> JFFS2 write cache is not marked as an experimental feature so I thought
> I should be safe...
>
Can't speak from experience here as I don't have write cache enabled,
but I don't imagine you'd lose the whole fs if you were using write
cache and lost power. I suspect you'd just lose your changes or maybe
the file that was being updated.
Justin.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2006-09-09 22:01 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-09-08 15:27 Again 2.6.18-RC6 XScale P30 issues Nils Faerber
2006-09-09 11:16 ` Justin Clacherty
2006-09-09 12:16 ` Nils Faerber
2006-09-09 14:10 ` Josh Boyer
2006-09-09 22:00 ` Justin Clacherty
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox