Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#1000481: upgrade-reports: Bullseye kernel hangs while initialising i915 gpu driver on old intel graphic chip
544 views
Skip to first unread message
Ben Mueller
Nov 23, 2021, 5:00:04 PM11/23/21
to
Package: upgrade-reports
Severity: normal
X-Debbugs-Cc: lett...@internix.de
My previous release is: Buster
I am upgrading to: Bullseye
Archive date: ?
Upgrade date: 2021-11-21
uname -a before upgrade: (kernel: linux-image-4.19.0-18-amd64 4.19.208-1)
uname -a after upgrade: Linux rappel 5.10.0-9-amd64 #1 SMP Debian 5.10.70-1 (2021-09-30) x86_64 GNU/Linux
Method: apt
Contents of /etc/apt/sources.list:
deb http://ftp.de.debian.org/debian/ bullseye main contrib non-free
deb-src http://ftp.de.debian.org/debian/ bullseye main
deb http://security.debian.org/debian-security bullseye-security main contrib non-free
deb-src http://security.debian.org/debian-security bullseye-security main
deb http://ftp.de.debian.org/debian/ bullseye-updates main contrib non-free
deb-src http://ftp.de.debian.org/debian/ bullseye-updates main
Further Comments/Problems:
The update went fine without errors. But booting with the new kernel did
not work. The display went black shortly after loading the new kernel. I
think it was the moment when it normally changes the display resolution.
The boot process did not continue. Keyboard and mouse were not functioning.
I had to hard switch off the computer. There were no logs written to disk.
Fortunately my old kernel linux-image-4.19.0-18-amd64 was still able to
boot.
I solved the problem by inserting a boot parameter "intel_iommu=off" to
grub. With this parameter the kernel from bullseye
linux-image-5.10.0-9-amd64 was able to boot properly and the graphic was
fine on console and with x. The kernel from buster did not need this
boot parameter.
I think the problem is, that the i915 gpu driver has difficulties to
initialise my old intel graphic chip. According to lspci it is:
00:02.0 VGA compatible controller: Intel Corporation 82Q35 Express Integrated Graphics Controller (rev 02) (prog-if 00 [VGA controller])
Subsystem: Fujitsu Technology Solutions 82Q35 Express Integrated Graphics Controller
Flags: bus master, fast devsel, latency 0, IRQ 16
Memory at f0200000 (32-bit, non-prefetchable) [size=512K]
I/O ports at 1c70 [size=8]
Memory at e0000000 (32-bit, prefetchable) [size=256M]
Memory at f0000000 (32-bit, non-prefetchable) [size=1M]
Expansion ROM at 000c0000 [virtual] [disabled] [size=128K]
Capabilities: <access denied>
Kernel driver in use: i915
Kernel modules: i915
I hope this report will be useful to other people trying to run the
bullseye kernel on old intel hardware.
Severity: normal
X-Debbugs-Cc: lett...@internix.de
My previous release is: Buster
I am upgrading to: Bullseye
Archive date: ?
Upgrade date: 2021-11-21
uname -a before upgrade: (kernel: linux-image-4.19.0-18-amd64 4.19.208-1)
uname -a after upgrade: Linux rappel 5.10.0-9-amd64 #1 SMP Debian 5.10.70-1 (2021-09-30) x86_64 GNU/Linux
Method: apt
Contents of /etc/apt/sources.list:
deb http://ftp.de.debian.org/debian/ bullseye main contrib non-free
deb-src http://ftp.de.debian.org/debian/ bullseye main
deb http://security.debian.org/debian-security bullseye-security main contrib non-free
deb-src http://security.debian.org/debian-security bullseye-security main
deb http://ftp.de.debian.org/debian/ bullseye-updates main contrib non-free
deb-src http://ftp.de.debian.org/debian/ bullseye-updates main
Further Comments/Problems:
The update went fine without errors. But booting with the new kernel did
not work. The display went black shortly after loading the new kernel. I
think it was the moment when it normally changes the display resolution.
The boot process did not continue. Keyboard and mouse were not functioning.
I had to hard switch off the computer. There were no logs written to disk.
Fortunately my old kernel linux-image-4.19.0-18-amd64 was still able to
boot.
I solved the problem by inserting a boot parameter "intel_iommu=off" to
grub. With this parameter the kernel from bullseye
linux-image-5.10.0-9-amd64 was able to boot properly and the graphic was
fine on console and with x. The kernel from buster did not need this
boot parameter.
I think the problem is, that the i915 gpu driver has difficulties to
initialise my old intel graphic chip. According to lspci it is:
00:02.0 VGA compatible controller: Intel Corporation 82Q35 Express Integrated Graphics Controller (rev 02) (prog-if 00 [VGA controller])
Subsystem: Fujitsu Technology Solutions 82Q35 Express Integrated Graphics Controller
Flags: bus master, fast devsel, latency 0, IRQ 16
Memory at f0200000 (32-bit, non-prefetchable) [size=512K]
I/O ports at 1c70 [size=8]
Memory at e0000000 (32-bit, prefetchable) [size=256M]
Memory at f0000000 (32-bit, non-prefetchable) [size=1M]
Expansion ROM at 000c0000 [virtual] [disabled] [size=128K]
Capabilities: <access denied>
Kernel driver in use: i915
Kernel modules: i915
I hope this report will be useful to other people trying to run the
bullseye kernel on old intel hardware.
Paul Gevers
Dec 23, 2021, 3:10:04 PM12/23/21
to
Hi Ben,
Sorry it took so long to get back to you.
On 23-11-2021 22:46, Ben Mueller wrote:
> Further Comments/Problems:
> The update went fine without errors. But booting with the new kernel did
> not work. The display went black shortly after loading the new kernel. I
> think it was the moment when it normally changes the display resolution.
> The boot process did not continue. Keyboard and mouse were not functioning.
> I had to hard switch off the computer. There were no logs written to disk.
> Fortunately my old kernel linux-image-4.19.0-18-amd64 was still able to
> boot.
>
> I solved the problem by inserting a boot parameter "intel_iommu=off" to
> grub. With this parameter the kernel from bullseye
> linux-image-5.10.0-9-amd64 was able to boot properly and the graphic was
> fine on console and with x. The kernel from buster did not need this
> boot parameter.
>
> I think the problem is, that the i915 gpu driver has difficulties to
> initialise my old intel graphic chip. According to lspci it is:
Which package has the driver you're using? I propose we reassign this
package to that package for further investigation.
Paul
Sorry it took so long to get back to you.
On 23-11-2021 22:46, Ben Mueller wrote:
> Further Comments/Problems:
> The update went fine without errors. But booting with the new kernel did
> not work. The display went black shortly after loading the new kernel. I
> think it was the moment when it normally changes the display resolution.
> The boot process did not continue. Keyboard and mouse were not functioning.
> I had to hard switch off the computer. There were no logs written to disk.
> Fortunately my old kernel linux-image-4.19.0-18-amd64 was still able to
> boot.
>
> I solved the problem by inserting a boot parameter "intel_iommu=off" to
> grub. With this parameter the kernel from bullseye
> linux-image-5.10.0-9-amd64 was able to boot properly and the graphic was
> fine on console and with x. The kernel from buster did not need this
> boot parameter.
>
> I think the problem is, that the i915 gpu driver has difficulties to
> initialise my old intel graphic chip. According to lspci it is:
package to that package for further investigation.
Paul
Ben Mueller
Dec 23, 2021, 6:00:05 PM12/23/21
to
Hi Paul,
On 12/23/21 9:05 PM, Paul Gevers wrote:
> Sorry it took so long to get back to you.
I'm fine. I found a solution that works for me.
>> I solved the problem by inserting a boot parameter "intel_iommu=off" to
>> grub. With this parameter the kernel from bullseye
>> linux-image-5.10.0-9-amd64 was able to boot properly and the graphic was
>> fine on console and with x. The kernel from buster did not need this
>> boot parameter.
>
I first saw the problem with version 5.10.70-1
(linux-image-5.10.0-9-amd64). Now I'm using version 5.10.84-1
(linux-image-5.10.0-10-amd64) which also works fine using the boot
parameter "intel_iommu=off". Although I did not try this version in the
default configuration without this boot parameter.
Ben
On 12/23/21 9:05 PM, Paul Gevers wrote:
> Sorry it took so long to get back to you.
>> I solved the problem by inserting a boot parameter "intel_iommu=off" to
>> grub. With this parameter the kernel from bullseye
>> linux-image-5.10.0-9-amd64 was able to boot properly and the graphic was
>> fine on console and with x. The kernel from buster did not need this
>> boot parameter.
>
> Which package has the driver you're using? I propose we reassign this
> package to that package for further investigation.
The i915 gpu driver belongs to the kernel: linux-image-amd64.
> package to that package for further investigation.
I first saw the problem with version 5.10.70-1
(linux-image-5.10.0-9-amd64). Now I'm using version 5.10.84-1
(linux-image-5.10.0-10-amd64) which also works fine using the boot
parameter "intel_iommu=off". Although I did not try this version in the
default configuration without this boot parameter.
Ben
Paul Gevers
Dec 24, 2021, 1:40:03 AM12/24/21
to
Control: reassign -1 src:linux 5.10.70-1
Hi Ben,
On 23-12-2021 23:46, Ben Mueller wrote:
> On 12/23/21 9:05 PM, Paul Gevers wrote:
>>> I solved the problem by inserting a boot parameter "intel_iommu=off" to
>>> grub. With this parameter the kernel from bullseye
>>> linux-image-5.10.0-9-amd64 was able to boot properly and the graphic was
>>> fine on console and with x. The kernel from buster did not need this
>>> boot parameter.
>>
>> Which package has the driver you're using? I propose we reassign this
>> package to that package for further investigation.
>
> The i915 gpu driver belongs to the kernel: linux-image-amd64.
So, I reassign the bug report to the linux source package.
> I first saw the problem with version 5.10.70-1
> (linux-image-5.10.0-9-amd64). Now I'm using version 5.10.84-1
> (linux-image-5.10.0-10-amd64) which also works fine using the boot
> parameter "intel_iommu=off". Although I did not try this version in the
> default configuration without this boot parameter.
It would help the Debian linux maintainers a lot if you could/want to
try this with the latest version in bullseye. Just in case it got
already fixed without going noticed inside Debian.
Paul
Hi Ben,
On 23-12-2021 23:46, Ben Mueller wrote:
> On 12/23/21 9:05 PM, Paul Gevers wrote:
>>> I solved the problem by inserting a boot parameter "intel_iommu=off" to
>>> grub. With this parameter the kernel from bullseye
>>> linux-image-5.10.0-9-amd64 was able to boot properly and the graphic was
>>> fine on console and with x. The kernel from buster did not need this
>>> boot parameter.
>>
>> Which package has the driver you're using? I propose we reassign this
>> package to that package for further investigation.
>
> The i915 gpu driver belongs to the kernel: linux-image-amd64.
> I first saw the problem with version 5.10.70-1
> (linux-image-5.10.0-9-amd64). Now I'm using version 5.10.84-1
> (linux-image-5.10.0-10-amd64) which also works fine using the boot
> parameter "intel_iommu=off". Although I did not try this version in the
> default configuration without this boot parameter.
try this with the latest version in bullseye. Just in case it got
already fixed without going noticed inside Debian.
Paul
Bogdan Veringioiu
Jun 10, 2022, 2:10:04 AM6/10/22
to
Hello,
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.
Symptoms:
The monitor gets blank when the i915 changes resolution on boot.
The PC remains accessible (ssh).
xrandr shows no monitor connected. Somehow the i915 driver is not
detecting the built-in monitor when resolution is changing on boot.
$ xrandr
Screen 0: minimum 8 x 8, current 1024 x 768, maximum 32767 x 32767
VGA1 disconnected primary (normal left inverted right x axis y axis)
VIRTUAL1 disconnected (normal left inverted right x axis y axis)
Connecting an external VGA monitor works without issues.
The intel_iommu=off does not work.
Some details about the system below:
lspci
..
00:02.0 VGA compatible controller: Intel Corporation 82Q35 Express
Integrated Graphics Controller (rev 02)
$ dmesg | grep 915
[ 8.816308] i915 0000:00:02.0: vgaarb: deactivate vga console
[ 8.846333] i915 0000:00:02.0: [drm] Failed to find VBIOS tables (VBT)
[ 8.846882] i915 0000:00:02.0: vgaarb: changed VGA decodes:
olddecodes=io+mem,decodes=io+mem:owns=io+mem
[ 9.116269] i915 0000:00:02.0: [drm] Initialized overlay support.
[ 9.118527] [drm] Initialized i915 1.6.0 20200917 for 0000:00:02.0 on
minor 0
[ 9.163178] fbcon: i915drmfb (fb0) is primary device
[ 9.203620] i915 0000:00:02.0: [drm] fb0: i915drmfb frame buffer device
Thank you
Bogdan
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.
Symptoms:
The monitor gets blank when the i915 changes resolution on boot.
The PC remains accessible (ssh).
xrandr shows no monitor connected. Somehow the i915 driver is not
detecting the built-in monitor when resolution is changing on boot.
$ xrandr
Screen 0: minimum 8 x 8, current 1024 x 768, maximum 32767 x 32767
VGA1 disconnected primary (normal left inverted right x axis y axis)
VIRTUAL1 disconnected (normal left inverted right x axis y axis)
Connecting an external VGA monitor works without issues.
The intel_iommu=off does not work.
Some details about the system below:
lspci
..
00:02.0 VGA compatible controller: Intel Corporation 82Q35 Express
Integrated Graphics Controller (rev 02)
[ 8.816308] i915 0000:00:02.0: vgaarb: deactivate vga console
[ 8.846333] i915 0000:00:02.0: [drm] Failed to find VBIOS tables (VBT)
[ 8.846882] i915 0000:00:02.0: vgaarb: changed VGA decodes:
olddecodes=io+mem,decodes=io+mem:owns=io+mem
[ 9.116269] i915 0000:00:02.0: [drm] Initialized overlay support.
[ 9.118527] [drm] Initialized i915 1.6.0 20200917 for 0000:00:02.0 on
minor 0
[ 9.163178] fbcon: i915drmfb (fb0) is primary device
[ 9.203620] i915 0000:00:02.0: [drm] fb0: i915drmfb frame buffer device
Thank you
Bogdan
Diederik de Haas
Jun 10, 2022, 6:40:03 AM6/10/22
to
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:
>
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 0000:00:02.0: vgaarb: changed VGA decodes:
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.
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.
> Symptoms:
> The monitor gets blank when the i915 changes resolution on boot.
> The PC remains accessible (ssh).
@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 0000:00:02.0: vgaarb: deactivate vga console
> [ 8.846333] i915 0000:00:02.0: [drm] Failed to find VBIOS tables (VBT)
When putting "i915 [drm] Failed to find VBIOS tables (VBT)" into a search
>
> [ 8.816308] i915 0000:00:02.0: vgaarb: deactivate vga console
> [ 8.846333] i915 0000:00:02.0: [drm] Failed to find VBIOS tables (VBT)
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 0000:00:02.0: vgaarb: changed VGA decodes:
> olddecodes=io+mem,decodes=io+mem:owns=io+mem
> [ 9.116269] i915 0000:00:02.0: [drm] Initialized overlay support.
> [ 9.118527] [drm] Initialized i915 1.6.0 20200917 for 0000:00:02.0 on
> minor 0
> [ 9.163178] fbcon: i915drmfb (fb0) is primary device
> [ 9.203620] i915 0000:00:02.0: [drm] fb0: i915drmfb frame buffer device
Request to both Bogdan and Ben:
> [ 9.116269] i915 0000:00:02.0: [drm] Initialized overlay support.
> [ 9.118527] [drm] Initialized i915 1.6.0 20200917 for 0000:00:02.0 on
> minor 0
> [ 9.163178] fbcon: i915drmfb (fb0) is primary device
> [ 9.203620] i915 0000:00:02.0: [drm] fb0: i915drmfb frame buffer device
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.
Ben Mueller
Jun 10, 2022, 11:40:04 AM6/10/22
to
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
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?
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
Bogdan Veringioiu
Oct 28, 2022, 9:10:04 AM10/28/22
to
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
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
Diederik de Haas
Oct 28, 2022, 9:40:03 AM10/28/22
to
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.208...@linux.intel.com/
> 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?
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?
Ben Mueller
Oct 28, 2022, 2:10:03 PM10/28/22
to
once again, when the patches made it into the Debian kernel.
Ben
0 new messages