Closed grahamperrin closed 7 years ago
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.
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
$
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?
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 https://github.com/FreeBSDDesktop/freebsd-base-graphics/issues/114#issuecomment-276912382, or mute the thread https://github.com/notifications/unsubscribe-auth/AH-D0xl77gaUWLr6t5aZ0X90JSsnDOpqks5rYaZ-gaJpZM4LwaMk .
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.
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.
Environment
HP EliteBook 850 G2, KDE Plasma 4.
From before the last stop:
pciconf -lv.txt
Xorg.0.log.old.txt
Details
From https://gitter.im/trueos/troubleshooting?at=588c082bdb9cafe9183e1333:
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.