[Bug 1733068] Re: Unmounted USB drives wake up on 16.04

[Alan Stern]

If you want to get more information about what's happening at the USB
level, you should use usbmon (see Documentation/usb/usbmon.txt in the
kernel source for instructions).  It will tell you what commands are
being sent to the drive, but not which program is responsible for
sending them.  Still, you can use it to compare the different Ubuntu
releases.

(Hint: If you do collect a usbmon trace, it helps to unplug beforehand
as many of the other USB devices as you can, to prevent the data streams
from getting all mixed together.)

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1733068

Title:
  Unmounted USB drives wake up on 16.04

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+bug/1733068/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1733068] Re: Unmounted USB drives wake up on 16.04

[Alan Stern]

It wouldn't be surprising to find that udisks2 is the program waking up
your drive.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1733068

Title:
  Unmounted USB drives wake up on 16.04

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+bug/1733068/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1733068] Re: Unmounted USB drives wake up on 16.04

[Alan Stern]

I have no idea which kernel versions Ubuntu uses in its releases, but
the recurring Hardware Error bug should be fixed in the 4.14 kernel.  At
least I think it should -- nobody has reported on whether the fix
actually works, so I have no way of knowing.

As for the drive spontaneously waking up...  You may not be aware of
this, but the kernel periodically probes for drive events, even when no
user process is accessing the drive.  You can control the probe
frequency by writing to the /sys/block/sd?/events_poll_msecs file (fill
in the ? with the drive letter).  -1 means to use the system default
probing interval and 0 means to disable polling entirely.

Now, I'm not saying that the kernel polling is what is waking up your
drive.  But it is something you need to know about.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1733068

Title:
  Unmounted USB drives wake up on 16.04

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+bug/1733068/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Re: [Bug 1136110] Re: USB Audio Codec choppy playback

[Alan Stern]

On Sat, 6 Dec 2014, Tim Passingham wrote:

> I assumed that since others had supplied so much detail I didn't need to
> supply any more.  I was simply saying that this problem affects me as
> well (as I think was requested by an earlier post),

What makes you think this is the same problem?  It probably isn't, 
since the problem that originally provoked this bug report has been 
fixed.  And so have some of the other problems raised later on in this 
same bug report.

> and noting that on
> an older USB-2 only system I get no problems at all (and didn't have on
> previous versions of xubuntu).  I thought that might be useful extra
> information.

I doubt that the age of the system is directly related.

> I don't know enough about linux to know what to include, or how.  I am
> just a user, not any form of expert.  So I don't know what OHCI is, but
> when is says .../0/usb3/3-1... I assume that's what it means.  More fool
> me.
> 
> Both laptops are on 14.04 xubuntu, fully up to date.  If it really will
> help, I will try to read and understand all 200 items here and submit
> further data, but I didn't imagine I'd have anything new to contribute.

What is the output from uname -r?  Also, see comment #172.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1136110

Title:
  USB Audio Codec choppy playback

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1136110/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1136110] Re: USB Audio Codec choppy playback

[Alan Stern]

Tim: This has nothing to do with USB-3.  You can tell from the log:

> Dec 6 13:33:29 twpsamlinux kernel: [ 512.148960] usb 3-1: new full-
speed USB device number 2 using ohci-pci

OHCI is strictly USB-1.1.  However, you have not provided nearly enough
useful information to tell what's going wrong.  You didn't even say what
version of the kernel you are using! -- let alone provide a usbmon trace
like some of the other people contributing to this bug report.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1136110

Title:
  USB Audio Codec choppy playback

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1136110/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1136110] Re: USB Audio Codec choppy playback

[Alan Stern]

I can't tell what's happening with daphile.  Maybe it's simply a matter
of how much network activity or disk activity or graphics activity is
going on at the time.  (Of course, storing a usbmon trace creates some
disk activity of its own...)

You can check whether graphics is the issue by switching to a VT console
while the audio is playing.

There is no way to reconfigure the PCI bus.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1136110

Title:
  USB Audio Codec choppy playback

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1136110/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1136110] Re: USB Audio Codec choppy playback

[Alan Stern]

The usbmon trace contains a bunch of -63 error codes.  28 of them
occurred during the 13-second trace.  This code is documented to mean
"During an OUT transfer, the Host Controller could not retrieve data
system memory fast enough to keep up with the USB data rate".

In other words, the PCI bus in your old laptop was overloaded.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1136110

Title:
  USB Audio Codec choppy playback

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1136110/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1136110] Re: USB Audio Codec choppy playback

[Alan Stern]

Please read comment #172.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1136110

Title:
  USB Audio Codec choppy playback

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1136110/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1136110] Re: USB Audio Codec choppy playback

[Alan Stern]

You can find the correspondence between the PCI device list and the USB
bus list by running

   grep . /sys/bus/usb/devices/usb*/serial

In addition to the NEC controller, your listing includes two EHCI (i.e.,
USB-2) controllers; they are the ones with "Enhanced" in the
description.  Any of those controllers ought to work okay for your
audio.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1136110

Title:
  USB Audio Codec choppy playback

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1136110/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1136110] Re: USB Audio Codec choppy playback

[Alan Stern]

I recently heard that USB audio works okay over USB-3 using xHCI
controllers from NEC rather than Intel; see

   http://marc.info/?l=linux-usb&m=139958150312402&w=2

If you run "lspci", it will show the manufacturers for the xHCI
controllers in your system.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1136110

Title:
  USB Audio Codec choppy playback

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1136110/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1136110] Re: USB Audio Codec choppy playback

[Alan Stern]

There probably is a document somewhere on the Ubuntu web site explaining
how to do this.  (I don't know where, and I don't use Ubuntu.)  Or maybe
Joseph Salisbury can do it for you.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1136110

Title:
  USB Audio Codec choppy playback

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1136110/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1136110] Re: USB Audio Codec choppy playback

[Alan Stern]

Just what I was going to suggest.  Maybe you can find a true USB-2 card
somewhere else.

You can try building a kernel with the attached (untested) patch.  It is
a partial fix for a bug in the xHCI driver, and it might solve your
problem on the USB-3 ports.

** Patch added: "Partial fix for xhci-hcd isochronous start-frame bug"
   
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1136110/+attachment/4103424/+files/xhci-isoc-start.patch

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1136110

Title:
  USB Audio Codec choppy playback

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1136110/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1136110] Re: USB Audio Codec choppy playback

[Alan Stern]

I hate to say this, but the "xhci_hcd" in the second line means that the
port is USB-3, not USB-2.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1136110

Title:
  USB Audio Codec choppy playback

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1136110/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1136110] Re: USB Audio Codec choppy playback

[Alan Stern]

What about the dmesg output for when you plugged in the audio device?

The information in the usbmon trace suggests that the device was plugged
into a USB-3 port, not into the USB-2 PCI card.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1136110

Title:
  USB Audio Codec choppy playback

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1136110/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1136110] Re: USB Audio Codec choppy playback

[Alan Stern]

Have you tried an add-on PCI USB-2 card?  (The lsusb output suggests you
don't.)  That's the combination most likely to work.  If you can do
that, attach the corresponding usbmon trace.

If you don't have any USB-2 ports on the PCI card, attach a usbmon trace
using a USB-2 port on the motherboard.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1136110

Title:
  USB Audio Codec choppy playback

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1136110/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1136110] Re: USB Audio Codec choppy playback

[Alan Stern]

Was this dmesg taken after you plugged the device into the add-on PCI
card?  It shows that the device is connected to a USB-3 port.

That's the reason for your problems; the support in Linux for
isochronous transfers over USB-3 is buggy.  Try plugging the device into
a USB-2 port instead.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1136110

Title:
  USB Audio Codec choppy playback

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1136110/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1136110] Re: USB Audio Codec choppy playback

[Alan Stern]

Do this: After plugging the audio device into the PCI card, run the
"dmesg" command and attach the output to this bug report.

Did you read comment #72 in this bug report?  Follow the intructions in
the URL mentioned in that comment.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1136110

Title:
  USB Audio Codec choppy playback

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1136110/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1136110] Re: USB Audio Codec choppy playback

[Alan Stern]

You know, if would help a lot if you provided some concrete data instead
of just saying "it doesn't work".  For example, what shows up in the
dmesg log when you plug the audio device into the PCI card?  If you
collect a usbmon trace showing a noise-filled session, what do you get
(see comments #72-#53 and also comment #82).

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1136110

Title:
  USB Audio Codec choppy playback

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1136110/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1136110] Re: USB Audio Codec choppy playback

[Alan Stern]

Mark, Phil, and others:

This problem is not going to get solved any time soon.  It requires a
substantial rewrite of a large portion of the ehci-hcd driver,, which
would itself take many months, and I have other things to work on.

In theory you can get around the problem by buying an add-on PCI USB
card and plugging the audio device into that card instead of into the
motherboard's USB ports.  Of course, this isn't practical for laptops
and it has other obvious disadvantages.

If anybody feels like doing the work to fix up ehci-hcd, I'll be happy
to provide advice and oversee their efforts.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1136110

Title:
  USB Audio Codec choppy playback

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1136110/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1136110] Re: USB Audio Codec choppy playback

[Alan Stern]

Andrejs:

If you read comments #118 and #121, you would understand why the
kernel's revert is different from the patch attached to comment #118.

There is another commit currently queued for the 3.13 kernel release:

https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit?id=976b6c064a957445eb0573b270f2d0282630e9b9

You might find that it helps your system.  If it doesn't, please follow
the debugging procedure described in comments #82, 90, 105, and 111.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1136110

Title:
  USB Audio Codec choppy playback

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1136110/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Re: [Bug 1136110] Re: USB Audio Codec choppy playback

[Alan Stern]

On Sat, 9 Nov 2013, Andrejs Hanins wrote:

> Hi all, sorry for bothering, but I'm upgraded to latest Ubuntu 13.10
> and the bug is still there, despite the fact fix was available few
> months ago. Is it expected situation?

Maybe you are seeing a different bug.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1136110

Title:
  USB Audio Codec choppy playback

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1136110/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1191603] Re: raring-updates: regression: 3.8.0-24.35 causes sporadic failure of USB audio devices

[Alan Stern]

Printing the debug messages shouldn't slow down your system very much.
However, the audio driver could indeed slow down your system when a
delay occurs like this.

If you want to check whether printing the debug messages slows down your
system, all you have to do is change the system's printing level and see
what happens.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1191603

Title:
  raring-updates: regression: 3.8.0-24.35 causes sporadic failure of USB
  audio devices

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1191603/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1191603] Re: raring-updates: regression: 3.8.0-24.35 causes sporadic failure of USB audio devices

[Alan Stern]

First, those are not warning messages; they are debugging messages.
Therefore they should not be stored in your system log or printed out.

Second, if you are using a USB webcam then the webcam can't send audio
data to the system if no processing is asking for it.

Third, the messages indicate that the audio I/O was blocked for more
than 0.25 second.  That's a very long time for this sort of thing.  You
might try to find out what caused that blockage and fix it.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1191603

Title:
  raring-updates: regression: 3.8.0-24.35 causes sporadic failure of USB
  audio devices

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1191603/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1191603] Re: raring-updates: regression: 3.8.0-24.35 causes sporadic failure of USB audio devices

[Alan Stern]

Please be more specific.  Which patch causes the side effect?

Also, please attach a portion of your system log showing the warning
messages.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1191603

Title:
  raring-updates: regression: 3.8.0-24.35 causes sporadic failure of USB
  audio devices

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1191603/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1191603] Re: raring-updates: regression: 3.8.0-24.35 causes sporadic failure of USB audio devices

[Alan Stern]

Steve, as the original bug reporter, it's up to you to verify whether or
not the patch attached to comment #75 fixes your problem.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1191603

Title:
  raring-updates: regression: 3.8.0-24.35 causes sporadic failure of USB
  audio devices

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1191603/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1191603] Re: raring-updates: regression: 3.8.0-24.35 causes sporadic failure of USB audio devices

[Alan Stern]

Steve: Since you're using an OHCI controller, the fixes for EHCI won't
help you.  Please try the attached patch and let me know how it works.
If you can run the irqsoff tracer too, that would be great.

** Attachment added: "Accept URB submissions in OHCI during underruns, with a 
debugging message"
   
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1191603/+attachment/3773878/+files/ohci-iso-accept

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1191603

Title:
  raring-updates: regression: 3.8.0-24.35 causes sporadic failure of USB
  audio devices

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1191603/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1191603] Re: raring-updates: regression: 3.8.0-24.35 causes sporadic failure of USB audio devices

[Alan Stern]

Will the people who are experiencing trouble with audio devices attached
to EHCI controllers please try the attached patch?  It won't fix the
underlying problems (underruns in the data stream) but it will prevent
them from causing fatal errors.

I can provide a similar patch for OHCI controllers, if anyone needs it.

** Attachment added: "Accept URB submissions during underruns, with a debugging 
message"
   
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1191603/+attachment/3761476/+files/ehci-iso-accept

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1191603

Title:
  raring-updates: regression: 3.8.0-24.35 causes sporadic failure of USB
  audio devices

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1191603/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1191603] Re: raring-updates: regression: 3.8.0-24.35 causes sporadic failure of USB audio devices

[Alan Stern]

If it's xHCI then there's nothing I can do.  If it's EHCI then the
attached patch ought to help.  For debugging purpose it writes a warning
message to the kernel log whenever an underrun occurs, but it prevents
the underrun from causing a failure.

It turns out there are two bugs in the snd-usb-audio driver, either of
which may be affecting you.  There's a patch for one of the bugs at
, but there's no
fix for the other bug (not enough URBs submitted).

** Attachment added: "Accept URB submissions during underruns, with a warning"
   
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1191603/+attachment/3757297/+files/ehci-iso-accept

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1191603

Title:
  raring-updates: regression: 3.8.0-24.35 causes sporadic failure of USB
  audio devices

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1191603/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1191603] Re: raring-updates: regression: 3.8.0-24.35 causes sporadic failure of USB audio devices

[Alan Stern]

Paul, what kind of USB controller is your sound card attached to (UHCI,
OHCI, or EHCI)?

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1191603

Title:
  raring-updates: regression: 3.8.0-24.35 causes sporadic failure of USB
  audio devices

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1191603/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1103018] Re: line6usb - POD Studio UX2 Playback problem. Very robotic and slightly slower than usual

[Alan Stern]

It looks like this problem was fixed in the 3.9.5 stable kernel release
by commit 33edcea352d7c7e601a61e987b029620fed0ca4d (USB: fix latency in
uhci-hcd and ohci-hcd).

I guess the commit wasn't added to any of the 3.8.stable releases
because they were already closed.  But it is present in 3.10.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1103018

Title:
  line6usb - POD Studio UX2 Playback problem. Very robotic and slightly
  slower than usual

To manage notifications about this bug go to:
https://bugs.launchpad.net/linux/+bug/1103018/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1191603] Re: raring-updates: regression: 3.8.0-24.35 causes sporadic failure of USB audio devices

[Alan Stern]

Steve, any progress on the irqsoff tracing?

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1191603

Title:
  raring-updates: regression: 3.8.0-24.35 causes sporadic failure of USB
  audio devices

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1191603/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1103018] Re: line6usb - POD Studio UX2 Playback problem. Very robotic and slightly slower than usual

[Alan Stern]

Actually, I'd like to see a trace that makes the problem show up
quickly.  Whether that's from the first bad commit or from the current
kernel doesn't matter much.

Instructions for usbmon are in the kernel source file
Documentation/usb/usbmon.txt.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1103018

Title:
  line6usb - POD Studio UX2 Playback problem. Very robotic and slightly
  slower than usual

To manage notifications about this bug go to:
https://bugs.launchpad.net/linux/+bug/1103018/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1103018] Re: line6usb - POD Studio UX2 Playback problem. Very robotic and slightly slower than usual

[Alan Stern]

Can somebody who's getting the "robotic" sound or related problems
please attach a usbmon trace?

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1103018

Title:
  line6usb - POD Studio UX2 Playback problem. Very robotic and slightly
  slower than usual

To manage notifications about this bug go to:
https://bugs.launchpad.net/linux/+bug/1103018/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1191603] Re: raring-updates: regression: 3.8.0-24.35 causes sporadic failure of USB audio devices

[Alan Stern]

The debugging output indicates that interrupts were disabled for
something like 9 ms, which means the problem is caused by some other
part of the kernel, not by ohci-hcd.

To debug farther, use the ftrace facility.  Complete instructions are in
Documentation/trace/ftrace.txt, if you're interested.  For our purposes
here, you should start the irqsoff tracer just before running a test:

   cd /sys/kernel/debug/tracing
   echo 0 > options/function-trace
   echo irqsoff > current_tracer
   echo 1 > tracing_on
   echo 0 > tracing_max_latency
   ... run the test ...
   echo 0 > tracing_on
   cat trace

The contents of the "trace" file are what we need to see.  You can do
this with the regular ohci-hcd driver; the diagnostic patch isn't
necessary.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1191603

Title:
  raring-updates: regression: 3.8.0-24.35 causes sporadic failure of USB
  audio devices

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1191603/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1191603] Re: raring-updates: regression: 3.8.0-24.35 causes sporadic failure of USB audio devices

[Alan Stern]

Sorry about that.  This new version has been tested on my own machine,
so it definitely won't crash or otherwise mess up.

** Attachment added: "Diagnostic patch for OHCI interrupt gaps"
   
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1191603/+attachment/3737929/+files/ohci-test-irqs

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1191603

Title:
  raring-updates: regression: 3.8.0-24.35 causes sporadic failure of USB
  audio devices

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1191603/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1136110] Re: USB Audio Codec choppy playback

[Alan Stern]

Toby: I'm sure whatever problem is caused by the hub is NOT identical to
the original problem.  It may have similar symptoms, but the underlying
cause must be different.  For example, it might be a bug in the hub
itself.

Tyson: In theory, connecting a USB device through a hub should not
affect any latency, DPC or other.  Furthermore, in many cases there is
no choice -- the design of the motherboard forces all non-high-speed
devices to be routed to an on-board hub.

On the other hand, it is true that Linux's support for periodic
transfers to low/full-speed USB devices is more robust in the UHCI and
OHCI drivers than in the EHCI driver.  This means that if your
motherboard has a UHCI or OHCI controller, your DAC (or mouse!) is
likely to work more reliably if plugged directly into the motherboard
than if connected through a USB-2 hub.  Using an old USB-1.1 hub should
be about as good as going directly to the motherboard.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1136110

Title:
  USB Audio Codec choppy playback

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1136110/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1191603] Re: raring-updates: regression: 3.8.0-24.35 causes sporadic failure of USB audio devices

[Alan Stern]

Oops, my fault.  This one should work better.

** Attachment added: "Diagnostic patch for OHCI isochronous gaps"
   
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1191603/+attachment/3725964/+files/ohci-test-irqs

** Patch removed: "Diagnostic patch for OHCI interrupt gaps"
   
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1191603/+attachment/3723579/+files/ohci-test-irqs

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1191603

Title:
  raring-updates: regression: 3.8.0-24.35 causes sporadic failure of USB
  audio devices

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1191603/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1191603] Re: raring-updates: regression: 3.8.0-24.35 causes sporadic failure of USB audio devices

[Alan Stern]

Something went wrong with that last test.  I'm not sure why -- maybe the
patch was tracking the wrong endpoint.  As just one example, the output
should have stopped after those "cannot submit urb" errors.

Anyway, here's a revised version of the patch.  It will provide slightly
different output, and hopefully not so much as before.  When running the
test, you should try to avoid using any other USB devices as much as
possible.  In fact, unplug as many of them as you can.

The first line of output from the patch will be labelled "Alan start";
I'll need to see it to verify that it is working properly.  After that,
there should not be much more output until the problem occurs.  If there
is a lot of output in the first few seconds of the test, you might as
well stop right there and post the results.

** Attachment added: "Diagnostic patch for OHCI interrupt gaps"
   
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1191603/+attachment/3723579/+files/ohci-test-irqs

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1191603

Title:
  raring-updates: regression: 3.8.0-24.35 causes sporadic failure of USB
  audio devices

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1191603/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1191603] Re: raring-updates: regression: 3.8.0-24.35 causes sporadic failure of USB audio devices

[Alan Stern]

The error shows up clearly in the usbmon trace.  It resulted from the
fact that no events occurred during an 8-ms time period; normally an
audio-in transfer would finish up every ms.

Why were there no events during that time?  I can't tell; the two most
likely explanations are a hardware bug in your OHCI USB controller, or
some other driver leaving interrupts disabled for far too long.

The attached patch may help.  It will attempt to print some information
to the system log when one of these gaps occurs.  This ought to pin down
where the source of the problem lies.

** Attachment added: "Diagnostic patch for OHCI interrupt gaps"
   
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1191603/+attachment/3722124/+files/ohci-irq-info

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1191603

Title:
  raring-updates: regression: 3.8.0-24.35 causes sporadic failure of USB
  audio devices

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1191603/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1191603] Re: raring-updates: regression: 3.8.0-24.35 causes sporadic failure of USB audio devices

[Alan Stern]

Oops, I attached the wrong patch file by mistake.  Here's the right one.

** Attachment added: "Diagnostic patch for OHCI interrupt gaps"
   
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1191603/+attachment/3722125/+files/ohci-test-irqs

** Patch removed: "Diagnostic patch for OHCI interrupt gaps"
   
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1191603/+attachment/3722124/+files/ohci-irq-info

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1191603

Title:
  raring-updates: regression: 3.8.0-24.35 causes sporadic failure of USB
  audio devices

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1191603/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1191603] Re: raring-updates: regression: 3.8.0-24.35 causes sporadic failure of USB audio devices

[Alan Stern]

By the way, what about the audio-out stream?  The usbmon traces show
that it uses about twice the bandwidth of the audio-in.  Is it 4-channel
instead of stereo?  Or does it have a sampling rate of 88 KHz?

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1191603

Title:
  raring-updates: regression: 3.8.0-24.35 causes sporadic failure of USB
  audio devices

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1191603/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1191603] Re: raring-updates: regression: 3.8.0-24.35 causes sporadic failure of USB audio devices

[Alan Stern]

I guess it's a matter of what you mean by "latency".

For the next step, I'm going to have to ask for help from somebody who
understands the snd-usb-audio driver.  In the meantime, there is one
more piece of information you can provide.  We should see what lsusb has
to say about your sound device; please attach the output from "lsusb -v
-s 1:2".

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1191603

Title:
  raring-updates: regression: 3.8.0-24.35 causes sporadic failure of USB
  audio devices

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1191603/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1191603] Re: raring-updates: regression: 3.8.0-24.35 causes sporadic failure of USB audio devices

[Alan Stern]

You didn't say what your data value size was.  From looking at the data,
it appears to be 4 bytes (i.e., 32-bit audio -- maybe only 24 of those
32 bits are actually used).

You didn't say how many data values per sample you were using.  From
looking at the data, it appears to be one (i.e., mono).

The documentation file you mentioned talks about frames, periods, and
buffers.  The manual page explains what a period is but not a buffer or
a frame.  It appears that a frame is the same as what I've been calling
a "sample".

You didn't say what you were using for periods/buffer.  From what you
wrote in an earlier comment, it appears to be 2.

Maybe you can understand why I'm feeling a little frustrated.  It would
be nice to have real answers to my questions instead of having to guess.

The documentation file doesn't explain how the latency is calculated.
>From looking at the example, it appears to be frames/period times
periods/buffer divided by the sample rate.  If I understand correctly,
this is the right formula for the output latency, but it is wrong for
the input latency.  The input latency should be frames/period divided by
the sample rate.

Putting together the numbers I guessed for your session, the calculated
latency would be 256 * 2 / 44100 = 11.6 ms.  But the calculated value is
wrong; the correct value is 256 / 44100 = 5.8 ms.  Raising the
frames/period to 512 will double these values.

Why are input latencies computed differently from output latencies?  To
explain, let's consider a simple example.  Suppose we use 256
samples/period and 8 periods/buffer.  If we try to change the output
right now, the changed value goes at the end of the current buffer and
it doesn't reach the hardware until 256*8 sample times have elapsed.
Hence the output latency is 2048 sample times (and of course, the sample
time is one over the sampling rate).

Now suppose we use the same parameters for input.  If the input changes
right now, the changed value will get stored in the current period, and
we will see it when the current period elapses.  Thus the latency will
be 256 sample times, not 2048.

Part of our problem here is that the settings you specify affect how
jack communicates with the kernel's audio driver, but they don't
directly reflect how the kernel's audio driver communicates with the USB
driver.  The usbmon trace for 3.5 shows that the audio driver was really
using the equivalent of 5.5 frames/period and 8 periods/buffer.  This
means the actual latency (as far as the kernel is concerned) was 5.5 /
44100 = 0.125 ms, as I mentioned earlier.  The usbmon trace for 3.8
shows that the audio driver was really using the equivalent of 11
frames/period and 8 periods/buffer, for a latency of 11 / 44100 = 0.25
ms.  Undoubtedly, either of these is a value you could easily live with.

I don't know how the audio driver converts the settings it gets from
jack to the settings it sends to the USB driver, but that appears to be
where the problem lies.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1191603

Title:
  raring-updates: regression: 3.8.0-24.35 causes sporadic failure of USB
  audio devices

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1191603/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1191603] Re: raring-updates: regression: 3.8.0-24.35 causes sporadic failure of USB audio devices

[Alan Stern]

Of course you got a lot more output.  That's because the audio-in worked
under 3.5 but not under 3.8.  It generated something like 7 times as
much data from usbmon as the audio-out, partly because of the
ridiculously low latency.

I assume the 3.8 usbmon trace was also done with jack set to 256.  Can
you provide a short trace (1000 lines would be more than enough) showing
jack at 512?

Part of the difficulty here is that I don't understand your terminology.
What do you mean by a "frame" and a "period"?  You wrote above than 256
"frames/period" gives a round-trip time of 21.3 ms, implying that one
"frame" is 21.3 ms / 512 = 41.6 us.  Where does that number come from
and what does it mean?  Is it a coincidence that this value is 1 / (24
KHz)?

For that matter, what sampling parameters did you use for the audio-in?
That is, bits per data value, data values per sample (i.e., mono vs.
stereo), and samples per second?

Finally, it's worth mentioning that what I wrote earlier wasn't quite
right.  For the audio-in channel, the total pipeline length was indeed 1
ms.  But for incoming data, the latency is the time between transfers,
not the pipeline length, so the latency was actually 125 us.  Neither
value is at all close to your implication that 256 "frames/period" gives
a round-trip time of 10.7 ms.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1191603

Title:
  raring-updates: regression: 3.8.0-24.35 causes sporadic failure of USB
  audio devices

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1191603/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1191603] Re: raring-updates: regression: 3.8.0-24.35 causes sporadic failure of USB audio devices

[Alan Stern]

The two traces are very similar.  They show that both the audio-out and
audio-in channels used latencies of 8 ms, which should have been
absolutely fine.  The only reasons I can think of for a problem to occur
would be a bug in the OHCI hardware (which is not unheard of) or
something disabling interrupts for more than 8 ms (which seems
unlikely).

A usbmon trace showing the problem would help.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1191603

Title:
  raring-updates: regression: 3.8.0-24.35 causes sporadic failure of USB
  audio devices

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1191603/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1191603] Re: raring-updates: regression: 3.8.0-24.35 causes sporadic failure of USB audio devices

[Alan Stern]

I'm not sure what you mean by frames and periods, but 21.3 ms is much
larger than the minimum latency is supposed to be -- it is supposed to
be around 1 - 2 ms.  The usbmon trace attached to comment #25 showed
three channels in use:

   The audio-out channel had a pipeline of 8 transfers, each containing 7 
packets worth of data, with an interval between packets of 1 microframe (a 
microframe = 1/8 ms).  Thus the latency was 7 ms.
(Each packet contained 96 bytes of data.)

   The audio-sync channel had  a pipeline of 4 transfers, each
containing 1 packet with an interval of 8 microframes, for a latency of
4 ms.

  The audio-in channel had a pipeline of 8 transfers, each containing 1
packet with an interval of 1 microframe, for a latency of 1 ms -- which
was too small and resulted in the errors you saw.  (Oddly, each packet
had room for 1024 bytes of data but the device sent only 48 bytes.)

Maybe you can figure out from this how your frames and periods are
related to the transfers, packets, and microframes used on the USB bus.
In any case, if the number of packets in each of the audio-in transfers
was increased to 2, the latency would go up to 2 ms and everything
should work.

If it doesn't, please attach another usbmon trace showing the problem.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1191603

Title:
  raring-updates: regression: 3.8.0-24.35 causes sporadic failure of USB
  audio devices

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1191603/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1191603] Re: raring-updates: regression: 3.8.0-24.35 causes sporadic failure of USB audio devices

[Alan Stern]

It's hard to believe that a latency of 1 ms is usable but a latency of 2
ms (or even 1.5 ms) is not.

The difference between the current kernel and 3.5 is that the driver in
3.5 violated the hardware requirements in the EHCI spec.  It may have
worked for you, but the result was by no means guaranteed.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1191603

Title:
  raring-updates: regression: 3.8.0-24.35 causes sporadic failure of USB
  audio devices

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1191603/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1191603] Re: raring-updates: regression: 3.8.0-24.35 causes sporadic failure of USB audio devices

[Alan Stern]

James, your problem appears to be completely different,because the
usbmon data you attached shows a device running at high speed and
therefore not attached to a UHCI controller.  In this case, the problem
is caused by your application -- it is attempting to use a latency of 1
ms for its audio input, and the USB subsystem just isn't fast enough for
that.  (By contrast, the audio output uses a latency of 7 ms, and the
sync channel uses a latency of 4 ms).

Steve, your output merely shows that the system fell behind, which we
already know.  It would  help to see a usbmon trace, even if it doesn't
show the problem.  The first few seconds of a session would be a good
start; at least I would be able to tell what the expected latencies are.

In all, cases, it should be possible to configure the application to
avoid these problems by making the latency requirements less
restrictive.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1191603

Title:
  raring-updates: regression: 3.8.0-24.35 causes sporadic failure of USB
  audio devices

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1191603/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1191603] Re: raring-updates: regression: 3.8.0-24.35 causes sporadic failure of USB audio devices

[Alan Stern]

usbmon traces can include sensitive data.  However, I don't need to see
the entire trace.  Just the portion in the vicinity of when the error
occurred would be enough.

Also, it would be best if during the test, no other devices on the same
bus were being used.  Just the microphone.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1191603

Title:
  raring-updates: regression: 3.8.0-24.35 causes sporadic failure of USB
  audio devices

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1191603/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1191603] Re: raring-updates: regression: 3.8.0-24.35 causes sporadic failure of USB audio devices

[Alan Stern]

How easy is it to duplicate the problem?  If it isn't too hard, can
somebody provide a usbmon trace showing what happens when the problem
occurs?

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1191603

Title:
  raring-updates: regression: 3.8.0-24.35 causes sporadic failure of USB
  audio devices

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1191603/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1136110] Re: USB Audio Codec choppy playback

[Alan Stern]

Thanks to Tyson and Tim for all their testing.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1136110

Title:
  USB Audio Codec choppy playback

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1136110/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1136110] Re: USB Audio Codec choppy playback

[Alan Stern]

I have submitted a reversion for commit
3e619d04159be54b3daa0b7036b0ce9e067f4b5d.  It will appear probably in
the 3.10-rc6 kernel and then in the next 3.9.stable kernel released
after that.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1136110

Title:
  USB Audio Codec choppy playback

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1136110/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1136110] Re: USB Audio Codec choppy playback

[Alan Stern]

Thanks for testing.  It's good to know that the patch works as intended
and that it fixes the problem.  It indicates that my understanding of
what's going on with the hardware is basically right.

Nevertheless, I think the safest course will be to revert the commit.
This part of the driver is in such bad shape that fixing one bug is
likely to cause another one to surface (which in fact is exactly what
happened to cause your problem in the first place).

Unless there are any objections, I'll submit the reversion next week.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1136110

Title:
  USB Audio Codec choppy playback

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1136110/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1136110] Re: USB Audio Codec choppy playback

[Alan Stern]

I'm not sure if this is worth it...  Reverting that commit would be a
lot more straightforward, and that's probably what I'll end up doing.
However, this patch makes the driver "more correct" -- although it's
still a long way from being right.  But the only way to fix this
properly is to rewrite a large chunk of the code, and that's just not
feasible for a simple regression fix.

In the meantime, I'd like to know what happens when you apply this patch
to the non-working kernel.  Does the sound come out right?  And either
way, what does the "periodic" file say?

** Attachment added: "fix some mistakes in ehci-hcd's split transaction 
scheduler"
   
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1136110/+attachment/3685174/+files/ehci-split-bugs

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1136110

Title:
  USB Audio Codec choppy playback

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1136110/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1136110] Re: USB Audio Codec choppy playback

[Alan Stern]

Just out of curiosity, does it make any difference if you remove the
Logitech receiver?

(Not that I think this would be any sort of fix.  A real code update is
needed.  I just wondered if it would change anything.)

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1136110

Title:
  USB Audio Codec choppy playback

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1136110/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1136110] Re: USB Audio Codec choppy playback

[Alan Stern]

Okay, good, this does help.  The difference between the two kernels
shows up when you compare the lines that say "sitd1" -- the working
kernel has "sitd1-003c" and the non-working kernel has "sitd1-0078".

While this difference is caused by the commit in question, it's more or
less a coincidence that one value works and the other doesn't.  The
commit doesn't really make things worse than they already are; it's just
that this part of the driver is in bad shape generally.

Before I try to do a poper fix, it would help to see the contents of
/sys/kernel/debug/usb/devices while the audio is playing (on either
kernel, it doesn't matter which).

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1136110

Title:
  USB Audio Codec choppy playback

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1136110/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1136110] Re: USB Audio Codec choppy playback

[Alan Stern]

You did set CONFIG_USB_DEBUG correctly, as witnessed by the fact that
the debugging directories and files now exist on your system.  (Actually
the HID section in your .config file is only two lines long; it ends
after the "CONFIG_USB_MOUSE=m" line, but the end isn't marked in any
way.)

The sound being played doesn't matter, so long as the sampling rate is
the same on both the buggy and working kernels.

You can attach the entire file; it isn't tremendously big.  What I
really need to see are the lines marked with "sitd", plus at least one
representative of the various "qh" lines.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1136110

Title:
  USB Audio Codec choppy playback

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1136110/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1136110] Re: USB Audio Codec choppy playback

[Alan Stern]

The two symbols you need to enable are CONFIG_DEBUG_FS (which probably
is enabled already) and CONFIG_USB_DEBUG.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1136110

Title:
  USB Audio Codec choppy playback

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1136110/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1136110] Re: USB Audio Codec choppy playback

[Alan Stern]

I can't make any Canonical-type kernels (and I don't know what "8...20"
means).  But maybe Joseph can help you.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1136110

Title:
  USB Audio Codec choppy playback

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1136110/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1136110] Re: USB Audio Codec choppy playback

[Alan Stern]

The next debugging steps are described in comment #82.  Nobody has done
them yet.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1136110

Title:
  USB Audio Codec choppy playback

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1136110/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Re: [Bug 1136110] Re: USB Audio Codec choppy playback

[Alan Stern]

On Fri, 3 May 2013, Wilbert van Bakel wrote:

> To me this seems a kernel scheduling problem and I experimented with the
> a few well know RT hacks.

This cannot possibly be a scheduling problem.  If it were, reverting 
commit 3e619d04159be would not make any difference.

Alan Stern

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1136110

Title:
  USB Audio Codec choppy playback

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1136110/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1136110] Re: USB Audio Codec choppy playback

[Alan Stern]

Kernel version numbers, especially those used by Canonical, don't mean
much to me.  What matters is whether or not the kernel includes the
troublesome commit identified in comment #67.

Joseph, can you build a pair of test kernels, one with the bad commit
and one without, but both with CONFIG_USB_DEBUG enabled?  Then maybe
people could try them out and report back the debugging information I
asked for in comment #82.

Tim, I'm afraid $248 is somewhat more than I want to spend merely for
testing purposes.  Especially given that there's no guarantee the device
would fail in the same way on my computer (it probably is similar to
your arch i686 machine).

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1136110

Title:
  USB Audio Codec choppy playback

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1136110/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1136110] Re: USB Audio Codec choppy playback

[Alan Stern]

The point of testing on a different computer is to try and narrow down
the location of the problem.  If the problem persists then it's likely
to be in the USB device.  Otherwise it's likely to be in the computer's
hardware or software.

I just realized that my own USB audio device uses asynchronous mode.
(The lsusb output is attached so you can see for yourselves.)  Unlike
Tyson's device it supports only 16-bit audio, not 24-bit, but like his,
it runs at full speed.  And the usbmon output I get from it looks quite
similar to the posted traces.  However my device works just fine, no
crackling noises or anything when running at 44100 samples/second.

So more testing is needed.  Here's the next thing to try.  This will
require a kernel that was built with CONFIG_USB_DEBUG enabled.  Go to
the appropriate subdirectory of /sys/kernel/debug/usb/ehci/.  On Tyson's
system that would be the :00:1a.0 directory (because the EHCI
controller for bus 1 is named :00:1a.0).  While the crackly audio is
playing make a copy of the "periodic" file, and then attach the copy to
this bug report.

It would be great also to see the same thing for a kernel that doesn't
have the troublesome commit.

** Attachment added: "lsusb output for my USB audio device"
   
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1136110/+attachment/3655259/+files/lsusb

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1136110

Title:
  USB Audio Codec choppy playback

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1136110/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1136110] Re: USB Audio Codec choppy playback

[Alan Stern]

I didn't see the last few comments until today, because I wasn't
subscribed to this bug report.  Now I am.

The two usbmon traces don't seem to have any significant differences.
The problem must lie at a lower level, probably something in the
hardware.  Is there any way you can try testing the device with a
different type of computer?

In answer to the questions above:

1) USB 1.1 devices can be either full speed or low speed.  This device
is full speed.  (Low-speed USB does not have enough bandwidth for high-
quality audio and does not support isochronous transfers.)

2) The two modes do have different bandwidth requirements; both are well
below the limits of full-speed USB.  For example, the usbmon traces
showed that the device was using no more than 273 bytes of data every
millisecond, whereas full-speed USB can transfer over 1000 bytes of
isochronous data per millisecond.

3) The buffer size is the same in the working and non-working cases, as
far as I can tell.

The easiest way for me to work on this may be to buy one of these
devices for testing here.  Do you know if any of them are available from
Amazon?

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1136110

Title:
  USB Audio Codec choppy playback

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1136110/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1136110] Re: [alsa-devel] Asynchronous audio USB chips: choppy playback since 3.8-rc7

[Alan Stern]

On Wed, 24 Apr 2013, David Henningsson wrote:

> >> Ok, Joseph Salisbury has build some bisection kernels, and Tyson Tan
> >> relentlessly tested all of them, and it turns out that
> >>
> >> 3e619d0415 ("USB: EHCI: fix bug in scheduling periodic split transfers")
> >>
> >> Is the first bad commit. Also, reverting this commit from the current
> >> mainline head makes the problem disappear.
> >>
> >> Alan, any idea?
> >>
> >>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1136110
> >
> > No ideas as to the cause.
> >
> > For debugging, it would help to see a usbmon trace from a kernel where
> > the problem occurs, together with a trace from another kernel where the
> > problem does not occur.
> >
> > Alan Stern
> 
> First, thanks for looking at this bug.
> 
> While a long-term solution is being discussed, this patch went to stable 
> too, where it is causing regressions. Would it be okay just to revert 
> this patch in the next stable series? (Even if this was a bug fix, few 
> people seem to have noticed?) Or do you envision something else 
> happening but the original -ENOSPC error showing up, due to other stuff 
> that went to stable at the same time?

I think reverting it from stable won't cause any new problems to show 
up (although the original problem will return, obviously).  Go ahead.

At the same time, it would be nice to know that some people are really
carrying out tests to find the reason for the new problem.  Otherwise
we end up with this commit reverted and nobody trying to figure out how
to fix the original bug correctly.

Alan Stern

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1136110

Title:
  USB Audio Codec choppy playback

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1136110/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1136110] Re: [alsa-devel] Asynchronous audio USB chips: choppy playback since 3.8-rc7

[Alan Stern]

On Fri, 19 Apr 2013, Daniel Mack wrote:

> On 03.04.2013 12:25, Takashi Iwai wrote:
> > At Wed, 03 Apr 2013 12:15:25 +0200,
> > David Henningsson wrote:
> >>
> >> Hi ALSA developers,
> >>
> >> Just to get your attention here on what seems to be an USB audio 
> >> regression.
> >>
> >> The bug is described in detail here:
> >>
> >> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1136110?comments=all
> >>
> >> Quoting the bug:
> >>
> >> "
> >> This bug seems to affect only a certain kind of hardware, which is 
> >> called "Asynchronous USB Digital Audio Codec (DAC)". It's said that such 
> >> a DAC hosts the clock itself (USB Device Host). An ordinary DAC, so 
> >> called "Synchronous USB DAC", uses the clock hosted by the mother board, 
> >> which is not affected by this bug.
> >>
> >> When this bug affects an asynchronous USB DAC, the audio played by the 
> >> DAC is constantly interrupted. The playback itself does not stop, but 
> >> the output becomes discontinous, filling with constant crackling noises, 
> >> destroying everything the DAC plays.
> >> "
> >>
> >> According to the bug reporter, which seems to have done quite a bit of 
> >> research, this started between 3.8-rc6 and 3.8-rc7 as well as stable 
> >> kernels and the bug also lists a few commits which could be the cause, 
> >> none under sound/usb though.
> > 
> > Yes, there is no commits regarding usb-audio itself between 3.8-rc6
> > and rc7, so the likely culprit is in drivers/usb (usually either
> > drivers/usb/host or drivers/usb/core).  There are a bunch of changes
> > there, so further bisection would be appreciated.
> 
> Ok, Joseph Salisbury has build some bisection kernels, and Tyson Tan
> relentlessly tested all of them, and it turns out that
> 
> 3e619d0415 ("USB: EHCI: fix bug in scheduling periodic split transfers")
> 
> Is the first bad commit. Also, reverting this commit from the current
> mainline head makes the problem disappear.
> 
> Alan, any idea?
> 
>   https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1136110

No ideas as to the cause.

For debugging, it would help to see a usbmon trace from a kernel where 
the problem occurs, together with a trace from another kernel where the 
problem does not occur.

Alan Stern

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1136110

Title:
  USB Audio Codec choppy playback

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1136110/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1088733] Re: Regression in dib0700 dvb-t driver

[Alan Stern]

Good.  I will submit the changes for inclusion in an upcoming stable
kernel release.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1088733

Title:
  Regression in dib0700 dvb-t driver

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1088733/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1088733] Re: Regression in dib0700 dvb-t driver

[Alan Stern]

Here's a patch to try; it is based on vanilla 3.8.  It contains an
attempted fix for the second software bug plus a work-around for the
hardware bug.

If this doesn't work, I'd like to see another combined usbmon/dmesg
output from a kernel built with this patch plus the most recent
debugging patch (which should apply on top of this one with only minor
offsets).

** Patch added: "Attempt to fix or work around the bug in ehci-hcd"
   
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1088733/+attachment/3546838/+files/ehci-fix.patch

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1088733

Title:
  Regression in dib0700 dvb-t driver

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1088733/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1088733] Re: Regression in dib0700 dvb-t driver

[Alan Stern]

This is good; I think I see what the problem is.

It's actually very complicated, involving two software bugs and a
hardware bug.  The commit you identified fixes one of the software bugs,
so it can't simply be reverted.  But in doing so, it exposed the other
software bug.  My attempts at fixing that one have run afoul of the
hardware bug, which cannot be fixed but only worked around.

This will take more time.  I'll get back to you next week.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1088733

Title:
  Regression in dib0700 dvb-t driver

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1088733/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1088733] Re: Regression in dib0700 dvb-t driver

[Alan Stern]

I finally had a chance to take a look at the new trace data set.
Unfortunately it appears that the kernel was built without
CONFIG_USB_DEBUG, making the data useless.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1088733

Title:
  Regression in dib0700 dvb-t driver

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1088733/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Re: [Bug 1088733] Re: Regression in dib0700 dvb-t driver

[Alan Stern]

On Wed, 6 Feb 2013, Stephen Thirlwall wrote:

> Attached is another set of usbmon captures, as well as the dmesg output
> for each session.

I get the impression that this is a hardware bug, but there's not enough
data to be sure.  Attached is a revised version of the diagnostic patch; 
it will provide a lot more detail about what's going on.  Once again, I'll
need to see both the dmesg logs and the usbmon traces.

Before starting each run, do "dmesg -C" to clear the kernel's log buffer.  
(The boot-up messages aren't particularly relevant.)  It's not necessary
to have more than one recording attempt per run.

Alan Stern

P.S.: Let me know if the attached patch doesn't survive the transition 
from email.


** Attachment added: "ehci-refresh-debug"
   
https://bugs.launchpad.net/bugs/1088733/+attachment/3521106/+files/ehci-refresh-debug

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1088733

Title:
  Regression in dib0700 dvb-t driver

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1088733/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1088733] Re: Regression in dib0700 dvb-t driver

[Alan Stern]

Stephen, please try this debugging patch.  Let's see if the output it
produces can be matched up to the usbmon data for both working and non-
working cases.

** Attachment added: "Diagnostic patch for EHCI qh_refresh() change"
   
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1088733/+attachment/3514990/+files/refresh-debug

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1088733

Title:
  Regression in dib0700 dvb-t driver

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1088733/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1088395] Re: Bug. Can't read uvcvideo (usb video / webcams) devices

[Alan Stern]

On Wed, 19 Dec 2012, Егор Орлов wrote:

> Alan, thank you for your reply. May be in the future this bug will be
> fixed. I understand it's not a simple bug. I will not send any
> messages concerning this bug anymore.
> 
> When I tested the camera on other two machines running Ubuntu it
> showed the same log message but it worked:
>  not running at top speed; connect to a high speed hub

The difference is those other two machines have a non-EHCI host 
controller (either UHCI or OHCI).  Your first machine has only EHCI.

Alan Stern

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1088395

Title:
  Can't read uvcvideo (usb video / webcams) devices

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1088395/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1088395] Re: Bug. Can't read uvcvideo (usb video / webcams) devices

[Alan Stern]

On Mon, 17 Dec 2012, [KOI8-R]  wrote:

> Guys, possibly found bug in usb host controller.

This is not a new bug; it has been known for many, many years.  The 
ehci-hcd driver does not allocate periodic schedules very well for 
full-speed and low-speed devices.

> Attempting to read /dev/video0 for USB video device gives:
> libv4l2: error turning on stream: No space left on device
> 
> The camera:
> Bus 002 Device 006: ID 18ec:3299 Arkmicro Technologies Inc.
> 
> The hardware on that machine, is ok. I also have win7 installed and
> the camera works in it.
> I tested this camera on other two machines with Ubuntu 12.10 and it
> works out of the box (luvcview, guvcview).

Actually, the camera does not seem to be working properly.  Did you 
notice these lines in the log?

[  373.762871] usb 1-1.6: new full-speed USB device number 4 using ehci_hcd
[  373.855116] usb 1-1.6: not running at top speed; connect to a high speed hub

The camera should be running at high speed -- at least, it claims to
support high speed -- but it's only using full speed.

> I tested it with the latest mainline kernel, the bug still exists.

Yes.  I'm afraid this bug isn't going to be fixed any time soon.  
Fixing it will be a pretty big job; it's not a simple bug.

> Here is the link to bug at Ubuntu's launchpad:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1088395
> 
> Necessary files attached.

Alan Stern

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1088395

Title:
  Can't read uvcvideo (usb video / webcams) devices

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1088395/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1069289] Re: 058f:9360 8GB MicroSD card not recognized in Alcor Micro Corp. 8-in-1 Media Card Reader

[Alan Stern]

On Sun, 4 Nov 2012, Dan 'Da Man' wrote:

> Bug Short Description: 058f:9360 8GB MicroSD card not recognized in
> Alcor Micro Corp. 8-in-1 Media Card Reader
> 
> When I insert a 8GB MicroSD into my integrated Alcor Micro Corp.
> 8-in-1 Media Card Reader using Oneiric it is not recognized. However,
> the same MicroSD card works in a different laptop's card reader.
> 
> As well, in 10.04.4 through 11.10, when I insert a 2GB SD card it is
> recognized, automatically mounted, and a window opens to display what
> files are on the card.

It's possible that the old 8-in-1 media card reader can't handle
high-capacity SD cards.  It works okay with the low capacity 2-GB card
but not the 8-GB SDHC card.

However it wouldn't hurt to get more information.  You should post a 
usbmon trace showing what happens when the 8-GB card is inserted.

Alan Stern

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1069289

Title:
  058f:9360 8GB MicroSD card not recognized in Alcor Micro Corp. 8-in-1
  Media Card Reader

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1069289/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1062114] Re: usb issue on Intel chipset: abrupt mouse movements, usb keyboard loosing key events

[Alan Stern]

On Thu, 18 Oct 2012, Martin Vysny wrote:

> Good day,
>thank you for your response, please see the answers below.
> 
> 
> On 10/17/2012 08:05 PM, Alan Stern wrote:
> > On Wed, 17 Oct 2012, Martin Vysny wrote:
> >
> >> Good day,
> >> thank you for your mail. I was finally able to reproduce the issue. I
> >> am attaching a dmesg output of a correct boot (please note that there
> >> still are several unwanted IRQs), and a dmesg output of a reproduced error.
> >
> > Did you boot with the "irqpoll" option?  Judging by the log, it looks
> > like you did.
> >
> 
> Nope, I didn't boot with the irqpoll boot option enabled:
> $ cat /proc/cmdline
> BOOT_IMAGE=/boot/vmlinuz-3.5.0-17-generic 
> root=UUID=02dfb985-99c1-431d-882f-87475db02062 ro 
> crashkernel=384M-2G:64M,2G-:128M splash elevator=noop vt.handoff=7

Hmmm.  Maybe the kernel automatically polls disabled IRQs every 0.1 
second.

> >> [   67.512014] ehci_hcd :00:1d.0: >Unwanted IRQ: c000 0
> >> [   67.512021] ehci_hcd :00:1d.0: >Unwanted IRQ: e000 0
> >> [   67.512023] irq 17: nobody cared (try booting with the "irqpoll" option)
> >> [   67.512026] Pid: 0, comm: swapper/0 Tainted: G   O 
> >> 3.5.0-17-generic #28
> >> [   67.512027] Call Trace:
> >> [   67.512034]  [] __report_bad_irq+0x29/0xd0
> >> [   67.512037]  [] note_interrupt+0x175/0x1c0
> >> [   67.512041]  [] ? intel_idle+0xc3/0x120
> >> [   67.512045]  [] handle_irq_event_percpu+0x9f/0x1d0
> >> [   67.512047]  [] handle_irq_event+0x3b/0x60
> >> [   67.512050]  [] ? unmask_irq+0x30/0x30
> >> [   67.512052]  [] handle_fasteoi_irq+0x4e/0xd0
> >> [   67.512053][] ? do_IRQ+0x42/0xc0
> >> [   67.512062]  [] ? enqueue_hrtimer+0x1e/0x70
> >> [   67.512064]  [] ? common_interrupt+0x30/0x38
> >> [   67.512069]  [] ? in_gate_area+0x10/0x50
> >> [   67.512071]  [] ? intel_idle+0xc3/0x120
> >> [   67.512076]  [] ? cpuidle_enter+0x15/0x20
> >> [   67.512078]  [] ? cpuidle_idle_call+0x88/0x220
> >> [   67.512081]  [] ? cpu_idle+0xaa/0xe0
> >> [   67.512086]  [] ? rest_init+0x5d/0x68
> >> [   67.512090]  [] ? start_kernel+0x35d/0x363
> >> [   67.512092]  [] ? do_early_param+0x80/0x80
> >> [   67.512094]  [] ? i386_start_kernel+0xa6/0xad
> >> [   67.512095] handlers:
> >> [   67.512098] [] usb_hcd_irq
> >> [   67.512099] Disabling IRQ #17
> >> [   69.507175] ehci_hcd :00:1d.0: >Unwanted IRQ: c000 0
> >> [   69.607118] ehci_hcd :00:1d.0: >Unwanted IRQ: c000 0
> >
> > The debugging output show that the EHCI controller was not the source
> > of the unwanted IRQs.  And /proc/interrupts shows that ehci-hcd is the
> > only driver using IRQ #17, for the :00:1d.0 device.

This should be stated more carefully.  The EHCI controller was not the 
source of the unwanted IRQs, unless it is somehow malfunctioning.

> > The most likely explanation is that there an interrupt-routing error
> > and some other device is causing these problems.  I don't know of any
> > easy way to find out what the other device is, however.
> >
> 
> Thanks for hinting at the probable source of the problem. I am new to 
> these things, but the /proc/interrupts lists IO-APIC-fasteoi. Perhaps 
> there may be some relation to some APIC issue?

There may be, but I don't know anything about that.  Somebody else will 
have to help.

Alan Stern

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1062114

Title:
  usb behaving strangely (e.g. abrupt mouse movements, usb keyboard
  loosing key events)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1062114/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1062114] Re: usb issue on Intel chipset: abrupt mouse movements, usb keyboard loosing key events

[Alan Stern]

On Wed, 17 Oct 2012, Martin Vysny wrote:

> Good day,
>thank you for your mail. I was finally able to reproduce the issue. I 
> am attaching a dmesg output of a correct boot (please note that there 
> still are several unwanted IRQs), and a dmesg output of a reproduced error.

Did you boot with the "irqpoll" option?  Judging by the log, it looks 
like you did.

> [   67.512014] ehci_hcd :00:1d.0: >Unwanted IRQ: c000 0
> [   67.512021] ehci_hcd :00:1d.0: >Unwanted IRQ: e000 0
> [   67.512023] irq 17: nobody cared (try booting with the "irqpoll" option)
> [   67.512026] Pid: 0, comm: swapper/0 Tainted: G   O 
> 3.5.0-17-generic #28
> [   67.512027] Call Trace:
> [   67.512034]  [] __report_bad_irq+0x29/0xd0
> [   67.512037]  [] note_interrupt+0x175/0x1c0
> [   67.512041]  [] ? intel_idle+0xc3/0x120
> [   67.512045]  [] handle_irq_event_percpu+0x9f/0x1d0
> [   67.512047]  [] handle_irq_event+0x3b/0x60
> [   67.512050]  [] ? unmask_irq+0x30/0x30
> [   67.512052]  [] handle_fasteoi_irq+0x4e/0xd0
> [   67.512053][] ? do_IRQ+0x42/0xc0
> [   67.512062]  [] ? enqueue_hrtimer+0x1e/0x70
> [   67.512064]  [] ? common_interrupt+0x30/0x38
> [   67.512069]  [] ? in_gate_area+0x10/0x50
> [   67.512071]  [] ? intel_idle+0xc3/0x120
> [   67.512076]  [] ? cpuidle_enter+0x15/0x20
> [   67.512078]  [] ? cpuidle_idle_call+0x88/0x220
> [   67.512081]  [] ? cpu_idle+0xaa/0xe0
> [   67.512086]  [] ? rest_init+0x5d/0x68
> [   67.512090]  [] ? start_kernel+0x35d/0x363
> [   67.512092]  [] ? do_early_param+0x80/0x80
> [   67.512094]  [] ? i386_start_kernel+0xa6/0xad
> [   67.512095] handlers:
> [   67.512098] [] usb_hcd_irq
> [   67.512099] Disabling IRQ #17
> [   69.507175] ehci_hcd :00:1d.0: >Unwanted IRQ: c000 0
> [   69.607118] ehci_hcd :00:1d.0: >Unwanted IRQ: c000 0

The debugging output show that the EHCI controller was not the source
of the unwanted IRQs.  And /proc/interrupts shows that ehci-hcd is the
only driver using IRQ #17, for the :00:1d.0 device.

The most likely explanation is that there an interrupt-routing error 
and some other device is causing these problems.  I don't know of any 
easy way to find out what the other device is, however.

Alan Stern

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1062114

Title:
  usb behaving strangely (e.g. abrupt mouse movements, usb keyboard
  loosing key events)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1062114/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1062114] Re: usb issue on Intel chipset: abrupt mouse movements, usb keyboard loosing key events

[Alan Stern]

On Fri, 12 Oct 2012, Martin Vysny wrote:

> usb issue: abrupt mouse movements, usb keyboard loosing key events
> 
> After some boots, the USB mouse behaves strangely (abrupt mouse 
> movements), also, USB keyboard tends to loose some keypresses. This 
> behavior occurs randomly (I can't find out what's causing this) and 
> lasts from the point when lightdm is displayed until the computer is 
> rebooted. This issue never starts to manifest during computer runtime - 
> either it is present right from the Ubuntu start, or it does not occur. 
> The issue is never present in grub menu, in Windows, nor in BIOS menu. 
> Sometimes, the bug manifests in multiple consecutive reboots.
> Running commands as described here: 
> http://davidjb.com/blog/2012/06/restartreset-usb-in-ubuntu-12-04-without-rebooting
>  
> fixes the issue (until the following computer boot - not necessarily the 
> very next boot). There is an interesting warning in my dmesg about 
> ignored IRQ 17 - perhaps it is somehow related?
> [ 40.224653] irq 17: nobody cared (try booting with the "irqpoll" option)
> [ 40.224668] [] __report_bad_irq+0x29/0xd0
> [ 40.224678] [] handle_irq_event_percpu+0x9f/0x1d0
> [ 40.224680] [] ? unmask_irq+0x30/0x30
> [ 40.224688] [] handle_irq_event+0x3b/0x60
> [ 40.224689] [] ? unmask_irq+0x30/0x30
> [ 40.224691] [] handle_fasteoi_irq+0x4e/0xd0
> [ 40.224692]  [] ? do_IRQ+0x42/0xc0
> [ 40.224728] [] usb_hcd_irq
> [ 40.224729] Disabling IRQ #17

Undoubtedly this is related.  Here's a debugging patch to help get more 
information.  Let's what shows up in your system log with the patch 
installed.

Alan Stern


Index: usb-3.6/drivers/usb/host/ehci-hcd.c
===
--- usb-3.6.orig/drivers/usb/host/ehci-hcd.c
+++ usb-3.6/drivers/usb/host/ehci-hcd.c
@@ -727,6 +727,7 @@ static irqreturn_t ehci_irq (struct usb_
/* Shared IRQ? */
if (!masked_status || unlikely(ehci->rh_state == EHCI_RH_HALTED)) {
spin_unlock(&ehci->lock);
+   ehci_info(ehci, "Unwanted IRQ: %x %x\n", status, masked_status);
return IRQ_NONE;
}

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1062114

Title:
  usb behaving strangely (e.g. abrupt mouse movements, usb keyboard
  loosing key events)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1062114/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1050566] Re: 0711:5100 sisusbvga driver not working with StarTech USB2VGAE2

[Alan Stern]

On Fri, 21 Sep 2012, Anthony Hook wrote:

> Apologies, this is my first ever upstream report. I hope I did alright
> by whoever gets this.
> -
> 0711:5100 sisusbvga driver not working with StarTech USB2VGAE2
> 
> Along with the bug posted at:
> 
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/517934
> 
> I am not able to use this device. I have not, however, manually added
> the device ID and recompiled, as the original poster did.
> 
> Upon plugging it in, dmesg shows:
> 
> [21732.185356] usb 1-1.4.3: USB disconnect, device number 5
> [22319.105209] usb 2-1.1: new high-speed USB device number 4 using ehci_hcd
> 
> and lsusb:
> 
> Bus 002 Device 004: ID 0711:5100 Magic Control Technology Corp. Magic
> Control Technology Corp. (USB2VGA dongle)

The sisusbvga driver's device table does not include an entry for ID
0711:5100.  You will have to add it to make the driver work, like the 
original poster did.

The file to edit is drivers/usb/misc/sisusbvga/sisusb.c.  Add an entry 
to the sisusb_table[] array.

Alan Stern

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1050566

Title:
  0711:5100 sisusbvga driver not working with StarTech USB2VGAE2

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1050566/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 964133] Re: PROBLEM: Certain USB devices wake up the system after power off

[Alan Stern]

On Wed, 22 Aug 2012, Àlex Magaz Graça wrote:

> Hi,
> 
> [1.] One line summary of the problem:
> Certain USB devices wake up the system after power off
> 
> [2.] Full description of the problem/report:
> 
> The computer no longer shuts down properly after upgrading from Ubuntu 
> 11.04 to 11.10 (this is from kernel 2.6.38 to 3.0.20 (*)), it powers on 
> immediately after being shut down.
> 
> WORKAROUND: It doesn't happen if any of the problematic USB devices are 
> not plugged.
> 
> I perform the following the following steps:
> 
> 1. Switch to a virtual terminal (no XWindow) and log in.
> 2. Run: sudo poweroff
> 3. The computer shuts down (I see how all LEDs switch off and hear the 
> hard drive stopping).
> 4. Immediately the computer powers on again.
> 
> It only fails when the device is plugged in on the back USB ports, NOT 
> in the ones in the front panel.
>- Fails with: WiFi card or pendrive.
>- Doesn't fail with: printer, keyboard/mouse wireless receiver, 
> bluetooth dongle.
> 
> If I boot passing acpi=off to the kernel command line, the computer 
> doesn't shut down.
> 
> After bisecting I've found the problem was introduced in commit 
> c61875977458637226ab093a35d200f2d5789787. OHCI: final fix for NVIDIA 
> problems (I hope).

That patch affects shutdown for all OHCI controllers, not just NVIDIA
controllers.  On the other hand, it's strange that the problem is
triggered only by devices that don't use OHCI.

Have you checked for any BIOS updates from the manufacturer?

The lsusb output attached to your bug report indicates that only two
devices were plugged in: the WiFi card and the wireless receiver.  
What happens if the only USB device attached is the WiFi card?  (For
best testing, unplug the receiver and other things before you boot.)

Please post the output from:

ls -d /sys/bus/pci/drivers/?hci_hcd/*/usb?

Also, post the output from "lsusb" with the WiFi card plugged 
into a rear port and the pendrive plugged into a front port.

Alan Stern

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/964133

Title:
  0ace:1211 WiFi USB card wakes up the system after power off

To manage notifications about this bug go to:
https://bugs.launchpad.net/linux/+bug/964133/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1032342] Re: 090c:1000 file transfer to/from USB 2.0 flash drive, via 3.0 port at best 50-60 Mb/s

[Alan Stern]

On Fri, 3 Aug 2012, mat brown wrote:

> I'm getting a bit out of my depth now, but I'm pretty sure the
> xhci_hcd module is compiled into the Ubuntu kernels.  If I were to dig
> around in Ubuntu's kernel sources looking for xhci_hcd.* files to diff
> against Fedora's, would that be a useful thing for me to do?

I don't know.  If there's no difference then it wouldn't be very
useful.  :-)

> It's been a few years but I have compiled my own kernels in the past,
> but I can definitely have a go at that if you think it would be
> beneficial.

There aren't too many alternatives at this point.  One possibility is
to try booting a Fedora kernel on an Ubuntu system.  I don't know if
that can work, but if it does then it would indicate whether the
problem is in the kernel or in the userspace environment.

> Thanks for your help so far Alan, it's very much appreciated.  I know
> wizards of your level are busy people.

You're welcome.  (And I don't feel like a wizard; I feel like an 
ordinary busy person...)

Alan Stern

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1032342

Title:
  090c:1000 file transfer to/from USB 2.0 flash drive, via 3.0 port at
  best 50-60 Mb/s

To manage notifications about this bug go to:
https://bugs.launchpad.net/linux/+bug/1032342/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1032342] Re: 090c:1000 file transfer to/from USB 2.0 flash drive, via 3.0 port at best 50-60 Mb/s

[Alan Stern]

On Fri, 3 Aug 2012, mat brown wrote:

> Already done as requested by the Ubuntu devs.  File is here:
> https://launchpadlibrarian.net/111697628/usbmon.out
> 
> The transfer which created that file was generated using dd
> if=/dev/zero of=/media/littlun/tmp oflag=direct bs=120K count=2K

It's odd.  The usbmon log shows things working pretty well most of the
time, with transfer speeds around 200 Mb/s, but every now and then a
single 120-KB transfer takes more than half a second!

I have no idea why.  We can rule out hardware problems because it 
doesn't happen under Fedora.  Maybe interrupt delivery gets delayed 
somehow under Ubuntu, or maybe something is different in the xhci-hcd 
driver.  Can you compare the driver source files?

To do more serious testing will require you to build your own kernel, 
or at least, your own version of the driver.

Alan Stern

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1032342

Title:
  090c:1000 file transfer to/from USB 2.0 flash drive, via 3.0 port at
  best 50-60 Mb/s

To manage notifications about this bug go to:
https://bugs.launchpad.net/linux/+bug/1032342/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1032342] Re: 090c:1000 file transfer to/from USB 2.0 flash drive, via 3.0 port at best 50-60 Mb/s

[Alan Stern]

On Fri, 3 Aug 2012, mat brown wrote:

> mount reports the following:
> 
> /dev/sdb1 on /media/littlun type vfat
> (rw,nosuid,nodev,uid=1000,gid=1000,shortname=mixed,dmask=0077,utf8=1,showexec,flush,uhelper=udisks)
> 
> Nothing shows up in syslog during transfers.
> 
> One thing I hadn't tried until a moment ago was an fs other than
> fat32.  Same issue occurs with ext4.

In that case you should use usbmon to record what happens during one of
the slow transfers.  Instructions are in the kernel source file
Documentation/usb/usbmon.txt.

It doesn't have to be a big transfer; 10 MB will probably be enough to
point out the problem.

Alan Stern

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1032342

Title:
  090c:1000 file transfer to/from USB 2.0 flash drive, via 3.0 port at
  best 50-60 Mb/s

To manage notifications about this bug go to:
https://bugs.launchpad.net/linux/+bug/1032342/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1032342] Re: 090c:1000 file transfer to/from USB 2.0 flash drive, via 3.0 port at best 50-60 Mb/s

[Alan Stern]

On Fri, 3 Aug 2012, mat brown wrote:

> The following is formatted in line with the info here:
> https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Kernel.org_Format
> and sent as advised at the end of this bug report here:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1032342
> 
> Thanks in advance for your time, I very much hope I've minimised any
> wastage of that precious resource.


> Summary:
> 
> 090c:1000 file transfer to/from USB 2.0 flash drive, via 3.0 port at
> best 50-60 Mb/s

> The reason I'm reporting it here rather than at kernel.org is that I
> don't think it's a kernel bug, I think it's to do with Debian/Ubuntu's
> kernel patches. Because it doesn't happen in the live version of
> Fedora 17 I tried, but it does happen with Debian Wheezy. Windows 7 is
> also fast.

What mount options are used for the flash drive?  In particular, does
Ubuntu use the "sync" option?

Also, do any error messages show up in the system log during the slow 
data transfers?

Alan Stern

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1032342

Title:
  090c:1000 file transfer to/from USB 2.0 flash drive, via 3.0 port at
  best 50-60 Mb/s

To manage notifications about this bug go to:
https://bugs.launchpad.net/linux/+bug/1032342/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 42149] Re: USB devices are not powered off at shutdown

[Alan Stern]

Thanks Don, but that doesn't address the question I was asking.  It
doesn't matter whether or not the existing kernels work on your
computer; the question is whether the new test kernel works.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/42149

Title:
  USB devices are not powered off at shutdown

To manage notifications about this bug go to:
https://bugs.launchpad.net/linux/+bug/42149/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 42149] Re: USB devices are not powered off at shutdown

[Alan Stern]

To everybody who has been affected by this problem:

Attached is a kernel patch which (I hope) will solve the whole matter
once and for all.  The patch was written for a 3.1 kernel, but it should
apply with only minimal changes to other recent kernels.  It will affect
the way the system handles OHCI controllers -- even systems that are
working okay now.

Since different types of NVIDIA controllers and chipsets behave in
different ways, I'd like to get as much testing over as wide a range of
hardware as possible before submitting this for the official kernel.

Please test the patch and let me know if there are any problems with it.
Two particular things to look out for: Are USB devices powered down
properly when the system shuts down?  Does the controller continue to
work after you do "rmmod ohci-hcd ; modprobe ohci-hcd"?

Thanks.

** Attachment added: "Reset and suspend all idle OHCI controllers; remove 
NVIDIA shutdown quirk"
   
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/42149/+attachment/2588553/+files/ohci-idle-suspend

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/42149

Title:
  USB devices are not powered off at shutdown

To manage notifications about this bug go to:
https://bugs.launchpad.net/linux/+bug/42149/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs