port-evbarm/54696: Kernel panic in bus_dma.c on Raspberry Pi 3B/3B+

[dhop%nwlink.com@localhost]

>Number:         54696
>Category:       port-evbarm
>Synopsis:       Kernel panic in bus_dma.c on Raspberry Pi 3B/3B+
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    port-evbarm-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Nov 13 07:40:00 +0000 2019
>Originator:     David Hopper
>Release:        NetBSD-9BETA (several builds)
>Organization:
>Environment:
GENERIC64 (aarch64 on RPI3B+), several kernel builds
>Description:
Kernel panic on playing audio of any kind through a Class-1 USB audio device on a Raspberry Pi 3B+.  Tested with Puredata (pd) and sox (play), both compiled cleanly from the 11/10 pkgsrc-current.  This is the only audio interface on this device, and I do not know if this is an audio issue, a _USB_ audio issue or an alignment issue of some kind.  The error seems to come from bus_dma.c:

[   153.534940] panic: kernel diagnostic assertion "len > 0 && offset + len <= map->dm_mapsize" failed: file "/usr/src/sys/arch/arm/arm32/bus_dma.c", line 1058 len 0 offset 0 mapsize 8192
[   153.544936] cpu3: Begin traceback...
[   153.554937] trace fp ffffffc0331d79f0
[   153.554937] fp ffffffc0331d7a10 vpanic() at ffffffc000366248 netbsd:vpanic+0x198
[   153.564940] fp ffffffc0331d7a70 kern_assert() at ffffffc00048f904 netbsd:kern_assert+0x5c
[   153.574944] fp ffffffc0331d7b00 _bus_dmamap_sync() at ffffffc000016214 netbsd:_bus_dmamap_sync+0x12c
[   153.584943] fp ffffffc0331d7b70 dwc2_device_start() at ffffffc000213408 netbsd:dwc2_device_start+0x140
[   153.594951] fp ffffffc0331d7bf0 dwc2_device_isoc_transfer() at ffffffc0002138ec netbsd:dwc2_device_isoc_transfer+0x3c
[   153.604950] fp ffffffc0331d7c10 usbd_transfer() at ffffffc00004c370 netbsd:usbd_transfer+0x98
[   153.614954] fp ffffffc0331d7c40 uaudio_trigger_input() at ffffffc00005610c netbsd:uaudio_trigger_input+0xac
[   153.624957] fp ffffffc0331d7c70 audio_rmixer_input() at ffffffc0001dd828 netbsd:audio_rmixer_input+0x80
[   153.634958] fp ffffffc0331d7cd0 audio_rmixer_start() at ffffffc0001dd9a8 netbsd:audio_rmixer_start+0x30
[   153.644961] fp ffffffc0331d7d00 audioread() at ffffffc0001e226c netbsd:audioread+0x6d4
[   153.654963] fp ffffffc0331d7da0 dofileread() at ffffffc0003737d8 netbsd:dofileread+0x70
[   153.664966] fp ffffffc0331d7e20 syscall() at ffffffc000028bcc netbsd:syscall+0x19c
[   153.664966] tf ffffffc0331d7ed0 el0_trap() at ffffffc0000272b8 netbsd:el0_trap
[   153.674964] ---- trapframe 0xffffffc0331d7ed0 (304 bytes) ----
[   153.684968] pc=0000f18c17b98378,   spsr=0000000020000000
[   153.684968] esr=0000000056000003,    far=0000ffffffdd69b0
[   153.694965] x0=0000000000000005,     x1=0000ffffffdd7bd8
[   153.694965] x2=0000000000000100,     x3=0000000000000000
[   153.704967] x4=ffffffffffffffff,     x5=ffffffffffffffff
[   153.714968] x6=000000000000ac44,     x7=00000000ffffffff
[   153.714968] x8=0000000000000018,     x9=0000000000001003
[   153.724970] x10=000000000000000c,    x11=0000000000000001
[   153.724970] x12=0000000000000000,    x13=000003c6305ed158
[   153.734970] x14=00000000001742c8,    x15=0000f18c17b45600
[   153.734970] x16=0000f18c17f81658,    x17=0000f18c17b98374
[   153.744972] x18=0000f18c17f8d820,    x19=0000f18c17f81000
[   153.754972] x20=0000f18c17fe5800,    x21=000000020019ffb0
[   153.754972] x22=0000000000000005,    x23=0000000000000001
[   153.764973] x24=0000ffffffdd7bc0,    x25=0000ffffffdd9c40
[   153.764973] x26=00000002001a0000,    x27=000000020019f000
[   153.774974] x28=0000ffffffdd9c50, fp=x29=0000000000000000
[   153.774974] lr=x30=0000f18c17f68484,     sp=0000ffffffdd7af0
[   153.784976] ------------------------------------------------
[   153.794976] cpu3: End traceback...

If we need more from this I'll have a serial device in a couple days.  I can confirm that this issue does not occur with earmv7hf/6hf, I've only seen it with aarch64 images from Jared McNeill and the several I've compiled myself from -current tracking back to mid-October. 
>How-To-Repeat:
Using a Class-1 USB audio device (I have a Behringer UCA222), try to play audio from a Raspberry Pi 3B or 3B+ (happens on both) using the aarch64 GENERIC64 kernel.
>Fix: