12.0-RC1 drm_atomic panic (supervisor read data, protection violation)

Mon Nov 19 17:58:09 UTC 2018

Sorry for the spam, I had forgotten this:

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x830c0db10
fault code      = supervisor read data, protection violation
instruction pointer = 0x20:0xffffffff83e89ad1
stack pointer           = 0x28:0xfffffe00ea0a9740
frame pointer           = 0x28:0xfffffe00ea0a9880
code segment        = base 0x0, limit 0xfffff, type 0x1b
             = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags    = interrupt enabled, resume, IOPL = 0
current process     = 55043 (sublime_text)
trap number     = 12
WARNING !state->acquire_ctx failed at drm_atomic.c:676
WARNING !state->acquire_ctx failed at drm_atomic.c:263
WARNING !state->acquire_ctx failed at drm_atomic.c:676
WARNING !state->acquire_ctx failed at drm_atomic.c:676
WARNING !state->acquire_ctx failed at drm_atomic.c:263
WARNING !state->acquire_ctx failed at drm_atomic.c:263
WARNING !state->acquire_ctx failed at drm_atomic.c:676
WARNING !state->acquire_ctx failed at drm_atomic.c:676
WARNING !state->acquire_ctx failed at drm_atomic.c:676
WARNING !state->acquire_ctx failed at drm_atomic.c:676
WARNING !state->acquire_ctx failed at drm_atomic.c:676
WARNING !state->acquire_ctx failed at drm_atomic.c:676
WARNING !state->acquire_ctx failed at drm_atomic.c:263
WARNING !state->acquire_ctx failed at drm_atomic.c:676
WARNING !state->acquire_ctx failed at drm_atomic.c:263
WARNING !state->acquire_ctx failed at drm_atomic.c:263
WARNING !state->acquire_ctx failed at drm_atomic.c:999
WARNING !state->acquire_ctx failed at drm_atomic.c:263
WARNING !state->acquire_ctx failed at drm_atomic.c:999
WARNING !state->acquire_ctx failed at drm_atomic.c:263
WARNING !state->acquire_ctx failed at drm_atomic.c:263
WARNING !state->acquire_ctx failed at drm_atomic.c:676
WARNING !state->acquire_ctx failed at drm_atomic.c:263
WARNING !state->acquire_ctx failed at drm_atomic.c:676
WARNING !state->acquire_ctx failed at drm_atomic.c:263
WARNING !state->acquire_ctx failed at drm_atomic.c:263
WARNING !state->acquire_ctx failed at drm_atomic.c:263
<4>WARN_ON(!mutex_is_locked(&dev->struct_mutex))WARN_ON(!mutex_is_locked(&fbc->lock))pipe 
A vblank wait timed out
<4>WARN_ON(!mutex_is_locked(&fbc->lock))WARN_ON(!mutex_is_locked(&fbc->lock))WARN_ON(!mutex_is_locked(&fbc->lock))
  panic: page fault

On 19/11/2018 18:43, matias at pizarro.net wrote:
> Sorry, I forgot to mention I am using the on-board UHD Graphics 620
> 
> On 19/11/2018 18:37, matias at pizarro.net wrote:
>> Hello everyone,
>> 
>> Thanks for your great work that allows me to use a real OS on my work 
>> machine.
>> 
>> I have been tracking 12-CURRENT on a ThinkPad T450 without issues
>> until now. I just got myself a T480 and rolled out 12.0-BETA4 and then
>> RC1, with the same packages but I am getting a panic when launching
>> either Sublime Text 3 or Textadept. All my other packages (mpv,
>> libreoffice, Inkscape, Firefox, Chromium, Xfe etc...) are working fine
>> but these two, which are linux binaries (relevant?), trigger the
>> panic, both in BETA4 and RC1, using drm-stable-kmod or drm-next-kmod,
>> from quarterly or latest pkg repos.
>> At the moment I have
>> $ pkg info -d drm-next-kmod
>> drm-next-kmod-4.11.g20181027_1:
>>         gpu-firmware-kmod-g20181104
>> 
>> Bearing in mind these are running on different hardware:
>>     - works, self-compiled kernel:
>>         FreeBSD lenovo01 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r334644 
>> amd64
>>     - panics, fresh install from BETA4 image, binary-updated to RC1:
>>         FreeBSD lenovo01 12.0-RC1 FreeBSD 12.0-RC1 r340470 GENERIC  
>> amd64
>> 
>> After 12 hours of trying to sort this out I have run out of ideas. I
>> would appreciate it if you could help me figure out what should my
>> next steps be.
>> I could, for instance:
>>     1) Roll-out 12.0-RC1 on a BE on the machine that works to see if
>> the issue is linked with the change of hardware
>>     2) Roll-out 12-CURRENT r334644 on a BE on the panicking machine to
>> see if the issue is linked to the change of kernel
>>     3) Compile a DEBUG kernel on the panicking machine to help you
>> diagnose the issue
>>     4) Roll out a patched kernel if the included information inspires
>> you an idea for a patch
>> 
>> I have no idea of C or kernel hacking but I am confortable with
>> compiling custom kernels or building ports.
>> 
>> I have put the following in a gist, though I include here an extract
>> of part of the dump report to (hopefully) whet your appetite:
>>     - /var/crash/core.txt, that contains full boot log, ps -axlww,
>> vmstat -s | -m | -z
>>     - /boot/loader.conf
>>     - /etc/rc.conf
>>     - /etc/sysctl.conf
>>     - /var/log/Xorg.0.log (I am not using any Xorg configuration)
>> 
>> gist URL: 
>> https://gist.github.com/rebost/1a2bbfc45e9273ae5a76a98c3a67a23d
>> 
>> I also have the actual vmcore dump at hand if necessary, but that's 
>> 1,4GB.
>> 
>> If there is anything else I can help you help me with, just let me 
>> know
>> 
>> Thanks for your help, past and future.
>> 
>> -- matías
>> _______________________________________________
>> freebsd-x11 at freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-x11
>> To unsubscribe, send any mail to "freebsd-x11-unsubscribe at freebsd.org"
> _______________________________________________
> freebsd-x11 at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-x11
> To unsubscribe, send any mail to "freebsd-x11-unsubscribe at freebsd.org"