LinuxLists.cc - Logitech USB headset not working in 3.6-rc3

[permalink] [raw]

Subject: Re: Logitech USB headset not working in 3.6-rc3

On Fri, Aug 24, 2012 at 9:08 PM, Josh Boyer <[email protected]> wrote:
> Hi All,
>
> We've had a report[1] that the Logitech USB headset 0003:046D:0A0C isn't
> working with 3.6-rc3. It seems the last working kernel was based on
> commit 10c63c9, and it first stopped working with a kernel based on
> commit 23dcfa6. There are only a few ALSA commits between those
> revisions, so hopefully this is something that is fairly easy to
> identify. The only commit to USB audio in that set is:
>
> commit e9ba389c5ffc4dd29dfe17e00e48877302111135
> Author: Takashi Iwai <[email protected]>
> Date: Wed Aug 15 12:32:00 2012 +0200
>
> ALSA: usb-audio: Fix scheduling-while-atomic bug in PCM capture stream
>
>
> I've CC'd the reporter and attached the alsa-info is below.

Does it work again once you revert that commit?

Daniel

> [1] https://bugzilla.redhat.com/show_bug.cgi?id=851619
>
> upload=true&script=true&cardinfo=
> !!################################
> !!ALSA Information Script v 0.4.60
> !!################################
>
> !!Script ran on: Fri Aug 24 18:35:42 UTC 2012
>
>
> !!Linux Distribution
> !!------------------
>
> Fedora release 18 (Rawhide) Fedora release 18 (Rawhide) NAME=Fedora ID=fedora PRETTY_NAME="Fedora 18 (Rawhide)" CPE_NAME="cpe:/o:fedoraproject:fedora:18" Fedora release 18 (Rawhide) Fedora release 18 (Rawhide)
>
>
> !!DMI Information
> !!---------------
>
> Manufacturer: Dell Inc.
> Product Name: Precision WorkStation 690
> Product Version:
>
>
> !!Kernel Information
> !!------------------
>
> Kernel release: 3.6.0-0.rc3.git0.1.fc18.x86_64
> Operating System: GNU/Linux
> Architecture: x86_64
> Processor: x86_64
> SMP Enabled: Yes
>
>
> !!ALSA Version
> !!------------
>
> Driver version: 1.0.25
> Library version: 1.0.25
> Utilities version: 1.0.25
>
>
> !!Loaded ALSA modules
> !!-------------------
>
> snd_hda_intel
> snd_usb_audio
>
>
> !!Sound Servers on this system
> !!----------------------------
>
> Pulseaudio:
> Installed - Yes (/usr/bin/pulseaudio)
> Running - Yes
>
> aRts:
> Installed - Yes (/usr/bin/artsd)
> Running - No
>
> Jack:
> Installed - Yes (/usr/bin/jackd)
> Running - No
>
>
> !!Soundcards recognised by ALSA
> !!-----------------------------
>
> 0 [Intel ]: HDA-Intel - HDA Intel
> HDA Intel at 0xfcffc000 irq 66
> 1 [Headset ]: USB-Audio - Logitech USB Headset
> Logitech Logitech USB Headset at usb-0000:00:1d.7-6.4, full speed
>
>
> !!PCI Soundcards installed in the system
> !!--------------------------------------
>
> 00:1b.0 Audio device: Intel Corporation 631xESB/632xESB High Definition Audio Controller (rev 09)
>
>
> !!Advanced information - PCI Vendor/Device/Subsystem ID's
> !!--------------------------------------------------------
>
> 00:1b.0 0403: 8086:269a (rev 09)
> Subsystem: 1028:01c0
>
>
> !!Loaded sound module options
> !!--------------------------
>
> !!Module: snd_hda_intel
> align_buffer_size : -1
> bdl_pos_adj : 1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1
> beep_mode : N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N
> enable : Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y
> enable_msi : -1
> id : (null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null)
> index : -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1
> model : (null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null)
> patch : (null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null)
> position_fix : 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
> power_save : 0
> power_save_controller : Y
> probe_mask : -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1
> probe_only : 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
> single_cmd : N
> snoop : Y
>
> !!Module: snd_usb_audio
> async_unlink : Y
> device_setup : 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
> enable : Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y
> id : (null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null)
> ignore_ctl_error : N
> index : -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1
> nrpacks : 8
> pid : -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1
> vid : -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1
>
>
> !!HDA-Intel Codec information
> !!---------------------------
> --startcollapse--
>
> Codec: SigmaTel STAC9200
> Address: 0
> AFG Function Id: 0x1 (unsol 1)
> Vendor Id: 0x83847690
> Subsystem Id: 0x102801c0
> Revision Id: 0x102201
> No Modem Function Group found
> Default PCM:
> rates [0x7e0]: 44100 48000 88200 96000 176400 192000
> bits [0xe]: 16 20 24
> formats [0x1]: PCM
> Default Amp-In caps: N/A
> Default Amp-Out caps: ofs=0x1f, nsteps=0x1f, stepsize=0x05, mute=1
> GPIO: io=4, o=0, i=0, unsolicited=1, wake=1
> IO[0]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0
> IO[1]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0
> IO[2]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0
> IO[3]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0
> Node 0x02 [Audio Output] wcaps 0xd0401: Stereo
> Device: name="STAC92xx Analog", type="Audio", device=0
> Converter: stream=8, channel=0
> Power states:
> Power: setting=D0, actual=D0
> Delay: 13 samples
> Node 0x03 [Audio Input] wcaps 0x1d0541: Stereo
> Device: name="STAC92xx Analog", type="Audio", device=0
> Converter: stream=4, channel=0
> SDI-Select: 0
> Power states:
> Power: setting=D0, actual=D0
> Delay: 13 samples
> Connection: 1
> 0x0a
> Processing caps: benign=0, ncoeff=0
> Node 0x04 [Audio Input] wcaps 0x140311: Stereo Digital
> Converter: stream=0, channel=0
> SDI-Select: 0
> Digital:
> Digital category: 0x0
> PCM:
> rates [0x160]: 44100 48000 96000
> bits [0xe]: 16 20 24
> formats [0x5]: PCM AC3
> Delay: 4 samples
> Connection: 1
> 0x08
> Node 0x05 [Audio Output] wcaps 0x40211: Stereo Digital
> Converter: stream=0, channel=0
> Digital:
> Digital category: 0x0
> PCM:
> rates [0x1e0]: 44100 48000 88200 96000
> bits [0xe]: 16 20 24
> formats [0x5]: PCM AC3
> Delay: 4 samples
> Node 0x06 [Vendor Defined Widget] wcaps 0xf30201: Stereo Digital
> Delay: 3 samples
> Node 0x07 [Audio Selector] wcaps 0x300901: Stereo R/L
> Connection: 3
> 0x02* 0x08 0x0a
> Node 0x08 [Pin Complex] wcaps 0x430681: Stereo Digital
> Pincap 0x00010024: IN EAPD Detect
> EAPD 0x0:
> Pin Default 0x400001f0: [N/A] Line Out at Ext N/A
> Conn = Unknown, Color = Unknown
> DefAssociation = 0xf, Sequence = 0x0
> Misc = NO_PRESENCE
> Pin-ctls: 0x00:
> Unsolicited: tag=00, enabled=0
> Power states:
> Power: setting=D0, actual=D0
> Delay: 3 samples
> Node 0x09 [Pin Complex] wcaps 0x400301: Stereo Digital
> Pincap 0x00000010: OUT
> Pin Default 0x400001f1: [N/A] Line Out at Ext N/A
> Conn = Unknown, Color = Unknown
> DefAssociation = 0xf, Sequence = 0x1
> Misc = NO_PRESENCE
> Pin-ctls: 0x00:
> Connection: 2
> 0x05* 0x0a
> Node 0x0a [Audio Selector] wcaps 0x30090d: Stereo Amp-Out R/L
> Control: name="Capture Volume", index=0, device=0
> ControlAmp: chs=3, dir=Out, idx=0, ofs=0
> Control: name="Capture Switch", index=0, device=0
> ControlAmp: chs=3, dir=Out, idx=0, ofs=0
> Amp-Out caps: ofs=0x00, nsteps=0x0f, stepsize=0x05, mute=1
> Amp-Out vals: [0x07 0x07]
> Connection: 1
> 0x0c
> Node 0x0b [Audio Selector] wcaps 0x300105: Stereo Amp-Out
> Control: name="PCM Playback Volume", index=0, device=0
> ControlAmp: chs=3, dir=Out, idx=0, ofs=0
> Control: name="PCM Playback Switch", index=0, device=0
> ControlAmp: chs=3, dir=Out, idx=0, ofs=0
> Amp-Out caps: N/A
> Amp-Out vals: [0x9f 0x9f]
> Connection: 1
> 0x07
> Node 0x0c [Audio Selector] wcaps 0x30010d: Stereo Amp-Out
> Control: name="Mux Capture Volume", index=0, device=0
> ControlAmp: chs=3, dir=Out, idx=0, ofs=0
> Amp-Out caps: ofs=0x00, nsteps=0x04, stepsize=0x27, mute=0
> Amp-Out vals: [0x00 0x00]
> Connection: 5
> 0x10* 0x0f 0x0e 0x0d 0x12
> Node 0x0d [Pin Complex] wcaps 0x400181: Stereo
> Control: name="Front Headphone Jack", index=0, device=0
> Pincap 0x0000003f: IN OUT HP Detect Trigger ImpSense
> Pin Default 0x0221401f: [Jack] HP Out at Ext Front
> Conn = 1/8, Color = Green
> DefAssociation = 0x1, Sequence = 0xf
> Pin-ctls: 0xc0: OUT HP
> Unsolicited: tag=01, enabled=1
> Connection: 1
> 0x0b
> Node 0x0e [Pin Complex] wcaps 0x400181: Stereo
> Control: name="Line Out Jack", index=0, device=0
> Pincap 0x0000003f: IN OUT HP Detect Trigger ImpSense
> Pin Default 0x01014010: [Jack] Line Out at Ext Rear
> Conn = 1/8, Color = Green
> DefAssociation = 0x1, Sequence = 0x0
> Pin-ctls: 0x40: OUT
> Unsolicited: tag=02, enabled=1
> Connection: 1
> 0x0b
> Node 0x0f [Pin Complex] wcaps 0x400181: Stereo
> Control: name="Line Jack", index=0, device=0
> Pincap 0x00000037: IN OUT Detect Trigger ImpSense
> Pin Default 0x01813020: [Jack] Line In at Ext Rear
> Conn = 1/8, Color = Blue
> DefAssociation = 0x2, Sequence = 0x0
> Pin-ctls: 0x20: IN
> Unsolicited: tag=04, enabled=1
> Connection: 1
> 0x0b
> Node 0x10 [Pin Complex] wcaps 0x400181: Stereo
> Control: name="Mic Jack", index=0, device=0
> Pincap 0x00001737: IN OUT Detect Trigger ImpSense
> Vref caps: HIZ 50 GRD 80
> Pin Default 0x02a19021: [Jack] Mic at Ext Front
> Conn = 1/8, Color = Pink
> DefAssociation = 0x2, Sequence = 0x1
> Pin-ctls: 0x24: IN VREF_80
> Unsolicited: tag=03, enabled=1
> Connection: 1
> 0x0b
> Node 0x11 [Pin Complex] wcaps 0x400104: Mono Amp-Out
> Control: name="LFE Playback Volume", index=0, device=0
> ControlAmp: chs=1, dir=Out, idx=0, ofs=0
> Control: name="LFE Playback Switch", index=0, device=0
> ControlAmp: chs=1, dir=Out, idx=0, ofs=0
> Control: name="Speaker Phantom Jack", index=0, device=0
> Amp-Out caps: N/A
> Amp-Out vals: [0x00]
> Pincap 0x00000010: OUT
> Pin Default 0x90100140: [Fixed] Speaker at Int N/A
> Conn = Unknown, Color = Unknown
> DefAssociation = 0x4, Sequence = 0x0
> Misc = NO_PRESENCE
> Pin-ctls: 0x00:
> Connection: 1
> 0x13
> Node 0x12 [Pin Complex] wcaps 0x400001: Stereo
> Pincap 0x00000020: IN
> Pin Default 0x400001f2: [N/A] Line Out at Ext N/A
> Conn = Unknown, Color = Unknown
> DefAssociation = 0xf, Sequence = 0x2
> Misc = NO_PRESENCE
> Pin-ctls: 0x20: IN
> Node 0x13 [Audio Mixer] wcaps 0x200100: Mono
> Connection: 1
> 0x07
> Node 0x14 [Beep Generator Widget] wcaps 0x70000c: Mono Amp-Out
> Amp-Out caps: ofs=0x03, nsteps=0x03, stepsize=0x17, mute=1
> Amp-Out vals: [0x00]
> --endcollapse--
>
>
> !!USB Mixer information
> !!---------------------------
> --startcollapse--
>
> USB Mixer: usb_id=0x046d0a0c, ctrlif=0, ctlerr=0
> Card: Logitech Logitech USB Headset at usb-0000:00:1d.7-6.4, full speed
> Unit: 1
> Control: name="Speaker Playback Volume", index=0
> Info: id=1, control=2, cmask=0x3, channels=2, type="S16"
> Volume: min=-10496, max=768, dBmin=-4100, dBmax=300
> Unit: 1
> Control: name="Speaker Playback Switch", index=0
> Info: id=1, control=1, cmask=0x0, channels=1, type="INV_BOOLEAN"
> Volume: min=0, max=1, dBmin=0, dBmax=0
> Unit: 2
> Control: name="Mic Capture Volume", index=0
> Info: id=2, control=2, cmask=0x0, channels=1, type="S16"
> Volume: min=4096, max=7424, dBmin=1600, dBmax=2900
> Unit: 2
> Control: name="Mic Capture Switch", index=0
> Info: id=2, control=1, cmask=0x0, channels=1, type="INV_BOOLEAN"
> Volume: min=0, max=1, dBmin=0, dBmax=0
> Unit: 6
> Control: name="Mic Playback Volume", index=0
> Info: id=6, control=2, cmask=0x0, channels=1, type="S16"
> Volume: min=-10496, max=-3072, dBmin=-4100, dBmax=-1200
> Unit: 6
> Control: name="Mic Playback Switch", index=0
> Info: id=6, control=1, cmask=0x0, channels=1, type="INV_BOOLEAN"
> Volume: min=0, max=1, dBmin=0, dBmax=0
> --endcollapse--
>
>
> !!ALSA Device nodes
> !!-----------------
>
> crw-rw----+ 1 root audio 116, 8 Aug 24 12:18 /dev/snd/controlC0
> crw-rw----+ 1 root audio 116, 4 Aug 24 12:18 /dev/snd/controlC1
> crw-rw----+ 1 root audio 116, 7 Aug 24 12:18 /dev/snd/hwC0D0
> crw-rw----+ 1 root audio 116, 6 Aug 24 12:19 /dev/snd/pcmC0D0c
> crw-rw----+ 1 root audio 116, 5 Aug 24 12:19 /dev/snd/pcmC0D0p
> crw-rw----+ 1 root audio 116, 3 Aug 24 12:19 /dev/snd/pcmC1D0c
> crw-rw----+ 1 root audio 116, 2 Aug 24 12:30 /dev/snd/pcmC1D0p
> crw-rw----+ 1 root audio 116, 1 Aug 24 12:18 /dev/snd/seq
> crw-rw----+ 1 root audio 116, 33 Aug 24 12:18 /dev/snd/timer
>
> /dev/snd/by-id:
> total 0
> drwxr-xr-x. 2 root root 60 Aug 24 12:18 .
> drwxr-xr-x. 4 root root 260 Aug 24 12:18 ..
> lrwxrwxrwx. 1 root root 12 Aug 24 12:18 usb-Logitech_Logitech_USB_Headset-00 -> ../controlC1
>
> /dev/snd/by-path:
> total 0
> drwxr-xr-x. 2 root root 80 Aug 24 12:18 .
> drwxr-xr-x. 4 root root 260 Aug 24 12:18 ..
> lrwxrwxrwx. 1 root root 12 Aug 24 12:18 pci-0000:00:1b.0 -> ../controlC0
> lrwxrwxrwx. 1 root root 12 Aug 24 12:18 pci-0000:00:1d.7-usb-0:6.4:1.0 -> ../controlC1
>
>
> !!ALSA configuration files
> !!------------------------
>
> !!System wide config file (/etc/asound.conf)
>
> #
> # Place your global alsa-lib configuration here...
> #
>
>
> !!Aplay/Arecord output
> !!------------
>
> APLAY
>
> **** List of PLAYBACK Hardware Devices ****
> card 0: Intel [HDA Intel], device 0: STAC92xx Analog [STAC92xx Analog]
> Subdevices: 1/1
> Subdevice #0: subdevice #0
> card 1: Headset [Logitech USB Headset], device 0: USB Audio [USB Audio]
> Subdevices: 0/1
> Subdevice #0: subdevice #0
>
> ARECORD
>
> **** List of CAPTURE Hardware Devices ****
> card 0: Intel [HDA Intel], device 0: STAC92xx Analog [STAC92xx Analog]
> Subdevices: 1/1
> Subdevice #0: subdevice #0
> card 1: Headset [Logitech USB Headset], device 0: USB Audio [USB Audio]
> Subdevices: 1/1
> Subdevice #0: subdevice #0
>
> !!Amixer output
> !!-------------
>
> !!-------Mixer controls for card 0 [Intel]
>
> Card hw:0 'Intel'/'HDA Intel at 0xfcffc000 irq 66'
> Mixer name : 'SigmaTel STAC9200'
> Components : 'HDA:83847690,102801c0,00102201'
> Controls : 15
> Simple ctrls : 6
> Simple mixer control 'Master',0
> Capabilities: pvolume pvolume-joined pswitch pswitch-joined penum
> Playback channels: Mono
> Limits: Playback 0 - 31
> Mono: Playback 31 [100%] [0.00dB] [off]
> Simple mixer control 'PCM',0
> Capabilities: pvolume pswitch penum
> Playback channels: Front Left - Front Right
> Limits: Playback 0 - 31
> Mono:
> Front Left: Playback 31 [100%] [0.00dB] [off]
> Front Right: Playback 31 [100%] [0.00dB] [off]
> Simple mixer control 'LFE',0
> Capabilities: pvolume pvolume-joined pswitch pswitch-joined penum
> Playback channels: Mono
> Limits: Playback 0 - 31
> Mono: Playback 31 [100%] [0.00dB] [off]
> Simple mixer control 'Capture',0
> Capabilities: cvolume cswitch penum
> Capture channels: Front Left - Front Right
> Limits: Capture 0 - 15
> Front Left: Capture 7 [47%] [10.50dB] [on]
> Front Right: Capture 7 [47%] [10.50dB] [on]
> Simple mixer control 'Input Source',0
> Capabilities: cenum
> Items: 'Mic' 'Line'
> Item0: 'Mic'
> Simple mixer control 'Mux',0
> Capabilities: cvolume penum
> Capture channels: Front Left - Front Right
> Limits: Capture 0 - 4
> Front Left: Capture 0 [0%] [0.00dB]
> Front Right: Capture 0 [0%] [0.00dB]
>
> !!-------Mixer controls for card 1 [Headset]
>
> Card hw:1 'Headset'/'Logitech Logitech USB Headset at usb-0000:00:1d.7-6.4, full speed'
> Mixer name : 'USB Mixer'
> Components : 'USB046d:0a0c'
> Controls : 6
> Simple ctrls : 2
> Simple mixer control 'Speaker',0
> Capabilities: pvolume pswitch pswitch-joined penum
> Playback channels: Front Left - Front Right
> Limits: Playback 0 - 44
> Mono:
> Front Left: Playback 35 [80%] [-6.00dB] [on]
> Front Right: Playback 35 [80%] [-6.00dB] [on]
> Simple mixer control 'Mic',0
> Capabilities: pvolume pvolume-joined cvolume cvolume-joined pswitch pswitch-joined cswitch cswitch-joined penum
> Playback channels: Mono
> Capture channels: Mono
> Limits: Playback 0 - 29 Capture 0 - 13
> Mono: Playback 0 [0%] [-41.00dB] [off] Capture 13 [100%] [29.00dB] [on]
>
>
> !!Alsactl output
> !!-------------
>
> --startcollapse--
> state.Intel {
> control.1 {
> iface MIXER
> name 'PCM Playback Volume'
> value.0 31
> value.1 31
> comment {
> access 'read write'
> type INTEGER
> count 2
> range '0 - 31'
> dbmin -9999999
> dbmax 0
> dbvalue.0 0
> dbvalue.1 0
> }
> }
> control.2 {
> iface MIXER
> name 'PCM Playback Switch'
> value.0 false
> value.1 false
> comment {
> access 'read write'
> type BOOLEAN
> count 2
> }
> }
> control.3 {
> iface MIXER
> name 'Capture Volume'
> value.0 7
> value.1 7
> comment {
> access 'read write'
> type INTEGER
> count 2
> range '0 - 15'
> dbmin 0
> dbmax 2250
> dbvalue.0 1050
> dbvalue.1 1050
> }
> }
> control.4 {
> iface MIXER
> name 'Capture Switch'
> value.0 true
> value.1 true
> comment {
> access 'read write'
> type BOOLEAN
> count 2
> }
> }
> control.5 {
> iface MIXER
> name 'LFE Playback Volume'
> value 31
> comment {
> access 'read write'
> type INTEGER
> count 1
> range '0 - 31'
> dbmin -4650
> dbmax 0
> dbvalue.0 0
> }
> }
> control.6 {
> iface MIXER
> name 'LFE Playback Switch'
> value false
> comment {
> access 'read write'
> type BOOLEAN
> count 1
> }
> }
> control.7 {
> iface MIXER
> name 'Mux Capture Volume'
> value.0 0
> value.1 0
> comment {
> access 'read write'
> type INTEGER
> count 2
> range '0 - 4'
> dbmin 0
> dbmax 4000
> dbvalue.0 0
> dbvalue.1 0
> }
> }
> control.8 {
> iface MIXER
> name 'Input Source'
> value Mic
> comment {
> access 'read write'
> type ENUMERATED
> count 1
> item.0 Mic
> item.1 Line
> }
> }
> control.9 {
> iface MIXER
> name 'Master Playback Volume'
> value 31
> comment {
> access 'read write'
> type INTEGER
> count 1
> range '0 - 31'
> dbmin -9999999
> dbmax 0
> dbvalue.0 0
> }
> }
> control.10 {
> iface MIXER
> name 'Master Playback Switch'
> value false
> comment {
> access 'read write'
> type BOOLEAN
> count 1
> }
> }
> control.11 {
> iface CARD
> name 'Line Out Jack'
> value true
> comment {
> access read
> type BOOLEAN
> count 1
> }
> }
> control.12 {
> iface CARD
> name 'Front Headphone Jack'
> value false
> comment {
> access read
> type BOOLEAN
> count 1
> }
> }
> control.13 {
> iface CARD
> name 'Speaker Phantom Jack'
> value true
> comment {
> access read
> type BOOLEAN
> count 1
> }
> }
> control.14 {
> iface CARD
> name 'Mic Jack'
> value false
> comment {
> access read
> type BOOLEAN
> count 1
> }
> }
> control.15 {
> iface CARD
> name 'Line Jack'
> value false
> comment {
> access read
> type BOOLEAN
> count 1
> }
> }
> }
> state.Headset {
> control.1 {
> iface MIXER
> name 'Mic Playback Switch'
> value false
> comment {
> access 'read write'
> type BOOLEAN
> count 1
> }
> }
> control.2 {
> iface MIXER
> name 'Mic Playback Volume'
> value 0
> comment {
> access 'read write'
> type INTEGER
> count 1
> range '0 - 29'
> dbmin -4100
> dbmax -1200
> dbvalue.0 -4100
> }
> }
> control.3 {
> iface MIXER
> name 'Speaker Playback Switch'
> value true
> comment {
> access 'read write'
> type BOOLEAN
> count 1
> }
> }
> control.4 {
> iface MIXER
> name 'Speaker Playback Volume'
> value.0 35
> value.1 35
> comment {
> access 'read write'
> type INTEGER
> count 2
> range '0 - 44'
> dbmin -4100
> dbmax 300
> dbvalue.0 -600
> dbvalue.1 -600
> }
> }
> control.5 {
> iface MIXER
> name 'Mic Capture Switch'
> value true
> comment {
> access 'read write'
> type BOOLEAN
> count 1
> }
> }
> control.6 {
> iface MIXER
> name 'Mic Capture Volume'
> value 13
> comment {
> access 'read write'
> type INTEGER
> count 1
> range '0 - 13'
> dbmin 1600
> dbmax 2900
> dbvalue.0 2900
> }
> }
> }
> --endcollapse--
>
>
> !!All Loaded Modules
> !!------------------
>
> Module
> fuse
> nf_conntrack_ipv4
> nf_defrag_ipv4
> xt_state
> nf_conntrack
> snd_hda_codec_idt
> snd_usb_audio
> snd_hda_intel
> snd_usbmidi_lib
> snd_hda_codec
> snd_rawmidi
> snd_hwdep
> iTCO_wdt
> iTCO_vendor_support
> lpc_ich
> i5000_edac
> snd_seq
> snd_seq_device
> edac_core
> snd_pcm
> mfd_core
> serio_raw
> ppdev
> snd_page_alloc
> snd_timer
> coretemp
> snd
> i5k_amb
> soundcore
> parport_pc
> dcdbas
> microcode
> shpchp
> parport
> i2c_i801
> vhost_net
> tun
> macvtap
> macvlan
> kvm_intel
> kvm
> uinput
> binfmt_misc
> xts
> gf128mul
> dm_crypt
> raid1
> radeon
> i2c_algo_bit
> drm_kms_helper
> ttm
> drm
> tg3
> mptsas
> mptscsih
> mptbase
> i2c_core
> scsi_transport_sas
> sunrpc
> be2iscsi
> bnx2i
> cnic
> uio
> cxgb4i
> cxgb4
> cxgb3
> mdio
> libcxgbi
> libiscsi_tcp
> qla4xxx
> iscsi_boot_sysfs
> libiscsi
> scsi_transport_iscsi
>
>
> !!Sysfs Files
> !!-----------
>
> /sys/class/sound/hwC0D0/init_pin_configs:
> 0x08 0x40f000f0
> 0x09 0x40f000f1
> 0x0d 0x0221101f
> 0x0e 0x01014010
> 0x0f 0x0181302e
> 0x10 0x02a11020
> 0x11 0x40f000f2
> 0x12 0x40f000f3
>
> /sys/class/sound/hwC0D0/driver_pin_configs:
> 0x08 0x400001f0
> 0x09 0x400001f1
> 0x0d 0x0221401f
> 0x0e 0x01014010
> 0x0f 0x01813020
> 0x10 0x02a19021
> 0x11 0x90100140
> 0x12 0x400001f2
>
> /sys/class/sound/hwC0D0/user_pin_configs:
>
> /sys/class/sound/hwC0D0/init_verbs:
>
>
> !!ALSA/HDA dmesg
> !!------------------
>
> [ 38.190306] SELinux: initialized (dev configfs, type configfs), uses genfs_contexts
> [ 38.229616] snd_hda_intel 0000:00:1b.0: irq 66 for MSI/MSI-X
> [ 38.270699] ALSA sound/usb/mixer.c:866 6:0: cannot get min/max values for control 2 (id 6)
> [ 38.274097] ALSA sound/usb/mixer.c:866 1:0: cannot get min/max values for control 2 (id 1)
> [ 38.276753] ALSA sound/usb/mixer.c:866 2:0: cannot get min/max values for control 2 (id 2)
> [ 38.279322] ALSA sound/pci/hda/hda_auto_parser.c:322 autoconfig: line_outs=1 (0xe/0x0/0x0/0x0/0x0) type:line
> [ 38.279326] ALSA sound/pci/hda/hda_auto_parser.c:326 speaker_outs=1 (0x11/0x0/0x0/0x0/0x0)
> [ 38.279329] ALSA sound/pci/hda/hda_auto_parser.c:330 hp_outs=1 (0xd/0x0/0x0/0x0/0x0)
> [ 38.279331] ALSA sound/pci/hda/hda_auto_parser.c:331 mono: mono_out=0x0
> [ 38.279333] ALSA sound/pci/hda/hda_auto_parser.c:335 inputs:
> [ 38.279336] ALSA sound/pci/hda/hda_auto_parser.c:339 Mic=0x10
> [ 38.279342] ALSA sound/pci/hda/hda_auto_parser.c:339 Line=0xf
> [ 38.285983] usbcore: registered new interface driver snd-usb-audio
> [ 38.290348] input: HDA Intel Line as /devices/pci0000:00/0000:00:1b.0/sound/card0/input8
> [ 38.294975] input: HDA Intel Mic as /devices/pci0000:00/0000:00:1b.0/sound/card0/input9
> [ 38.297406] input: HDA Intel Front Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card0/input10
> [ 38.301369] input: HDA Intel Line Out as /devices/pci0000:00/0000:00:1b.0/sound/card0/input11
> [ 39.377352] EXT4-fs: Warning: mounting with data=journal disables delayed allocation and O_DIRECT support!
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/

2012-08-24 22:30:46

[permalink] [raw]

Subject: Re: Logitech USB headset not working in 3.6-rc3

Hi,

On 24.08.2012 21:08, Josh Boyer wrote:
> We've had a report[1] that the Logitech USB headset 0003:046D:0A0C isn't
> working with 3.6-rc3. It seems the last working kernel was based on
> commit 10c63c9, and it first stopped working with a kernel based on
> commit 23dcfa6. There are only a few ALSA commits between those
> revisions, so hopefully this is something that is fairly easy to
> identify. The only commit to USB audio in that set is:

[...]

> !!ALSA/HDA dmesg
> !!------------------
>
> [ 38.190306] SELinux: initialized (dev configfs, type configfs), uses genfs_contexts
> [ 38.229616] snd_hda_intel 0000:00:1b.0: irq 66 for MSI/MSI-X
> [ 38.270699] ALSA sound/usb/mixer.c:866 6:0: cannot get min/max values for control 2 (id 6)
> [ 38.274097] ALSA sound/usb/mixer.c:866 1:0: cannot get min/max values for control 2 (id 1)
> [ 38.276753] ALSA sound/usb/mixer.c:866 2:0: cannot get min/max values for control 2 (id 2)
> [ 38.279322] ALSA sound/pci/hda/hda_auto_parser.c:322 autoconfig: line_outs=1 (0xe/0x0/0x0/0x0/0x0) type:line
> [ 38.279326] ALSA sound/pci/hda/hda_auto_parser.c:326 speaker_outs=1 (0x11/0x0/0x0/0x0/0x0)
> [ 38.279329] ALSA sound/pci/hda/hda_auto_parser.c:330 hp_outs=1 (0xd/0x0/0x0/0x0/0x0)
> [ 38.279331] ALSA sound/pci/hda/hda_auto_parser.c:331 mono: mono_out=0x0
> [ 38.279333] ALSA sound/pci/hda/hda_auto_parser.c:335 inputs:
> [ 38.279336] ALSA sound/pci/hda/hda_auto_parser.c:339 Mic=0x10
> [ 38.279342] ALSA sound/pci/hda/hda_auto_parser.c:339 Line=0xf
> [ 38.285983] usbcore: registered new interface driver snd-usb-audio

Also, according to this dmesg, the device is probed just fine (which the
commit you mentioned wouldn't change anything about though).

So what does "isn't working anymore" refer to precisely? Are there any
more dmesg entries generated once the stream is started?

Daniel

2012-08-24 22:31:41

[permalink] [raw]

Subject: Re: Logitech USB headset not working in 3.6-rc3

On Fri, Aug 24, 2012 at 11:30:12PM +0200, Daniel Mack wrote:
> On Fri, Aug 24, 2012 at 9:08 PM, Josh Boyer <[email protected]> wrote:
> > Hi All,
> >
> > We've had a report[1] that the Logitech USB headset 0003:046D:0A0C isn't
> > working with 3.6-rc3. It seems the last working kernel was based on
> > commit 10c63c9, and it first stopped working with a kernel based on
> > commit 23dcfa6. There are only a few ALSA commits between those
> > revisions, so hopefully this is something that is fairly easy to
> > identify. The only commit to USB audio in that set is:
> >
> > commit e9ba389c5ffc4dd29dfe17e00e48877302111135
> > Author: Takashi Iwai <[email protected]>
> > Date: Wed Aug 15 12:32:00 2012 +0200
> >
> > ALSA: usb-audio: Fix scheduling-while-atomic bug in PCM capture stream
> >
> >
> > I've CC'd the reporter and attached the alsa-info is below.
>
> Does it work again once you revert that commit?

Haven't built a kernel with that done yet. Had a few other things pop
up this afternoon. If Bruno doesn't build one himself, I'll try to get
one built later this evening for testing.

josh

2012-08-25 11:26:17

[permalink] [raw]

Subject: Re: Logitech USB headset not working in 3.6-rc3

On Sat, Aug 25, 2012 at 00:30:22 +0200,
Daniel Mack <[email protected]> wrote:
>
>So what does "isn't working anymore" refer to precisely? Are there any
>more dmesg entries generated once the stream is started?

When I try to play music, the progress bar for the song doesn't advance and
there is no audbile sound. I am able to use sound preferences to change
the configuration for the device. (The headset has a few different output
modes and the like.)

I saved dmesg output in a file, tried to start a song, saved dmesg output
to another file. diff reported the two files as identical. So trying to
play music doesn't seem to trigger dmesg output.

I see this behavior on three different computers. Rebooting into an old
enough kernel gets things working again. The older kernels also have
older initramfs images. I could rebuild those to see if there is some
issue there instead of the kernels themselves?

2012-08-25 11:56:19

[permalink] [raw]

Subject: Re: Logitech USB headset not working in 3.6-rc3

On Sat, Aug 25, 2012 at 06:17:49 -0500,
Bruno Wolff III <[email protected]> wrote:
>
>I see this behavior on three different computers. Rebooting into an old
>enough kernel gets things working again. The older kernels also have
>older initramfs images. I could rebuild those to see if there is some
>issue there instead of the kernels themselves?

I tested one of the older kernels (where the headset still worked) with a
rebuilt initramfs and the headset still worked. So it likely isn't an issue
with something in the initramfs images.

2012-08-25 12:03:07

[permalink] [raw]

Subject: Re: Logitech USB headset not working in 3.6-rc3

On 25.08.2012 13:54, Bruno Wolff III wrote:
> On Sat, Aug 25, 2012 at 06:17:49 -0500,
> Bruno Wolff III <[email protected]> wrote:
>>
>> I see this behavior on three different computers. Rebooting into an old
>> enough kernel gets things working again. The older kernels also have
>> older initramfs images. I could rebuild those to see if there is some
>> issue there instead of the kernels themselves?
>
> I tested one of the older kernels (where the headset still worked) with a
> rebuilt initramfs and the headset still worked. So it likely isn't an issue
> with something in the initramfs images.
>

Can you revert commit e9ba389c5 ("ALSA: usb-audio: Fix
scheduling-while-atomic bug in PCM capture stream") and see if that
helps? If not, can you summarize again which kernels still work for you
and which don't?

Daniel

2012-08-25 12:09:38

[permalink] [raw]

Subject: Re: Logitech USB headset not working in 3.6-rc3

On Sat, Aug 25, 2012 at 14:02:51 +0200,
Daniel Mack <[email protected]> wrote:
>
>Can you revert commit e9ba389c5 ("ALSA: usb-audio: Fix
>scheduling-while-atomic bug in PCM capture stream") and see if that

I can try that, but it takes a long time to build a new kernel on my
old hardware.

>helps? If not, can you summarize again which kernels still work for you
>and which don't?

The latest kernel that works is 3.6.0-0.rc2.git1.2.fc18. The earliest that
doesn't work is 3.6.0-0.rc2.git2.1.fc18.

2012-08-25 12:13:52

[permalink] [raw]

Subject: Re: Logitech USB headset not working in 3.6-rc3

On Sat, Aug 25, 2012 at 07:07:40AM -0500, Bruno Wolff III wrote:
> On Sat, Aug 25, 2012 at 14:02:51 +0200,
> Daniel Mack <[email protected]> wrote:
> >
> >Can you revert commit e9ba389c5 ("ALSA: usb-audio: Fix
> >scheduling-while-atomic bug in PCM capture stream") and see if that
>
> I can try that, but it takes a long time to build a new kernel on my
> old hardware.

I started a scratch build of a kernel with that patch reverted (via
patch -R). You'll find it here when it finishes:

http://koji.fedoraproject.org/koji/taskinfo?taskID=4421817

josh

2012-08-25 12:14:20

[permalink] [raw]

Subject: Re: Logitech USB headset not working in 3.6-rc3

On 25.08.2012 14:07, Bruno Wolff III wrote:
> On Sat, Aug 25, 2012 at 14:02:51 +0200,
> Daniel Mack <[email protected]> wrote:
>>
>> Can you revert commit e9ba389c5 ("ALSA: usb-audio: Fix
>> scheduling-while-atomic bug in PCM capture stream") and see if that
>
> I can try that, but it takes a long time to build a new kernel on my
> old hardware.
>
>> helps? If not, can you summarize again which kernels still work for you
>> and which don't?
>
> The latest kernel that works is 3.6.0-0.rc2.git1.2.fc18. The earliest that
> doesn't work is 3.6.0-0.rc2.git2.1.fc18.
>

The report you sent doesn't look like it could be caused by e9ba389c5.
It fixes a kernel Ooops. But as it is the only relevant patch in that
area, it would be interesting if reverting it fixes anything.

Btw - thanks a lot for testing -rc kernels, much appreciated!

Daniel

2012-08-25 12:18:12

[permalink] [raw]

Subject: Re: Logitech USB headset not working in 3.6-rc3

On Sat, Aug 25, 2012 at 02:13:58PM +0200, Daniel Mack wrote:
> On 25.08.2012 14:07, Bruno Wolff III wrote:
> > On Sat, Aug 25, 2012 at 14:02:51 +0200,
> > Daniel Mack <[email protected]> wrote:
> >>
> >> Can you revert commit e9ba389c5 ("ALSA: usb-audio: Fix
> >> scheduling-while-atomic bug in PCM capture stream") and see if that
> >
> > I can try that, but it takes a long time to build a new kernel on my
> > old hardware.
> >
> >> helps? If not, can you summarize again which kernels still work for you
> >> and which don't?
> >
> > The latest kernel that works is 3.6.0-0.rc2.git1.2.fc18. The earliest that
> > doesn't work is 3.6.0-0.rc2.git2.1.fc18.
> >
>
> The report you sent doesn't look like it could be caused by e9ba389c5.
> It fixes a kernel Ooops. But as it is the only relevant patch in that
> area, it would be interesting if reverting it fixes anything.

Yep, agreed. If this revert kernel doesn't work, we're likely down to a
git bisect, Bruno.

> Btw - thanks a lot for testing -rc kernels, much appreciated!

Indeed!

josh

2012-08-25 12:18:20

[permalink] [raw]

Subject: Re: Logitech USB headset not working in 3.6-rc3

On Sat, Aug 25, 2012 at 08:13:27 -0400,
Josh Boyer <[email protected]> wrote:
>On Sat, Aug 25, 2012 at 07:07:40AM -0500, Bruno Wolff III wrote:
>> On Sat, Aug 25, 2012 at 14:02:51 +0200,
>> Daniel Mack <[email protected]> wrote:
>> >
>> >Can you revert commit e9ba389c5 ("ALSA: usb-audio: Fix
>> >scheduling-while-atomic bug in PCM capture stream") and see if that
>>
>> I can try that, but it takes a long time to build a new kernel on my
>> old hardware.
>
>I started a scratch build of a kernel with that patch reverted (via
>patch -R). You'll find it here when it finishes:
>
>http://koji.fedoraproject.org/koji/taskinfo?taskID=4421817
>
>josh

I'll test it when it finishes. Thanks. It takes me a long time to build
kernels locally, and I wasn't sure how to do a scratch build on koji without
committing stuff remotely.

2012-08-25 13:45:11

[permalink] [raw]

Subject: Re: Logitech USB headset not working in 3.6-rc3

At Sat, 25 Aug 2012 08:17:58 -0400,
Josh Boyer wrote:
>
> On Sat, Aug 25, 2012 at 02:13:58PM +0200, Daniel Mack wrote:
> > On 25.08.2012 14:07, Bruno Wolff III wrote:
> > > On Sat, Aug 25, 2012 at 14:02:51 +0200,
> > > Daniel Mack <[email protected]> wrote:
> > >>
> > >> Can you revert commit e9ba389c5 ("ALSA: usb-audio: Fix
> > >> scheduling-while-atomic bug in PCM capture stream") and see if that
> > >
> > > I can try that, but it takes a long time to build a new kernel on my
> > > old hardware.
> > >
> > >> helps? If not, can you summarize again which kernels still work for you
> > >> and which don't?
> > >
> > > The latest kernel that works is 3.6.0-0.rc2.git1.2.fc18. The earliest that
> > > doesn't work is 3.6.0-0.rc2.git2.1.fc18.
> > >
> >
> > The report you sent doesn't look like it could be caused by e9ba389c5.
> > It fixes a kernel Ooops. But as it is the only relevant patch in that
> > area, it would be interesting if reverting it fixes anything.
>
> Yep, agreed. If this revert kernel doesn't work, we're likely down to a
> git bisect, Bruno.

Yes, please. I'm currently traveling for KS and Plumbers, so I cannot
debug it deeply, unfortunately.

If the culprit were really my patch, I still don't figure out why it
breaks. In that case, it must be really a subtle timing issue...

thanks,

Takashi

2012-08-25 15:02:25

[permalink] [raw]

Subject: Re: Logitech USB headset not working in 3.6-rc3

On Sat, Aug 25, 2012 at 08:13:27 -0400,
Josh Boyer <[email protected]> wrote:
>On Sat, Aug 25, 2012 at 07:07:40AM -0500, Bruno Wolff III wrote:
>> On Sat, Aug 25, 2012 at 14:02:51 +0200,
>> Daniel Mack <[email protected]> wrote:
>> >
>> >Can you revert commit e9ba389c5 ("ALSA: usb-audio: Fix
>> >scheduling-while-atomic bug in PCM capture stream") and see if that
>>
>> I can try that, but it takes a long time to build a new kernel on my
>> old hardware.
>
>I started a scratch build of a kernel with that patch reverted (via
>patch -R). You'll find it here when it finishes:
>
>http://koji.fedoraproject.org/koji/taskinfo?taskID=4421817

I tested this on two of the three (the other is at work) that I was having
the problem on and they both work as expected now.

2012-08-26 12:46:10

[permalink] [raw]

Subject: Kernel module build workflow (Re: Logitech USB headset not working in 3.6-rc3)

At Sat, 25 Aug 2012 07:16:21 -0500,
Bruno Wolff III wrote:
>
> On Sat, Aug 25, 2012 at 08:13:27 -0400,
> Josh Boyer <[email protected]> wrote:
> >On Sat, Aug 25, 2012 at 07:07:40AM -0500, Bruno Wolff III wrote:
> >> On Sat, Aug 25, 2012 at 14:02:51 +0200,
> >> Daniel Mack <[email protected]> wrote:
> >> >
> >> >Can you revert commit e9ba389c5 ("ALSA: usb-audio: Fix
> >> >scheduling-while-atomic bug in PCM capture stream") and see if that
> >>
> >> I can try that, but it takes a long time to build a new kernel on my
> >> old hardware.
> >
> >I started a scratch build of a kernel with that patch reverted (via
> >patch -R). You'll find it here when it finishes:
> >
> >http://koji.fedoraproject.org/koji/taskinfo?taskID=4421817
> >
> >josh
>
> I'll test it when it finishes. Thanks. It takes me a long time to build
> kernels locally, and I wasn't sure how to do a scratch build on koji without
> committing stuff remotely.

Actually you don't have to rebuild the whole kernel at all just for
debugging this usb-audio bug. The workflow below is what I do often
for debugging a driver problem on a distro kernel.

1. Prepare the compile-ready kernel source tree corresponding to your
running kernel. This may depend on distro; in the case of SUSE,
kernel-default-devel.rpm must be installed for kernel-default.rpm,
for example.

2. Copy sound/usb subdirectory of the kernel source tree locally
anywhere else, say, $HOME/usb. It can be a normal user
directory.

3. Apply the patch to that local directory.

4. Build modules as a normal user like
% make -C /lib/modules/$(uname -r)/build M=$HOME/usb modules

5. Make an extra update directory in the module directory once, e.g.
# mkdir /lib/modules/$(uname -r)/updates

6. Copy *.ko files to there
# cp $HOME/usb/*.ko /lib/modules/$(uname -r)/updates

7. Run depmod once
# /sbin/depmod -a

8. Reload snd-usb-audio module.

If you want to take back to the original module, just remove updates
module directory and run depmod again. Pretty convenient, eh?

HTH,

Takashi

2012-08-29 11:26:38

[permalink] [raw]

Subject: Re: Logitech USB headset not working in 3.6-rc3

On 25.08.2012 14:17, Josh Boyer wrote:
> On Sat, Aug 25, 2012 at 02:13:58PM +0200, Daniel Mack wrote:
>> On 25.08.2012 14:07, Bruno Wolff III wrote:
>>> On Sat, Aug 25, 2012 at 14:02:51 +0200,
>>> Daniel Mack <[email protected]> wrote:
>>>>
>>>> Can you revert commit e9ba389c5 ("ALSA: usb-audio: Fix
>>>> scheduling-while-atomic bug in PCM capture stream") and see if that
>>>
>>> I can try that, but it takes a long time to build a new kernel on my
>>> old hardware.
>>>
>>>> helps? If not, can you summarize again which kernels still work for you
>>>> and which don't?
>>>
>>> The latest kernel that works is 3.6.0-0.rc2.git1.2.fc18. The earliest that
>>> doesn't work is 3.6.0-0.rc2.git2.1.fc18.
>>>
>>
>> The report you sent doesn't look like it could be caused by e9ba389c5.
>> It fixes a kernel Ooops. But as it is the only relevant patch in that
>> area, it would be interesting if reverting it fixes anything.
>
> Yep, agreed. If this revert kernel doesn't work, we're likely down to a
> git bisect, Bruno.
>
>> Btw - thanks a lot for testing -rc kernels, much appreciated!
>
> Indeed!

Could you please try this patch on top of Takashi's? Thanks again!

Daniel

Attachments:

0001-ALSA-snd-usb-Fix-URB-cancellation-at-stream-start.patch (4.56 kB)

2012-08-29 13:29:06

[permalink] [raw]

Subject: Re: Logitech USB headset not working in 3.6-rc3

At Wed, 29 Aug 2012 13:26:25 +0200,
Daniel Mack wrote:
>
> [1 <text/plain; ISO-8859-1 (7bit)>]
> On 25.08.2012 14:17, Josh Boyer wrote:
> > On Sat, Aug 25, 2012 at 02:13:58PM +0200, Daniel Mack wrote:
> >> On 25.08.2012 14:07, Bruno Wolff III wrote:
> >>> On Sat, Aug 25, 2012 at 14:02:51 +0200,
> >>> Daniel Mack <[email protected]> wrote:
> >>>>
> >>>> Can you revert commit e9ba389c5 ("ALSA: usb-audio: Fix
> >>>> scheduling-while-atomic bug in PCM capture stream") and see if that
> >>>
> >>> I can try that, but it takes a long time to build a new kernel on my
> >>> old hardware.
> >>>
> >>>> helps? If not, can you summarize again which kernels still work for you
> >>>> and which don't?
> >>>
> >>> The latest kernel that works is 3.6.0-0.rc2.git1.2.fc18. The earliest that
> >>> doesn't work is 3.6.0-0.rc2.git2.1.fc18.
> >>>
> >>
> >> The report you sent doesn't look like it could be caused by e9ba389c5.
> >> It fixes a kernel Ooops. But as it is the only relevant patch in that
> >> area, it would be interesting if reverting it fixes anything.
> >
> > Yep, agreed. If this revert kernel doesn't work, we're likely down to a
> > git bisect, Bruno.
> >
> >> Btw - thanks a lot for testing -rc kernels, much appreciated!
> >
> > Indeed!
>
> Could you please try this patch on top of Takashi's? Thanks again!
>
>
> Daniel
>
> [2 0001-ALSA-snd-usb-Fix-URB-cancellation-at-stream-start.patch <text/x-patch (7bit)>]
> >From 6617bb2463ae3fad21390b59cc2a71f96b9e9ca8 Mon Sep 17 00:00:00 2001
> From: Daniel Mack <[email protected]>
> Date: Wed, 29 Aug 2012 13:17:05 +0200
> Subject: [PATCH] ALSA: snd-usb: Fix URB cancellation at stream start
>
> Commit e9ba389c5 ("ALSA: usb-audio: Fix scheduling-while-atomic bug in
> PCM capture stream") fixed a scheduling-while-atomic bug that happened
> when snd_usb_endpoint_start was called from the trigger callback, which
> is an atmic context. However, the patch breaks the idea of the endpoints
> reference counting, which is the reason why the driver has been
> refactored lately.
>
> Revert that commit and let snd_usb_endpoint_start() take care of the URB
> cancellation again. As this function is called from both atomic and
> non-atomic context, add a flag to denote whether the function may sleep.
>
> Signed-off-by: Daniel Mack <[email protected]>
> Cc: [email protected] [3.5+]
> ---
> sound/usb/endpoint.c | 10 ++++++++--
> sound/usb/endpoint.h | 2 +-
> sound/usb/pcm.c | 13 +++++--------
> 3 files changed, 14 insertions(+), 11 deletions(-)
>
> diff --git a/sound/usb/endpoint.c b/sound/usb/endpoint.c
> index c411812..678456c 100644
> --- a/sound/usb/endpoint.c
> +++ b/sound/usb/endpoint.c
> @@ -799,7 +799,9 @@ int snd_usb_endpoint_set_params(struct snd_usb_endpoint *ep,
> /**
> * snd_usb_endpoint_start: start an snd_usb_endpoint
> *
> - * @ep: the endpoint to start
> + * @ep: the endpoint to start
> + * @can_sleep: flag indicating whether the operation is executed in
> + * non-atomic context
> *
> * A call to this function will increment the use count of the endpoint.
> * In case it is not already running, the URBs for this endpoint will be
> @@ -809,7 +811,7 @@ int snd_usb_endpoint_set_params(struct snd_usb_endpoint *ep,
> *
> * Returns an error if the URB submission failed, 0 in all other cases.
> */
> -int snd_usb_endpoint_start(struct snd_usb_endpoint *ep)
> +int snd_usb_endpoint_start(struct snd_usb_endpoint *ep, int can_sleep)
> {
> int err;
> unsigned int i;
> @@ -821,6 +823,10 @@ int snd_usb_endpoint_start(struct snd_usb_endpoint *ep)
> if (++ep->use_count != 1)
> return 0;
>
> + /* just to be sure */
> + deactivate_urbs(ep, 0, can_sleep);
> + wait_clear_urbs(ep);

It'd be safer to protect the call of wait_clear_urbs() when
can_sleep=0.

thanks,

Takashi

2012-08-29 13:32:43

[permalink] [raw]

Subject: Re: Logitech USB headset not working in 3.6-rc3

On 29.08.2012 15:29, Takashi Iwai wrote:
> At Wed, 29 Aug 2012 13:26:25 +0200,
> Daniel Mack wrote:
>>
>> [1 <text/plain; ISO-8859-1 (7bit)>]
>> On 25.08.2012 14:17, Josh Boyer wrote:
>>> On Sat, Aug 25, 2012 at 02:13:58PM +0200, Daniel Mack wrote:
>>>> On 25.08.2012 14:07, Bruno Wolff III wrote:
>>>>> On Sat, Aug 25, 2012 at 14:02:51 +0200,
>>>>> Daniel Mack <[email protected]> wrote:
>>>>>>
>>>>>> Can you revert commit e9ba389c5 ("ALSA: usb-audio: Fix
>>>>>> scheduling-while-atomic bug in PCM capture stream") and see if that
>>>>>
>>>>> I can try that, but it takes a long time to build a new kernel on my
>>>>> old hardware.
>>>>>
>>>>>> helps? If not, can you summarize again which kernels still work for you
>>>>>> and which don't?
>>>>>
>>>>> The latest kernel that works is 3.6.0-0.rc2.git1.2.fc18. The earliest that
>>>>> doesn't work is 3.6.0-0.rc2.git2.1.fc18.
>>>>>
>>>>
>>>> The report you sent doesn't look like it could be caused by e9ba389c5.
>>>> It fixes a kernel Ooops. But as it is the only relevant patch in that
>>>> area, it would be interesting if reverting it fixes anything.
>>>
>>> Yep, agreed. If this revert kernel doesn't work, we're likely down to a
>>> git bisect, Bruno.
>>>
>>>> Btw - thanks a lot for testing -rc kernels, much appreciated!
>>>
>>> Indeed!
>>
>> Could you please try this patch on top of Takashi's? Thanks again!
>>
>>
>> Daniel
>>
>> [2 0001-ALSA-snd-usb-Fix-URB-cancellation-at-stream-start.patch <text/x-patch (7bit)>]
>> >From 6617bb2463ae3fad21390b59cc2a71f96b9e9ca8 Mon Sep 17 00:00:00 2001
>> From: Daniel Mack <[email protected]>
>> Date: Wed, 29 Aug 2012 13:17:05 +0200
>> Subject: [PATCH] ALSA: snd-usb: Fix URB cancellation at stream start
>>
>> Commit e9ba389c5 ("ALSA: usb-audio: Fix scheduling-while-atomic bug in
>> PCM capture stream") fixed a scheduling-while-atomic bug that happened
>> when snd_usb_endpoint_start was called from the trigger callback, which
>> is an atmic context. However, the patch breaks the idea of the endpoints
>> reference counting, which is the reason why the driver has been
>> refactored lately.
>>
>> Revert that commit and let snd_usb_endpoint_start() take care of the URB
>> cancellation again. As this function is called from both atomic and
>> non-atomic context, add a flag to denote whether the function may sleep.
>>
>> Signed-off-by: Daniel Mack <[email protected]>
>> Cc: [email protected] [3.5+]
>> ---
>> sound/usb/endpoint.c | 10 ++++++++--
>> sound/usb/endpoint.h | 2 +-
>> sound/usb/pcm.c | 13 +++++--------
>> 3 files changed, 14 insertions(+), 11 deletions(-)
>>
>> diff --git a/sound/usb/endpoint.c b/sound/usb/endpoint.c
>> index c411812..678456c 100644
>> --- a/sound/usb/endpoint.c
>> +++ b/sound/usb/endpoint.c
>> @@ -799,7 +799,9 @@ int snd_usb_endpoint_set_params(struct snd_usb_endpoint *ep,
>> /**
>> * snd_usb_endpoint_start: start an snd_usb_endpoint
>> *
>> - * @ep: the endpoint to start
>> + * @ep: the endpoint to start
>> + * @can_sleep: flag indicating whether the operation is executed in
>> + * non-atomic context
>> *
>> * A call to this function will increment the use count of the endpoint.
>> * In case it is not already running, the URBs for this endpoint will be
>> @@ -809,7 +811,7 @@ int snd_usb_endpoint_set_params(struct snd_usb_endpoint *ep,
>> *
>> * Returns an error if the URB submission failed, 0 in all other cases.
>> */
>> -int snd_usb_endpoint_start(struct snd_usb_endpoint *ep)
>> +int snd_usb_endpoint_start(struct snd_usb_endpoint *ep, int can_sleep)
>> {
>> int err;
>> unsigned int i;
>> @@ -821,6 +823,10 @@ int snd_usb_endpoint_start(struct snd_usb_endpoint *ep)
>> if (++ep->use_count != 1)
>> return 0;
>>
>> + /* just to be sure */
>> + deactivate_urbs(ep, 0, can_sleep);
>> + wait_clear_urbs(ep);
>
> It'd be safer to protect the call of wait_clear_urbs() when
> can_sleep=0.

Right. New patch attached.

Attachments:

0001-ALSA-snd-usb-Fix-URB-cancellation-at-stream-start.patch (4.58 kB)

2012-08-29 14:14:20

[permalink] [raw]

Subject: Re: Logitech USB headset not working in 3.6-rc3

At Wed, 29 Aug 2012 15:32:34 +0200,
Daniel Mack wrote:
>
> [1 <text/plain; ISO-8859-1 (7bit)>]
> On 29.08.2012 15:29, Takashi Iwai wrote:
> > At Wed, 29 Aug 2012 13:26:25 +0200,
> > Daniel Mack wrote:
> >>
> >> [1 <text/plain; ISO-8859-1 (7bit)>]
> >> On 25.08.2012 14:17, Josh Boyer wrote:
> >>> On Sat, Aug 25, 2012 at 02:13:58PM +0200, Daniel Mack wrote:
> >>>> On 25.08.2012 14:07, Bruno Wolff III wrote:
> >>>>> On Sat, Aug 25, 2012 at 14:02:51 +0200,
> >>>>> Daniel Mack <[email protected]> wrote:
> >>>>>>
> >>>>>> Can you revert commit e9ba389c5 ("ALSA: usb-audio: Fix
> >>>>>> scheduling-while-atomic bug in PCM capture stream") and see if that
> >>>>>
> >>>>> I can try that, but it takes a long time to build a new kernel on my
> >>>>> old hardware.
> >>>>>
> >>>>>> helps? If not, can you summarize again which kernels still work for you
> >>>>>> and which don't?
> >>>>>
> >>>>> The latest kernel that works is 3.6.0-0.rc2.git1.2.fc18. The earliest that
> >>>>> doesn't work is 3.6.0-0.rc2.git2.1.fc18.
> >>>>>
> >>>>
> >>>> The report you sent doesn't look like it could be caused by e9ba389c5.
> >>>> It fixes a kernel Ooops. But as it is the only relevant patch in that
> >>>> area, it would be interesting if reverting it fixes anything.
> >>>
> >>> Yep, agreed. If this revert kernel doesn't work, we're likely down to a
> >>> git bisect, Bruno.
> >>>
> >>>> Btw - thanks a lot for testing -rc kernels, much appreciated!
> >>>
> >>> Indeed!
> >>
> >> Could you please try this patch on top of Takashi's? Thanks again!
> >>
> >>
> >> Daniel
> >>
> >> [2 0001-ALSA-snd-usb-Fix-URB-cancellation-at-stream-start.patch <text/x-patch (7bit)>]
> >> >From 6617bb2463ae3fad21390b59cc2a71f96b9e9ca8 Mon Sep 17 00:00:00 2001
> >> From: Daniel Mack <[email protected]>
> >> Date: Wed, 29 Aug 2012 13:17:05 +0200
> >> Subject: [PATCH] ALSA: snd-usb: Fix URB cancellation at stream start
> >>
> >> Commit e9ba389c5 ("ALSA: usb-audio: Fix scheduling-while-atomic bug in
> >> PCM capture stream") fixed a scheduling-while-atomic bug that happened
> >> when snd_usb_endpoint_start was called from the trigger callback, which
> >> is an atmic context. However, the patch breaks the idea of the endpoints
> >> reference counting, which is the reason why the driver has been
> >> refactored lately.
> >>
> >> Revert that commit and let snd_usb_endpoint_start() take care of the URB
> >> cancellation again. As this function is called from both atomic and
> >> non-atomic context, add a flag to denote whether the function may sleep.
> >>
> >> Signed-off-by: Daniel Mack <[email protected]>
> >> Cc: [email protected] [3.5+]
> >> ---
> >> sound/usb/endpoint.c | 10 ++++++++--
> >> sound/usb/endpoint.h | 2 +-
> >> sound/usb/pcm.c | 13 +++++--------
> >> 3 files changed, 14 insertions(+), 11 deletions(-)
> >>
> >> diff --git a/sound/usb/endpoint.c b/sound/usb/endpoint.c
> >> index c411812..678456c 100644
> >> --- a/sound/usb/endpoint.c
> >> +++ b/sound/usb/endpoint.c
> >> @@ -799,7 +799,9 @@ int snd_usb_endpoint_set_params(struct snd_usb_endpoint *ep,
> >> /**
> >> * snd_usb_endpoint_start: start an snd_usb_endpoint
> >> *
> >> - * @ep: the endpoint to start
> >> + * @ep: the endpoint to start
> >> + * @can_sleep: flag indicating whether the operation is executed in
> >> + * non-atomic context
> >> *
> >> * A call to this function will increment the use count of the endpoint.
> >> * In case it is not already running, the URBs for this endpoint will be
> >> @@ -809,7 +811,7 @@ int snd_usb_endpoint_set_params(struct snd_usb_endpoint *ep,
> >> *
> >> * Returns an error if the URB submission failed, 0 in all other cases.
> >> */
> >> -int snd_usb_endpoint_start(struct snd_usb_endpoint *ep)
> >> +int snd_usb_endpoint_start(struct snd_usb_endpoint *ep, int can_sleep)
> >> {
> >> int err;
> >> unsigned int i;
> >> @@ -821,6 +823,10 @@ int snd_usb_endpoint_start(struct snd_usb_endpoint *ep)
> >> if (++ep->use_count != 1)
> >> return 0;
> >>
> >> + /* just to be sure */
> >> + deactivate_urbs(ep, 0, can_sleep);
> >> + wait_clear_urbs(ep);
> >
> > It'd be safer to protect the call of wait_clear_urbs() when
> > can_sleep=0.
>
> Right. New patch attached.

Thanks. This makes me thinking whether we really need to call
deactivate_urbs() at snd_usb_endpoint_start(). deactivate_endpoints()
is called already in prepare (at the beginning). Which possibility is
considered? The comment "just to be sure" implies that my original
code before your stream model change was simply optional. Now I'm not
quite sure whether we can drop it or not...

thanks,

Takashi

>
> [2 0001-ALSA-snd-usb-Fix-URB-cancellation-at-stream-start.patch <text/x-patch (7bit)>]
> >From 42ff3e2d34427dc4c6faa09052a2531f2e71d7d6 Mon Sep 17 00:00:00 2001
> From: Daniel Mack <[email protected]>
> Date: Wed, 29 Aug 2012 13:17:05 +0200
> Subject: [PATCH] ALSA: snd-usb: Fix URB cancellation at stream start
>
> Commit e9ba389c5 ("ALSA: usb-audio: Fix scheduling-while-atomic bug in
> PCM capture stream") fixed a scheduling-while-atomic bug that happened
> when snd_usb_endpoint_start was called from the trigger callback, which
> is an atmic context. However, the patch breaks the idea of the endpoints
> reference counting, which is the reason why the driver has been
> refactored lately.
>
> Revert that commit and let snd_usb_endpoint_start() take care of the URB
> cancellation again. As this function is called from both atomic and
> non-atomic context, add a flag to denote whether the function may sleep.
>
> Signed-off-by: Daniel Mack <[email protected]>
> Cc: [email protected] [3.5+]
> ---
> sound/usb/endpoint.c | 11 +++++++++--
> sound/usb/endpoint.h | 2 +-
> sound/usb/pcm.c | 13 +++++--------
> 3 files changed, 15 insertions(+), 11 deletions(-)
>
> diff --git a/sound/usb/endpoint.c b/sound/usb/endpoint.c
> index c411812..b896c55 100644
> --- a/sound/usb/endpoint.c
> +++ b/sound/usb/endpoint.c
> @@ -799,7 +799,9 @@ int snd_usb_endpoint_set_params(struct snd_usb_endpoint *ep,
> /**
> * snd_usb_endpoint_start: start an snd_usb_endpoint
> *
> - * @ep: the endpoint to start
> + * @ep: the endpoint to start
> + * @can_sleep: flag indicating whether the operation is executed in
> + * non-atomic context
> *
> * A call to this function will increment the use count of the endpoint.
> * In case it is not already running, the URBs for this endpoint will be
> @@ -809,7 +811,7 @@ int snd_usb_endpoint_set_params(struct snd_usb_endpoint *ep,
> *
> * Returns an error if the URB submission failed, 0 in all other cases.
> */
> -int snd_usb_endpoint_start(struct snd_usb_endpoint *ep)
> +int snd_usb_endpoint_start(struct snd_usb_endpoint *ep, int can_sleep)
> {
> int err;
> unsigned int i;
> @@ -821,6 +823,11 @@ int snd_usb_endpoint_start(struct snd_usb_endpoint *ep)
> if (++ep->use_count != 1)
> return 0;
>
> + /* just to be sure */
> + deactivate_urbs(ep, 0, can_sleep);
> + if (can_sleep)
> + wait_clear_urbs(ep);
> +
> ep->active_mask = 0;
> ep->unlink_mask = 0;
> ep->phase = 0;
> diff --git a/sound/usb/endpoint.h b/sound/usb/endpoint.h
> index ee2723f..a8e60c1 100644
> --- a/sound/usb/endpoint.h
> +++ b/sound/usb/endpoint.h
> @@ -13,7 +13,7 @@ int snd_usb_endpoint_set_params(struct snd_usb_endpoint *ep,
> struct audioformat *fmt,
> struct snd_usb_endpoint *sync_ep);
>
> -int snd_usb_endpoint_start(struct snd_usb_endpoint *ep);
> +int snd_usb_endpoint_start(struct snd_usb_endpoint *ep, int can_sleep);
> void snd_usb_endpoint_stop(struct snd_usb_endpoint *ep,
> int force, int can_sleep, int wait);
> int snd_usb_endpoint_activate(struct snd_usb_endpoint *ep);
> diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c
> index 62ec808..1546577 100644
> --- a/sound/usb/pcm.c
> +++ b/sound/usb/pcm.c
> @@ -212,7 +212,7 @@ int snd_usb_init_pitch(struct snd_usb_audio *chip, int iface,
> }
> }
>
> -static int start_endpoints(struct snd_usb_substream *subs)
> +static int start_endpoints(struct snd_usb_substream *subs, int can_sleep)
> {
> int err;
>
> @@ -225,7 +225,7 @@ static int start_endpoints(struct snd_usb_substream *subs)
> snd_printdd(KERN_DEBUG "Starting data EP @%p\n", ep);
>
> ep->data_subs = subs;
> - err = snd_usb_endpoint_start(ep);
> + err = snd_usb_endpoint_start(ep, can_sleep);
> if (err < 0) {
> clear_bit(SUBSTREAM_FLAG_DATA_EP_STARTED, &subs->flags);
> return err;
> @@ -239,7 +239,7 @@ static int start_endpoints(struct snd_usb_substream *subs)
> snd_printdd(KERN_DEBUG "Starting sync EP @%p\n", ep);
>
> ep->sync_slave = subs->data_endpoint;
> - err = snd_usb_endpoint_start(ep);
> + err = snd_usb_endpoint_start(ep, can_sleep);
> if (err < 0) {
> clear_bit(SUBSTREAM_FLAG_SYNC_EP_STARTED, &subs->flags);
> return err;
> @@ -544,13 +544,10 @@ static int snd_usb_pcm_prepare(struct snd_pcm_substream *substream)
> subs->last_frame_number = 0;
> runtime->delay = 0;
>
> - /* clear the pending deactivation on the target EPs */
> - deactivate_endpoints(subs);
> -
> /* for playback, submit the URBs now; otherwise, the first hwptr_done
> * updates for all URBs would happen at the same time when starting */
> if (subs->direction == SNDRV_PCM_STREAM_PLAYBACK)
> - return start_endpoints(subs);
> + return start_endpoints(subs, 1);
>
> return 0;
> }
> @@ -1175,7 +1172,7 @@ static int snd_usb_substream_capture_trigger(struct snd_pcm_substream *substream
>
> switch (cmd) {
> case SNDRV_PCM_TRIGGER_START:
> - err = start_endpoints(subs);
> + err = start_endpoints(subs, 0);
> if (err < 0)
> return err;
>
> --
> 1.7.11.4
>

2012-08-29 14:25:54

[permalink] [raw]

Subject: Re: Logitech USB headset not working in 3.6-rc3

On 29.08.2012 16:14, Takashi Iwai wrote:
> At Wed, 29 Aug 2012 15:32:34 +0200,
> Daniel Mack wrote:
>>
>> [1 <text/plain; ISO-8859-1 (7bit)>]
>> On 29.08.2012 15:29, Takashi Iwai wrote:
>>> At Wed, 29 Aug 2012 13:26:25 +0200,
>>> Daniel Mack wrote:
>>>>
>>>> [1 <text/plain; ISO-8859-1 (7bit)>]
>>>> On 25.08.2012 14:17, Josh Boyer wrote:
>>>>> On Sat, Aug 25, 2012 at 02:13:58PM +0200, Daniel Mack wrote:
>>>>>> On 25.08.2012 14:07, Bruno Wolff III wrote:
>>>>>>> On Sat, Aug 25, 2012 at 14:02:51 +0200,
>>>>>>> Daniel Mack <[email protected]> wrote:
>>>>>>>>
>>>>>>>> Can you revert commit e9ba389c5 ("ALSA: usb-audio: Fix
>>>>>>>> scheduling-while-atomic bug in PCM capture stream") and see if that
>>>>>>>
>>>>>>> I can try that, but it takes a long time to build a new kernel on my
>>>>>>> old hardware.
>>>>>>>
>>>>>>>> helps? If not, can you summarize again which kernels still work for you
>>>>>>>> and which don't?
>>>>>>>
>>>>>>> The latest kernel that works is 3.6.0-0.rc2.git1.2.fc18. The earliest that
>>>>>>> doesn't work is 3.6.0-0.rc2.git2.1.fc18.
>>>>>>>
>>>>>>
>>>>>> The report you sent doesn't look like it could be caused by e9ba389c5.
>>>>>> It fixes a kernel Ooops. But as it is the only relevant patch in that
>>>>>> area, it would be interesting if reverting it fixes anything.
>>>>>
>>>>> Yep, agreed. If this revert kernel doesn't work, we're likely down to a
>>>>> git bisect, Bruno.
>>>>>
>>>>>> Btw - thanks a lot for testing -rc kernels, much appreciated!
>>>>>
>>>>> Indeed!
>>>>
>>>> Could you please try this patch on top of Takashi's? Thanks again!
>>>>
>>>>
>>>> Daniel
>>>>
>>>> [2 0001-ALSA-snd-usb-Fix-URB-cancellation-at-stream-start.patch <text/x-patch (7bit)>]
>>>> >From 6617bb2463ae3fad21390b59cc2a71f96b9e9ca8 Mon Sep 17 00:00:00 2001
>>>> From: Daniel Mack <[email protected]>
>>>> Date: Wed, 29 Aug 2012 13:17:05 +0200
>>>> Subject: [PATCH] ALSA: snd-usb: Fix URB cancellation at stream start
>>>>
>>>> Commit e9ba389c5 ("ALSA: usb-audio: Fix scheduling-while-atomic bug in
>>>> PCM capture stream") fixed a scheduling-while-atomic bug that happened
>>>> when snd_usb_endpoint_start was called from the trigger callback, which
>>>> is an atmic context. However, the patch breaks the idea of the endpoints
>>>> reference counting, which is the reason why the driver has been
>>>> refactored lately.
>>>>
>>>> Revert that commit and let snd_usb_endpoint_start() take care of the URB
>>>> cancellation again. As this function is called from both atomic and
>>>> non-atomic context, add a flag to denote whether the function may sleep.
>>>>
>>>> Signed-off-by: Daniel Mack <[email protected]>
>>>> Cc: [email protected] [3.5+]
>>>> ---
>>>> sound/usb/endpoint.c | 10 ++++++++--
>>>> sound/usb/endpoint.h | 2 +-
>>>> sound/usb/pcm.c | 13 +++++--------
>>>> 3 files changed, 14 insertions(+), 11 deletions(-)
>>>>
>>>> diff --git a/sound/usb/endpoint.c b/sound/usb/endpoint.c
>>>> index c411812..678456c 100644
>>>> --- a/sound/usb/endpoint.c
>>>> +++ b/sound/usb/endpoint.c
>>>> @@ -799,7 +799,9 @@ int snd_usb_endpoint_set_params(struct snd_usb_endpoint *ep,
>>>> /**
>>>> * snd_usb_endpoint_start: start an snd_usb_endpoint
>>>> *
>>>> - * @ep: the endpoint to start
>>>> + * @ep: the endpoint to start
>>>> + * @can_sleep: flag indicating whether the operation is executed in
>>>> + * non-atomic context
>>>> *
>>>> * A call to this function will increment the use count of the endpoint.
>>>> * In case it is not already running, the URBs for this endpoint will be
>>>> @@ -809,7 +811,7 @@ int snd_usb_endpoint_set_params(struct snd_usb_endpoint *ep,
>>>> *
>>>> * Returns an error if the URB submission failed, 0 in all other cases.
>>>> */
>>>> -int snd_usb_endpoint_start(struct snd_usb_endpoint *ep)
>>>> +int snd_usb_endpoint_start(struct snd_usb_endpoint *ep, int can_sleep)
>>>> {
>>>> int err;
>>>> unsigned int i;
>>>> @@ -821,6 +823,10 @@ int snd_usb_endpoint_start(struct snd_usb_endpoint *ep)
>>>> if (++ep->use_count != 1)
>>>> return 0;
>>>>
>>>> + /* just to be sure */
>>>> + deactivate_urbs(ep, 0, can_sleep);
>>>> + wait_clear_urbs(ep);
>>>
>>> It'd be safer to protect the call of wait_clear_urbs() when
>>> can_sleep=0.
>>
>> Right. New patch attached.
>
> Thanks. This makes me thinking whether we really need to call
> deactivate_urbs() at snd_usb_endpoint_start(). deactivate_endpoints()
> is called already in prepare (at the beginning). Which possibility is
> considered? The comment "just to be sure" implies that my original
> code before your stream model change was simply optional. Now I'm not
> quite sure whether we can drop it or not...

Yes, we can most probably drop it, but I would clearly do that in
another patch for 3.6 - I'll prepare one.

I also found some regressions caused by the recent refactoring, and will
send out a patch collection, hopefully later today.

Daniel

2012-08-29 15:01:17

[permalink] [raw]

Subject: Re: Logitech USB headset not working in 3.6-rc3

At Wed, 29 Aug 2012 16:25:46 +0200,
Daniel Mack wrote:
>
> On 29.08.2012 16:14, Takashi Iwai wrote:
> > At Wed, 29 Aug 2012 15:32:34 +0200,
> > Daniel Mack wrote:
> >>
> >> [1 <text/plain; ISO-8859-1 (7bit)>]
> >> On 29.08.2012 15:29, Takashi Iwai wrote:
> >>> At Wed, 29 Aug 2012 13:26:25 +0200,
> >>> Daniel Mack wrote:
> >>>>
> >>>> [1 <text/plain; ISO-8859-1 (7bit)>]
> >>>> On 25.08.2012 14:17, Josh Boyer wrote:
> >>>>> On Sat, Aug 25, 2012 at 02:13:58PM +0200, Daniel Mack wrote:
> >>>>>> On 25.08.2012 14:07, Bruno Wolff III wrote:
> >>>>>>> On Sat, Aug 25, 2012 at 14:02:51 +0200,
> >>>>>>> Daniel Mack <[email protected]> wrote:
> >>>>>>>>
> >>>>>>>> Can you revert commit e9ba389c5 ("ALSA: usb-audio: Fix
> >>>>>>>> scheduling-while-atomic bug in PCM capture stream") and see if that
> >>>>>>>
> >>>>>>> I can try that, but it takes a long time to build a new kernel on my
> >>>>>>> old hardware.
> >>>>>>>
> >>>>>>>> helps? If not, can you summarize again which kernels still work for you
> >>>>>>>> and which don't?
> >>>>>>>
> >>>>>>> The latest kernel that works is 3.6.0-0.rc2.git1.2.fc18. The earliest that
> >>>>>>> doesn't work is 3.6.0-0.rc2.git2.1.fc18.
> >>>>>>>
> >>>>>>
> >>>>>> The report you sent doesn't look like it could be caused by e9ba389c5.
> >>>>>> It fixes a kernel Ooops. But as it is the only relevant patch in that
> >>>>>> area, it would be interesting if reverting it fixes anything.
> >>>>>
> >>>>> Yep, agreed. If this revert kernel doesn't work, we're likely down to a
> >>>>> git bisect, Bruno.
> >>>>>
> >>>>>> Btw - thanks a lot for testing -rc kernels, much appreciated!
> >>>>>
> >>>>> Indeed!
> >>>>
> >>>> Could you please try this patch on top of Takashi's? Thanks again!
> >>>>
> >>>>
> >>>> Daniel
> >>>>
> >>>> [2 0001-ALSA-snd-usb-Fix-URB-cancellation-at-stream-start.patch <text/x-patch (7bit)>]
> >>>> >From 6617bb2463ae3fad21390b59cc2a71f96b9e9ca8 Mon Sep 17 00:00:00 2001
> >>>> From: Daniel Mack <[email protected]>
> >>>> Date: Wed, 29 Aug 2012 13:17:05 +0200
> >>>> Subject: [PATCH] ALSA: snd-usb: Fix URB cancellation at stream start
> >>>>
> >>>> Commit e9ba389c5 ("ALSA: usb-audio: Fix scheduling-while-atomic bug in
> >>>> PCM capture stream") fixed a scheduling-while-atomic bug that happened
> >>>> when snd_usb_endpoint_start was called from the trigger callback, which
> >>>> is an atmic context. However, the patch breaks the idea of the endpoints
> >>>> reference counting, which is the reason why the driver has been
> >>>> refactored lately.
> >>>>
> >>>> Revert that commit and let snd_usb_endpoint_start() take care of the URB
> >>>> cancellation again. As this function is called from both atomic and
> >>>> non-atomic context, add a flag to denote whether the function may sleep.
> >>>>
> >>>> Signed-off-by: Daniel Mack <[email protected]>
> >>>> Cc: [email protected] [3.5+]
> >>>> ---
> >>>> sound/usb/endpoint.c | 10 ++++++++--
> >>>> sound/usb/endpoint.h | 2 +-
> >>>> sound/usb/pcm.c | 13 +++++--------
> >>>> 3 files changed, 14 insertions(+), 11 deletions(-)
> >>>>
> >>>> diff --git a/sound/usb/endpoint.c b/sound/usb/endpoint.c
> >>>> index c411812..678456c 100644
> >>>> --- a/sound/usb/endpoint.c
> >>>> +++ b/sound/usb/endpoint.c
> >>>> @@ -799,7 +799,9 @@ int snd_usb_endpoint_set_params(struct snd_usb_endpoint *ep,
> >>>> /**
> >>>> * snd_usb_endpoint_start: start an snd_usb_endpoint
> >>>> *
> >>>> - * @ep: the endpoint to start
> >>>> + * @ep: the endpoint to start
> >>>> + * @can_sleep: flag indicating whether the operation is executed in
> >>>> + * non-atomic context
> >>>> *
> >>>> * A call to this function will increment the use count of the endpoint.
> >>>> * In case it is not already running, the URBs for this endpoint will be
> >>>> @@ -809,7 +811,7 @@ int snd_usb_endpoint_set_params(struct snd_usb_endpoint *ep,
> >>>> *
> >>>> * Returns an error if the URB submission failed, 0 in all other cases.
> >>>> */
> >>>> -int snd_usb_endpoint_start(struct snd_usb_endpoint *ep)
> >>>> +int snd_usb_endpoint_start(struct snd_usb_endpoint *ep, int can_sleep)
> >>>> {
> >>>> int err;
> >>>> unsigned int i;
> >>>> @@ -821,6 +823,10 @@ int snd_usb_endpoint_start(struct snd_usb_endpoint *ep)
> >>>> if (++ep->use_count != 1)
> >>>> return 0;
> >>>>
> >>>> + /* just to be sure */
> >>>> + deactivate_urbs(ep, 0, can_sleep);
> >>>> + wait_clear_urbs(ep);
> >>>
> >>> It'd be safer to protect the call of wait_clear_urbs() when
> >>> can_sleep=0.
> >>
> >> Right. New patch attached.
> >
> > Thanks. This makes me thinking whether we really need to call
> > deactivate_urbs() at snd_usb_endpoint_start(). deactivate_endpoints()
> > is called already in prepare (at the beginning). Which possibility is
> > considered? The comment "just to be sure" implies that my original
> > code before your stream model change was simply optional. Now I'm not
> > quite sure whether we can drop it or not...
>
> Yes, we can most probably drop it, but I would clearly do that in
> another patch for 3.6 - I'll prepare one.

Yeah, that's fine for post 3.6. I just wondered.

> I also found some regressions caused by the recent refactoring, and will
> send out a patch collection, hopefully later today.

OK, thanks.

Takashi

2012-08-29 17:08:13

[permalink] [raw]

Subject: Re: Logitech USB headset not working in 3.6-rc3

On Wed, Aug 29, 2012 at 03:32:34PM +0200, Daniel Mack wrote:
> On 29.08.2012 15:29, Takashi Iwai wrote:
> > At Wed, 29 Aug 2012 13:26:25 +0200,
> > Daniel Mack wrote:
> >>
> >> [1 <text/plain; ISO-8859-1 (7bit)>]
> >> On 25.08.2012 14:17, Josh Boyer wrote:
> >>> On Sat, Aug 25, 2012 at 02:13:58PM +0200, Daniel Mack wrote:
> >>>> On 25.08.2012 14:07, Bruno Wolff III wrote:
> >>>>> On Sat, Aug 25, 2012 at 14:02:51 +0200,
> >>>>> Daniel Mack <[email protected]> wrote:
> >>>>>>
> >>>>>> Can you revert commit e9ba389c5 ("ALSA: usb-audio: Fix
> >>>>>> scheduling-while-atomic bug in PCM capture stream") and see if that
> >>>>>
> >>>>> I can try that, but it takes a long time to build a new kernel on my
> >>>>> old hardware.
> >>>>>
> >>>>>> helps? If not, can you summarize again which kernels still work for you
> >>>>>> and which don't?
> >>>>>
> >>>>> The latest kernel that works is 3.6.0-0.rc2.git1.2.fc18. The earliest that
> >>>>> doesn't work is 3.6.0-0.rc2.git2.1.fc18.
> >>>>>
> >>>>
> >>>> The report you sent doesn't look like it could be caused by e9ba389c5.
> >>>> It fixes a kernel Ooops. But as it is the only relevant patch in that
> >>>> area, it would be interesting if reverting it fixes anything.
> >>>
> >>> Yep, agreed. If this revert kernel doesn't work, we're likely down to a
> >>> git bisect, Bruno.
> >>>
> >>>> Btw - thanks a lot for testing -rc kernels, much appreciated!
> >>>
> >>> Indeed!
> >>
> >> Could you please try this patch on top of Takashi's? Thanks again!
> >>
> >>
> >> Daniel
> >>
> >> [2 0001-ALSA-snd-usb-Fix-URB-cancellation-at-stream-start.patch <text/x-patch (7bit)>]
> >> >From 6617bb2463ae3fad21390b59cc2a71f96b9e9ca8 Mon Sep 17 00:00:00 2001
> >> From: Daniel Mack <[email protected]>
> >> Date: Wed, 29 Aug 2012 13:17:05 +0200
> >> Subject: [PATCH] ALSA: snd-usb: Fix URB cancellation at stream start
> >>
> >> Commit e9ba389c5 ("ALSA: usb-audio: Fix scheduling-while-atomic bug in
> >> PCM capture stream") fixed a scheduling-while-atomic bug that happened
> >> when snd_usb_endpoint_start was called from the trigger callback, which
> >> is an atmic context. However, the patch breaks the idea of the endpoints
> >> reference counting, which is the reason why the driver has been
> >> refactored lately.
> >>
> >> Revert that commit and let snd_usb_endpoint_start() take care of the URB
> >> cancellation again. As this function is called from both atomic and
> >> non-atomic context, add a flag to denote whether the function may sleep.
> >>
> >> Signed-off-by: Daniel Mack <[email protected]>
> >> Cc: [email protected] [3.5+]
> >> ---
> >> sound/usb/endpoint.c | 10 ++++++++--
> >> sound/usb/endpoint.h | 2 +-
> >> sound/usb/pcm.c | 13 +++++--------
> >> 3 files changed, 14 insertions(+), 11 deletions(-)
> >>
> >> diff --git a/sound/usb/endpoint.c b/sound/usb/endpoint.c
> >> index c411812..678456c 100644
> >> --- a/sound/usb/endpoint.c
> >> +++ b/sound/usb/endpoint.c
> >> @@ -799,7 +799,9 @@ int snd_usb_endpoint_set_params(struct snd_usb_endpoint *ep,
> >> /**
> >> * snd_usb_endpoint_start: start an snd_usb_endpoint
> >> *
> >> - * @ep: the endpoint to start
> >> + * @ep: the endpoint to start
> >> + * @can_sleep: flag indicating whether the operation is executed in
> >> + * non-atomic context
> >> *
> >> * A call to this function will increment the use count of the endpoint.
> >> * In case it is not already running, the URBs for this endpoint will be
> >> @@ -809,7 +811,7 @@ int snd_usb_endpoint_set_params(struct snd_usb_endpoint *ep,
> >> *
> >> * Returns an error if the URB submission failed, 0 in all other cases.
> >> */
> >> -int snd_usb_endpoint_start(struct snd_usb_endpoint *ep)
> >> +int snd_usb_endpoint_start(struct snd_usb_endpoint *ep, int can_sleep)
> >> {
> >> int err;
> >> unsigned int i;
> >> @@ -821,6 +823,10 @@ int snd_usb_endpoint_start(struct snd_usb_endpoint *ep)
> >> if (++ep->use_count != 1)
> >> return 0;
> >>
> >> + /* just to be sure */
> >> + deactivate_urbs(ep, 0, can_sleep);
> >> + wait_clear_urbs(ep);
> >
> > It'd be safer to protect the call of wait_clear_urbs() when
> > can_sleep=0.
>
> Right. New patch attached.

I'll try and get another kernel built with this later today. I'm at
Plumbers so it might have to wait a bit.

Bruno, if you're comfortable adding the patch to the Fedora 18 kernel
via a spec file, you should be able to do a scratch build by passing an
SRPM. If you get tired of waiting for me, give it a shot.

josh

2012-08-29 17:23:12

[permalink] [raw]

Subject: Re: Logitech USB headset not working in 3.6-rc3

On Wed, Aug 29, 2012 at 01:07:53PM -0400, Josh Boyer wrote:
> > Right. New patch attached.
>
> I'll try and get another kernel built with this later today. I'm at
> Plumbers so it might have to wait a bit.

OK, I got impatient with myself and got the kernel building sooner than
I said. Bruno, you can find the kernel here when the build finishes:

http://koji.fedoraproject.org/koji/taskinfo?taskID=4434883

Please test and let us know.

josh

2012-08-29 18:52:15

[permalink] [raw]

Subject: Re: Logitech USB headset not working in 3.6-rc3

On Wed, Aug 29, 2012 at 13:22:54 -0400,
Josh Boyer <[email protected]> wrote:
>On Wed, Aug 29, 2012 at 01:07:53PM -0400, Josh Boyer wrote:
>> > Right. New patch attached.
>>
>> I'll try and get another kernel built with this later today. I'm at
>> Plumbers so it might have to wait a bit.
>
>OK, I got impatient with myself and got the kernel building sooner than
>I said. Bruno, you can find the kernel here when the build finishes:
>
>http://koji.fedoraproject.org/koji/taskinfo?taskID=4434883
>
>Please test and let us know.

I tested 3.6.0-0.rc3.git2.1.3.fc18.x86_64 on my machine at work and sound
through the headset is working. I'll test my i686 machines at home tonight.

2012-08-30 14:10:17

[permalink] [raw]

Subject: Re: Logitech USB headset not working in 3.6-rc3

At Wed, 29 Aug 2012 15:32:34 +0200,
Daniel Mack wrote:
>
> On 29.08.2012 15:29, Takashi Iwai wrote:
> > At Wed, 29 Aug 2012 13:26:25 +0200,
> > Daniel Mack wrote:
> >>
> >> [1 <text/plain; ISO-8859-1 (7bit)>]
> >> On 25.08.2012 14:17, Josh Boyer wrote:
> >>> On Sat, Aug 25, 2012 at 02:13:58PM +0200, Daniel Mack wrote:
> >>>> On 25.08.2012 14:07, Bruno Wolff III wrote:
> >>>>> On Sat, Aug 25, 2012 at 14:02:51 +0200,
> >>>>> Daniel Mack <[email protected]> wrote:
> >>>>>>
> >>>>>> Can you revert commit e9ba389c5 ("ALSA: usb-audio: Fix
> >>>>>> scheduling-while-atomic bug in PCM capture stream") and see if that
> >>>>>
> >>>>> I can try that, but it takes a long time to build a new kernel on my
> >>>>> old hardware.
> >>>>>
> >>>>>> helps? If not, can you summarize again which kernels still work for you
> >>>>>> and which don't?
> >>>>>
> >>>>> The latest kernel that works is 3.6.0-0.rc2.git1.2.fc18. The earliest that
> >>>>> doesn't work is 3.6.0-0.rc2.git2.1.fc18.
> >>>>>
> >>>>
> >>>> The report you sent doesn't look like it could be caused by e9ba389c5.
> >>>> It fixes a kernel Ooops. But as it is the only relevant patch in that
> >>>> area, it would be interesting if reverting it fixes anything.
> >>>
> >>> Yep, agreed. If this revert kernel doesn't work, we're likely down to a
> >>> git bisect, Bruno.
> >>>
> >>>> Btw - thanks a lot for testing -rc kernels, much appreciated!
> >>>
> >>> Indeed!
> >>
> >> Could you please try this patch on top of Takashi's? Thanks again!
> >>
> >>
> >> Daniel
> >>
> >> [2 0001-ALSA-snd-usb-Fix-URB-cancellation-at-stream-start.patch <text/x-patch (7bit)>]
> >> >From 6617bb2463ae3fad21390b59cc2a71f96b9e9ca8 Mon Sep 17 00:00:00 2001
> >> From: Daniel Mack <[email protected]>
> >> Date: Wed, 29 Aug 2012 13:17:05 +0200
> >> Subject: [PATCH] ALSA: snd-usb: Fix URB cancellation at stream start
> >>
> >> Commit e9ba389c5 ("ALSA: usb-audio: Fix scheduling-while-atomic bug in
> >> PCM capture stream") fixed a scheduling-while-atomic bug that happened
> >> when snd_usb_endpoint_start was called from the trigger callback, which
> >> is an atmic context. However, the patch breaks the idea of the endpoints
> >> reference counting, which is the reason why the driver has been
> >> refactored lately.
> >>
> >> Revert that commit and let snd_usb_endpoint_start() take care of the URB
> >> cancellation again. As this function is called from both atomic and
> >> non-atomic context, add a flag to denote whether the function may sleep.
> >>
> >> Signed-off-by: Daniel Mack <[email protected]>
> >> Cc: [email protected] [3.5+]
> >> ---
> >> sound/usb/endpoint.c | 10 ++++++++--
> >> sound/usb/endpoint.h | 2 +-
> >> sound/usb/pcm.c | 13 +++++--------
> >> 3 files changed, 14 insertions(+), 11 deletions(-)
> >>
> >> diff --git a/sound/usb/endpoint.c b/sound/usb/endpoint.c
> >> index c411812..678456c 100644
> >> --- a/sound/usb/endpoint.c
> >> +++ b/sound/usb/endpoint.c
> >> @@ -799,7 +799,9 @@ int snd_usb_endpoint_set_params(struct snd_usb_endpoint *ep,
> >> /**
> >> * snd_usb_endpoint_start: start an snd_usb_endpoint
> >> *
> >> - * @ep: the endpoint to start
> >> + * @ep: the endpoint to start
> >> + * @can_sleep: flag indicating whether the operation is executed in
> >> + * non-atomic context
> >> *
> >> * A call to this function will increment the use count of the endpoint.
> >> * In case it is not already running, the URBs for this endpoint will be
> >> @@ -809,7 +811,7 @@ int snd_usb_endpoint_set_params(struct snd_usb_endpoint *ep,
> >> *
> >> * Returns an error if the URB submission failed, 0 in all other cases.
> >> */
> >> -int snd_usb_endpoint_start(struct snd_usb_endpoint *ep)
> >> +int snd_usb_endpoint_start(struct snd_usb_endpoint *ep, int can_sleep)
> >> {
> >> int err;
> >> unsigned int i;
> >> @@ -821,6 +823,10 @@ int snd_usb_endpoint_start(struct snd_usb_endpoint *ep)
> >> if (++ep->use_count != 1)
> >> return 0;
> >>
> >> + /* just to be sure */
> >> + deactivate_urbs(ep, 0, can_sleep);
> >> + wait_clear_urbs(ep);
> >
> > It'd be safer to protect the call of wait_clear_urbs() when
> > can_sleep=0.
>
> Right. New patch attached.

As the test result looks positive, I applied it for the next pull
request. Thanks.

Takashi

2012-08-30 15:05:30