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
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 Mes
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
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
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 yours
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
>> w
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 gra
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
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, pres
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 U
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 U
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
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 que
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 driver
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
Sorry about that. Would it be helpful if I verified that and sent it in
signed off?
Thanks
Stuart
-Original Message-
From: Andrew Morton [mailto:[EMAIL PROTECTED]
Sent: Friday, May 25, 2007 5:00 PM
To: Greg KH
Cc: Mattia Dongili; Linux Kernel Mailing List; Hayes, Stuart; David
Brownell
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 incompati
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 that
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 ca
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"
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_
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]
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 so
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 t
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, af
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 PM
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 t
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: R
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
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 di
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 ho
> 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
39 matches
Mail list logo
