Intel HD Graphics 5500: attempting to disable the integral display causes TrueOS Desktop to stop

[grahamperrin]

Environment

HP EliteBook 850 G2, KDE Plasma 4.

From before the last stop:

$ date ; uname -v ; uname -n
Sat 28 Jan 2017 01:24:59 GMT
FreeBSD 12.0-CURRENT #20 3dbce2a(drm-next): Sat Jan 21 13:48:35 UTC 2017     root@gauntlet:/usr/obj/usr/src/sys/GENERIC 
momh167-gjp4-hpelitebook850g2-trueos.university.brighton.ac.uk
$ pciconf -lv > ~/Desktop/pciconf\ -lv.txt
$ tail /var/log/Xorg.0.log
[  3282.305] (II) modeset(0): Printing DDC gathered Modelines:
[  3282.305] (II) modeset(0): Modeline "1366x768"x0.0   85.50  1366 1436 1579 1792  768 771 774 798 +hsync +vsync (47.7 kHz eP)
[  3282.305] (II) modeset(0): Modeline "800x600"x0.0   40.00  800 840 968 1056  600 601 605 628 +hsync +vsync (37.9 kHz e)
[  3282.305] (II) modeset(0): Modeline "640x480"x0.0   31.50  640 656 720 840  480 481 484 500 -hsync -vsync (37.5 kHz e)
[  3282.305] (II) modeset(0): Modeline "640x480"x0.0   25.18  640 656 752 800  480 490 492 525 -hsync -vsync (31.5 kHz e)
[  3282.305] (II) modeset(0): Modeline "720x400"x0.0   28.32  720 738 846 900  400 412 414 449 -hsync +vsync (31.5 kHz e)
[  3282.305] (II) modeset(0): Modeline "1024x768"x0.0   78.75  1024 1040 1136 1312  768 769 772 800 +hsync +vsync (60.0 kHz e)
[  3282.305] (II) modeset(0): Modeline "1024x768"x0.0   65.00  1024 1048 1184 1344  768 771 777 806 -hsync -vsync (48.4 kHz e)
[  3282.305] (II) modeset(0): Modeline "800x600"x0.0   49.50  800 816 896 1056  600 601 604 625 +hsync +vsync (46.9 kHz e)
[  3282.305] (II) modeset(0): Modeline "1280x800"x0.0   83.50  1280 1352 1480 1680  800 803 809 831 -hsync +vsync (49.7 kHz e)
$ lumina-xconfig
Loading Locale: "lumina-xconfig" "en_GB" "UTF-8"
 - Could not load Locale: "en_GB"
 - Created new single-instance lock
QSvgHandler: Image filename is empty
QSvgHandler: Image filename is empty
QSvgHandler: Image filename is empty
 - ID: "eDP-1" Current Geometry: "1920x1080+0+0"
Create new Screen entry: "eDP-1" "1920x1080+0+0"
 - ID: "DP-1" Current Geometry: ""
 - ID: "HDMI-1" Current Geometry: ""
 - ID: "DP-2" Current Geometry: "1366x768+1920+0"
Create new Screen entry: "DP-2" "1366x768+1920+0"
 - ID: "HDMI-2" Current Geometry: ""
QSvgHandler: Image filename is empty
 - ID: "eDP-1" Current Geometry: "1920x1080+0+0"
Create new Screen entry: "eDP-1" "1920x1080+0+0"
 - ID: "DP-1" Current Geometry: ""
 - ID: "HDMI-1" Current Geometry: ""
 - ID: "DP-2" Current Geometry: "1366x768+1920+0"
Create new Screen entry: "DP-2" "1366x768+1920+0"
 - ID: "HDMI-2" Current Geometry: ""

pciconf -lv.txt

Xorg.0.log.old.txt

Details

From https://gitter.im/trueos/troubleshooting?at=588c082bdb9cafe9183e1333:

… Unfortunately the stop seems to be so hard that details are not logged. …

I'll boot the affected environment 12.0-CURRENT-up-20170127_233200 to take a photograph of what's on screen when the stop occurs. Aiming to reproduce the issue with Lumina, without KDE.

$ beadm list
BE                              Active Mountpoint  Space Created
12.0-CURRENT-201612152147       -      -            3.8G 2016-12-15 21:47
trueos-core-issue-303           NR     /           34.3G 2017-01-22 21:49
12.0-CURRENT-up-20170127_233200 -      -           11.2G 2017-01-27 22:55
$ sudo beadm activate 12.0-CURRENT-up-20170127_233200
Activated successfully
$ 

[grahamperrin]

Not reproducible with Lumina on this occasion (I might have had trouble with Lumina when the notebook was docked, with two external displays in DisplayPort ports).

With KDE, preparing to disable the display:

(Probably no need to clone, but I wanted to ensure that it's possible to set an absolute position.)

After clicking 'Apply':

… and I thought I took a photograph of the bottom right hand corner of the screen but (sorry) it seems that I didn't press properly.

[grahamperrin]

From a subsequent boot of the affected system:

$ about
  ______                   ____  _____
 /_  __/______  _____     / __ \/ ___/ 
  / / / ___/ / / / _ \   / / / /\__ \ 
 / / / /  / /_/ /  __/  / /_/ /___/ / 
/_/ /_/   \__,_/\___/   \____//____/  

General info:
       Host:...............momh167-gjp4-hpelitebook850g2-trueos.university.brighton.ac.uk
       User:...............grahamperrin
       Uptime:.............8 mins
       FreeBSD kernel ver:.12.0-CURRENT
       FreeBSD world ver:..12.0-CURRENT
       FreeBSD git branch:.drm-next
       FreeBSD git rev:....3dbce2a
       TrueOS ver:.........TrueOS-Desktop-201701261715
       Arch:...............amd64
       Kernel ident:.......GENERIC
       Bootloader:.........BSD
       Bootloader type:....EFI
       CPU:................Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz
       CPU cores:..........4
       Memory (free/avail):13529 / 16384 Mb
       Package set:........CUSTOM
       Desktop environment:Lumina
       X11 Driver:.........modesetting_drv.so 
       OSS Driver:.........pcm1: <Realtek (0x0280) (Analog 2.0+HP/2.0)> (play/rec) default
       WIFI Driver:........iwm0
$ 

[grahamperrin]

I wondered whether part of what's off-screen (in the photographs) is a kernel panic so I did what I think is necessary to prepare the boot environments for kernel core dumps.

Then: booted the affected environment, logged in to KDE, reproduced the 'stop' (for want of a better expression) by using lumina-xconfig (in lieu of KDE System Settings) to attempt to disable the display.

As far as I could tell, the stop was not a kernel panic. @mattmacy does that seem reasonable and if so, is there a way for me to get something more useful than photographs?

[nomadlogic]

On Feb 2, 2017 1:48 AM, "Graham Perrin" <notifications@github.com> wrote: I wondered whether part of what's off-screen (in the photographs) is a kernel panic so I did what I *think* is necessary to prepare the boot environments for kernel core dumps. Then: booted the affected environment, logged in to KDE, reproduced the 'stop' (for want of a better expression) by using lumina-xconfig (in lieu of KDE System Settings) to attempt to disable the display. As far as I could tell, the stop was *not* a kernel panic. @mattmacy <https://github.com/mattmacy> does that seem reasonable and if so, is there a way for me to get something more useful than photographs? After loading the i915kms module set this sysctl knob: dev.drm.skip_ddb=1 That should ensure you get a core if it is a panic as opposed to a deadlock. This assumes you have savecore enabled in rc.conf. this is also documented in the github wiki, along with other helpful debug tips.

…

-pete — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#114 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AH-D0xl77gaUWLr6t5aZ0X90JSsnDOpqks5rYaZ-gaJpZM4LwaMk> .

[grahamperrin]

Thanks.

Early indications are that with a more recent build of TrueOS Desktop, the issue is not reproducible.

We should probably leave it open for me to review after the next push to TrueOS UNSTABLE.

[grahamperrin]

Re: the shortlist of stable and unstable distributions at https://discourse.trueos.org/t/-/898 I'm certain that this issue is no longer reproducible.