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_h
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 s
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.
>
> http://user
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
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
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, perhap
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,
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 ehci_bu
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'
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
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 r
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_en
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 co
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
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 re
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
>
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
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
> > > mo
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]>
>
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:
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
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
dri
23 matches
Mail list logo
