FreeBSDDesktop / DEPRECATED-freebsd-base-graphics

Fork of FreeBSD's base repository to work on graphics-stack-related projects
Other
49 stars 13 forks source link

Thinkpad X1 Carbon 3rd Gen, hangs without starting the debugger. #164

Open raichoo opened 7 years ago

raichoo commented 7 years ago

Hi,

I've been having this issue for a month now and I'm pretty sure that it's related to KMS. My machine basically just hangs, no panic or whatsoever (hence I don't have any useful information yet).

I've tried running X using scfb for about 3 weeks and had now issues (apart from being unable to adjust screen brightness and lots of power consumption). Switched on KMS again this weekend and today (a couple of days later) it froze again. I'm really not sure what to report here since it everything just freezes without yielding any information. I also have no way of reproducing the issue, it just happens around once or twice a week. So I thought I'd open this issue to collect some data.

Kind regards, raichoo

markjdb commented 7 years ago

Is this a regression? Are you able to ssh into the machine when the hang occurs?

raichoo commented 7 years ago

I don't think it's a regression. I've had this issue since I've switched to FreeBSD 3 months ago. Couldn't pinpoint the culprit but now I'm relatively sure. Haven't tried to ssh into the machine, I'll try to have another machine in reach when this happens again.

raichoo commented 7 years ago

Just in case, is there information I should collect once this happens again?

markjdb commented 7 years ago

If you're able, it would be useful to get output of "sudo procstat -kka" and "dmesg". As a more extreme measure, you can try and get a kernel dump by panicking the system from the ssh session "sudo sysctl debug.kdb.panic=1", assuming you have configured a dump device (check with "dumpon -l").

raichoo commented 7 years ago

It happened again but the machine was not reachable via ssh. Again, no panic or whatsoever.

raichoo commented 7 years ago

Happened again at home. No connection via ssh possible. Is there anything I can do to get some more information that might help? I recall having a similar issue with Linux on the same machine a at around February/March last year. Not sure of that's related, I'm reaching for straws right now.

raichoo commented 7 years ago

Here is some dmesg output from my system (not crashed). Are these warnings normal?

[drm] Initialized
drmn0: <drmn> on vgapci0
vgapci0: child drmn0 requested pci_enable_io
vgapci0: child drmn0 requested pci_enable_io
[drm] Memory usable by graphics device = 4096M
[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[drm] Driver supports precise vblank timestamp query.
[drm] Connector eDP-1: get mode from tunables:
[drm]   - kern.vt.fb.modes.eDP-1
[drm]   - kern.vt.fb.default_mode
[drm] Connector DP-1: get mode from tunables:
[drm]   - kern.vt.fb.modes.DP-1
[drm]   - kern.vt.fb.default_mode
[drm] Connector HDMI-A-1: get mode from tunables:
[drm]   - kern.vt.fb.modes.HDMI-A-1
[drm]   - kern.vt.fb.default_mode
[drm] Connector DP-2: get mode from tunables:
[drm]   - kern.vt.fb.modes.DP-2
[drm]   - kern.vt.fb.default_mode
[drm] Connector HDMI-A-2: get mode from tunables:
[drm]   - kern.vt.fb.modes.HDMI-A-2
[drm]   - kern.vt.fb.default_mode
[drm] Initialized i915 1.6.0 20160919 for drmn on minor 0
WARN_ON(!msg->buffer != !msg->size)
WARN_ON(!msg->buffer != !msg->size)WARN_ON(!msg->buffer != !msg->size)
WARN_ON(!msg->buffer != !msg->size)WARN_ON(!msg->buffer != !msg->size)WARN_ON(!msg->buffer != !msg->size)WARN_ON(!msg->buffer != !msg->size)WARN_ON(!msg->buffer != !msg->size)WARN_ON(!msg->buffer != !msg->size)WARN_ON(!msg->buffer != !msg->size)WARN_ON(!msg->buffer != !msg->size)WARN_ON(!msg->buffer != !msg->size)WARN_ON(!msg->buffer != !msg->size)WARN_ON(!msg->buffer != !msg->size)WARN_ON(!msg->buffer != !msg->size)WARN_ON(!msg->buffer != !msg->size)WARN_ON(!msg->buffer != !msg->size)WARN_ON(!msg->buffer != !msg->size)WARN_ON(!msg->buffer != !msg->size)WARN_ON(!msg->buffer != !msg->size)WARN_ON(!msg->buffer != !msg->size)WARN_ON(!msg->buffer != !msg->size)WARN_ON(!msg->buffer != !msg->size)WARN_ON(!msg->buffer != !msg->size)WARN_ON(!msg->buffer != !msg->size)WARN_ON(!msg->buffer != !msg->size)WARN_ON(!msg->buffer != !msg->size)WARN_ON(!msg->buffer != !msg->size)WARN_ON(!msg->buffer != !msg->size)WARN_ON(!msg->buffer != !msg->size)WARN_ON(!msg->buffer != !msg->size)WARN_ON(!msg->buffer != !msg->size)
[drm:intel_dp_link_training_channel_equalization] failed to update link training
VT: Replacing driver "efifb" with new "fb".
start FB_INFO:
type=11 height=1440 width=2560 depth=32
cmsize=16 size=14745600
pbase=0xe0000000 vbase=0xfffff800e0000000
name=drmn0 flags=0x0 stride=10240 bpp=32
cmap[0]=0 cmap[1]=7f0000 cmap[2]=7f00 cmap[3]=c4a000
end FB_INFO
drmn0: fb0: inteldrmfb frame buffer device
[drm] Reducing the compressed framebuffer size. This may lead to less power savings than a non-reduced-size. Try to increase stolen memory size if available in BIOS.
nomadlogic commented 7 years ago

Have you tried setting the following in /boot/loader.conf? These should help increase the likely hood of capturing a core for analysis:

dev.drm.drm_skip_ddb=1

raichoo commented 7 years ago

Haven't tried that yet. Put the setting in there, let's see what happens.

raichoo commented 7 years ago

I know that this question is not directly related to the issue but I'm having issues setting up a dumpdev with an encrypted swap device on my system. dumpdev is set to AUTO and I've tried using the "late" option in fstab for the swap partition. It always complains about not finding a suitable dump device. Am I missing something?

raichoo commented 7 years ago

I've turned off geli for the time being and the crash happened shortly after that. Sadly the kernel didn't dump any information regarding the crash.

raichoo commented 7 years ago

I've updated this weekend and crashes now seem to happen more frequently, currently on a daily basis. Not sure if this is related to the update or me just triggering whatever causes the crash more often.