Hi!
From: Rafael J. Wysocki [EMAIL PROTECTED]
Reduce code duplication in drivers/base/suspend.c by introducing a separate
function for printing diagnostic messages.
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
ACK, thanks.
Hi!
Can you break this up into two patches? If the first adds the queuing
code and the second adds autosuspend support, it will be much easier to
appraise and test them.
Hi,
this code implements delayed execution of output requests arriving
for suspended HID devices.
usbhid.h
Hi!
In that case the user would see data corruption - just as if he mounts a
piece
of removable media in a USB card reader; yanks out the card and modifies
it
elsewhere, and then puts it back in.
I my opinion we can't really defend ourselves against such users... We
can
Hi!
The GNOME hath spoken?
I also thought about that,
I think that the best solution is still to hide connect/disconnect of
usb devices from userspace (now it also causes corruption)
But to refuse suspend with any usb mass storage device connected with
mounted
Hi!
Problem is that suspending _with_ removable mass storage devices
attached just will not work. User will unplug them, then complain
about corruption. Advanced user will unplug them, work with them
somewhere else, replug them, then loose filesystem.
Feel free to send patch to teach
Hi!
Problem is that suspending _with_ removable mass storage devices
attached just will not work. User will unplug them, then complain
about corruption. Advanced user will unplug them, work with them
somewhere else, replug them, then loose filesystem.
Feel free to send patch to teach
Hi!
Even if one doesn't use the fb console at all, radeonfb apparently
is still required on some ThinkPad models to work around BIOS bugs:
http://www.thinkwiki.org/wiki/Problem_with_high_power_drain_in_ACPI_sleep#Radeon_GPU_not_powered_off
s2ram should be able to work around
Hi!
Ok. To be honest, you are the first reporter that seems to have read
the documentation above, but not understood what to do.
thanks for the compliment ;-) _I_ very much know what to do (i mailed
the right person after all ;), but i dont really count and on the 6
(Can we get the
Hi!
You're better off using the VGA console, and lettign X re-initialize the
graphics device. That generally at least has a reasonably good chance of
working.
Re-initializing graphics modes really is very hard. You can try with the
BIOS video hack (I forget the kernel command line
Hi!
disabling the following radeonfb options in the .config made resume work
again:
In general, don't even *try* to use radeonfb for suspend/resume.
I don't think it has ever worked, except on some very rare laptops
(largely PPC Macs) where people had enough information to set up the
Hi!
You should have /proc/acpi/battery/*/state ; it shows current power
consumption.
Yes, that works. Cool :-)
Good... so how much power is it saving for you?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
On Wed 2007-01-31 16:54:39, Alan Stern wrote:
On Wed, 31 Jan 2007, Oliver Neukum wrote:
timer whenever there is any activity, and when the timer expires you know
the device has been idle long enough that you should suspend it. That's
exactly how the autosuspend infrastructure works.
Hi!
this preliminary patch should suspend your mouse, if it supports remote
wakeup. In fact it should do this to all devices which are HID, claimed by
the input layer and support remote wakeup.
It works for me with my mouse. I've tested letting it autosuspend and
resume. It survives going
Hi1
Measurements on x60:
What strange architectures is that?
It is thinkpad x60. i386 architecture.
Feb 1 15:58:14 amd kernel: Added idle timer for firing in 10 seconds
^[ Feb 1 15:58:24 amd kernel: state is 0
Feb 1 15:58:24 amd kernel: Modded idle timer for firing in 10 seconds
Hi!
You should have /proc/acpi/battery/*/state ; it shows current power
consumption.
Yes, that works. Cool :-)
Good... so how much power is it saving for you?
Nothing USB:
present rate:1874 mA
Mouse in use:
present rate:2031 mA
Sleeping
Hi!
this preliminary patch should suspend your mouse, if it supports remote
wakeup. In fact it should do this to all devices which are HID, claimed by
the input layer and support remote wakeup.
It works for me with my mouse. I've tested letting it autosuspend and
resume. It survives going
Hi!
if (ret != -EAGAIN)
msleep(1000);
+if (try_to_freeze())
+uea_err(INS_TO_USBDEV(sc), suspend/resume not
supported,
+please unplug/replug your modem\n);
Hi!
I started using el-cheapo usb mouse... only to find out that it breaks
suspend to RAM. Suspend-to-disk works okay. I was not able to extract
any usefull messages...
Resume process hangs; I can still switch console and even type on
keyboard, but userland is dead, and I was not able to get
Hi!
I started using el-cheapo usb mouse... only to find out that it breaks
suspend to RAM. Suspend-to-disk works okay. I was not able to extract
any usefull messages...
Resume process hangs; I can still switch console and even type on
keyboard, but userland is dead, and I was not able to
Hi!
I started using el-cheapo usb mouse... only to find out that it breaks
suspend to RAM. Suspend-to-disk works okay. I was not able to extract
any usefull messages...
Resume process hangs; I can still switch console and even type on
keyboard, but userland is dead, and I was not
Hi!
No, HID is the preferred... I am not sure what is going on - on my box
STR does not work at all thanks to nvidia chip turning the display on
all the way as the very last step of suspend ;(
One or several of these options might help cure this:
- agp=off kernel command line (plus AGP
On Thu 2007-01-11 08:48:53, Oliver Neukum wrote:
Am Mittwoch, 10. Januar 2007 23:35 schrieb Alan Stern:
Apparently here: drivers/base/core.c:
void device_del(struct device * dev)
{
struct device * parent = dev-parent;
struct class_interface *class_intf;
Hi!
usb 2-1: new full speed USB device using uhci_hcd and address 68
usb 2-1: USB disconnect, address 68
usb 2-1: unable to read config index 0 descriptor/start
usb 2-1: chopping to 0 config(s)
Does anybody know a legitimate reasons a device should have
0 configurations? Independent
Hi!
The obvious change with this device is that usb_set_configuration() is never
called, but that should not matter.
No, I think you're barking up the wrong tree.
Pavel, did you have CONFIG_USB_MULTITHREAD_PROBE turned on? I bet you did
-- there's no other way to generate the
Hi!
Here are a bunch of USB patches for 2.6.19.
They contain:
- new driver for usb debug device (client side only so far)
- helper functions to find usb endpoints easier
- minor bugfixes
- new device support
- usb core rework for autosuspend logic
-
Hi!
From: Paolo Abeni [EMAIL PROTECTED]
A binary interface is added to usbmon. For each USB bus present on the host
system a new file is added to the debugfs directory, in the form usb%db.
USB records are stored in a liked list, alike current text interface
implementation, so most code
Hi!
OK, let me state the basics.
To get real power savings, we:
- blank the display
- spin down the hard drive
- put the CPU into an ACPI sleep state
To do the latter well, we need to make sure there's no DMA. It is
important that less or little DMA will not help. We
Hi!
That is, the standard model is useless? I think you've made
a few strange leaps of logic there ... care to fill in those
gaps and explain just _why_ that standard model is useless???
Recall by the way that the autosuspend stuff kicked off with
discussions about exactly how to
Hi!
The power management functions without
timeout are also exported. For other power control features like
cpu frequency considerable effort has been made to export them to
user space.
Yes, and many of us use the much lighter weight kernel based control
models by preference.
On Sun 2006-10-08 21:57:17, Oliver Neukum wrote:
Am Sonntag, 8. Oktober 2006 21:36 schrieb Pavel Machek:
AOLMee too/AOL
Please, lets do few autosuspend things, and when we know how it
looks, we can think about doing something more advanced.
Very well, which drivers do you want first
Hi!
- the issues of manual automatic suspend and remote wakeup are
orthogonal
- there should be a common API for all devices
AFAIK there is no demonstrated need for an API to suspend
individual devices. ...
I doubt that a lot.
You haven't demonstrated
On Thu 2006-10-05 18:35:21, Oliver Neukum wrote:
Am Donnerstag, 5. Oktober 2006 18:21 schrieb Alan Stern:
Currently we don't have any userspace APIs for such a daemon to use. The
only existing API is deprecated and will go away soon.
I trust it'll be replaced.
It does not seem that API
On Thu 2006-10-05 20:43:59, Oliver Neukum wrote:
Am Donnerstag, 5. Oktober 2006 20:24 schrieb Alan Stern:
On Thu, 5 Oct 2006, Oliver Neukum wrote:
Am Donnerstag, 5. Oktober 2006 18:21 schrieb Alan Stern:
Currently we don't have any userspace APIs for such a daemon to use.
The
On Fri 2006-10-06 09:04:51, Oliver Neukum wrote:
Am Freitag, 6. Oktober 2006 04:47 schrieb David Brownell:
On Thursday 05 October 2006 2:25 pm, Oliver Neukum wrote:
- the issues of manual automatic suspend and remote wakeup are
orthogonal
- there should be a common API for all
Hi!
Reproduce it with 2.6.18, then it is bugzilla time, or post
to linux-usb mailing list.
Thanks Pavel. I tried with kernel 2.6.18. It worked fine with bulk
device ( USB key). But does not work with isochronous device and system
hangs. This time I did not have kdb so could not figure
Hi!
You marked all the patches as 1/3, btw.
this patch avoid that the kernel thread block the suspend process.
Some work is still need to recover after a resume.
Signed-off-by: Matthieu CASTET [EMAIL PROTECTED]
this patch avoid that the kernel thread block the suspend process.
Some
Hi!
this implements suspend support for usblp. According to the CUPS people
ENODEV will make CUPS retry the job. Thus it is returned in the runtime
case. My printer survives suspend/resume cycles with it.
Does it allow uhci to powersave, thus saving lots of power?
Hi!
Plug/unplug should be easy enough to simulate from usb driver, no?
if a USB driver doesn't define suspend/resume methods, then the core simply
unplugs it on suspend, and replugs on resume (IIRC).
No longer true, and IIRC it never was. All that happens is that URB
submissions
Sonntag, 24. September 2006 11:08 schrieb Pavel Machek:
Hi!
I made some quick experiments, and usb still eats 4W of battery
power. (With whole machine eating 9W, that's kind of a big deal)...
This particular machine has usb bluetooth, but it can be disabled by
firmware, and appears
Hi!
I made some quick experiments, and usb still eats 4W of battery
power. (With whole machine eating 9W, that's kind of a big deal)...
This particular machine has usb bluetooth, but it can be disabled by
firmware, and appears unplugged. (I did that). It also has fingerprint
scanner, that can't
Hi!
I made some quick experiments, and usb still eats 4W of battery
power. (With whole machine eating 9W, that's kind of a big deal)...
This particular machine has usb bluetooth, but it can be disabled by
firmware, and appears unplugged. (I did that). It also has fingerprint
scanner, that
Hi!
I made some quick experiments, and usb still eats 4W of battery
power. (With whole machine eating 9W, that's kind of a big deal)...
This particular machine has usb bluetooth, but it can be disabled by
firmware, and appears unplugged. (I did that). It also has fingerprint
scanner,
Hi!
+main kernel instead of as a separate module, you can put
+usbcore.persist=1 on the boot command line. You can also change the
+kernel's behavior on the fly using sysfs: Type
+
+ echo y /sys/module/usbcore/parameters/persist
Does sysfs treat 'y' as '1'?
Anyway, it would
Hi!
And we also need to be able to handle devices in the device tree that do
not have a suspend/resume function, or ones that are not attached to any
bus, without failing the suspend, as obviously they do not care or need
to worry about the whole issue.
Ah, there's the rub. If a
Hi!
diff --git a/drivers/usb/host/ohci-pxa27x.c b/drivers/usb/host/ohci-pxa27x.c
index acde886..1d8b58c 100644
--- a/drivers/usb/host/ohci-pxa27x.c
+++ b/drivers/usb/host/ohci-pxa27x.c
@@ -185,6 +185,13 @@ int usb_hcd_pxa27x_probe (const struct h
/* Select Power Management Mode */
Hi!
If that does the job we need to somehow inherit the power supply maximum
from
PCI when we allocate the root hub's device structure.
I don't think there is such a convention that's generic for PCI. There
might
be ACPI-specific tables holding that value, but on embedded
This limits power budget on spitz to 250mA. I'm not sure if it is the
right value, but it is certainly better than default 500mA, and
prevents nasty failure mode with zd1201.
Signed-off-by: Pavel Machek [EMAIL PROTECTED]
PATCH FOLLOWS
KernelVersion: 2.6.17-rc6-git
diff --git a/drivers/usb/host
On Út 06-06-06 10:02:55, Mark Lord wrote:
Pavel Machek wrote:
Common cellphones are 2W, iirc; (so it would be ~1mW) but I was more
interested in system power consumption. WIFI is too power intensive
for a cellphone (mostly). Is this designed to go into cellphones?
notebooks?
Most mobile
UWB is a high-bandwidth, low-power, point-to-point radio
technology using a wide spectrum (3.1-10.6HGz). It is
How much power is low power?
For what I know (and I could be wrong) max is around -40dBm/MHz
in the US. I am no expert in the nitty-gritty radio details, but
I've been
Hi!
It's Ok if it involves a drive change, so long as its an optional change,
which
means that it shouldn't affect the interface very much (i.e. the calling
convention). That's why it'd be good to augment and/or modify pm_message_t
to implement the changes, so we wouldn't have to
Hi!
https://bugzilla.novell.com/show_bug.cgi?id=173420
From Comment #30 at the above url: The Linux ACPI code seems to
actively prevent the fan from running and that worries me.
I saw that as well, and found the following recipe would work around
the problem:
1. Set the trip point
Hi!
During swsusp the system is
supposed to be completely off, with no suspend power available. Hence
all the power sessions are guaranteed to be interrupted, and the boot
kernel doesn't have to worry about destroying any of them.
Not necessarily. x86
On Út 25-04-06 16:13:41, David Brownell wrote:
On Tuesday 25 April 2006 2:41 pm, Pavel Machek wrote:
Well, if we had a pm_should_I_spin_down_drives() it would make sense to me
that it return FALSE during kernel_restart_prepare() too ... surely kexec
users have the same issues
(aha, I see the mail now)
I've begun thinking that calls like pm_should_I_spin_down_drives() would
be a
better structural approach than continually redefining this freeze
thing so
it makes less and less sense to all other drivers ... who nonethless need
to
clutter
Hi!
That's suspend-to-disk, yes?
Dave, would you have the 2.6.15-1.1830_FC4 - 2.6.15-1.1831_FC4 details
handy? There surely can't be much difference?
There seem to be several ACPI problems there. Do we have a reliable means
of feeding such reports up into the (for example) acpi
On So 04-02-06 23:14:26, Russell King wrote:
On Sat, Feb 04, 2006 at 08:47:29AM -0800, Martin J. Bligh wrote:
[Bug 5958] CF bluetooth card oopses machine when
http://bugzilla.kernel.org/show_bug.cgi?id=5958
This isn't a serial bug - it's a bluetooth ldisc bug. I
Hi!
http://projects.o-hand.com/hx2750/patches/usb_pxa27x_udc-r0.patch
is the pxa27x driver itself. I've taken the one from handhelds.org and
made changes to get full CDC-Ethernet running with it instead of
CDC-Subset by handling the pxa27x specific configuration issues
properly. I've also
Hi!
since I switched to 2.6.15-rc2-git6, my machine is not able to suspend
anymore if my USB printer is plugged in. The problem is reproducible.
usb 1-2: new full speed USB device using uhci_hcd and address 3
drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 3 if 0 alt
Hi!
This converts comments into C-style, and removes unused
initializers. I'd like it applied...
On a related note -- how well does it work, particulary with different
hosts? It uses 'volatile' quite heavily, and that scares me a lot.
Signed-off-by: Pavel Machek [EMAIL PROTECTED]
diff --git
Hi!
This converts comments into C-style,
You missed a lot of them.
Yes, I know, at one point I realized you probably liked it that
way. Shall I resent just the remove the initializer part?
What's the reason for this prejudice against C++-style comments in the
kernel? I've never
Hi!
What's the reason for this prejudice against C++-style comments in the
kernel? I've never understood it... They seem so obviously useful,
saving 3 characters of typing at the end of each comment line.
I've never seen a piece of non-crappy code using them... that's
probably
Hi!
Of course I forgot the patch...
Pavel
Remove useless initalizers.
Signed-off-by: Pavel Machek [EMAIL PROTECTED]
diff --git a/drivers/usb/gadget/file_storage.c
b/drivers/usb/gadget/file_storage.c
--- a/drivers/usb/gadget
Hi!
In -mm, usb breaks suspend to disk. Compiled without
CONFIG_USB_SUSPEND, it just plainly fails; iwth USB_SUSPEND, it
actually tries to suspend USB, but it fails and machine refuses to
suspend. Is it known or is it worth debugging?
Hi!
In -mm, usb breaks suspend to disk. Compiled without
CONFIG_USB_SUSPEND, it just plainly fails; iwth USB_SUSPEND, it
actually tries to suspend USB, but it fails and machine refuses to
suspend. Is it known or is it worth debugging?
More details please.
2.6.14-rc1 is a little old
Hi!
- You might want to differentiate between this key and the ENTER key
of your keyboard, at least I do. If the kernel is sending the same
code for both keys, this is not possible in userspace.
No, I think that you can still diferentiate between them ... they come
from different keyboard
Hi!
I discovered a minor change in 2.6.10-mm1, changing this value back
corrects the ok button issue.
diff -urN linux/drivers/usb/input/ati_remote.c
linux-2.6.11/drivers/usb/input/ati_remote.c
--- linux/drivers/usb/input/ati_remote.c2005-08-02
17:56:26.0 +1200
+++
Hi!
Actually this patch should be in the queue somewhere... We had it in
suse trees for a long time, and IMO it can solve problem easily.
Pavel
--- clean-git/kernel/sys.c2005-04-23 23:21:55.0 +0200
Hi!
Well it seems that people are starting to want to hook the reboot
notifier, or the device shutdown facility in order to properly shutdown
pci drivers to make kexec work nicer.
So here's a patch for the PCI core that allows pci drivers to now just
add a shutdown notifier
Hi!
I don't like this notion of stop separated from power states anyway, I
think it just doesn't work in practice.
Yeah, after giving it some additional thought, I think there are better ways.
Ben.
Ok, here's a new idea.
For many devices -suspend and -resume with
On Po 25-04-05 18:13:27, Dave Jones wrote:
On Mon, Apr 25, 2005 at 02:58:31PM -0700, Andrew Morton wrote:
Alan Stern [EMAIL PROTECTED] wrote:
On Mon, 25 Apr 2005, Alexander Nyberg wrote:
Not sure what you mean by make kexec work nicer but if it is because
some devices
I've been considering for a while that, in addition to -probe and -remove,
we
have the following:
struct device --
-attach - binds to the device and allocates data structures
-probe - detects and sets up the hardware
-start - begins transactions (like DMA)
-stop - stops transactions
Hi!
Well, you can do half suspend to ram; change your frequency; half
resume today, and it should work, but I do not think you'll like the
speed.
Indeed. With people running things like cpuspeed daemons to dynamically
scale speed, this is going to be really painful.
Of course, any
Hi!
Well it seems that people are starting to want to hook the reboot
notifier, or the device shutdown facility in order to properly shutdown
pci drivers to make kexec work nicer.
So here's a patch for the PCI core that allows pci drivers to now just
add a shutdown notifier
Hi!
Apr 13 21:22:52 amd kernel: usb 2-2: new full speed USB device using
uhci_hcd and address 3
Apr 13 21:22:52 amd kernel: usb-storage: This device (0693,0002,0100 S 06 P
50) has unneeded SubClass and Protocol entries in unusual_devs.h
Apr 13 21:22:52 amd kernel:Please send a
Hi!
...
Apr 13 21:22:52 amd kernel: usb 2-2: new full speed USB device using uhci_hcd
and address 3
Apr 13 21:22:52 amd kernel: usb-storage: This device (0693,0002,0100 S 06 P 50)
has unneeded SubClass and Protocol entries in unusual_devs.h
Apr 13 21:22:52 amd kernel:Please send a copy of
Hi!
Here, for your consideration, are fixups I still have in my tree after
updating to rc2.
(USB Framebuffer lists copied because a reasonable number apply
there).
Regards,
Nigel
diff -ruNp
840-combined-pm_message_t-patch.patch-old/drivers/base/power/resume.c
Hi!
And here's the patch. Applies cleanly against the latest kernel.org BK.
Agaist Greg's latest BK, and maybe against the MM tree, you'll want
to globally substitute HCD_STATE and USB_STATE with HC_STATE before
applying the patch.
Summary of changes: cope with pm_message_t, and
Hi!
Please. I think that's all the suspend-related patches I've sent
recently, and from what I see of Pavel's patch they're basically a
superset: comparable pm_message_t changes, plus real bugfixes. :)
I'm getting wholly fed up with this whole fiasco. How about I just drop
Hi!
a) apply
b) compile
c) work
?
The patches I sent certainly meet those requirements -- in my testing,
and against 2.6.12-rc1.
You're wanting a version that applies to 2.6.12-rc1-mm? Then instead
of the patch I previously sent on this thread, I think this
Hi!
Guys, is this something which we expect will be fixed when the USB power
management fixes are complete?
Changing config during hibernate should be okay for all things that
are hot-pluggable (when we are done ;-). That includes USB
Hi!
In 2.6.11-rc[23], I get problems after swsusp resume:
Feb 4 23:54:39 amd kernel: Restarting tasks...3hub 3-0:1.0:
over-current change on port 1
Feb 4 23:54:39 amd kernel: done
Feb 4 23:54:39 amd kernel: hub 3-0:1.0: connect-debounce failed, port
1 disabled
Feb 4 23:54:39
Hi!
In 2.6.11-rc[23], I get problems after swsusp resume:
Feb 4 23:54:39 amd kernel: Restarting tasks...3hub 3-0:1.0:
over-current change on port 1
Feb 4 23:54:39 amd kernel: done
Feb 4 23:54:39 amd kernel: hub 3-0:1.0: connect-debounce failed, port
1 disabled
Feb 4 23:54:39 amd kernel: hub
Hi!
In 2.6.11-rc[23], I get problems after swsusp resume:
Feb 4 23:54:39 amd kernel: Restarting tasks...3hub 3-0:1.0:
over-current change on port 1
Feb 4 23:54:39 amd kernel: done
Feb 4 23:54:39 amd kernel: hub 3-0:1.0: connect-debounce failed, port
1 disabled
Feb 4 23:54:39 amd
Hi!
In 2.6.11-rc[23], I get problems after swsusp resume:
Feb 4 23:54:39 amd kernel: Restarting tasks...3hub 3-0:1.0:
over-current change on port 1
Feb 4 23:54:39 amd kernel: done
Feb 4 23:54:39 amd kernel: hub 3-0:1.0: connect-debounce failed, port
1 disabled
Feb 4 23:54:39
Hi!
Your logs don't indicate which host controller driver is bound to each of
your hubs. /proc/bus/usb/devices will contain that information. Without
it, it's hard to diagnose what happened.
I do not think I have any hubs... no external hubs anyway. And I do
not have
Hi!
From: Bernard Blackham [EMAIL PROTECTED]
This fixes types in USB w.r.t. driver model. It should not actually
change any code. Please apply,
Pavel
Signed-off-by: Pavel Machek [EMAIL PROTECTED]
diff -ru linux-2.6.11-rc2
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
information that was essential to figuring
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 instead, or
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
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
Hi!
Okay, it is probably different problem (and looks like usb
problem). It worked ok in 2.6.9, right?
I don't know. This laptop is quite new.
Noapic doesn't work.
Okay, it probably never worked before. I'm happy that it at least
works after unplug/replug :-). Probably better
Hi!
I don't have swsusp compiled in, but if I unload and
reload the module, then it works.
Anyway, this is not the intended behaviour, as it
worked fine till 2.6.10 without unload/reload.
Yes it is a bug. Find which changeset causes it and complain to its author.
It is probably going to be
Hi!
With kernel 2.6.10, I have the following problem with uhci_hcd:
After an ACPI S3 suspend it fails to see any USB device plugged in.
If I unload the module and load it again, it works again.
I hadn't this problem with previous kernels, where it worked just fine.
Do you know something that
Hi!
One significant example involves USB mice. If they were to be
suspended (usb_suspend_device) after a few seconds of inactivity,
that change could often spread up the device tree and let the
USB host controller stop DMA access. Some x86 CPUs could
then enter C3 and save a couple Watts
Hi!
It seems there's a problem with USB OHCI driver that causes these traces to
appear on suspend on an AMD64-based box:
Check if OHCI's suspend/resume method is called correctly and that
OHCI really acts on it.
Pavel
--
People
Hi!
So how about this instead? We have a policy-oriented list of power
settings, pretty much the same as it is now. Things like Full-Power,
Standby, Suspend-to-RAM, Suspend-to-Disk, Power-Off, and
Selective-Suspend. The values are descriptive only; they don't indicate
anything about
Hi!
Pavel says this is linux/kernel.h system_state, but I don't
see the mapping. Used by ide-disk.c, and little else.
SYSTEM_BOOTING isn't a power level...
I'd be interested in seeing system power policies be pluggable
objects like cpufreq governors, i/o schedulers, and so forth.
Hi!
I'd rather see a struct with a printable name (or even just the printable
name) and drivers knowing which constant pointers to compare to.
And have that name show up in sysfs. Abolish confusion about u32
values, and easily catch all the drivers (ab)using the old value. Not
Hi!
Oh and do not spend too much time on standby, new computers usually do
not support it anyway. If we have suspend-to-ram working, there's no
reason using standby.
I suspect that once the other states are implemented, Standby won't add
much extra.
By the way, I see that the
Hi!
So how about this instead? We have a policy-oriented list of power
settings, pretty much the same as it is now. Things like Full-Power,
Standby, Suspend-to-RAM, Suspend-to-Disk, Power-Off, and
Selective-Suspend. The values are descriptive only; they don't indicate
anything
1 - 100 of 165 matches
Mail list logo
