Page 1 of 2 12 LastLast
Results 1 to 10 of 17

Thread: Kernel 5.14 RC (Release Candidate) series

  1. #1
    Join Date
    Feb 2011
    Location
    Coquitlam, B.C. Canada
    Beans
    3,026
    Distro
    Ubuntu Development Release

    Kernel 5.14 RC (Release Candidate) series

    Kernel 5.14-rc1 has been released, but all versions did not build on the Ubuntu mainline PPA.
    I have to compile the kernel myself anyhow, and that worked fine:

    Code:
    doug@s19:~$ uname -a
    Linux s19 5.14.0-rc1-stock #901 SMP PREEMPT Tue Jul 13 07:13:01 PDT 2021 x86_64 x86_64 x86_64 GNU/Linux
    Here is the link back trail to previous rc series threads:

    5.13, 5.12, 5.11, 5.10, 5.9, 5.8, 5.7, 5.6, 5.5, 5.4, 5.3, 5.2, 5.1, 5.0, 4.20, 4.19 ?, 4.18, 4.17, 4.16, 4.15, 4.14.
    Any follow-up information on your issue would be appreciated. Please have the courtesy to report back.

  2. #2
    Join Date
    Oct 2008
    Location
    ExodusHair<Čubura
    Beans
    Hidden!
    Distro
    Ubuntu Development Release

    Re: Kernel 5.14 RC (Release Candidate) series

    Ignota nulla curatio morbi.

  3. #3
    Join Date
    Feb 2011
    Location
    Coquitlam, B.C. Canada
    Beans
    3,026
    Distro
    Ubuntu Development Release

    Re: Kernel 5.14 RC (Release Candidate) series

    The compile actually seems to work fine, but there seems to be a spurious "+" sign in the path. From the log file:

    Code:
      SIGN    /home/kernel/COD/linux/debian/linux-modules-5.14.0-051400rc1-generic//lib/modules/5.14.0-051400rc1-generic+/kernel/sound/xen/snd_xen_front.ko
      SIGN    /home/kernel/COD/linux/debian/linux-modules-5.14.0-051400rc1-generic//lib/modules/5.14.0-051400rc1-generic+/kernel/sound/usb/snd-usb-audio.ko
      DEPMOD  /home/kernel/COD/linux/debian/linux-modules-5.14.0-051400rc1-generic//lib/modules/5.14.0-051400rc1-generic+
    Now notice no "+" sign:

    Code:
    mv /home/kernel/COD/linux/debian/linux-modules-5.14.0-051400rc1-generic/lib/modules/5.14.0-051400rc1-generic/modules.order \
    	/home/kernel/COD/linux/debian/linux-modules-5.14.0-051400rc1-generic/lib/modules/5.14.0-051400rc1-generic/_
    mv: cannot stat '/home/kernel/COD/linux/debian/linux-modules-5.14.0-051400rc1-generic/lib/modules/5.14.0-051400rc1-generic/modules.order': No such file or directory
    I haven't seen any traffic on the kernel channel on IRC about the build problems. (I looked at many days, not just the day of the link.)

    Here is the same/similar stuff from my compile log, noting that multi-threaded ordering will be different:

    Code:
      SIGN    debian/linux-image/lib/modules/5.14.0-rc1-stock2/kernel/sound/virtio/virtio_snd.ko
      SIGN    debian/linux-image/lib/modules/5.14.0-rc1-stock2/kernel/sound/x86/snd-hdmi-lpe-audio.ko
      SIGN    debian/linux-image/lib/modules/5.14.0-rc1-stock2/kernel/sound/xen/snd_xen_front.ko
      DEPMOD  debian/linux-image/lib/modules/5.14.0-rc1-stock2
    and I don't have the "mv" step.
    Last edited by Doug S; July 16th, 2021 at 04:18 PM.
    Any follow-up information on your issue would be appreciated. Please have the courtesy to report back.

  4. #4
    Join Date
    Oct 2008
    Location
    ExodusHair<Čubura
    Beans
    Hidden!
    Distro
    Ubuntu Development Release

    Re: Kernel 5.14 RC (Release Candidate) series

    It seems that, one week later, we have first .deb files ready on Ubuntu mainline...
    Code:
     :~$ uname -r
    5.14.0-051400rc2daily20210719-generic
    Update₁:
    It works nice on a rather old machine. On a rather new machine: no boot... Who would have said...
    Last edited by zika; July 20th, 2021 at 04:41 AM.
    Ignota nulla curatio morbi.

  5. #5
    Join Date
    Feb 2011
    Location
    Coquitlam, B.C. Canada
    Beans
    3,026
    Distro
    Ubuntu Development Release

    Re: Kernel 5.14 RC (Release Candidate) series

    Quote Originally Posted by zika View Post
    It seems that, one week later, we have first .deb files ready on Ubuntu mainline...
    Code:
     :~$ uname -r
    5.14.0-051400rc2daily20210719-generic
    Aghhh, finally. It is late here, I'll try it tomorrow.

    With 5.14-rc1 I just had:

    Code:
    Message from syslogd@s19 at Jul 18 19:34:09 ...
     kernel:[469844.099059] watchdog: BUG: soft lockup - CPU#10 stuck for 22s! [kworker/10:0:556474]
    
    Message from syslogd@s19 at Jul 18 19:34:37 ...
     kernel:[469872.099056] watchdog: BUG: soft lockup - CPU#10 stuck for 48s! [kworker/10:0:556474]
    ...
    Message from syslogd@s19 at Jul 18 19:38:21 ...
     kernel:[470096.099034] watchdog: BUG: soft lockup - CPU#10 stuck for 257s! [kworker/10:0:556474]
    client_loop: send disconnect: Connection reset
    Which I also had at the end of the 5.13-rc series, but thought it was a BIOS upgrade issue. But it is a very brutal test that I am running.

    EDIT: ... the next monring ...
    Now I get another compile error:

    Code:
    doug@s19:~/temp-k-git/linux$ time make -j13 olddefconfig bindeb-pkg LOCALVERSION=-stock > bla
     dpkg-source --before-build .
     debian/rules binary
    make[5]: *** No rule to make target 'debian/canonical-revoked-certs.pem', needed by 'certs/x509_revocation_list'.  Stop.
    make[5]: *** Waiting for unfinished jobs....
    make[4]: *** [Makefile:1842: certs] Error 2
    make[4]: *** Waiting for unfinished jobs....
    make[3]: *** [debian/rules:7: build-arch] Error 2
    dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2
    make[2]: *** [scripts/Makefile.package:83: bindeb-pkg] Error 2
    make[1]: *** [Makefile:1560: bindeb-pkg] Error 2
    make: *** [Makefile:351: __build_one_by_one] Error 2
    And so needed to add this to my compile procedure:

    Code:
    doug@s19:~/temp-k-git/linux$ scripts/config --disable SYSTEM_REVOCATION_KEYS
    So, to summarize: For a new rc compile, starting with the mainline PPA kernel configuration file:

    Code:
    doug@s19:~/temp-k-git/linux$ scripts/config --disable SYSTEM_TRUSTED_KEYS
    doug@s19:~/temp-k-git/linux$ scripts/config --disable DEBUG_INFO
    doug@s19:~/temp-k-git/linux$ scripts/config --disable SYSTEM_REVOCATION_KEYS
    resulting in, after compile:

    Code:
    doug@s19:~/temp-k-git/linux$ scripts/diffconfig .config-5.14.0-051400rc2-lowlatency .config
    -DEBUG_INFO_BTF y
    -DEBUG_INFO_BTF_MODULES y
    -DEBUG_INFO_COMPRESSED n
    -DEBUG_INFO_DWARF4 y
    -DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT n
    -DEBUG_INFO_REDUCED n
    -DEBUG_INFO_SPLIT n
    -GDB_SCRIPTS y
    -PAHOLE_HAS_SPLIT_BTF y
     AS_VERSION 23690 -> 23400
     CC_VERSION_TEXT "gcc (Ubuntu 10.3.0-6ubuntu1) 10.3.0" -> "gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0"
     DEBUG_INFO y -> n
     GCC_VERSION 100300 -> 90300
     LD_VERSION 23690 -> 23400
     SYSTEM_REVOCATION_KEYS "debian/canonical-revoked-certs.pem" -> ""
     SYSTEM_TRUSTED_KEYS "debian/canonical-certs.pem" -> ""
    Last edited by Doug S; July 19th, 2021 at 03:36 PM.
    Any follow-up information on your issue would be appreciated. Please have the courtesy to report back.

  6. #6
    Join Date
    Oct 2008
    Location
    ExodusHair<Čubura
    Beans
    Hidden!
    Distro
    Ubuntu Development Release

    Re: Kernel 5.14 RC (Release Candidate) series

    5.14 came, also, from Ubuntu repositories, so, now, it's a bit more stable source...
    Code:
    :~$ apt search 5.14|grep install
    linux-headers-5.14.0-1-generic/impish,now 5.14.0-1.1 amd64 [installed,automatic]
    linux-image-5.14.0-1-generic/impish,now 5.14.0-1.1 amd64 [installed,automatic]
    linux-modules-5.14.0-1-generic/impish,now 5.14.0-1.1 amd64 [installed,automatic]
    linux-modules-extra-5.14.0-1-generic/impish,now 5.14.0-1.1 amd64 [installed,automatic]
    linux-unstable-headers-5.14.0-1/impish,impish,now 5.14.0-1.1 all [installed,automatic
    It works quite nice on old machine.
    On new one:
    Code:
    [   14.520056] gpio gpiochip2: (gpio_aaeon): tried to insert a GPIO c>
    [   14.520099] gpiochip_add_data_with_key: GPIOs 0..-1 (gpio_aaeon) f>
    [   14.520140] gpio-aaeon: probe of gpio-aaeon.0 failed with error -22
    I'll have to see what that means, in a kind of rush right now... Looks to me more for Pi than for Ryzen (where this happens) but little do I know now...
    Update₁: GPIO hurdle jumped over but something else does make kernel stall just like that from mainline. Will investigate more...
    Update₂: Got some spare time and got 5.14 workin' on that newer machine in drm-tip flavour. Searching for difference to fugure out a reason why that one works and other two do not...
    Update₃: Daily finally booted OK. 5.14.0-2 from Ubuntu started having same issue as Daily had... Waiting for 5.14.0-3... DrmTip is OK all the time since it started working...
    Update₄: Finally, waiting was worthwhile. All 3 (drmtip, daily and rc3) are working nice.
    Last edited by zika; July 26th, 2021 at 12:31 PM.
    Ignota nulla curatio morbi.

  7. #7
    Join Date
    Feb 2011
    Location
    Coquitlam, B.C. Canada
    Beans
    3,026
    Distro
    Ubuntu Development Release

    Re: Kernel 5.14 RC (Release Candidate) series

    Ever since kernel 5.14-rc1 I have been getting (for example):

    Code:
    Jul 13 07:34:05 s19 kernel: Unknown command line parameters: BOOT_IMAGE=/boot/vmlinuz-5.14.0-rc1-stock
    but I don't know what the problem is:

    My command lines have been:

    Code:
    Aug 02 08:12:14 s19 kernel: Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.14.0-rc3-teo root=UUID=0ac356c1-caa9-4c2e-8229-4408bd998dbd ro ipv6.disable=1 consoleblank=314 intel_pstate=active intel_pstate=no_hwp msr.allow_writes=on cpuidle.governor=teo
    and:

    Code:
    Aug 04 15:23:03 s19 kernel: Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.14.0-rc3-teo2 root=UUID=0ac356c1-caa9-4c2e-8229-4408bd998dbd ro ipv6.disable=1 consoleblank=450 intel_pstate=passive intel_pstate=no_hwp cpufreq.default_governor=ondemand msr.allow_writes=on cpuidle.governor=teo
    For as yet unknown reasons (but the kernel version has been eliminated) my system is starting with HWP enabled regardless, since July 6th, which does coincide with a BIOS update, but the system at first lists HWP as disabled:

    Code:
    Aug  4 16:24:44 s19 kernel: [    0.000000] intel_pstate: HWP disabled... Doug...3
    and then later on it is enabled:

    Code:
    Aug  4 16:24:44 s19 kernel: [    0.374427] intel_pstate: HWP enabled... Doug...1
    Note: I put the flags there, just to be sure where the messages came from.

    Going backwards quickly these weeks.
    Note: for also unknown reasons, I am unable to go back to the previous BIOS version as a test. Seems to have been a one way trip, which is counter to the most basic of system rules. Sigh...

    EDIT: I added another flag and edited above. O.K. so flag 3 doesn't prove anything, because it is just saying what the command line is telling it. So this looks like a BIOS issue.
    Last edited by Doug S; August 5th, 2021 at 12:31 AM. Reason: attempted to clarify
    Any follow-up information on your issue would be appreciated. Please have the courtesy to report back.

  8. #8
    Join Date
    Apr 2019
    Beans
    19

    Re: Kernel 5.14 RC (Release Candidate) series

    Quote Originally Posted by Doug S View Post
    E
    Note: for also unknown reasons, I am unable to go back to the previous BIOS version as a test. Seems to have been a one way trip, which is counter to the most basic of system rules. Sigh...

    EDIT: I added another flag and edited above. O.K. so flag 3 doesn't prove anything, because it is just saying what the command line is telling it. So this looks like a BIOS issue.
    That means you have a BIOS parameter(s) that prevents flashing an older version.

    Lenovo > Security > UEFI BIOS Update Option (1) > Secure RollBack Prevention > Disabled > Allows flashing to older version / Enabled > Prevents flashing previous ones.

    UEFI BIOS Update Option (2) > Windows UEFI Firmware Update > Disabled > BIOS will skip Windows UEFI firmware update.

    Both are disabled and previous versions are working. From memory, I do believe they were enabled out of the box.

    Code:
    uname -r
    5.14.0-051400rc4-generic
    I hope you're not too affected by the fires mate and you have air conditioning.

    Take care,

  9. #9
    Join Date
    Feb 2011
    Location
    Coquitlam, B.C. Canada
    Beans
    3,026
    Distro
    Ubuntu Development Release

    Re: Kernel 5.14 RC (Release Candidate) series

    Quote Originally Posted by xyz-t View Post
    That means you have a BIOS parameter(s) that prevents flashing an older version.
    Lenovo > Security > UEFI BIOS Update Option (1) > Secure RollBack Prevention > Disabled > Allows flashing to older version / Enabled > Prevents flashing previous ones.
    UEFI BIOS Update Option (2) > Windows UEFI Firmware Update > Disabled > BIOS will skip Windows UEFI firmware update.
    Thanks.
    This Motherboard is an ASUS Prime Z490-A, and so far I still haven't been able to go back to BIOS version 1003. I contacted ASUS, but they merely referred me to a procedure that I had already tried and had already said didn't work in my initial inquiry to them. Grrr...

    Quote Originally Posted by xyz-t View Post
    I hope you're not too affected by the fires mate and you have air conditioning.
    We have been lucky, with only a couple of days of haze, so far. We don't have air conditioning.
    Any follow-up information on your issue would be appreciated. Please have the courtesy to report back.

  10. #10
    Join Date
    Feb 2011
    Location
    Coquitlam, B.C. Canada
    Beans
    3,026
    Distro
    Ubuntu Development Release

    Re: Kernel 5.14 RC (Release Candidate) series

    Quote Originally Posted by Doug S View Post
    Ever since kernel 5.14-rc1 I have been getting (for example):

    Code:
    Jul 13 07:34:05 s19 kernel: Unknown command line parameters: BOOT_IMAGE=/boot/vmlinuz-5.14.0-rc1-stock
    but I don't know what the problem is:
    I bisected the kernel only to find this:

    Code:
    doug@s19:~/temp-k-git/linux$ git show 86d1919a4fb0d9c115dd1d3b969f5d1650e45408
    commit 86d1919a4fb0d9c115dd1d3b969f5d1650e45408
    Author: Andrew Halaney <ahalaney@redhat.com>
    Date:   Wed Jun 30 18:56:28 2021 -0700
    
        init: print out unknown kernel parameters
    
        It is easy to foobar setting a kernel parameter on the command line
        without realizing it, there's not much output that you can use to assess
        what the kernel did with that parameter by default.
    
        Make it a little more explicit which parameters on the command line
        _looked_ like a valid parameter for the kernel, but did not match anything
        and ultimately got tossed to init.  This is very similar to the unknown
        parameter message received when loading a module.
    
        This assumes the parameters are processed in a normal fashion, some
        parameters (dyndbg= for example) don't register their parameter with the
        rest of the kernel's parameters, and therefore always show up in this list
        (and are also given to init - like the rest of this list).
    
        Another example is BOOT_IMAGE= is highlighted as an offender, which it
        technically is, but is passed by LILO and GRUB so most systems will see
        that complaint.
    
        An example output where "foobared" and "unrecognized" are intentionally
        invalid parameters:
    
          Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.12-dirty debug log_buf_len=4M foobared unrecognized=foo
          Unknown command line parameters: foobared BOOT_IMAGE=/boot/vmlinuz-5.12-dirty unrecognized=foo
    
        Link: https://lkml.kernel.org/r/20210511211009.42259-1-ahalaney@redhat.com
        Signed-off-by: Andrew Halaney <ahalaney@redhat.com>
        Suggested-by: Steven Rostedt <rostedt@goodmis.org>
        Suggested-by: Borislav Petkov <bp@suse.de>
        Acked-by: Borislav Petkov <bp@suse.de>
        Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
        Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    
    diff --git a/init/main.c b/init/main.c
    index e9c42a183e33..d4f7af4cf560 100644
    --- a/init/main.c
    +++ b/init/main.c
    @@ -872,6 +872,47 @@ void __init __weak arch_call_rest_init(void)
            rest_init();
     }
    
    +static void __init print_unknown_bootoptions(void)
    +{
    +       char *unknown_options;
    +       char *end;
    +       const char *const *p;
    +       size_t len;
    +
    +       if (panic_later || (!argv_init[1] && !envp_init[2]))
    +               return;
    +
    +       /*
    +        * Determine how many options we have to print out, plus a space
    +        * before each
    +        */
    +       len = 1; /* null terminator */
    +       for (p = &argv_init[1]; *p; p++) {
    +               len++;
    +               len += strlen(*p);
    +       }
    +       for (p = &envp_init[2]; *p; p++) {
    +               len++;
    +               len += strlen(*p);
    +       }
    +
    +       unknown_options = memblock_alloc(len, SMP_CACHE_BYTES);
    +       if (!unknown_options) {
    +               pr_err("%s: Failed to allocate %zu bytes\n",
    +                       __func__, len);
    +               return;
    +       }
    +       end = unknown_options;
    +
    +       for (p = &argv_init[1]; *p; p++)
    +               end += sprintf(end, " %s", *p);
    +       for (p = &envp_init[2]; *p; p++)
    +               end += sprintf(end, " %s", *p);
    +
    +       pr_notice("Unknown command line parameters:%s\n", unknown_options);
    +       memblock_free(__pa(unknown_options), len);
    +}
    +
     asmlinkage __visible void __init __no_sanitize_address start_kernel(void)
     {
            char *command_line;
    @@ -913,6 +954,7 @@ asmlinkage __visible void __init __no_sanitize_address start_kernel(void)
                                      static_command_line, __start___param,
                                      __stop___param - __start___param,
                                      -1, -1, NULL, &unknown_bootoption);
    +       print_unknown_bootoptions();
            if (!IS_ERR_OR_NULL(after_dashes))
                    parse_args("Setting init args", after_dashes, NULL, 0, -1, -1,
                               NULL, set_init_arg);
    Any follow-up information on your issue would be appreciated. Please have the courtesy to report back.

Page 1 of 2 12 LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •