[U-Boot] ext4: crash when writing a file

[U-Boot] ext4: crash when writing a file

[Sébastien Szymanski]

Hello,

I am working on a i.MX6UL based board with a 4GB eMMC partitioned as
following:

Device     Boot   Start     End Sectors  Size Id Type
/dev/sdb1          2048  264191  262144  128M 83 Linux
/dev/sdb2        264192 4458495 4194304    2G 83 Linux
/dev/sdb3       4458496 7634943 3176448  1.5G 83 Linux

On the 2nd partition, I write this ext4 filesystem file generated by
Buildroot:
Filesystem volume name:   "ROOTFS"
Last mounted on:          <not available>
Filesystem UUID:          b9833a36-e89d-429a-b120-c3b00bcb7785
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal dir_index filetype extent
sparse_super uninit_bg
Filesystem flags:         signed_directory_hash
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Unknown (continue)
Filesystem OS type:       Linux
Inode count:              3456
Block count:              91756
Reserved block count:     4587
Free blocks:              13458
Free inodes:              488
First block:              1
Block size:               1024
Fragment size:            1024
Blocks per group:         7648
Fragments per group:      7648
Inodes per group:         288
Inode blocks per group:   36
Last mount time:          n/a
Last write time:          Tue Nov 29 09:44:52 2016
Mount count:              0
Maximum mount count:      -1
Last checked:             Tue Nov 29 09:44:52 2016
Check interval:           0 (<none>)
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               128
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      a583a07f-6b59-442d-8e08-9be305f78d17
Journal backup:           inode blocks

This filesystem is written with the following commands:

BIOS> setexpr nbblocks ${filesize} / 0x200
BIOS> setexpr nbblocks ${nbblocks} + 1
BIOS> mmc write ${loadaddr} 0x40800 ${nbblocks}
MMC write: dev # 0, block # 264192, count 183513 ... 183513 blocks
written: OK

I can boot Linux with it without any issues, however if I try to write a
file in it I get the following crash:

BIOS> ext4write mmc 0:2 ${loadaddr} /boot/${kernelimg} ${filesize}

File System is consistent
file found, deleting
update journal finished
File System is consistent
update journal finished
data abort
pc : [<8ff783ac>]          lr : [<8ff86c95>]
reloc pc : [<8780e3ac>]    lr : [<8781cc95>]
sp : 8ef696b8  ip : 00000000     fp : 8ffbc6d8
r10: 00000200  r9 : 8ef69ee8     r8 : 8ffbc744
r7 : 8ef9f600  r6 : 8ef999b6     r5 : 00000003  r4 : 8ffa35fc
r3 : 8ef999b8  r2 : 00000001     r1 : fffffffe  r0 : 8ef999c0
Flags: NzCv  IRQs off  FIQs off  Mode SVC_32
Resetting CPU ...

resetting ...

I have investigated a bit and I found that the crash is in the
ext4fs_deinit() function provoked by the free() call at line 722
(fs/ext4/ext4_write.c) and the ext4fs_deinit() is called in
ext4fs_write() at line 980.

If I resize the filesystem under Linux, I don't get the crash but the
following error:

ext4fs_devread read outside partition 4294967294
error in File System init
** Error ext4fs_write() **
** Unable to write file /boot/opos6ul-linux.bin **

Any idea ?

Regards,

-- 
S?bastien Szymanski
Software Engineer, Armadeus Systems
sebastien.szymanski at armadeus.com
Tel: +33 (0)9 72 29 41 44
Fax: +33 (0)9 72 28 79 26

[U-Boot] ext4: crash when writing a file

[Brüns, Stefan]

On Dienstag, 29. November 2016 10:50:45 CET you wrote:
> Hello,
> 
> I am working on a i.MX6UL based board with a 4GB eMMC partitioned as
> following:
> 
> Device     Boot   Start     End Sectors  Size Id Type
> /dev/sdb1          2048  264191  262144  128M 83 Linux
> /dev/sdb2        264192 4458495 4194304    2G 83 Linux
> /dev/sdb3       4458496 7634943 3176448  1.5G 83 Linux
> 
> On the 2nd partition, I write this ext4 filesystem file generated by
> Buildroot:
> Filesystem volume name:   "ROOTFS"
> Last mounted on:          <not available>
> Filesystem UUID:          b9833a36-e89d-429a-b120-c3b00bcb7785
> Filesystem magic number:  0xEF53
> Filesystem revision #:    1 (dynamic)
> Filesystem features:      has_journal dir_index filetype extent
> sparse_super uninit_bg
> Filesystem flags:         signed_directory_hash
> Default mount options:    (none)
> Filesystem state:         clean
> Errors behavior:          Unknown (continue)
> Filesystem OS type:       Linux
> Inode count:              3456
> Block count:              91756
91756 blocks ...

> Reserved block count:     4587
> Free blocks:              13458
> Free inodes:              488
> First block:              1
> Block size:               1024
1k each -> 91 MByte filesystem

> Fragment size:            1024
> Blocks per group:         7648
> Fragments per group:      7648
> Inodes per group:         288
> Inode blocks per group:   36
> Last mount time:          n/a
> Last write time:          Tue Nov 29 09:44:52 2016
> Mount count:              0
> Maximum mount count:      -1
> Last checked:             Tue Nov 29 09:44:52 2016
> Check interval:           0 (<none>)
> Reserved blocks uid:      0 (user root)
> Reserved blocks gid:      0 (group root)
> First inode:              11
> Inode size:               128
> Journal inode:            8
> Default directory hash:   half_md4
> Directory Hash Seed:      a583a07f-6b59-442d-8e08-9be305f78d17
> Journal backup:           inode blocks
> 
> This filesystem is written with the following commands:
> 
> BIOS> setexpr nbblocks ${filesize} / 0x200
> BIOS> setexpr nbblocks ${nbblocks} + 1
> BIOS> mmc write ${loadaddr} 0x40800 ${nbblocks}
> MMC write: dev # 0, block # 264192, count 183513 ... 183513 blocks
> written: OK
> 
> I can boot Linux with it without any issues, however if I try to write a
> file in it I get the following crash:
> 
> BIOS> ext4write mmc 0:2 ${loadaddr} /boot/${kernelimg} ${filesize}

What are you trying to achieve here? What is the value of $filesize?

Btw, which u-boot version are you using?

Regards,

Stefan

[U-Boot] ext4: crash when writing a file

[Sébastien Szymanski]

On 11/29/2016 01:14 PM, Br?ns, Stefan wrote:
> On Dienstag, 29. November 2016 10:50:45 CET you wrote:
>> Hello,
>>
>> I am working on a i.MX6UL based board with a 4GB eMMC partitioned as
>> following:
>>
>> Device     Boot   Start     End Sectors  Size Id Type
>> /dev/sdb1          2048  264191  262144  128M 83 Linux
>> /dev/sdb2        264192 4458495 4194304    2G 83 Linux
>> /dev/sdb3       4458496 7634943 3176448  1.5G 83 Linux
>>
>> On the 2nd partition, I write this ext4 filesystem file generated by
>> Buildroot:
>> Filesystem volume name:   "ROOTFS"
>> Last mounted on:          <not available>
>> Filesystem UUID:          b9833a36-e89d-429a-b120-c3b00bcb7785
>> Filesystem magic number:  0xEF53
>> Filesystem revision #:    1 (dynamic)
>> Filesystem features:      has_journal dir_index filetype extent
>> sparse_super uninit_bg
>> Filesystem flags:         signed_directory_hash
>> Default mount options:    (none)
>> Filesystem state:         clean
>> Errors behavior:          Unknown (continue)
>> Filesystem OS type:       Linux
>> Inode count:              3456
>> Block count:              91756
> 91756 blocks ...
> 
>> Reserved block count:     4587
>> Free blocks:              13458
>> Free inodes:              488
>> First block:              1
>> Block size:               1024
> 1k each -> 91 MByte filesystem

Yes. Is there something wrong here ?

> 
>> Fragment size:            1024
>> Blocks per group:         7648
>> Fragments per group:      7648
>> Inodes per group:         288
>> Inode blocks per group:   36
>> Last mount time:          n/a
>> Last write time:          Tue Nov 29 09:44:52 2016
>> Mount count:              0
>> Maximum mount count:      -1
>> Last checked:             Tue Nov 29 09:44:52 2016
>> Check interval:           0 (<none>)
>> Reserved blocks uid:      0 (user root)
>> Reserved blocks gid:      0 (group root)
>> First inode:              11
>> Inode size:               128
>> Journal inode:            8
>> Default directory hash:   half_md4
>> Directory Hash Seed:      a583a07f-6b59-442d-8e08-9be305f78d17
>> Journal backup:           inode blocks
>>
>> This filesystem is written with the following commands:
>>
>> BIOS> setexpr nbblocks ${filesize} / 0x200
>> BIOS> setexpr nbblocks ${nbblocks} + 1
>> BIOS> mmc write ${loadaddr} 0x40800 ${nbblocks}
>> MMC write: dev # 0, block # 264192, count 183513 ... 183513 blocks
>> written: OK
>>
>> I can boot Linux with it without any issues, however if I try to write a
>> file in it I get the following crash:
>>
>> BIOS> ext4write mmc 0:2 ${loadaddr} /boot/${kernelimg} ${filesize}
> 
> What are you trying to achieve here? What is the value of $filesize?

I try to update the kernel image which is /boot/opos6ul-linux.bin. I
download it from a tftp server so $filesize is the size of the kernel image

BIOS> printenv filesize
filesize=518f68

> 
> Btw, which u-boot version are you using?

I first noticed the issue on U-Boot 2016.05 so I rebase on master from
http://git.denx.de/u-boot.git

Regards,

> 
> Regards,
> 
> Stefan
> 


-- 
S?bastien Szymanski
Software Engineer, Armadeus Systems
sebastien.szymanski at armadeus.com
Tel: +33 (0)9 72 29 41 44
Fax: +33 (0)9 72 28 79 26

[U-Boot] ext4: crash when writing a file

[Brüns, Stefan]

On Dienstag, 29. November 2016 14:10:54 CET S?bastien Szymanski wrote:
> 
> > Btw, which u-boot version are you using?
> 
> I first noticed the issue on U-Boot 2016.05 so I rebase on master from
> http://git.denx.de/u-boot.git
> 
> Regards,

That still doesn't make clear on which version you see this issue. 2016.05? 
Master? Which date/tag/hash?

U-Boot 2016.11 has received a huge number of fixes, and current master has 
some more.

Regards,

Stefan

[U-Boot] ext4: crash when writing a file

[Sébastien Szymanski]

On 11/29/2016 03:38 PM, Br?ns, Stefan wrote:
> On Dienstag, 29. November 2016 14:10:54 CET S?bastien Szymanski wrote:
>>
>>> Btw, which u-boot version are you using?
>>
>> I first noticed the issue on U-Boot 2016.05 so I rebase on master from
>> http://git.denx.de/u-boot.git
>>
>> Regards,
> 
> That still doesn't make clear on which version you see this issue. 2016.05? 
> Master? Which date/tag/hash?
> 
> U-Boot 2016.11 has received a huge number of fixes, and current master has 
> some more.

Sorry for being unclear.

I was working with U-Boot 2016.05 (commit
aeaec0e682f45b9e0c62c522fafea353931f73ed) when I saw this issue. Then, I
rebased on current master (commit
e94793c844a40606252f2e3f6428063e057b3fd2) and I still see this issue.

I hope it's clearer now.

Regards,

> 
> Regards,
> 
> Stefan
> 

S?bastien Szymanski

[U-Boot] ext4: crash when writing a file

[Stefan Bruens]

On Dienstag, 29. November 2016 16:23:28 CET S?bastien Szymanski wrote:
> On 11/29/2016 03:38 PM, Br?ns, Stefan wrote:
> > On Dienstag, 29. November 2016 14:10:54 CET S?bastien Szymanski wrote:
> >>> Btw, which u-boot version are you using?
> >> 
> >> I first noticed the issue on U-Boot 2016.05 so I rebase on master from
> >> http://git.denx.de/u-boot.git
> >> 
> >> Regards,
> > 
> > That still doesn't make clear on which version you see this issue.
> > 2016.05?
> > Master? Which date/tag/hash?
> > 
> > U-Boot 2016.11 has received a huge number of fixes, and current master has
> > some more.
> 
> Sorry for being unclear.
> 
> I was working with U-Boot 2016.05 (commit
> aeaec0e682f45b9e0c62c522fafea353931f73ed) when I saw this issue. Then, I
> rebased on current master (commit
> e94793c844a40606252f2e3f6428063e057b3fd2) and I still see this issue.
> 
> I hope it's clearer now.
> 
> Regards,
> 
> > Regards,
> > 
> > Stefan
> 
> S?bastien Szymanski

So to restate what you are doing:

1. You have a partitioned MMC, where the 2nd partition starts at block 
264192/0x40800
2. You load a 93958144 byte (~90 MB) file via TFTP to ${loadaddr}
3. You write this partition image to 0x40800 using "mmc write"
4. You load another 5345128 byte (5 MB) file via TFTP to $loadaddr
5. You try to write this file to the 2nd partition, which now is ext4 
formatted, and already contains a file of the same name, i.e. boot/opos6ul-
linux.bin


Actually, I can't reproduce the crash. Maybe you have corrupted part of the 
memory when loading the image, e.g. overwritten part of u-boot or its heap.

Things you can try:
a) reboot the system after loading/writing the partion image.
b) checking the fs contents after the reboot, e.g "ls mmc 0:2 /boot" 
c) overwriting opos6ul-linux.bin with just a single byte, e.g "ext4write mmc 
0:2 0x0 /boot/opos6ul-linux.bin 1"
d) transferring back the partition image to your host and running fschk on it

You may also able to reproduce this using the u-boot sandbox.

Kind regards,

Stefan



-- 
Stefan Br?ns  /  Bergstra?e 21  /  52062 Aachen
home: +49 241 53809034     mobile: +49 151 50412019
work: +49 2405 49936-424

[U-Boot] ext4: crash when writing a file

[Sébastien Szymanski]

Hi,

sorry for the late answer.

> So to restate what you are doing:
> 
> 1. You have a partitioned MMC, where the 2nd partition starts at block 
> 264192/0x40800
> 2. You load a 93958144 byte (~90 MB) file via TFTP to ${loadaddr}
> 3. You write this partition image to 0x40800 using "mmc write"
> 4. You load another 5345128 byte (5 MB) file via TFTP to $loadaddr
> 5. You try to write this file to the 2nd partition, which now is ext4 
> formatted, and already contains a file of the same name, i.e. boot/opos6ul-
> linux.bin

That's right.

> 
> 
> Actually, I can't reproduce the crash. Maybe you have corrupted part of the 
> memory when loading the image, e.g. overwritten part of u-boot or its heap.
> 
> Things you can try:
> a) reboot the system after loading/writing the partion image.
> b) checking the fs contents after the reboot, e.g "ls mmc 0:2 /boot" 

No issue here.

> c) overwriting opos6ul-linux.bin with just a single byte, e.g "ext4write mmc 
> 0:2 0x0 /boot/opos6ul-linux.bin 1"

It doesn't crash here. On the u-boot sandbox I can write up to 256Ko.
When I try 512Ko it crashes.

> d) transferring back the partition image to your host and running fschk on it

The partition is fine when transferred back to my host.

> 
> You may also able to reproduce this using the u-boot sandbox.

I'm able to reproduce it using the u-boot sandbox.

I've created a disk image as explained in board/sandbox/README.sandbox
"Block Device Emulation":

Command (m for help): p
Disk /dev/loop0: 3 GiB, 3221225472 bytes, 6291456 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xd8192f55

Device       Boot  Start     End Sectors  Size Id Type
/dev/loop0p1        2048  264191  262144  128M 83 Linux
/dev/loop0p2      264192 4458495 4194304    2G 83 Linux

Then I use dd to emulate the mmc write command since there is no host
write command:

dd if=/tftproot/opos6ul-rootfs.ext4 of=/dev/loop0p2

The partition seems to be fine according to fsck.ext4:
e2fsck 1.43.3 (04-Sep-2016)
"ROOTFS": clean, 3830/4312 files, 73797/88390 blocks

I can mount it and see its content.

Then under the sandbox I do the following:

U-Boot 2017.01-00002-g558e41e-dirty (Jan 20 2017 - 16:19:47 +0100)

DRAM:  256 MiB
MMC:
Using default environment

In:    serial
Out:   serial
Err:   serial
SCSI:  Net:   No ethernet found.
IDE:   Bus 0: not available

=> host bind 0 /tftproot/rootfs.raw

=> ls host 0:2
<DIR>       1024 .
<DIR>       1024 ..
<DIR>      16384 lost+found
<DIR>       1024 var
<DIR>       1024 run
<DIR>       1024 root
<DIR>       1024 media
<DIR>       1024 mnt
<DIR>       1024 tmp
<SYM>          3 lib32
<DIR>       1024 usr
<DIR>       1024 proc
<DIR>       1024 dev
<DIR>       1024 boot
<DIR>       1024 sys
<DIR>       3072 sbin
<DIR>       3072 bin
<SYM>         11 linuxrc
<DIR>       1024 etc
<DIR>       1024 opt
<DIR>       3072 lib

=> ls host 0:2 /boot
<DIR>       1024 .
<DIR>       1024 ..
           26909 imx6ul-opos6uldev.dtb
<SYM>          1 dtbs
         5359984 opos6ul-linux.bin

=> host load hostfs - 0 /tftproot/opos6ul-linux.bin
5359984 bytes read in 2 ms (2.5 GiB/s)

=> printenv filesize
filesize=51c970

=> ext4write host 0:2 0 /boot/opos6ul-linux.bin ${filesize}
File System is consistent
file found, deleting
update journal finished
File System is consistent
update journal finished
Segmentation fault

Regards,

> 
> Kind regards,
> 
> Stefan


S?bastien Szymanski

[U-Boot] ext4: crash when writing a file

[Brüns, Stefan]

On Freitag, 20. Januar 2017 18:32:49 CET S?bastien Szymanski wrote:
[...]
> Then under the sandbox I do the following:
> 
> U-Boot 2017.01-00002-g558e41e-dirty (Jan 20 2017 - 16:19:47 +0100)
> 
> DRAM:  256 MiB
> MMC:
> Using default environment
> 
> In:    serial
> Out:   serial
> Err:   serial
> SCSI:  Net:   No ethernet found.
> IDE:   Bus 0: not available
> 
> => host bind 0 /tftproot/rootfs.raw
> 
> => ls host 0:2
> <DIR>       1024 .
> <DIR>       1024 ..
> <DIR>      16384 lost+found
> <DIR>       1024 var
> <DIR>       1024 run
> <DIR>       1024 root
> <DIR>       1024 media
> <DIR>       1024 mnt
> <DIR>       1024 tmp
> <SYM>          3 lib32
> <DIR>       1024 usr
> <DIR>       1024 proc
> <DIR>       1024 dev
> <DIR>       1024 boot
> <DIR>       1024 sys
> <DIR>       3072 sbin
> <DIR>       3072 bin
> <SYM>         11 linuxrc
> <DIR>       1024 etc
> <DIR>       1024 opt
> <DIR>       3072 lib
> 
> => ls host 0:2 /boot
> <DIR>       1024 .
> <DIR>       1024 ..
>            26909 imx6ul-opos6uldev.dtb
> <SYM>          1 dtbs
>          5359984 opos6ul-linux.bin
> 
> => host load hostfs - 0 /tftproot/opos6ul-linux.bin
> 5359984 bytes read in 2 ms (2.5 GiB/s)
> 
> => printenv filesize
> filesize=51c970
> 
> => ext4write host 0:2 0 /boot/opos6ul-linux.bin ${filesize}
> File System is consistent
> file found, deleting
> update journal finished
> File System is consistent
> update journal finished
> Segmentation fault

As you can repeat this under sandbox, the next step would be to run sandbox 
under gdb, e.g.:
$> gdb --args sandbox -c "host bind 0 /tftproot/rootfs.raw ; host load hostfs 
- 0 /tftproot/opos6ul-linux.bin ; ext4write host 0:2 0 /boot/opos6ul-linux.bin 
${filesize}"

Kind regards,

Stefan

[U-Boot] ext4: crash when writing a file

[Sébastien Szymanski]

On 01/23/2017 05:38 PM, Br?ns, Stefan wrote:
> On Freitag, 20. Januar 2017 18:32:49 CET S?bastien Szymanski wrote:
> [...]
>> Then under the sandbox I do the following:
>>
>> U-Boot 2017.01-00002-g558e41e-dirty (Jan 20 2017 - 16:19:47 +0100)
>>
>> DRAM:  256 MiB
>> MMC:
>> Using default environment
>>
>> In:    serial
>> Out:   serial
>> Err:   serial
>> SCSI:  Net:   No ethernet found.
>> IDE:   Bus 0: not available
>>
>> => host bind 0 /tftproot/rootfs.raw
>>
>> => ls host 0:2
>> <DIR>       1024 .
>> <DIR>       1024 ..
>> <DIR>      16384 lost+found
>> <DIR>       1024 var
>> <DIR>       1024 run
>> <DIR>       1024 root
>> <DIR>       1024 media
>> <DIR>       1024 mnt
>> <DIR>       1024 tmp
>> <SYM>          3 lib32
>> <DIR>       1024 usr
>> <DIR>       1024 proc
>> <DIR>       1024 dev
>> <DIR>       1024 boot
>> <DIR>       1024 sys
>> <DIR>       3072 sbin
>> <DIR>       3072 bin
>> <SYM>         11 linuxrc
>> <DIR>       1024 etc
>> <DIR>       1024 opt
>> <DIR>       3072 lib
>>
>> => ls host 0:2 /boot
>> <DIR>       1024 .
>> <DIR>       1024 ..
>>            26909 imx6ul-opos6uldev.dtb
>> <SYM>          1 dtbs
>>          5359984 opos6ul-linux.bin
>>
>> => host load hostfs - 0 /tftproot/opos6ul-linux.bin
>> 5359984 bytes read in 2 ms (2.5 GiB/s)
>>
>> => printenv filesize
>> filesize=51c970
>>
>> => ext4write host 0:2 0 /boot/opos6ul-linux.bin ${filesize}
>> File System is consistent
>> file found, deleting
>> update journal finished
>> File System is consistent
>> update journal finished
>> Segmentation fault
> 
> As you can repeat this under sandbox, the next step would be to run sandbox 
> under gdb, e.g.:
> $> gdb --args sandbox -c "host bind 0 /tftproot/rootfs.raw ; host load hostfs 
> - 0 /tftproot/opos6ul-linux.bin ; ext4write host 0:2 0 /boot/opos6ul-linux.bin 
> ${filesize}"

Yes, I did this and it crashes exactly where I pointed out in my first post:

(gdb) run
Starting program: /home/sszy/development/armadeus-u-boot/u-boot -c host\
bind\ 0\ /tftproot/rootfs.raw\;\ host\ load\ hostfs\ -\ 0\
/tftproot/opos6ul-linux.bin\;\ ext4write\ host\ 0:2\ 0\
/boot/opos6ul-linux.bin\ \$\{filesize\}
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".


U-Boot 2017.01-00002-g558e41e-dirty (Jan 24 2017 - 10:44:13 +0100)

DRAM:  256 MiB
MMC:
Using default environment

In:    serial
Out:   serial
Err:   serial
SCSI:  Net:   No ethernet found.
IDE:   Bus 0: not available
5359984 bytes read in 2 ms (2.5 GiB/s)
File System is consistent
file found, deleting
update journal finished
File System is consistent
update journal finished

Program received signal SIGSEGV, Segmentation fault.
free (mem=<optimized out>) at common/dlmalloc.c:1586
1586      if (!(inuse_bit_at_offset(next, nextsz)))   /* consolidate
forward */
(gdb) bt
#0  free (mem=<optimized out>) at common/dlmalloc.c:1586
#1  0x000000000044e9a3 in ext4fs_deinit () at fs/ext4/ext4_write.c:722
#2  0x000000000044fd85 in ext4fs_write (fname=<optimized out>,
buffer=<optimized out>, sizebytes=sizebytes at entry=5359984) at
fs/ext4/ext4_write.c:980
#3  0x000000000044fe5f in ext4_write_file (filename=<optimized out>,
buf=<optimized out>, offset=<optimized out>, len=5359984,
actwrite=0x7fffffffd5b8)
    at fs/ext4/ext4_write.c:1012
#4  0x000000000044a41b in fs_write
(filename=filename at entry=0x7ffff4887280 "/boot/opos6ul-linux.bin",
addr=addr at entry=0, offset=offset at entry=0, len=len at entry=5359984,
    actwrite=actwrite at entry=0x7fffffffd5b8) at fs/fs.c:325
#5  0x000000000044a7a3 in do_save (cmdtp=<optimized out>,
flag=<optimized out>, argc=6, argv=<optimized out>, fstype=<optimized
out>) at fs/fs.c:478

Regards,

> 
> Kind regards,
> 
> Stefan
> 


-- 
S?bastien Szymanski
Software Engineer, Armadeus Systems
sebastien.szymanski at armadeus.com
Tel: +33 (0)9 72 29 41 44
Fax: +33 (0)9 72 28 79 26