On Sun, 9 Jan 2005, David Brownell wrote:
> > After all, you say everything works if ehci-hcd isn't loaded
> > beforehand.
>
> Or UHCI. It's only the combination that's trouble.
Is it? What happens if ehci-hcd isn't loaded and Oliver unplugs the
mouse while the system is asleep?
Alan Ste
Hi!
> > > > boot
> > > > swsusp suspend
> > > > SWSUSP MESSAGES AFTER IMAGE WAS WRITTEN
> > > > (RE)BOOT
> > > > SWSUSP MESSAGES SWITCHING TO OLD IMAGE
> > > > swsusp resume
> > > >
> > > > I've certainly found cases where the the "MISSING LOG DATA" had some
> > > > inform
On Sunday 09 January 2005 12:42 pm, Alan Stern wrote:
> On Sun, 9 Jan 2005, Oliver Neukum wrote:
>
> >
> > NO. I am sorry about that misconception, but ehci is modular.
> > Uhci is static.
>
> Oh. It's possible that this has something to do with it, but I can't
> think what.
It'd still be be
On Sun, 9 Jan 2005, Oliver Neukum wrote:
> I am working on netconsole. It is surprisingly hard. Is there anything
> obvious to miss?
I don't know. Maybe just messages about URBs for 1-0:1.0 failing with
various error codes...
If you have a null-modem cable, a serial console would be easier to s
Am Sonntag, 9. Januar 2005 18:20 schrieb Alan Stern:
> On Sat, 8 Jan 2005, Oliver Neukum wrote:
>
> > > boot
> > > swsusp suspend
> > > SWSUSP MESSAGES AFTER IMAGE WAS WRITTEN
> > > (RE)BOOT
> > > SWSUSP MESSAGES SWITCHING TO OLD IMAGE
> > > swsusp resume
> > >
> > > I've
Am Sonntag, 9. Januar 2005 18:20 schrieb Alan Stern:
> On Sat, 8 Jan 2005, Oliver Neukum wrote:
>
> > > boot
> > > swsusp suspend
> > > SWSUSP MESSAGES AFTER IMAGE WAS WRITTEN
> > > (RE)BOOT
> > > SWSUSP MESSAGES SWITCHING TO OLD IMAGE
> > > swsusp resume
> > >
> > > I've certainly fo
On Sat, 8 Jan 2005, Oliver Neukum wrote:
> > boot
> > swsusp suspend
> > SWSUSP MESSAGES AFTER IMAGE WAS WRITTEN
> > (RE)BOOT
> > SWSUSP MESSAGES SWITCHING TO OLD IMAGE
> > swsusp resume
> >
> > I've certainly found cases where the the "MISSING LOG DATA" had some
> > infor
On Sun, 9 Jan 2005, Nigel Cunningham wrote:
> Hi guys.
>
> I've just joined the list in the hope that I might be able to provide
> some help in getting USB suspend/resume more reliable, or at least get
> better understanding regarding what the issues are.
Thanks for helping.
> > You can't. You o
Am Samstag, 8. Januar 2005 22:36 schrieb David Brownell:
> On Saturday 08 January 2005 10:51 am, Oliver Neukum wrote:
> > Upon further reflection, in a statically compiled driver you know
> > you are taking over from yourself, already at compile time.
>
> Not true with the default swsusp "shutdown
Am Samstag, 8. Januar 2005 22:45 schrieb David Brownell:
> On Saturday 08 January 2005 12:09 pm, Alan Stern wrote:
>
> > Time to go look at those logs again...
>
> Another complication here is that a serial console will give a much more
> complete set of logs than "dmesg" after swsusp resumes ..
Hi guys.
I've just joined the list in the hope that I might be able to provide
some help in getting USB suspend/resume more reliable, or at least get
better understanding regarding what the issues are.
On Sun, 2005-01-09 at 05:46, Oliver Neukum wrote:
> Am Samstag, 8. Januar 2005 18:52 schrieb Al
On Saturday 08 January 2005 12:09 pm, Alan Stern wrote:
> Time to go look at those logs again...
Another complication here is that a serial console will give a much more
complete set of logs than "dmesg" after swsusp resumes ... below, I
summarize log contents, with CAPS SHOWING WHAT DMESG WILL
On Saturday 08 January 2005 10:51 am, Oliver Neukum wrote:
> Upon further reflection, in a statically compiled driver you know
> you are taking over from yourself, already at compile time.
Not true with the default swsusp "shutdown" method. In that case
you're quite possibly taking over from BIOS
On Sat, 8 Jan 2005, Oliver Neukum wrote:
> Am Samstag, 8. Januar 2005 18:52 schrieb Alan Stern:
>
> > Secondly, the startup kernel gets control of the machine. If the HCD is
> > compiled in, then it will grab the HC and reset it. (I would like to know
> > how to tell whether that step can be av
Am Samstag, 8. Januar 2005 18:52 schrieb Alan Stern:
> Thirdly the memory image is restored and the driver in the image is
> running again. Now it may have to take control of the HC from the BIOS,
> from nobody (but after the HC may or may not have been reset), from its
> duplicate in the startup
Am Samstag, 8. Januar 2005 18:56 schrieb Alan Stern:
> On Sat, 8 Jan 2005, Oliver Neukum wrote:
>
> > Am Samstag, 8. Januar 2005 05:48 schrieb Alan Stern:
> > > Oliver, what happens if you run with CONFIG_USB_SUSPEND not set and apply
> > > the patch I wrote for Paul Ionescu in
> > >
> > > http:/
Am Samstag, 8. Januar 2005 18:52 schrieb Alan Stern:
> Secondly, the startup kernel gets control of the machine. If the HCD is
> compiled in, then it will grab the HC and reset it. (I would like to know
> how to tell whether that step can be avoided. There's a further
You can't. You only know
On Sat, 8 Jan 2005, Oliver Neukum wrote:
> Am Samstag, 8. Januar 2005 05:48 schrieb Alan Stern:
> > Oliver, what happens if you run with CONFIG_USB_SUSPEND not set and apply
> > the patch I wrote for Paul Ionescu in
> >
> > http://marc.theaimsgroup.com/?l=linux-usb-devel&m=110503079717138&w=2
>
On Sat, 8 Jan 2005, Oliver Neukum wrote:
> But I don't understand your line of reasoning. You are not taking
> over from the BIOS. You are taking over from yourself as the kernel
> has already initialised all devices once the image is read back.
It's a very tricky matter, and it depends on whethe
Am Samstag, 8. Januar 2005 05:48 schrieb Alan Stern:
> Oliver, what happens if you run with CONFIG_USB_SUSPEND not set and apply
> the patch I wrote for Paul Ionescu in
>
> http://marc.theaimsgroup.com/?l=linux-usb-devel&m=110503079717138&w=2
No change.
Jan 8 11:49:39 macbeth kernel: Stopping t
Am Samstag, 8. Januar 2005 05:48 schrieb Alan Stern:
> Oliver, what happens if you run with CONFIG_USB_SUSPEND not set and apply
> the patch I wrote for Paul Ionescu in
>
> http://marc.theaimsgroup.com/?l=linux-usb-devel&m=110503079717138&w=2
I'll apply it as soon as I am home.
But I don't unders
On Fri, 7 Jan 2005, David Brownell wrote:
> > > Given that the UHCI LEGSUP register changed (a BIOS thing), I think
> > > the first thing to try is making the UHCI driver get the port back
> > > from the BIOS. It's very possible that changing that UHCI register
> > > will automatically restore th
On Friday 07 January 2005 2:52 pm, Alan Stern wrote:
> On Fri, 7 Jan 2005, David Brownell wrote:
>
> > Given that the UHCI LEGSUP register changed (a BIOS thing), I think
> > the first thing to try is making the UHCI driver get the port back
> > from the BIOS. It's very possible that changing tha
On Fri, 7 Jan 2005, David Brownell wrote:
> Given that the UHCI LEGSUP register changed (a BIOS thing), I think
> the first thing to try is making the UHCI driver get the port back
> from the BIOS. It's very possible that changing that UHCI register
> will automatically restore the correct PORT_O
On Friday 07 January 2005 7:30 am, Alan Stern wrote:
> On Thu, 6 Jan 2005, Oliver Neukum wrote:
>
> > Jan 6 23:42:53 macbeth kernel: ehci_hcd :00:1d.7: resume root hub
> > Jan 6 23:42:53 macbeth kernel: Port: 5, Status: 1000
> > Jan 6 23:42:53 macbeth kernel: Port: 4, Status: 1000
>
On Thu, 6 Jan 2005, Oliver Neukum wrote:
> > I'm just suggesting that in ehci-hub.c, you add code to ehci_hub_suspend
> > to print the values of port and t1 inside the loop. Similarly, in
> > ehci_hub_resume print the values of i and temp in the two loops.
>
> Here we go:
> Jan 6 23:42:52 ma
Am Donnerstag, 6. Januar 2005 23:27 schrieb Alan Stern:
> Do you have Legacy USB support enabled in your BIOS?
Without legacy support:
Jan 7 00:35:15 macbeth kernel: Stopping tasks:
===|
Jan 7 00:35:15 macbeth kernel: Freeing memory...
^H-^H\^H|^H/^H-^H\^
Am Donnerstag, 6. Januar 2005 22:01 schrieb Alan Stern:
> On Thu, 6 Jan 2005, Oliver Neukum wrote:
>
> > Am Donnerstag, 6. Januar 2005 20:11 schrieb Alan Stern:
> > > It's also possible that the flip-flop is changed during the suspend
> > > operation rather than the resume operation. ÂPerhaps Oliv
On Thu, 6 Jan 2005, David Brownell wrote:
> On Thursday 06 January 2005 1:01 pm, Alan Stern wrote:
> >
> > If the power was shut off entirely, upon resume the controller would have
> > seen a connect change event. No such event shows up in the system logs
> > you posted with ehci-hcd unloaded.
On Thu, 6 Jan 2005, David Brownell wrote:
> This suggests that the problem is in UHCI. A key difference
> between having /sys/power/disk be "platform" vs "shutdown"
> is basically that BIOS treats the shutdown path as a reboot,
> while the "platform" path is a real resume.
>
> Reboot probably me
> It's worth checking this out. Oliver, after resuming with both uhci-hcd
> and ehci-hcd loaded, try doing lspci -xxx for the UHCI controller. The
> two bytes at offset 0xc0 are of interest.
>
> Do you have Legacy USB support enabled in your BIOS?
Legacy support was on.
I've swit
On Thursday 06 January 2005 1:49 pm, Oliver Neukum wrote:
> Am Donnerstag, 6. Januar 2005 22:31 schrieb David Brownell:
> > But an honest-to-gosh resume acts different. The BIOS
> > won't touch the controllers there.
> >
> > Now, the HCD resume() method has to handle at least
> > three different
On Thursday 06 January 2005 1:54 pm, Pavel Machek wrote:
> > Does swsusp behave correctly in the "shutdown" case?
> > That's roughly the difference between an ACPI S4bios
> > and an ACPI S4 suspend sequence. Both need testing.
>
> "platform" is swsusp followed by S4 powerdown.
>
> S4bios is "fir
Hi!
> > In any case this isn't under our control.
> > Devices are resumed in the same order they were detected initially. I
> > think the only way to solve this problem is to find a workaround for EHCI
> > controllers that act weird when they resume.
>
> The problem could well be in UHCI inst
Am Donnerstag, 6. Januar 2005 22:31 schrieb David Brownell:
> But an honest-to-gosh resume acts different. The BIOS
> won't touch the controllers there.
>
> Now, the HCD resume() method has to handle at least
> three different states:
>
> - Honest-to-gosh resume (which worked in this case)
>
Am Donnerstag, 6. Januar 2005 22:01 schrieb Alan Stern:
> On Thu, 6 Jan 2005, Oliver Neukum wrote:
>
> > Am Donnerstag, 6. Januar 2005 20:11 schrieb Alan Stern:
> > > It's also possible that the flip-flop is changed during the suspend
> > > operation rather than the resume operation. Perhaps Oliv
On Thursday 06 January 2005 11:40 am, Oliver Neukum wrote:
> Am Donnerstag, 6. Januar 2005 18:19 schrieb David Brownell:
> > The problem could well be in UHCI instead, or BIOS.
> > There are at least several dozen different configurations
> > to test here, after all ... ;)
>
> I am developing rebo
On Thu, 6 Jan 2005, Oliver Neukum wrote:
> Am Donnerstag, 6. Januar 2005 20:11 schrieb Alan Stern:
> > It's also possible that the flip-flop is changed during the suspend
> > operation rather than the resume operation. Perhaps Oliver can add some
> > debugging lines to print the values of the reg
On Thursday 06 January 2005 11:11 am, Alan Stern wrote:
> > The only thing that a quick scan of the ehci resume
> > code suggested might be a problem is the line of code
> > in ehci-hub.c::ehci_resume() that checks for whether
> > the PORT_SUSPEND bit is set. Maybe that should be
> > checking for
On Thursday 06 January 2005 1:01 pm, Alan Stern wrote:
>
> If the power was shut off entirely, upon resume the controller would have
> seen a connect change event. No such event shows up in the system logs
> you posted with ehci-hcd unloaded. But it does show up in the logs with
> ehci-hcd load
Am Donnerstag, 6. Januar 2005 20:11 schrieb Alan Stern:
> It's also possible that the flip-flop is changed during the suspend
> operation rather than the resume operation. Perhaps Oliver can add some
> debugging lines to print the values of the regs->port_status[] entries in
> those three loops (o
Am Donnerstag, 6. Januar 2005 18:19 schrieb David Brownell:
> The problem could well be in UHCI instead, or BIOS.
> There are at least several dozen different configurations
> to test here, after all ... ;)
I am developing reboot psychosis ;-)
Anyway, using platform makes a difference. The box do
On Thu, 6 Jan 2005, David Brownell wrote:
> > In any case this isn't under our control.
> > Devices are resumed in the same order they were detected initially. I
> > think the only way to solve this problem is to find a workaround for EHCI
> > controllers that act weird when they resume.
>
>
Am Donnerstag, 6. Januar 2005 18:19 schrieb David Brownell:
> We saw the /proc/debug/uhci/:00:1d:0 output; what
> does the corresponding /sys/class/usb_host/.../registers
> information (for EHCI) show, before and after suspend?
After:
bus pci, device :00:1d.7 (driver 26 Oct 2004)
EHCI 1.00
Am Donnerstag, 6. Januar 2005 18:19 schrieb David Brownell:
> On Thursday 06 January 2005 6:54 am, Alan Stern wrote:
> > On Wed, 5 Jan 2005, David Brownell wrote:
> >
> > > > > Is EHCI being resumed before UHCI -- or afterwards?
> > > >
> > > > EHCI was resumed after UHCI.
> > >
> > > I suspect
On Thursday 06 January 2005 6:54 am, Alan Stern wrote:
> On Wed, 5 Jan 2005, David Brownell wrote:
>
> > > > Is EHCI being resumed before UHCI -- or afterwards?
> > >
> > > EHCI was resumed after UHCI.
> >
> > I suspect it'd work better the other way around.
>
> Maybe it would, maybe not.
I'd
On Wed, 5 Jan 2005, David Brownell wrote:
> > > Is EHCI being resumed before UHCI -- or afterwards?
> >
> > EHCI was resumed after UHCI.
>
> I suspect it'd work better the other way around.
Maybe it would, maybe not. In any case this isn't under our control.
Devices are resumed in the same o
On Wednesday 05 January 2005 2:26 pm, Alan Stern wrote:
> On Wed, 5 Jan 2005, David Brownell wrote:
>
> > On Wednesday 05 January 2005 1:33 pm, Alan Stern wrote:
> >
> > > David, any idea on what could be messing up the flip-flop setting?
> >
> > Is EHCI being resumed before UHCI -- or afterward
On Wed, 5 Jan 2005, David Brownell wrote:
> On Wednesday 05 January 2005 1:33 pm, Alan Stern wrote:
>
> > David, any idea on what could be messing up the flip-flop setting?
>
> Is EHCI being resumed before UHCI -- or afterwards?
EHCI was resumed after UHCI.
Alan Stern
--
On Wednesday 05 January 2005 1:33 pm, Alan Stern wrote:
> David, any idea on what could be messing up the flip-flop setting?
Is EHCI being resumed before UHCI -- or afterwards?
---
The SF.Net email is sponsored by: Beat the post-holiday blues
Am Mittwoch, 5. Januar 2005 22:33 schrieb Alan Stern:
> That looks good to me. And the mouse was still working...?
Yes. To summarize:
EHCI+UHCI: usb totally crashed
EHCI+UHCI+SUSPEND: needs unplug/plug cycle
UHCI only: works
UHCI + SUSPEND: works
In addition, EHCI has an additional strange eff
Am Mittwoch, 5. Januar 2005 15:55 schrieb Alan Stern:
> On Tue, 4 Jan 2005, Oliver Neukum wrote:
>
> > Right on. A kernel without ehci wakes up with a working mouse.
> > Here's the log:
>
> > Do you want it with CONFIG_USB_SUSPEND?
>
> That would be a good thing to try. According to your first
On Wed, 5 Jan 2005, Oliver Neukum wrote:
> Here's the log of UHCI only, CONFIG_USB_SUSPEND enabled:
> Jan 5 21:54:14 macbeth kernel: usb 1-1: RESUME
> Jan 5 21:54:14 macbeth kernel: uhci_hcd :00:1d.0: port 1 portsc 0195,01
> Jan 5 21:54:14 macbeth kernel: usb 1-1: usb resume
> Jan 5 21:54
On Tue, 4 Jan 2005, Oliver Neukum wrote:
> Right on. A kernel without ehci wakes up with a working mouse.
> Here's the log:
> Do you want it with CONFIG_USB_SUSPEND?
That would be a good thing to try. According to your first debugging
log, sometime during the suspend/resume procedure the mouse
Am Dienstag, 4. Januar 2005 22:24 schrieb Alan Stern:
> On Tue, 4 Jan 2005, Oliver Neukum wrote:
>
> > Am Dienstag, 4. Januar 2005 21:03 schrieb David Brownell:
> > > Does it work better if you enable CONFIG_USB_SUSPEND?
> >
> > Without it, the effect is catastrophic. USB ceases to work and
> > w
On Tue, 4 Jan 2005, Oliver Neukum wrote:
> Am Dienstag, 4. Januar 2005 21:03 schrieb David Brownell:
> > Does it work better if you enable CONFIG_USB_SUSPEND?
>
> Without it, the effect is catastrophic. USB ceases to work and
> will not be cured by a warm reboot. I had to cycle the power.
I have
Am Dienstag, 4. Januar 2005 21:03 schrieb David Brownell:
> Does it work better if you enable CONFIG_USB_SUSPEND?
Without it, the effect is catastrophic. USB ceases to work and
will not be cured by a warm reboot. I had to cycle the power.
The log was:
Jan 4 21:33:49 macbeth kernel: Stopping task
On Tuesday 04 January 2005 12:14 pm, Oliver Neukum wrote:
> Am Dienstag, 4. Januar 2005 21:03 schrieb David Brownell:
> > Does it work better if you enable CONFIG_USB_SUSPEND?
>
> It is enabled. I'll try disabled.
Then I suspect the HID resume() method never got called for
some reason.
---
Am Dienstag, 4. Januar 2005 21:03 schrieb David Brownell:
> Does it work better if you enable CONFIG_USB_SUSPEND?
It is enabled. I'll try disabled.
Regards
Oliver
---
The SF.Net email is sponsored by: Beat the post-holi
Does it work better if you enable CONFIG_USB_SUSPEND?
- Dave
---
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almosthttp://www.th
Am Dienstag, 4. Januar 2005 16:02 schrieb Alan Stern:
> On Mon, 3 Jan 2005, Oliver Neukum wrote:
>
> > Hi,
> >
> > with 2.6.10 (i386/UP/UHCI)
> > :00:1d.0 USB Controller: Intel Corp. 82801DB USB (Hub #1) (rev 03)
> > :00:1d.1 USB Controller: Intel Corp. 82801DB USB (Hub #2) (rev 03)
> > 0
On Mon, 3 Jan 2005, Oliver Neukum wrote:
> Hi,
>
> with 2.6.10 (i386/UP/UHCI)
> :00:1d.0 USB Controller: Intel Corp. 82801DB USB (Hub #1) (rev 03)
> :00:1d.1 USB Controller: Intel Corp. 82801DB USB (Hub #2) (rev 03)
> :00:1d.2 USB Controller: Intel Corp. 82801DB USB (Hub #3) (rev 03)
Hi,
with 2.6.10 (i386/UP/UHCI)
:00:1d.0 USB Controller: Intel Corp. 82801DB USB (Hub #1) (rev 03)
:00:1d.1 USB Controller: Intel Corp. 82801DB USB (Hub #2) (rev 03)
:00:1d.2 USB Controller: Intel Corp. 82801DB USB (Hub #3) (rev 03)
:00:1d.7 USB Controller: Intel Corp. 82801DB USB2
63 matches
Mail list logo
