Re: Slow enumeration of Creative Sound Blaster G3

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Nov 12, 2023 at 12:03:42PM +0100, Andreas Kempf wrote:
> On Sat, Nov 11, 2023 at 03:01:24PM -0500, Alan Stern wrote:
> > On Sat, Nov 11, 2023 at 05:58:08PM +0100, Andreas Kempf wrote:
> > > Hi,
> > > 
> > > I apologize if this is the wrong mailing list but my investigation
> > > led me to the USB subsystem and I do not know how to proceed.
> > > 
> > > My system:
> > > Arch Linux
> > > Linux kernel 6.6.1 (-arch1-1)
> > > Motherboard: ASRock X670E PG Lightning
> > > Device: Creative Sound Blaster G3
> > > 
> > > I have a Creative Technology Sound Blaster G3 USB sound device that
> > > seems to work perfectly on Windows. It used to work just fine on Linux,
> > > as well. However, at some point a few weeks ago, it started behaving
> > > oddly. Unfortunately, I cannot pinpoint exactly when the problems
> > > started happening because the symptoms did not immediately point me
> > > toward the device and I did not immediately figure out what was going
> > > on as I only noticed hangs when shutting down the system.
> > 
> > Did you update your kernel between the time when the device was
> > working okay and now?
> > 
> Unfortunately, I cannot really pinpoint when the issues started to
> appear, but on Arch Linux, almost every stable release gets picked up and
> a new kernel package is pushed every few days, so it is very likely.
> What confuses me, though, is that switching to a 6.1 LTS kernel did not
> seem to change anything.

If the problem was caused by a change in the kernel, the change might
have been included in the LTS kernels.

> > > After some testing I figured out that it takes several minutes for the
> > > device to be recognized. Having plugged in the device, a command like
> > > 
> > > $ cat /sys/devices/pci0000:00/0000:00:02.1/0000:04:00.0/ \
> > >   0000:05:0c.0/0000:17:00.0/usb5/5-4/manufacturer
> > > 
> > > blocks for several minutes, until, at some point, it correctly prints
> > > Creative Technology Ltd
> > 
> > It sounds like the device isn't behaving properly.  Or maybe the USB
> > cable, but I assume you checked that.
> > 
> > Have you tried plugging the device into a different computer?  And
> > have you tried plugging other devices into the same USB port?
> > 
> The device has a permanently attached cable that cannot be swapped,
> unfortunately.

In any case, it's very unlikely that the cable is at fault.

> This whole issue is extremely confusing to me as I cannot really figure
> out a pattern. Today I tried the following:
> - I plugged the device in on Linux: issue occurred
> - I plugged the device into a different port on the same machine on
>   Linux: issue occurred.
> - I plugged the device into an Android phone: played audio immediately
> - I plugged the device into a Laptop running Arch on 6.6.1: played audio
>   immediately (?!)

Is that the same kernel as on the first system?  (Just want to be
certain.)  If it is then the kernel probably isn't the cause.

Can you collect a usbmon trace on that machine?  And also, can you
post the output from "lsusb -v" for the Sound Blaster?

> - I booted the machine on Linux with the device already plugged in:
>   played audio immediately (?!)
> - I booted Windows and plugged in the device: played audio immediately
> - I plugged a keyboard and a mouse into the port: no issues

Yeah, it's really hard to tell what's happening.

> At this point I am more interested in figuring out what the heck is
> going on than actually getting this device to work.
> 
> Andreas Kempf

I've removed the first part of the usbmon trace.  It shows an ordinary
device detection and enumeration.

> ffff888106725d40 503577493 S Co:5:002:0 s 00 09 0001 0000 0000 0
> ffff888106725d40 503578614 C Co:5:002:0 0 0
> ffff888106725d40 503578910 S Ci:5:002:0 s 80 06 0309 0409 00ff 255 <
> ffff888106725d40 503581615 C Ci:5:002:0 0 34 = 22033100 35004300 31004500 35004500 33003100 36003500 42003900 42003300
> ffff888106725d40 503581622 S Co:5:002:0 s 21 0a 0000 0000 0000 0
> ffff888106725d40 503583615 C Co:5:002:0 0 0
> ffff888106725d40 503583619 S Ci:5:002:0 s 81 06 2200 0000 004f 79 <
> ffff888106725d40 503587625 C Ci:5:002:0 0 79 = 050c0901 a1011600 00260100 09e909ea 09e209cd 09b509b6 09b109b3 09b409cf
> ffff888106725d40 503587756 S Ii:5:002:6 -115:32 64 <
> ffff888106725c80 503644602 S Ci:5:002:0 s 80 06 0302 0409 00ff 255 <
> ffff888106725c80 503646631 C Ci:5:002:0 0 34 = 22035300 6f007500 6e006400 20004200 6c006100 73007400 65007200 20004700
> ffff888106725c80 503646635 S Ci:5:002:0 s 80 06 0301 0409 00ff 255 <
> ffff888106725c80 503649624 C Ci:5:002:0 0 50 = 32034300 72006500 61007400 69007600 65002000 54006500 63006800 6e006f00

That part is normal also.  It shows a Set-Configuration request, HID
Set-Idle and Get-Report-Descriptor requests, and a few Get-Descriptor
requests for some strings.

> ffff888106725140 503649650 S Co:5:002:0 s 21 01 0100 2203 0001 1 = 01

I don't recognize this request.  It's probably a USB audio thing.  Its
most notable aspect is that the device doesn't send a reply.  Maybe it
gets confused?

> ffff888101f31680 503651820 C Ii:5:001:1 0:2048 2 = 1000
> ffff888101f31680 503651824 S Ii:5:001:1 -115:2048 4 <
...

This next part is just a bunch of root-hub statuses, which I am leaving
out.  They don't make any progress because the system is waiting for
the device to respond to the earlier request.

> ffff888106725140 508701320 C Co:5:002:0 -2 0

After five seconds (the second column is a timestamp in microseconds)
with no response, the request times out and is aborted (the -2 status
code).

> ffff8881067255c0 508701366 S Co:5:002:0 s 01 0b 0000 0004 0000 0

This is a standard request telling the device to install alternate
setting 0 on interface 4 (probably one of the audio interfaces).
Again there's no reply.

> ffff888101f31680 508913548 C Ii:5:001:1 0:2048 2 = 1000
> ffff888101f31680 508913567 S Ii:5:001:1 -115:2048 4 <
...

> ffff8881067255c0 513820637 C Co:5:002:0 -2 0

And again the request times out after five seconds and is aborted.
There's no point going through the rest of the trace; it all looks
like this.

One gets the definite impression that the audio part of the device
simply isn't working.  But it can't be as straightforward as that,
because your tests show the device does work with other computers.

Alan Stern




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux