Bug#1000481: Bullseye kernel hangs while initialising i915 gpu driver on old intel graphic chip
On 10/28/22 15:27, Diederik de Haas wrote: On Friday, 28 October 2022 14:57:12 CEST Bogdan Veringioiu wrote: this issue affecting the LVDS connector was reported here: https://gitlab.freedesktop.org/drm/intel/-/issues/7301 and fixed. Any chance it will be backported in 5.10? https://lore.kernel.org/all/20221026101134.20865-1-ville.syrj...@linux.intel.com/ is where the changes have been submitted upstream. When that gets accepted by the upstream maintainer, then a request for a backport to the _upstream_ 5.10 kernel can be made and when done and accepted then it should land in Debian's 5.10 kernel too. Ben: it would be really great and interesting to know whether the patches would solve your issue too. Are you able to test that? Unfortunately I don't use this hardware anymore. But I could power it up once again, when the patches made it into the Debian kernel. Ben
Bug#1000481: Bullseye kernel hangs while initialising i915 gpu driver on old intel graphic chip
On Friday, 28 October 2022 14:57:12 CEST Bogdan Veringioiu wrote: > this issue affecting the LVDS connector was reported here: > > https://gitlab.freedesktop.org/drm/intel/-/issues/7301 > > and fixed. > > Any chance it will be backported in 5.10? https://lore.kernel.org/all/20221026101134.20865-1-ville.syrj...@linux.intel.com/ is where the changes have been submitted upstream. When that gets accepted by the upstream maintainer, then a request for a backport to the _upstream_ 5.10 kernel can be made and when done and accepted then it should land in Debian's 5.10 kernel too. Ben: it would be really great and interesting to know whether the patches would solve your issue too. Are you able to test that? signature.asc Description: This is a digitally signed message part.
Bug#1000481: Bullseye kernel hangs while initialising i915 gpu driver on old intel graphic chip
Hi this issue affecting the LVDS connector was reported here: https://gitlab.freedesktop.org/drm/intel/-/issues/7301 and fixed. Any chance it will be backported in 5.10? Thanks On 10.06.22 15:01, Bogdan Veringioiu wrote: Hi Diederik, thanks for answering. I am attaching dmesg, Xorg, xrandr output as well as a listing of /sys/class/drm directory of: - a buster install running kernel 4.19.98 which is working fine - a bullseye install running kernel 5.10.106 which is not working As mentioned intel_iommu parameter does not help me. After more tests, I understood what is happening under bullseye with 5.10 kernel. The built-in monitor of the POS PC is connected via LVDS. This LVDS connection is not detected/listed at all by the i915 driver upon initialization on boot and the screen goes blank. See the Xorg + xrand outputs. Under buster + kernel 4.19 it works perfectly. Additionaly (bullseye): If I hook an external VGA monitor using the VGA connector in the back of the POS PC, that monitor is detected and it is working fine, Xorg is using it as the main display. The built-in LVDS monitor remains blank, the LVDS connection is not listed. Regards Bogdan On 10.06.22 12:35, Diederik de Haas wrote: Control: found -1 linux/5.10.106-1 Control: found -1 linux/5.16.12-1~bpo11+1 On Friday, 10 June 2022 07:57:12 CEST Bogdan Veringioiu wrote: the bug is still exists in kernel version 5.10.106 (32 bit). Also tried a newer kernel linux-image-5.16.0-0.bpo.4 from bullseye-backports, with the same result. Thanks for that. Metadata updated accordingly. Symptoms: The monitor gets blank when the i915 changes resolution on boot. The PC remains accessible (ssh). That seems different from what Ben reported, which may be useful info. @Ben: can you tell whether you can ssh into your device or not? The intel_iommu=off does not work. Some details about the system below: $ dmesg | grep 915 [ 8.816308] i915 :00:02.0: vgaarb: deactivate vga console [ 8.846333] i915 :00:02.0: [drm] Failed to find VBIOS tables (VBT) When putting "i915 [drm] Failed to find VBIOS tables (VBT)" into a search engine, most results were about GPU passthrough (VMs). I don't see a (direct) connection with this bug, but thought I'd share this observation in case it might give a clue to others. [ 8.846882] i915 :00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=io+mem [ 9.116269] i915 :00:02.0: [drm] Initialized overlay support. [ 9.118527] [drm] Initialized i915 1.6.0 20200917 for :00:02.0 on minor 0 [ 9.163178] fbcon: i915drmfb (fb0) is primary device [ 9.203620] i915 :00:02.0: [drm] fb0: i915drmfb frame buffer device Request to both Bogdan and Ben: Can you share the full dmesg output of the 'failing' system and in case of a working workaround (like "intel_iommu=off"), also the dmesg output of that? The full dmesg output may contain clues as to why this issue occurs.
Bug#1000481: Bullseye kernel hangs while initialising i915 gpu driver on old intel graphic chip
Control: found -1 linux/5.10.113-1 On 6/10/22 12:35, Diederik de Haas wrote: > On Friday, 10 June 2022 07:57:12 CEST Bogdan Veringioiu wrote: > >> Symptoms: >> The monitor gets blank when the i915 changes resolution on boot. >> The PC remains accessible (ssh). > > That seems different from what Ben reported, which may be useful info. > @Ben: can you tell whether you can ssh into your device or not? In my case the machine stops booting at a very early stage. I tried it again with the current kernel in bullseye (5.10.0-14-amd64 #1 SMP Debian 5.10.113-1 (2022-04-29) x86_64 GNU/Linux). I cannot access the system even not with ssh, there are no logfiles written and I have no dmesg output. With "intel_iommu=off" it still boots fine. You'll find the output of dmesg attached. Thanks! Ben[0.00] Linux version 5.10.0-14-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.113-1 (2022-04-29) [0.00] Command line: BOOT_IMAGE=/vmlinuz-5.10.0-14-amd64 root=/dev/mapper/rappel-root ro intel_iommu=off quiet [0.00] x86/fpu: x87 FPU will use FXSAVE [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009d7ff] usable [0.00] BIOS-e820: [mem 0x0009d800-0x0009] reserved [0.00] BIOS-e820: [mem 0x000ce000-0x000c] reserved [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0xdf4b] usable [0.00] BIOS-e820: [mem 0xdf4c-0xdf4c9fff] ACPI data [0.00] BIOS-e820: [mem 0xdf4ca000-0xdf4cafff] ACPI NVS [0.00] BIOS-e820: [mem 0xdf4cb000-0xdf5f] reserved [0.00] BIOS-e820: [mem 0xdf80-0xe01f] reserved [0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved [0.00] BIOS-e820: [mem 0xfec0-0xfec0] reserved [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved [0.00] BIOS-e820: [mem 0xffb0-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x00011bff] usable [0.00] NX (Execute Disable) protection: active [0.00] SMBIOS 2.5 present. [0.00] DMI: FUJITSU SIEMENS ESPRIMO P5925 /D2584-A1, BIOS 6.00 R1.05.2584.A1 10/10/2007 [0.00] tsc: Fast TSC calibration using PIT [0.00] tsc: Detected 1861.825 MHz processor [0.002445] e820: update [mem 0x-0x0fff] usable ==> reserved [0.002451] e820: remove [mem 0x000a-0x000f] usable [0.002461] last_pfn = 0x11c000 max_arch_pfn = 0x4 [0.002469] MTRR default type: uncachable [0.002470] MTRR fixed ranges enabled: [0.002473] 0-9 write-back [0.002475] A-B uncachable [0.002476] C-C7FFF write-protect [0.002478] C8000-D uncachable [0.002480] E-F write-protect [0.002481] MTRR variable ranges enabled: [0.002484] 0 base 0E000 mask FE000 uncachable [0.002486] 1 base 11C00 mask FFC00 uncachable [0.002489] 2 base 0 mask F write-back [0.002491] 3 base 1 mask FE000 write-back [0.002493] 4 base 0DF50 mask 0 uncachable [0.002494] 5 base 0DF60 mask FFFE0 uncachable [0.002496] 6 base 0DF80 mask FFF80 uncachable [0.002498] 7 disabled [0.003307] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WP UC- WT [0.003543] e820: update [mem 0xdf50-0x] usable ==> reserved [0.003552] last_pfn = 0xdf4c0 max_arch_pfn = 0x4 [0.013728] found SMP MP-table at [mem 0x000f73a0-0x000f73af] [0.020841] RAMDISK: [mem 0x3215-0x3509] [0.020846] ACPI: Early table checksum verification disabled [0.020851] ACPI: RSDP 0x000F72A0 14 (v00 PTLTD ) [0.020857] ACPI: RSDT 0xDF4C4B5D 5C (v01 FSCPC 0006 LTP ) [0.020867] ACPI: FACP 0xDF4C98B5 74 (v01 FSC 0006 000F4240) [0.020876] ACPI: DSDT 0xDF4C4BB9 004CFC (v01 FSCD2584/A1 0006 MSFT 0301) [0.020882] ACPI: FACS 0xDF4CAFC0 40 [0.020888] ACPI: TCPA 0xDF4C9929 32 (v01 Phoeni x 0006 TL ) [0.020895] ACPI: DMAR 0xDF4C995B F8 (v01 Intel OEMDMAR 0006 LOHR 0001) [0.020901] ACPI: SSDT 0xDF4C9A53 7A (v01 FSCCST_CPU0 0006 CSF 0001) [0.020907] ACPI: SSDT 0xDF4C9ACD 7A (v01 FSCCST_CPU1 0006 CSF 0001) [0.020913] ACPI: SSDT 0xDF4C9B47 B6 (v01 FSCPST_CPU0 0006 CSF 0001) [0.020920] ACPI: SSDT 0xDF4C9BFD B6 (v01 FSCPST_CPU1 00
Bug#1000481: Bullseye kernel hangs while initialising i915 gpu driver on old intel graphic chip
Control: found -1 linux/5.10.106-1 Control: found -1 linux/5.16.12-1~bpo11+1 On Friday, 10 June 2022 07:57:12 CEST Bogdan Veringioiu wrote: > the bug is still exists in kernel version 5.10.106 (32 bit). > > Also tried a newer kernel linux-image-5.16.0-0.bpo.4 from > bullseye-backports, with the same result. Thanks for that. Metadata updated accordingly. > Symptoms: > The monitor gets blank when the i915 changes resolution on boot. > The PC remains accessible (ssh). That seems different from what Ben reported, which may be useful info. @Ben: can you tell whether you can ssh into your device or not? > The intel_iommu=off does not work. > > Some details about the system below: > > $ dmesg | grep 915 > > [8.816308] i915 :00:02.0: vgaarb: deactivate vga console > [8.846333] i915 :00:02.0: [drm] Failed to find VBIOS tables (VBT) When putting "i915 [drm] Failed to find VBIOS tables (VBT)" into a search engine, most results were about GPU passthrough (VMs). I don't see a (direct) connection with this bug, but thought I'd share this observation in case it might give a clue to others. > [8.846882] i915 :00:02.0: vgaarb: changed VGA decodes: > olddecodes=io+mem,decodes=io+mem:owns=io+mem > [9.116269] i915 :00:02.0: [drm] Initialized overlay support. > [9.118527] [drm] Initialized i915 1.6.0 20200917 for :00:02.0 on > minor 0 > [9.163178] fbcon: i915drmfb (fb0) is primary device > [9.203620] i915 :00:02.0: [drm] fb0: i915drmfb frame buffer device Request to both Bogdan and Ben: Can you share the full dmesg output of the 'failing' system and in case of a working workaround (like "intel_iommu=off"), also the dmesg output of that? The full dmesg output may contain clues as to why this issue occurs. signature.asc Description: This is a digitally signed message part.
