UBIFS assert when rebooting a read only ubifs when it's been remounted r/w

UBIFS assert when rebooting a read only ubifs when it's been remounted r/w

[Martin Townsend]

Hi,

I've just seen the following UBIFS assert which relates to
ubifs_remount_fs in fs/ubifs/super.c
We have a read only root filesystem and it looks like this problem
occurs after rebooting the board when the root filesystem has been
remounted as as r/w, I use the following command to do this in case
I'm doing this incorrectly.
mount -o remount,rw /
The only way to stop it is to login and run
mount -o remount,rw /
mount -o remount,ro /
and then reboots do not assert.

I've tried a few times now and can happily reproduce it.

Any ideas on how to fix this?

Many Thanks,
Martin.

May 17 14:54:44 am43-controller-aquila-1bf6b1 kernel: UBIFS assert
failed in ubifs_remount_fs at 1869 (pid 108)
May 17 14:54:44 am43-controller-aquila-1bf6b1 kernel: CPU: 0 PID: 108
Comm: mount Not tainted 4.1.18-g6b41ca0b94 #1
May 17 14:54:44 am43-controller-aquila-1bf6b1 kernel: Hardware name:
Generic AM43 (Flattened Device Tree)
May 17 14:54:44 am43-controller-aquila-1bf6b1 kernel: Backtrace:
May 17 14:54:44 am43-controller-aquila-1bf6b1 kernel:
May 17 14:54:44 am43-controller-aquila-1bf6b1 kernel: [<c0013398>]
(dump_backtrace) from [<c00135b8>] (show_stack+0x18/0x1c)
May 17 14:54:44 am43-controller-aquila-1bf6b1 kernel:  r7:00000000
May 17 14:54:44 am43-controller-aquila-1bf6b1 kernel:  r6:ee327ee4
r5:00000000 r4:ee01a000
May 17 14:54:44 am43-controller-aquila-1bf6b1 kernel: [<c00135a0>]
(show_stack) from [<c060006c>] (dump_stack+0x20/0x28)
May 17 14:54:44 am43-controller-aquila-1bf6b1 kernel: [<c060004c>]
(dump_stack) from [<c029ba4c>] (ubifs_remount_fs+0x558/0x800)
May 17 14:54:44 am43-controller-aquila-1bf6b1 kernel: [<c029b4f4>]
(ubifs_remount_fs) from [<c013e1e0>] (do_remount_sb+0x6c/0x1d8)
May 17 14:54:44 am43-controller-aquila-1bf6b1 kernel:  r9:ee0dfc40
r8:00000000 r7:00000000 r6:00000000 r5:00000000 r4:ee0dfc00
May 17 14:54:44 am43-controller-aquila-1bf6b1 kernel: [<c013e174>]
(do_remount_sb) from [<c015d69c>] (do_mount+0x80c/0xcd0)
May 17 14:54:44 am43-controller-aquila-1bf6b1 kernel:  r8:00000021
r7:ee0dfc00 r6:ee0fe0d0 r5:00000060 r4:00000000
May 17 14:54:44 am43-controller-aquila-1bf6b1 kernel: [<c015ce90>]
(do_mount) from [<c015dee4>] (SyS_mount+0x9c/0xc8)
May 17 14:54:44 am43-controller-aquila-1bf6b1 kernel:  r10:00000000
r9:ee326000 r8:c0ed0021 r7:7f62d700 r6:00000000 r5:ee31d280
May 17 14:54:44 am43-controller-aquila-1bf6b1 kernel:  r4:ee31d240
May 17 14:54:44 am43-controller-aquila-1bf6b1 kernel: [<c015de48>]
(SyS_mount) from [<c000f920>] (ret_fast_syscall+0x0/0x3c)
May 17 14:54:44 am43-controller-aquila-1bf6b1 kernel:  r8:c000fac4
r7:00000015 r6:7f62d6f0 r5:00000000 r4:00000000

Re: UBIFS assert when rebooting a read only ubifs when it's been remounted r/w

[Richard Weinberger]

[-- Attachment #1: Type: text/plain, Size: 854 bytes --]

On Tue, May 17, 2016 at 5:19 PM, Martin Townsend
<mtownsend1973@gmail.com> wrote:
> Hi,
>
> I've just seen the following UBIFS assert which relates to
> ubifs_remount_fs in fs/ubifs/super.c
> We have a read only root filesystem and it looks like this problem
> occurs after rebooting the board when the root filesystem has been
> remounted as as r/w, I use the following command to do this in case
> I'm doing this incorrectly.
> mount -o remount,rw /
> The only way to stop it is to login and run
> mount -o remount,rw /
> mount -o remount,ro /
> and then reboots do not assert.
>
> I've tried a few times now and can happily reproduce it.
>
> Any ideas on how to fix this?

Let's analyze the root cause first.
Can you please reproduce with the attached debug patch applied?
I wonder what the value of c->lst.taken_empty_lebs is.

-- 
Thanks,
//richard

[-- Attachment #2: ubifs_assert.diff --]
[-- Type: text/plain, Size: 447 bytes --]

diff --git a/fs/ubifs/super.c b/fs/ubifs/super.c
index e98c24e..7514fab 100644
--- a/fs/ubifs/super.c
+++ b/fs/ubifs/super.c
@@ -1870,7 +1870,11 @@ static int ubifs_remount_fs(struct super_block *sb, int *flags, char *data)
 		c->bu.buf = NULL;
 	}
 
-	ubifs_assert(c->lst.taken_empty_lebs > 0);
+	if (!(c->lst.taken_empty_lebs > 0)) {
+		ubifs_err(c, "taken_empty_lebs is %i", c->lst.taken_empty_lebs);
+		ubifs_assert(0);
+	}
+
 	return 0;
 }
 

Re: UBIFS assert when rebooting a read only ubifs when it's been remounted r/w

[Martin Townsend]

On Tue, May 17, 2016 at 5:13 PM, Richard Weinberger
<richard.weinberger@gmail.com> wrote:
> On Tue, May 17, 2016 at 5:19 PM, Martin Townsend
> <mtownsend1973@gmail.com> wrote:
>> Hi,
>>
>> I've just seen the following UBIFS assert which relates to
>> ubifs_remount_fs in fs/ubifs/super.c
>> We have a read only root filesystem and it looks like this problem
>> occurs after rebooting the board when the root filesystem has been
>> remounted as as r/w, I use the following command to do this in case
>> I'm doing this incorrectly.
>> mount -o remount,rw /
>> The only way to stop it is to login and run
>> mount -o remount,rw /
>> mount -o remount,ro /
>> and then reboots do not assert.
>>
>> I've tried a few times now and can happily reproduce it.
>>
>> Any ideas on how to fix this?
>
> Let's analyze the root cause first.
> Can you please reproduce with the attached debug patch applied?
> I wonder what the value of c->lst.taken_empty_lebs is.
>
> --
> Thanks,
> //richard

Here's the output
[    3.185429] UBIFS error (ubi0:0 pid 106): ubifs_remount_fs:
taken_empty_lebs is 0

A bit info:
I booted the board over the network using TFTP/NFS and then mounting
the UBIFS partition using
ubiattach /dev/ubi_ctrl -m 12 -O 2048
mount -o ro -t ubifs /dev/ubi0_0 /mnt/ubifs/
but this never triggered the assert. So I thought maybe it was
something to do with U-Boot mounting the rootfs to load the kernel and
device tree which are in the UBIFS so I loaded the kernel and device
tree from a TFTP server and then booted from NAND but this still
triggered the assert so this kind of rules out U-Boot.

-Martin

Re: UBIFS assert when rebooting a read only ubifs when it's been remounted r/w

[Martin Townsend]

On Wed, May 18, 2016 at 10:24 AM, Martin Townsend
<mtownsend1973@gmail.com> wrote:
> On Tue, May 17, 2016 at 5:13 PM, Richard Weinberger
> <richard.weinberger@gmail.com> wrote:
>> On Tue, May 17, 2016 at 5:19 PM, Martin Townsend
>> <mtownsend1973@gmail.com> wrote:
>>> Hi,
>>>
>>> I've just seen the following UBIFS assert which relates to
>>> ubifs_remount_fs in fs/ubifs/super.c
>>> We have a read only root filesystem and it looks like this problem
>>> occurs after rebooting the board when the root filesystem has been
>>> remounted as as r/w, I use the following command to do this in case
>>> I'm doing this incorrectly.
>>> mount -o remount,rw /
>>> The only way to stop it is to login and run
>>> mount -o remount,rw /
>>> mount -o remount,ro /
>>> and then reboots do not assert.
>>>
>>> I've tried a few times now and can happily reproduce it.
>>>
>>> Any ideas on how to fix this?
>>
>> Let's analyze the root cause first.
>> Can you please reproduce with the attached debug patch applied?
>> I wonder what the value of c->lst.taken_empty_lebs is.
>>
>> --
>> Thanks,
>> //richard
>
> Here's the output
> [    3.185429] UBIFS error (ubi0:0 pid 106): ubifs_remount_fs:
> taken_empty_lebs is 0
>
> A bit info:
> I booted the board over the network using TFTP/NFS and then mounting
> the UBIFS partition using
> ubiattach /dev/ubi_ctrl -m 12 -O 2048
> mount -o ro -t ubifs /dev/ubi0_0 /mnt/ubifs/
> but this never triggered the assert. So I thought maybe it was
> something to do with U-Boot mounting the rootfs to load the kernel and
> device tree which are in the UBIFS so I loaded the kernel and device
> tree from a TFTP server and then booted from NAND but this still
> triggered the assert so this kind of rules out U-Boot.
>
> -Martin
Here's the kernel bootargs in case they help
console=ttyS0,115200n8 root=ubi0:rootfs ro ubi.mtd=NAND.rootfs,2048
rootfstype=ubifs rootwait=1 mtdoops.mtddev=13 loglevel=5

Re: UBIFS assert when rebooting a read only ubifs when it's been remounted r/w

[Richard Weinberger]

Am 18.05.2016 um 11:24 schrieb Martin Townsend:
> A bit info:
> I booted the board over the network using TFTP/NFS and then mounting
> the UBIFS partition using
> ubiattach /dev/ubi_ctrl -m 12 -O 2048
> mount -o ro -t ubifs /dev/ubi0_0 /mnt/ubifs/
> but this never triggered the assert. So I thought maybe it was
> something to do with U-Boot mounting the rootfs to load the kernel and
> device tree which are in the UBIFS so I loaded the kernel and device
> tree from a TFTP server and then booted from NAND but this still
> triggered the assert so this kind of rules out U-Boot.

So, you can trigger without U-Boot touching the UBIFS?
Also no UBI attach happens in U-Boot?

Is the assert you're facing really the top most error?
Another question, goes the error way when you call "sync"
before remounting ro?

Thanks,
//richard

Re: UBIFS assert when rebooting a read only ubifs when it's been remounted r/w

[Martin Townsend]

On Wed, May 18, 2016 at 11:13 AM, Richard Weinberger <richard@nod.at> wrote:
> Am 18.05.2016 um 11:24 schrieb Martin Townsend:
>> A bit info:
>> I booted the board over the network using TFTP/NFS and then mounting
>> the UBIFS partition using
>> ubiattach /dev/ubi_ctrl -m 12 -O 2048
>> mount -o ro -t ubifs /dev/ubi0_0 /mnt/ubifs/
>> but this never triggered the assert. So I thought maybe it was
>> something to do with U-Boot mounting the rootfs to load the kernel and
>> device tree which are in the UBIFS so I loaded the kernel and device
>> tree from a TFTP server and then booted from NAND but this still
>> triggered the assert so this kind of rules out U-Boot.
>
> So, you can trigger without U-Boot touching the UBIFS?
> Also no UBI attach happens in U-Boot?
>
> Is the assert you're facing really the top most error?
> Another question, goes the error way when you call "sync"
> before remounting ro?
>
> Thanks,
> //richard

Here are the U-Boot commands I ran
setenv autoload no; dhcp; tftp ${loadaddr} ${bootfile}; tftp
${fdtaddr} ${fdtfile};
run nandargs -> This just sets the bootargs variable
bootz ${loadaddr} - ${fdtaddr}
I don't think any of these will trigger any UBI related functions, so
yes to the first 2 questions.

There are 3 errors before the UBIFS one and they are all OMAP related
and have always been there.  I've included some more of the log which
has some more UBI info that might be of interest as it states that a
recovery was needed but deferred.

I can't do the sync as the error only occurs during boot and I can see
the assert whilst systemd is rmounting all the filesystems. Once I've
logged in I can't get the assert to trigger again.  Just to summarise
the conditions for triggering the assert
To trigger I login and remount / as rw and then reboot (to a ro
rootfs) and the assert first during the boot.
The assert will appear on all subsequent boots (Providing I don't do
the following)
To get rid of the assert I can, once logged in, remount / rw and then
ro and then reboot.

Here's that log output:
May 18 10:20:56 am43-controller-aquila-1bf6b1 kernel: nand: device
found, Manufacturer ID: 0x2c, Chip ID: 0xdc
May 18 10:20:56 am43-controller-aquila-1bf6b1 kernel: nand: Micron
MT29F4G08ABADAWP
May 18 10:20:56 am43-controller-aquila-1bf6b1 kernel: nand: 512 MiB,
SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
May 18 10:20:56 am43-controller-aquila-1bf6b1 kernel: nand: using
OMAP_ECC_BCH8_CODE_HW ECC scheme
May 18 10:20:56 am43-controller-aquila-1bf6b1 kernel: 14 ofpart
partitions found on MTD device 8000000.nand
May 18 10:20:56 am43-controller-aquila-1bf6b1 kernel: Creating 14 MTD
partitions on "8000000.nand":
May 18 10:20:56 am43-controller-aquila-1bf6b1 kernel:
0x000000000000-0x000000020000 : "NAND.SPL"
May 18 10:20:56 am43-controller-aquila-1bf6b1 kernel:
0x000000020000-0x000000040000 : "NAND.SPL.backup1"
May 18 10:20:56 am43-controller-aquila-1bf6b1 kernel:
0x000000040000-0x000000060000 : "NAND.SPL.backup2"
May 18 10:20:56 am43-controller-aquila-1bf6b1 kernel:
0x000000060000-0x000000080000 : "NAND.SPL.backup3"
May 18 10:20:56 am43-controller-aquila-1bf6b1 kernel:
0x000000080000-0x0000000a0000 : "NAND.dtb"
May 18 10:20:56 am43-controller-aquila-1bf6b1 kernel:
0x0000000a0000-0x0000000c0000 : "NAND.dtb.backup1"
May 18 10:20:56 am43-controller-aquila-1bf6b1 kernel:
0x0000000c0000-0x0000000e0000 : "NAND.dtb.backup2"
May 18 10:20:56 am43-controller-aquila-1bf6b1 kernel:
0x0000000e0000-0x000000100000 : "NAND.dtb.backup3"
May 18 10:20:56 am43-controller-aquila-1bf6b1 kernel:
0x000000100000-0x000000180000 : "NAND.u-boot"
May 18 10:20:56 am43-controller-aquila-1bf6b1 kernel: mmc0: host does
not support reading read-only switch, assuming write-enable
May 18 10:20:56 am43-controller-aquila-1bf6b1 kernel:
0x000000180000-0x000000200000 : "NAND.u-boot.backup1"
May 18 10:20:56 am43-controller-aquila-1bf6b1 kernel:
0x000000200000-0x000000240000 : "NAND.u-boot-env"
May 18 10:20:56 am43-controller-aquila-1bf6b1 kernel:
0x000000240000-0x000000280000 : "NAND.u-boot-env.backup1"
May 18 10:20:56 am43-controller-aquila-1bf6b1 kernel:
0x000000280000-0x00001ff80000 : "NAND.rootfs"
May 18 10:20:56 am43-controller-aquila-1bf6b1 kernel: mmc0: new high
speed SDHC card at address e624
May 18 10:20:56 am43-controller-aquila-1bf6b1 kernel: mmcblk0:
mmc0:e624 SU08G 7.40 GiB
May 18 10:20:56 am43-controller-aquila-1bf6b1 kernel:  mmcblk0: p1 p2
May 18 10:20:56 am43-controller-aquila-1bf6b1 kernel: mmc1:
MAN_BKOPS_EN bit is not set
May 18 10:20:56 am43-controller-aquila-1bf6b1 kernel: mmc1: new high
speed MMC card at address 0001
May 18 10:20:56 am43-controller-aquila-1bf6b1 kernel: mmcblk1:
mmc1:0001 8GND3R 7.28 GiB
May 18 10:20:56 am43-controller-aquila-1bf6b1 kernel: mmcblk1boot0:
mmc1:0001 8GND3R partition 1 4.00 MiB
May 18 10:20:56 am43-controller-aquila-1bf6b1 kernel: mmcblk1boot1:
mmc1:0001 8GND3R partition 2 4.00 MiB
May 18 10:20:56 am43-controller-aquila-1bf6b1 kernel:  mmcblk1: p1 p2
May 18 10:20:56 am43-controller-aquila-1bf6b1 kernel:
0x00001ff80000-0x000020000000 : "NAND.mtdoops"
May 18 10:20:56 am43-controller-aquila-1bf6b1 kernel: mtdoops: ready
0, 1 (no erase)
May 18 10:20:56 am43-controller-aquila-1bf6b1 kernel: mtdoops:
Attached to MTD device 13
May 18 10:20:56 am43-controller-aquila-1bf6b1 kernel: omap_i2c
44e0b000.i2c: bus 0 rev0.12 at 100 kHz
May 18 10:20:56 am43-controller-aquila-1bf6b1 kernel: rtc-isl12057
1-0068: rtc core: registered rtc-isl12057 as rtc0
May 18 10:20:56 am43-controller-aquila-1bf6b1 kernel: at24 1-0050:
8192 byte 24c64 EEPROM, writable, 1 bytes/write
May 18 10:20:56 am43-controller-aquila-1bf6b1 kernel: omap_i2c
4802a000.i2c: bus 1 rev0.12 at 100 kHz
May 18 10:20:56 am43-controller-aquila-1bf6b1 kernel: wkup_m3_ipc
44e11324.wkup_m3_ipc: wkup_m3_ipc probe success
May 18 10:20:56 am43-controller-aquila-1bf6b1 kernel: ubi0: attaching mtd12
May 18 10:20:56 am43-controller-aquila-1bf6b1 kernel: ubi0: scanning is finished
May 18 10:20:56 am43-controller-aquila-1bf6b1 kernel: ubi0: attached
mtd12 (name "NAND.rootfs", size 509 MiB)
May 18 10:20:56 am43-controller-aquila-1bf6b1 kernel: ubi0: PEB size:
131072 bytes (128 KiB), LEB size: 126976 bytes
May 18 10:20:56 am43-controller-aquila-1bf6b1 kernel: ubi0: min./max.
I/O unit sizes: 2048/2048, sub-page size 512
May 18 10:20:56 am43-controller-aquila-1bf6b1 kernel: ubi0: VID header
offset: 2048 (aligned 2048), data offset: 4096
May 18 10:20:56 am43-controller-aquila-1bf6b1 kernel: ubi0: good PEBs:
4070, bad PEBs: 2, corrupted PEBs: 0
May 18 10:20:56 am43-controller-aquila-1bf6b1 kernel: ubi0: user
volume: 1, internal volumes: 1, max. volumes count: 128
May 18 10:20:56 am43-controller-aquila-1bf6b1 kernel: ubi0: max/mean
erase counter: 1/0, WL threshold: 4096, image sequence number:
1528335448
May 18 10:20:56 am43-controller-aquila-1bf6b1 kernel: ubi0: available
PEBs: 0, total reserved PEBs: 4070, PEBs reserved for bad PEB
handling: 78
May 18 10:20:56 am43-controller-aquila-1bf6b1 kernel: ubi0: background
thread "ubi_bgt0d" started, PID 76
May 18 10:20:56 am43-controller-aquila-1bf6b1 kernel: rtc-isl12057
1-0068: setting system clock to 2016-05-18 10:20:55 UTC (1463566855)
May 18 10:20:56 am43-controller-aquila-1bf6b1 kernel:
touch_3v3_regulator: disabling
May 18 10:20:56 am43-controller-aquila-1bf6b1 kernel: vmmcwl_fixed: disabling
May 18 10:20:56 am43-controller-aquila-1bf6b1 kernel: UBIFS (ubi0:0):
recovery needed
May 18 10:20:56 am43-controller-aquila-1bf6b1 kernel: UBIFS (ubi0:0):
recovery deferred
May 18 10:20:56 am43-controller-aquila-1bf6b1 kernel: UBIFS (ubi0:0):
UBIFS: mounted UBI device 0, volume 0, name "rootfs", R/O mode
May 18 10:20:56 am43-controller-aquila-1bf6b1 kernel: UBIFS (ubi0:0):
LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048
bytes/2048 bytes
May 18 10:20:56 am43-controller-aquila-1bf6b1 kernel: UBIFS (ubi0:0):
FS size: 504983552 bytes (481 MiB, 3977 LEBs), journal size 9023488
bytes (8 MiB, 72 LEBs)
May 18 10:20:56 am43-controller-aquila-1bf6b1 kernel: UBIFS (ubi0:0):
reserved for root: 0 bytes (0 KiB)
May 18 10:20:56 am43-controller-aquila-1bf6b1 kernel: UBIFS (ubi0:0):
media format: w4/r0 (latest is w4/r0), UUID
05AF8668-C412-4672-AD8F-574C29776A53, small LPT model
May 18 10:20:56 am43-controller-aquila-1bf6b1 kernel: VFS: Mounted
root (ubifs filesystem) readonly on device 0:15.
May 18 10:20:56 am43-controller-aquila-1bf6b1 kernel: devtmpfs: mounted
May 18 10:20:56 am43-controller-aquila-1bf6b1 kernel: Freeing unused
kernel memory: 340K (c081d000 - c0872000)
May 18 10:20:56 am43-controller-aquila-1bf6b1 kernel: NET: Registered
protocol family 10
May 18 10:20:56 am43-controller-aquila-1bf6b1 kernel: random: systemd
urandom read with 4 bits of entropy available
May 18 10:20:56 am43-controller-aquila-1bf6b1 systemd[1]: systemd 225
running in system mode. (+PAM -AUDIT -SELINUX +IMA -APPARMOR +SMACK
+SYSVINIT +UTMP -LIBCRYPTSETUP -GCRYPT +GNUTLS +ACL +XZ -LZ4 -SECCOMP
+BLKID -ELFUTILS +KMOD -IDN)
May 18 10:20:56 am43-controller-aquila-1bf6b1 systemd[1]: Detected
architecture arm.
May 18 10:20:56 am43-controller-aquila-1bf6b1 systemd[1]: Set hostname
to <am43-controller-aquila-1bf6b1>.
May 18 10:20:56 am43-controller-aquila-1bf6b1 systemd[1]: Initializing
machine ID from random generator.
May 18 10:20:56 am43-controller-aquila-1bf6b1 systemd[1]: Installed
transient /etc/machine-id file.
May 18 10:20:56 am43-controller-aquila-1bf6b1 systemd[1]: Reached
target Remote File Systems.
May 18 10:20:56 am43-controller-aquila-1bf6b1 systemd[1]: Reached target Swap.
May 18 10:20:56 am43-controller-aquila-1bf6b1 systemd[1]: Started
Forward Password Requests to Wall Directory Watch.
May 18 10:20:56 am43-controller-aquila-1bf6b1 systemd[1]: Created
slice Root Slice.
May 18 10:20:56 am43-controller-aquila-1bf6b1 systemd[1]: Listening on
Journal Socket (/dev/log).
May 18 10:20:56 am43-controller-aquila-1bf6b1 systemd[1]: Listening on
/dev/initctl Compatibility Named Pipe.
May 18 10:20:56 am43-controller-aquila-1bf6b1 systemd[1]: Listening on
udev Kernel Socket.
May 18 10:20:56 am43-controller-aquila-1bf6b1 systemd[1]: Listening on
Syslog Socket.
May 18 10:20:56 am43-controller-aquila-1bf6b1 systemd[1]: Listening on
Journal Socket.
May 18 10:20:56 am43-controller-aquila-1bf6b1 systemd[1]: Listening on
udev Control Socket.
May 18 10:20:56 am43-controller-aquila-1bf6b1 systemd[1]: Created
slice User and Session Slice.
May 18 10:20:56 am43-controller-aquila-1bf6b1 systemd[1]: Created
slice System Slice.
May 18 10:20:56 am43-controller-aquila-1bf6b1 systemd[1]: Mounting
Debug File System...
May 18 10:20:56 am43-controller-aquila-1bf6b1 systemd[1]: Starting
Create list of required static device nodes for the current kernel...
May 18 10:20:56 am43-controller-aquila-1bf6b1 systemd[1]: Created
slice system-busybox\x2difplugd.slice.
May 18 10:20:56 am43-controller-aquila-1bf6b1 systemd[1]: Mounting
Temporary Directory...
May 18 10:20:56 am43-controller-aquila-1bf6b1 systemd[1]: Mounting
POSIX Message Queue File System...
May 18 10:20:56 am43-controller-aquila-1bf6b1 systemd[1]: Reached target Slices.
May 18 10:20:56 am43-controller-aquila-1bf6b1 systemd[1]: Starting
Remount Root and Kernel File Systems...
May 18 10:20:56 am43-controller-aquila-1bf6b1 systemd[1]: Starting
Apply Kernel Variables...
May 18 10:20:56 am43-controller-aquila-1bf6b1 systemd[1]: Mounting
Configuration File System...
May 18 10:20:56 am43-controller-aquila-1bf6b1 kernel: UBIFS assert
failed in ubifs_remount_fs at 1869 (pid 97)
May 18 10:20:56 am43-controller-aquila-1bf6b1 kernel: CPU: 0 PID: 97
Comm: mount Not tainted 4.1.18-g6b41ca0b94 #1
....

Re: UBIFS assert when rebooting a read only ubifs when it's been remounted r/w

[Richard Weinberger]

Am 18.05.2016 um 12:39 schrieb Martin Townsend:
> I can't do the sync as the error only occurs during boot and I can see
> the assert whilst systemd is rmounting all the filesystems. Once I've
> logged in I can't get the assert to trigger again.  Just to summarise
> the conditions for triggering the assert
> To trigger I login and remount / as rw and then reboot (to a ro
> rootfs) and the assert first during the boot.
> The assert will appear on all subsequent boots (Providing I don't do
> the following)
> To get rid of the assert I can, once logged in, remount / rw and then
> ro and then reboot.

Hmm, so there is no reset/power cut involved at all?
Can you trigger it when you mount a UBIFS by hand ro and remount?

Thanks,
//richard

Re: UBIFS assert when rebooting a read only ubifs when it's been remounted r/w

[Richard Weinberger]

Am 20.05.2016 um 09:49 schrieb Richard Weinberger:
> Am 18.05.2016 um 12:39 schrieb Martin Townsend:
>> I can't do the sync as the error only occurs during boot and I can see
>> the assert whilst systemd is rmounting all the filesystems. Once I've
>> logged in I can't get the assert to trigger again.  Just to summarise
>> the conditions for triggering the assert
>> To trigger I login and remount / as rw and then reboot (to a ro
>> rootfs) and the assert first during the boot.
>> The assert will appear on all subsequent boots (Providing I don't do
>> the following)
>> To get rid of the assert I can, once logged in, remount / rw and then
>> ro and then reboot.
> 
> Hmm, so there is no reset/power cut involved at all?
> Can you trigger it when you mount a UBIFS by hand ro and remount?

Another thought, can you try this patch (if it is not already applied)?

commit 807612db2f9940b9fa6deaef054eb16d51bd3e00
Author: Andrew Ruder <andrew.ruder@elecsyscorp.com>
Date:   Thu Jan 30 09:26:54 2014 -0600

    fs/super.c: sync ro remount after blocking writers

    Move sync_filesystem() after sb_prepare_remount_readonly().  If writers
    sneak in anywhere from sync_filesystem() to sb_prepare_remount_readonly()
    it can cause inodes to be dirtied and writeback to occur well after
    sys_mount() has completely successfully.

    This was spotted by corrupted ubifs filesystems on reboot, but appears
    that it can cause issues with any filesystem using writeback.

    Cc: Artem Bityutskiy <dedekind1@gmail.com>
    Cc: Christoph Hellwig <hch@infradead.org>
    Cc: Alexander Viro <viro@zeniv.linux.org.uk>
    CC: Richard Weinberger <richard@nod.at>
    Co-authored-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Andrew Ruder <andrew.ruder@elecsyscorp.com>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

Thanks,
//richard

Re: UBIFS assert when rebooting a read only ubifs when it's been remounted r/w

[Martin Townsend]

On Fri, May 20, 2016 at 8:49 AM, Richard Weinberger <richard@nod.at> wrote:
> Am 18.05.2016 um 12:39 schrieb Martin Townsend:
>> I can't do the sync as the error only occurs during boot and I can see
>> the assert whilst systemd is rmounting all the filesystems. Once I've
>> logged in I can't get the assert to trigger again.  Just to summarise
>> the conditions for triggering the assert
>> To trigger I login and remount / as rw and then reboot (to a ro
>> rootfs) and the assert first during the boot.
>> The assert will appear on all subsequent boots (Providing I don't do
>> the following)
>> To get rid of the assert I can, once logged in, remount / rw and then
>> ro and then reboot.
>
> Hmm, so there is no reset/power cut involved at all?
> Can you trigger it when you mount a UBIFS by hand ro and remount?
>
I was resetting the board but will try the reboot command, I won't be
able to try until Monday though as I don't currently have the board.
I couldn't trigger this by booting via NFS and then trying to manually
mount, remount UBIFS.

Also will try patch on Monday :)

Cheers,
Martin.

> Thanks,
> //richard

Re: UBIFS assert when rebooting a read only ubifs when it's been remounted r/w

[Martin Townsend]

On Fri, May 20, 2016 at 10:47 AM, Martin Townsend
<mtownsend1973@gmail.com> wrote:
> On Fri, May 20, 2016 at 8:49 AM, Richard Weinberger <richard@nod.at> wrote:
>> Am 18.05.2016 um 12:39 schrieb Martin Townsend:
>>> I can't do the sync as the error only occurs during boot and I can see
>>> the assert whilst systemd is rmounting all the filesystems. Once I've
>>> logged in I can't get the assert to trigger again.  Just to summarise
>>> the conditions for triggering the assert
>>> To trigger I login and remount / as rw and then reboot (to a ro
>>> rootfs) and the assert first during the boot.
>>> The assert will appear on all subsequent boots (Providing I don't do
>>> the following)
>>> To get rid of the assert I can, once logged in, remount / rw and then
>>> ro and then reboot.
>>
>> Hmm, so there is no reset/power cut involved at all?
>> Can you trigger it when you mount a UBIFS by hand ro and remount?
>>
> I was resetting the board but will try the reboot command, I won't be
> able to try until Monday though as I don't currently have the board.
> I couldn't trigger this by booting via NFS and then trying to manually
> mount, remount UBIFS.
>
> Also will try patch on Monday :)
Hi Richard,

with reboot I get the assert on shutdown too, the commit
807612db2f9940b9fa6deaef054eb16d51bd3e00 is there already.  A
colleague doesn't see this problem so I will try on a newly flashed
board.

[  OK  ] Reached target Shutdown.
[   23.537561] watchdog watchdog0: watchdog did not stop!
[   23.660530] UBIFS assert failed in ubifs_remount_fs at 1869 (pid 1)
[   23.668470] CPU: 0 PID: 1 Comm: systemd-shutdow Tainted: G
 O    4.1.18-g6b41ca0b94 #1
[   23.677338] Hardware name: Generic AM43 (Flattened Device Tree)
[   23.683285] Backtrace:
[   23.687520] [<c0013398>] (dump_backtrace) from [<c00135b8>]
(show_stack+0x18/0x1c)
[   23.695223]  r7:00000000 r6:ee8abee4 r5:00000000 r4:ee01a000
[   23.700953] [<c00135a0>] (show_stack) from [<c060006c>]
(dump_stack+0x20/0x28)
[   23.708277] [<c060004c>] (dump_stack) from [<c029ba4c>]
(ubifs_remount_fs+0x558/0x800)
[   23.716325] [<c029b4f4>] (ubifs_remount_fs) from [<c013e1e0>]
(do_remount_sb+0x6c/0x1d8)
[   23.724469]  r9:ee0dfc40 r8:00000000 r7:00000000 r6:00000000
r5:00000000 r4:ee0dfc00
[   23.732293] [<c013e174>] (do_remount_sb) from [<c015d69c>]
(do_mount+0x80c/0xcd0)
[   23.739821]  r8:00000021 r7:ee0dfc00 r6:ee0fe0d0 r5:00000060 r4:00000000
[   23.746604] [<c015ce90>] (do_mount) from [<c015dee4>] (SyS_mount+0x9c/0xc8)
[   23.753592]  r10:00000000 r9:ee8aa000 r8:00000021 r7:7f5cc008
r6:00000000 r5:00000000
[   23.761502]  r4:00000000
[   23.764060] [<c015de48>] (SyS_mount) from [<c000f920>]
(ret_fast_syscall+0x0/0x3c)
[   23.771672]  r8:c000fac4 r7:00000015 r6:7f5c4464 r5:00000000 r4:00000000
[   23.778504] UBIFS assert failed in ubifs_remount_fs at 1869 (pid 1)
[   23.785113] CPU: 0 PID: 1 Comm: systemd-shutdow Tainted: G
 O    4.1.18-g6b41ca0b94 #1
[   23.793925] Hardware name: Generic AM43 (Flattened Device Tree)
[   23.799981] Backtrace:
[   23.802518] [<c0013398>] (dump_backtrace) from [<c00135b8>]
(show_stack+0x18/0x1c)
[   23.810446]  r7:00000000 r6:ee8abee4 r5:00000000 r4:ee01a000
[   23.816227] [<c00135a0>] (show_stack) from [<c060006c>]
(dump_stack+0x20/0x28)
[   23.823494] [<c060004c>] (dump_stack) from [<c029ba4c>]
(ubifs_remount_fs+0x558/0x800)
[   23.831597] [<c029b4f4>] (ubifs_remount_fs) from [<c013e1e0>]
(do_remount_sb+0x6c/0x1d8)
[   23.839806]  r9:ee0dfc40 r8:00000000 r7:00000000 r6:00000000
r5:00000000 r4:ee0dfc00
[   23.847748] [<c013e174>] (do_remount_sb) from [<c015d69c>]
(do_mount+0x80c/0xcd0)
[   23.855337]  r8:00000021 r7:ee0dfc00 r6:ee0fe0d0 r5:00000060 r4:00000000
[   23.862231] [<c015ce90>] (do_mount) from [<c015dee4>] (SyS_mount+0x9c/0xc8)
[   23.869374]  r10:00000000 r9:ee8aa000 r8:00000021 r7:7f5cc008
r6:00000000 r5:00000000
[   23.877312]  r4:00000000
[   23.879869] [<c015de48>] (SyS_mount) from [<c000f920>]
(ret_fast_syscall+0x0/0x3c)
[   23.887499]  r8:c000fac4 r7:00000015 r6:7f5c4464 r5:00000000 r4:00000000

- Martin

> Cheers,
> Martin.
>
>> Thanks,
>> //richard
>
> Cheers,
> Martin.
>
>> Thanks,
>> //richard

Re: UBIFS assert when rebooting a read only ubifs when it's been remounted r/w

[Richard Weinberger]

Am 23.05.2016 um 16:16 schrieb Martin Townsend:
>> Also will try patch on Monday :)
> Hi Richard,
> 
> with reboot I get the assert on shutdown too, the commit
> 807612db2f9940b9fa6deaef054eb16d51bd3e00 is there already.  A
> colleague doesn't see this problem so I will try on a newly flashed
> board.

Interesting, so it happens only with that UBIFS instance?
Can you share a nanddump?

Thanks,
//richard

Re: UBIFS assert when rebooting a read only ubifs when it's been remounted r/w

[Martin Townsend]

On Mon, May 23, 2016 at 8:57 PM, Richard Weinberger <richard@nod.at> wrote:
> Am 23.05.2016 um 16:16 schrieb Martin Townsend:
>>> Also will try patch on Monday :)
>> Hi Richard,
>>
>> with reboot I get the assert on shutdown too, the commit
>> 807612db2f9940b9fa6deaef054eb16d51bd3e00 is there already.  A
>> colleague doesn't see this problem so I will try on a newly flashed
>> board.
>
> Interesting, so it happens only with that UBIFS instance?
> Can you share a nanddump?
>
No problem, is there a specific command? looking at the help I would guess:
nanddump --bb=dumpbad --oob -f nand.img /dev/mtdX

Is there a preference as to where to put the dump file?

> Thanks,
> //richard

Re: UBIFS assert when rebooting a read only ubifs when it's been remounted r/w

[Richard Weinberger]

Am 24.05.2016 um 10:31 schrieb Martin Townsend:
> On Mon, May 23, 2016 at 8:57 PM, Richard Weinberger <richard@nod.at> wrote:
>> Am 23.05.2016 um 16:16 schrieb Martin Townsend:
>>>> Also will try patch on Monday :)
>>> Hi Richard,
>>>
>>> with reboot I get the assert on shutdown too, the commit
>>> 807612db2f9940b9fa6deaef054eb16d51bd3e00 is there already.  A
>>> colleague doesn't see this problem so I will try on a newly flashed
>>> board.
>>
>> Interesting, so it happens only with that UBIFS instance?
>> Can you share a nanddump?
>>
> No problem, is there a specific command? looking at the help I would guess:
> nanddump --bb=dumpbad --oob -f nand.img /dev/mtdX

nandump --omitoob -f nand.img /dev/mtdX is fine.


> Is there a preference as to where to put the dump file?

Anything where I can download anonymously is fine.

Thanks,
//richard

Re: UBIFS assert when rebooting a read only ubifs when it's been remounted r/w

[Martin Townsend]

On Tue, May 24, 2016 at 10:04 AM, Richard Weinberger <richard@nod.at> wrote:
> Am 24.05.2016 um 10:31 schrieb Martin Townsend:
>> On Mon, May 23, 2016 at 8:57 PM, Richard Weinberger <richard@nod.at> wrote:
>>> Am 23.05.2016 um 16:16 schrieb Martin Townsend:
>>>>> Also will try patch on Monday :)
>>>> Hi Richard,
>>>>
>>>> with reboot I get the assert on shutdown too, the commit
>>>> 807612db2f9940b9fa6deaef054eb16d51bd3e00 is there already.  A
>>>> colleague doesn't see this problem so I will try on a newly flashed
>>>> board.
>>>
>>> Interesting, so it happens only with that UBIFS instance?
>>> Can you share a nanddump?
>>>
>> No problem, is there a specific command? looking at the help I would guess:
>> nanddump --bb=dumpbad --oob -f nand.img /dev/mtdX
>
> nandump --omitoob -f nand.img /dev/mtdX is fine.
>
>
>> Is there a preference as to where to put the dump file?
>
> Anything where I can download anonymously is fine.
>

Here's a link to the image
https://file.io/0s7OA9

I've just tried on another board and can still get the same assert so
it's not just a one off. I also saw this warning whilst formatting
this board.  I tried reflashing again until I did not get the warning
below but still saw the assert so I don't think they are related.
ubiformat: mtd12 (nand), size 533725184 bytes (509.0 MiB), 4072
eraseblocks of 131072 bytes (128.0 KiB), min. I/O size 2048 bytes
libscan: scanning eraseblock 4071 -- 100 % complete
ubiformat: 4070 eraseblocks are supposedly empty
ubiformat: 2 bad eraseblocks found, numbers: 1324, 1640
ubiformat: flashing eraseblock 191 -- 17 % complete  [   51.525672]
------------[ cut here ]------------
[   80.185567] WARNING: CPU: 0 PID: 896 at
/home/poweroasis/bia/build/am43-controller-aquila/tmp/work-shared/am43-controller-aquila/kernel-source/drivers/mtd/nand/nand_base.c:928
nand_wait+0x150/0x174()
[   80.207539] Modules linked in: xhci_plat_hcd xhci_hcd usbcore cmac
esp4 ah4 crypto_null rpmsg_pru virtio_rpmsg_bus pru_rproc dwc3
udc_core ti_am335x_adc kfifo_buf industrialio cpufreq_voltdm
thermal_sys pruss dwc3_omap extcon omap_rng c_can_platform c_can
rng_core can_dev max31865(O) lm73 hwmon omap_wdt ti_am335x_tscadc
phy_omap_usb2 sch_fq_codel ipv6
[   80.239238] CPU: 0 PID: 896 Comm: ubiformat Tainted: G           O
  4.1.18-g6b41ca0b94 #1
[   80.251528] Hardware name: Generic AM43 (Flattened Device Tree)
[   80.259707] Backtrace:
[   80.262225] [<c0013398>] (dump_backtrace) from [<c00135b8>]
(show_stack+0x18/0x1c)
[   80.273766]  r7:c07c11f4 r6:000003a0 r5:00000009 r4:00000000
[   80.279692] [<c00135a0>] (show_stack) from [<c060006c>]
(dump_stack+0x20/0x28)
[   80.291014] [<c060004c>] (dump_stack) from [<c00393f4>]
(warn_slowpath_common+0x80/0xb8)
[   80.301369] [<c0039374>] (warn_slowpath_common) from [<c00394d0>]
(warn_slowpath_null+0x24/0x2c)
[   80.312445]  r8:c0919bd8 r7:c0884ee0 r6:ffffaa20 r5:ee040010 r4:00000080
[   80.319433] [<c00394ac>] (warn_slowpath_null) from [<c045a150>]
(nand_wait+0x150/0x174)
[   80.331400] [<c045a000>] (nand_wait) from [<c04585e0>]
(nand_write_page+0x104/0x158)
[   80.341377]  r9:00000000 r8:00009000 r7:00000800 r6:c045d220
r5:ee040010 r4:ee040268
[   80.349386] [<c04584dc>] (nand_write_page) from [<c045ada0>]
(nand_do_write_ops+0x2a0/0x438)
[   80.361838]  r8:00009000 r7:ee040010 r6:ee040268 r5:ec737000 r4:c04584dc
[   80.368796] [<c045ab00>] (nand_do_write_ops) from [<c045b0e8>]
(nand_write+0x64/0x84)
[   80.380498]  r10:00020000 r9:00000000 r8:05da0000 r7:ec720000
r6:ec58be8c r5:ec58bdc8
[   80.388587]  r4:ee040010
[   80.391171] [<c045b084>] (nand_write) from [<c0448284>]
(part_write+0x48/0x50)
[   80.402601]  r10:ec58a000 r9:ee08a000 r8:be7eb418 r7:00000000
r6:00000000 r5:00000000
[   80.412195]  r4:00280000
[   80.416939] [<c044823c>] (part_write) from [<c0444f18>] (mtd_write+0x88/0xa0)
[   80.424109]  r5:00000000 r4:c044823c
[   80.431712] [<c0444e90>] (mtd_write) from [<c044ae1c>]
(mtdchar_write+0xdc/0x288)
[   80.443252]  r7:ec720000 r6:00000000 r5:ec58bf80 r4:00020000
[   80.449538] [<c044ad40>] (mtdchar_write) from [<c013a3a8>]
(__vfs_write+0x34/0xe4)
[   80.461287]  r10:00000000 r9:ec58a000 r8:c000fac4 r7:ec58bf80
r6:00020000 r5:c044ad40
[   80.469339]  r4:ee22ed80
[   80.471908] [<c013a374>] (__vfs_write) from [<c013acd8>]
(vfs_write+0x98/0x1a4)
[   80.484273]  r9:ec58a000 r8:c000fac4 r7:ec58bf80 r6:be7eb418
r5:00020000 r4:ee22ed80
[   80.492131] [<c013ac40>] (vfs_write) from [<c013b60c>] (SyS_write+0x4c/0xa8)
[   80.502751]  r9:ec58a000 r8:c000fac4 r7:00020000 r6:be7eb418
r5:ee22ed80 r4:ee22ed80
[   80.510770] [<c013b5c0>] (SyS_write) from [<c000f920>]
(ret_fast_syscall+0x0/0x3c)
[   80.522050]  r7:00000004 r6:00000000 r5:be80b508 r4:000002d9
[   80.527935] ---[ end trace a11e7645e6ddf1b3 ]---

> Thanks,
> //richard

Re: UBIFS assert when rebooting a read only ubifs when it's been remounted r/w

[Richard Weinberger]

Am 24.05.2016 um 12:37 schrieb Martin Townsend:
> Here's a link to the image
> https://file.io/0s7OA9

404 :-(

> I've just tried on another board and can still get the same assert so
> it's not just a one off. I also saw this warning whilst formatting
> this board.  I tried reflashing again until I did not get the warning
> below but still saw the assert so I don't think they are related.
> ubiformat: mtd12 (nand), size 533725184 bytes (509.0 MiB), 4072
> eraseblocks of 131072 bytes (128.0 KiB), min. I/O size 2048 bytes
> libscan: scanning eraseblock 4071 -- 100 % complete
> ubiformat: 4070 eraseblocks are supposedly empty
> ubiformat: 2 bad eraseblocks found, numbers: 1324, 1640
> ubiformat: flashing eraseblock 191 -- 17 % complete  [   51.525672]
> ------------[ cut here ]------------
> [   80.185567] WARNING: CPU: 0 PID: 896 at
> /home/poweroasis/bia/build/am43-controller-aquila/tmp/work-shared/am43-controller-aquila/kernel-source/drivers/mtd/nand/nand_base.c:928
> nand_wait+0x150/0x174()

Not good. Please verify.
See the comment above that WARN_ON().

Thanks,
//richard

Re: UBIFS assert when rebooting a read only ubifs when it's been remounted r/w

[Martin Townsend]

On Tue, May 24, 2016 at 1:26 PM, Richard Weinberger <richard@nod.at> wrote:
> Am 24.05.2016 um 12:37 schrieb Martin Townsend:
>> Here's a link to the image
>> https://file.io/0s7OA9
>
> 404 :-(
>
>> I've just tried on another board and can still get the same assert so
>> it's not just a one off. I also saw this warning whilst formatting
>> this board.  I tried reflashing again until I did not get the warning
>> below but still saw the assert so I don't think they are related.
>> ubiformat: mtd12 (nand), size 533725184 bytes (509.0 MiB), 4072
>> eraseblocks of 131072 bytes (128.0 KiB), min. I/O size 2048 bytes
>> libscan: scanning eraseblock 4071 -- 100 % complete
>> ubiformat: 4070 eraseblocks are supposedly empty
>> ubiformat: 2 bad eraseblocks found, numbers: 1324, 1640
>> ubiformat: flashing eraseblock 191 -- 17 % complete  [   51.525672]
>> ------------[ cut here ]------------
>> [   80.185567] WARNING: CPU: 0 PID: 896 at
>> /home/poweroasis/bia/build/am43-controller-aquila/tmp/work-shared/am43-controller-aquila/kernel-source/drivers/mtd/nand/nand_base.c:928
>> nand_wait+0x150/0x174()
>
> Not good. Please verify.
> See the comment above that WARN_ON().
>

Try this one:
http://gofile.io/?id=P2z2Zd


Oops sorry about that, trying to do to many things today and missed
the cut here. manged to get the WARN_ON twice in succession this
morning but as you can guess it won't fire now.  It did get this error
though?
ubiformat: formatting eraseblock 3867 -- 93 % co[   92.443658] nand:
nand_erase_nand: attempt to erase a bad block at page 0x0003dc80
ubiformat: formatting eraseblock 3934 -- 95 % complete  libmtd:
error!: MEMERASE64 ioctl failed for eraseblock 3934 (mtd12)
        error 5 (Input/output error)

ubiformat: error!: failed to erase eraseblock 3934
           error 5 (Input/output error)
ubiformat: marking block 3934 bad
ubiformat: formatting eraseblock 4071 -- 100 % complete

I'll send the full backtrace when I get it to fire again.


> Thanks,
> //richard

Re: UBIFS assert when rebooting a read only ubifs when it's been remounted r/w

[Richard Weinberger]

Am 24.05.2016 um 15:23 schrieb Martin Townsend:
> On Tue, May 24, 2016 at 1:26 PM, Richard Weinberger <richard@nod.at> wrote:
>> Am 24.05.2016 um 12:37 schrieb Martin Townsend:
>>> Here's a link to the image
>>> https://file.io/0s7OA9
>>
>> 404 :-(
>>
>>> I've just tried on another board and can still get the same assert so
>>> it's not just a one off. I also saw this warning whilst formatting
>>> this board.  I tried reflashing again until I did not get the warning
>>> below but still saw the assert so I don't think they are related.
>>> ubiformat: mtd12 (nand), size 533725184 bytes (509.0 MiB), 4072
>>> eraseblocks of 131072 bytes (128.0 KiB), min. I/O size 2048 bytes
>>> libscan: scanning eraseblock 4071 -- 100 % complete
>>> ubiformat: 4070 eraseblocks are supposedly empty
>>> ubiformat: 2 bad eraseblocks found, numbers: 1324, 1640
>>> ubiformat: flashing eraseblock 191 -- 17 % complete  [   51.525672]
>>> ------------[ cut here ]------------
>>> [   80.185567] WARNING: CPU: 0 PID: 896 at
>>> /home/poweroasis/bia/build/am43-controller-aquila/tmp/work-shared/am43-controller-aquila/kernel-source/drivers/mtd/nand/nand_base.c:928
>>> nand_wait+0x150/0x174()
>>
>> Not good. Please verify.
>> See the comment above that WARN_ON().
>>
> 
> Try this one:
> http://gofile.io/?id=P2z2Zd

Again file not found. WTF?

Thanks,
//richard

Re: UBIFS assert when rebooting a read only ubifs when it's been remounted r/w

[Martin Townsend]

On Tue, May 24, 2016 at 2:42 PM, Richard Weinberger <richard@nod.at> wrote:
> Am 24.05.2016 um 15:23 schrieb Martin Townsend:
>> On Tue, May 24, 2016 at 1:26 PM, Richard Weinberger <richard@nod.at> wrote:
>>> Am 24.05.2016 um 12:37 schrieb Martin Townsend:
>>>> Here's a link to the image
>>>> https://file.io/0s7OA9
>>>
>>> 404 :-(
>>>
>>>> I've just tried on another board and can still get the same assert so
>>>> it's not just a one off. I also saw this warning whilst formatting
>>>> this board.  I tried reflashing again until I did not get the warning
>>>> below but still saw the assert so I don't think they are related.
>>>> ubiformat: mtd12 (nand), size 533725184 bytes (509.0 MiB), 4072
>>>> eraseblocks of 131072 bytes (128.0 KiB), min. I/O size 2048 bytes
>>>> libscan: scanning eraseblock 4071 -- 100 % complete
>>>> ubiformat: 4070 eraseblocks are supposedly empty
>>>> ubiformat: 2 bad eraseblocks found, numbers: 1324, 1640
>>>> ubiformat: flashing eraseblock 191 -- 17 % complete  [   51.525672]
>>>> ------------[ cut here ]------------
>>>> [   80.185567] WARNING: CPU: 0 PID: 896 at
>>>> /home/poweroasis/bia/build/am43-controller-aquila/tmp/work-shared/am43-controller-aquila/kernel-source/drivers/mtd/nand/nand_base.c:928
>>>> nand_wait+0x150/0x174()
>>>
>>> Not good. Please verify.
>>> See the comment above that WARN_ON().
>>>
>>
>> Try this one:
>> http://gofile.io/?id=P2z2Zd
>
> Again file not found. WTF?
>
aaarrgh, sums my day up so far, try this one, I've just tested and at
least it started downloading the file.
http://tempsend.com/32760A445F

> Thanks,
> //richard

Re: UBIFS assert when rebooting a read only ubifs when it's been remounted r/w

[Richard Weinberger]

Am 24.05.2016 um 16:12 schrieb Martin Townsend:
> aaarrgh, sums my day up so far, try this one, I've just tested and at
> least it started downloading the file.
> http://tempsend.com/32760A445F

That worked.
Can you please share your NAND id bytes or the flash geometry?

Thanks,
//richard

Re: UBIFS assert when rebooting a read only ubifs when it's been remounted r/w

[Martin Townsend]

On Tue, May 24, 2016 at 5:51 PM, Richard Weinberger <richard@nod.at> wrote:
> Am 24.05.2016 um 16:12 schrieb Martin Townsend:
>> aaarrgh, sums my day up so far, try this one, I've just tested and at
>> least it started downloading the file.
>> http://tempsend.com/32760A445F
>
> That worked.
> Can you please share your NAND id bytes or the flash geometry?
>
This should be the part, it's the 4Gbit device.
https://www.micron.com/parts/nand-flash/mass-storage/mt29f4g08abadawp
Page size x8: 2112 bytes (2048 + 64 bytes)
Block size: 64 pages (128K + 4K bytes)
Plane size: 2 planes x 2048 blocks per plane
Device size: 4Gb: 4096 blocks

- Martin.
> Thanks,
> //richard

Re: UBIFS assert when rebooting a read only ubifs when it's been remounted r/w

[Martin Townsend]

Hi Richard,

On Wed, May 25, 2016 at 9:04 AM, Martin Townsend
<mtownsend1973@gmail.com> wrote:
> On Tue, May 24, 2016 at 5:51 PM, Richard Weinberger <richard@nod.at> wrote:
>> Am 24.05.2016 um 16:12 schrieb Martin Townsend:
>>> aaarrgh, sums my day up so far, try this one, I've just tested and at
>>> least it started downloading the file.
>>> http://tempsend.com/32760A445F
>>
>> That worked.
>> Can you please share your NAND id bytes or the flash geometry?
>>
> This should be the part, it's the 4Gbit device.
> https://www.micron.com/parts/nand-flash/mass-storage/mt29f4g08abadawp
> Page size x8: 2112 bytes (2048 + 64 bytes)
> Block size: 64 pages (128K + 4K bytes)
> Plane size: 2 planes x 2048 blocks per plane
> Device size: 4Gb: 4096 blocks
>
> - Martin.
>> Thanks,
>> //richard

I know many months have passed but I'm looking back into the UBIFS
assert that keeps occurring on our board. We have since moved over to
4.1 LTSI kernel and the problem still occurs. Did you manage to
reproduce this assert with the image I sent or has there has been a
patch submitted recently that may fix this, or if not I'm happy to put
some more printk's in to get some more analysis if the image does show
the problem.

The original assert was

[    4.077496] [<c0013550>] (show_stack) from [<c05f4428>]
(dump_stack+0x20/0x28)
[  OK  ] Started Journal Service.
[    4.099269] [<c05f4408>] (dump_stack) from [<c029ba8c>]
(ubifs_remount_fs+0x558/0x800)
[    4.107743] [<c029b534>] (ubifs_remount_fs) from [<c013dd70>]
(do_remount_sb+0x6c/0x1d8)
[    4.121587]  r9:ee112c40 r8:00000000 r7:00000000 r6:00000000
r5:00000000 r4:ee112c00
[    4.129451] [<c013dd04>] (do_remount_sb) from [<c015d1f8>]
(do_mount+0x810/0xcb0)
[    4.151530]  r8:00000021 r7:ee112c00 r6:ee05c850 r5:00000060 r4:00000000
[    4.158342] [<c015c9e8>] (do_mount) from [<c015da1c>] (SyS_mount+0x9c/0xc8)
[    4.181549]  r10:00000000 r9:ee2ba000 r8:c0ed0021 r7:7f5ed788
r6:00000000 r5:ee2d5480
[    4.189471]  r4:ee2d5440
[    4.208415] [<c015d980>] (SyS_mount) from [<c000f8e0>]
(ret_fast_syscall+0x0/0x3c)
[    4.221613]  r8:c000fa84 r7:00000015 r6:7f5ed778 r5:00000000 r4:00000000

Cheers, Martin.