CVS tags?

CVS tags?

[Andrew Dixon]

Hi Everyone,

I wanted to grab a stable version of the mtd stuff and I was wondering
which cvs tag I should use.  I'm building for a linux 2.4.16 kernel.  It
looks like maybe "core_patch_applied" is a good one to go with.  Any
thoughts?

Thanks,
Andy


-- 
Andrew Dixon
Software Engineer
Seranoa Networks
978.897.3434 x231

Re: CVS tags?

[Jörn Engel]

Hi!

> I wanted to grab a stable version of the mtd stuff and I was wondering
> which cvs tag I should use.  I'm building for a linux 2.4.16 kernel.  It
> looks like maybe "core_patch_applied" is a good one to go with.  Any
> thoughts?

Whow, someone noticed!

That tag belongs to the mtd-2_5-newpartcode-branch, which should get
included into 2.5 as soon as David has actually read and approved the
code. It is working stable for me, on four different platforms with up
to 10 mtd devices, each one being partitioned. But noone else uses the
code, as far as I know of, so the decision is yours. :-)

You should use it if you
- have more than one device that can be partitioned or
- want to get used to the new code from the beginning.

Jörn

-- 
Public Domain  - Free as in Beer
General Public - Free as in Speech
BSD License    - Free as in Enterprise
Shared Source  - Free as in "Work will make you..."

Re: CVS tags?

[Andrew Dixon]

Jörn Engel wrote:

<snip>
 It
> > looks like maybe "core_patch_applied" is a good one to go with.  Any
> > thoughts?
> 

<snip>

> You should use it if you
> - have more than one device that can be partitioned or
> - want to get used to the new code from the beginning.

As far as the MTD device goes I'm in a pretty good spot.  I put together
a driver that takes two flashes, creates one device from them, and then
partitions them the way I want.  Then I put jffs2 onto my one BIG flash
partition.  And that's where I get problems.  It takes a very long time
to mount the jffs2 partition and I'm looking for the latest jffs2 code
to try to speed things up (I recall there was some talk about long mount
times a little while back).

So what I'm looking for is faster jffs2 code.  Also, does it matter if I
grab stuff from the 2.5 branch if I'm using a 2.4 kernel?

Thanks,
Andy

-- 
Andrew Dixon
Software Engineer
Seranoa Networks
978.897.3434 x231

RE: CVS tags?

[Joakim Tjernlund]

>
> Jörn Engel wrote:
>
> <snip>
>  It
> > > looks like maybe "core_patch_applied" is a good one to go with.  Any
> > > thoughts?
> >
>
> <snip>
>
> > You should use it if you
> > - have more than one device that can be partitioned or
> > - want to get used to the new code from the beginning.
>
> As far as the MTD device goes I'm in a pretty good spot.  I put together
> a driver that takes two flashes, creates one device from them, and then
> partitions them the way I want.  Then I put jffs2 onto my one BIG flash
> partition.  And that's where I get problems.  It takes a very long time
> to mount the jffs2 partition and I'm looking for the latest jffs2 code
> to try to speed things up (I recall there was some talk about long mount
> times a little while back).
>
> So what I'm looking for is faster jffs2 code.  Also, does it matter if I
> grab stuff from the 2.5 branch if I'm using a 2.4 kernel?

You need the latest JFFS2 code to get faster mount time.
As far as I know, it works on 2.4 also. I haven't tried yet, I am on the
stable branch still, but I do run most of mount speedups and that reduced my
mount time from about 14 sec to about 4 sec(if my memory serves me right)

   Jocke

>
> Thanks,
> Andy
>

Re: CVS tags?

[David Woodhouse]

joakim.tjernlund@lumentis.se said:
>  You need the latest JFFS2 code to get faster mount time. As far as I
> know, it works on 2.4 also. I haven't tried yet, I am on the stable
> branch still, but I do run most of mount speedups and that reduced my
> mount time from about 14 sec to about 4 sec(if my memory serves me
> right) 

It works fine on 2.4. Almost all the testing is done on 2.4.

--
dwmw2

Unable to recover from CRC failiure

[Joakim Tjernlund]

Hi 

I got the following on one of our nodes:
-------------- Start log --------------
<snip>
JFFS2: Total scan time: 11.41 sec
Eep. Child "utmp" (ino #1853) of dir ino #130 doesn't exist!
VFS: Mounted root (jffs2 filesystem).
Freeing unused kernel memory: 52k init 4k openfirmware
jffs2_read_inode() on nonexistent ino 1853
INIT: version 2.78 booting
Fast boot, no file system check
none on /dev/shm type shm (rw)
Cleaning: /etc/network/ifstate.
Enabling packet forwarding: done.
Configuring network interfaces: done.
Cleaning: /tmp /var/lock /var/runfind: ./utmp: Input/output error
/etc/init.d/rcS: /var/run/utmp: Input/output error
Give root password for maintenance
(or type Control-D for normal startup):
bash-2.04# cd /var/run
bash-2.04# ls
exim  utmp
bash-2.04# ls -l
ls: utmp: Input/output error
total 0
drwxr-xr-x    1 root     root            0 May 24  2001 exim
bash-2.04# rm utmp
rm: cannot remove `utmp': Input/output error
bash-2.04# rm -f utmp
rm: cannot remove `utmp': Input/output error
bash-2.04# ls
exim  utmp
bash-2.04# ls -l
ls: utmp: Input/output error
total 0
drwxr-xr-x    1 root     root            0 May 24  2001 exim
bash-2.04# cd ..
bash-2.04# pwd
/var
bash-2.04# ls
cache  lib  local  lock  log  mail  opt  run  spool  tmp  ucd-snmp
bash-2.04# ls run
exim  utmp
bash-2.04# mv run slask
mv: cannot stat `run/utmp': Input/output error
bash-2.04# df
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/root                63744     44996     18748  71% /
bash-2.04#
-------------- End log -------------

I have no problem with getting a bad CRC on the JFFS2 FS at times, but that I am unable to get rid of
the offending file(utmp).

I am using the latest stable 2.4 branch.

Any ideas?

           Jocke
 

Re: Unable to recover from CRC failiure

[David Woodhouse]

joakim.tjernlund@lumentis.se said:
>  I have no problem with getting a bad CRC on the JFFS2 FS at times,
> but that I am unable to get rid of the offending file(utmp).

perl -e "unlink 'utmp';"

I, on the other hand, _do_ have a problem with you getting a bad CRC, if it 
means you lose data. How did it happen?

--
dwmw2

RE: Unable to recover from CRC failiure

[Joakim Tjernlund]

> joakim.tjernlund@lumentis.se said:
> >  I have no problem with getting a bad CRC on the JFFS2 FS at times,
> > but that I am unable to get rid of the offending file(utmp).
> 
> perl -e "unlink 'utmp';"

I don't have perl on this system. It's an emmbedded system. Is there another
way? Why can I not just do a rm?

> 
> I, on the other hand, _do_ have a problem with you getting a bad CRC, if it 
> means you lose data. How did it happen?

:-) According to our system test it was after installing a new version of our SW and
reboot. 
The reason I not too troubled is that we got a batch of bad Strata Flash:es a while
back ago. They carry FPO revision P and no one seems to know what revision P is. I think
it's some pre production crap. We already know that erase suspend does not work so I attribute
this CRC problem to bad flash until the HW department has proven otherwise.

    Jocke

Re: Unable to recover from CRC failiure

[David Woodhouse]

joakim.tjernlund@lumentis.se said:
>  I don't have perl on this system. It's an emmbedded system. Is there
> another way? Why can I not just do a rm? 

rm (even rm -f) insists on doing a stat() on the inode it's trying to 
unlink, and doesn't bother to do what you asked it to if that stat() fails.

A one-line C program which just does the unlink() should work.

--
dwmw2

RE: Unable to recover from CRC failiure

[Joakim Tjernlund]

> 
> joakim.tjernlund@lumentis.se said:
> >  I don't have perl on this system. It's an emmbedded system. Is there
> > another way? Why can I not just do a rm? 
> 
> rm (even rm -f) insists on doing a stat() on the inode it's trying to 
> unlink, and doesn't bother to do what you asked it to if that stat() fails.
> 
> A one-line C program which just does the unlink() should work.

I tried the one-line C program and it gave me this:
ksymoops 2.4.1 on i686 2.4.9-31.  Options used
     -V (default)
     -K (default)
     -L (default)
     -O (default)
     -m /usr/local/src/MV/commitkernel/linux-2.4.2_hhl20/System.map (specified)

Oops: kernel access of bad area, sig: 11
NIP: C007FBC8 XER: E000825B LR: C007FB0C SP: C7BF1DD0 REGS: c7bf1d20 TRAP: 0300
Using defaults from ksymoops -t elf32-little -a unknown
MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11                                
TASK = c7bf0000[99] 'unlink' Last syscall: 10 
last math 00000000 last altivec 00000000      
GPR00: 00000000 C7BF1DD0 C7BF0000 00009032 00001032 0000000C C7BF1CF4 00000000 
GPR08: C7EC2000 C7D379C0 C7EBE000 00000000 03E40000 100187F8 00000000 100B38D0 
GPR16: 100C71D0 007FFE90 007FFF00 00000000 00009032 07BF1E80 00000000 C0002838 
GPR24: C0002560 00000000 C7F3D2A0 C7FF19E0 C7D377E0 C7D378F0 C7D37AD0 C7EBE7E0 
Call backtrace:                                                                
C007FB0C C007FC34 C0040FE8 C004113C C00025BC 10000544 0FED9DBC 
00000000                                                       
Warning (Oops_read): Code line not seen, dumping what data is available

>>???; c007fbc8 <jffs2_do_unlink+2e0/338>   <=====
Trace; c007fb0c <jffs2_do_unlink+224/338>
Trace; c007fc34 <jffs2_unlink+14/24>
Trace; c0040fe8 <vfs_unlink+17c/1e8>
Trace; c004113c <sys_unlink+e8/194>
Trace; c00025bc <ret_from_syscall_1+0/b4>
Trace; 10000544 Before first symbol
Trace; 0fed9dbc Before first symbol
Trace; 00000000 Before first symbol


1 warning issued.  Results may not be reliable.


But why can't JFFS2 resolve this itself? Should it not just "delete" the bad nodes?

 Jocke 

Re: Unable to recover from CRC failiure

[David Woodhouse]

joakim.tjernlund@lumentis.se said:
> >>???; c007fbc8 <jffs2_do_unlink+2e0/338>   <===== 
> Trace; c007fb0c <jffs2_do_unlink+224/338>

Now fixed, I think.

> But why can't JFFS2 resolve this itself? Should it not just "delete"
> the bad nodes?

Possibly, yes. 

--
dwmw2

unsubscribe

[Roy Sherrill]

-----Original Message-----
From: linux-mtd-admin@lists.infradead.org
[mailto:linux-mtd-admin@lists.infradead.org]On Behalf Of Joakim
Tjernlund
Sent: Wednesday, March 27, 2002 2:47 AM
To: linux-mtd@lists.infradead.org
Subject: Unable to recover from CRC failiure


Hi

I got the following on one of our nodes:
-------------- Start log --------------
<snip>
JFFS2: Total scan time: 11.41 sec
Eep. Child "utmp" (ino #1853) of dir ino #130 doesn't exist!
VFS: Mounted root (jffs2 filesystem).
Freeing unused kernel memory: 52k init 4k openfirmware
jffs2_read_inode() on nonexistent ino 1853
INIT: version 2.78 booting
Fast boot, no file system check
none on /dev/shm type shm (rw)
Cleaning: /etc/network/ifstate.
Enabling packet forwarding: done.
Configuring network interfaces: done.
Cleaning: /tmp /var/lock /var/runfind: ./utmp: Input/output error
/etc/init.d/rcS: /var/run/utmp: Input/output error
Give root password for maintenance
(or type Control-D for normal startup):
bash-2.04# cd /var/run
bash-2.04# ls
exim  utmp
bash-2.04# ls -l
ls: utmp: Input/output error
total 0
drwxr-xr-x    1 root     root            0 May 24  2001 exim
bash-2.04# rm utmp
rm: cannot remove `utmp': Input/output error
bash-2.04# rm -f utmp
rm: cannot remove `utmp': Input/output error
bash-2.04# ls
exim  utmp
bash-2.04# ls -l
ls: utmp: Input/output error
total 0
drwxr-xr-x    1 root     root            0 May 24  2001 exim
bash-2.04# cd ..
bash-2.04# pwd
/var
bash-2.04# ls
cache  lib  local  lock  log  mail  opt  run  spool  tmp  ucd-snmp
bash-2.04# ls run
exim  utmp
bash-2.04# mv run slask
mv: cannot stat `run/utmp': Input/output error
bash-2.04# df
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/root                63744     44996     18748  71% /
bash-2.04#
-------------- End log -------------

I have no problem with getting a bad CRC on the JFFS2 FS at times, but that
I am unable to get rid of
the offending file(utmp).

I am using the latest stable 2.4 branch.

Any ideas?

           Jocke



______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: CVS tags?

[Jörn Engel]

On Mon, 25 March 2002 09:48:36 -0500, Andrew Dixon wrote:
> > You should use it if you
> > - have more than one device that can be partitioned or
> > - want to get used to the new code from the beginning.
> 
> As far as the MTD device goes I'm in a pretty good spot.  I put together
> a driver that takes two flashes, creates one device from them, and then
> partitions them the way I want.  Then I put jffs2 onto my one BIG flash
> partition.

Thought so. most people really don't need this stuff, as all the flash
will be in one big partition (minus bootloader). But if you add nvram,
slram or such, you already have two devices. Add partitioning and
things get messy. :-)
You really should try my code, stumble and demand better
documentation. As long as noone asks for it...

Jörn

-- 
Treating your users as co-developers is your least-hassle route to
rapid code improvement and effective debugging.
-- Eric Raymond in "The cathedral and the bazaar"

Re: CVS tags?

[David Woodhouse]

joern@wohnheim.fh-wedel.de said:
> Whow, someone noticed!
> That tag belongs to the mtd-2_5-newpartcode-branch, which should get
> included into 2.5 as soon as David has actually read and approved the
> code. It is working stable for me, on four different platforms with up
> to 10 mtd devices, each one being partitioned. But noone else uses the
> code, as far as I know of, so the decision is yours. :-) 

I will start paying attention to this soon, I promise. In the meantime, it 
would be good if people could start testing it. 

The current plan, such as there is one, is to wait for Marcelo to 
release 2.4.19 with the MTD fixes that are already in his tree, then send 
the remainder of the new code which I didn't want to go into such a late 
prerelease. Then I'll update the code to build in 2.5 and use all the stuff 
in compatmac.h for the 2.4 build, and send that to Linus. 

At that point, I'll be looking to merge Jörn's partition code - so if it 
doesn't work for you, make sure you've squealed by that point.

--
dwmw2