Open raichoo opened 7 years ago
Is this a regression? Are you able to ssh into the machine when the hang occurs?
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.
Just in case, is there information I should collect once this happens again?
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").
It happened again but the machine was not reachable via ssh
. Again, no panic or whatsoever.
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.
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.
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
Haven't tried that yet. Put the setting in there, let's see what happens.
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?
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.
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.
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