Crash on laptop lid close

On a fresh install of openSUSE 12.3 on my Dell Latitude D505, the machine crashes when I close the laptop lid. The strange thing is that all other power management functions work:

[ul]
[li]In the “System Settings / Power Management” dialog (opened using the confusingly named “Configure Desktop” entry in the Start Menu) I can:[/li][LIST]
[li] Configure “Suspend Session” to enter sleep mode after a fixed timeout, and this works fine. [/li][li]Configure the system to sleep when the power button is pressed, and it also works fine. [/li][li]Set it up to enter hibernation instead of sleep in the scenarios above, and it also works. [/li][/ul]

[li]I can regulate screen brightness using the Fn + Arrow Up/Down keys. [/li][/LIST]

Configuring it to “Do nothing” on laptop lid close does not solve the problem.

When the lid is closed, the screen blanks, but the backlight remains on, and the machine freezes (including SSH sessions from other machines). This state persists even if the lid is opened. The only remedy is to power down the machine (by holding the power button).

This is a regression - on 12.2 all laptop power management functionality worked beautifully.

I considered filing a bug report about this, but since I haven’t found any information that might be useful for pinpointing the problem (no log entries are written on the crash) I decided to try the forums instead.

Does anyone have an idea how to solve this?

I’m not going to be of any help here but I also have the very same issue. All power and shutdown functions seem to work perfectly apart from when I close the lid. On opening it back up the screen will start flashing black/white. The only way out of the sequence is to hold the power button until it shuts down. This is Opensuse 12.3 running on a HP Probook 4525s (ATI Radeon).

Andy.

Try adding

acpi_osi=linux

to the boot options.

I’m having the same issue, so I was wondering two things; 1 did this solve the issue for you, and 2 how does one add the code to the boot options?

In response to where to add boot options:

Navigate to /etc/default/grub and add “acpi_osi=linux” (without quotes) to the line “GRUB_CMDLINE_LINUX_DEFAULT”.

I want to add “acpi_osi=linux” as you said to do but I already have the following in that line:

“resume=/dev/disk/by-id/ata-ST9320320AS_5SX575EQ-part6 splash=silent quiet showopts”

It is there with the quotes.

Where do I add “acpi_osi=linux” and do I need the quotes?

Thanks

No quotes.

I have the same problem: screen flashes and crashes when laptop tries to wake up from suspend or hibernate. I tried the add acpi-option to bootload options as suggested, but it did not solve the problem. From /var/log/messages if found an error message that repeats over and over again. It says

[drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -35!

.

Googling and Duckduckgoing around aLOT and i found this bug report with a fix suggestion from Novell bugzilla:

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

The solution suggests:

Maybe the newer xf86-video-ati.rpm from
Index of /repositories/home:/olh:/12.3/openSUSE_12.3_Update_standard
helps for your issue.

and then

Yes, updated to xf86-video-ati-7.1.0-30.6.i586 and during 3 weeks no issues

I have a HP 6735s laptop with Ati mobility radeon 3200. OpenSuse 12.3. and KDE with the net-installer from yesterday, so everything should propably be quite up to date. So is there any reason to believe that I don’t already have the version 7.1.0-30.6.i586? Or is this something that does not come through the regular update channels. I’m not at my computer at the moment so I’m unable to check it.

I would later like to try the solution described above, but am new to OpenSuse and its packagemanagement. How does one use the programs Yast or zypper to install that particular rpm without breaking the system?

Thank you all for helping out.

I searched the Index of /distribution/12.3/repo and found that it indeed contains the old version of xf86-vide-ati-driver and that there is no newer one in the updates.

There is also another bug report for this issue. Access Denied It doesn’t seem to be related to power management and can be reproduced by switching to console and back to Kde.

Updating to the 12.3 7.1.0 version from the X11:Xorg repository has resolved the issue

…I tried the X11:Xorg repository as recommended … runs fine since one week.

I just installed xf86-video-ati-7.1.0-2.1 from openSUSE:Factory, and both suspend/resume and VT-switching seems to be working now.

As I said in my previous post I’m not quite familiar with the repository system in OpenSuse. What are all these colons in repository names? I undesrstood that the “Factory” is something that is in developement and should not be used. So if the same rpm is available in an “X11:Xorg”-repository should I prefere that? Or should I just wait for the developers to add the new driver to regular updates? That could take a while, seeing that the bug reports and fixes date back to april 2013. And how on earth do I get rid of all these smileys? That one is supposed to be X11 [colon] Xorg.

Those colons seperate namespaces, you can compare it to the ‘/’ in path names.
So there is the ‘X11’ repo, which contains a sub-repo ‘XOrg’ whose full “path name” then would be [noparse]‘X11:XOrg’[/noparse]. (there could also be a ‘XOrg’ repo in a different namespace, [noparse]‘myX11:XOrg’[/noparse] f.e.)

I undesrstood that the “Factory” is something that is in developement and should not be used. So if the same rpm is available in an “X11:Xorg”-repository should I prefere that? Or should I just wait for the developers to add the new driver to regular updates? That could take a while, seeing that the bug reports and fixes date back to april 2013.

Factory is a distribution of its own. It’s where the future 13.1 is developed and is not even beta yet. Also it can break at any time.

NEVER EVER add the Factory repo to an existing openSUSE installation!!!
The packages there are from the same vendor and therefore zypper or the Update applet will happily install them as updates, which will in the worst case result in an incompatible mix of packages from Factory and, say, 12.3.

If you want to try the newer version of the ati driver, you should take the one from the X11:Xorg repo. But you need the newer Xorg from there then as well, otherwise it will not work.

So, add the repo and install ALL packages from there.
There are basically two ways to do that:
1.) Use YaST:

  • Enter YaST->“Software Repositories”, click on “Add”, select “Specify URL” (should be pre-selected) and press “Next”, then enter the following URL: [noparse]http://download.opensuse.org/repositories/X11:/XOrg/openSUSE_12.3[/noparse]
    You can leave the “Name” field blank (a default will then be used) or enter what you like.
    Then press on “Next” again and leave the module with “OK”
  • Enter YaST->“Software Management”, click on “View”->“Repositories”, select your newly added XOrg repo in the list on the left.
    Click on “Switch system packages to the versions in this Repository” just above the package list on the right and click on “Accept”.

2.) Use zypper:
Start a terminal window and enter the following:

sudo zypper ar http://download.opensuse.org/repositories/X11:/XOrg/openSUSE_12.3 X11:XOrg
sudo zypper dup --from X11:XOrg

If you get any conflicts and are not sure what to do, just ask please.

You may wish to disable that repo again after the update, since it is not guaranteed to be 100% stable.

And how on earth do I get rid of all these smileys? That one is supposed to be X11 [colon] Xorg.

Enclose the text in [noparse] tags, or select “Disable graphical Smilies” below the text editor window.

Thank you so much for this explanation. It helped.

I understand namespaces, but maybe just not so well in given context (eg. the repositories). As to why I needed to install the whole XOrg from the new repository instead of just the video-driver maybe wasn’t so clear to me.

Anyhoo, I did as I was instructed (at my own responsibility of course) and lo and behold it seems to work now.

I can Ctrl + Alt + F2/F3/F7 to console and back without a problem. Laptop goes to sleep from menus and from closing the lid, and it wakes up without crashing too.

Setting it to hibernate though, starts the screen flashing maneuver again. But from between the flashes one can see a progress bar on the bottom of the screen. It takes a while but it gets there. Then it shuts down, and resuming from hibernate works without crashing.

I disabled the new repository after the install. Now I only wonder what will happen when there are updates for Xorg through the stable repos. Will the system still keep my current versions form the development repo? Will they be updated when the stable repos versions exceed them? Are version numbers the only thing used to resolve what versions to keep or must I somehow tag my current video-driver to ‘keep’?

Thank you again. I almost went and installed Debian stable, though it seems sleep and hibernate cause trouble through all distros. Hope to stay with Suse for now.

Glad to hear it worked! :slight_smile:

The repo contains a newer Xorg, and the video drivers in that repo are built against that newer Xorg.
That’s why they won’t work with the older version included in openSUSE 12.3.

I disabled the new repository after the install. Now I only wonder what will happen when there are updates for Xorg through the stable repos. Will the system still keep my current versions form the development repo? Will they be updated when the stable repos versions exceed them? Are version numbers the only thing used to resolve what versions to keep or must I somehow tag my current video-driver to ‘keep’?

No. The stable repos won’t get newer versions, that’s part of openSUSE’s policy. The update repo only provides backports of security- and critical bug-fixes, but the versions stay the same.

Also, there’s the concept of “vendor-stickiness” in openSUSE’s update software stack. Packages won’t be changed automatically to a different repo, you have to “force” that.
The official repos are considered equal though, otherwise you wouldn’t get updates at all.
That’s why I gave the warning about the Factory repo. This would be considered equal to the standard oss and update repo as well, so in that case only the version numbers would be taken into account for deciding what to update (and most of them would be higher in Factory, so in effect you would get an unstable system).

It’s great to hear you’re up and running. If you continue to have a problem, please submit a bug report so that the devs know about the model of your laptop.

If openSUSE provides a stable update, you will be prompted by a pop up message asking if you would like to keep your selection or select the patch.

Makes no difference.