On Mon, Sep 05, 2016 at 01:55:38PM -0400, Shawn Webb wrote:
> Hey all,
> I'm at revision 3872750 of the hardened/current/drm-next-4.7 branch in
> the HardenedBSD/hardenedBSD-playground repo. I've gotten this kernel
> panic a couple times when booting. I'm using full-disk encryption with
> ZFS and encrypted swap. The hardware is a Purism 15 2K laptop.
> The panic doesn't happen often nor is there a way I can reproduce it
> 100%.
> Here's my `uname -a` output:
> FreeBSD hbsd-dev-laptop 12.0-CURRENT-HBSD FreeBSD 12.0-CURRENT-HBSD #0 
> 3872750(hardened/current/drm-next-4.7): Tue Aug 30 17:41:53 EDT 2016     
> shawn@hbsd-dev-laptop:/usr/obj/usr/src/sys/LATT-SEC  amd64
> Here's a couple pictures of the panic I took:
> https://goo.gl/photos/P5kiwabPYjwQX7Kr8
> https://goo.gl/photos/BWtvBnq7QLnwgRP28

Based on the faulting instruction, the panic probably happened because
qid is uninitialized in the loop that starts with

    while ((gtask = LIST_FIRST(&gtask_head))) {

I don't know this code very well, so I'm not sure how that can happen. I
suspect iflib_irq_alloc_generic() is buggy: it calls

    taskqgroup_attach_cpu(... CPU_FFS(&cpus) ...);

and CPU_FFS returns 1-indexed IDs, but taskqgroup_attach_cpu() pretty
clearly expects 0-indexed CPU IDs. There's a similar bug in find_nth()
in iflib.c.
freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to