linux-6.9.4 or firmware broke monitor type/size detection for Dell box?
Devs, Tonight's update to linux-6.9.4 and the firmware seems to have broken the monitor type/size detection on Arch. I have a older Dell box I use for a media center connected to a Samsung 59" TV. Arch has always properly detected it and configured itself for full HD resolution. After update tonight, it no longer does that. Instead both the console (I use startx) and fluxbox (or any other desktop) boots and starts at 800x600 or so -- which is quite unusable. Has something changed in the kernel image generation or in the new firmware that has caused this? I'm not sure what the dmesg output was before, it always just worked, but now I get: [ 1.574525] i915 0000:00:02.0: vgaarb: deactivate vga console [ 1.600709] tsc: Refined TSC clocksource calibration: 3324.978 MHz [ 1.600721] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x2fed77ea564, max_idle_ns: 440795278175 ns [ 1.600739] clocksource: Switched to clocksource tsc [ 1.608956] sr 3:0:0:0: [sr0] scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw xa/form2 cdda tray [ 1.608963] cdrom: Uniform CD-ROM driver Revision: 3.20 [ 1.609861] i915 0000:00:02.0: [drm] Initialized overlay support. [ 1.610256] [drm] Initialized i915 1.6.0 20230929 for 0000:00:02.0 on minor 1 [ 1.630543] fbcon: i915drmfb (fb0) is primary device [ 1.630545] fbcon: Deferring console take-over [ 1.630547] i915 0000:00:02.0: [drm] fb0: i915drmfb frame buffer device This box is grub2/MBR, so if something changed there, that may also be the issue. Anybody have an idea what changed? -- David C. Rankin, J.D.,P.E.
On 24/06/12 11:52PM, David C. Rankin wrote:
Devs,
Hello David,
Tonight's update to linux-6.9.4 and the firmware seems to have broken the monitor type/size detection on Arch. I have a older Dell box I use for a media center connected to a Samsung 59" TV. Arch has always properly detected it and configured itself for full HD resolution.
After update tonight, it no longer does that. Instead both the console (I use startx) and fluxbox (or any other desktop) boots and starts at 800x600 or so -- which is quite unusable.
Has something changed in the kernel image generation or in the new firmware that has caused this?
Well the kernel has a different source with each release, so of course both updated could have caused something like this.
I'm not sure what the dmesg output was before, it always just worked, but now I get:
[ 1.574525] i915 0000:00:02.0: vgaarb: deactivate vga console [ 1.600709] tsc: Refined TSC clocksource calibration: 3324.978 MHz [ 1.600721] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x2fed77ea564, max_idle_ns: 440795278175 ns [ 1.600739] clocksource: Switched to clocksource tsc [ 1.608956] sr 3:0:0:0: [sr0] scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw xa/form2 cdda tray [ 1.608963] cdrom: Uniform CD-ROM driver Revision: 3.20 [ 1.609861] i915 0000:00:02.0: [drm] Initialized overlay support. [ 1.610256] [drm] Initialized i915 1.6.0 20230929 for 0000:00:02.0 on minor 1 [ 1.630543] fbcon: i915drmfb (fb0) is primary device [ 1.630545] fbcon: Deferring console take-over [ 1.630547] i915 0000:00:02.0: [drm] fb0: i915drmfb frame buffer device
Did you already have a chance to see if downgrading the linux package helps? You can get a older version from [here][0]: sudo pacman -U https://archive.archlinux.org/packages/l/linux/linux-6.9.3.arch1-1-x86_64.pk... Then please also share the full logs ;) Cheers, gromit [0]: https://archive.archlinux.org/packages/l/linux/
On 6/13/24 05:00, Christian Heusel wrote:
Did you already have a chance to see if downgrading the linux package helps? You can get a older version from [here][0]:
sudo pacman -Uhttps://archive.archlinux.org/packages/l/linux/linux-6.9.3.arch1-1-x86_64.pk...
Then please also share the full logs ;)
Thank you Christian! Just downgraded to 6.9.3 and the display comes up full-HD 1920x1080 at console and in X. So it is definitely 6.9.4. Which logs? I have dmesg from each kernel, but at least by my eyes they are pretty much identical, nothing stands out related to any display driver or framebuffer mode. I'm happy to compress and attach them, but it should probably go in a bug report as the list will likely strip attachments. Let me know what logs you want to see and where you want me to put them and I'll be happy to get them. There is no question, there is something that changed in the 6.9.4 kernel update that changed monitor/resolution detection and which is selected on boot. Let me know what logs and I'll get them to you. Happy to e-mail logs off list as well if that will help. -- David C. Rankin, J.D.,P.E.
On 24/06/13 03:38PM, David C. Rankin wrote:
On 6/13/24 05:00, Christian Heusel wrote:
Did you already have a chance to see if downgrading the linux package helps? You can get a older version from [here][0]:
sudo pacman -Uhttps://archive.archlinux.org/packages/l/linux/linux-6.9.3.arch1-1-x86_64.pk...
Then please also share the full logs ;)
Thank you Christian!
Just downgraded to 6.9.3 and the display comes up full-HD 1920x1080 at console and in X. So it is definitely 6.9.4.
Huh, this is interesting 🤔 This could possibly be a regression within the stable series ... Could you please open a bugreport on the [linux package][0] so we could debug the issue together there? Most likely one of the backported bugfixes that was applied to the stable series had some unexpected sideeffects. There are a few display related commits, but I'm struggling to point anything out directly. I'd say we try to bisect the issue down to the relevant commit so we can report this behaviour to the linux kernel devs 😅
Which logs? I have dmesg from each kernel, but at least by my eyes they are pretty much identical, nothing stands out related to any display driver or framebuffer mode.
I'm happy to compress and attach them, but it should probably go in a bug report as the list will likely strip attachments.
Let me know what logs you want to see and where you want me to put them and I'll be happy to get them.
Yes, I'd say linking them on [some pastebin][1] would also be good! But if you open a bugreport you can also just attach the files there 🤗 Cheers, gromit [0]: https://gitlab.archlinux.org/archlinux/packaging/packages/linux/-/issues/new [1]: https://wiki.archlinux.org/title/Arch_IRC_channels#Collaborative_debugging
On 6/13/24 16:15, Christian Heusel wrote:
Yes, I'd say linking them on [some pastebin][1] would also be good! But if you open a bugreport you can also just attach the files there 🤗
Cheers, gromit
[0]:https://gitlab.archlinux.org/archlinux/packaging/packages/linux/-/issues/new [1]:https://wiki.archlinux.org/title/Arch_IRC_channels#Collaborative_debugging
Will open it this evening. Thank you! -- David C. Rankin, J.D.,P.E.
Hi,
There is no question, there is something that changed in the 6.9.4 kernel update that changed monitor/resolution detection and which is selected on boot. Let me know what logs and I'll get them to you. Happy to e-mail logs off list as well if that will help.
Maybe you can bisect with https://wiki.archlinux.org/title/Modprobed-db which caused the issue? Regards Bjoern
On 6/13/24 05:00, Christian Heusel wrote:
Then please also share the full logs ;)
Looking at the Xorg.0.log for both 6.9.3 and 6.9.4 kernels, it is clear the 6.9.3 log selects the correct 1920x1080 resolution while the 6.9.4 kernel selects 1024x768. This is what is happening for the console and for X. The snippet from the 6.9.3 Xorg.0.log is: [ 1035.029] (--) intel(0): Integrated Graphics Chipset: Intel(R) G33 [ 1035.029] (--) intel(0): CPU: x86-64, sse2, sse3, ssse3, sse4.1; using a maximum of 2 threads [ 1035.029] (II) intel(0): Creating default Display subsection in Screen section "Default Screen Section" for depth/fbbpp 24/32 [ 1035.029] (==) intel(0): Depth 24, (--) framebuffer bpp 32 [ 1035.029] (==) intel(0): RGB weight 888 [ 1035.029] (==) intel(0): Default visual is TrueColor [ 1035.029] (II) intel(0): Output VGA1 has no monitor section [ 1035.030] (II) intel(0): Enabled output VGA1 [ 1035.030] (--) intel(0): Using a maximum size of 256x256 for hardware cursors [ 1035.030] (II) intel(0): Output VIRTUAL1 has no monitor section [ 1035.030] (II) intel(0): Enabled output VIRTUAL1 [ 1035.030] (--) intel(0): Output VGA1 using initial mode 1920x1080 on pipe 0 ... [ 1035.285] (II) intel(0): switch to mode 1920x1080@60.0 on VGA1 using pipe 0, position (0, 0), rotation normal, reflection none [ 1035.296] (II) intel(0): Setting screen physical size to 508 x 285 After update to 6.9.4 that becomes: [ 5371.538] (--) intel(0): Integrated Graphics Chipset: Intel(R) G33 [ 5371.538] (--) intel(0): CPU: x86-64, sse2, sse3, ssse3, sse4.1; using a maximum of 2 threads [ 5371.538] (II) intel(0): Creating default Display subsection in Screen section "Default Screen Section" for depth/fbbpp 24/32 [ 5371.539] (==) intel(0): Depth 24, (--) framebuffer bpp 32 [ 5371.539] (==) intel(0): RGB weight 888 [ 5371.539] (==) intel(0): Default visual is TrueColor [ 5371.539] (II) intel(0): Output VGA1 has no monitor section [ 5371.539] (II) intel(0): Enabled output VGA1 [ 5371.539] (--) intel(0): Using a maximum size of 256x256 for hardware cursors [ 5371.539] (II) intel(0): Output VIRTUAL1 has no monitor section [ 5371.539] (II) intel(0): Enabled output VIRTUAL1 [ 5371.539] (--) intel(0): Output VGA1 using initial mode 1024x768 on pipe 0 ... [ 5371.571] (II) intel(0): switch to mode 1024x768@75.0 on VGA1 using pipe 0, position (0, 0), rotation normal, reflection none [ 5371.576] (II) intel(0): Setting screen physical size to 270 x 203 All lines in between the '...' are the same. In fact the rest of the Xorg.0.log files are the same other than the file names, session numbers and kernel versions and shutdown from the 6.9.4 log, e.g. $ diff -uNb <(sed 's/^.............//' 6.9.3-Xorg.0.log) <(sed 's/^.............//' 6.9.4-Xorg.0.log) No remarkable difference other than the resolutions chosen. Let me know what other log info you want and I'm happy to get it. -- David C. Rankin, J.D.,P.E.
On Thu, 13 Jun 2024 16:12:36 -0500 "David C. Rankin" <drankinatty@gmail.com> wrote:
On 6/13/24 05:00, Christian Heusel wrote:
Then please also share the full logs ;)
Looking at the Xorg.0.log for both 6.9.3 and 6.9.4 kernels, it is clear the 6.9.3 log selects the correct 1920x1080 resolution while the 6.9.4 kernel selects 1024x768. This is what is happening for the console and for X.
The snippet from the 6.9.3 Xorg.0.log is:
[snip]
[ 1035.285] (II) intel(0): switch to mode 1920x1080@60.0 on VGA1 using pipe 0, position (0, 0), rotation normal, reflection none [ 1035.296] (II) intel(0): Setting screen physical size to 508 x 285
After update to 6.9.4 that becomes:
[snip]
[ 5371.571] (II) intel(0): switch to mode 1024x768@75.0 on VGA1 using pipe 0, position (0, 0), rotation normal, reflection none [ 5371.576] (II) intel(0): Setting screen physical size to 270 x 203 [snip] /^.............//' 6.9.4-Xorg.0.log)
No remarkable difference other than the resolutions chosen.
The physical screen size (and implied aspect ratio) is also very different. Is either correct?
Well David-and-All, even though I switched back to Debian, I am running 6.9.4 from Zabbly. So I rebooted, have not noticed any changes. Out of the box I am getting 67by240, but I run an Lat15 to double an amount of lines to 135. I am also totally blind, so just going by a text console. Chime
I too have no issues with 6.9.4 (including laptops, monitors and an older TV) so its quite possible the issue David has is hardware specific. 1) Perhaps its useful to compare what edid your monitors provide using 6.9.3 and 6.9.4 kernels. To do so, one way is to build the edid-decode-git package from the aur which provides edid-decode. (I have not had much success with get- edid/parse-edid tools). Find edid device(s): find /sys/devices -iname edid Which should list them for example like: /sys/devices/pci0000:00/0000:00:02.0/drm/card1/card1-eDP-1/edid Then you can read/parse the edid info: edid-decode < /sys/devices/pci0000:00/0000:00:02.0/drm/card1/card1- eDP-1/edid Perhap comparing the outputs on 6.9.4 vs 6.9.3 might be helpful. 2) I also did a quick git log check on kernel changes between 6.9.3 and 6.9.4 and there are a few graphics related ones - nothing jumped out at me but perhaps it may to others. Course other code changes than drm may well be involved. * drm/panel: sitronix-st7789v: fix display size for jt240mhqs_hwt_ek_e3 panel * drm/panel: sitronix-st7789v: tweak timing for jt240mhqs_hwt_ek_e3 panel * drm/panel: sitronix-st7789v: fix timing for jt240mhqs_hwt_ek_e3 panel * drm/amdgpu: Adjust logic in amdgpu_device_partner_bandwidth() * drm/i915/gt: Fix CCS id's calculation for CCS mode setting * drm/i915/guc: avoid FIELD_PREP warning * drm/xe: Only use reserved BCS instances for usm migrate exec queue * drm/xe: Change pcode timeout to 50msec while polling again * drm/xe: check pcode init status only on root gt of root tile * drm/xe: Add dbg messages on the suspend resume functions. * drm/amd/display: Enable colorspace property for MST connectors * drm/msm/a6xx: Avoid a nullptr dereference when speedbin setting fails * drm/msm/adreno: fix CP cycles stat retrieval on a7xx * drm: zynqmp_dpsub: Always register bridge * Revert "drm/bridge: ti-sn65dsi83: Fix enable error path" * drm/amdgpu: Fix buffer size in gfx_v9_4_3_init_ cp_compute_microcode() and rlc_microcode() * drm/amdgpu: init microcode chip name from ip versions * drm/bridge: imx: Fix unmet depenency for PHY_FSL_SAMSUNG_HDMI_PHY * drm: Make drivers depends on DRM_DW_HDMI * drm/bridge: tc358775: fix support for jeida-18 and jeida-24 * drm/msm/dpu: Add callback function pointer check before its call * drm/meson: gate px_clk when setting rate * drm/mediatek: dp: Fix mtk_dp_aux_transfer return value * drm/msm/dpu: Allow configuring multiple active DSC blocks * drm/msm/dpu: Always flush the slave INTF on the CTL * drm/msm/dsi: Print dual-DSI-adjusted pclk instead of original mode pclk -- Gene
If dkms has anything to do with monitors, last kernel that supported dkms was 6.80 so dkms likely isn't working now. Good excuse to remove those packages and find other ways to accommodate hardware. I found this out after installing kernel 6.94 a couple days ago. -- Jude <jdashiel at panix dot com> "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." Ed Howdershelt 1940. On Fri, 14 Jun 2024, Genes Lists wrote:
I too have no issues with 6.9.4 (including laptops, monitors and an older TV) so its quite possible the issue David has is hardware specific.
1) Perhaps its useful to compare what edid your monitors provide using 6.9.3 and 6.9.4 kernels.
To do so, one way is to build the edid-decode-git package from the aur which provides edid-decode. (I have not had much success with get- edid/parse-edid tools).
Find edid device(s):
find /sys/devices -iname edid
Which should list them for example like:
/sys/devices/pci0000:00/0000:00:02.0/drm/card1/card1-eDP-1/edid
Then you can read/parse the edid info:
edid-decode < /sys/devices/pci0000:00/0000:00:02.0/drm/card1/card1- eDP-1/edid
Perhap comparing the outputs on 6.9.4 vs 6.9.3 might be helpful.
2) I also did a quick git log check on kernel changes between 6.9.3 and 6.9.4 and there are a few graphics related ones - nothing jumped out at me but perhaps it may to others. Course other code changes than drm may well be involved.
* drm/panel: sitronix-st7789v: fix display size for jt240mhqs_hwt_ek_e3 panel * drm/panel: sitronix-st7789v: tweak timing for jt240mhqs_hwt_ek_e3 panel * drm/panel: sitronix-st7789v: fix timing for jt240mhqs_hwt_ek_e3 panel * drm/amdgpu: Adjust logic in amdgpu_device_partner_bandwidth() * drm/i915/gt: Fix CCS id's calculation for CCS mode setting * drm/i915/guc: avoid FIELD_PREP warning * drm/xe: Only use reserved BCS instances for usm migrate exec queue * drm/xe: Change pcode timeout to 50msec while polling again * drm/xe: check pcode init status only on root gt of root tile * drm/xe: Add dbg messages on the suspend resume functions. * drm/amd/display: Enable colorspace property for MST connectors * drm/msm/a6xx: Avoid a nullptr dereference when speedbin setting fails * drm/msm/adreno: fix CP cycles stat retrieval on a7xx * drm: zynqmp_dpsub: Always register bridge * Revert "drm/bridge: ti-sn65dsi83: Fix enable error path" * drm/amdgpu: Fix buffer size in gfx_v9_4_3_init_ cp_compute_microcode() and rlc_microcode() * drm/amdgpu: init microcode chip name from ip versions * drm/bridge: imx: Fix unmet depenency for PHY_FSL_SAMSUNG_HDMI_PHY * drm: Make drivers depends on DRM_DW_HDMI * drm/bridge: tc358775: fix support for jeida-18 and jeida-24 * drm/msm/dpu: Add callback function pointer check before its call * drm/meson: gate px_clk when setting rate * drm/mediatek: dp: Fix mtk_dp_aux_transfer return value * drm/msm/dpu: Allow configuring multiple active DSC blocks * drm/msm/dpu: Always flush the slave INTF on the CTL * drm/msm/dsi: Print dual-DSI-adjusted pclk instead of original mode pclk
On 6/14/24 07:39, Chime Hart wrote:
Well David-and-All, even though I switched back to Debian, I am running 6.9.4 from Zabbly. So I rebooted, have not noticed any changes. Out of the box I am getting 67by240, but I run an Lat15 to double an amount of lines to 135. I am also totally blind, so just going by a text console. Chime
Wow Chime, I'm impressed with the way you read the list. God love technology. An auto-braille of sorts. That's cool. The issue has been identified as an issue triggered by the virtualbox 7.0.18 driver (installed from PUEL - virtualbox-bin AUR package) Christian caught the driver taint and I blacklisted the driver and tried 6.9.4 again -- and it correctly detected the resolution again. The bug has been moved from Arch to Oracle: https://www.virtualbox.org/ticket/22098 I've used this same box with virtualbox since Jan. 8, 2017, and have never seen this issue before. There is apparently a regression somewhere, but since it appears to be triggered by the virtualbox driver, we will work it from that side. -- David C. Rankin, J.D.,P.E.
On 6/14/24 03:54, Dave Howorth wrote:
[snip]
[ 1035.285] (II) intel(0): switch to mode1920x1080@60.0 on VGA1 using pipe 0, position (0, 0), rotation normal, reflection none [ 1035.296] (II) intel(0): Setting screen physical size to 508 x 285
After update to 6.9.4 that becomes:
[snip]
[ 5371.571] (II) intel(0): switch to mode1024x768@75.0 on VGA1 using pipe 0, position (0, 0), rotation normal, reflection none [ 5371.576] (II) intel(0): Setting screen physical size to 270 x 203 [snip] /^.............//' 6.9.4-Xorg.0.log)
No remarkable difference other than the resolutions chosen. The physical screen size (and implied aspect ratio) is also very different. Is either correct?
Yes, the 6.9.3 kernel gets it right. Every other kernel since arch was installed on 1/8/17 has gotten it right. Something in 6.9.4 seems to have changed. Likely an unintended side effect of some other change. Bug opened: https://gitlab.archlinux.org/archlinux/packaging/packages/linux/-/issues/62 -- David C. Rankin, J.D.,P.E.
participants (7)
-
Bjoern Franke
-
Chime Hart
-
Christian Heusel
-
Dave Howorth
-
David C. Rankin
-
Genes Lists
-
Jude DaShiell