Re: "panic: malloc(M_WAITOK) with sleeping prohibited" at main-n245363-b3dac3913dc9

On Tue, Mar 9, 2021 at 5:09 AM David Wolfskill <david_at_catwhisker.org> wrote:

> Just did a source-based  update from:
>
> FreeBSD 14.0-CURRENT #1205 main-n245338-221622ec0c8e: Mon Mar  8 03:49:58
> PST 2021     root_at_freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC
> amd64 1400005 1400005
>
> to:
>
> FreeBSD 14.0-CURRENT #1206 main-n245363-b3dac3913dc9: Tue Mar  9 03:55:00
> PST 2021
>     root_at_freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC
> amd64
>
> [latter scraped from the console]
>
> and:
>
> ...
> pass6 at umass-sim0 bus 0 scbus6 target 0 lun 0
> pass6: uhub3: 6 ports with 6 removable, self powered
> <Generic- Compact Flash 1.00> Removable Direct Access SCSI device
> pass6: Serial Number 20100818841300000
> pass6: 40.000MB/s transfersuhub4: 8 ports with 8 removable, self powered
>
> panic: malloc(M_WAITOK) with sleeping prohibited
> cpuid = 0
> time = 22
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> 0xfffffe00e157a4b0
> vpanic() at vpanic+0x181/frame 0xfffffe00e157a500
> panic() at panic+0x43/frame 0xfffffe00e157a560
> malloc_dbg() at malloc_dbg+0xd4/frame 0xfffffe00e157a580
> malloc() at malloc+0x34/frame 0xfffffe00e157a5e0
> disk_alloc() at disk_alloc+0x1c/frame 0xfffffe00e157a600
> daregister() at daregister+0x3f4/frame 0xfffffe00e157a880
> cam_periph_alloc() at cam_periph_alloc+0x57b/frame 0xfffffe00e157a950
> daasync() at daasync+0x2c2/frame 0xfffffe00e157a9c0
> xpt_async_process_dev() at xpt_async_process_dev+0x152/frame
> 0xfffffe00e157aa10
> xpt_async_process() at xpt_async_process+0x334/frame 0xfffffe00e157ab20
> xpt_done_process() at xpt_done_process+0x3a3/frame 0xfffffe00e157ab60
> xpt_done_td() at xpt_done_td+0xf5/frame 0xfffffe00e157abb0
> fork_exit() at fork_exit+0x80/frame 0xfffffe00e157abf0
> fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00e157abf0
> --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
> KDB: enter: panic
> [ thread pid 17 tid 100095 ]
> Stopped at      kdb_enter+0x37: movq    $0,0x128b97e(%rip)
> db>
>

The following reviews should fix this. It introduces a no-wait variant for
disk_alloc(), provides a way to free allocated, but not created, disks  and
changes CAM to use the new routines and take some care for not leaking when
an allocation fails.

https://reviews.freebsd.org/D29161
https://reviews.freebsd.org/D29162
https://reviews.freebsd.org/D29163

Maybe you can try it? I got similar tracebacks when I booted w/o these
changes, but not a peep with them...

Warner


>
> I can afford to leave it that way for a bit, in case anyone has
> suggestions for poking at it to get more information.  I expect to
> be attempting the same upgrade on a couple of laptops -- after they
> finish building firefox.
>
> Peace,
> david
> --
> David H. Wolfskill                              david_at_catwhisker.org
> It is supremely disingenuous to claim a lack of jurisdiction, then
> proceed to participate in a decision on the same matter.
>
> See https://www.catwhisker.org/~david/publickey.gpg for my public key.
>