Created attachment 24941 [details] lspci output from the buggy machine After plugging in Logitech ClearChat Comfort USB headset and listening to/recording sound for 2-5 minutes, all audio input/output from the device stops and any programs that try to play sound lock up. This includes volume managers, flash applications, media players, and so on. Locked applications can usually be unfrozen by removing the device. However, after the device has been removed, some time later (exactly how long varies) the USB mouse will stop responding. Keyboard functionality is uninhibited. After this point, any USB devices that are plugged into the machine, including ones that are removed after the crash and plugged back in are not detected and receive no power from the computer. A reboot is the only way I have found to restore control. Oddly enough, when running ALSA if the USB headset is plugged in while no USB mouse is inserted, the amount of time before a crash is lengthened significantly. The brand of mouse had no effect on how long or if the crash happens. The presence of a mouse does not seem to affect the time until a crash when running OSS4. Additionally, this bug cannot be reproduced on my laptop. Steps to reproduce: Insert the USB headset either before or after boot. Play or record sound. Once audio applications stop responding, remove the USB headset.
Created attachment 24942 [details] lsusb verbose output from buggy machine
Created attachment 24943 [details] output of messages.log pre-crash from buggy machine
Created attachment 24944 [details] ossinfo output from buggy machine
Created attachment 24945 [details] output of messages.log post-crash from buggy machine
Created attachment 24946 [details] output of everything.log post-crash from buggy machine This is where I think you'll get most of the important information. I'm not very familiar with kernel programming, but this output looks relevant.
(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). There's a soflockup-detector trace in the bugzilla report. On Mon, 8 Feb 2010 01:33:37 GMT bugzilla-daemon@bugzilla.kernel.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=15253 > > Summary: USB audio headset crashes entire USB subsystem > Product: Drivers > Version: 2.5 > Kernel Version: 2.6.32.7 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: high > Priority: P1 > Component: USB > AssignedTo: greg@kroah.com > ReportedBy: rwdalpe@gmail.com > Regression: No > > > Created an attachment (id=24941) > --> (http://bugzilla.kernel.org/attachment.cgi?id=24941) > lspci output from the buggy machine > > After plugging in Logitech ClearChat Comfort USB headset and listening > to/recording sound for 2-5 minutes, all audio input/output from the device > stops and any programs that try to play sound lock up. This includes volume > managers, flash applications, media players, and so on. Locked applications > can > usually be unfrozen by removing the device. However, after the device has > been > removed, some time later (exactly how long varies) the USB mouse will stop > responding. Keyboard functionality is uninhibited. After this point, any USB > devices that are plugged into the machine, including ones that are removed > after the crash and plugged back in are not detected and receive no power > from > the computer. A reboot is the only way I have found to restore control. > > Oddly enough, when running ALSA if the USB headset is plugged in while no USB > mouse is inserted, the amount of time before a crash is lengthened > significantly. The brand of mouse had no effect on how long or if the crash > happens. The presence of a mouse does not seem to affect the time until a > crash > when running OSS4. > > Additionally, this bug cannot be reproduced on my laptop. > > Steps to reproduce: > > Insert the USB headset either before or after boot. > Play or record sound. > Once audio applications stop responding, remove the USB headset.
On Mon, 8 Feb 2010, Andrew Morton wrote: > > http://bugzilla.kernel.org/show_bug.cgi?id=15253 > > > > Summary: USB audio headset crashes entire USB subsystem > > After plugging in Logitech ClearChat Comfort USB headset and listening > > to/recording sound for 2-5 minutes, all audio input/output from the device > > stops and any programs that try to play sound lock up. This includes volume > > managers, flash applications, media players, and so on. Locked applications > can > > usually be unfrozen by removing the device. However, after the device has > been > > removed, some time later (exactly how long varies) the USB mouse will stop > > responding. Keyboard functionality is uninhibited. After this point, any > USB > > devices that are plugged into the machine, including ones that are removed > > after the crash and plugged back in are not detected and receive no power > from > > the computer. A reboot is the only way I have found to restore control. Do this: Build a kernel with CONFIG_PRINTK_TIME, CONFIG_FRAME_POINTER, CONFIG_DEBUG_FS, and CONFIG_USB_DEBUG all enabled. Run your test, and when the audio stops _don't_ try to start or kill any audio applications. Instead attach a copy of the dmesg log to the bug report and post an email message to let us know when the log is ready. Based on the log contents, we'll see what happens next. Going by the information you already provided, I'd guess there's something funky about your nVidia USB controller hardware. Alan Stern
Created attachment 25009 [details] post-crash dmesg output from the buggy machine
Sorry it took me so long, but I have done as you said and attached ( http://bugzilla.kernel.org/attachment.cgi?id=25009 ) the dmesg output to the bug report. Some notes about this attachment: 1. You might see a second instance of the USB headset trying to be recognized. This is because I plugged it back in to make sure that the same error was occurring; it was. 2. The last messages from about 544.069838 to the end of the log are the result of me disconnecting my mouse and reconnecting it in order to speed up the mouse crash. Hopefully this is of assistance, and please let me know if there's anything else I need to do.
On Fri, 12 Feb 2010, Winslow Dalpe wrote: > Sorry it took me so long, but I have done as you said and attached ( > http://bugzilla.kernel.org/attachment.cgi?id=25009 ) the dmesg output to > the bug report. > > Some notes about this attachment: > > 1. You might see a second instance of the USB headset trying to be > recognized. This is because I plugged it back in to make sure that the > same error was occurring; it was. The headset apparently was unplugged at time 212.009448, which is long after a whole bunch of error messages about audio output timing out. They may or may not be related to what you hear. Then at time 319.524108 the headset was plugged back in. Is that what you mean? > 2. The last messages from about 544.069838 to the end of the log are the > result of me disconnecting my mouse and reconnecting it in order to > speed up the mouse crash. > > Hopefully this is of assistance, and please let me know if there's > anything else I need to do. It gives me the overall picture. Now you need to repeat the test. This time, when the audio stops, unplug & replug the mouse. Then a few seconds later, unplug the headset. When that is done, mount a debugfs filesystem on /sys/kernel/debug, go to /sys/kernel/debug/usb/ohci/0000:00:04.0/ and attach the files you find there to the bug report. You can omit files that are empty -- the ones that matter most are "registers" and "async". Don't forget to attach the dmesg log as well. Alan Stern
Winslow Dalpe wrote: > [ 109.196676] oss usbaudio: Audio output timed out on device 14. > [ 360.520149] [<f80a798d>] usb_kill_urb+0x5d/0x90 [usbcore] > [ 360.520156] [<fa09fc27>] udi_usb_cancel_request+0x17/0x20 [oss_usb] > [ 360.520159] [<fa0a6d2c>] T.106+0x3c/0x70 [oss_usb] > [ 360.520166] [<f9d529b6>] audio_reset_adev+0x156/0x250 [osscore] This is not a driver that ships with the kernel, we cannot help you with that. (The OSS driver is known to be buggy, and development has stopped, so 4Front Technologies will not be able to help you either.) Please try the ALSA driver. Regards, Clemens
On Mon, 15 Feb 2010, Clemens Ladisch wrote: > Winslow Dalpe wrote: > > [ 109.196676] oss usbaudio: Audio output timed out on device 14. > > [ 360.520149] [<f80a798d>] usb_kill_urb+0x5d/0x90 [usbcore] > > [ 360.520156] [<fa09fc27>] udi_usb_cancel_request+0x17/0x20 [oss_usb] > > [ 360.520159] [<fa0a6d2c>] T.106+0x3c/0x70 [oss_usb] > > [ 360.520166] [<f9d529b6>] audio_reset_adev+0x156/0x250 [osscore] > > This is not a driver that ships with the kernel, we cannot help you > with that. (The OSS driver is known to be buggy, and development has > stopped, so 4Front Technologies will not be able to help you either.) > > Please try the ALSA driver. While it's quite possible that the driver is responsible for the problem, nevertheless Winslow's logs show that khubd is blocked waiting in usb_kill_urb(), which should never happen. Either the oss_usb driver is corrupting an URB or else the OHCI controller/driver combination is malfunctioning. Alan Stern
On 02/15/2010 12:23 PM, Alan Stern wrote: > While it's quite possible that the driver is responsible for the > problem, nevertheless Winslow's logs show that khubd is blocked waiting > in usb_kill_urb(), which should never happen. Either the oss_usb > driver is corrupting an URB or else the OHCI controller/driver > combination is malfunctioning. > > Alan Stern > Although I do not have as detailed error logs for ALSA as I do for OSS, a similar error is returned when using ALSA. Should I reinstall ALSA and repeat the steps that I've already done? Winslow Dalpe
On 02/15/2010 12:23 PM, Alan Stern wrote: > While it's quite possible that the driver is responsible for the > problem, nevertheless Winslow's logs show that khubd is blocked waiting > in usb_kill_urb(), which should never happen. Either the oss_usb > driver is corrupting an URB or else the OHCI controller/driver > combination is malfunctioning. > > Alan Stern > > Although I do not have as detailed error logs for ALSA as I do for OSS, I can tell you that a similar error is returned when using ALSA. Should I reinstall ALSA and repeat the steps that I've already done? Winslow Dalpe
Winslow Dalpe wrote: > On 02/15/2010 12:23 PM, Alan Stern wrote: >> While it's quite possible that the driver is responsible for the >> problem, nevertheless Winslow's logs show that khubd is blocked waiting >> in usb_kill_urb(), which should never happen. > > Although I do not have as detailed error logs for ALSA as I do for OSS, > a similar error is returned when using ALSA. That would be "timeout: still x active urbs.."? This would be a result of the complete callback never be called after usb_unlink_urb(). Regards, Clemens
On Mon, 15 Feb 2010, Winslow Dalpe wrote: > Although I do not have as detailed error logs for ALSA as I do for > OSS, I can tell you that a similar error is returned when using ALSA. > Should I reinstall ALSA and repeat the steps that I've already done? Do you still get the "INFO: task khubd:364 blocked for more than 120 seconds" error messages in the system log? If you do, then carry out the test described in comment #10. Alan Stern
Created attachment 25109 [details] ALSA post-crash dmesg output from buggy machine
On 02/16/2010 10:21 AM, Alan Stern wrote: > Do you still get the "INFO: task khubd:364 blocked for more than 120 > seconds" error messages in the system log? If you do, then carry out > the test described in comment #10. > > Alan Stern > > > No, using the ALSA drivers I no longer see much of the errors from when I was using OSS. However, the problem is not resolved, so if anything I just have less to work with now. Additionally, the errors seem to be inconsistent between tests. I have attached the post crash dmesg output to the report in case it can help. This issue continues with the latest kernel update, also.
>> Do you still get the "INFO: task khubd:364 blocked for more than 120 >> seconds" error messages in the system log? > > No, using the ALSA drivers I no longer see much of the errors from when > I was using OSS. However, the problem is not resolved, The ALSA driver calls usb_unlink_urb() and then waits manually for the complete callbacks to be called. If that doesn't happen in one second, it just prints the message you see in the log: timeout: still 7 active urbs.. and goes on. So we still have some dangling URBs, but nobody is actively waiting for them.
Should I conduct the second set of instructions?
On Fri, 19 Feb 2010, Winslow Dalpe wrote: > Should I conduct the second set of instructions? Yes. Alan Stern
Created attachment 25224 [details] output of dmesg after second test instructions
I have attempted to execute the second test, and the most curious thing happens. I can't finish the test as Alan described it because after unplugging the headset my keyboard freezes also. However, I did manage to log dmesg right before I lost control. Here are things of importance: [ 411.956826] is when audio dies [ 450.414809] marks the removal of the mouse [ 453.709975] is the last message after the mouse is plugged back in Any messages after that point are after the headset is unplugged. I will run the test again, but this time unplugging the headset before the mouse to see if I can keep my keyboard long enough to finish the rest of the test. I will post any relevant files.
Created attachment 25225 [details] output of dmesg after altered second test
Created attachment 25226 [details] registers file from altered second test
Created attachment 25227 [details] periodic file from altered second test
On 02/25/2010 05:06 PM, Winslow Dalpe wrote: > I will run the test again, but this time unplugging the headset before > the mouse to see if I can keep my keyboard long enough to finish the > rest of the test. I will post any relevant files. I did this, and posted dmesg.log and the files periodic and registers. I know Alan said that async was also important, but it was empty so I did not attach it. I don't know if that's due to the fact that I cannot execute the test as described.
On Thu, 25 Feb 2010, Winslow Dalpe wrote: > On 02/25/2010 05:06 PM, Winslow Dalpe wrote: > > I will run the test again, but this time unplugging the headset before > > the mouse to see if I can keep my keyboard long enough to finish the > > rest of the test. I will post any relevant files. > I did this, and posted dmesg.log and the files periodic and registers. I > know Alan said that async was also important, but it was empty so I did > not attach it. I don't know if that's due to the fact that I cannot > execute the test as described. The log and the files don't show anything unusual, except that when you replug the mouse, the computer can't communicate with it. Was the headset still plugged in at that time? Do things improve if you unplug the mouse, then unplug the headset, then plug the mouse back in? My thinking is that somehow the problems with the headset may affect all the devices attached to that bus. Alan Stern