On Tue, 30 Jan 2007, Dominik Brodowski wrote:
There may not be anything we can do about a rogue BIOS, other than to
avoid suspending the controller at all.
Just to make sure, try this: In ehci-hub.c, near the end of
ehci_bus_suspend(), print out the value returned by ehci_halt().
On Mon, 29 Jan 2007, Dominik Brodowski wrote:
Allright, done some more debugging:
- using my patch with your fix, devices which are already plugged in when
the STS_FLR exception occurs continue to work
- however, new devices which are plugged in, or devices which are removed,
(unless the
Hi,
On Tue, Jan 30, 2007 at 10:50:19AM -0500, Alan Stern wrote:
On Mon, 29 Jan 2007, Dominik Brodowski wrote:
Allright, done some more debugging:
- using my patch with your fix, devices which are already plugged in when
the STS_FLR exception occurs continue to work
- however, new
On Tue, 30 Jan 2007, Dominik Brodowski wrote:
Try running this test again, with CONFIG_USB_DEBUG turned on. After
plugging in a new device, make a copy of
/sys/class/usb_host/usb_host1/registers
and post it. Ditto for unplugging an existing device.
Hi,
On Tue, Jan 30, 2007 at 03:31:24PM -0500, Alan Stern wrote:
next test:
http://userweb.kernel.org/~brodo/pre-insert
= added device 2
http://userweb.kernel.org/~brodo/post-insert
These were all done with the controller supposedly suspended, right?
Yes.
But
they all show that it
On Sun, 28 Jan 2007, Dominik Brodowski wrote:
You could try another test: Let the IRQ be disabled, and then rmmod
ehci-hcd and modprobe it back. Perhaps then rmmod usb-storage to force
another suspend, perhaps not. Anyway, see what happens to intr_enable.
You can always force
Hi,
On Mon, Jan 29, 2007 at 10:41:58AM -0500, Alan Stern wrote:
On Sun, 28 Jan 2007, Dominik Brodowski wrote:
You could try another test: Let the IRQ be disabled, and then rmmod
ehci-hcd and modprobe it back. Perhaps then rmmod usb-storage to force
another suspend, perhaps not.
Hi,
Sorry for not getting back to you earlier -- many things kept me distracted:
On Tue, Dec 12, 2006 at 04:08:39PM -0500, Alan Stern wrote:
On Tue, 12 Dec 2006, Dominik Brodowski wrote:
On the other hand, your latest log suggests that the STS_FLR bit gets set
during the
On Mon, Dec 11, 2006 at 11:11:08PM -0500, Alan Stern wrote:
On Mon, 11 Dec 2006, Dominik Brodowski wrote:
Yes, that's right. In fact the controller isn't supposed to send an IRQ
when only those two bits are on. I suspect the STS_FLR bit is somehow
getting set in the intr_enable
On Tue, 12 Dec 2006, Dominik Brodowski wrote:
I'll have to study the code some more. Which kernel did you say you are
using?
Latest Linus' git. Today's snd-usb-audio test was with head
4259cb25d436a79bf6b07d8075423573567c211d (plus an completely unrelated
pcmcia patch, but the related
On Tue, Dec 12, 2006 at 11:27:42AM -0500, Alan Stern wrote:
from today confirms it, and I also ran the pre-autosuspend kernel ( its head
is 8c03356a559ced6fa78931f498193f776d67e445 ) to re-check that it is an
issue
which appeared with the autosuspend patch.
Okay, I was fooled by the
On Tue, 12 Dec 2006, Dominik Brodowski wrote:
On the other hand, your latest log suggests that the STS_FLR bit gets set
during the ehci_bus_suspend() routine, not the resume routine. So it will
be best to check at the beginning and end of both routines.
Unfortunately, it doesn't get
On Sat, Dec 09, 2006 at 04:03:48PM -0500, Alan Stern wrote:
but that did not help:
http://userweb.kernel.org/~brodo/dmesg-autosuspend.txt
The offending IRQ status seems to be 2008; as INTR_MASK does neither
include STS_FLR nor STS_RECL (if I got the math correctly), IRQ_NONE is
On Mon, 11 Dec 2006, Dominik Brodowski wrote:
Yes, that's right. In fact the controller isn't supposed to send an IRQ
when only those two bits are on. I suspect the STS_FLR bit is somehow
getting set in the intr_enable register (don't ask me how -- there doesn't
seem to be any code that
On Fri, 8 Dec 2006, Dominik Brodowski wrote:
Hi,
On Fri, Dec 08, 2006 at 11:00:15AM -0500, Alan Stern wrote:
Okay. Here's a patch that will print out some information for each of the
first 100 interrupts received by ehci-hcd. Block yenta-socket from being
loaded, so as to reduce the
On Wed, 6 Dec 2006, Dominik Brodowski wrote:
Now I tested this a bit further... and strangely, if I modprobe the USB
modules somewhen later, it is no problem at all. Running many many
possible
combinations of modprobe'ing yenta_socket, ehci_hcd, uhci_hcd and other
modules loaded
On Thu, 7 Dec 2006, Dominik Brodowski wrote:
Or perhaps not. I can't think of any reason why the EHCI controller
should have generated the unhandled IRQ, and it seems very suspicious that
it occurred just as the cs port probing was going on. So maybe
yenta_socket is at fault, and the
Hi,
On Fri, Dec 08, 2006 at 11:00:15AM -0500, Alan Stern wrote:
Okay. Here's a patch that will print out some information for each of the
first 100 interrupts received by ehci-hcd. Block yenta-socket from being
loaded, so as to reduce the number of extraneous interrupts, and see what
you
Hi,
On Thu, Dec 07, 2006 at 05:29:32PM -0500, Alan Stern wrote:
Any ideas?
No doubt it's caused by the peculiar timing of events at startup. Lots of
things are happening all at once, and the computer can't keep up with
everything.
For instance, your log shows the Matrox HD was
Hi,
On Tue, Dec 05, 2006 at 04:39:34PM -0500, Alan Stern wrote:
On Tue, Dec 05, 2006 at 07:19:01AM -0500, Dominik Brodowski wrote:
Hi,
git bisect proved that the patch
commit 40f122f343797d02390c5a157372cac0c5b50bb7
Author: Alan Stern [EMAIL PROTECTED]
Date: Thu Nov 9
Hi,
git bisect proved that the patch
commit 40f122f343797d02390c5a157372cac0c5b50bb7
Author: Alan Stern [EMAIL PROTECTED]
Date: Thu Nov 9 14:44:33 2006 -0500
USB: Add autosuspend support to the hub driver
This patch (as742b) adds autosuspend/autoresume support to the USB hub
Hi,
On Tue, Dec 05, 2006 at 07:19:01AM -0500, Dominik Brodowski wrote:
Hi,
git bisect proved that the patch
commit 40f122f343797d02390c5a157372cac0c5b50bb7
Author: Alan Stern [EMAIL PROTECTED]
Date: Thu Nov 9 14:44:33 2006 -0500
USB: Add autosuspend support to the hub driver
On Tue, 5 Dec 2006, Dominik Brodowski wrote:
Hi,
On Tue, Dec 05, 2006 at 07:19:01AM -0500, Dominik Brodowski wrote:
Hi,
git bisect proved that the patch
commit 40f122f343797d02390c5a157372cac0c5b50bb7
Author: Alan Stern [EMAIL PROTECTED]
Date: Thu Nov 9 14:44:33 2006 -0500
23 matches
Mail list logo
