[SOLVED] Slarm64 on the Pinebook 1080 - help with kernel?

shelldweller · 03-10-2021, 11:42 AM

I have been timing the boot process of different versions, just out of curiosity. I am not counting the first few boots where it resizes the partition and creates a swap file, those obviously take longer.

The latest legacy image with a 5.4.104 kernel takes about 2:25 to boot to a console login prompt (not counting the graphical login manager).

If I remove (or rename) the initrd, then it takes about 1:55 to boot.

The legacy image with the 5.6.19 kernel boots in about 0:35, even with the initrd in place.

This is not fatal, but it is definitely noticeable.

After the boot process is done and the performance governor kicks in, the 5.4.y kernels seem fine so far, although I have not tested them extensively under high I/O load yet, which is what tends to lock up the 5.6.19 kernel, while the 5.5.y series was more robust in that sense.

I went ahead and uploaded some 5.4.104 images just in case anyone wants to try them out:

[removed, see below for better images using the same kernel]

sndwvs · 03-10-2021, 11:51 AM

I enabled PERFORMANCE by default.

shelldweller · 03-10-2021, 12:10 PM

Quote:

Originally Posted by sndwvs

I enabled PERFORMANCE by default.

Thank you, building now...., will report back.

shelldweller · 03-11-2021, 11:43 AM

Okay, this was a success! These images boot in under 50 seconds, even with initrd in place. Also, I spent some time testing it under heavy I/O load (specifically, downloading a torrent with a large number of seeders using a usb-ethernet converter while doing other random tasks). It did slow down significantly a few times, but I was always able to move the mouse cursor around, and I was always able to switch to another console and log in and muck around as root while the download continued. Never did it lock up fully, which I cannot say for the 5.6.19 kernel.

So, all tests passed. Boots quick, snappy on the desktop, all hardware features work, and handles the I/O load quite well compared to other kernels. I call this one a winner!

slarm64-current-aarch64-base-pinebook-5.4.104-build-20210310.img.zst
slarm64-current-aarch64-base-pinebook-5.4.104-build-20210310.img.zst.sha256
slarm64-current-aarch64-xfce-pinebook-5.4.104-build-20210310.img.zst
slarm64-current-aarch64-xfce-pinebook-5.4.104-build-20210310.img.zst.sha265

I will eventually pull the other images off of this server, since these completely replace all of the others.

Thank you, keep rocking.

UPDATE: I will upload working images/kernels when I have the time and when they pass preliminary testing. Only older base images will be kept, making room for newer images, both base and xfce. The latest few working kernels will be available also, all in one convenient directory for easy access:

https://shelldweller.beauxbead.com/slack/pineslarm/

and the older domain still works for the time being, although it could go away at any point:

http://3space.xyz/pineslarm/

This way, I do not have to post each individual update. Interested users can just grab the latest copy from that directory going forward.

Thanks for all your help getting this up and running (again). Now that we are on a solid working LTS kernel, it feels more stable. I will test out next-kernels from time to time, with no expectations of results. If anything interesting happens upstream, I may post here again.

endless gratitude....

shelldweller · 03-17-2021, 10:03 PM

Just a few notes on the different kernels (again)...

I can get redshift (blue-light filter) to work on the 5.6.19 kernel, but NOT on the 5.4.105 kernel. That is an interesting difference to say the least. Something about the drm driver in the different kernels, I think (from what I have read on various fora).

On both kernels, to keep the console from going blank and getting stuck on blank, I need to add the following line to /etc/rc.d/rc.local:

Code:

setterm -blank 0 -powerdown 0

Similar, on both kernels, I need to add this line as a startup script in my X window manager in order to keep the screen from going blank and getting stuck on blank:

Code:

xset s off -dpms

The side effect is that the screen never goes blank fully. I do not recall this problem on the 5.5.y kernels, but it has been so long, I might be remembering incorrectly. I noticed this for the first time on the 5.6.y kernel. It is troublesome, because when the screen goes blank, you either have to access it over ssh, or else just hold the power button until it shuts off. I have not figured out a way to get the screen to come back on after it goes fully blank. However, the xlock "blank" option works, even if the screen does not power off all the way, at least I can switch to a black blank screen manually and switch back without getting stuck. It is just the automatic screen power-off feature that gets stuck, it seems.

In any case, these differences have inspired me to keep trying the next kernels. However, they have not been building fully. It keeps stopping here:

Code:

bob@builder:~$ tail -f /build/slarm64/images*/build/source/build.log 
  LD [M]  drivers/media/usb/gspca/gspca_t613.o
  LD [M]  drivers/media/usb/gspca/gspca_topro.o
  LD [M]  drivers/media/usb/gspca/gspca_touptek.o
  LD [M]  drivers/media/usb/gspca/gspca_tv8532.o
  LD [M]  drivers/media/usb/gspca/gspca_vc032x.o
  LD [M]  drivers/media/usb/gspca/gspca_vicam.o
  LD [M]  drivers/media/usb/gspca/gspca_xirlink_cit.o
  LD [M]  drivers/media/usb/gspca/gspca_zc3xx.o
  AR      drivers/media/built-in.a
make: *** [Makefile:1809: drivers] Error 2

I checked the log farther back than that, and no errors are listed, just a bunch of USB module files mostly.

Wireguard, or some other missing driver config perhaps? Just curious, thanks much...

sndwvs · 03-18-2021, 12:34 PM

if it is a 5.4.y kernel, I tried to build it 5.4.106, there were no problems.

sndwvs · 03-18-2021, 03:09 PM

shelldweller thanks,
yes, there was no patch for the wifi driver, there is also a patch for the Pinebook LCD.

shelldweller · 03-19-2021, 10:58 PM

Quote:

Originally Posted by sndwvs

shelldweller thanks,
yes, there was no patch for the wifi driver, there is also a patch for the Pinebook LCD.

Oh cool, that is good to hear, I hope it fixes some of the LCD issues. In the mean time, my local build is failing during sunxi-tools. I have not seen this error yet, but it happens right after the kernel is done compiling (either kernel) and right when sunxi-tools starts building, but before any actual packages are created

Code:

  HDRINST usr/include/asm/swab.h
  HDRINST usr/include/asm/termios.h
  HDRINST usr/include/asm/resource.h
  HDRINST usr/include/asm/ioctls.h
  INSTALL /build/slarm64/images_build_kit/build/pkg/kernel-headers/usr/include
|----------- delimiter ----------- "compiling" "sunxi-tools" -----------|
Setting version information: 6c02224

fit_image.c:19:10: fatal error: libfdt.h: No such file or directory
   19 | #include <libfdt.h>
      |          ^~~~~~~~~~
compilation terminated.
make: *** [Makefile:141: sunxi-fel] Error 1

Is this something to do with the sunxi-tools source code, or is it a missing header file on my build system? The reason that I ask is because I usually remove the kernel-source package, so if it is looking for something provided by the kernel-source package, then that could explain it. However, I have never seen this before on the same build system that has produced a few good images so far (Raspberry Pi 4 with a 5.11.0 kernel,has been serving me well for about a month now...) and kernel-source was never needed before, so I am guessing something happened upstream with sunxi-tools? I do have all the kernel-header packages installed, so I am not sure what this could be if not an upstream thing.

I have a few more things I can try, but so far this one has me stumped.

Thanks.

sndwvs · 03-20-2021, 04:04 AM

Thanks shelldweller,
a new addiction appeared, fixed

shelldweller · 03-21-2021, 12:46 PM

Ok, good news! The 5.10.25 kernel seems to work as well as any of the others, with full LCD functionality (using it as I write this in fact). I tested it under high I/O load, and it did not fully freeze up, similar to how the 5.4.y kernels perform (and unlike 5.6.19 which can lock up 100% if you push it too hard). Oh, and redshift works again like it did on 5.6.19, so this is the best of both worlds in that sense, very nice.

Two things I noticed:

1) The boot is slow on the next kernel. Can we set the performance governor in the config for next like we did for legacy?

2) I still have the problem where the screen will go blank and never come back on again if left alone for 15 minutes, both on the console and while running X. The two settings mentioned in a previous post solve the issue at the expense of the screen ever fully shutting off. (although, the blank xlock mode works fine, thankfully). I will search around for similar reports, so far I have not even looked.

I am uploading the new images and kernels now.

Thanks for the fixes, as always!

sndwvs · 03-21-2021, 01:02 PM

Good news, I turned on CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y by default.

shelldweller · 03-21-2021, 03:05 PM

Quote:

Originally Posted by sndwvs

Good news, I turned on CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y by default.

Thanks for this! Rebuilding now...

Side note: After further testing, the 5.10.25 kernel does not handle heavy I/O load nearly as well as the 5.4.y series does, from my analysis. While neither locks up fully like 5.6.19 did, on 5.10.25 the X session does lock up and has to be restarted once things get bogged down. This is not the case with 5.4.y (now using 5.4.106, thanks again for that too).

My testing goes something like this: start a torrent with a large number of seeders, start building something from SlackBuilds.org in the background (my latest discovery is calcurse, very cool...), start transferring something over FTP, and maybe start moving something over the LAN with scp, all at the same time. 5.4.106 is handling this with grace, but 5.10.25 slowed down until X stopped responding, however I could just kill X from another terminal and things would be okay again, no reboot necessary.

So, 5.10.25 is a huge improvement in terms of the LCD panel (yay!), but is less stable under heavy I/O load than the legacy series. This kinda makes sense to me, it almost is what the split between legacy and next is all about: stability vs. features, in this case that would be i/o performance vs. redshift. Overall, I would say that 5.4.y is still the winner in terms of daily usage. I like redshift, but even when I get it working on the pinebook, it flickers and is not totally solid; so not perfect anyway, not yet at least.

I will continue to test and research as spare time allows. Thanks again.

sndwvs · 03-22-2021, 12:01 PM

slarm64-current-aarch64-base-pinebook-5.10.25-build-20210322.img.zst
slarm64-current-aarch64-base-pinebook-5.10.25-build-20210322.img.zst.sha256
slarm64-current-aarch64-xfce-pinebook-5.10.25-build-20210322.img.zst
slarm64-current-aarch64-xfce-pinebook-5.10.25-build-20210322.img.zst.sha256

shelldweller · 03-23-2021, 02:00 PM

Thanks! These seem to work fine.... boots quickly, and the only noticeable issues are present on all other tested kernels in one form or another (more on those later if I can find some supporting evidence, still gathering info...). Awesome!

sndwvs · 03-29-2021, 12:28 AM

kernel 5.11.10
slarm64-current-aarch64-base-pinebook-5.11.10-build-20210328.img.zst
slarm64-current-aarch64-base-pinebook-5.11.10-build-20210328.img.zst.sha256
slarm64-current-aarch64-xfce-pinebook-5.11.10-build-20210328.img.zst
slarm64-current-aarch64-xfce-pinebook-5.11.10-build-20210328.img.zst.sha256