Igor Posted June 22, 2017 Posted June 22, 2017 Shall we go back with sunxi and cubox NEXT to 4.9.x and push update out since: https://forum.armbian.com/index.php?/topic/4254-cryptdisks-fail-with-new-kernel-41012/#comment-31614 https://forum.armbian.com/index.php?/topic/4498-no-network-after-upgrade-to-530/&page=4#comment-33710 Any other critical thing?
zador.blood.stained Posted June 22, 2017 Posted June 22, 2017 23 minutes ago, Igor said: https://forum.armbian.com/index.php?/topic/4254-cryptdisks-fail-with-new-kernel-41012/#comment-31614 Did you mean this? https://forum.armbian.com/index.php?/topic/4538-cubieboard-2-a20-lxc-issue-after-5314115-upgrade/
tkaiser Posted June 22, 2017 Posted June 22, 2017 What about thinking about (discussing) update procedures? Armbian has default, next and dev variants while the distros are horribly outdated (stable, stable, stable) but for whatever reasons Armbian tries to introduce update drama every few months. Why exactly? I'm a big fan of users testing stuff if they have been warned they're using experimental software. But if users choose to use something called 'stable' why can't Armbian provide something stable? What about differentiating between next (somewhat stable LTS release) and dev (latest and greatest mainline kernel)? Applies even more to u-boot updates (this one -- BTW users and 3rd party image builders don't get it if we remain polite, they simply ignore the contents of the message) 2
zador.blood.stained Posted June 22, 2017 Posted June 22, 2017 7 minutes ago, tkaiser said: Armbian has default, next and stable variants while the distros are horribly outdated (stable, stable, stable) but for whatever reasons Armbian tries to introduce update drama every few months. Why exactly? Bugfixes, security fixes, new features, support for new devices due to "one kernel per SoC family" approach. 7 minutes ago, tkaiser said: I'm a big fan of users testing stuff if they have been warned they're using experimental software. But if users choose to use something called 'stable' why can't Armbian provide something stable? I believe we have an option now - freezing the relevant packages via "armbian-config" (or manually), so the next step is telling about this feature to people who use Armbian for production. 8 minutes ago, tkaiser said: What about differentiating between next (somewhat stable LTS release) and dev (latest and greatest mainline kernel)? If only it was that simple to throw away every legacy "feature" or "convention" that got into the project at some time. At this point it may be easier to make "Armbian-ng" or "Armbian-next", not upgradable from current images, than to change logic for naming kernel and u-boot branches. 1
Igor Posted June 23, 2017 Author Posted June 23, 2017 9 hours ago, zador.blood.stained said: Did you mean this? https://forum.armbian.com/index.php?/topic/4538-cubieboard-2-a20-lxc-issue-after-5314115-upgrade/ Well, also I could reproduce on Hummingboard when trying to connect wireless - it instantly crashed on 4.11.5 while working fine on 4.9.33 ... 9 hours ago, tkaiser said: but for whatever reasons Armbian tries to introduce update drama every few months. Why exactly? Of course there is risk when upgrading, especially u-boot, because worse case boot breaks ... but kernel upgrades are more flexible since it "only" breaks some part of functionality at worse. Like in this example. Perhaps this upgrade procedure should be divided and provide more selective relevant upgrades. That should limit down problems. 9 hours ago, zador.blood.stained said: I believe we have an option now Also possible to apply it to images by default and we gain stability - user must act to get latest updates. Like on deprecated boards. 1
zador.blood.stained Posted June 23, 2017 Posted June 23, 2017 3 hours ago, Igor said: Well, also I could reproduce on Hummingboard when trying to connect wireless - it instantly crashed on 4.11.5 while working fine on 4.9.33 ... Client or AP? Can it be easily reproduced on any other boards (sunxi-next, sun8i-dev branches) so I could try to capture a crash log? I tried to "crash" sunxi-next 4.11.4 kernel with "openssl speed" and "cryptsetup benchmark", but it works fine for me, ars_arm module is loaded without issues.
Igor Posted June 23, 2017 Author Posted June 23, 2017 11 minutes ago, zador.blood.stained said: Client or AP? Can it be easily reproduced on any other boards (sunxi-next, sun8i-dev branches) so I could try to capture a crash log? Client, ath10, crashed also on Clearfog with 4.11. Will do more test and provide logs ... currently out of office.
zador.blood.stained Posted June 23, 2017 Posted June 23, 2017 [ 129.711961] Unable to handle kernel NULL pointer dereference at virtual address 0000000c [ 129.711969] pgd = c0004000 [ 129.711974] [0000000c] *pgd=00000000 [ 129.711988] Internal error: Oops: 5 [#1] SMP THUMB2 [ 129.716887] Modules linked in: aes_arm(+) ath9k ath9k_common ath9k_hw led_class mac80211 ath cfg80211 rfkill marvell_cesa mv_cesa ip_tables x_tables [ 129.730259] CPU: 1 PID: 1814 Comm: cryptomgr_test Not tainted 4.11.4-mvebu #1 [ 129.737413] Hardware name: Marvell Armada 380/385 (Device Tree) [ 129.743347] task: c281b840 task.stack: ed594000 [ 129.747894] PC is at crypto_remove_spawns+0x74/0x178 [ 129.752871] LR is at 0xed595f18 [ 129.756022] pc : [<c03a7990>] lr : [<ed595f18>] psr: a0070033 sp : ed595f10 ip : ed595f20 fp : ed595f50 [ 129.767529] r10: 00000401 r9 : c0a27108 r8 : edeec288 [ 129.772768] r7 : 00000000 r6 : ed595f10 r5 : ed595f18 r4 : 00000000 [ 129.779313] r3 : edee7a88 r2 : bf96e000 r1 : edeec3c0 r0 : c0a27100 [ 129.785857] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA Thumb Segment none [ 129.793185] Control: 50c5387d Table: 2de9004a DAC: 00000051 [ 129.798946] Process cryptomgr_test (pid: 1814, stack limit = 0xed594220) [ 129.805664] Stack: (0xed595f10 to 0xed596000) [ 129.810035] 5f00: ef3e5dc0 ef3e5dc0 edee7bd8 edeec3c0 [ 129.818238] 5f20: ed595f20 ed595f20 00000000 edeecc00 bf96e000 c0a24f58 00000401 c0a27100 [ 129.826440] 5f40: bf96e028 bf96e068 c0a27128 c03a7c71 ed595f50 ed595f50 ed445140 edf0bd80 [ 129.834642] 5f60: ed445140 00000000 ed594000 edf0bd80 c03af865 ed58dd10 ed53b15c c03af86f [ 129.842844] 5f80: ed53b140 c012f3a5 ffffffff ed445140 c012f2b1 00000000 00000000 00000000 [ 129.851045] 5fa0: 00000000 00000000 00000000 c0106071 00000000 00000000 00000000 00000000 [ 129.859246] 5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 129.867447] 5fe0: 00000000 00000000 00000000 00000000 00000013 00000000 ffffffff ffffffff [ 129.875653] [<c03a7990>] (crypto_remove_spawns) from [<c03a7c71>] (crypto_alg_tested+0xf5/0x124) [ 129.884465] [<c03a7c71>] (crypto_alg_tested) from [<c03af86f>] (cryptomgr_test+0xb/0x18) [ 129.892582] [<c03af86f>] (cryptomgr_test) from [<c012f3a5>] (kthread+0xf5/0xfc) [ 129.899918] [<c012f3a5>] (kthread) from [<c0106071>] (ret_from_fork+0x11/0x20) [ 129.907164] Code: 681c 42a3 d014 681c (68e3) 4283 [ 129.912097] ---[ end trace 20ed4eee1eb1850a ]---
Igor Posted June 23, 2017 Author Posted June 23, 2017 I revert cubox and clearfog, for sunxi I am bit confused what to remove and what to leave due to overlay support ... and Tinkerboard / MiQi @TonyMac32, shall we go back to 4.9 with NEXT too?
zador.blood.stained Posted June 23, 2017 Posted June 23, 2017 I'm investigating the issue, it should be possible to fix without reverting kernel versions.
zador.blood.stained Posted June 23, 2017 Posted June 23, 2017 @Igor Please try to compile and test 4.11 with this patch added: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/patch/?id=b56f5cbc7e08ec7d31c42fc41e5247677f20b143 So far it seems to fix the issue on mvebu-next, but I need to build a new image to test this for sure.
zador.blood.stained Posted June 23, 2017 Posted June 23, 2017 Since wireless now works for me on mvebu-next I reverted your last commit for now and added the patch to sunxi-next and mvebu-next. More tests needed (obviously).
TonyMac32 Posted June 23, 2017 Posted June 23, 2017 Wireless isn't up on Tinker Board Next because the driver wasn't added to the kernel until 4.12, On Dev I connect to wireless no problem, it's one of the things I've been making sure to test since fooling with rfkill/btcoexist with Myy to try to get BT to work. For MiQi I don't know without the device. If your MiQi isn't tied up, could you verify if you have any reboot issues with the current legacy 4.4 kernel? 4.12 changes some things it would seem, or the rockchip-linux kernel is just plain that different, attempting to "fix" it the same way did nothing at all on the Tinker Board, but Myy reported it broke rebooting on her MiQi with 4.12. Researching to find another way, I'm not sure where the Kernel decides to shut down all the supplies. If a reboot issue with MiQi exists with the power supply code on Tinker (no one reported an issue, but I don't know how many MiQi people are out there), I'll have to "re-break" the Tinker board for the time being. If reboot can't be fixed properly, that's a major strike against it.
Igor Posted June 23, 2017 Author Posted June 23, 2017 4 hours ago, zador.blood.stained said: Since wireless now works for me on mvebu-next I reverted your last commit for now and added the patch to sunxi-next and mvebu-next. More tests needed (obviously). It works for me to, cubox-next, ath10 and brcmfmac. @tonymac32 Reboot reboots. http://sprunge.us/CaOj U-boot on eMMC: U-Boot SPL 2017.05-rc3-armbian (May 04 2017 - 15:10:29) Returning to boot ROM... U-Boot 2017.05-rc3-armbian (May 04 2017 - 15:10:29 +0200) 2
zador.blood.stained Posted June 23, 2017 Posted June 23, 2017 Just now, Igor said: It works for me to, cubox-next, ath10 and brcmfmac. So the patch needs to be copied to other stable mainline configurations, and then we can make a bugfix release.
zador.blood.stained Posted June 23, 2017 Posted June 23, 2017 5 minutes ago, Igor said: Any objections for rebuild and update? None from me, I don't see any bugs for stable releases, especially ones that can be quickly fixed.
Recommended Posts