On Thu, May 28, 2020 at 01:41:43PM +0100, Stuart Henderson wrote:
> No idea if related to the hangs I saw earlier, but I've just hit a
> uaudio-related kernel crash when starting to play a video in firefox.
>
> RA\xaf\xdeRA\xaf\xdeRA\xaf\xdeRA\xaf\xdeRA\xaf\xdeRA\xaf\xdeRA\xaf\xde: can't
> set interface
> kernel: protection fault trap, code=0
> Stopped at uaudio_stream_close+0x8a: movzbl 0x8(%r12),%esi
> ddb{3}> [-- sthen@localhost attached -- Thu May 28 11:58:19 2020]
>
> Note that RA\xaf\xde is 52 41 af de; case 3 of poison_value() in
> kern/subr_poison.c
> gives us
>
> $ echo '(POISON1 & 0xffff0000) | (~POISON1 & 0x0000ffff)' | sed
> s/POISON1/0xdeafbead/g | moo
> 0xdeaf4152
>
> (aren't you glad this is serial console not screenshots :)
Indeed.
> uaudio0 at uhub7 port 2 configuration 1 interface 1 "GN Netcom GN 9350" rev
> 2.00/1.00 addr 7
> uaudio0: class v1, full-speed, sync, channels: 1 play, 1 rec, 4 ctls
> audio1 at uaudio0
> uhidev0 at uhub7 port 2 configuration 1 interface 3 "GN Netcom GN 9350" rev
> 2.00/1.00 addr 7
> uhidev0: iclass 3/0
> uhid0 at uhidev0: input=2, output=2, feature=0
> uaudio0: can't reset interface
> uaudio0: can't reset interface
> audio1 detached
> uaudio0 detached
> uhid0 detached
> uhidev0 detached
> RA\xaf\xdeRA\xaf\xdeRA\xaf\xdeRA\xaf\xdeRA\xaf\xdeRA\xaf\xdeRA\xaf\xde: can't
> set interface
> kernel: protection fault trap, code=0
> Stopped at uaudio_stream_close+0x8a: movzbl 0x8(%r12),%esi
> ddb{3}> [-- sthen@localhost attached -- Thu May 28 11:58:19 2020]
>
> ddb{3}>
> ddb{3}> tr
> uaudio_stream_close(ffff800001dfb000,1) at uaudio_stream_close+0x8a
> uaudio_stream_open(ffff800001dfb000,1,ffff8000001e8000,ffff8000001eaa80,2a8,ffffffff816f7630)
> at uaudio_stream_open+0x761
> uaudio_trigger_output(ffff800001dfb000,ffff8000001e8000,ffff8000001eaa80,2a8,ffffffff816f7630,ffff800001e95c00)
> at uaudio_trigger_output+0x47
> audio_start_do(ffff800001e95c00) at audio_start_do+0xb5
> audioioctl(2a01,20004126,ffff800035a74470,7,ffff800034fe6750) at
> audioioctl+0x71
> VOP_IOCTL(fffffd867a72e9e0,20004126,ffff800035a74470,7,fffffd84fea6f9c0,ffff800034fe6750)
> at VOP_IOCTL+0x55
> vn_ioctl(fffffd867d490f10,20004126,ffff800035a74470,ffff800034fe6750) at
> vn_ioctl+0x75
> sys_ioctl(ffff800034fe6750,ffff800035a74580,ffff800035a745e0) at
> sys_ioctl+0x2df
> syscall(ffff800035a74650) at syscall+0x389
> Xsyscall() at Xsyscall+0x128
> end of kernel
I think the above happened because the audio device was not fully
drained of users before it got destroyed. Possibly uaudio_stream_open()
got blocked and then the device was detached. Once uaudio_stream_open()
resumed, the device was gone.
Unfortunately, the kernel has no unified way to do the draining. Maybe
uaudio(4) could adopt more of the tricks that some other USB device
drivers use to manage with detaching devices.
