| View previous topic :: View next topic |
| Author |
Message |
gord
n00b
Joined: 25 May 2024
Posts: 17
|
 Posted: Sat May 25, 2024 2:11 pm Post subject: Black screen after modesetting - i915 and fbcon seem fine |
 |
|
Hi there,
On a new Gentoo install on a Thinkpad X201, I'm having trouble getting the system console to display under DRM/KMS (there seems to be output visible before the modeset happens, and passing nomodeset from the bootloader works fine). As far as I can tell, all the necessary kernel drivers are in place and working, but perhaps I'm mistaken? (For what it's worth, the drivers are all compiled in to the kernel and I'm not using an initramfs).
The machine is otherwise booting fine and I can log in via ssh. I've read through the full dmesg output and nothing seems problematic (as far as I can tell)? Some relevant parts:
dmesg | grep 'i915\|Console\|vga\|drm':
| Code: |
[ 0.079454] Console: colour VGA+ 80x25
[ 0.304532] pci 0000:00:02.0: vgaarb: setting as boot VGA device
[ 0.304532] pci 0000:00:02.0: vgaarb: bridge control possible
[ 0.304532] pci 0000:00:02.0: vgaarb: VGA device added: decodes=io+mem,owns=io+mem,locks=none
[ 0.304616] vgaarb: loaded
[ 0.422806] ACPI: bus type drm_connector registered
[ 0.425618] i915 0000:00:02.0: vgaarb: deactivate vga console
[ 0.426187] Console: switching to colour dummy device 80x25
[ 0.429777] i915 0000:00:02.0: vgaarb: VGA decodes changed: olddecodes=io+mem,decodes=io+mem:owns=io+mem
[ 0.459013] i915 0000:00:02.0: [drm] Skipping intel_backlight registration
[ 0.459105] [drm] Initialized i915 1.6.0 20201103 for 0000:00:02.0 on minor 0
[ 0.476376] fbcon: i915drmfb (fb0) is primary device
[ 0.478101] Console: switching to colour frame buffer device 160x50
[ 0.479693] i915 0000:00:02.0: [drm] fb0: i915drmfb frame buffer device
[ 0.936014] snd_hda_intel 0000:00:1b.0: bound 0000:00:02.0 (ops i915_audio_component_bind_ops)
|
cat /sys/kernel/debug/dri/0/framebuffer:
| Code: |
framebuffer[64]:
allocated by = [fbcon]
refcount=1
format=XR24 little-endian (0x34325258)
modifier=0x0
size=1280x800
layers:
size[0]=1280x800
pitch[0]=5120
offset[0]=0
obj[0]:
name=0
|
cat /sys/kernel/debug/dri/0/i915_display_info:
| Code: |
CRTC info
---------
[CRTC:45:pipe A]:
uapi: enable=yes, active=yes, mode="1280x800": 60 69286 640 1328 1360 1403 400 803 809 821 0x40 0xa
hw: enable=yes, active=yes
adjusted_mode="1280x800": 60 69286 1280 1328 1360 1403 800 803 809 821 0x40 0xa
pipe__mode="1280x800": 60 69286 1280 1328 1360 1403 800 803 809 821 0x40 0xa
pipe src=640x400+0+0, dither=no, bpp=18
No scalers available on this platform
[ENCODER:62:LVDS]: connectors:
[CONNECTOR:61:LVDS-1]
[PLANE:31:primary A]: type=PRI
uapi: [FB:0] n/a,0x0,0x0,, visible=hidden, src=0.000000x0.000000+0.000000+0.000000, dst=0x0+0+0, rotation=0 (0x00000001)
[PLANE:35:sprite A]: type=OVL
uapi: [FB:0] n/a,0x0,0x0,, visible=hidden, src=0.000000x0.000000+0.000000+0.000000, dst=0x0+0+0, rotation=0 (0x00000001)
[PLANE:41:cursor A]: type=CUR
uapi: [FB:0] n/a,0x0,0x0,, visible=hidden, src=0.000000x0.000000+0.000000+0.000000, dst=0x0+0+0, rotation=0 (0x00000001)
underrun reporting: cpu=no pch=no
[CRTC:60:pipe B]:
uapi: enable=no, active=no, mode="": 0 0 0 0 0 0 0 0 0 0 0x0 0x0
hw: enable=no, active=no
adjusted_mode="": 0 0 0 0 0 0 0 0 0 0 0x0 0x0
pipe__mode="": 0 0 0 0 0 0 0 0 0 0 0x0 0x0
pipe src=0x0+0+0, dither=no, bpp=0
No scalers available on this platform
[PLANE:46:primary B]: type=PRI
uapi: [FB:0] n/a,0x0,0x0,, visible=hidden, src=0.000000x0.000000+0.000000+0.000000, dst=0x0+0+0, rotation=0 (0x00000001)
[PLANE:50:sprite B]: type=OVL
uapi: [FB:0] n/a,0x0,0x0,, visible=hidden, src=0.000000x0.000000+0.000000+0.000000, dst=0x0+0+0, rotation=0 (0x00000001)
[PLANE:56:cursor B]: type=CUR
uapi: [FB:0] n/a,0x0,0x0,, visible=hidden, src=0.000000x0.000000+0.000000+0.000000, dst=0x0+0+0, rotation=0 (0x00000001)
underrun reporting: cpu=yes pch=yes
Connector info
--------------
[CONNECTOR:61:LVDS-1]: status: connected
physical dimensions: 260x160mm
subpixel order: Horizontal RGB
CEA rev: 0
HDCP version: No Connector Support
max bpc: 0
fixed modes:
"1280x800": 60 69300 1280 1328 1360 1403 800 803 809 821 0x48 0xa
"1280x800": 50 57590 1280 1328 1360 1403 800 803 809 821 0x40 0xa
modes:
"1280x800": 60 69300 1280 1328 1360 1403 800 803 809 821 0x48 0xa
"1280x800": 50 57590 1280 1328 1360 1403 800 803 809 821 0x40 0xa
[CONNECTOR:65:VGA-1]: status: disconnected
[CONNECTOR:68:HDMI-A-1]: status: disconnected
[CONNECTOR:76:DP-1]: status: disconnected
|
So the console framebuffer and graphics driver both seem to be set up, just not... connected to each other? As a sanity check, I installed Debian on the same machine, which worked out of the box and shows pipe A's primary plane as linked to the fbcon framebuffer in i915_display_info. I also diff'ed the Debian vs Gentoo dmesg outputs and couldn't find any differences that seemed relevant (but obviously, I'm missing something).
Any advice or further debugging suggestions would be welcomed! I'm starting to run out of ideas for things to check. |
|
| Back to top |
|
 |
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 5109
Location: Bavaria
|
|
| Back to top |
|
|
gord
n00b
Joined: 25 May 2024
Posts: 17
|
| Posted: Sat May 25, 2024 3:22 pm Post subject: |
|
|
| pietinger wrote: |
Welcome to Gentoo Forums ! 
|
Thank you! 
| pietinger wrote: |
Why do you want "nomodeset" ?
|
Sorry I wasn't clear here. I do want modesetting, but that (i.e omitting the nomodeset parameter) gives me the black screen. Passing the nomodeset parameter provides a functional low-res console, which is helpful for debugging purposes but not what I ultimately want.
Thank you for that link! Question about "Support for frame buffer devices". I've tried with this (+ the VESA VGA support) and without, and it doesn't seem to make a difference? My interpretation of the Linux documentation is that this shouldn't be needed: "the DRM subsystem provides support for emulated frame buffer devices on top of KMS drivers, but this option [Support for frame buffer devices] allows legacy fbdev drivers to be enabled as well ... If you are compiling for the x86 architecture, you can say Y if you want to play with it, but it is not essential ... If unsure, say N".
Otherwise, I'm including everything you mention, other than the EFI options since this is a legacy BIOS device.
Update: I copied the contents of /dev/fb0 to another machine and visualized the pixels - they're indeed the full-res console display (so fbcon is working fine, other than the fact that it's not outputting to a display). I also tried plugging in an external monitor which showed up in i915_display_info, although it wouldn't activate either.
Update 2: I should have mentioned earlier that I've also tried using an unmodified distribution kernel, but the issue remained. I also just installed Gentoo on a Thinkpad X61, and KMS works as expected both with the distribution kernel and a custom kernel derived from the exact same .config file used in the X201. So I'm quite certain this isn't a kernel configuration problem, unless it's attributable to differences between the X61 (GMA X3100) and X201 (HD Graphics) Intel graphics? |
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 5109
Location: Bavaria
|
| Posted: Tue May 28, 2024 9:56 am Post subject: |
|
|
| gord wrote: | | Update 2: I should have mentioned earlier that I've also tried using an unmodified distribution kernel, but the issue remained. [...] |
If our dist-kernel does not help, then I would try to boot with an UbuntuLiveCD (just for testing) ... maybe you will need a newer kernel version? ... maybe there is a hardware problem (therefore the test with Ubuntu).
_________________
https://wiki.gentoo.org/wiki/User:Pietinger |
|
| Back to top |
|
|
gord
n00b
Joined: 25 May 2024
Posts: 17
|
| Posted: Tue May 28, 2024 5:00 pm Post subject: |
|
|
| pietinger wrote: |
If our dist-kernel does not help, then I would try to boot with an UbuntuLiveCD (just for testing) ... maybe you will need a newer kernel version? ... maybe there is a hardware problem (therefore the test with Ubuntu). |
Thanks, yes, the Debian tests I mention in the first post give me some confidence that it’s not a hardware issue. I was considering installing the same (older) kernel version that Debian provides to see if that made a difference or not. I hadn’t considered a newer version, but that might be worth a try as well.
I had also been thinking about using libdrm to try to manually associate the framebuffer to the CRTC? That wouldn’t help diagnose the issue but might provide a workaround if I’m otherwise stuck. |
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 5109
Location: Bavaria
|
|
| Back to top |
|
|
gord
n00b
Joined: 25 May 2024
Posts: 17
|
| Posted: Wed May 29, 2024 2:42 am Post subject: |
|
|
Sure thing, thanks!
Note these were all collected over SSH with the machine running with the black screen, i.e., without nomodeset.
Kernel .config: http://dpaste.com/G2L9NV7LY
dmesg: http://dpaste.com/37F5T8TGX
lspci -nnk: http://dpaste.com/GWY6YYEAJ
(I've been experimenting with various things to see if any of it makes a difference - so far no luck, but if there's anything you'd like me to change and re-upload, e.g. kernel config options, bootloader parameters, etc, just let me know.) |
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 5109
Location: Bavaria
|
| Posted: Wed May 29, 2024 11:20 am Post subject: |
|
|
gord,
1. I have seen this:
| Code: | | # CONFIG_BLK_DEV_INITRD is not set |
That is okay ... I am not using an initramfs also ... BUT ... you have:
| Code: | | CONFIG_EXTRA_FIRMWARE="" |
This leads to:
| Code: | | [ 0.834229] rtl8192se 0000:02:00.0: Direct firmware load for rtlwifi/rtl8192sefw.bin failed with error -2 |
Please read this short chapter:
https://wiki.gentoo.org/wiki/User:Pietinger/Tutorials/Manual_kernel_configuration#Driver_needs_Firmware
Boot with our GentooLiveCD and do number 2 of:
https://wiki.gentoo.org/wiki/User:Pietinger/Tutorials/Manual_kernel_configuration#Before_you_start
(maybe you must emerge "linux-firmware" and "intel-microcode" and "wireless-regdb" also if not already done)
Add every firmware filename into CONFIG_EXTRA_FIRMWARE
Read also number 2 (intel-microcode) of:
https://wiki.gentoo.org/wiki/User:Pietinger/Tutorials/Manual_Configuring_Kernel_Version_6.6#Part_4_-_My_recommendations
2. Please change all this (in "make menuconfig"; search with / in there):
| Code: | 1.
# CONFIG_EFI is not set
2.
CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y
3.
CONFIG_SYSFB_SIMPLEFB=y
4.
# Intel pinctrl drivers
#
# CONFIG_PINCTRL_BAYTRAIL is not set
# CONFIG_PINCTRL_CHERRYVIEW is not set
# CONFIG_PINCTRL_LYNXPOINT is not set
# CONFIG_PINCTRL_ALDERLAKE is not set
# CONFIG_PINCTRL_BROXTON is not set
# CONFIG_PINCTRL_CANNONLAKE is not set
# CONFIG_PINCTRL_CEDARFORK is not set
# CONFIG_PINCTRL_DENVERTON is not set
# CONFIG_PINCTRL_ELKHARTLAKE is not set
# CONFIG_PINCTRL_EMMITSBURG is not set
# CONFIG_PINCTRL_GEMINILAKE is not set
# CONFIG_PINCTRL_ICELAKE is not set
# CONFIG_PINCTRL_JASPERLAKE is not set
# CONFIG_PINCTRL_LAKEFIELD is not set
# CONFIG_PINCTRL_LEWISBURG is not set
# CONFIG_PINCTRL_METEORLAKE is not set
# CONFIG_PINCTRL_SUNRISEPOINT is not set
# CONFIG_PINCTRL_TIGERLAKE is not set
# end of Intel pinctrl drivers
5.
# CONFIG_LPC_ICH is not set
# CONFIG_MFD_INTEL_LPSS_ACPI is not set
# CONFIG_MFD_INTEL_LPSS_PCI is not set
6.
# CONFIG_INTEL_IOMMU_SVM is not set
# CONFIG_IRQ_REMAP is not set
7.
CONFIG_VIDEO_NOMODESET=y |
1. Enable it. You need it to be able to enable THEN: CONFIG_FB_EFI. Enable also CONFIG_FB_VESA to be on a safe side
2. Read: https://wiki.gentoo.org/wiki/User:Pietinger/Tutorials/Manual_Configuring_Kernel_Version_6.6#Part_3_-_Must_Haves
3. Disable this bad option !
4. Maybe you dont have missed it (if you use no i2c device), but i2c needs PINCTRL. If unsure enable every
5. Enable all !
6. Enable all ! IRQ_REMAP is important
7. Disable it.
If you boot with our GentooLiveCD and do all queries then check with the list of "lsmod" also if you need CONFIG_INTEL_IDMA64
_________________
https://wiki.gentoo.org/wiki/User:Pietinger |
|
| Back to top |
|
|
gord
n00b
Joined: 25 May 2024
Posts: 17
|
| Posted: Wed May 29, 2024 4:21 pm Post subject: |
|
|
Thanks for your attention!
Yes, I haven't set up the Wifi yet, I'll be sure to use your instructions for that after the screen is working.
For the kernel configurations, I have now disabled #2 and #3, and enabled #4, #5, and #6 per your recommendations. No change in the issue, unfortunately 
Some follow-up questions:
- This is a legacy BIOS device, I assume the EFI-related options (#1) aren't needed?
- The search function didn't show a menu location for disabling #7 (CONFIG_VIDEO_NOMODESET). How would I do that? Does this involve "expert mode"? (I've been hesitant to touch that so far..) |
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 5109
Location: Bavaria
|
| Posted: Wed May 29, 2024 6:00 pm Post subject: |
|
|
| gord wrote: | | - This is a legacy BIOS device, I assume the EFI-related options (#1) aren't needed? |
Yes ... therefore I added VESA ... it should be loaded now ... I would like to see the new "dmesg" with these settings ... maybe add also FB_VGA16 and FB_SIMPLE (only to be very sure; dont confuse FB_SIMPLE with SYSFB_SIMPLEFB).
| gord wrote: | | - The search function didn't show a menu location for disabling #7 (CONFIG_VIDEO_NOMODESET). How would I do that? Does this involve "expert mode"? (I've been hesitant to touch that so far..) |
Yes, sorry, it is only a dependency ... you dont need expert mode ... but it doesnt hurt (I am using it == must have to be able to reach some important settings ... for hardening my kernel)
_________________
https://wiki.gentoo.org/wiki/User:Pietinger |
|
| Back to top |
|
|
gord
n00b
Joined: 25 May 2024
Posts: 17
|
| Posted: Wed May 29, 2024 6:50 pm Post subject: |
|
|
| Ok, here's dmesg with FB_VESA, FB_VGA16, and FB_SIMPLE enabled (still no change unfortunately): http://dpaste.com/GBNGQCBWM |
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 5109
Location: Bavaria
|
| Posted: Wed May 29, 2024 7:07 pm Post subject: |
|
|
Because this is not a systemd orOpenRC system:
| Code: | [ 2.428072] kbd_mode (92) used greatest stack depth: 13832 bytes left
[ 2.455288] loadkeys (93) used greatest stack depth: 13624 bytes left
[ 2.457404] init-early.sh (91) used greatest stack depth: 13536 bytes left
[ 2.961887] gendepends.sh (111) used greatest stack depth: 13528 bytes left
[ 3.559139] openrc-run.sh (434) used greatest stack depth: 13400 bytes left
[ 3.885176] udevadm (504) used greatest stack depth: 13008 bytes left |
I cannot help further ... (Kernel is okay) ... the last idea I would have is:
Some old thinkpad have a key (key combination) where you can switch off and on the screen ... what happens if you press it once ... or twice ?
If this is not the reason then there must be a problem with your init ... is it s6 ? (you see, I dont know s6)
_________________
https://wiki.gentoo.org/wiki/User:Pietinger |
|
| Back to top |
|
|
gord
n00b
Joined: 25 May 2024
Posts: 17
|
| Posted: Wed May 29, 2024 10:55 pm Post subject: |
|
|
| pietinger wrote: | Because this is not a systemd orOpenRC system:
|
I'm using OpenRC, I promise What is indicating otherwise?
That raises an interesting point, though. I've noticed that when using the distribution kernels, the modesetting seems to happen after the OpenRC log starts. Whereas in the custom kernels, it happens before the OpenRC log. This is the case both on the X201, where I just get a black screen and so never see anything related to OpenRC, and on the X61, where the KMS handover works, and the remaining kernel logs + full OpenRC logs are shown at full resolution in the DRM framebuffer. I had initially assumed it had something to do with delayed handover when using an initramfs, but it also persisted when I did a manual kernel compile based on the distribution kernel config file, but without dracut or providing initramfs info to the bootloader. Is there a kernel option that would cause that? I'm not sure it would explain this issue, since my config works as-is on the X61, but it would be interesting to understand.
| pietinger wrote: |
Some old thinkpad have a key (key combination) where you can switch off and on the screen ... what happens if you press it once ... or twice ?
|
I'm not sure I have that, unless you mean the secondary display swap button? Just tried that, with no results. The backlight/brightness controls do work though, and I'm able to see various different shades of black when using them... |
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 5109
Location: Bavaria
|
| Posted: Wed May 29, 2024 11:49 pm Post subject: |
|
|
| gord wrote: | | I'm using OpenRC, I promise What is indicating otherwise? |
I am using also OpenRC but these log entries are unknown for me ... maybe it is time to ask you for a "emerge --info" ... this also shows the used versions of various files and portage itself.
_________________
https://wiki.gentoo.org/wiki/User:Pietinger |
|
| Back to top |
|
|
gord
n00b
Joined: 25 May 2024
Posts: 17
|
|
| Back to top |
|
|
pingtoo
Veteran
Joined: 10 Sep 2021
Posts: 1248
Location: Richmond Hill, Canada
|
| Posted: Thu May 30, 2024 12:23 am Post subject: |
|
|
| pietinger wrote: | Because this is not a systemd orOpenRC system:
| Code: | [ 2.428072] kbd_mode (92) used greatest stack depth: 13832 bytes left
[ 2.455288] loadkeys (93) used greatest stack depth: 13624 bytes left
[ 2.457404] init-early.sh (91) used greatest stack depth: 13536 bytes left
[ 2.961887] gendepends.sh (111) used greatest stack depth: 13528 bytes left
[ 3.559139] openrc-run.sh (434) used greatest stack depth: 13400 bytes left
[ 3.885176] udevadm (504) used greatest stack depth: 13008 bytes left |
I cannot help further ... (Kernel is okay) ... the last idea I would have is:
Some old thinkpad have a key (key combination) where you can switch off and on the screen ... what happens if you press it once ... or twice ?
If this is not the reason then there must be a problem with your init ... is it s6 ? (you see, I dont know s6) |
I think this is because CONFIG_DEBUG_STACK_USAGE=y. See this in | github.com/torvalds/linux/kernel/exit.c#L744: | #ifdef CONFIG_DEBUG_STACK_USAGE
static void check_stack_usage(void)
{
static DEFINE_SPINLOCK(low_water_lock);
static int lowest_to_date = THREAD_SIZE;
unsigned long free;
free = stack_not_used(current);
if (free >= lowest_to_date)
return;
spin_lock(&low_water_lock);
if (free < lowest_to_date) {
pr_info("%s (%d) used greatest stack depth: %lu bytes left\n",
current->comm, task_pid_nr(current), free);
lowest_to_date = free;
}
spin_unlock(&low_water_lock);
}
#else
static inline void check_stack_usage(void) {}
#endif |
|
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 5109
Location: Bavaria
|
| Posted: Thu May 30, 2024 2:07 am Post subject: |
|
|
pingtoo,
Thank you ... that will be it ... I have found even more debug statements in the meantime ...
gord,
Your Gentoo system is state of the art ... good.
I dug deep (because the box is really very old; it is an old i7 first generation) and found the following recommendation:
Have you VT-d in your BIOS enabled ? If yes, please add these kernel command line parameter: intel_iommu=igfx_off acpi_backlight=video
If this does not help, try also (but I dont think it is really necessary):
| Code: | CONFIG_MTRR_SANITIZER=y
CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1 |
I dont think it is necessary but it does not hurt to enable it: CONFIG_INTEL_PMC_CORE
I am not a fan of most debug-options and I wrote this:
https://wiki.gentoo.org/wiki/User:Pietinger/Tutorials/Manual_kernel_configuration#CONFIG_DEBUG_.3F
_________________
https://wiki.gentoo.org/wiki/User:Pietinger |
|
| Back to top |
|
|
gord
n00b
Joined: 25 May 2024
Posts: 17
|
| Posted: Thu May 30, 2024 2:42 pm Post subject: |
|
|
| pietinger wrote: |
Have you VT-d in your BIOS enabled ?
|
Just checked, and no I don't.
I enabled the MTRR cleanup options, but no improvement. Same with INTEL_PMC_CORE, unfortunately.
Any more ideas? Do you think it's worth trying a reinstall to see if anything changes? (In particular, I'm now remembering that I switched filesystems from XFS to Ext4 at the last minute during the install, and rsync-ed the filesystem contents over to the current drive... I didn't think that should cause any problems, but maybe something odd happened there?
There's still also the possibility of fiddling with libdrm to see if the framebuffer and CRTC can be linked manually. Although even if it worked that wouldn't explain the underlying issue, which at this point I'm super-curious to track down! |
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 5109
Location: Bavaria
|
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 5109
Location: Bavaria
|
|
| Back to top |
|
|
gord
n00b
Joined: 25 May 2024
Posts: 17
|
| Posted: Thu May 30, 2024 5:31 pm Post subject: |
|
|
| pietinger wrote: |
Have you tried to set these kernel command line parameters anyway ?
|
Just tried, and no change.
I agree that trying different kernel versions makes sense. I'll start with 6.1 since I know that worked on Debian. I see that 6.1.90 is available in stable - is there a process for down-converting a .config from a newer kernel to an older one? |
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 5109
Location: Bavaria
|
|
| Back to top |
|
|
gord
n00b
Joined: 25 May 2024
Posts: 17
|
| Posted: Fri May 31, 2024 1:53 am Post subject: |
|
|
| pietinger wrote: |
I have never done that ... but theorethical it should be possible to use also "make oldconfig"
|
I wasn't sure if it was a one-way tool, but yes, just tried and can confirm it worked.
Not only that, but... v6.1.90 works!! Amazing!
| pietinger wrote: |
But, I would suggest to go the "other way" ... try the newest (6.9.3) ...  |
I'll try this next, for completeness. But regardless of the outcome, I wanted to share the good news.
Update: Seems like 6.9.3 doesn't work - interesting... Do we know for sure that the commit you linked is included in 6.9.3 (seems like it was committed very recently)? |
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 5109
Location: Bavaria
|
| Posted: Fri May 31, 2024 7:46 am Post subject: |
|
|
| gord wrote: | | Not only that, but... v6.1.90 works!! Amazing! |
Happy to hear that !
| gord wrote: | | Update: Seems like 6.9.3 doesn't work - interesting... Do we know for sure that the commit you linked is included in 6.9.3 (seems like it was committed very recently)? |
Yes, this is a patch included in 6.9.3. Sad, it doesnt work. If it works with 6.1.90 and it does not work with later versions then this is surely a kernel regression. You might file a kernel bug report ... but be aware they want surely that you bisect it.
Have fun with Gentoo ! 
_________________
https://wiki.gentoo.org/wiki/User:Pietinger |
|
| Back to top |
|
|
gord
n00b
Joined: 25 May 2024
Posts: 17
|
| Posted: Fri May 31, 2024 6:33 pm Post subject: |
|
|
| pietinger wrote: | | but be aware they want surely that you bisect it. |
What's the recomended approach for doing that in Gentoo? I see there aren't any gentoo-sources or vanilla-sources package versions between 6.1 and 6.6. Should I just clone the Git repository directly and compile from that? |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Installing Gentoo
