lkml.org 
[lkml]   [2006]   [Feb]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Flames over -- Re: Which is simpler?
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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-02-13 21:11    [W:0.119 / U:1.156 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site