Puppy Linux Discussion Forum

Superseded.

@ozsouth

Thanks for this

Switched the default kernel of VoidPup64 to this one, works well and no issues so far

ozsouth wrote: ↑Fri Jul 26, 2024 5:51 am

I made a 64bit 6.10.1 2018 KIT High-Frequency NON-USRMERGE kernel. Has Overlayfs and Aufs builtin.
Has Voluntary Preemption & Frequency at 1000Hz.

Is this an RT kernel that may be suitable to experiment with Puppy Versions of LinuxCNC and perhaps other dedicated older pre-FossaPup Puppy Linux systems that require a real time kernel?

@dogcat - not realtime - high frequency means fairly low-latency though, so faster response for users. Complete low-latency would have full preemption set too, but I think voluntary preemption is better all round for average user. If you have a non-destructive non-mission-critical test application, you could see how it goes (at own risk, of course). I'd be interested to know.

@ozsouth :-

Dave, would this work with the original Fossapup64's fdrv? I say this because that fdrv does everything I want it to.......and from what I've always understood, fdrvs are kernel-agnostic?

Mainly I'm thinking of that "awkward" wireless/Bluetooth 'combo' chip in this HP desktop. That's the one you compiled me a driver for because I just could NOT get Ethernet to behave itself in Bionicpup64....remember?

This is the RTL8822BE, for reference.

TIA.

Mike.

@mikewalsh - should do. Kernel has rtw88_8822be driver & fossapup64-9.5's fdrv has rtw8822b_fw.bin.

@ozsouth :-

Cheers, Oz; appreciate the reply. I'll give this a try over the next couple of days, and let you know how I get on.

I'm curious to see if this one will recover from overnight suspend. I do this a lot; I tried Erik's k6.9.1 - which worked very well (even in Tahrpup64!).....but attempting to restart after suspending, all I got was a blank screen. Let's see if this one behaves itself; if not, then perhaps this is endemic to all 6-series kernels for this five-year old HP desktop....

I have 2 Pups I can try these on; Quirky64 'April' lite - from jrb - and a re-built, heavily-modded/customized Xenialpup64 (my current 'daily driver'). These run 'nouveau'; all my others have the Nvidia driver installed via shinobar's GetNvidia - from the 'run file - and the drivers for MY GPU won't compile under 6-series kernels. Anyway...

.....will report back.

Mike.

@ozsouth :-

Nah; it's just the same. Try to "wake up" from suspend, and all I get is a blank screen. Drat!

See, if I was like most folks - shut-down every night, power-on again the next morning - I'd never notice it. In that respect, it's fine.....and in operation, it runs A-OK. Hmm....I'm now wondering if the kernel team have made any changes to the ACPI stuff that might explain this odd behaviour?

So; either I quit suspending overnight, or I stick with 5-series kernels. What to do, what to do....? I think a bit of research is called-for.....

Watch this space.

Mike.

@mikewalsh - maybe an adjustment to suspend.sh will help. Try adding restartwm to the end of /etc/acpi/actions/suspend.sh

@ozsouth :-

Hmm. Well, it's there.....but currently commented-out. The relevant section looks like this (this is in Xenialpup64, but I'm guessing this same file is pretty much standard across most Puppies).

These are the last dozen or so lines of /etc/acpi/actions/suspend.sh:-

# process before suspend
# sync for non-usb drives
sync
rmmod ehci_hcd

#suspend
echo -n mem > /sys/power/state

# process at recovery from suspend
#restartwm
modprobe ehci_hcd
#/etc/rc.d/rc.network restart

rm -f "$LOCKFILE

But why should it need uncommenting for the 6-series when it clearly works fine, as-is, for the 5-series? That's the only bit I can't figure out. Still, it's worth a try, I guess..!

Mike.

@ozsouth :-

No dice. Previously, it was leaving a single, orphaned inode.......with that modification, it's creating more than 30.

I'll stick with k5.4.53. The original Fossa's kernel and fdrv seem to be a perfect match for this hardware!

Mike.

@mikewalsh - I guess security is one reason for updating kernels. Have seen some machines that don't like 6.x though. Trouble with aufs is that 5.x kernels are now unsupported. Maybe try a more recent one though? My small fossa-based pups use my 5.10.208 (Jan 2024) kernel without complaints. I can't successfully compile a later 5.10.x than that.

@ozsouth :-

Well, I'll go with your k5.19.11 kernel, Dave. That'll do me; it's somewhat newer than Fossa's original.

I know it's been "superseded" according to your thread, but I snagged this one a while back & only ever tried it in jrb's Quirky64 'April'-lite. That WAS before I started generally upgrading kernels/glibc's throughout the kennels, along with a few other bits'n'bobs.

Like so:-

(A wee utility script I knocked together for myself the other night. Starting to play around with 'sed' and 'cut', and I wanted to 'smarten-up' my personal gxmessage boxes.....so this brings up the 'PRETTY_NAME' from etc/os-release and writes it to a file in /tmp, appends the output of uname -a and ldd --version to the same file, adds the time of the query, then reads the file with gxmessage. Quite neat, if I do say so myself.....especially for summat knocked-up over the course of about 3 hours , given that I knew nowt about 'sed' OR 'cut' until after I came up with the idea!)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The important thing, though..? It recovers sweetly from suspend.....which confirms what I've been saying about the 6-series kernels, AND tells me that an 8-yr old 'modified' Puppy running on 5-yr old hardware IS perhaps getting a bit behind the times now.

Couldn't care less, me. This combo does absolutely everything I could want it to do, so I'm as happy with it as a pig in shit. Hell, even Racy's k3.0.66 still does everything I need.....including the Logitech c920 HD 'Pro' webcam. (Which goes to show just how many years that thing's been on the market, yet believe it or not it is STILL the most popular, best-selling 'cam in the world. And even supported by a 10/11-yr old kernel. Logitech must have got summat right when they threw it together!)

Cheers for this one, Dave!

@mikewalsh - Glad that works. Would you mind running the following terminal command (to see what your wakeup options are): cat /proc/acpi/wakeup
I had laptops that wouldn't wake on lid lift & willams2 pointed out a tweakable fix.

@ozsouth :-

Here you go, mate:-

root# cat /proc/acpi/wakeup
Device	S-state	  Status   Sysfs node
PEG0	  S4	*enabled   pci:0000:00:01.0
PEGP	  S4	*disabled  pci:0000:01:00.0
PEG1	  S4	*disabled
PEGP	  S4	*disabled
PEG2	  S4	*disabled
PEGP	  S4	*disabled
SIO1	  S3	*disabled
RP01	  S4	*disabled
PXSX	  S4	*disabled
RP02	  S4	*disabled
PXSX	  S4	*disabled
RP03	  S4	*disabled
PXSX	  S4	*disabled
RP04	  S4	*disabled
PXSX	  S4	*disabled
RP05	  S4	*enabled   pci:0000:00:1c.0
PXSX	  S4	*disabled  pci:0000:03:00.0
RP06	  S4	*disabled
PXSX	  S4	*disabled
RP07	  S4	*enabled   pci:0000:00:1c.6
PXSX	  S4	*disabled  pci:0000:04:00.0
RP08	  S4	*disabled
PXSX	  S4	*disabled
RP09	  S4	*disabled
PXSX	  S4	*disabled
RP10	  S4	*disabled
PXSX	  S4	*disabled
RP11	  S4	*disabled
PXSX	  S4	*disabled
RP12	  S4	*disabled
PXSX	  S4	*disabled
RP13	  S4	*disabled
PXSX	  S4	*disabled
RP14	  S4	*disabled
PXSX	  S4	*disabled
RP15	  S4	*disabled
PXSX	  S4	*disabled
RP16	  S4	*disabled
PXSX	  S4	*disabled
RP17	  S4	*disabled
PXSX	  S4	*disabled
RP18	  S4	*disabled
PXSX	  S4	*disabled
RP19	  S4	*disabled
PXSX	  S4	*disabled
RP20	  S4	*disabled
PXSX	  S4	*disabled
RP21	  S4	*disabled
PXSX	  S4	*disabled
RP22	  S4	*disabled
PXSX	  S4	*disabled
RP23	  S4	*disabled
PXSX	  S4	*disabled
RP24	  S4	*enabled   pci:0000:00:1b.0
PXSX	  S4	*disabled  pci:0000:02:00.0
XHC	  S3	*enabled   pci:0000:00:14.0
XDCI	  S3	*disabled
HDAS	  S4	*disabled  pci:0000:00:1f.3
CNVW	  S4	*disabled
AWAC	  S4	*enabled   platform:ACPI000E:00
root#

Does that tell you anything? I hope it does, 'cos it just looks like so much "Greek" to me.....

Mike.

@mikewalsh - you have a number of wakeup devices. Here is an 'I've got plenty of time to fiddle & it may not work' option.

Based on williams2's script, I made a script that disables all wakeup devices, then enables only what you want. I think XHC is all you want - usb, so moving a mouse should wakeup your desktop system (for laptops, I use LID).
This would only be useful for testing non-wakeup scenarios, i.e. 6.x kernel. However, I've attached .pet at bottom. Need to restart X after install.

@ozsouth :-

Okay. I'll have a try with this.....see what happens, like.

Does that k6.1.92 need an fdrv?

Mike.

@ozsouth :-

We're getting there, Dave. Little by little, we're advancing.....albeit "crab-wise" (by circuitous, roundabout routes), as opposed to a direct, full-frontal assault!

Your k6.1.92 runs sweetly, AND using the 'makesuspxhc' in /root/Startup, it recovers just fine from suspend, too...

This is still using the original Fossapup64 fdrv, as I have been doing all the way through.

I thought I'd give things a try - using the new script - with the subject of this thread again, k6.10.1. It runs absolutely fine - as it did when I first tried it, a couple of days ago - BUT: it still results in a black screen when trying to resume from suspend-to-RAM. Even with the XHC script.

So, like I said; we're getting there.......slowly, steadily, bit by bit. I'm not complaining; with k6.1.92, I already have a MUCH newer kernel than I did.....and it's now doing everything I want it to. Can't be bad..!

Mike.

@mikewalsh - excellent! That 25may2024 kernel is pretty recent. I posted sources & headers with kernel 3 posts up. Kernel 6.1 aufs is unsupported now, so later than about 6.1.99 may fail.

@ozsouth :-

Thanks for the sources, Oz. It's appreciated, even though I may rarely - if ever - actually use it. One question, if I may? Why do you always produce 'headers' in addition to the sources? Does any compiling particularly request them?

The way you did that wee XHC script is fine. USB is all I need for 'waking' the old girl up, 'cos I always do so with a tap on the wireless "mini-keyboard"s space bar. Trying to wake with the mouse has never worked here, but I'd rather hit a key to wake 'er up, and THEN turn the mouse on in ANY case.

Onwards & upwards....!!

Mike.

@mikewalsh - when compiling drivers, I need devx & sources. When compiling kernels, I need devx & headers - occasionally for c compiling too. Note, my 6.1.96 kernel may also work for you (has i2c_hid_acpi set - so laptop touchpads should work, but could cause other issues on some systems) - I mention that as an aside, as no reason for you to change now.

@ozsouth :-

Fair enough. Just curious, really.

I see k6.1.92 is an LTS release; projected EOL - December 2026.......and chosen by the C.I.P as their current newest "Super Long Term Support" release, with a projected EOL of August 2033.

Looks like this one will be a 'keeper'. Thanks a lot for your help with this, Dave (especially with the XCH script); much appreciated!

Cheers.

Mike.

Does this kernel work with BookwormPup?

@mikolaj_q - this 6.10.1 kernel needs conversion to work with Bookworm64. However the recent 6.9.9 kernel is immediately usable with Bookworm64.
See: viewtopic.php?p=126099#p126099

OK, thnks