Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FS#2837 - MT7620: JFFS2 errors with trunk, Archer C20v1 and C20i #7706

Closed
openwrt-bot opened this issue Feb 16, 2020 · 27 comments
Closed

FS#2837 - MT7620: JFFS2 errors with trunk, Archer C20v1 and C20i #7706

openwrt-bot opened this issue Feb 16, 2020 · 27 comments
Labels

Comments

@openwrt-bot
Copy link

mgondium:

I have at least five mt7620 devices (TPLINK Archer C20v1, C20i) that started having flash write errors at startup with trunk.

Had already a similar problem with ar79, can it be related?
https://bugs.openwrt.org/index.php?do=details&task_id=2742&order=id&sort=desc&pagenum=2

OpenWrt SNAPSHOT, r12235-49caf9f98a
Linux OpenWrt 4.14.169 #0 Sat Feb 15 07:57:49 2020 mips GNU/Linux

[ 0.639218] jffs2: version 2.2 (NAND) (SUMMARY) (LZMA) (RTIME) (CMODE_PRIORITY) (c) 2001-2006 Red Hat, Inc.

[ 9.296544] 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.
[ 37.831875] jffs2: Erase at 0x00378000 failed immediately: errno -22

[ 9.301481] jffs2: notice: (414) jffs2_build_xattr_subsystem: complete building xattr subsystem, 5 of xdatum (3 unchecked, 2 orphan) and 15 of xref (2 dead, 0 orphan) found.
[ 72.033254] jffs2: Erase at 0x00378000 failed immediately: errno -22

[ 9.300037] jffs2: notice: (414) jffs2_build_xattr_subsystem: complete building xattr subsystem, 5 of xdatum (3 unchecked, 2 orphan) and 16 of xref (2 dead, 0 orphan) found.
[ 30.629708] jffs2: Erase at 0x00378000 failed immediately: errno -22

[ 9.294011] jffs2: notice: (414) jffs2_build_xattr_subsystem: complete building xattr subsystem, 5 of xdatum (3 unchecked, 2 orphan) and 15 of xref (2 dead, 0 orphan) found.
[ 31.409183] jffs2: Erase at 0x00378000 failed immediately: errno -22

[ 9.286101] jffs2: notice: (411) jffs2_build_xattr_subsystem: complete building xattr subsystem, 4 of xdatum (3 unchecked, 1 orphan) and 17 of xref (1 dead, 0 orphan) found.
[ 93.305969] jffs2: Erase at 0x00378000 failed immediately: errno -22

@openwrt-bot
Copy link
Author

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]].

@openwrt-bot
Copy link
Author

ikazuhiro:

Reverting the above commit resolved the problem in my devices.

@openwrt-bot
Copy link
Author

mgondium:

I confirm, no errors after reverting it!

@openwrt-bot
Copy link
Author

ynezz:

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

@openwrt-bot
Copy link
Author

dormancygrace:

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

@openwrt-bot
Copy link
Author

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.

@openwrt-bot
Copy link
Author

dormancygrace:

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

@openwrt-bot
Copy link
Author

rmilecki:

Use git command
git revert 15a0701

@openwrt-bot
Copy link
Author

dormancygrace:

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

@openwrt-bot
Copy link
Author

dormancygrace:

done

@openwrt-bot
Copy link
Author

mgondium:

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

@openwrt-bot
Copy link
Author

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.

@openwrt-bot
Copy link
Author

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

@openwrt-bot
Copy link
Author

dormancygrace:

How to unrevert (back to master)?

@openwrt-bot
Copy link
Author

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

@openwrt-bot
Copy link
Author

dormancygrace:

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

@openwrt-bot
Copy link
Author

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.

@openwrt-bot
Copy link
Author

dormancygrace:

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

@openwrt-bot
Copy link
Author

dormancygrace:

serial log

@openwrt-bot
Copy link
Author

ikazuhiro:

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

@openwrt-bot
Copy link
Author

bjonglez:

FYI, the offending commit got reverted in fdfca33.

@openwrt-bot
Copy link
Author

mgondium:

I confirm that trunk is good. Close requested.

@openwrt-bot
Copy link
Author

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

@openwrt-bot
Copy link
Author

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).

@openwrt-bot
Copy link
Author

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?

@openwrt-bot
Copy link
Author

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?

@openwrt-bot
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant