User: Password:
|
|
Subscribe / Log in / New account

Blocking suspend blockers

Blocking suspend blockers

Posted May 20, 2010 18:30 UTC (Thu) by felipebalbi (guest, #56613)
In reply to: Blocking suspend blockers by neilbrown
Parent article: Blocking suspend blockers

Imagine what would happen if you suspend while usb cable is attached. You don't really know whether pc has mounted the file system (considering you're using mass storage) and if the pc is transferring files to device, since with mass storage we need a 2 second poll for media change and there's no way to differentiate those IRQs from actual _data_ coming to device. They're all endpoint IRQs.

If you forcefully suspend at that point, you're risking corrupting user's Data.

Also, we can get pretty much the same power consumption with cpufreq + cpuidle + runtime pm since idle consumption is HW characteristic, not SW. If we don't reach that level, it only mean device isn't idle enough and there's some cripple app waking up the processor.


(Log in to post comments)

Blocking suspend blockers

Posted May 20, 2010 19:40 UTC (Thu) by sfeam (subscriber, #2841) [Link]

That seems to be an argument in favor of suspend blockers, rather than against them. That "actual _data_" operation can be protected by a suspend block, while the period poll for media change is not. What level the suspend blocker is invoked from to bracket a data transfer is a separate question.

I may be missing your point about suspending while a usb file system is mounted. If you can suspend your laptop while the hard drive is mounted, isn't it equally desirable to be able to suspend it while a memory stick is mounted? I imagine that a forceful suspend would necessarily trigger a sync operation, but isn't that true anyhow?

Blocking suspend blockers

Posted May 21, 2010 1:30 UTC (Fri) by dlang (subscriber, #313) [Link]

a problem with suspending while a USB device is connected is that it's highly likely that the USB device will no longer be connected when the system tries to come back up from being suspended.

Blocking suspend blockers

Posted May 22, 2010 8:19 UTC (Sat) by quintesse (guest, #14569) [Link]

But that's a problem the system has to deal with anyway, the user can yank out the cable at any time.

Blocking suspend blockers

Posted May 22, 2010 18:48 UTC (Sat) by giraffedata (subscriber, #1954) [Link]

But that's a problem the system has to deal with anyway, the user can yank out the cable at any time.

The system more options to deal with the user yanking out the cable, because the user expects yanking the cable to interrupt use of the device, and the user can arrange not to yank the cable if it is a problem. In contrast, suspend happens all by itself at largely arbitrary times, so the user won't expect interruption and can't practically avoid it.

Blocking suspend blockers

Posted May 22, 2010 22:00 UTC (Sat) by sfeam (subscriber, #2841) [Link]

The system has more options to deal with the user yanking out the cable, because the user expects yanking the cable to interrupt use of the device, and the user can arrange not to yank the cable if it is a problem. In contrast, suspend happens all by itself at largely arbitrary times, so the user won't expect interruption and can't practically avoid it.

Huh? The point is that suspend/resume should be harmless with respect to a device that is still plugged in.

If the device is still plugged in when the system resumes, open files should still be open, etc. This already works with the hard drive; is it really so hard to re-establish communication with a usb device?
If the device is gone when the system resumes, that's a problem, yes. But it's the same problem as just yanking the cable while the system is active. Or hold on, it's actually a less serious problem, because we should have been smart enough to sync during the suspend process, whereas there was no opportunity to do so during the cable yanking.

Blocking suspend blockers

Posted May 22, 2010 22:32 UTC (Sat) by giraffedata (subscriber, #1954) [Link]

Oh, I misunderstood "connected" as in the device may not be connected when the system wakes up. "Connected" is a logical state to me, but I can see it was supposed to mean plugged in.

I agree. There's no issue with a cable being yanked while the system is asleep that doesn't also exist for the cable being yanked while it's awake.

Well, except that since going to sleep correlates with a lull in user activity, there's a higher chance of that yank happening while the system is asleep. But since preventing the sleep won't prevent the lull in user activity, I don't suppose that's relevant to the question of whether suspension should be blocked.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds