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
Comments
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:
so we can actually understand the issue. FS#2742 was reported before above commit and its dmesg-s don't contain |
dormancygrace: How can i revert? or i can go back to previous commit and build. |
rmilecki: Use git command |
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:
|
dormancygrace: How to unrevert (back to master)? |
rmilecki: You can remove the last local commit (like revert commit) and local changes doing: Or you can point what to switch to manually doing: |
dormancygrace: downloaded new copy. it doesn |
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.
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)). Keep in mind that my comment is not about this part: |
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
The text was updated successfully, but these errors were encountered: