Re: 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: Flames over -- Re: Which is simpler?
    ... different from testing whether it has changed -- it could have changed while the system was asleep, with the result that hardware is indeed there but it's not the _same_ hardware. ... It is currently my belief that the kernel probes the hardware the same way after a cold boot, resume from s-t-r, and resume from s-t-d. ... This is why you can suspend to disk, and when you resume, your open files are still valid; the disk is found to be still there, so it continues to be accessible. ... the kernel queries the USB controller to see if a disconnect occurred while the system was asleep. ...
    (Linux-Kernel)
  • Re: [opensuse] Kernel Update and USB Mouse on SuSE 9.3
    ... Ruben Safir wrote: ... I've update my kernel to get it to function with new hardware and the modules for my eepro100 ... and USB mouse aren't working now. ...
    (SuSE)
  • Re: [opensuse] Kernel Update and USB Mouse on SuSE 9.3
    ... I've update my kernel to get it to function with new hardware and the modules for my eepro100 ... The USB mouse, however, looks like a more ... USB Human Interface Device Configuration ...
    (SuSE)
  • Re: Broken USB detection on RH 9.0
    ... My problems with USB started couple days ago in other words whe have saw ... was instalation of SCSI Adaptec 29320ALP-R module from RPM package. ... usb-ehci they are loading but after messeges about found usb hardware at ... This is the latest 2.4 kernel, it will have more recent drivers than your ...
    (comp.os.linux.hardware)
  • PROBLEM: Oops when using emi62 with 2.6.28
    ... With kernel 2.6.28 (and I don't really know which version of the kernel ... emi62 soundcard usb firmware oops ... 2000-2fff: PCI Bus 0000:02 ... # Infrared-port device drivers ...
    (Linux-Kernel)