On Thu, 4 Sep 2003, reinhard schwab wrote:
> hi,
> i searched the kernel changelogs for changes in usb-storage.
> i have problems accessing an external usb hard drive.
> if i copy a lot of files to it, linux will crash after 100 mb or more.
> the kernel version is 2.4.18, not the latest, i know.
>
Hi!
> > Is not disk spin-down policy, and thus belonging to userspace? Having
> > daemon poll for inactivity of hubs once every 5 minutes and sending
> > them to sleep should not hurt, too...
> > Pavel
>
> Taking precedents into account i
Hi!
> > Can you mail me a patch? [Where does PCI do its "second round"? From a
> > quick look I did not see that.]
>
> I just comment out the init code in drivers/pci/power.c
Hmm, in such case whole power.c file can be
killed. pci_register_driver() should take care of registering proper
callback
Hello again,
> I will try S4 lateron.
After resuming from S4 uhci_hcd works fine (in opposition to S3 under exactly the same
circumstances).
USB support was completely compiled into kernel and not as modules (therefore no
unloading before suspend was done).
Interesting:
uhci_hcd wakes up agai
On Fri, 2003-08-01 at 00:03, Pavel Machek wrote:
> Can you mail me a patch? [Where does PCI do its "second round"? From a
> quick look I did not see that.]
I just comment out the init code in drivers/pci/power.c
Ben.
---
This SF.Net email sp
> Is not disk spin-down policy, and thus belonging to userspace? Having
> daemon poll for inactivity of hubs once every 5 minutes and sending
> them to sleep should not hurt, too...
> Pavel
Taking precedents into account it is the ker
Hi!
> > The pm_*() is how a handful of sound drivers and other random
> > stuff register themselves -- and how PCI does it.
> >
> > I'd sure have expected PCI to only use the driver model stuff,
> > and I'll hope all those users will all be phased out by the
> > time that 2.6 gets near the end of
> I suspect that USB should do some non-global PM stuff too.
> Hub ports can be suspended when the devices connected to them
> are idle for long enough ... that's not something I'd expect
> system-wide PM policies to address.
Indeed, this is not addressed, though it may sense to have
a way in the
Hi!
> > > - APM uses the pm_*() calls for a vetoable check,
> > >never issues SAVE_STATE, then goes POWER_DOWN.
> >
> > I remember the reason... SAVE_STATE expects user processes to be
> > stopped, which is not the case in APM. Perhaps that is easy to fix
> > these days...
>
> No ! You may
Benjamin Herrenschmidt wrote:
You should look at Patrick Mochel's stuff that shall be getting in
the official tree this month hopefully. It does that (among others)
OK, thanks for the update. It was puzzling to see this stuff
in such a state ... I've got a few patches for USB PM that are
worth put
Hi!
> > I suspect that USB should do some non-global PM stuff too.
> > Hub ports can be suspended when the devices connected to them
> > are idle for long enough ... that's not something I'd expect
> > system-wide PM policies to address.
>
> Indeed, this is not addressed, though it may sense to h
> For what kind of I/O? I do not see a reason for disk to veto
> suspend. CD-burner might want to do that, but it still would be bad
> idea... (Running on battery, battery goes low, and you destroy your CD
> *and* your filesystem.
Well... that's userland policy. You can have a notion of "severity
> If it's in the middle of any kind of write, suspending would
> seem to be unwise. Say, writing to a swap partition...
No, you wait for pending requests to complete and keep further
ones in the queue. I will probably write the proper infrastructure
for SCSI hosts later this month, it has to be
On Thu, 2003-07-31 at 15:37, David Brownell wrote:
> Pavel Machek wrote:
>
> >>All of which is a roundabout way of adding to what I
> >>said: the PM infrastructure USB will need to rely on
> >>seems like it needs polishing yet! :)
> >
> >
> > Do you need vetoing? Otherwise it should be ready,
> Well, partially; but it's not used consistently. Could you
> (or someone) explain what the plan is? I see:
>
> - Three separate x86 PM "initiators": APM, ACPI, swsusp.
> (Plus ones for ARM and MIPS.)
You should look at Patrick Mochel's stuff that shall be getting in
the official tree t
On Thu, 2003-07-31 at 15:23, David Brownell wrote:
> Pavel Machek wrote:
> > Hi!
> >
> >
> >> - APM uses the pm_*() calls for a vetoable check,
> >> never issues SAVE_STATE, then goes POWER_DOWN.
> >
> >
> > I remember the reason... SAVE_STATE expects user processes to be
> > stopped, which i
On Thu, 2003-07-31 at 11:49, Pavel Machek wrote:
> Hi!
>
> > - APM uses the pm_*() calls for a vetoable check,
> >never issues SAVE_STATE, then goes POWER_DOWN.
>
> I remember the reason... SAVE_STATE expects user processes to be
> stopped, which is not the case in APM. Perhaps that is easy
Hi!
> >>USB drivers don't talk suspend/resume yet, so they
> >>won't notice missing features there. Regressions
> >>are a different story though.
> >>
> >>But I can imagine that usb-storage (or is that SCSI?)
> >>might want to veto suspending devices that are being
> >>used for some kinds of i/o.
Pavel Machek wrote:
USB drivers don't talk suspend/resume yet, so they
won't notice missing features there. Regressions
are a different story though.
But I can imagine that usb-storage (or is that SCSI?)
might want to veto suspending devices that are being
used for some kinds of i/o. Eventually
Hi!
> >>- APM uses the pm_*() calls for a vetoable check,
> >> never issues SAVE_STATE, then goes POWER_DOWN.
> >
> >
> >I remember the reason... SAVE_STATE expects user processes to be
> >stopped, which is not the case in APM. Perhaps that is easy to fix
> >these days...
>
> That SAVE_STATE res
Hi!
> >>The "initiators" all talk to _both_ infrastructures, but they
> >>don't talk to the driver model stuff in the same way. For
> >>example, on suspend:
> >Where does acpi call pm_*()? It seems like it does not and it seems
> >like a bug to me.
>
> Doesn't; it showed up in a 'grep' that I s
Hi!
> >>All of which is a roundabout way of adding to what I
> >>said: the PM infrastructure USB will need to rely on
> >>seems like it needs polishing yet! :)
> >
> >
> >Do you need vetoing? Otherwise it should be ready, except for APM.
>
> USB drivers don't talk suspend/resume yet, so they
>
Pavel Machek wrote:
The "initiators" all talk to _both_ infrastructures, but they
don't talk to the driver model stuff in the same way. For
example, on suspend:
...
Where does acpi call pm_*()? It seems like it does not and it seems
like a bug to me.
Doesn't; it showed up in a 'grep' that I should
Pavel Machek wrote:
Hi!
- APM uses the pm_*() calls for a vetoable check,
never issues SAVE_STATE, then goes POWER_DOWN.
I remember the reason... SAVE_STATE expects user processes to be
stopped, which is not the case in APM. Perhaps that is easy to fix
these days...
Pavel Machek wrote:
All of which is a roundabout way of adding to what I
said: the PM infrastructure USB will need to rely on
seems like it needs polishing yet! :)
Do you need vetoing? Otherwise it should be ready, except for APM.
USB drivers don't talk suspend/resume yet, so they
won't notice
Hi!
> Well, partially; but it's not used consistently. Could you
> (or someone) explain what the plan is? I see:
>
> - Three separate x86 PM "initiators": APM, ACPI, swsusp.
>(Plus ones for ARM and MIPS.)
>
> - Two driver registration infrastructures, the driver model
>stuff and the
Hi!
> - APM uses the pm_*() calls for a vetoable check,
>never issues SAVE_STATE, then goes POWER_DOWN.
I remember the reason... SAVE_STATE expects user processes to be
stopped, which is not the case in APM. Perhaps that is easy to fix
these days...
Hi!
> >>root; and resume in the reverse order. Is that behaving now?
> >
> >
> >Yes.
>
> Well, partially; but it's not used consistently. Could you
> (or someone) explain what the plan is? I see:
>
> - Three separate x86 PM "initiators": APM, ACPI, swsusp.
>(Plus ones for ARM and MIPS.)
David Brownell wrote:
The pm_*() is how a handful of sound drivers and other random
stuff register themselves -- and how PCI does it.
To clarify, before someone jumps all over me: look inside
the PCI code, you'll see that PCI as a whole is registered
using the pm_*() stuff for power management.
Pavel Machek wrote:
Agreed, this needs work. Some USB device drivers will likely need to
implement suspend()/resume() callbacks, which thoughtfully enough the
driver model conversion already gave us. At one point it was planned
to have it automatically traverse the devices and suspend, leaves up
On Sat, 26 Jul 2003, Pavel Machek wrote:
> Hi!
>
> > >>I'm not sure how the design is intended to work, but either way something
> > >>needs to be fixed.
> >
> > Yes, it seems like all the HCDs (and the hub driver) need attention.
>
> Why the hub driver?
>
> For basic functionality, you simpl
Hi!
> >>I'm not sure how the design is intended to work, but either way something
> >>needs to be fixed.
>
> Yes, it seems like all the HCDs (and the hub driver) need attention.
Why the hub driver?
For basic functionality, you simply power it down (doing virtual
unplug), and power it back up o
Pavel Machek wrote:
Hi!
I'm not sure how the design is intended to work, but either way something
needs to be fixed.
Yes, it seems like all the HCDs (and the hub driver) need attention.
Why the hub driver?
For basic functionality, you simply power it down (doing virtual
unplug), and power it
On Fri, 25 Jul 2003, David Brownell wrote:
> Benjamin Herrenschmidt wrote, responding to Alan Stern:
> >>I think the hub driver's power management code may be at fault. It needs
> >>to cancel the status interrupt URB when suspending and resubmit it when
> >>waking up; right now it probably does n
Benjamin Herrenschmidt wrote, responding to Alan Stern:
I think the hub driver's power management code may be at fault. It needs
to cancel the status interrupt URB when suspending and resubmit it when
waking up; right now it probably does neither one.
Or maybe I'm wrong about that. Perhaps it's o
> I think the hub driver's power management code may be at fault. It needs
> to cancel the status interrupt URB when suspending and resubmit it when
> waking up; right now it probably does neither one.
>
> Or maybe I'm wrong about that. Perhaps it's okay to leave the URB active.
> If that's t
On Fri, 25 Jul 2003, Dominik Brugger wrote:
> Good morning,
>
> > Do not unload modules before suspend, they should handle that just
> > fine.
>
> If I keep them loaded during suspend:
>
> [...]
> Suspending devices
> uhci-hcd :00:11.2: suspend to state 3
> drivers/usb/host/uhci-hcd.c: dc00
Good morning,
> Do not unload modules before suspend, they should handle that just
> fine.
If I keep them loaded during suspend:
[...]
Suspending devices
uhci-hcd :00:11.2: suspend to state 3
drivers/usb/host/uhci-hcd.c: dc00: suspend_hc
hwsleep-0257 [10] acpi_enter_sleep_state: Entering sl
Hi!
> > In 2.6.0-test1, OHCI is non-functional after first suspend/resume, and
> > kills machine during secon suspend/resume cycle.
>
> I experience similar problems with UHCI:
>
> Before suspending to S3 I unload usb modules and afterwards I reload them, but it
> does not work again.
> (For te
Hi!
> > In 2.6.0-test1, OHCI is non-functional after first suspend/resume, and
> > kills machine during secon suspend/resume cycle.
>
> I experience similar problems with UHCI:
Strange, UHCI worked for me last time I tried. I'll try again soon...
Hello again,
I have a few things to add:
1) If uhci_hcd was never loaded before suspend, one has to press a key on the keyboard
after `echo 3 > /proc/acpi/sleep` in order to get the machine suspended. Wakeup does
not work in that case, reboot required.
2) It makes no difference whether the Log
> In 2.6.0-test1, OHCI is non-functional after first suspend/resume, and
> kills machine during secon suspend/resume cycle.
I experience similar problems with UHCI:
Before suspending to S3 I unload usb modules and afterwards I reload them, but it does
not work again.
(For testing I also plugged
42 matches
Mail list logo
