Re: Flames over -- Re: Which is simpler?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



David Brownell wrote:
What ide drive?  Oh, you're talking about PC-ish systems, not
embedded ones that don't _have_ rotating media to power off.

Yes, that's exactly what the discussion is about; disk drives with mounted filesystems and what happens to them when you suspend/resume.
Your experience is very different from mine; I've observed that
most PC hardware keeps USB powered in suspend-to-ram states, so
a keyboard or mouse action may wake the system up, just as it can
with many PS2 style keyboards and mice.  Same thing for Ethernet,
using various types of wakeup event including "magic packet".
See /proc/acpi/wakeup, and the related parts of the ACPI specs.
(And USB specs, and lots more ... this info is widespread.)

As I have said before, some systems can keep the USB bus in a low power mode where it can wake the system, but AFAIK, waking the system is all they can do in this state; they can not tell the kernel that device x has been connected and device y has been disconnected, the kernel must figure that out by probing the hardware and comparing the list with what it knew to be connected prior to suspending. Even if some hardware can provide that information, kernel can not rely on it.
<snip>

You should also remember a useful point from the ACPI spec:
if you're taking the system apart with a screwdriver, then
you've gone out-of-spec.  So swapping IDE drives is strongly
in the "user error" category ... unlike swapping USB drives,
which is equally strongly in the "normal operation" category.
(So it would be an error if Linux didn't properly detect when
users unplug all usb devices after putting their laptops into
STR and before carrying them someplace else...)

Yes, it would be an error if the kernel did not notice that you actually did unplug a usb disk while it was suspended. It is just as much an error however, if the kernel erroneously decides that you disconnected the drive, and thus breaks the mount on it, when you in fact, did no such thing.

Read about the #PME signal status in the PCI PM capabilities.

And the USB remote wakeup reporting done by USB hubs; you can
even look at the drivers/usb/core/hub.c code and see how usb
wakeup events (of various types) are handled.

You don't seem to know what you're talking about here.


Which is why I qualified my statements with "AFAIK". Maybe you could enlighten me. Does the #PME signal carry enough information to inform the kernel that the reason the system is being woken up is because you unplugged the mouse from the usb hub? I was under the impression that this was not the case, instead the kernel at best knows it is being woken up because the USB host controller generated a wake event. Because of this and the fact that SCSI busses that I have seen do no such thing, I assumed the kernel would handle USB in the same way, specifically, that it would reenumerate and provided the same hardware is still there that it expects to be there, then it would continue operation as normal rather than deciding the drive was unplugged.
You were wrong then too... both about probing "all hardware" and about not
being able to distinguish wakeup event sources.

Are you quite certain about that? This is not the case for SCSI disks, but for USB, maybe it can provide sufficient information to the kernel about state changes without having to do a full rescan. If that is the case, and the hardware is erroneously reporting that all devices were disconnected and reconnected after an ACPI suspend to disk, then such hardware is broken and the kernel should be patched to work around it.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux