Kernel woes - SOLVED (mostly)

[ozsouth]

03Feb25 UPDATE:

1. Bad commits in 6.6.72 fixed in next kernel, although .73 & .74 seem to have other issues.
No, my debian configs at fault, so changed.

2. Issue with Debian config 6.6.72+ - drive names seem to vary on boot (emmc drive).
No, my debian configs at fault, so changed.

3. 6.11+ doesn't allow some firmware to fall back to earlier versions, requiring the latest.
- iwlwifi seems most affected.

4. wl driver source needs a hack to compile in 6.12 . 6.13 needs an extra (dubious) hack.
- I guess if a pc is old enough to have a broadcom wl chip, probably too old for 6.13+.
Solution from BarryK - fixed.

26 Feb 2025 - 3 solved (2 by using modified x-series = m-series kernels) - 1 we have to live with.

[Marv]

Was 6.6.59 during that spell? I run that in my fossapup64-small install with zero issues but both in that install and in my savefile driven LxPupSc64 install I run AUFS. My Noblepup64 and VoidPup64 installs run overlayfs but they both are and have been for a while in the 6.12.x kernel series.

[ozsouth]

@Marv - from what I can see, it appears that 6.6.63, which had aufs issues too, was the start of this issue.
The lead dev GKH congratulated other devs on 6-Dec-24 for finding one that only affected overlayfs with files over 2Gb, but later discoveries (6.6.64 had many changes) required more fixes. Hopefully they've nailed it now. I've been using 6.6.67 for weeks & haven't had problems (that I noticed). As 6.12 doesn't have these problems, I've made a 6.6.73 kernel.

[ozsouth]

Now seems these bad commits only affected 6.6.72, so 6.6.71 & earlier seem ok.
I have found more issues with 6.6.73 & 6.6.74 - drive names seem to vary on boot (emmc drive) - is fine with 6.6.71 & earlier, so I have reinstated 6.6.71.

[Marv]

Thanks for following this fast moving train. I had no issues with 6.6.73 in a day or so but I run mostly sdax installs.

I have done some fancy gandy-dancing to keep my custom adrives and ydrives universal ( within a pup flavor) now that I have 4 different touchpads (including a really stinky Lenovo X1 carbon clickpad), 2 display resolutions & dpi, and both sdx and nvme SSDs on board. Finally got it boiled down to a couple of lines in rc.local and a script in /root/startup I call 00-model customization. That'n runs early enough in the startup sequence so the changes are respected. Model guidance is all there in .PUPSTATE and dmidecode so it wasn't bad though it took several iterations to boil it down to those two files. Makes my maintenance much simpler once done.

I did notice the size increase in the kernel modules SFS between say, 6.6.59 and 6.6.71. Seems to be mostly a lot more drivers, the penalty for modernity

Cheers,

[ozsouth]

I really getting frustrated over newer kernels.
My attempt to use a modified debian config is less successful than I had hoped.
Mostly small stuff, but is unpredictable, so I'm abandoning that idea.
I've had more complaints in the last 2 months than in previous years.
I'm going to retreat to my x-series kernels (2018 config with some updates &
some newer drivers), that I was making around October-November 2024.
6.6.69 aufs/overlay & 6.12.11 usrmerge/overlay x-series coming soon.
Hence if your pc was made after 2022, you may find some hardware doesn't work.

Having looked at the github kernel-kit outputs for 6.6.77 & 6.12.13 usrmerge kernels,
some hardware support is missing there too - i.e. ASUS_NB_WMI (used by TerryH) &
PINCTRL_JASPERLAKE (I use it). The latter is in my x-series. I can't get the former
to compile. It did in my debian config kernels, but there were other problems.

[rockedge]

After assembling a Void Linux kernel 6.13.2_1 for KLV and that most likely will work on any usrmerge Puppy Linux using overlay, I put together a firmware SFS that is around 370 M in size and has a broad range of firmware including some for the newest hardware.

@ozsouth I am hoping for a few testers of this firmware SFS. For use in a Puppy Linux rename the SFS to match the proper naming convention for that particular Puppy Linux variant.

The previous attempt of building such a firmware SFS version had some problem loading correctly and was abandoned. This one seems to work so far for me. I am using it on a KLV-Airedale-sr16 with success.

Here is the download link -> 01firmware-6.13.2_1.sfs

I also am having troubles successfully compiling RT kernels using the kernel-kit since kernel version 6.7 and higher.

[nocsak]

Hi all!

I have some kernel, fdrv and ucode variants on my SF repsoitory created last year. I'm not sure it is good but for our Hungarian pups they are working well. Maybe worth a test.
We have sound under wine with them, and dmesg not show any errors related to misconfiguration. If you need some extra info about them, ask and I try to answer. Or at least those kernels' DOTconfigs may help to you. Take into consideration which fdrvs need to be usrmerged and which ones for classic puppies! And if necessary, convert them as needed. Of course I am open to any suggestions.

Regards,
nocsak

[ozsouth]

@rockedge - used your firmware sfs with noblepup & bookwormpup - works well.

[greengeek]

After assembling a Void Linux kernel 6.13.2_1 for KLV and that most likely will work on any usrmerge Puppy Linux using overlay, I put together a firmware SFS that is around 370 M in size and has a broad range of firmware including some for the newest hardware.

@ozsouth I am hoping for a few testers of this firmware SFS. For use in a Puppy Linux rename the SFS to match the proper naming convention for that particular Puppy Linux variant.

I am probably not the target market for this sfs as I am using AUFS on Fossa Small - but i did find that my iwlwifi went missing.
(Would there be any value in me re-testing in overlay mode - or do I have the wrong sort of Pup?)

Here is the comparison between the good and bad detection:

GoodWifi.jpg (42.92 KiB) Viewed 1155 times

LostWifi.jpg (37.58 KiB) Viewed 1155 times

Hardware is Toshiba Satellite Pro S500

[ozsouth]

@greengeek - rockedge's new fdrv is set for usrmerge puppies only - firmware is in /usr/lib (not /lib , where fossa-small is looking). Need Jammypup, Bookwormpup, Noblepup type puppies. Your iwlwifi disappeared as you were running without accessible firmware.

[greengeek]

rockedge's new fdrv is set for usrmerge puppies only - firmware is in /usr/lib (not /lib , where fossa-small is looking). Need Jammypup, Bookwormpup, Noblepup type puppies. Your iwlwifi disappeared as you were running without accessible firmware.

Thanks for the explanation. Just retested on the same Toshiba machine but using Bkworm64 10.0.9nkb and now the huge fdrv works fine.

[dimkr]

I really getting frustrated over newer kernels.
My attempt to use a modified debian config is less successful than I had hoped.

If you're not building on Debian, this is probably why you're having problems. My automated kernel building pipeline builds the Debian 12 kernel with slight modifications inside a Debian 12 chroot (same technique with Debian 11 and Debian testing) and this has worked really well. These kernels are super close to Debian (/proc/config shows exactly the expected delta compared to Debian) and they work in a Puppy built from the same Debian version.

The kernel build process is sensitive to installed dependencies (some kernel features need extra dependenies installed on the machine where you're building it) but the real problem is dependency versions (especially GCC and easy to miss things like pahole). It's super hard to take the configuration from one distro and prepare a matching (same or close enough versions of everything) build environment in another.

[bigpup]

Hence if your pc was made after 2022, you may find some hardware doesn't work.

Well, support for newer or newest hardware, is the biggest reason to use, a newer kernel.

I have a very new laptop, with very new everything for hardware.

The only kernel that supports the hardware, is one of your newest builds.

I think I am correct in saying.

Configuring the kernel, is the black art, of compiling a kernel.

Remember in the past, when you compiled and configured a specific kernel, that provided good support, for sound hardware in ChromeBooks!

[rockedge]

@bigpup you have inspired me to create a non-usrmerge version of this firmware package!

This has the very latest firmware and still provides older and some legacy firmware. Remember to rename it to match the firmware SFS you are replacing.

firmware-17feb25_non-usrmerge.sfs 374 M

You will be the first tester on really new hardware and on non-usrmerge Puppy Linux

[bigpup]

@rockedge

Have not tried your firmware SFS yet.

Took a look at what is inside it.

The main issue I had, was not having the firmware for the very new computer, WIFI hardware.

The firmware needed is in your firmware SFS.

So, it should provide what I needed.

Now I will need to figure out what non-usermerge Puppy will boot and run it.
but it will still need to change it, to using a newer kernel, having the driver in it.

[BarryK]

4. wl driver source needs a hack to compile in 6.12 . 6.13 needs an extra (dubious) hack.
- I guess if a pc is old enough to have a broadcom wl chip, probably too old for 6.13+.

I used the official broadcom wl driver source, which compiles in 6.12.11 and 6.12.12 without needing any hack.

I don't recall the URL where I got it from, but it is inside this tarball:

https://distro.ibiblio.org/easyos/sourc ... nel.tar.gz

[ozsouth]

@bigpup - after much research, I'm currently trialling another DOTconfig - I started with x-series base & have added some useful options. If it works, that 2022 limit won't generally apply, but there will always be some new stuff I miss. I'm hoping to cover @TerryH 's asus settings (& a few others) at least.

[ozsouth]

@BarryK - thankyou - works with minor warnings, but no errors or hacks needed. I made a .zip of the wl source (5.5mb) & posted a link in forum Drivers (Broadcom) section.