and try to transcode it with similar parameters. That'd be the
easiest way to reproduce the issue.
Thanks for your insights.
Le ven. 21 août 2020 à 22:23, Hans Petter Selasky a
écrit :
> On 2020-08-16 22:23, Alexandre Levy wrote:
> > Any suggestions ?
>
> Are there any simple ste
adc0dedeadc0de
}
Le lun. 17 août 2020 à 09:03, Hans Petter Selasky a
écrit :
> On 2020-08-16 22:23, Alexandre Levy wrote:
> > (kgdb) p *m
> > $2 = {plinks = {q = {tqe_next = 0x578491b51dd60510, tqe_prev =
> > 0xd78c11bd9dde8518}, s = {ss = {sle_next = 0x578491b5
LOC_WAITFAIL) where m might be a NULL pointer ? I am very new to
kernel debugging so not sure where to go from there.
Thanks.
Le lun. 10 août 2020 à 12:04, Hans Petter Selasky a
écrit :
> Hi,
>
> On 2020-08-10 12:59, Alexandre Levy wrote:
> > Looking at the code, the error hap
LOCK(vm_obj);
vm_wait(NULL);
VM_OBJECT_WLOCK(vm_obj);
goto retry;
}
vm_page_valid(m);
}
pmap_page_set_memattr(m, attr);
vma->vm_pfn_count++;
}
VM_OBJECT_WUNLOCK(vm_obj);
return (rc);
}
Le lun. 10 août
Hi,
I installed the port drm-devel-kmod for Plex to be able to transcode videos
using the integrated GPU of my Intel Celeron G5900.
I'm running r364031 and the kernel is compiled with GENERIC-NODEBUG profile.
Transcoding has been working fine for quite a while now but one video
transcoding is
I'm recompiling the kernel using GENERIC at the moment but I'm not sure how
to enable debugging in i915 kms, there is no compile option for that, am I
missing something ?
Le lun. 10 août 2020 à 08:44, Hans Petter Selasky a
écrit :
> Hi,
>
> On 2020-08-10 00:19, Alexandre Levy wrot
Ah thanks, I was doing a make config-recursive and that didn't show the
DEBUG option. It's recompiling the module with DEBUG now.
Le lun. 10 août 2020 à 09:43, Hans Petter Selasky a
écrit :
> On 2020-08-10 10:41, Alexandre Levy wrote:
> > I'm recompiling the kernel using GENERIC at t
e panic as in we try to lock, then cannot and
eventually just return an error without retrying ? There is the flag
VM_ALLOC_WAITOK that says /* (acf) Sleep and retry */. Should I try to
patch intel_freebsd.c to use this flag instead ?
Thanks.
Le sam. 15 août 2020 à 20:35, Alexandre Levy a écrit
omap=)
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 a
écrit :
> On 2020-08-16 17:28, Alexandre Levy wrote:
> > Now at intel_freebsd.c:193 (frame #17) the driver calls
> &
