Just pushed the new kernel point releases:
- linux419 4.19.276
- linux54 5.4.235
- linux510 5.10.173
- linux515 5.15.100
- linux61 6.1.18
- linux62 6.2.5
Just pushed the new kernel point releases:
Question: if our issue was resolved by a fast-tracked package update (like was done today), should we change our answer to the poll? Since it was an issue with the update, but is no longer.
I noticed a new warning:
WARNING: consolefont: no font found in configuration
Is that expected or something out of ordinary?
Doesn’t work for me as My Broadcom wifi adaptor is not working with these new releases.
I’m using Linux510-LTS kernel (Can’t upgrade because of old legacy NVidia driver 340.108)
Same with Linux54-LTS
Found this on Arch Forum:
Most likely the developers doing the kernel work won’t get the info at all. Lets take a look at the patch header:
author John Harrison <John.C.Harrison@Intel.com> 2023-02-15 17:11:01 -0800 committer Greg Kroah-Hartman <firstname.lastname@example.org> 2023-03-10 09:40:14 +0100 commit 4eb6789f9177a5fdb90e1b7cdd4b069d1fb9ce45 (patch) tree 7f0259b02632bf92193b3b5aa5c45d6f0fa3ebdd parent 64bcaffa2d5c88ddfe12d6019ad58986bd0e314c (diff) download linux-4eb6789f9177a5fdb90e1b7cdd4b069d1fb9ce45.tar.gz drm/i915: Don't use BAR mappings for ring buffers with LLC commit 85636167e3206c3fbd52254fc432991cc4e90194 upstream. Direction from hardware is that ring buffers should never be mapped via the BAR on systems with LLC. There are too many caching pitfalls due to the way BAR accesses are routed. So it is safest to just not use it. Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Fixes: 9d80841ea4c9 ("drm/i915: Allow ringbuffers to be bound anywhere") Cc: Chris Wilson <email@example.com> Cc: Joonas Lahtinen <firstname.lastname@example.org> Cc: Jani Nikula <email@example.com> Cc: Rodrigo Vivi <firstname.lastname@example.org> Cc: Tvrtko Ursulin <email@example.com> Cc: firstname.lastname@example.org Cc: <email@example.com> # v4.9+
We know that there was an author by Intel John Harrison doing the patch. If we look at the last CC we see that patch should be added to all kernels starting with 4.9 kernel. So most likely you might have similar issues with higher and lower kernel series than your used 5.15 series if the same patch gets applied there also. You can check that here @stasadev: kernel/git/stable/stable-queue.git - Linux kernel stable patch queue. More or less higher than 6.2.2 might also not work on your end: 6.2.3 « releases - kernel/git/stable/stable-queue.git - Linux kernel stable patch queue. So test that by checking which kernels we provide.
So check other kernel series if they also don’t boot as you still have 5.15.98 as your fallback one.
If it is true, simply check if other kernel series are affected too by this.
The first thing you can do is to add a confirm report similar as you have found already here [i915]drm:add_taint_for_CI [i915]] CI tainted:0x9 by intel_gt_init+0xae/0x2d0 [i915] (#8284) · Issues · drm / intel · GitLab by adding your own details of hardware and maybe the dmesg log of the 5.15.99 and 5.15.98 of your own system additionally to the already reported one.
Next step is simply to summarize the issue in an email and sent that to upstream. Which emails? Well you have all what you need in the patch itself. Simply send them to the email addresses exactly as given. Also include the firstname.lastname@example.org and email@example.com mailing lists, as some developers still work on email.
Well, most likely it also can be a missing patch within the 5.15 kernel series. For example I see this in all the other kernel series when the patch is applied, except 5.15, even it is tacked to be included: drm-i915-don-t-use-stolen-memory-for-ring-buffers-with-llc.patch « 6.2.3 « releases - kernel/git/stable/stable-queue.git - Linux kernel stable patch queue So test as recommended other kernel series and see if they work for you.
We might revert the patch as of now and follow up with upstream.
Thanks. However, I’m not sure if I understand it. I don’t see any depreciated hooks in my case. And oh, this is a topic from 2012… so I’m not sure how relevant it is.
Here is mine grub file in/etc/default/ :
GRUB_DEFAULT=saved GRUB_TIMEOUT=5 GRUB_TIMEOUT_STYLE=hidden GRUB_DISTRIBUTOR="Manjaro" GRUB_CMDLINE_LINUX_DEFAULT="quiet splash loglevel=3 udev.log_priority=3 vt.global_cursor_default=0 resume=/dev/sda4 resume_offset=1363968" GRUB_CMDLINE_LINUX="rhgb quiet mitigations=off" # If you want to enable the save default function, uncomment the following # line, and set GRUB_DEFAULT to saved. GRUB_SAVEDEFAULT=true # Uncomment to disable submenus in boot menu #GRUB_DISABLE_SUBMENU=y # Preload both GPT and MBR modules so that they are not missed GRUB_PRELOAD_MODULES="part_gpt part_msdos" # Uncomment to enable booting from LUKS encrypted devices #GRUB_ENABLE_CRYPTODISK=y # Uncomment to use basic console GRUB_TERMINAL_INPUT=console # Uncomment to disable graphical terminal #GRUB_TERMINAL_OUTPUT=console # The resolution used on graphical terminal # note that you can use only modes which your graphic card supports via VBE # you can see them in real GRUB with the command 'videoinfo' GRUB_GFXMODE=auto # Uncomment to allow the kernel use the same resolution used by grub GRUB_GFXPAYLOAD_LINUX=keep # Uncomment if you want GRUB to pass to the Linux kernel the old parameter # format "root=/dev/xxx" instead of "root=/dev/disk/by-uuid/xxx" #GRUB_DISABLE_LINUX_UUID=true # Uncomment to disable generation of recovery mode menu entries GRUB_DISABLE_RECOVERY=true # Uncomment this option to enable os-prober execution in the grub-mkconfig command GRUB_DISABLE_OS_PROBER=false # Uncomment and set to the desired menu colors. Used by normal and wallpaper # modes only. Entries specified as foreground/background. GRUB_COLOR_NORMAL="light-gray/black" GRUB_COLOR_HIGHLIGHT="green/black" # Uncomment one of them for the gfx desired, a image background or a gfxtheme GRUB_BACKGROUND="/root/alien-background.png" #GRUB_THEME="/path/to/gfxtheme" # Uncomment to get a beep at GRUB start #GRUB_INIT_TUNE="480 440 1" # Uncomment to ensure that the root filesystem is mounted read-only so that # systemd-fsck can run the check automatically. We use 'fsck' by default, which # needs 'rw' as boot parameter, to avoid delay in boot-time. 'fsck' needs to be # removed from 'mkinitcpio.conf' to make 'systemd-fsck' work. # See also Arch-Wiki: https://wiki.archlinux.org/index.php/Fsck#Boot_time_checking #GRUB_ROOT_FS_RO=true
sudo vim /etc/vconsole.conf
sudo cp -p /etc/mkinitcpio.conf /etc/mkinitcpio_edit_consolefont.conf;sudo vim /etc/mkinitcpio.conf
remove consolefont from hooks line
sudo mkinitcpio -P;sudo grub-mkconfig -o /boot/grub/grub.cfg
v6.2.5 fixed the wifi issue
I have now a minor silly issue. Whenever I update the
nvidia driver I get this (harmless) error:
(4/5) reinstalling linux62-nvidia cat: /usr/lib/modules/extramodules-6.1-MANJARO/version: No such file or directory depmod: ERROR: Bad version passed error: command failed to execute correctly
I checked in
/usr/share/libalpm and the post-transaction hooks seem correct to me. I also don’t have any trace left of kernel v6.1 - as far as I can see, at least.
Where else shall I look for left-overs?
@chainofflowers Can be related to this: [pkg-upd] 34-1.1 (a2fb55ca) · Commits · Packages / Core / mkinitcpio · GitLab. Check if the preset is still given and see what mkinitcpio hook does …
Thanks. There was no font defined in the /etc/vconsole.conf`, Since I have no idea what is the default, I added what you have.
From what I see the consolefont hook is not depreciated, so I’m leaving it for now.
But not the 5.10.173
should be enough, I don’t have it on my hooks line as well.
There is no trace of 6.1 in /etc/mkinitcpio/*, and
mkinicpio -P behaves correctly…
Moreover I just tried with another computer with a Broacom Wifi with kernel 6.2.5 but on Mageia and I got the same pblm: Wifi not available
So the pblm is not specific to Manjaro
Question: Is it possible to downgrade the kernel?
In Manjaro you can have multiple kernels installed. See:
I know that. This is not the question as it seems all the last versions of kernels have a pblm with broadcom wifi card. I wanted to downgrade to the previous 5.10 that was working (5.10-171).
And it seems to be impossible. At least I don’t know howto
of course not! it’s an upstream issue, as I reported here: it’s a regression introduced by the linux-wireless folks, discussed in this thread in the mailing list.
it’s better to patch the kernel you want to use by rebuilding from source and manually applying the revert - but I think that the manjaro-arm team is already working on back-porting the patch to the 5.10 series on the distro?