Bug 217084

The VS-100 stopped working already in in kernel 5.15. here is another alsa-info (same desktop system of the working configuration, but with kernel 5.15):

http://alsa-project.org/db/?f=6b87c7f7307ed0f04ae8d9421777968e7498bae4

dmesg output when powering on the device:

[ 2544.908132] usb 1-6: new high-speed USB device number 10 using xhci_hcd
[ 2545.057294] usb 1-6: New USB device found, idVendor=0582, idProduct=00eb, bcdDevice= 1.00
[ 2545.057307] usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 2545.057313] usb 1-6: Product: VS-100 Audio/MIDI
[ 2545.057317] usb 1-6: Manufacturer: Roland
[ 2545.057321] usb 1-6: SerialNumber: SA17781

aplay and arecord don't work:

alberto@XPS8940:~$ aplay -D plughw:AudioMIDI -f S24_3LE -r 44100 -c 2 ./file.wav
aplay: main:852: audio open error: No such file or directory
alberto@XPS8940:~$ arecord -D plughw:AudioMIDI -f S24_3LE -r 44100 -c 2 ./file.wav
arecord: main:852: audio open error: No such file or directory

(In reply to Alberto Zin from comment #0)

> I'm willing to help testing as much as I can.

It would be good to know 

- if the latest kernel (6.2.1) also fails
- if this ever worked with a upstream kernel (5.6.0-1055-oem sounds a lot like it is a patched kernel)

A bisection would be ideal and might be needed later.

Created attachment 303797 [details]
attachment-24097-0.html

Hi Thorsten, thanks for your help. So far I tried the following kernels
(ubuntu/canonical ones, not really upstream, - I'm on Mint - don't know if
this is critical or not..). The issue is more complicated than I thought at
the beginning:

linux-image-5.4.0-58-generic/focal-updates,focal-security,now 5.4.0-58.64
amd64 [installed]: works fine (play, record, all I/O)
linux-image-5.4.0-139-generic/focal-updates,focal-security,now
5.4.0-139.156 amd64 [installed,automatic]: not working, VS-100 not listed
by aplay -l (& no sound)
linux-image-5.6.0-1055-oem/focal-updates,focal-security,now 5.6.0-1055.59
amd64 [installed,auto-removable]: works fine (play, record, all I/O)
linux-image-5.8.0-63-generic/focal-updates,focal-security,now
5.8.0-63.71~20.04.1 amd64 [installed]: not working, VS-100 not listed by
aplay -l (& no sound)
linux-image-5.11.0-46-generic/focal-updates,focal-security,now
5.11.0-46.51~20.04.1 amd64 [installed]: not working, VS-100 not listed by
aplay -l (& no sound)
linux-image-5.15.0-60-generic/focal-updates,focal-security,now
5.15.0-60.66~20.04.1 amd64 [installed]: not working, VS-100 not listed by
aplay -l (& no sound)
I still have to try the 6.2.1 upstream.

In all above cases the card is listed in  /proc/asound/cards
 1 [AudioMIDI      ]: USB-Audio - VS-100 Audio/MIDI
                      Roland VS-100 Audio/MIDI at usb-0000:00:14.0-6, high
speed
 2 [NVidia         ]: HDA-Intel - HDA NVidia
                      HDA NVidia at 0xc5080000 irq 17

I tried to use dyndbg in the snd_usb_audio but it seems that all those
kernels are not really "liking" it: i.e. when snd_usb_audio module is not
in use doing a whole deregister/register module cycle ("sudo modprobe -r
snd-usb-audio" followed by "sudo modprobe snd_usb_audio dyndbg=+p") prints
only this few lines on dmesg:

[  884.893620] usbcore: deregistering interface driver snd-usb-audio
[  903.955848] mc: Linux media interface: v0.10
[  903.961768] usb 1-6: Found last interface = 2
[  903.963381] usbcore: registered new interface driver snd-usb-audio

If running upsteam kernels is necessary I'll try to set them up in Linux
Mint.
I'll report the results of testing the 6.2.1.
Anything else I can try?
Alberto


Il giorno lun 27 feb 2023 alle ore 11:20 <bugzilla-daemon@kernel.org> ha
scritto:

> https://bugzilla.kernel.org/show_bug.cgi?id=217084
>
> The Linux kernel's regression tracker (Thorsten Leemhuis) (
> regressions@leemhuis.info) changed:
>
>            What    |Removed                     |Added
>
> ----------------------------------------------------------------------------
>                  CC|                            |regressions@leemhuis.info
>
> --- Comment #2 from The Linux kernel's regression tracker (Thorsten
> Leemhuis) (regressions@leemhuis.info) ---
> (In reply to Alberto Zin from comment #0)
>
> > I'm willing to help testing as much as I can.
>
> It would be good to know
>
> - if the latest kernel (6.2.1) also fails
> - if this ever worked with a upstream kernel (5.6.0-1055-oem sounds a lot
> like
> it is a patched kernel)
>
> A bisection would be ideal and might be needed later.
>
> --
> You may reply to this email to add a comment.
>
> You are receiving this mail because:
> You reported the bug.

(In reply to Alberto Zin from comment #3)
>
> If running upsteam kernels is necessary I'll try to set them up in Linux
> Mint.

It depends on the developer, but Ubuntu's kernel are known to be heavily patched, which makes things hard -- hence many developer stay away from it. Might be even a good idea to close this bug and open a new one where you only focus on mainline kernels, as too many distracting details about vendor kernels make things hard to follow.

Best approach for testing afaics: test latest 6.2.y kernel; if it's not working, try 5.4.58; if it's working, check latest 5.4.y kernel if that also fails. Then report back, but we might need a bisection later.

Update March 2, 2023: 
I took the vanilla kernel and compiled myself. I took them from offcial source:
https://mirrors.edge.kernel.org/pub/linux/kernel/
(The compilation was done with default kernel options).

So far I compiled and tried 

- vanilla kernel 5.4.59 (not patched) ==> VS-100 works fine!
- vanilla kernel 5.4.233 (not patched) ==> not working, VS-100 listed in aconnect -l and lsusb, but not listed by aplay -l (& no sound).



Concerning kernels 6.x:
I cannot compile the kernel 6.2.x my the current system (Mint 20.1, dependency on libc not satisfied)
I tried kernel 6.1 from a live distro (manjaro, from dec. 2022) ==> no sound.

What's your advice? 

Thanks.
Alberto

(In reply to Alberto Zin from comment #5)
> What's your advice? 

Now that you confirmed that this happens with vanilla kernels as well I'll leave things to the alsa developers. I just forwarded this bug to them to ensure they see it: https://lore.kernel.org/regressions/19284aff-436a-5130-5126-8ccdd1af476d@leemhuis.info/

Could you attach also output from 'lsusb -v -d 0582:00eb' (as root) ?

Are you able to compile own kernel with a debug patch ?

Created attachment 303835 [details]
verbose lsusb on 5.4.59 kernel (working VS-100)

verbose lsusb on 5.4.59 kernel (vanilla, working VS-100) as root. Working case. 
Non working kernel on VS-100 produces an almost exact output.

(In reply to Jaroslav Kysela from comment #7)
> Could you attach also output from 'lsusb -v -d 0582:00eb' (as root) ?

Hi Jaroslav, thanks for the support. The verbose lsusb output in in attachment to the bug.

> Are you able to compile own kernel with a debug patch ?

probably yes, but depends on which kernel: on my installed linux distribution (Mint 20.1) I've tried to compile the 6.2.1 kernel without success (I've a libc compatibility issue). 5.x kernels seems fine. In any case, if you have a patch and want me to try I'll arrange a way. Thanks,
Alberto

This looks like Edirol M-16DX (USB ID 0582:00c4).

Could you try this snd-usb-audio kernel module setup with the recent (6.x) kernels?

   echo "options snd-usb-audio quirk_alias=058200eb:058200c4" > /etc/modprobe.d/alsa-test.conf
   reboot

Hi Jaroslav, I couldn't try your suggestion on a 6.2.x kernel (got compilation errors on that kernel and live distros with 6.x seem not an option due to the reboot). 
I tried on a kernel 5.15.x one on my Linux Mint, by adding the line you suggested to my /etc/modprobe.d/alsa-base.conf (no need for alsa-test.conf). After unloading and reloading the snd-usb-audio (with "sudo modprobe snd_usb_audio dyndbg=+p") I got in dmesg:

[  199.267641] usbcore: deregistering interface driver snd-usb-audio
[  211.651484] mc: Linux media interface: v0.10
[  211.657225] usb 1-6: device (0582:00eb): applying quirk alias 0582:00c4
[  211.657449] usb 1-6: Found last interface = 2
[  211.659101] usbcore: registered new interface driver snd-usb-audio

==> the quirk alias seems correctly applied, but VS-100 does not show up in the devices (in aplay -l for example) and no sound. Is the reboot really needed? Unloading-loading should do the same, correct? 

Other ideas? Thanks, Alberto

(In reply to Alberto Zin from comment #11)
> Hi Jaroslav, I couldn't try your suggestion on a 6.2.x kernel (got
> compilation errors on that kernel and live distros with 6.x seem not an
> option due to the reboot). 
> I tried on a kernel 5.15.x one on my Linux Mint, by adding the line you
> suggested to my /etc/modprobe.d/alsa-base.conf (no need for alsa-test.conf).
> After unloading and reloading the snd-usb-audio (with "sudo modprobe
> snd_usb_audio dyndbg=+p") I got in dmesg:
> 
> [  199.267641] usbcore: deregistering interface driver snd-usb-audio
> [  211.651484] mc: Linux media interface: v0.10
> [  211.657225] usb 1-6: device (0582:00eb): applying quirk alias 0582:00c4
> [  211.657449] usb 1-6: Found last interface = 2
> [  211.659101] usbcore: registered new interface driver snd-usb-audio
> 
> ==> the quirk alias seems correctly applied, but VS-100 does not show up in
> the devices (in aplay -l for example) and no sound. Is the reboot really
> needed? Unloading-loading should do the same, correct? 
> 
> Other ideas? Thanks, Alberto

Not that it should work since it didn't work with your 5.15.x kernel, but you could try running as root "modprobe -r snd-usb-audio; modprobe snd-usb-audio quirk_alias=058200eb:058200c4 dyndbg=+p" on a live CD with a 6.x kernel, to test on that kernel without compilation.

I hope that furthers the knowledge,

  Lucas

Hmm, this looks stuck and I wonder how we can get things moving again.

(In reply to Alberto Zin from comment #9)

> on my installed linux
> distribution (Mint 20.1) I've tried to compile the 6.2.1 kernel without
> success (I've a libc compatibility issue).

The kernel should care about the libc. Can you maybe briefly describe the problem? With a bit of luck there is a easy way to work around it, so that we can move on with debugging the real problem.

There is still too little information.  The alsa-info.sh outputs in the description are from the older versions of the script, hence they lack of the important piece about the USB audio (the /proc/asound/card*/stream* and /proc/asound/card*/usbmixer).  Please retake the alsa-info.sh outputs from the working and non-working cases again with the latest script.

Also, boot with snd_usb_audio.dyndbg=+p option and get the dmesg output with USB-audio plugged for both working and non-working cases, too.

Hello, alsa-info.sh, (v 0.51), run as superuser:

working case:

http://alsa-project.org/db/?f=68f0c660c96385424e65672c79eed0447cb23687

non-working case:

http://alsa-project.org/db/?f=0fa0627d036800032302b5aa48631cf33fee7401

next message I'll post the dmesg output when booting with snd_usb_audio.dyndbg=+p

Looking at my verbose lsusb (attached) and trying to learn how quirk works here and there, I ended up with the attached "VS-100-quirk-simple-proposal.txt". Before I try to put in a custom kernel, I'm asking to you experienced developers if that makes any sense to you. Thanks for the advice.   

Thanks, Alberto

Created attachment 303971 [details]
VS-100-quirk-simple-proposal.txt

see comment 12 (or 13...)

Update. I got a successful compilation of vanilla kernel 6.2.2 with my quirk included (previously I was missing zstd package that caused compilation errors). 
The boot on this new kernel complained about nvidia graphic card drivers (but that is I guess). aplay -l now shows the VS-100 back again:

alberto@XPS8940:~$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: PCH [HDA Intel PCH], device 0: Generic Analog [Generic Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 3: Generic Digital [Generic Digital]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: AudioMIDI [VS-100 Audio/MIDI], device 0: USB Audio [USB Audio]
  Subdevices: 0/1
  Subdevice #0: subdevice #0
card 2: NVidia [HDA NVidia], device 3: HDMI 0 [HDMI 0]

etc..

but I got no sound from speaker-test or any way I try to play audio. So maybe I did 1 step in the right direction but there is something still preventing to use the board.
The new alsa info (v.51) is here:
http://alsa-project.org/db/?f=c29f09f5d6f9faea4a031193b9309253c9978fba

With the above solution, my dmesg got constantly filled with: 

[  275.472539] xhci_hcd 0000:00:14.0: WARN: buffer overrun event for slot 4 ep 2 on endpoint

until to turn off my VS-100, and dmesg stops spitting out these messages:

[  275.473437] usb 1-10: USB disconnect, device number 5

(In reply to Alberto Zin from comment #15)
> Hello, alsa-info.sh, (v 0.51), run as superuser:
> 
> working case:
> 
> http://alsa-project.org/db/?f=68f0c660c96385424e65672c79eed0447cb23687
> 
> non-working case:
> 
> http://alsa-project.org/db/?f=0fa0627d036800032302b5aa48631cf33fee7401

Thanks!

This might be the missing call of usb_driver_claim_interface().
Could you try the patch below?

Created attachment 303983 [details]
Test fix patch

(In reply to Alberto Zin from comment #19)
> With the above solution, my dmesg got constantly filled with: 
> 
> [  275.472539] xhci_hcd 0000:00:14.0: WARN: buffer overrun event for slot 4
> ep 2 on endpoint
> 
> until to turn off my VS-100, and dmesg stops spitting out these messages:
> 
> [  275.473437] usb 1-10: USB disconnect, device number 5

This is likely an issue of USB core side (either USB core code or XHCI driver), to be addressed in a different bugzilla entry once after the USB-audio quirk problem is fixed.

(In reply to Takashi Iwai from comment #20)
> 
> This might be the missing call of usb_driver_claim_interface().
> Could you try the patch below?

Hi Takashi, update: I imported your patch (and used my quirk) to compile the newest 6.2.7 kernel. The effect is the same as yesterday (VS-100 appears among the system sound outputs and inputs) but no output sound. The alsa-info 0.51 is here:
http://alsa-project.org/db/?f=6b80f34717e59aed2c8054d26840c808a416cb63

dmesg is still flooded with
[ 1018.200208] xhci_hcd 0000:00:14.0: WARN: buffer overrun event for slot 3 ep 2 on endpoint
[ 1018.200332] xhci_hcd 0000:00:14.0: WARN: buffer overrun event for slot 3 ep 2 on endpoint
etc.. (btw: I changed USB port..)

A small difference (that maybe I didn't notice yesterday): I started audacity (with alsa driver) and it seems I'm able to record a track with the microphone connected to VS-100. 
Jack is not yet able to start.
I'm still not sure that if quirk is properly filled with correct information...

Thanks again, alberto

Please try without your quirk but only with my patch at first.

I tried only the patch you provided, patching a Vanilla Kernel 6.2.6, but I only got "dummy audio" when booting on it. Interestingly though, the dmesg xhci_hcd are gone away, therefore they are caused by my quirk. Turning off and on the VS-100 I got on dmesg:

[   83.883692] usb 1-5: USB disconnect, device number 4
[   91.132162] usb 1-5: new high-speed USB device number 10 using xhci_hcd
[   91.281089] usb 1-5: New USB device found, idVendor=0582, idProduct=00eb, bcdDevice= 1.00
[   91.281102] usb 1-5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[   91.281108] usb 1-5: Product: VS-100 Audio/MIDI
[   91.281112] usb 1-5: Manufacturer: Roland
[   91.281116] usb 1-5: SerialNumber: SA17781
[   91.283983] snd-usb-audio: probe of 1-5:1.0 failed with error -16
[   91.284892] snd-usb-audio: probe of 1-5:1.1 failed with error -16

The alsa-info with this configuration is here:
http://alsa-project.org/db/?f=1cfb5d0cb541ddad02196b6faf3b4e71366beb82

(In reply to Alberto Zin from comment #25)
> I tried only the patch you provided, patching a Vanilla Kernel 6.2.6, but I
> only got "dummy audio" when booting on it.

OK, thanks for testing.  So the USB interface claiming was a red herring.
We need to dive deeply to see why the PCM device isn't created while MIDI is present.

Please scratch the patches, apply the debug patch below, and get the dmesg output with the device plugged?

Created attachment 303994 [details]
Patch to add debug prints

Hi Takashi, attached is the (limited) dmesg output of the kernel 6.2.5, patched only with the debug printouts. Please let me know if it contains useful information.

alberto

Created attachment 303998 [details]
dmesg debug prints (kernel 6.2.5)

Thanks!  The problem seems to be around parsing the audio format in the USB descriptor.  Let's go deeper there.

The revised debug patch is below.  Could you give the dmesg output with that one instead?

Created attachment 303999 [details]
Patch to add more debug prints

In attachment the dmesg of a newly compiled 6.2.8 kernel, with the patch of comment 31. Hope that it helps..

alberto

Created attachment 304001 [details]
relevant dmesg section of debug print patch v2

Thanks!  I believe I see the culprit now.  It's likely the fix in commit 43d5ca88dfcd35e43010fdd818e067aa9a55f5ba
    ALSA: usb-audio: Fix potential out-of-bounds shift

The device gives an invalid wFormatTag value (0x101), and the commit above makes it an error, to be more strict to the spec.

The patch below changes the behavior again to be more permissive.  Please give it a try.

Created attachment 304006 [details]
Test fix patch

BTW, the error from xhci might be still seen even if the fix patch above works.  In that case, it must be rather a problem in XHCI core side.

(In reply to Takashi Iwai from comment #34)
> Thanks!  I believe I see the culprit now.  It's likely the fix in commit
> 43d5ca88dfcd35e43010fdd818e067aa9a55f5ba
>     ALSA: usb-audio: Fix potential out-of-bounds shift
> The device gives an invalid wFormatTag value (0x101), and the commit above
> makes it an error, to be more strict to the spec.
> The patch below changes the behavior again to be more permissive.  Please
> give it a try.

Hi Takashi, almost there but not yet. I compiled your patch with a Kernel 6.2.8.  The VS-100 is back again in the output devices. Anyway no sound from speakers. dmesg is flooded again with messages every ~120 us:

[  372.067009] xhci_hcd 0000:00:14.0: WARN: buffer overrun event for slot 3 ep 2 on endpoint
[  372.067133] xhci_hcd 0000:00:14.0: WARN: buffer overrun event for slot 3 ep 2 on endpoint

The alsa-info for this case is here:
http://alsa-project.org/db/?f=277c4731f803c870a3a9b53e9aece123b81a3801  

PS. at the beginning, when booting the PC I can hear two short "crakles", probably when the usb is initialized. 

alberto

OK, then try to pass lowlatency=0 option to snd-usb-audio module at first.

Also, another thing you can try would be to build an old usb-audio driver for the new kernel: just sound/usb/* files just from 5.10.x kernel onto 6.2/6.3 kernel, i.e.:
  % cp /somewhere/linux-5.10.x/sound/usb/* /somewhere/linux-6.2.x/sound/usb/

And adjust the code slightly like below:

--- a/sound/usb/card.c
+++ b/sound/usb/card.c
@@ -59,7 +59,6 @@
 MODULE_AUTHOR("Takashi Iwai <tiwai@suse.de>");
 MODULE_DESCRIPTION("USB Audio");
 MODULE_LICENSE("GPL");
-MODULE_SUPPORTED_DEVICE("{{Generic,USB Audio}}");
 
 
 static int index[SNDRV_CARDS] = SNDRV_DEFAULT_IDX;     /* Index 0-MAX */
--- a/sound/usb/midi.c
+++ b/sound/usb/midi.c
@@ -1301,7 +1301,7 @@ static int snd_usbmidi_in_endpoint_create(struct snd_usb_midi *umidi,
                pipe = usb_rcvintpipe(umidi->dev, ep_info->in_ep);
        else
                pipe = usb_rcvbulkpipe(umidi->dev, ep_info->in_ep);
-       length = usb_maxpacket(umidi->dev, pipe, 0);
+       length = usb_maxpacket(umidi->dev, pipe);
        for (i = 0; i < INPUT_URBS; ++i) {
                buffer = usb_alloc_coherent(umidi->dev, length, GFP_KERNEL,
                                            &ep->urbs[i]->transfer_dma);
@@ -1390,7 +1390,7 @@ static int snd_usbmidi_out_endpoint_create(struct snd_usb_midi *umidi,
                pipe = usb_sndbulkpipe(umidi->dev, ep_info->out_ep);
        switch (umidi->usb_id) {
        default:
-               ep->max_transfer = usb_maxpacket(umidi->dev, pipe, 1);
+               ep->max_transfer = usb_maxpacket(umidi->dev, pipe);
                break;
                /*
                 * Various chips declare a packet size larger than 4 bytes, but


This should make it built.  The old driver behaves as lowlatency=0 of the new driver.

Created attachment 304015 [details]
Fix patch for the missing PCM device probe

A proper patch to be submitted, replacing the previous test fix patch.

Just to be sure: the previous test fix patch had some typo and it's corrected in the patch in comment 40.  Please verify that the problem persists with that version, too.

(In reply to Takashi Iwai from comment #41)
> Just to be sure: the previous test fix patch had some typo and it's
> corrected in the patch in comment 40.  Please verify that the problem
> persists with that version, too.

SUCCESS :-) !!!

alberto@XPS8940:~$ uname -r
6.2.7-custom

Alsa-info:  
http://alsa-project.org/db/?f=7fce7829f9faee2071bf0b57c3d13b9ae8c9eb05

No dmesg errors! 
In the next days I'll go through all the details and I'll try to tests that everything is fine. 

Thanks for your efforts, Takashi

alberto

Good to hear!  The patch has been already submitted and merged to my git tree.
I'm going to send a PR to Linus in this week, so that the fix will be included in 6.3-rc5 kernel.  Then it'll be backported to stable trees.

(In reply to Alberto Zin from comment #42)
> (In reply to Takashi Iwai from comment #41)
> > Just to be sure: the previous test fix patch had some typo and it's
> > corrected in the patch in comment 40.  Please verify that the problem
> > persists with that version, too.
> 
> SUCCESS :-) !!!
> 
> alberto@XPS8940:~$ uname -r
> 6.2.7-custom
> 
> Alsa-info:  
> http://alsa-project.org/db/?f=7fce7829f9faee2071bf0b57c3d13b9ae8c9eb05
> 
> No dmesg errors! 
> In the next days I'll go through all the details and I'll try to tests that
> everything is fine. 
> 
> Thanks for your efforts, Takashi
> 
> alberto

Great job you two!  It looked like a lot of compilations, so sufficient work, but luckily there was no need for bisection. I'm happy for you!

(In reply to Takashi Iwai from comment #43)
> Good to hear!  The patch has been already submitted and merged to my git
> tree.
> I'm going to send a PR to Linus in this week, so that the fix will be
> included in 6.3-rc5 kernel.  Then it'll be backported to stable trees.

That's great! then this will be brought back to 5.4.x and 5.15.x kernels I guess. I think you can safely close the bug.

(In reply to Lucas Endres from comment #44)
 
> Great job you two!  It looked like a lot of compilations, so sufficient work,
> > but luckily there was no need for bisection. I'm happy for you!

I did some kernel compilations, but without Takashi's support that would had never been solved (by myself, at least).  

alberto