All of lore.kernel.org
 help / color / mirror / Atom feed
From: Geraldo Nascimento <geraldogabriel@gmail.com>
To: "Geoffrey D. Bennett" <g@b4.vu>
Cc: alsa-devel@alsa-project.org
Subject: Re: [BUG] ALSA: usb-audio: Scarlett 2 mixer driver fails on ehci-pci
Date: Mon, 17 May 2021 19:13:27 -0300	[thread overview]
Message-ID: <CAEsQvcuMK5n4F++bXCD4ML5FoRQ+KCp5soXAY8mjUpf6yqYXBQ@mail.gmail.com> (raw)
In-Reply-To: <20210517172553.GA85102@m.b4.vu>

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@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.

  reply	other threads:[~2021-05-17 22:20 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-17 17:25 [BUG] ALSA: usb-audio: Scarlett 2 mixer driver fails on ehci-pci Geoffrey D. Bennett
2021-05-17 22:13 ` Geraldo Nascimento [this message]
2021-05-18 18:34   ` Geoffrey D. Bennett
2021-05-18 21:41     ` Geraldo Nascimento
2021-05-20 18:14       ` Geoffrey D. Bennett
2021-05-20 20:00         ` Geraldo Nascimento

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAEsQvcuMK5n4F++bXCD4ML5FoRQ+KCp5soXAY8mjUpf6yqYXBQ@mail.gmail.com \
    --to=geraldogabriel@gmail.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=g@b4.vu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.