lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <YAqIJHzE3UG51G/U@audible.transient.net>
Date:   Fri, 22 Jan 2021 08:09:08 +0000
From:   Jamie Heilman <jamie@...ible.transient.net>
To:     tiwai@...e.com
Cc:     linux-kernel@...r.kernel.org
Subject: bisected regression in v5.11-rc1 snd-usb-audio

I've bisected a failure in support for the M2Tech USB HiFace Two
192kHz Digital Audio Interface device (read as: a reclocked USB
S/PDIF) to the following ...

commit 93db51d06b32227319dae2ac289029ccf1b33181
Author: Takashi Iwai <tiwai@...e.de>
Date:   Mon Nov 23 09:53:09 2020 +0100

    ALSA: usb-audio: Check valid altsetting at parsing rates for UAC2/3

This has always been a somewhat finicky device, but my life is a
silent void without it, as it is currently a vital part of getting
audio to my mixer (now, if I could get USB Audio on my Rane MP2015
actually working right I'd very happily take that approach instead[1],
but I digress).  It has been known to require replugging to initialize
properly at times, but until now, it's always worked fine eventually.

I've attached the dmesg from a working 5.10.9 kernel, the alsa-info
output, and the lsusb -vvv output for this device when it's
functioning.  (Note, that alsa-info claims jack isn't running...
that's not actually true though, maybe because I'm using jack 2's
jackdbus subsystem, but jack is infact running, though it's probably
not relevant to the issue at hand[2].) 

When I boot 93db51d06b32 or later I get lot of errors in the dmesg
like:

 usb 1-1.1.2: New USB device found, idVendor=249c, idProduct=930b, bcdDevice= 2.13
 usb 1-1.1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
 usb 1-1.1.2: Product: M2Tech USB Audio 2.0
 usb 1-1.1.2: Manufacturer: M2Tech 
 usb 1-1.1.2: SerialNumber: 0000
 usb 1-1.1.2: cannot get ctl value: req = 0x83, wValue = 0x201, wIndex = 0xa00, type = 4
 usb 1-1.1.2: 10:0: cannot get min/max values for control 2 (id 10)
 usb 1-1.1.2: cannot get ctl value: req = 0x83, wValue = 0x200, wIndex = 0xa00, type = 4
 usb 1-1.1.2: 10:0: cannot get min/max values for control 2 (id 10)
 usbcore: registered new interface driver snd-usb-audio
 usb 1-1.1-port2: disabled by hub (EMI?), re-enabling...
 usb 1-1.1.2: USB disconnect, device number 6
 usb 1-1.1.2: new full-speed USB device number 7 using ehci-pci
 usb 1-1.1.2: device descriptor read/64, error -32
 usb 1-1.1.2: device descriptor read/64, error -32
 usb 1-1.1.2: new full-speed USB device number 8 using ehci-pci
 usb 1-1.1.2: device descriptor read/64, error -32
 usb 1-1.1.2: device descriptor read/64, error -32
 usb 1-1.1-port2: attempt power cycle
 usb 1-1.1.2: new full-speed USB device number 9 using ehci-pci
 usb 1-1.1.2: device not accepting address 9, error -32
 usb 1-1.1.2: new full-speed USB device number 10 using ehci-pci
 usb 1-1.1.2: device not accepting address 10, error -32
 usb 1-1.1-port2: unable to enumerate USB device

and obviously the device doesn't work at all.  Sometimes there's more
"cannot get ctl value:" noise than other times, but the above is a
clean boot after being in a working state (it tends to require
replugging to get back to a being usable again after this, once I've
booted a working kernel, possibly becuase its hanging off a hub in my
monitor, not the most elegant of setups, I know---but none of this
changes even if I plug it directly into my workstation's USB ports, I
tried that).

I'm happy to try any patches, or provide more details, just ask.

-- 
Jamie Heilman                     http://audible.transient.net/~jamie/

[1] it's never been quite right, if you ever want to try to figure out
    why, I'd be happy to tackle that separately

[2] just in case, jack_control dp output:
--- get driver parameters (type:isset:default:value)
              device: ALSA device name (str:set:hw:0:hw:CARD=hiFace2,DEV=0)
             capture: Provide capture ports.  Optionally set device (str:notset:none:none)
            playback: Provide playback ports.  Optionally set device (str:set:none:hw:CARD=hiFace2,DEV=0)
                rate: Sample rate (uint:set:48000:96000)
              period: Frames per period (uint:notset:1024:1024)
            nperiods: Number of periods of playback latency (uint:set:2:3)
               hwmon: Hardware monitoring, if available (bool:notset:False:False)
             hwmeter: Hardware metering, if available (bool:notset:False:False)
              duplex: Provide both capture and playback ports (bool:notset:True:True)
            softmode: Soft-mode, no xrun handling (bool:notset:False:False)
             monitor: Provide monitor ports for the output (bool:notset:False:False)
              dither: Dithering mode (char:notset:n:n)
          inchannels: Number of capture channels (defaults to hardware max) (uint:notset:0:0)
         outchannels: Number of playback channels (defaults to hardware max) (uint:notset:0:0)
              shorts: Try 16-bit samples before 32-bit (bool:notset:False:False)
       input-latency: Extra input latency (frames) (uint:notset:0:0)
      output-latency: Extra output latency (frames) (uint:notset:0:0)
         midi-driver: ALSA MIDI driver (str:notset:none:none)


View attachment "v5.10.9-working-dmesg.txt" of type "text/plain" (54052 bytes)

View attachment "v5.10.9-working-alsa-info.txt" of type "text/plain" (35117 bytes)

View attachment "v5.10.9-working-lsusb-vvv.txt" of type "text/plain" (15666 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ