ikazuhiro:

My three ramips devices have the same problem. As far as I confirmed, it occurs since [[https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=15a0701cdde8eeae2a54880b813cdb8cdc09a384|commit 15a0701]].

ikazuhiro:

Reverting the above commit resolved the problem in my devices.

mgondium:

I confirm, no errors after reverting it!

ynezz:

Workaround(revert) for this issue has been proposed https://patchwork.ozlabs.org/patch/1247614/

dormancygrace:

Confirm. Just found commit 15a0701 by myself. I`m using Xiaomi Router 4A Gigabit, MT7621

rmilecki:

Someone please provide a complete dmesg from:

• master
• master with 15a0701 reverted

so we can actually understand the issue.

FS#2742 was reported before above commit and its dmesg-s don't contain
Creating 1 MTD partitions on "rootfs":
so it a different issue.

dormancygrace:

How can i revert? or i can go back to previous commit and build.

rmilecki:

Use git command
git revert 15a0701

dormancygrace:

It was not that easy, but seems worked, after some more commands. It`s compiling now.

dormancygrace:

done

mgondium:

Here are mine, notice trunk at over 8 sec uptime.

ikazuhiro:

Here are mine. A device is [[https://openwrt.org/toh/hwdata/tama/tama_w06|Tama W06]]. *-sysupgrade.log are dmesg just after sysupgrade. *-reboot.log are dmesg on simple reboot.

rmilecki:

I've one more (hopefully the last) debugging request. Can you please:

• Switch back to the master branch (don't revert my 15a0701 commit anymore)
• Execute: rm target/linux/generic/pending-/41[12]
• Compile image, flash it, provide boot log, test it

dormancygrace:

How to unrevert (back to master)?

rmilecki:

You can remove the last local commit (like revert commit) and local changes doing:
git reset --hard HEAD~1
after that you can keep doing "git pull"s.

Or you can point what to switch to manually doing:
git fetch
git reset --hard origin/master

dormancygrace:

downloaded new copy. it doesnt start at all. ill check what`s going on in the morning

ikazuhiro:

Here is. The device is [[https://openwrt.org/toh/hwdata/planex/planex_vr500|Planex VR500]]. Bootlogs on master with and without reverted commit 15a0701 also uploaded. The kernel without target/linux/generic/pending-/41[12] may make the device inaccessible via network.

dormancygrace:

So, serial is the only way? Cause I think router works, but without network

dormancygrace:

serial log

ikazuhiro:

Ethernet network switch was not configured on my device, so serial was the only accessible way.

bjonglez:

FYI, the offending commit got reverted in fdfca33.

mgondium:

I confirm that trunk is good. Close requested.

humaita:

Hi,

the commit got reverted for kernel 4.14 but not for kernel 5.4. I still see this bug with the unsupported router Huawei B593u-12 with kernel 5.4.

See logs etc. in the forum: https://forum.openwrt.org/t/wrong-mtd-partitions-detected-in-huawei-b593u-12/77187

Best regards

adrianschmutzler:

Kernel 5.4/4.19 have a patch version that's comparable to 4.14 after the revert (401-mtd-add-support-for-different-partition-parser-types.patch).

humaita:

Hi, thank you for the quick feedback. Yesterdays trunk still had the bug. Removing patches 401-404 as mentioned in the forum post seem to solve the problem. So it looks like the new patch still is not OK?

humaita:

Hi, it turns out that without the patch, the kernel doesnt detect the rootfs_data partition, and thus doesnt try to write to the flash. With the patch, it detects and tries to write to rootfs_data. So it is not 100% clear if these patches are actually the problem or not. Any ideas on how to further diagnose the problem?

thedukesd:

May or may not be related to this problem.

jffs2: notice: (414) jffs2_build_xattr_subsystem: complete building xattr subsystem, 4 of xdatum (3 unchecked, 1 orphan) and 16 of xref (1 dead, 0 orphan) found.

Stuff like this (increasing orphan/dead (maybe unchecked too)) numbers (usually after reboot) started to happen with kernel 4.14 (it's not related to OpenWRT version, 18.06 has some platforms on 4.14 and it happens in 18.06 with kernel 4.14 too). It doesn't happen on 4.9. Based on what logs I saw on forum it looks like 5.4 is also affected. What I don't know is where exactly it started or if it's a kernel issue or a bug caused by some patch used in OpenWRT.

What I wrote here it can easily be another issue. In same time it can be the root of other issues (more like problems getting amplified in time (small problem not fixed, more code added/changed => weird abnormal behaviours)).
What I want to say is that the reverted commit might not be the problem and the problem might easily be somewhere else. The reverted commit might just amplify an already existing problem especially since the behaviour I talk about happened before the commit that was reverted.

Keep in mind that my comment is not about this part:
jffs2: Erase at 0x00378000 failed immediately: errno -22
it's related only to the first line that should show 0 and not numbers that look to increase based on reboot/jffs2 operations.