[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
I've been upgrading my system from 2.4.7 to 2.4.17, and I've run into a
problem with jffs2, which is being used as the root file system. My kernel
is based on 2.4.17-rmk3. (plus platform specific patch -consus1 for platform
"consus" -- which is an Assabet derivative -- ARM architecture).
I've traced it down to a call to jffs2_scan_eraseblock() -- it gets into
there and just hangs (never returns). I've been adding printk's to trace
this, and it usually calls it (jffs2_scan_eraseblock) 20-50 times before it
hangs. I've tried adding printk's into the function itself, but then it
keeps going and gets to the point where it mounts the root file system
read-only (the rest of the boot process after that doesn't work, FWIW,
stopping right when it tries to call init).
I've been printing out the block to which it progresses (variable i at the
beginning of jffs2_scan_medium()), which is how I know it's somewhere
between 20 and 50. If I reset the system and let it try again, it will
proceed to a different, but usually nearby value. An example progression of
block numbers is something like:
48 47 46 25 25 26 39 38 38 38 26 37 38 24
So it is semi-random, but with definite patterns. The boot of
2.4.7-rmk3-np1-consus2 works just fine.
Any ideas what the problem might be? Any idea how to track it down? What
other information is useful to know?
My next thoughts are to take the 2.4.7 jffs2 FS and run it under 2.4.17, or
run the 2.4.17 jffs2 under 2.4.7.
To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to firstname.lastname@example.org