booting issueVFS: Mounted root (jffs2 filesystem) inflate returned -3 unable access at virtual address e304186 aps: 00000000 PC: [<001090b8>] zlib_inflate+0x738/0x14f0<0>

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

booting issueVFS: Mounted root (jffs2 filesystem) inflate returned -3 unable access at virtual address e304186 aps: 00000000 PC: [<001090b8>] zlib_inflate+0x738/0x14f0<0>

1,455 Views
madhukumar
Contributor I

hello

 

  we used MPU drivers for MCF5485 processor are configuration LTIB-2008 tool in feedora 12, after power on during rootjffs2 image file copied from flash to ddram at the error cooured error message as shown below following lines 

 

VFS: Mounted root (jffs2 filesystem)

inflate returned -3

unable access at virtual address e304186 aps: 00000000

PC: [<001090b8>] zlib_inflate+0x738/0x14f0<0>

 

please give suggestion.

 

Regards,

madhukumar

Labels (1)
0 Kudos
5 Replies

879 Views
TomE
Specialist II

Google "inflate returned -3" gives "About 1,090 results (0.24 seconds)"

Looks like your root filesystem image is corrupt or isn't in the expected format.

Before the error you listed you also got:

physmap platform flash device: 007fffff at ff800000

physmap-flash.0: Found 1 x16 devices at 0x0 in 16-bit bank

NOR chip too large to fit in mapping. Attempting to cope...

Amd/Fujitsu Extended Query Table at 0x0040

physmap-flash.0: CFI does not contain boot bank location. Assuming top.

number of CFI chips: 1

cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.

Reducing visibility of 8192KiB chip to 8191KiB

2 cmdlinepart partitions found on MTD device physmap-flash.0

Creating 2 MTD partitions on "physmap-flash.0":

0x00000000-0x00280000 : "kernel"

0x00280000-0x007c0000 : "root"


Why hide that plain text in a WORD document. That only makes it harder than necessary.

Tom

0 Kudos

879 Views
madhukumar
Contributor I


hi Tom,


now kernel console output error as shown below following lines. it shows error inflate returned -3


U-Boot 1.3.3 (Apr 16 2015 - 12:05:58)

CPU:   Freescale MCF5485

       CPU CLK 150 Mhz BUS CLK 75 Mhz

Board-->u-boot.bin-V1.0

SATTVA etech Himagni CPU Board

DRAM:  64 MB

FLASH:  8 MB

In:    serial

Out:   serial

Err:   serial

Net:   FEC0, FEC1

Hit any key to stop autoboot:  0

## Booting kernel from Legacy Image at ff850000 ...

   Image Name: Linux Kernel Image

   Image Type: M68K Linux Kernel Image (uncompressed)

   Data Size: 2244608 Bytes =  2.1 MB

   Load Address: 00020000

   Entry Point: 00020000

   Verifying Checksum ... OK

   Loading Kernel Image ... OK

OK

Linux version 2.6.25 (root@localhost.localdomain) (gcc version 4.4.1 (Sourcery G++ Lite 4.4-217) ) #22 Thu Nov 22 16:10:35 IST 2012

starting up linux startmem 0x27c000, endmem 0x4000000,          size 61MB

console [ttyS0] enabled

Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 8156

Kernel command line: root=/dev/mtdblock1 rw rootfstype=jffs2 mtdparts=physmap-flash.0:2560k(kernel)ro,5376k(root) console=ttyS0,19200

PID hash table entries: 256 (order: 8, 1024 bytes)

Console: colour dummy device 80x25

Dentry cache hash table entries: 8192 (order: 2, 32768 bytes)

Inode-cache hash table entries: 4096 (order: 1, 16384 bytes)

Memory: 62592k/62592k available (1672k kernel code, 1200k data, 64k init)

SLUB: Genslabs=13, HWalign=16, Order=0-2, MinObjects=8, CPUs=1, Nodes=1

Mount-cache hash table entries: 1024

net_namespace: 152 bytes

NET: Registered protocol family 16

MCF5485x INIT_DEVICES

NET: Registered protocol family 2

IP route cache hash table entries: 2048 (order: 0, 8192 bytes)

TCP established hash table entries: 2048 (order: 1, 16384 bytes)

TCP bind hash table entries: 2048 (order: 0, 8192 bytes)

TCP: Hash tables configured (established 2048 bind 2048)

TCP reno registered

m547x_8x DMA: Initialize Multi-channel DMA API v1.0

JFFS2 version 2.2. (NAND) �© 2001-2006 Red Hat, Inc.

io scheduler noop registered

io scheduler anticipatory registered

io scheduler deadline registered

io scheduler cfq registered (default)

IOIVME Device Driver Registered with MAJOR = 0

Attached IRQ5 vector=69

Attached IRQ6 vector=70

Attached IRQ7 vector=71

Attached IRQ7 vector=71

IOI Device Driver Registered with MAJOR = 0

RESET Device Driver Registered with MAJOR = 0

RTC driver registered with major = 253

DISP DEVICE DRIVER REGISTERED with major = 254

RTS driver registered with major = 248

WDT DEVICE DRIVER REGISTERED with major = 251

req Device Driver Registered with MAJOR = 246

HIMAGNI MEMORY  DEVICE REMAPPED ADDRESS: fc000000

HIMAGNI MEMORY  DEVICE REMAPPED ADDRESS: fb000000

HIMAGNI MEMORY  DEVICE REMAPPED ADDRESS: fc900000

ColdFire internal UART serial driver version 1.00

ttyS0 at 0xf0008600 (irq = 99) is a builtin ColdFire UART

ttyS1 at 0xf0008700 (irq = 98) is a builtin ColdFire UART

ttyS2 at 0xf0008800 (irq = 97) is a builtin ColdFire UART

ttyS3 at 0xf0008900 (irq = 96) is a builtin ColdFire UART

brd: module loaded

loop: module loaded

FEC ENET (DMA) Version 0.20

eth0: ethernet 00:60:72:00:00:01

eth1: ethernet 00:60:72:00:00:02

physmap platform flash device: 007fffff at ff800000

physmap-flash.0: Found 1 x16 devices at 0x0 in 16-bit bank

NOR chip too large to fit in mapping. Attempting to cope...

Amd/Fujitsu Extended Query Table at 0x0040

physmap-flash.0: CFI does not contain boot bank location. Assuming top.

number of CFI chips: 1

cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.

Reducing visibility of 8192KiB chip to 8191KiB

2 cmdlinepart partitions found on MTD device physmap-flash.0

Creating 2 MTD partitions on "physmap-flash.0":

0x00000000-0x00280000 : "kernel"

0x00280000-0x007c0000 : "root"

mice: PS/2 mouse device common for all mice

TCP cubic registered

NET: Registered protocol family 1

NET: Registered protocol family 17

NET: Registered protocol family 15

RPC: Registered udp transport module.

RPC: Registered tcp transport module.

VFS: Mounted root (jffs2 filesystem).

inflate returned -3

Unable access at virtual address e304186aps: e3062ecb

PC: [<001090b8>] zlib_inflate+0x738/0x14f0<0>

SR: 2000  SP: 0302da68 a2: 0302a000

d0: 000001ff    d1: 00000000    d2: 00000003    d3: 20000249

d4: 00000000    d5: 00000100    a0: c004452c    a1: c004452c

Process init (pid: 1, stackpage=0302c000)

Stack from 0302da68:

       <0> 00000000<0> 00000003<0> 20000249<0> 00000000<0> 00000100<0> c004452c(0xc004452c)<0> c004452c(0xc004452c)<0>           0302a000

       <0> 000001ff<0> ffffffff<0> 00000000<0> e304186a<0> 00000000<0> 4c0a2000<0> 001090b8<0> 00000000

       <0> 0000001f<0> 00000006<0> 029c4200<0> 03fc4000<0> 0302dbb4<0> 00108980<0> 03041002<0> 000dee9a

       <0> 00001000<0> c004452c(0xc004452c)<0> 00000000<0> 0013e34a<0> 03052814<0> c00442ec(0xc00442ec)<0> 00001000<0>           00fc4000

       <0> 0000c81c<0> c004452c(0xc004452c)<0> c0044068(0xc0044068)<0> c004406c(0xc004406c)<0> c0044050(0xc0044050)<0>           c0044054(0xc0044054)<0> 000001ff<0> c004452c(0xc)

       <0> 0026c81c<0> c004452c(0xc004452c)<0> c00442ec(0xc00442ec)<0> c004452c(0xc004452c)<0> 00002504<0> 029ad000<0>           00000000<0> 00000000

Call Trace:

       <0> [<000e0736>]<0> [<000d16dc>]<0> [<00069660>]<0> [<000d46c0>]

       <0> [<001019e0>]<0> [<0010429e>]<0> [<000d44c0>]<0> [<000d483c>]

       <0> [<00052796>]<0> [<0004a652>]<0> [<000d2e22>]<0> [<000d3156>]

       <0> [<000d3196>]<0> [<00100100>]<0> [<00051d14>]<0> [<00051aac>]

       <0> [<000520e2>]<0> [<00051d50>]<0> [<0004a406>]<0> [<00051d8a>]

       <0> [<0004aee4>]<0> [<00056eb0>]<0> [<0003f398>]<0> [<00058372>]

       <0> [<00058496>]<0> [<001bf48a>]<0> [<001bfd12>]<0> [<0003f398>]

       <0> [<00058372>]<0> [<00022fc6>]<0> [<000251d4>]<0> [<00023952>]

       <0> [<0010453c>]<0> [<00098f40>]<0> [<0009a24e>]<0> [<0003f36c>]

       <0> [<00046a30>]<0> [<0006fdf4>]<0> [<0006fb7a>]<0> [<00070e00>]

       <0> [<00021030>]<0> [<000776c6>]<0> [<000214ae>]<0> [<00048ce2>]

       <0> [<00023a56>]<0> [<0003f36c>]<0> [<00021cc2>]<0> [<0002104c>]

       <0> [<000210a8>]<0> [<00104098>]<0> [<00023998>]<0> [<00021330>]

Kernel panic - not syncing: Attempted to kill init!

regards,

madhu

0 Kudos

879 Views
TomE
Specialist II

> it shows error inflate returned -3


So what does that mean?

Did google help you find out the cause? Did you look?

Otherwise, you should have the Kernel Source code there. Find the code that calls "inflate" and the "inflate" sources and find what "-3" means to it.

Hint: start in the kernel source tree in "fs/jffs2" and search for "returned". Then you'll find it is including "zlib.h", so ask any friendly Linux system "man zlib". That tells you where it is documented and what "-3" means.

Tracking it down to that level will STILL mean "Looks like your root filesystem image is corrupt or isn't in the expected format."

You may have to rebuild the system from scratch.

Tom

0 Kudos

879 Views
madhukumar
Contributor I

hi Tom

yes i looked, in the kernel source code mentioned in the zlib.h inflate returned -3 means Z_DATA_ERROR, i was rebuild system from scratch in two times but is shows same error (inflate returned -3)

i think during root file system copied image from flash to ddram at the compressing time it caused error, flash and sdram is not syncing, similarly filesystem mount with NFS is worked fine and also got shell prompt in kernel console output.

in NFS i gave link in /tftpboot, No problem only without NFS is not booted, may be i can change filesystem.

0 Kudos

879 Views
TomE
Specialist II

Do you only have the one board (that might have a hardware fault) or is this happening on multiple units?

What changed since it last worked?

You can boot over NFS. Once booted, you should try to mount the JFFS2 partition from Linux. You may get "better" error messages from there. At the very least you should try to copy /dev/ntdblock1 back over the network to the machine that you got the rootfs image from, and then compare the original with the one you got back from the device.

Once booted you can copy the rootfs image over the network and use "nandwrite" to write it to the Flash. That may work better.

You may have bad blocks on the Flash and may not be handling them properly. If you use the wrong commands to copy filesystems onto Flash, it can work OK when there are no bad blocks, but fail when there are.

See if you can run "nandtest" on the target to see if there are any problems. If you don't have "nandtest" loaded then you can ask "nanddump" to do much the same thing:

root@triton1:/# nanddump  /dev/mtd7 > /dev/null

ECC failed: 0

ECC corrected: 0

Number of bad blocks: 1

Number of bbt blocks: 0

Block size 131072, page size 2048, OOB size 64

Dumping data starting at 0x00000000 and ending at 0x01200000...

"mtd7" has a bad block which is being properly handled.

Does your Flash have any bad blocks in that partition? Maybe you used the wrong command in U-Boot to copy to it. Do you have any other units that don't have bad blocks?

Does your Flash have any spare partitions that you could try copying rootfs to (and then loading that one in the command line) instead?

Tom

0 Kudos