RE: seeking help on JFFS2

RE: seeking help on JFFS2

[Junping Zhang]

David,

    I changed mtd.h to make unpoint take four params, it doesn't seem to
have any effect.

    So here is what I have:
         linux-2.4.19 + shared-zlib patch + mtd-20021022 snapshot, but I
used the original
    patchin.sh, so JFFS2 in 2.4.19 is used.
         It always crashed at the same point in kernel.

    Here is the oops, ksymoops result and the source lines.

    Thanks  a lot  -- Junping

This is the oops message
========================
Oops: kernel access of bad area, sig: 11
NIP: C00E0008 XER: 00000000 LR: C00DFFB4 SP: C3E0DCC0 REGS: c3e0dc10 TRAP:
0300    Not tainted
MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: 00000005, DSISR: 20000000
TASK = c3e0c000[32] 'cp' Last syscall: 4
last math c3e0c000 last altivec 00000000
GPR00: C00E0004 C3E0DCC0 C3E0C000 80808080 C3F88560 C3F885E0 C3E0DCD4
00000010
GPR08: C3E0DDB0 00000000 00000000 00000010 00000000 10055EF0 00000000
C3ACFEC0
GPR16: C3E0DEBC C01CE670 C01CE670 00001000 C3E0DDB0 00000010 00000000
C3F885E0
GPR24: 0012E1D8 80808080 00005DDA 00000000 0012E1D8 C3F8861C C3F88560
00000010
Call backtrace:
C0013610 C00DDD38 C00E22B8 C00A62CC C00A6484 C00A2378 C002A024
C00375A4 C0005BBC FFFFFFFF 0FF2463C 0FF253A0 0FF1A1B0 1002FB8C
1002F874 1002F6A0 100056C4 1002F2C8 1002EF18 0FECEF70 00000000
Kernel panic: Aiee, killing interrupt handler!
In interrupt handler - not syncing
 <0>Rebooting in 180 seconds..


This is the oops through ksymoops 
(on my mount nfs. MTD & JFFS2 are compiled in, so no modules)
=============================================================
# ./ksymoops -v ./vmlinux -m ./System.map oops.now 
ksymoops 2.4.1 on ppc 2.4.19.  Options used
     -v ./vmlinux (specified)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.4.19/ (default)
     -m ./System.map (specified)

/usr/bin/nm: not found
Error (pclose_local): read_nm_symbols pclose failed 0xff00
Warning (read_vmlinux): no kernel symbols in vmlinux, is ./vmlinux a valid
vmlinux file?
No modules in ksyms, skipping objects
Warning (read_lsmod): no symbols in lsmod, is /proc/modules a valid lsmod
file?
Warning (compare_maps): mismatch on symbol xchg_u32  , ksyms_base says
c000d300, System.map says c0008yOops: kernel access of bad area, sig: 11
NIP: C00E0008 XER: 00000000 LR: C00DFFB4 SP: C3E0DCC0 REGS: c3e0dc10 TRAP:
0300    Not tainted
Using defaults from ksymoops -t elf32-powerpc -a powerpc:common
MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
TASK = c3e0c000[32] 'cp' Last syscall: 4 
last math c3e0c000 last altivec 00000000
GPR00: C00E0004 C3E0DCC0 C3E0C000 80808080 C3F88560 C3F885E0 C3E0DCD4
00000010 
GPR08: C3E0DDB0 00000000 00000000 00000010 00000000 10055EF0 00000000
C3ACFEC0 
GPR16: C3E0DEBC C01CE670 C01CE670 00001000 C3E0DDB0 00000010 00000000
C3F885E0 
GPR24: 0012E1D8 80808080 00005DDA 00000000 0012E1D8 C3F8861C C3F88560
00000010 
Call backtrace: 
C0013610 C00DDD38 C00E22B8 C00A62CC C00A6484 C00A2378 C002A024 
C00375A4 C0005BBC FFFFFFFF 0FF2463C 0FF253A0 0FF1A1B0 1002FB8C 
1002F874 1002F6A0 100056C4 1002F2C8 1002EF18 0FECEF70 00000000 
Kernel panic: Aiee, killing interrupt handler!
Warning (Oops_read): Code line not seen, dumping what data is available

>>NIP; c00e0008 <do_read_onechip+b8/4ec>   <=====
Trace; c0013610 <call_console_drivers+a0/168>
Trace; c00ddd38 <cfi_intelext_read+b4/100>
Trace; c00e22b8 <part_read+68/a0>
Trace; c00a62cc <writecheck+34/12c>
Trace; c00a6484 <jffs2_write_dnode+c0/2b4>
Trace; c00a2378 <jffs2_commit_write+364/614>
Trace; c002a024 <generic_file_write+49c/7ac>
Trace; c00375a4 <sys_write+bc/150>
Trace; c0005bbc <ret_from_syscall_1+0/b4>
Trace; ffffffff <END_OF_CODE+3fe0f237/????>
Trace; 0ff2463c Before first symbol
Trace; 0ff253a0 Before first symbol
Trace; 0ff1a1b0 Before first symbol
Trace; 1002fb8c Before first symbol
Trace; 1002f874 Before first symbol
Trace; 1002f6a0 Before first symbol
Trace; 100056c4 Before first symbol
Trace; 1002f2c8 Before first symbol
Trace; 1002ef18 Before first symbol
Trace; 0fecef70 Before first symbol
Trace; 00000000 Before first symbol


4 warnings and 1 error issued.  Results may not be reliable.

This is the source positions for the oops (for the last four)
=============================================================
I don't know how call_console_drivers got in the trace ...
(gdb) l *0xc00e0008
0xc00e0008 is in do_read_onechip (cfi_cmdset_0001.c:473).
468     /* Check that the chip's ready to talk to us.
469      * If it's in FL_ERASING state, suspend it and make it talk now.
470      */
471     switch (chip->state) {
472     case FL_ERASING:
473         if (!(((struct cfi_pri_intelext
*)cfi->cmdset_priv)->FeatureSupport & 2))
474             goto sleep; /* We don't support erase suspend */
475         
476         cfi_write (map, CMD(0xb0), cmd_addr);
477         /* If the flash has finished erasing, then 'erase suspend'
(gdb) l *0xc0013610
0xc0013610 is in call_console_drivers (printk.c:379).
374                 start_print = cur_index;
375                 break;
376             }
377         }
378     }
379     _call_console_drivers(start_print, end, msg_level);
380 }
381 
382 static void emit_log_char(char c)
383 {
(gdb) l *0xc00ddd38         
0xc00ddd38 is in cfi_intelext_read (cfi_cmdset_0001.c:607).
602         if ((len + ofs -1) >> cfi->chipshift)
603             thislen = (1<<cfi->chipshift) - ofs;
604         else
605             thislen = len;
606 
607         ret = do_read_onechip(map, &cfi->chips[chipnum], ofs, thislen,
buf);
608         if (ret)
609             break;
610 
611         *retlen += thislen;
(gdb) l *0xc00e22b8
0xc00e22b8 is in part_read (mtdpart.c:57).
52      struct mtd_part *part = PART(mtd);
53      if (from >= mtd->size)
54          len = 0;
55      else if (from + len > mtd->size)
56          len = mtd->size - from;
57      return part->master->read (part->master, from + part->offset, 
58                      len, retlen, buf);
59  }
60  
61  static int part_point (struct mtd_info *mtd, loff_t from, size_t len, 
(gdb)


> -----Original Message-----
> From:	David Woodhouse [SMTP:dwmw2@infradead.org]
> Sent:	Tuesday, November 05, 2002 4:37 PM
> To:	Junping Zhang
> Subject:	Re: seeking help on JFFS2 
> 
> 
> JZhang@erinc.com said:
> >   Here is the oops message through ksymoops: 
> 
> Can you show the whole oops, preferably also using gdb to identify the 
> precise line of code.
> 
> --
> dwmw2
> 

Re: seeking help on JFFS2

[David Woodhouse]

JZhang@erinc.com said:
> 0xc00e0008 is in do_read_onechip (cfi_cmdset_0001.c:473).
> 473         if (!(((struct cfi_pri_intelext*)cfi->cmdset_priv)->FeatureSupport & 2))

Why didn't you say so before? :)

cvs up


--
dwmw2

RE: seeking help on JFFS2

[Joakim Tjernlund]

David

Why does JEDEC end up in cfi_cmdset_0001.c?
If it should end up in cfi_cmdset_0001.c, why does it not set cmdset_priv?

 Jocke
> 
> 
> JZhang@erinc.com said:
> > 0xc00e0008 is in do_read_onechip (cfi_cmdset_0001.c:473).
> > 473         if (!(((struct cfi_pri_intelext*)cfi->cmdset_priv)->FeatureSupport & 2))
> 
> Why didn't you say so before? :)
> 
> cvs up
> 

Re: seeking help on JFFS2

[David Woodhouse]

joakim.tjernlund@lumentis.se said:
> Why does JEDEC end up in cfi_cmdset_0001.c? 

CFI only defines how you _probe_ chips. The actual Intel command set is the
same as it's always been, likewise the AMD one. This is why jedec_probe
passes control to the CFI drivers and all the other chip drivers are
deprecated.

> If it should end up in cfi_cmdset_0001.c, why does it not set cmdset_priv? 

IIRC because cmdset_priv is just a copy of the extended CFI table from the 
chip, which we don't have in the case of a non-CFI chip. It's that which 
holds the details of whether we can do erase suspend, etc.

Perhaps the table in jedec_probe should also contain a 'fake' extended CFI 
table. More sensibly, perhaps we should have a structure in the cmdset_priv 
with just the flags we care about, and at probe time either parse the 
extended CFI table or copy those flags from the jedec_probe table.

For now, we just assume jedec-probed chips have none of the extended 
features.

--
dwmw2

RE: seeking help on JFFS2

[Junping Zhang]

Thanks a lot. That one-line change worked, now under my cp/rm stress test,
JFFS2 doesn't
crash anymore, but I still crashed finally when I overflowed the file
system. My boss just asked
me to work on something else first, when I come back, I will generate the
dump for the new
oops.

Also, shouldn't unpoint() in mtd.h take four params? and MTD_UNPOINT() macro
doesn't seem
to be used by anyone.

Thanks everyone

- Junping

> -----Original Message-----
> From:	David Woodhouse [SMTP:dwmw2@infradead.org]
> Sent:	Wednesday, November 06, 2002 11:15 AM
> To:	Junping Zhang
> Cc:	linux-mtd@lists.infradead.org
> Subject:	Re: seeking help on JFFS2 
> 
> 
> JZhang@erinc.com said:
> > 0xc00e0008 is in do_read_onechip (cfi_cmdset_0001.c:473).
> > 473         if (!(((struct
> cfi_pri_intelext*)cfi->cmdset_priv)->FeatureSupport & 2))
> 
> Why didn't you say so before? :)
> 
> cvs up
> 
> 
> --
> dwmw2
> 

RE: seeking help on JFFS2

[Junping Zhang]

I specified CONFIG_MTD_CFI_INTELEXT only. Here is that section in .config
-----------------------------------------------------------
# CONFIG_MTD_CFI is not set
CONFIG_MTD_JEDECPROBE=y
CONFIG_MTD_GEN_PROBE=y
CONFIG_MTD_CFI_ADV_OPTIONS=y
CONFIG_MTD_CFI_NOSWAP=y
# CONFIG_MTD_CFI_BE_BYTE_SWAP is not set
# CONFIG_MTD_CFI_LE_BYTE_SWAP is not set
CONFIG_MTD_CFI_GEOMETRY=y
# CONFIG_MTD_CFI_B1 is not set
# CONFIG_MTD_CFI_B2 is not set
CONFIG_MTD_CFI_B4=y
# CONFIG_MTD_CFI_B8 is not set
# CONFIG_MTD_CFI_I1 is not set
# CONFIG_MTD_CFI_I2 is not set
CONFIG_MTD_CFI_I4=y
# CONFIG_MTD_CFI_I8 is not set
CONFIG_MTD_CFI_INTELEXT=y
# CONFIG_MTD_CFI_AMDSTD is not set
# CONFIG_MTD_CFI_STAA is not set
# CONFIG_MTD_RAM is not set
CONFIG_MTD_ROM=y
# CONFIG_MTD_ABSENT is not set
# CONFIG_MTD_OBSOLETE_CHIPS is not set
--------------------------------------

Since in xconfig, it has Intel/Sharp in the option together and my chips
have Sharp printed on it, I guess
it's right. Also, I referenced the .config file from Christian, who made
JFFS2 work for 2.4.4 (from denx) and
some older version of mtd, so I think the setup is ok.

Before I chase the source of the crashed trace, I want to look at something
I had to change to make it
compile, now seems to co-relate with my crash. I had to change mtdpart.c's
part_unpoint() to make
unpoint() only pass two parameters because mtd_info structure dictates it,
but in cfi_cmdset_0001.c,
the do_unpoint, which has four params, is assigned to unpoint func ptr
(warning in compile). It looks wrong
to me, and all those files are sym-linked from mtd-20021022 snapshot, can
you guys verify it's really
an inconsistancy, not my mistake?

When I stress test JFFS2 subsystem from 2.4.19 kernel, it seems to me it
always crashs at the beginning
of the 2nd cycle. I have a 7M JFFS2, and I copy 3M stuff on it, remove it,
and do it again, it always fails at
the 4th time, which, onsidering zlib compression on binary files, seems to
be the next cycle.

I will later provide the oops with the source lines.

Thanks a lot

- Junping

> -----Original Message-----
> From:	Jörn Engel [SMTP:joern@wohnheim.fh-wedel.de]
> Sent:	Tuesday, November 05, 2002 4:09 PM
> To:	Junping Zhang
> Cc:	linux-mtd@lists.infradead.org
> Subject:	Re: seeking help on JFFS2
> 
> On Tue, 5 November 2002 14:56:56 -0500, Junping Zhang wrote:
> > 
> >    I just tested 2.4.19 with shared-zlib patch, same behavior. I could
> use
> > the JFFS2 system,
> > but it will eventually crash after a while.
> > 
> >    The flash chip is original from Motorola: 8M, 80 pin SIMM, SM73228. I
> > used Christian's
> > map file. Since JFFS works on it without any problem, should I safely
> assume
> > the MTD layer
> > is correct?
> 
> Ok, glancing at the spec, it said something about being compatible to
> Am29F040 chips, which use the amd command set. And looking back at the
> trace, we see
>     Trace; c00df668 <cfi_intelext_read+b4/100>
>                          ^^^^^
> This is strange.
> 
> Have you configured only CONFIG_MTD_CFI_AMDSTD, only
> CONFIG_MTD_CFI_INTELEXT or both?
> 
> Jörn
> 
> -- 
> The competent programmer is fully aware of the strictly limited size of
> his own skull; therefore he approaches the programming task in full
> humility, and among other things he avoids clever tricks like the plague. 
> -- Edsger W. Dijkstra

RE: seeking help on JFFS2

[Junping Zhang]

Jörn,

   I just tested 2.4.19 with shared-zlib patch, same behavior. I could use
the JFFS2 system,
but it will eventually crash after a while.

   The flash chip is original from Motorola: 8M, 80 pin SIMM, SM73228. I
used Christian's
map file. Since JFFS works on it without any problem, should I safely assume
the MTD layer
is correct?

    I appreciate your thought, but my company won't let me give people
direct access. I will
check out the latest MTD from cvs tonight and give it a try tomorrow.

    Thanks

-   Junping

> -----Original Message-----
> From:	Jörn Engel [SMTP:joern@wohnheim.fh-wedel.de]
> Sent:	Tuesday, November 05, 2002 2:31 PM
> To:	Junping Zhang
> Cc:	linux-mtd@lists.infradead.org
> Subject:	Re: seeking help on JFFS2
> 
> On Tue, 5 November 2002 12:39:31 -0500, Junping Zhang wrote:
> > Yes, the minor number is 2, and I checked mkfs.jffs2 source, hex is ok.
> I
> > also tried with
> > the method you mentioned, the crashed happened right away.
> 
> Ok.
> 
> > I just tried using the stock JFFS2 in 2.4.18 kernel. It actually got me
> > further than JFFS2
> > in my mtd-20021022 snapshot, I could use either image or direct mount to
> > create JFFS2,
> > but it still crashed under stress test. On the other hand, JFFS works
> quite
> > well.
> 
> Ok.
> 
> > Does stock 2.4.19 have a stable JFFS2 without patch? I downloaded a
> > shared-zlib patch
> > for 2.4.19-pre10 but am not sure it will fix my JFFS2 problem.
> 
> 2.4.19 should have a stable jffs2, as should 2.4.18. You can try
> 2.4.19, but I don't expect any better behaviour.
> 
> What flashes do you exactly use? And can you provide ssh login to the
> development host?
> 
> Jörn
> 
> -- 
> If you're willing to restrict the flexibility of your approach,
> you can almost always do something better.
> -- John Carmack

Re: seeking help on JFFS2

[Jörn Engel]

On Tue, 5 November 2002 14:56:56 -0500, Junping Zhang wrote:
> 
>    I just tested 2.4.19 with shared-zlib patch, same behavior. I could use
> the JFFS2 system,
> but it will eventually crash after a while.
> 
>    The flash chip is original from Motorola: 8M, 80 pin SIMM, SM73228. I
> used Christian's
> map file. Since JFFS works on it without any problem, should I safely assume
> the MTD layer
> is correct?

Ok, glancing at the spec, it said something about being compatible to
Am29F040 chips, which use the amd command set. And looking back at the
trace, we see
    Trace; c00df668 <cfi_intelext_read+b4/100>
                         ^^^^^
This is strange.

Have you configured only CONFIG_MTD_CFI_AMDSTD, only
CONFIG_MTD_CFI_INTELEXT or both?

Jörn

-- 
The competent programmer is fully aware of the strictly limited size of
his own skull; therefore he approaches the programming task in full
humility, and among other things he avoids clever tricks like the plague. 
-- Edsger W. Dijkstra

RE: seeking help on JFFS2

[Junping Zhang]

Yes, the minor number is 2, and I checked mkfs.jffs2 source, hex is ok. I
also tried with
the method you mentioned, the crashed happened right away.

I just tried using the stock JFFS2 in 2.4.18 kernel. It actually got me
further than JFFS2
in my mtd-20021022 snapshot, I could use either image or direct mount to
create JFFS2,
but it still crashed under stress test. On the other hand, JFFS works quite
well.

Does stock 2.4.19 have a stable JFFS2 without patch? I downloaded a
shared-zlib patch
for 2.4.19-pre10 but am not sure it will fix my JFFS2 problem.

Thanks a lot

- Junping

> -----Original Message-----
> From:	Jörn Engel [SMTP:joern@wohnheim.fh-wedel.de]
> Sent:	Tuesday, November 05, 2002 11:41 AM
> To:	Junping Zhang
> Cc:	linux-mtd@lists.infradead.org
> Subject:	Re: seeking help on JFFS2
> 
> >         eraseall /dev/mtd1
> >         mount -t jffs /dev/mtdblock1 /mnt/flash
> 
> Just to be on the safe side, can you make sure that /dev/mtd1 has minor
> number 2? Common problem.
> 
> > 
> >         mkfs.jffs2 -dipc -e0x40000 -p0x700000 -b -o /opt/ipc.jffs2
>                              ^^^^^^^   ^^^^^^^^
> Does this really work? I remember that mkfs.jffs2 once didn't
> understand hex and you had to pass it the decimal numbers. Can you
> check that?
> 
> > 
> >   Any ideas? I have been reading the mailing list archive and could
> > not find the answer to this.
> 
> jffs2 also mounts partitions that are completely erased. You can
> eraseall /dev/mtd1 and then mount /dev/mtdblock1. That should work
> fine.
> 
> Jörn
> 
> -- 
> "Translations are and will always be problematic. They inflict violence 
> upon two languages." (translation from German)

Re: seeking help on JFFS2

[Jörn Engel]

On Tue, 5 November 2002 12:39:31 -0500, Junping Zhang wrote:
> Yes, the minor number is 2, and I checked mkfs.jffs2 source, hex is ok. I
> also tried with
> the method you mentioned, the crashed happened right away.

Ok.

> I just tried using the stock JFFS2 in 2.4.18 kernel. It actually got me
> further than JFFS2
> in my mtd-20021022 snapshot, I could use either image or direct mount to
> create JFFS2,
> but it still crashed under stress test. On the other hand, JFFS works quite
> well.

Ok.

> Does stock 2.4.19 have a stable JFFS2 without patch? I downloaded a
> shared-zlib patch
> for 2.4.19-pre10 but am not sure it will fix my JFFS2 problem.

2.4.19 should have a stable jffs2, as should 2.4.18. You can try
2.4.19, but I don't expect any better behaviour.

What flashes do you exactly use? And can you provide ssh login to the
development host?

Jörn

-- 
If you're willing to restrict the flexibility of your approach,
you can almost always do something better.
-- John Carmack

Re: seeking help on JFFS2

[Jeffrey Lim]

On Tue, 5 Nov 2002 17:41:26 +0100, "Jörn Engel"
<joern@wohnheim.fh-wedel.de> said:
> On Tue, 5 November 2002 08:40:31 -0500, Junping Zhang wrote:
> 
> >     (b) I tried mkfs.jffs2 on both target and my x86 host (with
> >         big-endian option)
> > 
> >         mkfs.jffs2 -dipc -e0x40000 -p0x700000 -b -o /opt/ipc.jffs2
>                              ^^^^^^^   ^^^^^^^^
> Does this really work? I remember that mkfs.jffs2 once didn't
> understand hex and you had to pass it the decimal numbers. Can you
> check that?
> 

I believe there shouldnt be a problem with passing hex to it - the code
uses strtol() to recognize both decimal and hex.

-jf

 
--
  "It's an extraordinary world!" - jfsworld <at> fastmail.fm
 
 

Re: seeking help on JFFS2

[Jörn Engel]

On Tue, 5 November 2002 17:17:12 +0000, Jeffrey Lim wrote:
> I believe there shouldnt be a problem with passing hex to it - the code
> uses strtol() to recognize both decimal and hex.

Makes sense. Hm. I wonder what has hit me back then. Strange.

Jörn

-- 
A surrounded army must be given a way out.
-- Sun Tzu

seeking help on JFFS2

[Junping Zhang]

Hi,

  I am new to MTD/JFFS2. Thanks to Christian Gagnaraud's patch, I got MTD
working, but
everytime I use JFFS2 on top of it, I get a kernel oops: "Oops: kernel
access of 
bad area, sig: 11"

  Here is my setup:
    board:      MPC8260ADS
    bootloader: ppcboot-1.1.6
    kernel:     2.4.18
    MTD/JFFS2:  mtd-snapshot-20021022.tar.bz2
    RAM:        64M
    flash:      8M
    root disk:  ramdisk of 16M
    host:       x86 with cross-compiler

  Here is the message of MTD from kernel startup:
    Found: Intel 28F016S5
    MPC8260ADS Bank 0: Found 4 x8 devices at 0x0 in 32-bit mode
    Using word write method
    MPC8260ADS flash bank 0: Using static image partition definition
    Creating 4 MTD partitions on "MPC8260ADS Bank 0":
    0x00000000-0x00700000 : "jffs2-root"
    mtd: Giving out device 1 to jffs2-root
    0x00700000-0x00740000 : "ppcboot"
    mtd: Giving out device 2 to ppcboot
    0x00740000-0x00780000 : "environment"
    mtd: Giving out device 3 to environment
    0x00780000-0x00800000 : "spare"
    mtd: Giving out device 4 to spare

  Here is how I made oops happen:
    eraseall /dev/mtd1
    mount -t jffs2 /dev/mtdblock1 /mnt/flash
    cp -R sbin /mnt/flash

  Here is the oops message through ksymoops:
    >>NIP; c00e1938 <do_read_onechip+b8/4ec>   <=====
    Trace; c0011480 <printk+15c/1b4>
    Trace; c00df668 <cfi_intelext_read+b4/100>
    Trace; c00e3be8 <part_read+68/a0>
    Trace; c00a2ba0 <jffs2_mark_node_obsolete+468/88c>
    Trace; c00a1fe0 <jffs2_do_reserve_space+264/55c>
    Trace; c00a1b90 <jffs2_reserve_space+1b8/2d8>
    Trace; c009df2c <jffs2_mkdir+54/454>
    Trace; c0041d84 <vfs_mkdir+10c/130>
    Trace; c0041e8c <sys_mkdir+e4/108>
    Trace; c0003ddc <ret_from_syscall_1+0/b4>
    Trace; 1002f4f0 Before first symbol
    Trace; 100056c4 Before first symbol
    Trace; 1002f2c8 Before first symbol
    Trace; 1002ef18 Before first symbol
    Trace; 0fecef70 Before first symbol
    Trace; 00000000 Before first symbol

  Here are what I have tried:
    (a) I tried plain JFFS on MTD, and it works. The steps I use:

        eraseall /dev/mtd1
        mount -t jffs /dev/mtdblock1 /mnt/flash
        
        I can then copy/edit/delete from it, and diff shows that
        the data is consistant.

        So I think MTD layer is fine and the configuration on MTD
        part (.config) is fine.

    (b) I tried mkfs.jffs2 on both target and my x86 host (with
        big-endian option)

        mkfs.jffs2 -dipc -e0x40000 -p0x700000 -b -o /opt/ipc.jffs2

        I then cp it on a mtd device with:
        eraseall /dev/mtd1
        cp /mnt/nfs/ipc.jffs2 /dev/mtd1

        the "cp" goes fine, but when I tried to mount & use the
        JFFS2 system, within one or two commands, it will give me
        the oops with the same reason "kernel access of bad area"

        But if I now boot into ppcboot(with JFFS2 capability compiled
        in), ppcboot can recognize my JFFS2 files just fine, which
        lead me to believe the linux JFFS2 subsystem is the problem.

    (c) I then tried disabling the compression for JFFS2 by forcing
        return of JFFS2_COMPR_NONE from jffs2_compress() to see if 
        zlib is a problem. It doesn't seem to have any effect.

  Any ideas? I have been reading the mailing list archive and could
not find the answer to this.

  Thanks a lot


- Junping

Re: seeking help on JFFS2

[Jörn Engel]

On Tue, 5 November 2002 08:40:31 -0500, Junping Zhang wrote:
> 
>   I am new to MTD/JFFS2. Thanks to Christian Gagnaraud's patch, I got MTD
> working, but
> everytime I use JFFS2 on top of it, I get a kernel oops: "Oops: kernel
> access of 
> bad area, sig: 11"
> 
>   Here is my setup:
>     board:      MPC8260ADS
>     bootloader: ppcboot-1.1.6
>     kernel:     2.4.18
>     MTD/JFFS2:  mtd-snapshot-20021022.tar.bz2
>     RAM:        64M
>     flash:      8M
>     root disk:  ramdisk of 16M
>     host:       x86 with cross-compiler
> 
>   Here is the message of MTD from kernel startup:
>     Found: Intel 28F016S5
>     MPC8260ADS Bank 0: Found 4 x8 devices at 0x0 in 32-bit mode
>     Using word write method
>     MPC8260ADS flash bank 0: Using static image partition definition
>     Creating 4 MTD partitions on "MPC8260ADS Bank 0":
>     0x00000000-0x00700000 : "jffs2-root"
>     mtd: Giving out device 1 to jffs2-root
>     0x00700000-0x00740000 : "ppcboot"
>     mtd: Giving out device 2 to ppcboot
>     0x00740000-0x00780000 : "environment"
>     mtd: Giving out device 3 to environment
>     0x00780000-0x00800000 : "spare"
>     mtd: Giving out device 4 to spare
> 
>   Here is how I made oops happen:
>     eraseall /dev/mtd1
>     mount -t jffs2 /dev/mtdblock1 /mnt/flash
>     cp -R sbin /mnt/flash
> 
>   Here is the oops message through ksymoops:
>     >>NIP; c00e1938 <do_read_onechip+b8/4ec>   <=====
>     Trace; c0011480 <printk+15c/1b4>
>     Trace; c00df668 <cfi_intelext_read+b4/100>
>     Trace; c00e3be8 <part_read+68/a0>
>     Trace; c00a2ba0 <jffs2_mark_node_obsolete+468/88c>
>     Trace; c00a1fe0 <jffs2_do_reserve_space+264/55c>
>     Trace; c00a1b90 <jffs2_reserve_space+1b8/2d8>
>     Trace; c009df2c <jffs2_mkdir+54/454>
>     Trace; c0041d84 <vfs_mkdir+10c/130>
>     Trace; c0041e8c <sys_mkdir+e4/108>
>     Trace; c0003ddc <ret_from_syscall_1+0/b4>
>     Trace; 1002f4f0 Before first symbol
>     Trace; 100056c4 Before first symbol
>     Trace; 1002f2c8 Before first symbol
>     Trace; 1002ef18 Before first symbol
>     Trace; 0fecef70 Before first symbol
>     Trace; 00000000 Before first symbol
> 
>   Here are what I have tried:
>     (a) I tried plain JFFS on MTD, and it works. The steps I use:
> 
>         eraseall /dev/mtd1
>         mount -t jffs /dev/mtdblock1 /mnt/flash

Just to be on the safe side, can you make sure that /dev/mtd1 has minor
number 2? Common problem.

>         I can then copy/edit/delete from it, and diff shows that
>         the data is consistant.
> 
>         So I think MTD layer is fine and the configuration on MTD
>         part (.config) is fine.
> 
>     (b) I tried mkfs.jffs2 on both target and my x86 host (with
>         big-endian option)
> 
>         mkfs.jffs2 -dipc -e0x40000 -p0x700000 -b -o /opt/ipc.jffs2
                             ^^^^^^^   ^^^^^^^^
Does this really work? I remember that mkfs.jffs2 once didn't
understand hex and you had to pass it the decimal numbers. Can you
check that?

>         I then cp it on a mtd device with:
>         eraseall /dev/mtd1
>         cp /mnt/nfs/ipc.jffs2 /dev/mtd1
> 
>         the "cp" goes fine, but when I tried to mount & use the
>         JFFS2 system, within one or two commands, it will give me
>         the oops with the same reason "kernel access of bad area"
> 
>         But if I now boot into ppcboot(with JFFS2 capability compiled
>         in), ppcboot can recognize my JFFS2 files just fine, which
>         lead me to believe the linux JFFS2 subsystem is the problem.
> 
>     (c) I then tried disabling the compression for JFFS2 by forcing
>         return of JFFS2_COMPR_NONE from jffs2_compress() to see if 
>         zlib is a problem. It doesn't seem to have any effect.
> 
>   Any ideas? I have been reading the mailing list archive and could
> not find the answer to this.

jffs2 also mounts partitions that are completely erased. You can
eraseall /dev/mtd1 and then mount /dev/mtdblock1. That should work
fine.

Jörn

-- 
"Translations are and will always be problematic. They inflict violence 
upon two languages." (translation from German)

Re: seeking help on JFFS2

[Darren Freeman]

Hi Junping,

I worked for Motorola a year ago and wrote drivers for the MPC8260 using
the MPC8260ADS board with TCOM board attached.

We used vxWorks in that project so I can't help you here. But I would be
interested to hear how things are going anyway =) Now I'm working with
the Altera EPXA10 dev board, running ARM-Linux (of course!).

I mainly worked on fast ethernet and ATM.

Have fun,
Darren Freeman


On Tue, 2002-11-05 at 13:40, Junping Zhang wrote:
> Hi,
> 
>   I am new to MTD/JFFS2. Thanks to Christian Gagnaraud's patch, I got MTD
> working, but
> everytime I use JFFS2 on top of it, I get a kernel oops: "Oops: kernel
> access of 
> bad area, sig: 11"
> 
>   Here is my setup:
>     board:      MPC8260ADS
>     bootloader: ppcboot-1.1.6
>     kernel:     2.4.18
>     MTD/JFFS2:  mtd-snapshot-20021022.tar.bz2
>     RAM:        64M
>     flash:      8M
>     root disk:  ramdisk of 16M
>     host:       x86 with cross-compiler
> 
>   Here is the message of MTD from kernel startup:
>     Found: Intel 28F016S5
>     MPC8260ADS Bank 0: Found 4 x8 devices at 0x0 in 32-bit mode
>     Using word write method
>     MPC8260ADS flash bank 0: Using static image partition definition
>     Creating 4 MTD partitions on "MPC8260ADS Bank 0":
>     0x00000000-0x00700000 : "jffs2-root"
>     mtd: Giving out device 1 to jffs2-root
>     0x00700000-0x00740000 : "ppcboot"
>     mtd: Giving out device 2 to ppcboot
>     0x00740000-0x00780000 : "environment"
>     mtd: Giving out device 3 to environment
>     0x00780000-0x00800000 : "spare"
>     mtd: Giving out device 4 to spare
> 
>   Here is how I made oops happen:
>     eraseall /dev/mtd1
>     mount -t jffs2 /dev/mtdblock1 /mnt/flash
>     cp -R sbin /mnt/flash
> 
>   Here is the oops message through ksymoops:
>     >>NIP; c00e1938 <do_read_onechip+b8/4ec>   <=====
>     Trace; c0011480 <printk+15c/1b4>
>     Trace; c00df668 <cfi_intelext_read+b4/100>
>     Trace; c00e3be8 <part_read+68/a0>
>     Trace; c00a2ba0 <jffs2_mark_node_obsolete+468/88c>
>     Trace; c00a1fe0 <jffs2_do_reserve_space+264/55c>
>     Trace; c00a1b90 <jffs2_reserve_space+1b8/2d8>
>     Trace; c009df2c <jffs2_mkdir+54/454>
>     Trace; c0041d84 <vfs_mkdir+10c/130>
>     Trace; c0041e8c <sys_mkdir+e4/108>
>     Trace; c0003ddc <ret_from_syscall_1+0/b4>
>     Trace; 1002f4f0 Before first symbol
>     Trace; 100056c4 Before first symbol
>     Trace; 1002f2c8 Before first symbol
>     Trace; 1002ef18 Before first symbol
>     Trace; 0fecef70 Before first symbol
>     Trace; 00000000 Before first symbol
> 
>   Here are what I have tried:
>     (a) I tried plain JFFS on MTD, and it works. The steps I use:
> 
>         eraseall /dev/mtd1
>         mount -t jffs /dev/mtdblock1 /mnt/flash
>         
>         I can then copy/edit/delete from it, and diff shows that
>         the data is consistant.
> 
>         So I think MTD layer is fine and the configuration on MTD
>         part (.config) is fine.
> 
>     (b) I tried mkfs.jffs2 on both target and my x86 host (with
>         big-endian option)
> 
>         mkfs.jffs2 -dipc -e0x40000 -p0x700000 -b -o /opt/ipc.jffs2
> 
>         I then cp it on a mtd device with:
>         eraseall /dev/mtd1
>         cp /mnt/nfs/ipc.jffs2 /dev/mtd1
> 
>         the "cp" goes fine, but when I tried to mount & use the
>         JFFS2 system, within one or two commands, it will give me
>         the oops with the same reason "kernel access of bad area"
> 
>         But if I now boot into ppcboot(with JFFS2 capability compiled
>         in), ppcboot can recognize my JFFS2 files just fine, which
>         lead me to believe the linux JFFS2 subsystem is the problem.
> 
>     (c) I then tried disabling the compression for JFFS2 by forcing
>         return of JFFS2_COMPR_NONE from jffs2_compress() to see if 
>         zlib is a problem. It doesn't seem to have any effect.
> 
>   Any ideas? I have been reading the mailing list archive and could
> not find the answer to this.
> 
>   Thanks a lot
> 
> 
> - Junping
> 
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>