Bookworm Build script

[fredx181]

I am having a problem with the newest kernel on Bookworm (6.1.0-8 and 6.1.0-9) when trying to set monitor resolution to something other than the default (for me 1920x1080, then changing to 1600x900) results in crashing X and unresponsive keyboard. Got this problem on Devuan Daedalus too, btw.
Anyone else experiencing this ? (edit: or not ?)
With kernel 6.1.0-7 (and earlier) it was OK for me.
EDIT: Used 'Monitor settings' from menu (lxrandr) but also tested "Display settings" on a XFCE build, same problem.

Now did a lot of investigating and experimenting and found a *fix* for my situation...
On my testing previously I did install "firmware-misc-nonfree" (for wifi) and got the freeze (as described earlier) after changing resolution with lxrandr.
Now I found that without installing "firmware-misc-nonfree" there's no problem for me, resolution change works ok.

Mysterious ... can't lay my finger on it, what's exactly the connection with the newest kernel and "firmware-misc-nonfree" (hasn't been updated since february 10) that this problem occurs, some sort of conflict ?!
@dancytron your situation may very well be different of course.

[dancytron]

I do install firmware-misc-nonfree, that's where the drivers for my usb TV card are (which I never use except for tornado warnings because American OTA TV is garbage).

[fredx181]

@dancytron

I do install firmware-misc-nonfree, that's where the drivers for my usb TV card are (which I never use except for tornado warnings because American OTA TV is garbage).

Yes, well, didn't mean as a real fix to avoid firmware-misc-nonfree , just trying to analyze the problem.

Can you test this kernel v6.3.0-0-amd64 ? (extract in 'live' folder):
https://github.com/DebianDog/MakeLive/r ... d64.tar.gz
It's from Debian experimental repo, for me at least the problems are fixed, booting with this kernel.

[dancytron]

Okay.

It will probably be tomorrow afternoon.

[dancytron]

Same result. Only sees 800x600.

I copied /var/log and found some errors in dmesg. I'll try to post that up this evening.

[fredx181]

Same result. Only sees 800x600.

I copied /var/log and found some errors in dmesg. I'll try to post that up this evening.

Thanks, pity, I was hoping of some similarity between your problem and mine, but it seems not.
Perhaps when you have time you can check what happens without firmware-misc-nonfree installed with kernel 6.1.0-9 (or 6.3.0-0) (may need a reboot if you uninstall it, in case already installed)

[fredx181]

@dancytron Bill suggested that you might need firmware-amd-graphics viewtopic.php?p=89841#p89841

[fredx181]

I am having a problem with the newest kernel on Bookworm (6.1.0-8 and 6.1.0-9) when trying to set monitor resolution to something other than the default (for me 1920x1080, then changing to 1600x900) results in crashing X and unresponsive keyboard. Got this problem on Devuan Daedalus too, btw.
Anyone else experiencing this ? (edit: or not ?)
With kernel 6.1.0-7 (and earlier) it was OK for me.
EDIT: Used 'Monitor settings' from menu (lxrandr) but also tested "Display settings" on a XFCE build, same problem.

Could solve this for my case (intel graphics) by adding kernel module i915 to be loaded at boot from the initrd1.xz.
Added also nouveau and radeon modules to the initrd to be loaded at early stage, in case these graphics are possibly also affected by the change (can't test that though).
EDIT: Adding nouveau and radeon wasn't a good idea, changed now to ONLY added i915 thanks @gumanzoy

No change needed for the mklive script or appimage, btw.

Making a new build will apply this change.
EDIT: Also updated "upgrade-kernel" package in the custom repos with this change for generating initrd1.xz
EDIT 26-5-2023: Reverted back to how it was, no loading i915 from the initrd.

[gumanzoy]

Added also nouveau and radeon modules to the initrd to be loaded at early stage

modprobe nouveau breaks nvidia driver (in case someone use it)

radeon module not work without firmware and need include firmware to initrd.

And all AMD Ryzen APU use amdgpu (need firmware too) module, not radeon.

I still can not reproduce 'Monitor settings' problem with kernel 6.1.0-8 and firmware-misc-nonfree

[fredx181]

Added also nouveau and radeon modules to the initrd to be loaded at early stage

modprobe nouveau breaks nvidia driver (in case someone use it)

radeon module not work without firmware and need include firmware to initrd.

And all AMD Ryzen APU use amdgpu (need firmware too) module, not radeon.

I still can not reproduce 'Monitor settings' problem with kernel 6.1.0-8 and firmware-misc-nonfree

Ah, thanks, don't know much about this stuff, so I better change the loading kernel modules from the initrd to be only i915 ? (not nouveau and radeon)
Rather frustrating this, the 6.1.0-7 kernel worked fine for me and also for @dancytron .

[gumanzoy]

Added also nouveau and radeon modules to the initrd to be loaded at early stage

modprobe nouveau breaks nvidia driver (in case someone use it)

radeon module not work without firmware and need include firmware to initrd.

And all AMD Ryzen APU use amdgpu (need firmware too) module, not radeon.

I still can not reproduce 'Monitor settings' problem with kernel 6.1.0-8 and firmware-misc-nonfree

Ah, thanks, don't know much about this stuff, so I better change the loading kernel modules from the initrd to be only i915 ?

Yes.

[fredx181]

See EDIT here: viewtopic.php?p=90093#p90093 changed things now to be ONLY added i915 to be loaded from initrd1.xz, thanks again @gumanzoy

[rcrsn51]

Does this work because i915 is now being loaded without its firmware, which you have already shown to be a workaround?

This could cause other problems.

[fredx181]

Does this work because i915 is now being loaded without its firmware, which you have already shown to be a workaround?

This could cause other problems.

No problem with this change for me with and without installed firmware-misc-nonfree (before worked well only without firmware-misc-nonfree)

[gumanzoy]

Does this work because i915 is now being loaded without its firmware, which you have already shown to be a workaround?

This could cause other problems.

Yes. Need more testing.

Fred can you check winch firmware file in firmware-misc-nonfree cause problem ? And then downgrade or upgrade it from linux-firmware.git

https://www.amazon.com/ASUS-Blacklit-Ke ... B09NVXQXRZ

Celeron N4020 is Gemini Lake Refresh so look at
/lib/firmware/i915/glk_dmc_ver1_04.bin
/lib/firmware/i915/glk_guc_32.0.3.bin
/lib/firmware/i915/glk_guc_33.0.0.bin
/lib/firmware/i915/glk_guc_49.0.1.bin
/lib/firmware/i915/glk_guc_62.0.0.bin
/lib/firmware/i915/glk_guc_69.0.3.bin
/lib/firmware/i915/glk_guc_70.1.1.bin
/lib/firmware/i915/glk_huc_4.0.0.bin
/lib/firmware/i915/glk_huc_ver03_01_2893.bin

EDIT: I look at difference in drivers/gpu/drm/i915 between kernel 6.1.0-7 (6.1.20) and 6.1.0-8 (6.1.25)

Fred can you try boot with i915.enable_psr=0 and/or i915.enable_guc=0 (without modprobe i915 in initrd and with firmware-misc-nonfree)

And if it fix problem, better to revert this change

Could solve this for my case (intel graphics) by adding kernel module i915 to be loaded at boot from the initrd1.xz.

[fredx181]

Fred can you check winch firmware file in firmware-misc-nonfree cause problem ? And then downgrade or upgrade it from linux-firmware.git

Thanks, will investigate tomorrow.
EDIT: btw, perhaps useful to mention that when adding i915 to the loaded modules in the initrd, some drm* modules are loaded too.

[fredx181]

EDIT: I look at difference in drivers/gpu/drm/i915 between kernel 6.1.0-7 (6.1.20) and 6.1.0-8 (6.1.25)

Fred can you try boot with i915.enable_psr=0 and/or i915.enable_guc=0 (without modprobe i915 in initrd and with firmware-misc-nonfree)

And if it fix problem, better to revert this change
....

Thanks anyway, but both kernel options didn't work.
On second thought, I'm not going into the trouble of finding which from /lib/firmware/i915/ is causing it. Had enough crashes for my whole life
Also I'd like to mention that my motivation for solving this problem is not for me personal, I can workaround things, e.g. setting resolution with xorg.conf or use the 6.3 kernel (which is fine, no problem,see earlier in thread), it's for the general cause, even if the crash happens for only 1 out of 1000 cases it should be fixed IMO (and it's not a "light" problem, total freeze) (and @dancytron reported a (different) problem too with the newest kernel, btw) .
The fact that booting with live-boot (initrd.img) was without problems for me setting resolution (with firmware-misc-nonfree installed) made me think that some change was needed for the initrd1.xz.
But if it appears that the i915 addition in initrd1.xz causes problems for someone, I will revert it back.

[fredx181]

The problem is caused for me by /lib/firmware/i915/glk_dmc_ver1_04.bin, removed it and no freezing anymore.
Besides that it's easy fix for my personal use, I think now that my action was to hasty and out of frustration, better to revert back the i915 loading from initrd. Will do tomorrow.
Hopefully with a new kernel version it will be solved then.

[gumanzoy]

For better support GPU other than intel need add Xorg DDX drivers packages to BASE_INSTALL= for each config https://debiandog.github.io/MakeLive/configs-bookworm/
xserver-xorg-video-amdgpu xserver-xorg-video-radeon xserver-xorg-video-nouveau xserver-xorg-video-openchrome xserver-xorg-video-fbdev xserver-xorg-video-vesa

For example Xorg on integrated GPU of motherboard ASRock N68-VS3 very slow with modesetting driver and work ok when install xserver-xorg-video-nouveau

And add note somewhere "All radeon and amdgpu cards need firmware-amd-graphics"

The fact that booting with live-boot (initrd.img) was without problems for me setting resolution (with firmware-misc-nonfree installed) made me think that some change was needed for the initrd1.xz.

If run mkinitramfs with firmware-misc-nonfree and firmware-amd-graphics installed its included into initrd.img.
/usr/lib/firmware/i915,nvidia,radeon

But i not see any problem without kernel modules kernel/drivers/gpu/drm/ i915 nouveau radeon in initrd.
I don't now why mkinitramfs include it. But if modules included need to include firmware too.

[fredx181]

If run mkinitramfs with firmware-misc-nonfree and firmware-amd-graphics installed its included into initrd.img.
/usr/lib/firmware/i915,nvidia,radeon

The initrd.img I tested with was built without firmware (at build system stage) (didn't have installed), I installed firmware-misc-nonfree later.
So there must be a difference with the initrd1.xz that makes it work for me without crash when setting resolution, but what? I had a look inside, but it's really much too complicated for me to figure out how it handles things.

[gumanzoy]

If modprobe i915 in initrd (porteus of live-boot) not contain firmware - no firmware for i915 loaded at all.

The initrd.img I tested with was built without firmware (at build system stage) (didn't have installed), I installed firmware-misc-nonfree later.

Try to make another initrd.img with /usr/lib/firmware/i915/glk_dmc_ver1_04.bin and it should crash.

[fredx181]

@gumanzoy My comparison is with initrd.img without firmware included and initrd1.xz also without firmware included.
With both tests I have package firmware-misc-nonfree installed.

On both I ran dmesg | grep i915

Output with live-boot initrd.img: (failed to load the firmware, which is good in my case and explains why there's no crash).

Code: Select all

root@live:~# dmesg | grep i915
[    4.853245] i915 0000:00:02.0: [drm] Unknown revid 0x06
[    4.855747] i915 0000:00:02.0: [drm] VT-d active for gfx access
[    4.860384] i915 0000:00:02.0: vgaarb: deactivate vga console
[    4.860452] i915 0000:00:02.0: [drm] Using Transparent Hugepages
[    4.860521] i915 0000:00:02.0: [drm] couldn't get memory information
[    4.884473] i915 0000:00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=io+mem
[    4.885440] i915 0000:00:02.0: firmware: failed to load i915/glk_dmc_ver1_04.bin (-2)
[    4.885461] i915 0000:00:02.0: firmware: failed to load i915/glk_dmc_ver1_04.bin (-2)
[    4.885467] i915 0000:00:02.0: Direct firmware load for i915/glk_dmc_ver1_04.bin failed with error -2
[    4.885474] i915 0000:00:02.0: [drm] Failed to load DMC firmware i915/glk_dmc_ver1_04.bin. Disabling runtime power management.
[    4.885479] i915 0000:00:02.0: [drm] DMC firmware homepage: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/i915
[    5.023169] [drm] Initialized i915 1.6.0 20201103 for 0000:00:02.0 on minor 0
[    5.291709] fbcon: i915drmfb (fb0) is primary device
[    5.329350] i915 0000:00:02.0: [drm] fb0: i915drmfb frame buffer device
[   13.543790] snd_hda_intel 0000:00:0e.0: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])
[   13.853609] mei_hdcp 0000:00:0f.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04: bound 0000:00:02.0 (ops i915_hdcp_component_ops [i915])

Output with porteus-boot initrd1.xz: (firmware loading successful, bad, resulting in the crash when changing resolution)
This is without the change I recently made (no i915 modprobed from the init)

Code: Select all

oot@live:~# dmesg | grep i915
[    7.813049] i915 0000:00:02.0: [drm] Unknown revid 0x06
[    7.813507] i915 0000:00:02.0: [drm] VT-d active for gfx access
[    7.817344] i915 0000:00:02.0: vgaarb: deactivate vga console
[    7.817440] i915 0000:00:02.0: [drm] Using Transparent Hugepages
[    7.817517] i915 0000:00:02.0: [drm] couldn't get memory information
[    7.839059] i915 0000:00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=io+mem
[    7.840722] i915 0000:00:02.0: firmware: direct-loading firmware i915/glk_dmc_ver1_04.bin
[    7.841178] i915 0000:00:02.0: [drm] Finished loading DMC firmware i915/glk_dmc_ver1_04.bin (v1.4)
[    8.029624] [drm] Initialized i915 1.6.0 20201103 for 0000:00:02.0 on minor 0
[    8.308906] fbcon: i915drmfb (fb0) is primary device
[    8.308830] snd_hda_intel 0000:00:0e.0: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])
[    8.309212] mei_hdcp 0000:00:0f.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04: bound 0000:00:02.0 (ops i915_hdcp_component_ops [i915])
[    8.378433] i915 0000:00:02.0: [drm] fb0: i915drmfb frame buffer device

So for some reason booting with initrd.img prevents loading the i915 firmware.
EDIT: For what it's worth: Other test I did now with the initrd1.xz with the i915 driver modprobe'd and got exactly the same output (failed to load firmware) as above with live-boot (and no crashing of course). So that makes me think that perhaps live-boot does load i915 from the initrd.
Not saying that it's good that firmware fails to load though.

[gumanzoy]

@gumanzoy My comparison is with initrd.img without firmware included and initrd1.xz also without firmware included.
With both tests I have package firmware-misc-nonfree installed.

On both I ran dmesg | grep i915

Output with live-boot initrd.img: (failed to load the firmware, which is good in my case and explains why there's no crash).

Output with porteus-boot initrd1.xz: (firmware loading successful, bad, resulting in the crash when changing resolution)
This is without the change I recently made (no i915 modprobed from the init)

So for some reason booting with initrd.img prevents loading the i915 firmware.
EDIT: For what it's worth: Other test I did now with the initrd1.xz with the i915 driver modprobe'd and got exactly the same output (failed to load firmware) as above with live-boot (and no crashing of course).

initrd.img include i915 module and not include firmware.
initrd1.xz not include i915 module and not include firmware.

Try to make another initrd.img with /usr/lib/firmware/i915/glk_dmc_ver1_04.bin and it should crash.

Code: Select all

[    4.885474] i915 0000:00:02.0: [drm] Failed to load DMC firmware i915/glk_dmc_ver1_04.bin. Disabling runtime power management.

Try to boot with i915.enable_dc=0 (with firmware)

[fredx181]

Try to make another initrd.img with /usr/lib/firmware/i915/glk_dmc_ver1_04.bin and it should crash.

Did that and yes indeed crashing. (and dmesg says firmware loading successful).

Try to boot with i915.enable_dc=0 (with firmware)

Yes, works, thanks.
But I see that as a workaround. As it is still now (when doing new build) with modprobe i915 from the init, is more like a solution IMO, or do you think it's no good ? (causing other troubles perhaps).
In short what do you make up about all this, and there's also the issue @dancytron described earlier in this thread, not being able to get resolution higher than 800x600 since kernel 6.1.0-8 .
Thanks anyway for the help to get (more or less) to the bottom of this issue !

[gumanzoy]

Try to boot with i915.enable_dc=0 (with firmware)

Yes, works, thanks.
But I see that as a workaround. As it is still now (when doing new build) with modprobe i915 from the init, is more like a solution IMO, or do you think it's no good ? (causing other troubles perhaps).

Need report bug to debian or kernel.org.

modprobe i915 from the init is no good. As result not load i915 firmware at all, and "Disabling runtime power management." for all modern intel GPU.

Better downgrade kernel until fixed new version released.

Or suggest boot with i915.enable_dc=0 for affected hardware. But it disables power management and as result higher power consumption.

[dancytron]

Matching the kernel to your hardware, especially if you use old/cheap consumer grade hardware, is just a part of using Linux sometimes.

I still use my old HP dual core desktop that won't run any kernel past Stretch.

Maybe just document in the 1st post how to use an older kernel if you have an issue.

[fredx181]

Matching the kernel to your hardware, especially if you use old/cheap consumer grade hardware, is just a part of using Linux sometimes.

I still use my old HP dual core desktop that won't run any kernel past Stretch.

Maybe just document in the 1st post how to use an older kernel if you have an issue.

But the discussion lately wasn't about older computers (well, my input) the problem you reported a while back, I thought, was on your very recent computer, not ?
My laptop? New? Yes! Cheap? Yes! Good? No! (had some other problems which I'm not going to bother you )

[fredx181]

Reverted back now the changes (so no modprobe i915) from the initrd1.xz . So... as if nothing happened , same as it was 2 days ago.
For a part it was nice time spending

[dcung]

Reverted back now the changes (so no modprobe i915) from the initrd1.xz . So... as if nothing happened , same as it was 2 days ago.
For a part it was nice time spending

Just to confirm,
This means that reversion applies to this too?
viewtopic.php?p=90097#p90097

[fredx181]

Just to confirm,
This means that reversion applies to this too?
viewtopic.php?p=90097#p90097

Yes.