[BUG] ALSA: usb-audio: Scarlett 2 mixer driver fails on ehci-pci

[Geoffrey D. Bennett]

Hi Geraldo,

Thanks for your suggestion. I found:

echo module ehci_hcd +p > /sys/kernel/debug/dynamic_debug/control

which I guess is the same thing.

I can't see any difference between the sent USB packet working and not
working with the additional debug:

kernel: ehci-pci 0000:00:1d.0: submit_async 1.2 urb 000000004f9d8dbb ep0out len 24, qtd 0000000055a1f6c8 [qh 00000000312c985a]
kernel: ehci-pci 0000:00:1d.0: ehci_urb_done 1.2 urb 000000004f9d8dbb ep0out status -115 len 0/24

kernel: ehci-pci 0000:00:1d.0: submit_async 1.2 urb 00000000de165beb ep0out len 24, qtd 0000000056de0c60 [qh 00000000d43a72d3]
kernel: ehci-pci 0000:00:1d.0: ehci_urb_done 1.2 urb 00000000de165beb ep0in status 0 len 24/24

I agree that the issue seems more related to USB kernel development; I
will subscribe to linux-usb and ask there.

Thanks,
Geoffrey.

On Mon, May 17, 2021 at 07:13:27PM -0300, Geraldo Nascimento wrote:
> Hi, Geoffrey, have you tried adding "ehci_hcd.dyndbg=+p" to your
> kernel boot options?
> 
> It will give you additional debugging information, and if you need
> more debugging information you can always use printk() and recompile
> your modules.
> 
> Note that your issue seems more related to USB kernel development than
> ALSA development, still, impossible to say where the fix will land
> without tracing the problem first.
> 
> Best of luck,
> Geraldo Nascimento
> 
> On Mon, May 17, 2021 at 2:27 PM Geoffrey D. Bennett <g at b4.vu> wrote:
> >
> > Hi there,
> >
> > I'm trying to track down an issue with my Scarlett Gen 2 mixer driver
> > that has been reported by a few people, and I can now reliably
> > reproduce the issue, but I need some help in figuring out where
> > exactly the issue is and how to fix it please.
> >
> > The issue only occurs when attempting to use the interface on a USB
> > port using ehci-pci. xhci_hcd USB ports work fine.
> >
> > The issue occurs when sending the first vendor-specific USB command,
> > but only when sending from the kernel driver. Sending the same USB
> > packets from user-space works fine(!).
> >
> > I did initially think that the fault could have been due to earlier
> > USB messages putting the device into a state where it would reject the
> > vendor-specific USB commands, but I have carefully ruled that out &
> > have gotten identical usbmon traces from device power-on up until the
> > device responds differently, the only difference beforehand being
> > whether the USB packet was sent from the kernel driver or user-space.
> >
> > The messages look like this in "usbmon -s 10000 -fu" when sent from
> > user-space (or when sent from the kernel driver when the interface is
> > plugged in to an xhci_hcd port):
> >
> > ffff888125855200 1006026497 S Ci:2:040:0 s a1 00 0000 0005 0018 24 <
> > ffff888125855200 1006026680 C Ci:2:040:0 0 24 = 66191018 73190604 01000000 01000000 00040000 00000000
> >
> > And like this when sent from the kernel driver when the interface is
> > plugged in to an ehci-pci port:
> >
> > ffff88810487a300 3686673995 S Ci:2:036:0 s a1 00 0000 0005 0018 24 <
> > ffff88810487a300 3692178724 C Ci:2:036:0 -2 0
> >
> > Identical messages sent according to usbmon, but they must be
> > different somehow!
> >
> > The kernel code to send that message looks like this:
> >
> >   return snd_usb_ctl_msg(
> >     dev, usb_sndctrlpipe(dev, 0),
> >     usb_req,
> >     USB_RECIP_INTERFACE | USB_TYPE_CLASS | USB_DIR_IN,
> >     0, interface, buf, size);
> >
> > and helper.c snd_usb_ctl_msg() then calls usb_control_msg().
> >
> > For sending arbitrary USB packets from user-space for testing, I'm
> > using libusb and:
> >
> >   int ret = usb_control_msg(
> >     devh, reqtype, request, value, index, buf, size, 1000
> >   );
> >
> > So, I presume usbmon isn't giving me the full story? How can I
> > determine the difference between the kernel and the user-space
> > usb_control_msg() functions? I see that I can #define EHCI_URB_TRACE
> > in ehci-hcd.c. Can anyone with more experience than me let me know if
> > I'm going in the right direction to track this down?
> >
> > Thanks,
> > Geoffrey.