[U-Boot] ext4: crash when writing a file
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,
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
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
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
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
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
Hi,
sorry for the late answer.
So to restate what you are doing:
- 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
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
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@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@entry=0x7ffff4887280 "/boot/opos6ul-linux.bin", addr=addr@entry=0, offset=offset@entry=0, len=len@entry=5359984, actwrite=actwrite@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
participants (3)
-
Brüns, Stefan -
Stefan Bruens
-
Sébastien Szymanski