David et al--
I've been working on a problem where devices plugged into a USB 2.0 hub
(which is plugged into an EHCI controller) aren't seen until there is some
other activity in the USB subsystem. To reproduce this, I booted up a
system with a USB2.0 hub connected to my EHCI controller, and,
Right, thanks. Sorry I didn't see that--it was fixed it in a different way
than I was looking for. I didn't actually test the latest kernels, but just
looked at the source.
Stuart
-Original Message-
From: David Brownell [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 27, 2004 2:27
One question on that, though. With the fix that was put into 2.4.22, the qh
is now initialized as live by qh_make (i.e., the halt bit isn't set). Then,
in intr_submit, the qh is scheduled with no QTDs, and the QTDs are added to
the live qh. When the QTDs are inserted by qh_append_tds, it sets
That's what I was missing: the queue advance is aborted if the QTD's active
bit isn't set.
Thanks again!
Stuart
-Original Message-
From: David Brownell [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 27, 2004 5:56 PM
To: Hayes, Stuart
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject:
is in uninterruptible sleep state. I can reproduce the failure by
cat'ing
/proc/bus/usb/devices while performing a mount on the usbdrive. Below
is a
This problem sounds a lot like one that I encountered a few months ago
with a Teac USB CD-ROM drive--the drive couldn't handle being accessed
I'm not the world's top authority on the subject, but my understanding
is that requests on endpoint 0 will either be standard device requests
(such as reading basic information about the device), or device specific
requests (things such as SET_IDLE for keyboard/mouse devices, which can
be used to
I notice that ehci-hcd.c only waits up to 25ms after setting CMD_RESET
in the EHCI command register before timing out and giving up.
Is that 25ms based on observation, or is it actually specified
somewhere? I couldn't find anything in the EHCI 1.0 spec that says how
long a controller can take
Will Beers wrote:
though maybe 500 msec is too short a period to wait.
See if 5000 msec helps.
I went all the way up to 2 msec and it still didn't help. I'm
sure it's a bad idea, but removing that whole if-block below it makes
it work (which is effectively what switching the and/or
I have several systems that are failing with the messages below when
the uhci-hcd module is loaded. This only seems to happen when the
QHs and/or TDs (I haven't narrowed this down yet) are at a physical
address above roughly 2.5GB. If I limit the memory with a mem=2500m
command line, or if
Any idea what might be causing this? Is anyone else seeing this?
--
May 25 11:54:20 discovery kernel: uhci_hcd :00:1d.0: new USB bus
registered, assigned bus number 1 May 25 11:54:20
Pete Zaitcev wrote:
On Wed, 11 Aug 2004 11:42:48 -0400 (EDT) Alan Stern
[EMAIL PROTECTED] wrote:
This patch fixes the error in the UHCI driver found by Stuart Hayes.
It adds the UHCI_PTR_QH bit into the initial entries stored in the
hardware framelist. It's not entirely clear how the
Hello...
I'm seeing a problem where I have an empty CD-ROM drive (or two)
connected
to the system, and, every now and then, I get hangs during boot (or
issues with commands not completing once the system is up).
I've tracked down the issue to a sequence of events similar to the
following:
Alan Stern wrote:
On Wed, 28 Apr 2004 [EMAIL PROTECTED] wrote:
Hello...
I'm seeing a problem where I have an empty CD-ROM drive (or two)
connected to the system, and, every now and then, I get hangs during
boot (or issues with commands not completing once the system is up).
I've
My apologies--my bugzilla account doesn't have the right permissions.
It's not that I'm hiding...
I'm the one who made submitted the patch, and I'm the one who posted
the message about Robert having found an easy way to reproduce the
issue.
--Stuart Hayes
[EMAIL PROTECTED]
-Original
Pete Zaitcev wrote:
On Wed, 28 Apr 2004 15:09:39 -0400 (EDT) Alan Stern
[EMAIL PROTECTED] wrote:
Perhaps I could keep the proc_ioctls from running until the device
isn't being used by usb-storage,
That sounds feasible.
It is feasible, but it runs into difficulties with locking order.
Alan Stern wrote:
On Fri, 30 Apr 2004 [EMAIL PROTECTED] wrote:
So, it looks like several things aren't working right: First, I
would *expect* the GET_DESCRIPTOR command to finish executing on
endpoint 0 even after the bulk in pipe stalls, but this doesn't
appear to be the case. It
looks
Here's the patch (for 2.4) if you're curious.
2cdromfix2.patch
Description: 2cdromfix2.patch
Matthew Dharm wrote:
On Fri, Apr 30, 2004 at 06:32:14PM -0700, Pete Zaitcev wrote:
On Fri, 30 Apr 2004 16:34:48 -0500
[EMAIL PROTECTED] wrote:
Here's the patch (for 2.4) if you're curious.
Do you want me to include all relevant transport types, or you want
to do it yourself?
Or the
David Brownell wrote:
Wouldn't a plain old atomic BUSY bitflag work better? If it's
set, usbcore would reject urbs with -EAGAIN ... from all
contexts, including the many that can't acquire semaphores!
I thought (and I might be confused with other OSes here) that there
was a way to
David Brownell wrote:
Wouldn't a plain old atomic BUSY bitflag work better? If it's set,
usbcore would reject urbs with -EAGAIN ... from all contexts,
including the many that can't acquire semaphores!
Going back a bit--what context were you thinking of that wouldn't be
able to grab the
Hello... While running minor stress on a system, I'm seeing messages
like this quite frequently:
usb 3-1.1: reset full speed USB device using ehci_hcd and address 5
These messages are occurring for all 4 of my low/full speed HID devices
that are connected to a USB2.0 hub (so all are using split
Greg KH wrote:
On Wed, Feb 14, 2007 at 04:49:11PM -0600, [EMAIL PROTECTED] wrote:
Hello... While running minor stress on a system, I'm seeing messages
like this quite frequently:
What kernel version are you using?
2.6.20
It seems to me that ehci-hcd itself should perhaps retry a
Many interrupt transactions to low/full speed devices are getting
QTD_STS_MMF from the EHCI controller because the split transaction isn't
completed in time. This happens when the EHCI controller tries to read
main memory during a CPU frequency change, and it can't get the data
back in time,
David Brownell wrote:
On Tuesday 20 February 2007 12:27 pm, [EMAIL PROTECTED] wrote:
This patch turns off periodic list processing in the EHCI controller
for the duration of processor frequency changes.
Did you test this with any kind of isochronous device active, like a
set of USB
David Brownell wrote:
On Tuesday 20 February 2007 12:27 pm, [EMAIL PROTECTED] wrote:
This patch turns off periodic list processing in the EHCI controller
for the duration of processor frequency changes.
Did you test this with any kind of isochronous device active, like a
set of USB
David Brownell wrote:
On Wednesday 07 March 2007 1:10 pm, [EMAIL PROTECTED] wrote:
OK, I've made an attempt to solve this issue without using such a
large hammer. Instead of shutting off the entire periodic schedule
during cpufreq changes, this patch will just inactivate (using the
I
bit
Sorry for the delayed response on this... I've been working on it and
other stuff at the same time. I found a couple bugs with my last patch,
and have tested quite a bit on both Intel ServerWorks systems. Here's
the new patch (very similar to the previous one I sent), and responses
to your
EHCI controllers that don't cache enough microframes can get MMF errors
when CPU frequency changes occur between the start and completion of
split interrupt transactions, due to delays in reading main memory
(caused by CPU cache snoop delays).
This patch adds a cpufreq notifier to the EHCI
Hayes, Stuart wrote:
EHCI controllers that don't cache enough microframes can get MMF
errors when CPU frequency changes occur between the start and
completion of split interrupt transactions, due to delays in reading
main memory (caused by CPU cache snoop delays).
This patch adds a
I wasn't actually able to reproduce the bug myself, but I guess it is
pretty obvious that I shouldn't have called cpufreq_unregister_notifier
with a spinlock held. I haven't been doing this long enough to know
exactly which kernel this patch should be against, so let me know if
this ins't good.
I don't see how my patch could cause a transfer to return an
actual_length of -4.
If it is my patch causing this problem, I suspect it would be because
the nVidia EHCI controller handles the inactivate bit in an unexpected
(and probably out of spec) way--I was able to test with Broadcom
Intel,
OK, I'm seeing an issue that I'm pretty sure is the same thing... the
keyboard is all kind of goofy (loses keys, repeats keys), then quits
working, then the system locks up, only when my patch is enabled and I'm
getting (faked) cpu frequency transitions. It definitely appears to be
some
I'm working on it, Pete. I've got a system with an nVidia EHCI
controller (unfortunately it's an Intel box, not AMD, since the failing
systems are AMD), and I'm working to reproduce the issue. I acknowledge
that this issue is probably caused by this patch.
I suspect that what's going on is
Greg KH wrote:
On Tue, Jul 31, 2007 at 03:06:07PM -0600, Grant Likely wrote:
I've observed instability on my Macbook c2d with the Linus' latest
tree. Symptom is that USB devices start behaving badly and the
kernel seems to be registering incorrect HID events; (ie. moving the
mouse causes odd
This patch fixes a bug with the cpu frequency change notifier and nVidia
EHCI controllers. The nVidia controllers write the transfer overlay
back to the qtd when they see the inactivate bit set in the qh, which
clears the active bit in qtd-hw_token. When the qh was reactivated,
the active bit in
Greg KH wrote:
On Tue, Jul 31, 2007 at 04:00:15PM -0700, Pete Zaitcev wrote:
On Tue, 31 Jul 2007 17:00:04 -0500, [EMAIL PROTECTED] wrote:
+ list_for_each_safe (entry, tmp, qh-qtd_list) {
+ qtd = list_entry (entry, struct ehci_qtd, qtd_list);
+ if (cpu_to_le32
Jiri Kosina wrote:
On Fri, 10 Aug 2007, Daniel Exner wrote:
After some serious hangs with 2.6.23-rc2 I did some bisects and this
was the result:
196705c9bbc03540429b0f7cf9ee35c2f928a534 is first bad commit commit
196705c9bbc03540429b0f7cf9ee35c2f928a534
Author: [EMAIL PROTECTED] [EMAIL
Daniel Exner wrote:
Jiri Kosina wrote:
On Fri, 10 Aug 2007, Daniel Exner wrote:
Please CC me, as I'm currently not subscribed to this list, thx.
Please also don't forget to CC relevant people/lists when reporting
bugs, thanks.
Guess its ok, now? Thanks anyway :)
After some serious hangs
38 matches
Mail list logo
