Jump to content

Partial bugfix update


Recommended Posts

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)

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

9 hours ago, zador.blood.stained 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 ... 

 

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

 

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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)

 

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines