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, yo
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 noti
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...
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 pro
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.
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
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
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/ubunt
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 c
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 b
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
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-hc
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 ma
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 Ubu
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.
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
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
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-
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 U
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=976b6c064a9
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 notificati
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 lev
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
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
Titl
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
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
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, i
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-aud
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 sp
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.
-
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 ma
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 yo
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 probl
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.
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
--
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
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.
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, an
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 yo
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 interrup
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 subs
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;
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).
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. C
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 inte
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 cont
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 guarante
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
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 receiv
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
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://bug
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 Ubunt
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 su
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
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, wh
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 th
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 b
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 p
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 pl
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 notification
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
-
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_D
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
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 devi
10
> >
> > 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
>
>
hat
>
> 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/
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 notifi
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
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 th
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.launchp
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-
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/+attach
g 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 noti
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
--
Y
ssible 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.
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 f
ing 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 notifica
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
y 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
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
ur 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
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
e 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 dri
unt 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 subsc
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 th
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 OHC
86 matches
Mail list logo
