Re: Kernel crash during video transcoding

"m" is not NULL :

(kgdb) frame 16
#16 0xffffffff80ec23ed in vm_page_busy_acquire (m=0xfffffe00040ff9e8,
allocflags=16) at /usr/src/sys/vm/vm_page.c:884
(kgdb) p *m
$2 = {plinks = {q = {tqe_next = 0x578491b51dd60510, tqe_prev =
0xd78c11bd9dde8518}, s = {ss = {sle_next = 0x578491b51dd60510}}, memguard =
{p = 6306325585301210384,
      v = 15531808720989095192}, uma = {slab = 0x578491b51dd60510, zone =
0xd78c11bd9dde8518}}, listq = {tqe_next = 0xd78c11bd9dde8518, tqe_prev =
0x265bc92017d7aa38},
  object = 0x2659c92217d5aa3a, pindex = 2758957463725517354, phys_addr =
2758957463725517354, md = {pv_list = {tqh_first = 0x2e49c1321fc5a22a,
tqh_last = 0x3e4bd1300fc7b228},
    pv_gen = 265794104, pat_mode = 1046204704}, ref_count = 257405624,
busy_lock = 1054593440, a = {{flags = 4757, queue = 48 '0', act_count = 134
'\206'}, _bits = 2251297429},
  order = 98 'b', pool = 204 '\314', flags = 75 'K', oflags = 105 'i',
psind = -107 '\225', segind = 18 '\022', valid = 48 '0', dirty = 134 '\206'}

I had to recompile drm-devel-kmod with make WITH_DEBUG=yes DEBUG_FLAGS="-g
-O0" because "m" was optimized out. I then started a kgdb session with the
same crash dump than before, loaded the module symbols with add-kld
/boot/modules/i915kms.ko and I now have a different backtrace from frames
#17 to #28.

Also the panic doesn't occur when I plug a screen to the HDMI port (which
now works for some reason...) and I can see the frame #17 is now the
following :

#17 0xffffffff82b4e980 in intel_plane_can_remap
(plane_state=0xfffff80315148300)
    at
/usr/ports/graphics/drm-devel-kmod/work/drm-kmod-drm_v5.3_4/drivers/gpu/drm/i915/display/intel_display.c:2583

and used to be :

#17 0xffffffff82b4e980 in remap_io_mapping (vma=0xfffff80315148300,
addr=<optimized out>, pfn=<optimized out>, size=<optimized out>,
iomap=<optimized out>)

I don't understand why the backtrace changed although the crash dump is the
same as before. Any suggestions ?

Le dim. 16 août 2020 à 18:19, Hans Petter Selasky <hps_at_selasky.org> a
écrit :

> On 2020-08-16 17:28, Alexandre Levy wrote:
> > Now at intel_freebsd.c:193 (frame #17) the driver calls
> > vm_page_busy_acquire(m, VM_ALLOC_WAITFAIL). 'm' is the page grabbed from
> > vm_obj of the calling frame.
>
> Can you check if "m" is NULL at this point?
>
> --HPS
>