Bug 439018

Yes, it is a requirement. And now that more and more Desktop systems become capable of doing a suspend to RAM, it might become an issue. Maybe we should at least add it to the release notes?

If you're interested, please see http://www.energystar.gov/ia/partners/product_specs/program_reqs/Computer_Spec_Final.pdf: (3) Power Management Requirements

I would not have a problem having it as default for SLED, as that's more of a business Desktop, but... Do we really need to be compliant for openSUSE? People will have no idea what happen and 1) Think their computer broke, 2) Report bugs about it here

Shouldn't we at least let the user decide if he wants to be compliant, either during install or something like that (IMHO, should be default off)

BTW; I think I've already seen bug reports about this, but didn't connect the dots until someone asked on the -factory ML.

We've got gconf2-branding-SLED and gconf2-branding-openSUSE I guess, so this could be easily changed.

But needs to be decided by the responsible people...

We might also want a different value for SLES, I believe.

Indeed, good catch.  I am pretty sure that by default SLES must not
suspend when idle.

Just a note: When making the decision if autosuspend should be enabled on usual desktop systems, please keep in mind that it actually makes even more sense to have it there than on a laptop. Desktops usually consume a lot more power than laptops, and it's also only for those few which are whitelisted to have working suspend to ram.

The biggest problem is desktop machines that *can't* suspend.  Doesn't pm-utils detect this and refuse to try?

Correct, for those which are not whitelisted to have working suspend, it shouldn't matter.

And for machines that are whitelisted and it still doesn't work? Or if a machine is whitelisted but STR doesn't work if one have to install proprietary video drivers to even be able to use the machine?
As I said, this, surely, is not something that we should have in openSUSE (or SLES).

If the system is whitelisted, suspend works there, if it doesn't, it's just a bug.

BTW; Isn't coolo back on deck now so he should be on "NEEDINFO"?

actually I have all my private computers to autosuspend set. So I'm biased.

Just chatted with Timo (as replacement of Holger :) and openSUSE PM. Based on the data we have, leaving the default to save power is a good thing - I think by now even the last one understood that wasting power is bad. And the default can be changed easily by those that need their computer in different ways.

If there are other bugs that make this feature dangerous, we can still back out of it, but that's not topic in this bug.

FYI: I just opened bug 439980 for the release notes entry.

If a developer has some time left: showing a notification shortly before the very first autosuspend (it will still be readable after resume if the user didn't close it before) with a hint how to disable autosuspend would be useful ;-)

(In reply to comment #14 from Stephan Kulow)

> And the default
> can be changed easily by those that need their computer in different ways.

No, we can't. Not system wide, not easily, and users are not warned.

Plus, the machine hibernates automatically even if there are open network connections or running programs or opened files on external media that do not survive.

(In reply to comment #15 from Christian Boltz)

> showing a notification shortly before the very first autosuspend
> (it will still be readable after resume if the user didn't close it before)

...by which time the user may have lost data and be very pissed.

(In reply to comment #15 from Christian Boltz)
> FYI: I just opened bug 439980 for the release notes entry.
> 
> If a developer has some time left: showing a notification shortly before the
> very first autosuspend (it will still be readable after resume if the user
> didn't close it before) with a hint how to disable autosuspend would be useful
> ;-)
> 

I don't think many users read the release notes.
Actually they will start complaining about this "feature" before someone point them to the way to disable it.

(In reply to comment #14 from Stephan Kulow)
> Just chatted with Timo (as replacement of Holger :) and openSUSE PM. Based on
> the data we have, leaving the default to save power is a good thing - I think
> by now even the last one understood that wasting power is bad. And the default
> can be changed easily by those that need their computer in different ways.
> 
> If there are other bugs that make this feature dangerous, we can still back out
> of it, but that's not topic in this bug.
> 

Just put a simple checkbox in the install process and let the user decide if he wants this enabled for all by default or not. And/or find the way to let root disable/enable it for all users.

*** Bug 439077 has been marked as a duplicate of this bug. ***

Most issues people might have are plain bugs that need to be fixed. Actually, I think that having something by default will put more pressure on people fixing the issues, like 'external usb disk is /dev/sdc after resume and has been /dev/sda before'.

So I think we'll keep this setting for openSUSE and SLED, and will disable it for SLES. If comment 14 still applies. And we'll try to fix all related bugs. If they're too severe, we still can revert it for openSUSE.

(In reply to comment #19 from Holger Macht)
> Most issues people might have are plain bugs that need to be fixed. Actually, I
> think that having something by default will put more pressure on people fixing
> the issues, like 'external usb disk is /dev/sdc after resume and has been
> /dev/sda before'.

Should I remind you that I opened a bug about this change drom sda to sdc about a year ago and it was closed as "INVALID"?  >:|

> 
> So I think we'll keep this setting for openSUSE and SLED, and will disable it
> for SLES. If comment 14 still applies. And we'll try to fix all related bugs.
> If they're too severe, we still can revert it for openSUSE.
> 

I'm going to feel more of a guinea pig than ever...

(In reply to comment #19 from Holger Macht)

> Most issues people might have are plain bugs that need to be fixed. Actually, I
> think that having something by default will put more pressure on people fixing
> the issues, like 'external usb disk is /dev/sdc after resume and has been
> /dev/sda before'.

Well, I would not call these "plain bugs", sir :-). 

By setting this feature as default, you are (arbitrarily) exposing your users
to a data loss, data corruption or even hardware failure if they are forced to
"button-reset" the machine.

Of course bugs have to be filled when problem arises, but keep in mind: data
cannot always be recovered! And you know, don't tell users about their backup,
as they even know it exists something called "backup" ;-)

While I agree that suspending the machine (at some scenarios, with certain
hardware and always triggered -manually or automatically- by a user / root
decision) and having this feature working in opensuse are both good ideas, in
no ways making this the default setup is a good idea (just my understanding).

> So I think we'll keep this setting for openSUSE and SLED, and will disable it
> for SLES. If comment 14 still applies. And we'll try to fix all related bugs.
> If they're too severe, we still can revert it for openSUSE.

Can you elaborate that statement, please? :-)

Are you telling us that having a default feature for suspending "SLES servers"
is not a good idea but seems to be the right approach for "openSUSE servers"?
>:-)

(In reply to comment #20 from Carlos Robinson)
> Should I remind you that I opened a bug about this change drom sda to sdc about
> a year ago and it was closed as "INVALID"?  >:|

Do you have the bug id, please?

(In reply to comment #21 from Camaleon --)
> Are you telling us that having a default feature for suspending "SLES servers"
> is not a good idea but seems to be the right approach for "openSUSE servers"?
> >:-)

Actually, yes. openSUSE does not have one specific target group, it's somewhere in the middle. And in my opinion, it is/should be rather designed for desktop use. People using openSUSE for server use have to tweak it anyway.

(In reply to comment #22 from Holger Macht)
> (In reply to comment #20 from Carlos Robinson)
> > Should I remind you that I opened a bug about this change drom sda to sdc about
> > a year ago and it was closed as "INVALID"?  >:|
> 
> Do you have the bug id, please?

[Bug 343874

I also ran into this, and it took me a while to understand what was
going on.

One thing that is really, really missing is a simple entry in
/var/log/messages indicating *why* the system is suspending.

Something like

  Nov  1 02:30:33 rana gp: Suspending to RAM due to EnergyStar compliance.
  Nov  1 02:31:00 rana gp: You can change this setting via gnome-power-manager or kpowersave.

That would have saved me quite some scratching and waste of time to track
this down.


Reopening to get this addressed.

  

(In reply to comment #24 from Gerald Pfeifer)
> I also ran into this, and it took me a while to understand what was
> going on.
> 
> One thing that is really, really missing is a simple entry in
> /var/log/messages indicating *why* the system is suspending.
> 
> Something like
> 
>   Nov  1 02:30:33 rana gp: Suspending to RAM due to EnergyStar compliance.
>   Nov  1 02:31:00 rana gp: You can change this setting via gnome-power-manager
> or kpowersave.
> 
> That would have saved me quite some scratching and waste of time to track
> this down.
> 
> 
> Reopening to get this addressed.

Thankyou!

I said this from day one!

http://lists.opensuse.org/opensuse-factory/2008-10/msg00512.html

I hope that now you people (novell) start to understand our (users) problem.

(In reply to comment #1 from Holger Macht)
> Yes, it is a requirement. And now that more and more Desktop systems become
> capable of doing a suspend to RAM, it might become an issue. Maybe we should at
> least add it to the release notes?
> 
> If you're interested, please see
> http://www.energystar.gov/ia/partners/product_specs/program_reqs/Computer_Spec_Final.pdf:
> (3) Power Management Requirements
> 

That spec is a requirement for machines, not software alone. You can not certify openSUSE for compliance in any case, even if included on any machine; and if bundled, only SLES or SLE is certifiable.


The spec says, for example:

User Information Requirement: In order to ensure that purchasers/users are properly informed on the benefits of power management, the manufacturer will include with each computer, one of the following:
• Information on ENERGY STAR and the benefits of power management in either a hard copy or electronic copy of the user manual. This information should be near the front of the user guide; or
• A package or box insert on ENERGY STAR and the benefits of power management.
Either option must at least include the following information:
• Notice that the computer has been shipped enabled for power management and what the time settings are; and
• How to properly wake the computer from Sleep mode;


All that information is missing.


It also says:

+++
Power Management Requirements

Shipment Requirement: Products must be shipped with the display’s Sleep mode set to activate within 15 minutes of user inactivity. All products, except for desktop-derived servers which are exempt from this requirement, must be shipped with a Sleep mode which is set to activate within 30 minutes of user inactivity. Products may have more than one low power mode but these proposed criteria address Sleep mode as defined in this specification. Computers shall reduce the speed of any active 1 Gb/s Ethernet network links when transitioning to Sleep or Standby.
++-

So, mine is a "desktop-derived servers" and therefore is exempt. I hope you propose to ad to yast a configuration during install so that users enter the classification of their machine so that the defaults configurations are modified to comply with above, ie, exempt servers.

Once done, please prepare a release notes snippet.

(In reply to comment #26 from Carlos Robinson)
> That spec is a requirement for machines, not software alone. You can not
> certify openSUSE for compliance in any case, even if included on any machine;
> and if bundled, only SLES or SLE is certifiable.

I never ever said that any of our distributions is Energy Star compliant. I also already stated somewhere else (where you are also the reporter of the bug) that we cannot do this because of the hardware dependencies. Please listen.

Rodrigo, it's about letting the user know that the system autosuspended. The proposal was to add it to /var/log/messages. I this that instead of showing such a warning, couldn't we show a libnotify bubble saying something like:

"The system just resumed from an automatic suspend", and a button like there is also in other places of g-p-m, "don't show me again"?

(In reply to comment #22 from Holger Macht)

> Actually, yes. openSUSE does not have one specific target group, it's somewhere
> in the middle. 

I have to disagree, sir, because it does. We (admins) choose the target we (admins) want for our systems and install opensuse accordingly.

> And in my opinion, it is/should be rather designed for desktop
> use. 

I guess we are not in the same boat or maybe we are talking on different operating systems... Are you telling we should avoid installing opensuse in our servers but it's o.k. in our desktops? :-/

> People using openSUSE for server use have to tweak it anyway.

Same tweak that SLES admins have to perform on their systems. No more, no less. You are making the difference, so please, specify "why".
 

(In reply to comment #1 from Holger Macht)

> Yes, it is a requirement. 

A requirement by "who", "why" or "what"? "Who" or "what" requires a machine to suspend on AC power?

> And now that more and more Desktop systems become
> capable of doing a suspend to RAM, it might become an issue. Maybe we should at
> least add it to the release notes?
> 
> If you're interested, please see
> http://www.energystar.gov/ia/partners/product_specs/program_reqs/Computer_Spec_Final.pdf:
> (3) Power Management Requirements

This information about Energy Star only applies to Energy Star compliant systems (hardware and software). If opensuse cannot be complaint to that standard (as per your comment #28), I cannot see your point to embrace or force a "by default setup" to achieve this.

(In reply to comment #30 from Camaleon --)
> (In reply to comment #22 from Holger Macht)
> I guess we are not in the same boat or maybe we are talking on different
> operating systems... Are you telling we should avoid installing opensuse in our
> servers but it's o.k. in our desktops? :-/

No, definitely not. I think it should be most suited for desktop, in it's default configuration. And I also wrote that that's _my personal opinion_.

(In reply to comment #31 from Camaleon --)
> A requirement by "who", "why" or "what"? "Who" or "what" requires a machine to
> suspend on AC power?

The Energy Star specification.

> This information about Energy Star only applies to Energy Star compliant
> systems (hardware and software). If opensuse cannot be complaint to that
> standard (as per your comment #28), I cannot see your point to embrace or force
> a "by default setup" to achieve this.

But we could try to come as close as possible, so that systems which fulfill the hardware requirements could, theoretically, just be labeled accordingly.

But please stop this discussion here, it doesn't lead anywhere. And don't get me wrong, I really much appreciate this input/discussion, because that's what we need in openSUSE. It's just not our decision in this specific case. Thanks.

Let's do the loo(In reply to comment #29 from Holger Macht)
> Rodrigo, it's about letting the user know that the system autosuspended. The
> proposal was to add it to /var/log/messages. I this that instead of showing
> such a warning, couldn't we show a libnotify bubble saying something like:

Sounds like a nice idea to add.  Please let's do the logging in any case,
though!

(In reply to comment #32 from Holger Macht)
> 
> But please stop this discussion here, it doesn't lead anywhere. And don't get
> me wrong, I really much appreciate this input/discussion, because that's what
> we need in openSUSE. It's just not our decision in this specific case. Thanks.
> 

It doesn't lead anywhere because you have already decided and you are not going to listen. I take it that Novell does not care about what users think and want.

Nice. :-/

Wouldn't it be an option to have a energy-star package which changes the different settings to be enery-star compliant. It can may get installed by default, but the user have the option to remove it and the setting would be the default one of the packages (and the system would work as the users expect or as the users know the system from the last release). 

Btw. (my personal opinion): I don't like the idea to autosuspend the system without the user enabled it. I have now to change after each new installation the settings for the user(s) and root to prevent unexpected suspend. An extra package would allow me to change the settings by removing it from the installation.              

The most annoying thing is that root is not able to disable this behavior for ALL users in a simple and quick way.

A pop up and a log message is not enough, because this things will be read after the suspension (actually hibernation).

Solution?

1) Do not enable it as default.
or
2) add a yast module to disable it for all users at once, and a notification after (welcome dialog) or during the install to warn the user about it (a simple paragraph in the release notes is not enough)

(In reply to comment #36 from Sergio Gabriel)
> The most annoying thing is that root is not able to disable this behavior for
> ALL users in a simple and quick way.

Actually, it's even easier than what I thought: go in the power management preferences (gnome-power-preferences, iirc), change the first slider in the first tab, and click "make defaults". It only works with the packages in GNOME:Factory right now since a few fixes were required to make it work. But as soon as the submissions get accepted, it will hit Factory.

(In reply to comment #28 from Holger Macht)
> (In reply to comment #26 from Carlos Robinson)
> > That spec is a requirement for machines, not software alone. You can not
> > certify openSUSE for compliance in any case, even if included on any machine;
> > and if bundled, only SLES or SLE is certifiable.
> 
> I never ever said that any of our distributions is Energy Star compliant. I
> also already stated somewhere else (where you are also the reporter of the bug)
> that we cannot do this because of the hardware dependencies. Please listen.


Of course I listen, but I'm afraid you don't.


I'm all in favour of energy savings. I have been using Energy Star features since before SuSE existed. I was thrilled when SuSE suddenly was able to hibernate my machine, and I have used it since then several times a day, even before the desktop was able to trigger it. I always recommend people to try hibernation: it is faster than booting, saves effort in starting all apps on the desktop, and saves energy. 

But I'm also against forcing the user, specially when it is dangerous for him.


The original reporter said:

> # Enable Energy Star compliant default configuration

and you said:

> Yes, it is a requirement.

Thus, the excuse for this default configuration is to be compliant with Energy Star - but software alone can not be compliant. To be compliant you have to pass a certification and complete tests, for the combination of hardware and software. This is not possible for openSUSE, so the above is just an excuse.


My points are:

 a) You must remember that such a default is dangerous before the machine is tested. Some machines crash when suspending or hibernating; some will "simply" loose data. This will cause users to be very pissed against Novell.

 b) It is a mistake, can cause damage and lost data, to configure a user's desktop, without the owner prior knowledge and permission, to suspend or hibernate. Before the user of a machine, or the vendor/supplier of the software (Novell), is allowed to configure autosuspend/autohibernate, the owner of the machine has to explicitly allow this configuration change.

 c) Before permitting a desktop to allow suspend/hibernate, during installation and later in YaST, the admin must be asked whether to permit it, or not permit it, or even force it. He is the person that knows whether the machine withstands the cycle, and what's the intended usage of the machine. For example, a server, even a home server, must never suspend or hibernate automatically.

 d) If the real intend is to conserve energy, then KDE must have this behaviour too, and the CLI, and the entire machine, even more when nobody is logged in. Not only when somebody is logged in GNome. Or is it your intend that openSUSE users act as guinea pigs for SLED, which uses gnome as default, and thus "forgive" kde users?

 e) You have to test first how services like apache, samba, etc, behave. The configuration change makes my machine hibernate, meaning that all network connections are killed.

 f) You also have to test how all possible configurations with external devices (usb, firewire, etc) survive: printers (what about cups printing a long job!), scanners (I bet you will find that xsane has to be restarted), disk devices (regardless of how they are mounted, not only mounted via gnome (they can be mounted by another user)), etc.

 g) Consider that the complains you are seeing are just a sample of what you will see once normal users find out. Till now only betatesters are aware, and we are more forgiving and prepared than most users.

    Or perhaps you do know, and thus you test first on gnome. 
    Kde users are a rougher crowd, already pissed because of 
    the KDE 4 "situation"  >:-P


My propossal is:

 a) That you (Novell) remove this default setting this time. Ie, delay it.
 b) Create a YaST module to configure the behaviour of the entire system:
     1) prohibit/allow suspend/hibernation system wide
     2) define default behaviour system wide.
     3) prohibit/allow users to change the default behaviour.
 c) Obviously, events must be logged.

I'm afraid you (Novell) will discard my proposal without consideration, and that my valuable time was wasted. Therefore, then at least:

 a) warn root during installation.
 b) provide at least a script to disable the default configuration 
    of autosuspend/hibernate.
 c) warn the users on the welcome window, that is, way before the actual act.
 d) pop a window in advance, and log the event.

Thank you!

We have _not_ set this in stone. Your assumption is wrong. If there are problems associated with saving power - and even problems that may cause data loss, we rather save data than power.

The autosuspend needs to be disabled by default, because with autosuspend enabled, simple POSIX functionality is broken. From 1970 on, "sleep 8h; echo ^G" produced beep after 8 hours. POSIX guarantees this should work. These defaults break it.

Following Energy Star would be nice, but we can't do it because of the POSIX stuff. You can try to use my "Sleepy Linux" patches to get this right (detect machine idleness at kernel level and set RTC wakeup accordingly), but that is not opensuse11.1 or SLE*11 material.

Before that happens, autosuspend can't be enabled by default.

Hey, folks!

Has somebody thought what happens to "cron" and "at" jobs while suspended/hibernated automatically?

Obviously, if the user decides to suspend, it is his responsibility, but if the system decides to suspend/hybernate, then the system is responsible and must wake up in time.

It would be a nice feature to have, though. Meanwhile... autosuspend can't be the default.

This problematic in a few cases. AFAIK we still eject PC-Cards when we suspend.
This will kill any tasks with open fds for them and may lead to data loss if
a block device is connected this way.

It seems to me that it should be disabled if the system has any PC-Card or
PCMCIA-card plugged in.

You have all the same problems when suspending and running on battery power. You can also not expect users to know that they should not hotplug a device when they do a suspend manually. Some use cases need to be solved in the desktop (unmounting, warning, etc.) and some in the kernel (/dev/sda must not change to /dev/sdc during suspend without a hotplug).

(In reply to comment #42 from Oliver Neukum)
> This problematic in a few cases. AFAIK we still eject PC-Cards when we suspend.
> This will kill any tasks with open fds for them and may lead to data loss if
> a block device is connected this way.
> 
> It seems to me that it should be disabled if the system has any PC-Card or
> PCMCIA-card plugged in.
> 

Or external media on USB. I have demonstrated that it breaks and data can be lost (Bug 439663).

But that suspend doesn't happen without warning. You either trigger it, or the
battery's charge would lead to uncontrolled stopage.

And yes, it is probably bad not to warn about block devices on PCMCIA, but it's
not as bad and badness is no reason to add badness.

[regarding #44]
That should work and looks like a kernel bug. Let's get it fixed. However if it is on PCMCIA we will fail for principal reasons.

(In reply to comment #40 from Pavel Machek)
> The autosuspend needs to be disabled by default,


Yes, at least on it's current incarnation.

(In reply to comment #38 from Carlos Robinson)
> (In reply to comment #28 from Holger Macht)
> > (In reply to comment #26 from Carlos Robinson)
> > > That spec is a requirement for machines, not software alone. You can not
> > > certify openSUSE for compliance in any case, even if included on any machine;
> > > and if bundled, only SLES or SLE is certifiable.
> > 
> > I never ever said that any of our distributions is Energy Star compliant. I
> > also already stated somewhere else (where you are also the reporter of the bug)
> > that we cannot do this because of the hardware dependencies. Please listen.
> 
> 
> Of course I listen, but I'm afraid you don't.
> 
> 
> I'm all in favour of energy savings. I have been using Energy Star features
> since before SuSE existed. I was thrilled when SuSE suddenly was able to
> hibernate my machine, and I have used it since then several times a day, even
> before the desktop was able to trigger it. I always recommend people to try
> hibernation: it is faster than booting, saves effort in starting all apps on
> the desktop, and saves energy. 
> 
> But I'm also against forcing the user, specially when it is dangerous for him.
> 
> 
> The original reporter said:
> 
> > # Enable Energy Star compliant default configuration
> 
> and you said:
> 
> > Yes, it is a requirement.
> 
> Thus, the excuse for this default configuration is to be compliant with Energy
> Star - but software alone can not be compliant. To be compliant you have to
> pass a certification and complete tests, for the combination of hardware and
> software. This is not possible for openSUSE, so the above is just an excuse.
> 
> 
> My points are:
> 
>  a) You must remember that such a default is dangerous before the machine is
> tested. Some machines crash when suspending or hibernating; some will "simply"
> loose data. This will cause users to be very pissed against Novell.
> 
>  b) It is a mistake, can cause damage and lost data, to configure a user's
> desktop, without the owner prior knowledge and permission, to suspend or
> hibernate. Before the user of a machine, or the vendor/supplier of the software
> (Novell), is allowed to configure autosuspend/autohibernate, the owner of the
> machine has to explicitly allow this configuration change.
> 
>  c) Before permitting a desktop to allow suspend/hibernate, during installation
> and later in YaST, the admin must be asked whether to permit it, or not permit
> it, or even force it. He is the person that knows whether the machine
> withstands the cycle, and what's the intended usage of the machine. For
> example, a server, even a home server, must never suspend or hibernate
> automatically.
> 
>  d) If the real intend is to conserve energy, then KDE must have this behaviour
> too, and the CLI, and the entire machine, even more when nobody is logged in.
> Not only when somebody is logged in GNome. Or is it your intend that openSUSE
> users act as guinea pigs for SLED, which uses gnome as default, and thus
> "forgive" kde users?

I can confirm: yes, also KDE 3.5.10 in openSUSE 11.1 Beta 3 shows this odd behaviour. (I am using a notebook Fujitsu-Siemens, 32-bit architecture.) After resuming from the suspend (or hibernate???) the mouse pointer does not move.

> 
>  e) You have to test first how services like apache, samba, etc, behave. The
> configuration change makes my machine hibernate, meaning that all network
> connections are killed.
> 
>  f) You also have to test how all possible configurations with external devices
> (usb, firewire, etc) survive: printers (what about cups printing a long job!),
> scanners (I bet you will find that xsane has to be restarted), disk devices
> (regardless of how they are mounted, not only mounted via gnome (they can be
> mounted by another user)), etc.
> 
>  g) Consider that the complains you are seeing are just a sample of what you
> will see once normal users find out. Till now only betatesters are aware, and
> we are more forgiving and prepared than most users.
> 
>     Or perhaps you do know, and thus you test first on gnome. 
>     Kde users are a rougher crowd, already pissed because of 
>     the KDE 4 "situation"  >:-P
> 
> 
> My propossal is:
> 
>  a) That you (Novell) remove this default setting this time. Ie, delay it.
>  b) Create a YaST module to configure the behaviour of the entire system:
>      1) prohibit/allow suspend/hibernation system wide
>      2) define default behaviour system wide.
>      3) prohibit/allow users to change the default behaviour.
>  c) Obviously, events must be logged.
> 
> I'm afraid you (Novell) will discard my proposal without consideration, and
> that my valuable time was wasted. Therefore, then at least:
> 
>  a) warn root during installation.
>  b) provide at least a script to disable the default configuration 
>     of autosuspend/hibernate.
>  c) warn the users on the welcome window, that is, way before the actual act.
>  d) pop a window in advance, and log the event.
> 
> Thank you!
> 

@Martin: Please don't make (useless) fullquotes in bugzilla.

What kind of info is needed here? AFAIK conclusion is pretty straightforward: autotsuspned in g-p-m is not mature enough to be enabled by default.

*** Bug 431295 has been marked as a duplicate of this bug. ***

Ok, decision was made, even if late. Autosuspend will be disabled in Beta5. Finally closing.

=Comment: #0=================================================
Jeremy M. Savoy <jsavoy@us.ibm.com> -
---Problem Description---
Machine:  HS21XM Mongoose
Processors:  2 @ 3.0 Ghz (Quad Core Harpertown)
Memory:  4 GB
System BIOS:   BAE145A
System BMC:    BABT49A
System Diags:  BAYT36A
AMM:            BPET34E
Operating System:  SLES11 Beta1   x86_64

Hardware Setup: HS21XM w/ following options
cKVM
4GB uDOC (39R8697)
BladeCenter FC Expansion Card SFF 26K4841

Problem: HS21XM powers off unexpectedly under stress while running SLES11 Beta1 64bit.

I have an HS21XM with two Harpertown CPU packages installed in it.  This blade
is running in a BladeCenterH Chassis.  The ESW on the blade and the AMM are
recorded above (all are probably slightly backlevel).  SLES11 Beta1 64bit
was installed on the blade successfully.  The autoscript generator and TUX was
then started on the blade (along with a client mounting the blade for network
traffic).  All looked normal.  I then checked on the HS21XM about an hour
later and noticed that it was powered off.

The same thing also happened on Crichton and Groucho (which were installed in a BladeCenterE).  A
look at the management module logs just show a simple "blade powered off" message, with nothing ugly
before or after.

Also seen on big Lewis, little Lewis, Morrison and Defiant.

Setting the Power Management to never and disabling the screen saver seems to get around this.

Contact Information = Jeremy Savoy jsavoy@us.ibm.com

---uname output---
SLES 11 Beta 1 (don't have specific uname info with me)

Machine Type = HS21XM

---System Hang---
The system is completely powered off

---Steps to Reproduce---
Install SLES 11 Beta1 64 bit on any of the hardware mentioned in the problem description, then log
in and let the unit sit. After the power management settings kick in, the unit powers off and must
be cold booted.

---Not Yet Classified Component Data---
=Comment: #2=================================================
Jeremy M. Savoy <jsavoy@us.ibm.com> -
This bug can be seen on any hardware available to you ... just install SLES 11 Beta1 64-bit and then
start the OS in runlevel 5 and wait a bit and the machine will power off. Setting the screensaver to
"Never" turn on fixes this issue.

It seems as though the machine may try to go to sleep, but then cannot be brought out of that state.
=Comment: #3=================================================
Jonathan R. Thomas <jon.thomas@us.ibm.com> -
Can you clarify does the machine power off or just freeze/hang?
=Comment: #4=================================================
Jeremy M. Savoy <jsavoy@us.ibm.com> -
I suspect that the machine is being put into sleep mode and then can't recover, it does not appear
"hung" but powered off. You can easily reproduce this issue on any machine and see the behaviour.

------- Comment From jrthomas@btv.ibm.com 2008-10-01 11:28 EDT-------
https://bugzilla.linux.ibm.com/mirrorproxy.cgi?distro=novell&eid=431295

------- Comment From jsavoy@us.ibm.com 2008-10-01 13:23 EDT-------
More specifically, if you go into "Control Panel" and select "Screensaver" then select "Power Management", then set the computer to "Never" be put to sleep - if you do this, the defect does not occur.
------- Comment From jon.thomas@us.ibm.com 2008-10-01 11:28 EDT-------


I suspect this came from the energy star patch, since this is fixed in b2.  Rodrigo?

------- Comment From jsavoy@us.ibm.com 2008-10-09 15:49 EDT-------
Novell has disabled by default power managment which would put the machine into sleep mode after a period of inactivity. So this doesn't actually fix the problem, it only prevents it from occurring.

If you re-enable the sleep function, your machine will power off, and when you reboot you get an error stating that the machine could not be put into suspend.

I think we need the suspend long Danny?

Yes. (Seife can tell you more if you have the logs)

please attach /var/log/pm-suspend.log after the machine had powered off.

Ok. The machine is autosuspending. Because it can not suspend to RAM, it does suspend to disk, which works perfectly and actually resumes fine.

So there is no suspend error :-)

The problem is
a) it is autosuspending at all
b) it is showing the suspend error even though it suspended just fine.

These are two bugs, that are already logged, however, I don't know their numbers offhand. I'll take the people who know more about those into CC:

Will be fixed in Beta5.

*** This bug has been marked as a duplicate of bug 439018 ***

Created attachment 250713 [details]
Here is the requested log ....

------- Comment From vant@us.ibm.com 2008-11-07 13:39 EDT-------
I have installed 32 bit Sles11.beta4 with the storage setup. While system is running IO test about an hour later, the system power off by itself. I am not sure that we are talking the same symptom here or not.. Please advice.

I think we do. Bug 431295 was about "HS21XM powers off after a period of inactivity", and this will be fixed in beta5. If there is another issue that the system recovers from sleep and is showing an erro message, this should go into a new bug. It should also be reproducible with manually triggering a hibernation/sleep.

------- Comment From jsavoy@us.ibm.com 2008-11-17 11:52 EDT-------
The issue still exists in Beta 5. When you set the computer to go to sleep after a period of time, instead it goes to hibernate.

Doesn't it only go to hibernate (suspend to disk) if suspend (suspend to ram) is not available, or also if suspend is available. Anyway, this is a different issue.

------- Comment From jsavoy@us.ibm.com 2008-11-17 13:14 EDT-------
This is the same issue, the only thing that has changed is that Novell changed the timeout to "go to sleep" from <scrennsaver_timeout> + 1, to NEVER.

When you manually set "go to sleep" to occur, the machine powers off in hibernate instead of going to sleep - this is the same issue.

(In reply to comment #59 from LTC BugProxy)

> When you manually set "go to sleep" to occur, the machine powers off in
> hibernate instead of going to sleep - this is the same issue.

No, that's Bug #440410, but it doesn't have any activity.

------- Comment From jsavoy@us.ibm.com 2008-11-18 09:00 EDT-------
Then these two bugs may be duplicates, however when I search for bug 440410 I get an error saying that bug does not exist, not sure if I'm doing something wrong?

If you take the time to read this bug's original bug entry, the symptoms we saw were caused by the system going into hibernate instead of suspend, that is the root cause of the issue and we have known that since before we reported the bug, again see the initial bug entry for details.

The fact that Novell has disabled this function by default by setting the power management to "Never" suspend does not fix the root cause of this issue.

We are ok with marking this bug as duplicate if there is another bug against the root cause.

(In reply to comment #61 from LTC BugProxy)
> ------- Comment From jsavoy@us.ibm.com 2008-11-18 09:00 EDT-------
> Then these two bugs may be duplicates, however when I search for bug 440410 I
> get an error saying that bug does not exist, not sure if I'm doing something
> wrong?

I'm getting the impression that somehow you are not looking at bugzilla properly. You should see an hiperlink on the word "bug 440410"; clicking on it should take you directly to the report. If you can't see it, click here instead:

https://bugzilla.novell.com/show_bug.cgi?id=440410


> If you take the time to read this bug's original bug entry, the symptoms we 
> saw were caused by the system going into hibernate instead of suspend, 
> that is theroot cause of the issue and we have known that since before 
> we reported the bug, again see the initial bug entry for details.
> 
> The fact that Novell has disabled this function by default by setting the
> power management to "Never" suspend does not fix the root cause of this 
> issue.
> 
> We are ok with marking this bug as duplicate if there is another bug against
> the root cause.

Because of what you say I have the feeling you are not seen bugzilla properly. The original report is not yours, but from Magnus. 

Click here to see it: Comment #0
And if that is not an hyperlink on your viewer, then clik here (or paste into a browser): 

https://bugzilla.novell.com/show_bug.cgi?id=439018&GoAheadAndLogIn=1#c0

Your first report goes as Comment #53 in this Bugzilla, and I must thank you for it :-)

------- Comment From jsavoy@us.ibm.com 2008-11-18 12:24 EDT-------
I see, seems like we are having bug mirroring issues, or that my IBM LTC bugzilla was mirrored into your existing bug.

I was speaking purely of my IBM LTC Bugzilla report, of which I was the author and therefore my comment was the first one :-)  I failed to realize that my IBM LTC bugzilla apparently was mirrored into an existing Novell Bugzilla and apologize for the confusion.

Ok, so what can we do to move forward? Obviously you can set "go to sleep" to "Never" and that prevents the issue but does not fix the root cause. Is there any effort going forward to try and understand why "sleep" is not working?

I guess sleep is simply not working because it's not available on this desktop machine. So it falls back to hibernate as "sleep method". If you like, you can create another bugreport for this.

------- Comment From vant@us.ibm.com 2008-11-19 12:31 EDT-------
Jus for your info. I am still having the servers shutdown with  Sles11.beta5 kernel on i386 and x86_64 platforms while running files system for about 24hrs. When do I expect this problem resolse ?

This should be fixed in Beta5 already. Did you do an update or a fresh install? An update would have kept your user configuration unchanged. Do you run a GNOME desktop at all?

------- Comment From vant@us.ibm.com 2008-11-21 13:11 EDT-------
I performed the upgrade instead of the fresh install. How can I fix if I use the desktop GNOME ? Please advice. Thanks.

Computer -> Control Center -> Power Management -> Put computer to sleep when inactive for:

------- Comment From jsavoy@us.ibm.com 2008-12-02 09:52 EDT-------
Novell has simply avoided the bug by setting the machine to never go to sleep by default. If you change this setting, the machine will go into hibernate because it fails when it goes into Sleep state.

I do not agree with this resolution, but from their bugzilla report they do not intend to work the root cause.

But this bug is not about this issue. This bug is about why the system suspends at all when running on AC. Please open another bug for you issue and put me into CC. Thanks.

------- Comment From jsavoy@us.ibm.com 2008-12-02 10:37 EDT-------
Going into suspend is not a bug, it is a setting.

The root cause of this bug as I have reported the entire time is that the machine (and all machines we have tested) fail to suspend but instead go into hibernate. You can see this through out any update I have made to this bug which I opened.

It was probably not mirrrored correctly, and the title could have been changed to better reflect the problem once we understood the root cause - but that does not change the problem determination and root cause which we have known for quite some time.

This bug was created by:
Reporter:   	 Magnus Boman <captain.magnus@opensuse.org>

And the main reasoning in the initial description is:
"Is it really a requirement to suspend the computer if it's on AC? This
obviously happens regardless if it's a Desktop or Laptop."

That's not about if it's doing hibernate or suspend, just about that it does anything when being AC powered. Please open a new report.

(In reply to comment #71 from LTC BugProxy)
> ------- Comment From jsavoy@us.ibm.com 2008-12-02 10:37 EDT-------
> Going into suspend is not a bug, it is a setting.
> 
> The root cause of this bug as I have reported the entire time is that the
> machine (and all machines we have tested) fail to suspend but instead go into
> hibernate. You can see this through out any update I have made to this bug
> which I opened.
> 
> It was probably not mirrrored correctly, and the title could have been changed
> to better reflect the problem once we understood the root cause - but that does
> not change the problem determination and root cause which we have known for
> quite some time.
> 

Please have a look here for an explanation:

<https://bugzilla.novell.com/show_bug.cgi?id=439018#c62>

IMO, you are reporting the problem in the wrong place. Novell/suse people (and plain opensuse reporters/users/testers, like me) see and use bugzilla numbers, and the issue you comment is a different issue, reported on another number (see link above).

You do have a problem with the mirroring of issues at both places.

Also, please remember that this bug is public and many people are reading it ;-)

------- Comment From jsavoy@us.ibm.com 2008-12-02 13:01 EDT-------
My previous comments were meant for IBM LTC, and I was referencing the IBM LTC Bugzilla report which I opened and which was mirrored to Novell.

Please disregard those comments as they were not meant for you. Next time I will check the "Internal Only" box, which I did not see before, so that my comments will be seen by the appropriate folks.

------- Comment From jrthomas@btv.ibm.com 2008-12-02 14:56 EDT-------
I think what happened here was this bug was mirrored to

https://bugzilla.novell.com/show_bug.cgi?id=431295

Which was marked a dup of

https://bugzilla.novell.com/show_bug.cgi?id=439018

which appears to be not the same bug.

At the Novell Bugzilla, there are these:

Bug 440410 - Machine auto hibernates to disk, not memory.
https://bugzilla.novell.com/show_bug.cgi?id=440410

That is the problem you are _really_ complaining about, and has not seen any activity since it was reported by myself a month ago.


But your current reports are going to _this_ other one, at the Novell Bugzilla, and is about a different issue:

Bug 439018 - g-p-m suspends desktop (and without any warning/indication to the user)
https://bugzilla.novell.com/show_bug.cgi?id=439018


And then, there is Novell Bug 431295, which I'm forbidden access, I don't know what it is about.


I have no idea how you folks at Ibm and Novell are mirroring your respective bug services, but, in my opinion, you should look directly at the Novell Bugzilla bypassing the mirror service, at least this once ;-)

------- Comment From vant@us.ibm.com 2008-12-08 21:12 EDT-------
I had a new install Sles11.beta5 and having the system running ok. After I upgraded to Sles11..i586 beta6. I start seeing the system x345-8670-71X shutdown while I have IO running.

I also have seen similar issue with the new install Sles11._x86_64.beta6 on the system x346-8840-31U. But this system shutdown and reboot by  itself. I am not quite sure this should be the same bug or not.  Note this system know to work ok with Sles11.beta5.

Another note. I did set Action/Display to Never on the ScreenSaver - Power managerment preferences on these systems.

Please advice.

Thanks.

------- Comment From jsavoy@us.ibm.com 2009-01-30 11:32 EDT-------
Novel has set power management options to "never" suspend the machine, so you do not see this bug in that case.

------- Comment From vant@us.ibm.com 2009-02-03 13:39 EDT-------
I have removed from this project. Thanks.

This is an autogenerated message for OBS integration:
This bug (439018) was mentioned in
https://build.opensuse.org/request/show/3568 Factory / gnome-power-manager