2021-06-13 06:41:36

by Salvatore Bonaccorso

Subject: Regression in at least 5.10.y and mainline: Firewire audio interface fails to work properly (when booted under Xen)

Hi,

On Sun, Jun 13, 2021 at 06:05:37AM +1000, 小太 wrote:
> Package: src:linux
> Version: 5.10.40-1
> Severity: normal
> Tags: upstream
> X-Debbugs-Cc: [email protected]
>
> After updating from linux-image-5.10.0-6-amd64, jackd now fails to sync to my
> DICE-compatible firewire audio interface (Profire 610), with the following
> error messages (full log attached):
>
> > $ jackd -d firewire -v
> > jackdmp 1.9.12
> > ...snip...
> > 00301056761: Warning (StreamProcessorManager.cpp)[ 913] alignReceivedStreams:
> xrun while aligning streams...
> > 00301056793: Error (StreamProcessorManager.cpp)[ 877] syncStartAll: Could not
> align streams...
> > 00301056829: Fatal (StreamProcessorManager.cpp)[1025] start: Could not
> syncStartAll...
> > 00301400626: Warning (TimestampedBuffer.cpp)[ 248] calculateRate: (0x1fa5a20)
> rate ( 708.18713) more that 10% off nominal (rate= 512.00000, diff=
> 5665.497, update_period=8)
> > 00301416642: Warning (TimestampedBuffer.cpp)[ 248] calculateRate: (0x1fa5a20)
> rate ( 686.49011) more that 10% off nominal (rate= 512.00000, diff=
> 5491.921, update_period=8)
> > 00301416925: Warning (devicemanager.cpp)[ 925] startStreaming: Failed to
> start SPM!
> > firewire ERR: Could not start streaming threads
> > Cannot start driver
> > JackServer::Start() failed with -1
> > 00301424329: Warning (ieee1394service.cpp)[1509] freeIsoChannel: Channel 1
> not registered
> > 00301424360: Error (dice_avdevice.cpp)[1440] startstopStreamByIndex: Could
> not deallocate iso channel for SP 1 (ARX 0)
> > 00301424397: Warning (devicemanager.cpp)[ 959] stopStreamingOnDevice: Could
> not stop stream 1 of device 0x1f6e600
> > 00301424406: Warning (devicemanager.cpp)[ 931] startStreaming: Could not stop
> streaming on device 0x1f6e600!
> > 00301424429: Fatal (ffado.cpp)[ 220] ffado_streaming_start: Could not start
> the streaming system
> > Failed to start server
> > no message buffer overruns
>
> Additionally, I also tried using the snd-dice driver to expose the audio
> interface directly in ALSA. While the interface did appear and was usable
> there, all inputs came out of my speakers highly distorted, with channels
> bleeding into each other - practically unusable.
>
> I've reproduced the issue on upstream kernel version v5.13-rc5+
> (ad347abe4a9876b1f65f408ab467137e88f77eb4), and bisected the first bad commit
> down to 85a5a6875ca93dc4efbf20df942ba41d27a917e3.
>
> To double check commit 85a5a6875ca93dc4efbf20df942ba41d27a917e3 was indeed the
> issue, I built the latest v5.10 kernel v5.10.43 with the commit reverted, and
> indeed the issue went away.
> Unfortunately, the reverse patch would not apply to v5.13-rc5+, since it seems
> like the file has changed too much.

A user in Debian reported the above issue, which was reproducible with
5.13-rc5 and 5.10.y as packaged in Debian and found that 85a5a6875ca9
("swiotlb: don't modify orig_addr in swiotlb_tbl_sync_single") that
introduced the issue.

The full bug log is at https://bugs.debian.org/989778

I'm CC'ing as well the xen-devel list, as it appears from
https://bugs.debian.org/989778#10 that the issue is only exposed when booting
under Xen.

Any ideas?

Regards,
Salvatore

2021-06-14 13:31:33

by Robin Murphy

Subject: Re: Regression in at least 5.10.y and mainline: Firewire audio interface fails to work properly (when booted under Xen)

On 2021-06-13 07:29, Salvatore Bonaccorso wrote:
> A user in Debian reported the above issue, which was reproducible with
> 5.13-rc5 and 5.10.y as packaged in Debian and found that 85a5a6875ca9
> ("swiotlb: don't modify orig_addr in swiotlb_tbl_sync_single") that
> introduced the issue.

Sounds like it's probably the same thing as being discussed over here:

https://lore.kernel.org/linux-iommu/[email protected]/

Robin.

2021-06-23 18:51:37

by Salvatore Bonaccorso

Subject: Re: Bug#989778: Regression in at least 5.10.y and mainline: Firewire audio interface fails to work properly (when booted under Xen)

Hi Robin,

On Mon, Jun 14, 2021 at 02:29:08PM +0100, Robin Murphy wrote:
> On 2021-06-13 07:29, Salvatore Bonaccorso wrote:
> > A user in Debian reported the above issue, which was reproducible with
> > 5.13-rc5 and 5.10.y as packaged in Debian and found that 85a5a6875ca9
> > ("swiotlb: don't modify orig_addr in swiotlb_tbl_sync_single") that
> > introduced the issue.
>
> Sounds like it's probably the same thing as being discussed over here:
>
> https://lore.kernel.org/linux-iommu/[email protected]/

Thanks for the pointer, it seems that now it has been fixed upstream
with 5f89468e2f06 ("swiotlb: manipulate orig_addr when tlb_addr has
offset").

Regards,
Salvatore