My device containing the Atom N2600 processor sometimes boots to a black display just before displaying an xfce desktop. When this problem occurs, I see the BIOS screen and startup text for grub and initramfs, but the screen goes black at some point before displaying the desktop and remains black. The backlight seems to work. This occurs about once out of every 5 reboots of my device. I am running Ubuntu 22 with an xfce desktop, but this same problem occurs on Ubuntu 20 with an LXQt desktop.

My display is connected via an LVDS interface. I've used an oscillisciope to probe the LVDS A clock and the 3 data pair signals (A0-A2) when this problem occurs, and it appears that the processor is setting every pixel to black on the display. I say this because if I force the display to solid black (via the command 'dd if=/dev/zero of=/dev/fb0' after pressing Ctrl+Alt+F1 to get into a virtual console) when the device starts normally I see the same activity on the LVDS clock and data lines. When the display is showing black the LVDS clock is running at 25MHz, the A0 data line is very busy, and the A1 and A2 data lines are idle. When this problem occurs everything else works fine - I can connect to the device via SSH and VNC. VNC shows the XFCE desktop I normally see.

I believe this is an issue with the gma500_gfx driver because if I blacklist the gma500_gfx driver, the i915 driver is used (with a non-optimal 800x600 resolution) and no matter how many times I reboot this device the LVDS display always works as expected.

I've tried to debug this issue by using drm.debug=6 as a kernel command line argument and recompiling the gma500_gfx driver to output additional register information, but nothing I've seen yet in dmesg or xrandr output is different between a normal and bad boot up of this device. I've just discovered the intel-gpu-tools package, but most of those tools fail with a message 'Couldn't map MMIO region' or 'No known gpu found for chipset flags 0x1 (intel)'. I suspect these tools don't support the gpu in the Atom N2600 processor.

I'd appreciate any other debugging advice. I'm new to gpu debugging and have already looked into this problem for days.

This sounds like a possible plymouth issue. Try disabling or removing it.

Does your device have an available BIOS update?

Your description suggests you are using autologin. If you disable autologin, is there any difference?

1 members found this post helpful.

Thank you for the quick response! My responses are inline below.

> This sounds like a possible plymouth issue. Try disabling or removing it.

Plymouth is already disabled - 'quiet splash' is removed from my Grub command line.

> Does your device have an available BIOS update?

I'll reach out to the BIOS suppliers - Advantech.

> Your description suggests you are using autologin. If you disable autologin, is there any difference?

I disabled autologin by removing my /etc/lightdm/lightdm.conf file. Unfortunately it doesn't make a difference - the problem can still occur.
When the problem occurs, if I switch from TTY7 (default) to TTY1 the display remains blank (ie. no text login prompt). Also I don't even see a mouse cursor.

Once the device boots up with this issue, I haven't yet found a way to get the display working again without another reboot.

Whatever your display's native mode is, try including it on the linu line in Grub where quiet splash used to be, e.g.: video=1920x1080@60 If it does not help, try with a lesser supported mode, e.g. video=1900x900@60. Note however if you do this, and Xorg is running on the intel DDX display driver rather than the normally preferred default modesetting DIX display driver, that Xorg can be expected to inherit use of the specified lesser mode. Like the modesetting, other GPU's display drivers ignore use of cmdline video=.

It may pay to report this on intel-gfx@lists.freedesktop.org, where the Intel driver devs communicate.

1 members found this post helpful.

Thanks for the quick response again mrmazda!

I tried adding the native mode of our display to the kernel command line (video=1024x600@60) and a lesser supported mode (video=1900x900@60) where 'quiet splash' used to be and unfortunately this doesn't make a difference - the boot-up issue I see still occurs.

I posted this issue to intel-gfx@lists.freedesktop.org as suggested.

Thanks for your help!

No one has responded on intel-gfx@lists.freedesktop.org, maybe because the gma500_gfx isn't their main driver (i915). I really need this problem fixed, however. Unfortunately I'm new to Linux DRM drivers so this fix might take a long time. I'll repost here with any sort of progress I make.

You could try IRC: irc://irc.oftc.net/intel-gfx

You could report a bug from within ubuntu using apport or reportbug (you may need to install first).

https://www.kernel.org/doc/Documenta...parameters.txt has a multitude command line options, any number of which conceivably could workaround this. Look near the middle to start: intel_iommu=

Can you reproduce this using a non-Debian-based distro?

gma500 is a special world I've never been directly exposted to. HTH

1 members found this post helpful.

More from thinking outside the box, a hunch:
If your initrd is over around 100M, and your /etc/initramfs-tools/initramfs.conf contains MODULES=most, try changing it to MODULES=dep and rebuilding your initrd. This is a solution to a problem of error: out of memory from Grub, known Ubuntu bug 1404415. Another workaround to that problem is in BIOS to reduce RAM available to graphics to as low as 64M, so that more RAM from below 512M is available to non-graphics operation. The smaller initrd is intended to have the same effect. I'm thinking RAM utilization during boot could be your problem too.

1 members found this post helpful.

This issue was (most likely) addressed with the July 11 2023 commit made to Linux kernel 6.5 - 'drm/client: Send hotplug event after registering a client' https://github.com/torvalds/linux/co...49b676898c52d5. When debugging the driver using drm.debug=0x1ff I could see that really the only difference between a bad boot (ie. display didn't work) and a good boot was the timing of the hotplug event (ie. detection of our LVDS display). I can't reproduce this issue any longer after upgrading the Linux kernel to 6.5 on our device running Ubuntu 22. I didn't think of upgrading the Linux kernel on our device earlier - I didn't realize that changes were still being made to this old gma500 driver until I browsed through git history on https://github.com/torvalds/linux/co...gpu/drm/gma500. I was partly fooled by the unchanging driver date of '2014' in the kernel debug output "[drm] Initialized gma500 1.0.0 20140314 for 0000:00:02.0 on minor 0". Anyways, I'm glad we no longer have this issue. Thanks for your help mrmazda!

1 members found this post helpful.