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

[Nick Hudson <nick.hudson%gmx.co.uk@localhost>]

The following reply was made to PR port-arm/54696; it has been noted by GNATS.

From: Nick Hudson <nick.hudson%gmx.co.uk@localhost>
To: sc.dying%gmail.com@localhost, gnats-bugs%netbsd.org@localhost,
 port-evbarm-maintainer%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
 netbsd-bugs%netbsd.org@localhost, dhop%nwlink.com@localhost
Cc: 
Subject: Re: port-evbarm/54696: Kernel panic in bus_dma.c on Raspberry Pi
 3B/3B+
Date: Sat, 23 Nov 2019 14:30:56 +0000

 On 23/11/2019 14:10, sc.dying%gmail.com@localhost wrote:
 > On 2019/11/23 10:25, Nick Hudson wrote:
 >> On 14/11/2019 22:35, sc.dying%gmail.com@localhost wrote:
 >> [snip]
 >>
 >>>  =C2=A0 But the transfer length of isoc xfer is sum of xfer->ux_frleng=
 ths[i]
 >>>  =C2=A0 where i =3D 0.. xfer->ux_nframes - 1, not zero.
 >>>  =C2=A0 dwc2 should do this usb_syncmem if xfertype =3D=3D UE_{INTERRU=
 PT,BULK},
 >>>  =C2=A0 UE_CONTROL that has data phase (that is, len !=3D 0), or if xf=
 ertype =3D=3D
 >>>  =C2=A0 UE_ISOCHRONOUS, should do usb_syncmem for each chunk of ux_frl=
 engths.
 >>>
 >>>  =C2=A0 However, the uaudio works with dwc2 even if avobe usb_syncmem =
 is ignored.
 >>>  =C2=A0 I think dwc2 does usb_syncmem for isoc data buf somewhere else=
 , but
 >>>  =C2=A0 I'm not sure where it is.
 >>
 >> Please try this patch
 >
 > I did s/ux_ux_nframes/ux_nframes/.
 
 Oops.Thanks for spotting this.
 
 > It works with one of my uaudio devices.
 >
 > # audiocfg list
 > 0: [*] audio0 @ uaudio0: USB audio
 >         playback: 2ch, 44100Hz
 >         record:   2ch, 44100Hz
 >         (-R) slinear_le 16/16, 2ch, { 44100 }
 >         (P-) slinear_le 16/16, 2ch, { 44100 }
 >
 > With another one
 >
 > 0: [*] audio0 @ uaudio0: USB audio
 >         playback: 2ch, 48000Hz
 >         record:   unavailable
 >         (P-) slinear_le 16/16, 2ch, { 48000, 44100 }
 >
 > the kernel prints number of messages, as David reported.
 >
 >> uaudio_chan_pintr: count(40) !=3D size(1920)
 >
 > The length of each chunk in this transfer is
 > 48000(kHz) x 2(bytes/chan) x 2(chans) / 1000(frames/s) =3D 192.
 > dwc2_get_actual_xfer_length() should return 192, but 4.
 > nframes is 10, so ux_length is 40.
 >
 > If !DIAGNOSTIC, this messages are suppresssed and the kernel
 > plays music clearly.
 
 Not sure I follow what's going on here... did you have a DWC2_DEBUG log
 for the device that triggers the uaudio_chan_pintr count !=3D size warning=
 ?
 
 I'll commit the fixed up diff if you agree.
 
 Thanks,
 Nick