Re: System hang when trying to enter sleep/standby state

[Karol Kozimor <sziwan-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org>]

Thus wrote Patrick Mochel:
> > > You're absolutely right. But, most people do those things deliberately, 
> > > and know the consequences. 
> > Do you think someone becomes root and does an "echo 5 > /proc/acpi/sleep"
> > by accident? ;-)
> Definitely. By, trying a range of values, they stumble on one that crashes 
> their system. 

Yeah, as if all the values worked smoothly on all systems. Echoing '1' or
'3' hangs my system in most (S1) or all cases (S3). Should they be
excluded also, or left as a config option? Enabled when they finally work
and are tested on all possible systems?

> > > Think about how this thread started: $Random User sees his system doesn't
> > > suspend when writing '4' to that file, so he tries every other value.
> > This is not a random user. This is someone who plays around with his
> > system while testing beta kernel drivers. 
> > The random user at this stage doesn't know about acpi at all. The
> > random user in the future (when acpi comes with Suse or RedHat Linux 
> > out of the box) will only use the GUIs to suspend and such. So there's
> > no problem at all, I think.
> The GUIs should not, and will not, support writing directly to that file. 
> In the perfect, abstract future, we will not even have /proc/acpi/sleep, 
> we will have an abstracted for entering sleep states. 

So, if you plan to change this anyway in the future (of ACPI becoming
mainstream, or being included in distros), what is really the reason of
changing it now, during the development steage?

Again, should I pull the reset button off my chassis just because I can
accidentally push it, have my machine rebooted, and oh my oh my, loose my
data? Is there really anybody who experiments with the sleep states not
having synced, or otherwise "secured" his data or filesystems?

[...]
> As a whole, we do enforce a minimum amount of policy we do not want to 
> lose users data. And that will happen. 
> 
> Let me repeat, and try and get you to listen: 
> 
> You *will* corrupt your data if you do not flush the disk buffers. 
> You *will* corrupt your data if you do not flush the disk buffers. 
> You *will* corrupt your data if you do not flush the disk buffers. 
> 
> That's why it's so slow when you do a normal shutdown. That's why 
> immediately putting the system into S5 is so fast - we don't flush the 
> buffers. 

This is obvious. At least for halfway intelligent users, who know what they
are doing. As Jens said, no random user will ever tamper with /proc, and if
he does, well, it's all his fault anyway.

[...]
> You are right, though, if they start writing random values into /proc, it 
> is their fault. But, the random range of numbers to be written to  
> /proc/acpi/sleep is small, and not that random. The documentation suggests 
> that some values work and others don't. It's human nature to exercise 
> curiosity and experiment with other close values. If they do, which they 
> are so likely to, I do not want to see them cause any harm to themselves. 

So let the documentation suggest explicitly, what exactly echoing 5 to that
file does? Anyway, as I said earlier, chances are that other values
will cause them equal harm. So what? Is that really the single way to harm
the machine, or cause filesystem corruption? I knew a user, who, when told
to copy a file on /dev/hda1, did exactly what he was said, i.e. "cp
filename /dev/hda1"... does this show that copying over a block device
should be disabled? That something is *generally* a bad idea doesn't mean,
it has no use whatsoever. 

Really, on modern desktops possibly data-corrupting reboots (due to a 
faulty X / DRI / whatever driver) are much more frequent to really care for
a poor user that experiments with ACPI not knowing much about it.

> > > For another, as mentioned before, we have safe mechanisms for halting a 
> > > system. See 'man 1 halt'. 
> > You have *no* other mechanism to turn your box off in less than one
> > second.
> Then concentrate on that, and don't encourage dangerous features in the 
> kernel. 

To be frank, there are some features in the kernel, that during the
configuration stage are labeled as ,,DANGEROUS''. For what reasons, do you
think, they still exist?

Regards,

-- 
Karol 'sziwan' Kozimor
sziwan-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org


-------------------------------------------------------
This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your  SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en