The Latest Kernel Release.

marav · 11-28-2022, 03:09 PM

Quote:

Originally Posted by cwizardone

FWIW: The first attempt to build the 6.1-rc7 kernel failed with an error message about the option for _x86_AMD_P_STATE being wrong. That is not the exact message, but close.
So, I edited the .config file and changed the "=m" to "=y" and the next attempt was successful.
Running for about two hours now and so far, so good.

Weird
Nothing like that here
And amd-pstate-ut added in the initrd works fine

Code:

blackstar :: ~ » lsmod | grep pstate
amd_pstate_ut          20480  0

cwizardone · 11-28-2022, 03:34 PM

Line #637 is the line that had to be changed from, CONFIG_X86_AMD_PSTATE=m
to
CONFIG_X86_AMD_PSTATE=y

Quote:

# CPU frequency scaling drivers
#
CONFIG_X86_INTEL_PSTATE=y
CONFIG_X86_PCC_CPUFREQ=m
CONFIG_X86_AMD_PSTATE=y
# CONFIG_X86_AMD_PSTATE_UT is not set
CONFIG_X86_ACPI_CPUFREQ=m
CONFIG_X86_ACPI_CPUFREQ_CPB=y
CONFIG_X86_POWERNOW_K8=m
CONFIG_X86_AMD_FREQ_SENSITIVITY=m
CONFIG_X86_SPEEDSTEP_CENTRINO=m
CONFIG_X86_P4_CLOCKMOD=m

enorbet · 11-28-2022, 04:08 PM

Quote:

Originally Posted by Didier Spaier

I do not understand your question. Could you please elaborate what you mean?

That's probably because I don't yet understand it well. I tried building 6.0.9 on a test system and when I ran "make oldconfig" (I've not always been successful with "make olddefconfig") I reviewed most changes and one mentioned "default init path" and it failed to boot, not finding init. I should mention that I usually on relatively new systems use the Generic config and hardwire the few I need to avoid any initrd, like ext4, etc. The test system was a dead stock v15.0 install excepting only the custom built 5.4.164 kernel whose config I used as a template.

I'm going to try again tonight, so maybe I simply missed something and just happened to focus on seeing the option for "Default init Path" popup as a change that I had never bothered with before. I was a bit sensitive about starting from a 5x config for a 6x build, so maybe I'll discover what I did wrong tonight.

LuckyCyborg · 11-28-2022, 04:30 PM

Quote:

Originally Posted by enorbet

That's probably because I don't yet understand it well. I tried building 6.0.9 on a test system and when I ran "make oldconfig" (I've not always been successful with "make olddefconfig") I reviewed most changes and one mentioned "default init path" and it failed to boot, not finding init. I should mention that I usually on relatively new systems use the Generic config and hardwire the few I need to avoid any initrd, like ext4, etc. The test system was a dead stock v15.0 install excepting only the custom built 5.4.164 kernel whose config I used as a template.

I'm going to try again tonight, so maybe I simply missed something and just happened to focus on seeing the option for "Default init Path" popup as a change that I had never bothered with before. I was a bit sensitive about starting from a 5x config for a 6x build, so maybe I'll discover what I did wrong tonight.

Well, I for one, I do not try ever to avoid an initrd. On contrary, I use the generic config as template and use the self-built kernel with an initrd. Today I use a "generic" 6.0.10 with a proper initrd with no issues on Slackware 15.0 and -current.

I confess, coming from an Ubuntu background, I consider absolutely normal to use an initrd. And UUIDs. Strange is for me to complicate the one life to "avoid" an initrd. Too much work and too much "potential risks" for so less gain.

BTW, hard-coding the kernel to "/sbin/init" will make it incompatible with the stock Slackware initrd system, where we have "/init" . I for one, I will never do this.

Didier Spaier · 11-28-2022, 05:03 PM

Quote:

Originally Posted by enorbet

That's probably because I don't yet understand it well. I tried building 6.0.9 on a test system and when I ran "make oldconfig" (I've not always been successful with "make olddefconfig") I reviewed most changes and one mentioned "default init path" and it failed to boot, not finding init. I should mention that I usually on relatively new systems use the Generic config and hardwire the few I need to avoid any initrd, like ext4, etc. The test system was a dead stock v15.0 install excepting only the custom built 5.4.164 kernel whose config I used as a template.

I'm going to try again tonight, so maybe I simply missed something and just happened to focus on seeing the option for "Default init Path" popup as a change that I had never bothered with before. I was a bit sensitive about starting from a 5x config for a 6x build, so maybe I'll discover what I did wrong tonight.

Here (Slint 15.0 based on Slackware 15.0) I run a 6.0.8 kernel and:

Code:

didier[~]$ zgrep DEFAULT_INIT /proc/config.gz 
 CONFIG_DEFAULT_INIT="

The machine boots as expected. Let's quote https://github.com/torvalds/linux/bl.../init/Kconfig:

Code:

config DEFAULT_INIT
     string "Default init path"
    default ""
    help
      This option determines the default init for the system if no init=
      option is passed on the kernel command line. If the requested path is
      not present, we will still then move on to attempting further
      locations (e.g. /sbin/init, etc). If this is empty, we will just use
       the fallback list when init= is not passed.

For your information, I build the kernel packages for Slint 15.0 from a local instance of this directory: https://slackware.uk/slint/x86_64/sl...source/kernel/ initially based on http://ftp.slackware.com/pub/slackwa...rce/installer/ running as root the script build.sh but, I do not build huge kernels.

PS To upgrade I do this:

Download a compressed archive of new kernel and decompress it.
Copy the config file in https://slackware.uk/slint/x86_64/sl...ernel-configs/ as .config at the root of the new kernel's tree.
Run "make oldconfig" from the root of the new kernel's tree.
Copy the .config in it in https://slackware.uk/slint/x86_64/sl...ernel-configs/ as config-generic-<new version>.x64 and remove the previous config file from this directory.
Edit the file https://slackware.uk/slint/x86_64/sl...ernel/build.sh to change the version.
As root type: sh build.sh.

No booting issue so far, either found by me or reported by a user.

marav · 11-28-2022, 05:07 PM

Quote:

Originally Posted by cwizardone

Line #637 is the line that had to be changed from, CONFIG_X86_AMD_PSTATE=m
to
CONFIG_X86_AMD_PSTATE=y

Did you edit the .config file manually ?
Because CONFIG_X86_AMD_PSTATE=m is not something available
This probably caused the error message you got

Aeterna · 11-28-2022, 06:31 PM

Quote:

Originally Posted by enorbet

That's probably because I don't yet understand it well. I tried building 6.0.9 on a test system and when I ran "make oldconfig" (I've not always been successful with "make olddefconfig") I reviewed most changes and one mentioned "default init path" and it failed to boot, not finding init. I should mention that I usually on relatively new systems use the Generic config and hardwire the few I need to avoid any initrd, like ext4, etc. The test system was a dead stock v15.0 install excepting only the custom built 5.4.164 kernel whose config I used as a template.

I'm going to try again tonight, so maybe I simply missed something and just happened to focus on seeing the option for "Default init Path" popup as a change that I had never bothered with before. I was a bit sensitive about starting from a 5x config for a 6x build, so maybe I'll discover what I did wrong tonight.

no need to specify

Quote:

CONFIG_DEFAULT_INIT

if left empty, it defaults to standard path.
First run diff to see differences between old (working) and new config. This may help to solve your problem. I don't use initrd and all works. I think that this is just minor problem that you will easily fix (I hope).

Aeterna · 11-28-2022, 06:37 PM

Quote:

Originally Posted by cwizardone

Line #637 is the line that had to be changed from, CONFIG_X86_AMD_PSTATE=m
to
CONFIG_X86_AMD_PSTATE=y

if you don't have AMD get rid of it, if you don't have INTEL, get rid of it.

enorbet · 11-28-2022, 07:43 PM

Quote:

Originally Posted by LuckyCyborg

Well, I for one, I do not try ever to avoid an initrd. On contrary, I use the generic config as template and use the self-built kernel with an initrd. Today I use a "generic" 6.0.10 with a proper initrd with no issues on Slackware 15.0 and -current.

I confess, coming from an Ubuntu background, I consider absolutely normal to use an initrd. And UUIDs. Strange is for me to complicate the one life to "avoid" an initrd. Too much work and too much "potential risks" for so less gain.

Not that such choices are a popularity contest, but I very much dislike initrd and not having to bother with one suits my workflow. I also dislike Grub2 and really dislike UUIDs. UUIDs are only meaningful to the machine. Since I'm human I prefer labels.

enorbet · 11-28-2022, 07:48 PM

Quote:

Originally Posted by Aeterna

no need to specify

if left empty, it defaults to standard path.
First run diff to see differences between old (working) and new config. This may help to solve your problem. I don't use initrd and all works. I think that this is just minor problem that you will easily fix (I hope).

Thanks and you were right. Tonight I started fresh, left it empty, and it booted just fine. I suppose I was previously overtired and simply made a mistake as well as overreacted to noticing "default init path". I still have some minor difficulty with an older nvidia card using the .run installer with the 6.0.9 kernel but I will either figure it out or just revert to nouveau on that old box or the older kernel. It served it's purpose as a test platform keeping my Main clean while I played around on a far less important PC.

cwizardone · 11-28-2022, 08:19 PM

Quote:

Originally Posted by marav

Did you edit the .config file manually ?
Because CONFIG_X86_AMD_PSTATE=m is not something available
This probably caused the error message you got

The error was that, "m" was not the correct option.
If you look in .config.old. you'll find, CONFIG_X86_AMD_PSTATE=y
I simply copied and pasted it into the right spot in .config.
The 6.1-rc7 kernel has been up and running now for a little over 9 hours without a problem,
in -current, of course, with the Nvidia-470.161.03.run driver.

marav · 11-29-2022, 05:24 AM

Quote:

Originally Posted by cwizardone

The error was that, "m" was not the correct option.
If you look in .config.old. you'll find, CONFIG_X86_AMD_PSTATE=y
I simply copied and pasted it into the right spot in .config.
The 6.1-rc7 kernel has been up and running now for a little over 9 hours without a problem,
in -current, of course, with the Nvidia-470.161.03.run driver.

After the copy, you must run "make oldconfig" and answer "y"

Code:

AMD Processor P-State driver (X86_AMD_PSTATE) [N/y/?] (NEW)

Aeterna · 11-29-2022, 09:16 AM

Quote:

CONFIG_X86_AMD_PSTATE

It is impossible to set the above as module unless someone is messing with kernel config manually. Perfect way to screw many things up

Living dangerously I guess..

marav · 11-29-2022, 03:42 PM

Slackware 15.0 (x86_64)

Code:

Tue Nov 29 20:56:03 UTC 2022
patches/packages/linux-5.15.80/*:  Upgraded.
  These updates fix various bugs and security issues.
  Be sure to upgrade your initrd after upgrading the kernel packages.
  If you use lilo to boot your machine, be sure lilo.conf points to the correct
  kernel and initrd and run lilo as root to update the bootloader.
  If you use elilo to boot your machine, you should run eliloconfig to copy the
  kernel and initrd to the EFI System Partition.
  For more information, see:
    Fixed in 5.15.63:
    https://www.cve.org/CVERecord?id=CVE-2022-3629
    https://www.cve.org/CVERecord?id=CVE-2022-3635
    https://www.cve.org/CVERecord?id=CVE-2022-3633
    https://www.cve.org/CVERecord?id=CVE-2022-3625
    Fixed in 5.15.64:
    https://www.cve.org/CVERecord?id=CVE-2022-39190
    https://www.cve.org/CVERecord?id=CVE-2022-3028
    https://www.cve.org/CVERecord?id=CVE-2022-2905
    Fixed in 5.15.65:
    https://www.cve.org/CVERecord?id=CVE-2022-42703
    https://www.cve.org/CVERecord?id=CVE-2022-3176
    Fixed in 5.15.66:
    https://www.cve.org/CVERecord?id=CVE-2022-4095
    https://www.cve.org/CVERecord?id=CVE-2022-20421
    Fixed in 5.15.68:
    https://www.cve.org/CVERecord?id=CVE-2022-3303
    https://www.cve.org/CVERecord?id=CVE-2022-2663
    https://www.cve.org/CVERecord?id=CVE-2022-40307
    https://www.cve.org/CVERecord?id=CVE-2022-3586
    Fixed in 5.15.70:
    https://www.cve.org/CVERecord?id=CVE-2022-0171
    https://www.cve.org/CVERecord?id=CVE-2022-39842
    https://www.cve.org/CVERecord?id=CVE-2022-3061
    Fixed in 5.15.72:
    https://www.cve.org/CVERecord?id=CVE-2022-2308
    Fixed in 5.15.73:
    https://www.cve.org/CVERecord?id=CVE-2022-2978
    https://www.cve.org/CVERecord?id=CVE-2022-43750
    Fixed in 5.15.74:
    https://www.cve.org/CVERecord?id=CVE-2022-40768
    https://www.cve.org/CVERecord?id=CVE-2022-42721
    https://www.cve.org/CVERecord?id=CVE-2022-3621
    https://www.cve.org/CVERecord?id=CVE-2022-42722
    https://www.cve.org/CVERecord?id=CVE-2022-42719
    https://www.cve.org/CVERecord?id=CVE-2022-41674
    https://www.cve.org/CVERecord?id=CVE-2022-3649
    https://www.cve.org/CVERecord?id=CVE-2022-3646
    https://www.cve.org/CVERecord?id=CVE-2022-42720
    Fixed in 5.15.75:
    https://www.cve.org/CVERecord?id=CVE-2022-43945
    https://www.cve.org/CVERecord?id=CVE-2022-41849
    https://www.cve.org/CVERecord?id=CVE-2022-3535
    https://www.cve.org/CVERecord?id=CVE-2022-3594
    https://www.cve.org/CVERecord?id=CVE-2022-2602
    https://www.cve.org/CVERecord?id=CVE-2022-41850
    https://www.cve.org/CVERecord?id=CVE-2022-3565
    https://www.cve.org/CVERecord?id=CVE-2022-3542
    Fixed in 5.15.77:
    https://www.cve.org/CVERecord?id=CVE-2022-3524
    Fixed in 5.15.78:
    https://www.cve.org/CVERecord?id=CVE-2022-3628
    https://www.cve.org/CVERecord?id=CVE-2022-3623
    https://www.cve.org/CVERecord?id=CVE-2022-42896
    https://www.cve.org/CVERecord?id=CVE-2022-42895
    https://www.cve.org/CVERecord?id=CVE-2022-3543
    https://www.cve.org/CVERecord?id=CVE-2022-3564
    https://www.cve.org/CVERecord?id=CVE-2022-3619
    Fixed in 5.15.80:
    https://www.cve.org/CVERecord?id=CVE-2022-3521
    https://www.cve.org/CVERecord?id=CVE-2022-3169
  (* Security fix *)

kjhambrick · 11-29-2022, 05:09 PM

Woo Hoo !

Thanks to Pat and the Team !

-- kjh