Re: Kernel crash during video transcoding
I re-installed the user land in my jail after re-compiling the sources and from that point I don't have the issue anymore. Seems like some libraries were not properly updated or something like that (maybe libva). In any case if it happens again I'll try to generate a test video with ffmpeg 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 steps to reproduce this? > > --HPS > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Kernel crash during video transcoding
ax_stride = 0xdeadc0dedeadc0de,
update_plane = 0xdeadc0dedeadc0de,
update_slave = 0xdeadc0dedeadc0de,
disable_plane = 0xdeadc0dedeadc0de,
get_hw_state = 0xdeadc0dedeadc0de,
check_plane = 0xdeadc0dedeadc0de
}
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 = 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'}
>
> This "m" structure looks freed.
>
> It looks like a use after free issue.
>
> Can you enter this in GDB:
>
> set print pretty on
>
> Then dump some more structures you can get hold of?
>
> --HPS
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Kernel crash during video transcoding
"m" is not NULL :
(kgdb) frame 16
#16 0x80ec23ed in vm_page_busy_acquire (m=0xfe00040ff9e8,
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 0x82b4e980 in intel_plane_can_remap
(plane_state=0xf80315148300)
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 0x82b4e980 in remap_io_mapping (vma=0xf80315148300,
addr=, pfn=, size=,
iomap=)
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
> > 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
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Kernel crash during video transcoding
Hi,
I looked at the crash dump and the code more closely:
#18 0x82be1c5f in i915_gem_fault (dummy=,
vmf=)
at
/usr/ports/graphics/drm-devel-kmod/work/drm-kmod-drm_v5.3_4/drivers/gpu/drm/i915/gem/i915_gem_mman.c:367
(kgdb) p area->vm_obj->lock
$43 = {lock_object = {lo_name = 0x8112c767 "vm object", lo_flags =
627245056, lo_data = 0, lo_witness = 0xf8045f575800}, rw_lock =
18446741878623409920}
So vm_obj is not NULL and has a rw_lock member
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.
The panic occurs in kern_rwlock.c:270 in frame #15 when
calling rw_wowner(rwlock2rw(c)) so something goes wrong either in rw_wowner
or in rwlock2rw.
Looking at rwlock2rw() :
/*
* Return the rwlock address when the lock cookie address is provided.
* This functionality assumes that struct rwlock* have a member named
rw_lock.
*/
#define rwlock2rw(c)(__containerof(c, struct rwlock, rw_lock))
I think this one is just extracting out the rw_lock member of the passed in
struct. However I don't understand what the cookie address is about due to
my lack of knowledge on kernel locking concepts. So maybe something is
wrong with the cookie or the rw_lock value itself.
Looking at rw_wowner() :
/*
* Return a pointer to the owning thread if the lock is write-locked or
* NULL if the lock is unlocked or read-locked.
*/
#define lv_rw_wowner(v) \
((v) & RW_LOCK_READ ? NULL :\
(struct thread *)RW_OWNER((v)))
#define rw_wowner(rw) lv_rw_wowner(RW_READ_VALUE(rw))
I don't think that one could cause a panic but again I'm not experienced
enough to be sure, it seems this either returns the thread that owns the
lock or NULL if no thread owns it.
The is also the fact that the driver calls vm_page_busy_acquire with the
VM_ALLOC_WAITFAIL flag which is defined in vm_page.h as :
#define VM_ALLOC_WAITFAIL 0x0010 /* (acf) Sleep and return error */
Could this be the reason of the 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 :
> Hi,
>
> I could finally generate a crash dump even with a black screen, I had to
> guess I was in the crash handler and I type "dump" and enter which worked.
> The driver logs "[drm] Cannot find any crtc or sizes" which I guess is the
> reason why I couldn't see anything on my screen.
>
> Back to the initial problem, I could start a kgdb session, loaded the
> i915kms.ko symbols and here are the results :
>
> (kgdb) bt
> #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
> #1 doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:394
> #2 0x8049c26a in db_dump (dummy=,
> dummy2=, dummy3=, dummy4=) at
> /usr/src/sys/ddb/db_command.c:575
> #3 0x8049c02c in db_command (last_cmdp=,
> cmd_table=, dopager=1) at /usr/src/sys/ddb/db_command.c:482
> #4 0x8049bd9d in db_command_loop () at
> /usr/src/sys/ddb/db_command.c:535
> #5 0x8049f048 in db_trap (type=, code= out>) at /usr/src/sys/ddb/db_main.c:270
> #6 0x80c1b374 in kdb_trap (type=3, code=0, tf=) at
> /usr/src/sys/kern/subr_kdb.c:699
> #7 0x8100ca98 in trap (frame=0xfe00d7567300) at
> /usr/src/sys/amd64/amd64/trap.c:576
> #8
> #9 kdb_enter (why=0x811d5de0 "panic", msg=) at
> /usr/src/sys/kern/subr_kdb.c:486
> #10 0x80bd00be in vpanic (fmt=, ap=)
> at /usr/src/sys/kern/kern_shutdown.c:902
> #11 0x80bcfe53 in panic (fmt=0x81c8c7c8
> "\b\214\031\201\377\377\377\377") at /usr/src/sys/kern/kern_shutdown.c:839
> #12 0x8100cee7 in trap_fatal (frame=0xfe00d7567600, eva=0) at
> /usr/src/sys/amd64/amd64/trap.c:915
> #13 0x8100c360 in trap (frame=0xfe00d7567600) at
> /usr/src/sys/amd64/amd64/trap.c:212
> #14
> #15 _rw_wowned (c=0x2659c92217d5aa52) at
> /usr/src/sys/kern/kern_rwlock.c:270
> #16 0x80ec23ed in vm_page_busy_acquire (m=0xfe00040ff9e8,
> allocflags=16) at /usr/src/sys/vm/vm_page.c:884
> #17 0x82b4e980 in remap_io_mapping (vma=0xf80315148300,
> addr=, pfn=, size=,
> iomap=)
> at
> /usr/ports/graphics/drm-devel-kmod/work/drm-kmod-drm_v5.3_4/drivers/gpu/drm/i915/intel_freebsd.c:193
> #18 0x82be1c5f in i915_gem_fault (dummy=,
> vmf=)
> at
> /usr/ports/graphics/drm-devel-kmod/work/drm-kmod-drm_v5.3_4/drivers/gpu/drm/i915/gem/i915_gem_mman.c:367
> #19 0x82cb5ddf in linux_cdev_pager_populate
> (vm_obj=0xf80368501420, pidx=, fault_type=
Re: Kernel crash during video transcoding
80ec23ed is in vm_page_busy_acquire (/usr/src/sys/vm/vm_page.c:884). 879 if (vm_page_tryacquire(m, allocflags)) 880 return (true); 881 if ((allocflags & VM_ALLOC_NOWAIT) != 0) 882 return (false); 883 if (obj != NULL) 884 locked = VM_OBJECT_WOWNED(obj); 885 else 886 locked = false; 887 MPASS(locked || vm_page_wired(m)); 888 if (_vm_page_busy_sleep(obj, m, m->pindex, "vmpba", allocflags, It seems like the problem occured when calling vm_page_busy_acquire(m, VM_ALLOC_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 happens during the call to VM_OBJECT_WLOCK > > (memory page locking for write ?) in the intel_freebsd.c (see [1] below). > > I'm out for a few days but I'll try to dig more into it when I'm back > next > > weekend although I have no experience in the drm-devel-kmod codebase. In > > the meantime if you have any suggestions on debugging this further I'm > > happy to follow them. > > The problem is likely that the vm_obj is NULL. > > I think I recall that this function is special and can only be called > from a certain context, unlike in Linux. Will need the full backtrace > with line numbers in order to debug this. > > --HPS > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Kernel crash during video transcoding
I could reproduce with GENERIC kernel and i915 kms compiled with DEBUG and
I got this additional info (still no crash dump though) :
Kernel page fault with the following non-sleepable locks held:
kernel: exclusive rw vm object (vm object) r = 0 (0xf8037533bc60)
locked @
/usr/ports/graphics/drm-devel-kmod/work/drm-kmod-drm_v5.3_4/drivers/gpu/drm/i915/intel_freebsd.c:186
Looking at the code, the error happens during the call to VM_OBJECT_WLOCK
(memory page locking for write ?) in the intel_freebsd.c (see [1] below).
I'm out for a few days but I'll try to dig more into it when I'm back next
weekend although I have no experience in the drm-devel-kmod codebase. In
the meantime if you have any suggestions on debugging this further I'm
happy to follow them.
Thanks again.
[1] i915/intel_freebsd.c
int
remap_io_mapping(struct vm_area_struct *vma, unsigned long addr,
unsigned long pfn, unsigned long size, struct io_mapping *iomap)
{
vm_page_t m;
vm_object_t vm_obj;
vm_memattr_t attr;
vm_paddr_t pa;
vm_pindex_t pidx, pidx_start;
int count, rc;
attr = iomap->attr;
count = size >> PAGE_SHIFT;
pa = pfn << PAGE_SHIFT;
pidx_start = OFF_TO_IDX(addr);
rc = 0;
vm_obj = vma->vm_obj;
vma->vm_pfn_first = pidx_start;
>>> VM_OBJECT_WLOCK(vm_obj); <<<
for (pidx = pidx_start; pidx < pidx_start + count;
pidx++, pa += PAGE_SIZE) {
retry:
m = vm_page_grab(vm_obj, pidx, VM_ALLOC_NOCREAT);
if (m == NULL) {
m = PHYS_TO_VM_PAGE(pa);
if (!vm_page_busy_acquire(m, VM_ALLOC_WAITFAIL))
goto retry;
if (vm_page_insert(m, vm_obj, pidx)) {
vm_page_xunbusy(m);
VM_OBJECT_WUNLOCK(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 2020 à 09:44, Alexandre Levy a écrit :
> 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 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 ?
>>
>> Type:
>>
>> make config
>>
>> Before building the i915kms port, then there should be a DEBUG option
>> you can select.
>>
>> --HPS
>>
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Kernel crash during video transcoding
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 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 ? > > Type: > > make config > > Before building the i915kms port, then there should be a DEBUG option > you can select. > > --HPS > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Kernel crash during video transcoding
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 wrote: > > 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 causing a kernel panic that is reproducible all the time > > with that particular video. It seems like it's caused by the i915kms > module > > (call of i915_gms_fault() in the stack) : > > If you compile the kernel using GENERIC and then enable debugging in the > i915 kms and reproduce, we might get a more clear picture! > > It is a so called NULL pointer you've experienced. > > --HPS > > > > > Fatal trap 12: page fault while in kernel mode > > cpuid = 0; apic id = 00 > > fault virtual address = 0xdf > > fault code = supervisor read data, page not present > > instruction pointer = 0x20:0x80bdd2b4 > > stack pointer = 0x0:0xfe00d2be56d0 > > frame pointer = 0x0:0xfe00d2be56d0 > > code segment= base 0x0, limit 0xf, type 0x1b > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > processor eflags= interrupt enabled, resume, IOPL = 0 > > current process = 4611 (Plex Transcoder) > > trap number = 12 > > panic: page fault > > cpuid = 0 > > time = 1596976796 > > KDB: stack backtrace: > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > > 0xfe00d2be5390 > > vpanic() at vpanic+0x182/frame 0xfe00d2be53e0 > > panic() at panic+0x43/frame 0xfe00d2be5440 > > trap_fatal() at trap_fatal+0x387/frame 0xfe00d2be54a0 > > trap_pfault() at trap_pfault+0x4f/frame 0xfe00d2be54f0 > > trap() at trap+0x271/frame 0xfe00d2be5600 > > calltrap() at calltrap+0x8/frame 0xfe00d2be5600 > > --- trap 0xc, rip = 0x80bdd2b4, rsp = 0xfe00d2be56d0, rbp = > > 0xfe00d2be56d0 --- > > _rw_wowned() at _rw_wowned+0x4/frame 0xfe00d2be56d0 > > vm_page_busy_acquire() at vm_page_busy_acquire+0x141/frame > > 0xfe00d2be5710 > > remap_io_mapping() at remap_io_mapping+0x120/frame 0xfe00d2be5760 > > i915_gem_fault() at i915_gem_fault+0x25f/frame 0xfe00d2be57d0 > > linux_cdev_pager_populate() at linux_cdev_pager_populate+0x11b/frame > > 0xfe00d2be5840 > > vm_fault() at vm_fault+0x3d1/frame 0xfe00d2be5950 > > vm_fault_trap() at vm_fault_trap+0x60/frame 0xfe00d2be5990 > > trap_pfault() at trap_pfault+0x19c/frame 0xfe00d2be59e0 > > trap() at trap+0x3f1/frame 0xfe00d2be5af0 > > calltrap() at calltrap+0x8/frame 0xfe00d2be5af0 > > --- trap 0xc, rip = 0x80296659a, rsp = 0x7fffbd38, rbp = 0x80fc0 > --- > > KDB: enter: panic > > > > I don't see any crash dump in /var/crash despite having the right > > configuration and I should have enough space on my swap device (128GB USB > > drive) : > > > > $ cat /etc/rc.conf | grep dump > > dumpdev="AUTO" > > > > $ swapinfo > > Device 1K-blocks UsedAvail Capacity > > /dev/gpt/crash0 1213070960 121307096 0% > > > > $ cat /etc/fstab > > /dev/gpt/crash0 noneswapsw 0 0 > > > > $ dumpon -l > > gpt/crash0 > > > > Not sure why no dump was generated, is it because the kernel was compiled > > with the GENERIC-NODEBUG profile ? However I see various KDB options in > the > > GENERIC profile that are inherited by GENERIC-NODEBUG. > > > > Happy to recompile the kernel with GENERIC profile if it's required. > > > > Thank you. > > ___ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to " > freebsd-current-unsubscr...@freebsd.org" > > > > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Kernel crash during video transcoding
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 causing a kernel panic that is reproducible all the time with that particular video. It seems like it's caused by the i915kms module (call of i915_gms_fault() in the stack) : Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xdf fault code = supervisor read data, page not present instruction pointer = 0x20:0x80bdd2b4 stack pointer = 0x0:0xfe00d2be56d0 frame pointer = 0x0:0xfe00d2be56d0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 4611 (Plex Transcoder) trap number = 12 panic: page fault cpuid = 0 time = 1596976796 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00d2be5390 vpanic() at vpanic+0x182/frame 0xfe00d2be53e0 panic() at panic+0x43/frame 0xfe00d2be5440 trap_fatal() at trap_fatal+0x387/frame 0xfe00d2be54a0 trap_pfault() at trap_pfault+0x4f/frame 0xfe00d2be54f0 trap() at trap+0x271/frame 0xfe00d2be5600 calltrap() at calltrap+0x8/frame 0xfe00d2be5600 --- trap 0xc, rip = 0x80bdd2b4, rsp = 0xfe00d2be56d0, rbp = 0xfe00d2be56d0 --- _rw_wowned() at _rw_wowned+0x4/frame 0xfe00d2be56d0 vm_page_busy_acquire() at vm_page_busy_acquire+0x141/frame 0xfe00d2be5710 remap_io_mapping() at remap_io_mapping+0x120/frame 0xfe00d2be5760 i915_gem_fault() at i915_gem_fault+0x25f/frame 0xfe00d2be57d0 linux_cdev_pager_populate() at linux_cdev_pager_populate+0x11b/frame 0xfe00d2be5840 vm_fault() at vm_fault+0x3d1/frame 0xfe00d2be5950 vm_fault_trap() at vm_fault_trap+0x60/frame 0xfe00d2be5990 trap_pfault() at trap_pfault+0x19c/frame 0xfe00d2be59e0 trap() at trap+0x3f1/frame 0xfe00d2be5af0 calltrap() at calltrap+0x8/frame 0xfe00d2be5af0 --- trap 0xc, rip = 0x80296659a, rsp = 0x7fffbd38, rbp = 0x80fc0 --- KDB: enter: panic I don't see any crash dump in /var/crash despite having the right configuration and I should have enough space on my swap device (128GB USB drive) : $ cat /etc/rc.conf | grep dump dumpdev="AUTO" $ swapinfo Device 1K-blocks UsedAvail Capacity /dev/gpt/crash0 1213070960 121307096 0% $ cat /etc/fstab /dev/gpt/crash0 noneswapsw 0 0 $ dumpon -l gpt/crash0 Not sure why no dump was generated, is it because the kernel was compiled with the GENERIC-NODEBUG profile ? However I see various KDB options in the GENERIC profile that are inherited by GENERIC-NODEBUG. Happy to recompile the kernel with GENERIC profile if it's required. Thank you. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
