Bug 111517 - No screen issues for extended period on xorg/lxde (HP systems)
Summary: No screen issues for extended period on xorg/lxde (HP systems)
Status: NEEDINFO
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: XOrg git
Hardware: Other All
: not set not set
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard: Triaged
Keywords:
Depends on:
Blocks:
 
Reported: 2019-08-29 12:03 UTC by Ferry
Modified: 2019-09-11 11:04 UTC (History)
1 user (show)

See Also:
i915 platform: SNB
i915 features:


Attachments
dmesg with drm.debug=0x1e -- XZ compressed (28.48 KB, application/x-xz)
2019-08-29 12:03 UTC, Ferry
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ferry 2019-08-29 12:03:21 UTC
Created attachment 145206 [details]
dmesg with drm.debug=0x1e -- XZ compressed

Hi there,

I'm not sure where to file this I'm afraid, I think it's supposed to go here.

We build a kiosk like distribution for taking exams with. It's based of Fedora 30 currently and runs Xorg with LXDE. We have no issues with stock Fedora 30 (which used Wayland/Gnome) on these machines. Besides our application (modified browser), all packages are from Fedora. Some config files have been modified and Xorg/LXDM isn't the default on Fedora, but they are in their repo's.

Our modified Fedora works fine nearly everywhere, but on some older HP machines GUI will not appear for an extended amount of time (Xorg, console is fine). After you see the LXDM service starting the console seems stuck there. After waiting 10-20 minutes GUI will appear and all seems well.

On some of the systems the GUI instantly comes to live after moving the mouse a few seconds after LXDM has started. Presume the mouse forces a redraw or something which makes it come to live.

The systems all concern older HP systems, 8200, 8300, & 6560B so far with various BIOS versions. Newer BIOS versions actually seem to have more issues.

On the 8200's the mouse will activate GUI, it does not on the 8300's from what we got. We have a 8200 to test with, we don't have 8300's ourselves but I can ask people to test those (more cumbersome tho' as there are several parties in between).

In order to gather logging we have a script active, if users plug in a USB stick which contains a file with a certain name it will output logs to the stick. This process also runs xrandr, which also seems to 'unfreeze?' the GUI.

We have tested with a lot of kernel versions (all stock Fedora kernels, although some come from older Fedora versions, we only replace the kernel (and the modules in /lib/modules oc) and nothing else).

With 4.16.x they all seem to work without any issues.
With 4.17.x about half works without issues, most of the time.
4.18 and higher they all exhibit issues.

I'm not sure where to start as the systems work fine when using Fedora 30 live, but then Wayland and gnome are used which probably address the GPU very differently.

As reverting the kernel to 4.16 solves it, my first guess would be the kernel driver. There's nothing in the logs that are indicative of the source, not to me anyways.

Hope we can tackle this. I've attached logs from a system, I moved the mouse on it to activate the GUI after waiting some time. Did pass along  drm.debug=0x1e log_buf_len=1M as mentioned on https://01.org/linuxgraphics/documentation/how-report-bugs

I can provide logging, test stuff, compile things, etc., but no clue where to start here I'm afraid, C driver code is beyond my skills. Hope someone can help us narrow this down.

Thanks in advance!
Comment 1 Lakshmi 2019-08-30 08:02:01 UTC
Is the external monitor connected through DP?
How did you recover from the situation, what steps you have followed to make GUI appear?
Can you verify the issue with drmtip?(https://cgit.freedesktop.org/drm-tip)
If issue appears can you please attach the logs?
Comment 2 Ferry 2019-09-10 08:34:53 UTC
Hi,

I'll be there this Thursday. I'll test with the drm tip branch. Anything in particular you'd like me to try / debug parameters?

Most systems have the monitor connected through DP cables, but there's also customers with VGA or DVI connections that have the issues.

I don't have to follow any steps to make the GUI appear. Either wait 10-20 minutes and it will come on it's own (perhaps due to something triggering a redraw - I don't know) or move the mouse.

On some systems moving the mouse doesn't help, they just need to wait a long time.
Comment 3 Lakshmi 2019-09-11 08:00:37 UTC
(In reply to Ferry from comment #2)
> Hi,
> 
> I'll be there this Thursday. I'll test with the drm tip branch. Anything in
> particular you'd like me to try / debug parameters?
You can collect dmesg logs from boot with kernel parameters drm.debug=0x1e log_buf_len=4M. This will show more information.
Comment 4 Ferry 2019-09-11 11:04:14 UTC
Hi, thanks.

Was already using those (well the buffer is listed as 1M on the debug page, not 4M). Thing is more that I'm only there once every 2 weeks so there's quite an interval on when I can test unfortunately.

I'll build drm-tip tomorrow and use the drm.debug=0x1e log_buf_len=4M parameters and report back.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.