[opensuse-factory] s2disk = hibernate issues
Hi! Current TW, wake up from s2disk no longer works. This has been an issue since some days. On wakeup, the login screen appears, but is not responding. It disappears again, comes up again and is responding, I can type my pw. But after log in, plasmashell freezes. Anybody else using s2disk? Regards, Alexander -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Mittwoch, den 25.01.2017, 11:42 +0100 schrieb AW:
Hi!
Current TW, wake up from s2disk no longer works. This has been an issue since some days.
On wakeup, the login screen appears, but is not responding. It disappears again, comes up again and is responding, I can type my pw. But after log in, plasmashell freezes.
Anybody else using s2disk? Which graphics?
The usual culprit is the gfx driver, but we need to rule out user space. Does it crash if you do echo disk > /sys/power/state ? If so, your best option is to bisect the kernel if you are using i915. HTH Oliver -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 25/01/2017 11:48, Oliver Neukum wrote:
Am Mittwoch, den 25.01.2017, 11:42 +0100 schrieb AW:
Hi!
Current TW, wake up from s2disk no longer works. This has been an issue since some days.
On wakeup, the login screen appears, but is not responding. It disappears again, comes up again and is responding, I can type my pw. But after log in, plasmashell freezes.
Anybody else using s2disk?
Which graphics?
The usual culprit is the gfx driver, but we need to rule out user space. Does it crash if you do echo disk > /sys/power/state ?
If so, your best option is to bisect the kernel if you are using i915.
HTH Oliver
I have a similar problem, when I get back from suspend, one of my displays have completely garbled colors. By switching to text console and back to grphics, it is fixed, so it is more annoying than a real problem. I reported the bug, gave the required informations, but so far it has not been fixed. It started as soon as I switched to TW from the Leap. Andrea. -- Andrea "Kontorotsui" Controzzi Contact: +39 392 9989834 - +39 050 644097 Skype: Kontorotsui Settore tecnico / Technical Department - www.LedMania.it ----- LedMania SRL unipersonale Via Galilei 27 56042 Lavoria (PI) P.IVA: 01941970509 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Mittwoch, den 25.01.2017, 11:54 +0100 schrieb Andrea Controzzi - LedMania.it:
I have a similar problem, when I get back from suspend, one of my displays have completely garbled colors. By switching to text console and back to grphics, it is fixed, so it is more annoying than a real
On 25/01/2017 11:48, Oliver Neukum wrote: problem. I reported the bug, gave the required informations, but so far it has not been fixed. It started as soon as I switched to TW from the Leap.
Again, bisection is the best way to get this fixed. Regards Oliver -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 25/01/2017 14:17, Oliver Neukum wrote:
Am Mittwoch, den 25.01.2017, 11:54 +0100 schrieb Andrea Controzzi - LedMania.it:
On 25/01/2017 11:48, Oliver Neukum wrote:
I have a similar problem, when I get back from suspend, one of my displays have completely garbled colors. By switching to text console and back to grphics, it is fixed, so it is more annoying than a real problem. I reported the bug, gave the required informations, but so far it has not been fixed. It started as soon as I switched to TW from the Leap. Again, bisection is the best way to get this fixed.
Regards Oliver
What do you mean by "bisection"? Use Leap kernel? -- Andrea "Kontorotsui" Controzzi Contact: +39 392 9989834 - +39 050 644097 Skype: Kontorotsui Settore tecnico / Technical Department - www.LedMania.it ----- LedMania SRL unipersonale Via Galilei 27 56042 Lavoria (PI) P.IVA: 01941970509 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 25.01.17 14:29 Andrea Controzzi - LedMania.it wrote:
What do you mean by "bisection"? Use Leap kernel?
http://lmgtfy.com/?q=bisect+kernel Johannes
On 25/01/2017 14:31, Johannes Kastl wrote:
On 25.01.17 14:29 Andrea Controzzi - LedMania.it wrote:
What do you mean by "bisection"? Use Leap kernel? http://lmgtfy.com/?q=bisect+kernel
Johannes
Dear Johannes, thanks. It is very clear. Is there a guide to do that on TW? My big problem is that I got this from my first TW installation, so I don't have a good release to be lower version starting point. Best regards, Andrea -- Andrea "Kontorotsui" Controzzi Contact: +39 392 9989834 - +39 050 644097 Skype: Kontorotsui Settore tecnico / Technical Department - www.LedMania.it ----- LedMania SRL unipersonale Via Galilei 27 56042 Lavoria (PI) P.IVA: 01941970509 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday, January 25, 2017 8:40:11 PM CET Andrea Controzzi - LedMania.it wrote:
On 25/01/2017 14:31, Johannes Kastl wrote:
On 25.01.17 14:29 Andrea Controzzi - LedMania.it wrote:
What do you mean by "bisection"? Use Leap kernel?
http://lmgtfy.com/?q=bisect+kernel
Johannes
Dear Johannes, thanks. It is very clear. Is there a guide to do that on TW? My big problem is that I got this from my first TW installation, so I don't have a good release to be lower version starting point.
Best regards, Andrea Johannes,
I have to say that that link was very unprofessional of you. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Mittwoch, 25. Januar 2017, 11:48:06 CET schrieb Oliver Neukum:
Am Mittwoch, den 25.01.2017, 11:42 +0100 schrieb AW:
Hi!
Current TW, wake up from s2disk no longer works. This has been an issue since some days.
On wakeup, the login screen appears, but is not responding. It disappears again, comes up again and is responding, I can type my pw. But after log in, plasmashell freezes.
Anybody else using s2disk?
Which graphics?
The usual culprit is the gfx driver, but we need to rule out user space. Does it crash if you do echo disk > /sys/power/state ?
If so, your best option is to bisect the kernel if you are using i915.
HTH Oliver
Intel graphics, probably i915.
echo disk > /sys/power/state
To do when? Before sending the PC into hibernate?
If so, your best option is to bisect the kernel if you are using i915.
There is a fundamental misunderstanding. I'm a user, and Tumbleweed was supposed to be a »rolling release«. I have no idea how to bisect a kernel. You may say »don't shoot the messenger« and indeed I don't aim at you, but at the Tumbleweed project: - kmail / akonadi crashes since December 16th, there have been a couple of bugreports, see e.g. here: https://bugs.kde.org/show_bug.cgi?id=374734 The state of the KDE development didn't yet allow to take care, the bug still is »unconfirmed«. - s2disk stopped working, not for the first time - plasma used to freeze, maybe this was solved yesterday This is not good enough for a rolling release, given other outages. I really guess that people at Suse do their very best to iron out all the bugs which come from upstream, be it intel or kde. But if a new version of an intel i915 driver is crap or a KDE update unreliable, you can't release it in a rolling release. Kind Regards, Alexander -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday, 25 January 2017 12:25:47 CET AW wrote:
Am Mittwoch, 25. Januar 2017, 11:48:06 CET schrieb Oliver Neukum:
Am Mittwoch, den 25.01.2017, 11:42 +0100 schrieb AW:
Hi!
Current TW, wake up from s2disk no longer works. This has been an issue since some days.
On wakeup, the login screen appears, but is not responding. It disappears again, comes up again and is responding, I can type my pw. But after log in, plasmashell freezes.
Anybody else using s2disk?
Which graphics?
The usual culprit is the gfx driver, but we need to rule out user space. Does it crash if you do echo disk > /sys/power/state ?
If so, your best option is to bisect the kernel if you are using i915.
HTH
Oliver
Intel graphics, probably i915.
echo disk > /sys/power/state
To do when? Before sending the PC into hibernate?
If so, your best option is to bisect the kernel if you are using i915.
There is a fundamental misunderstanding. I'm a user, and Tumbleweed was supposed to be a »rolling release«. I have no idea how to bisect a kernel.
You may say »don't shoot the messenger« and indeed I don't aim at you, but at the Tumbleweed project:
- kmail / akonadi crashes since December 16th, there have been a couple of bugreports, see e.g. here: https://bugs.kde.org/show_bug.cgi?id=374734 The state of the KDE development didn't yet allow to take care, the bug still is »unconfirmed«.
- s2disk stopped working, not for the first time
- plasma used to freeze, maybe this was solved yesterday
This is not good enough for a rolling release, given other outages.
I really guess that people at Suse do their very best to iron out all the bugs which come from upstream, be it intel or kde. But if a new version of an intel i915 driver is crap or a KDE update unreliable, you can't release it in a rolling release.
Kind Regards,
Alexander
echo disk > /sys/power/state would be before hibernation since your terminal wont be working afterwards. from my understanding tumbleweed is expressly for people who have a certain willingness and aptitude to solving small problems, Leap 42.2 is a stable release. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Mittwoch, 25. Januar 2017, 13:56:28 CET schrieb nicholas:
On Wednesday, 25 January 2017 12:25:47 CET AW wrote:
Am Mittwoch, 25. Januar 2017, 11:48:06 CET schrieb Oliver Neukum:
Am Mittwoch, den 25.01.2017, 11:42 +0100 schrieb AW:
Hi!
Current TW, wake up from s2disk no longer works. This has been an issue since some days.
On wakeup, the login screen appears, but is not responding. It disappears again, comes up again and is responding, I can type my pw. But after log in, plasmashell freezes.
Anybody else using s2disk?
Which graphics?
The usual culprit is the gfx driver, but we need to rule out user space. Does it crash if you do echo disk > /sys/power/state ?
If so, your best option is to bisect the kernel if you are using i915.
HTH
Oliver
Intel graphics, probably i915.
echo disk > /sys/power/state
To do when? Before sending the PC into hibernate?
If so, your best option is to bisect the kernel if you are using i915.
There is a fundamental misunderstanding. I'm a user, and Tumbleweed was supposed to be a »rolling release«. I have no idea how to bisect a kernel.
You may say »don't shoot the messenger« and indeed I don't aim at you, but at the Tumbleweed project:
- kmail / akonadi crashes since December 16th, there have been a couple of bugreports, see e.g. here: https://bugs.kde.org/show_bug.cgi?id=374734 The state of the KDE development didn't yet allow to take care, the bug still is »unconfirmed«.
- s2disk stopped working, not for the first time
- plasma used to freeze, maybe this was solved yesterday
This is not good enough for a rolling release, given other outages.
I really guess that people at Suse do their very best to iron out all the bugs which come from upstream, be it intel or kde. But if a new version of an intel i915 driver is crap or a KDE update unreliable, you can't release it in a rolling release.
Kind Regards,
Alexander
echo disk > /sys/power/state would be before hibernation since your terminal wont be working afterwards.
from my understanding tumbleweed is expressly for people who have a certain willingness and aptitude to solving small problems, Leap 42.2 is a stable release.
_Small_problems_? I ask you! A wildly running akonadi server pulled more than 10.000 duplicates of already downloaded emails from different servers and crashed every time I tried to delete them, steadily filling my HD! I felt like the soccerer's apprentice, if you remember the poem. It doesn't lead anywhere but into bad mood to discuss more ore less ugly details of what went wrong. *I can only appeal to the TW team to consider the speed and frequency of the updates, taking into consideration the experiences during the last months.* -- Alexander -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 25.01.17 14:22 AW wrote:
*I can only appeal to the TW team to consider the speed and frequency of the updates, taking into consideration the experiences during the last months.*
I answer to all your previous mails in this thread. You seem to get something fundamentally wrong. SUSE has nothing to do with Tumbleweed, this is done by openSUSE. Of course, SUSE sponsors stuff and has employes working on SLES that also contribute to openSUSE. But this is not a SUSE release. So, if you want to avoid the errors you described, either get involved, write openQA-tests to check for these issue or improve the documentation. Or stop using Tumbleweed, use Leap (or Arch or Gentoo or whatever suits your needs better than Tumbleweed), if you are not willing to help solving these issues. But nevertheless, ranting and demanding things is not helpful, but rather discouraging the volunteers spending their time on openSUSE. Johannes
Am Mittwoch, 25. Januar 2017, 14:30:29 CET schrieb Johannes Kastl:
You seem to get something fundamentally wrong.
Is it wrong to use a distribution, which has been announced as a rolling release, simply as a user and not as a contributor? Or are users, who don't contribute more than occasionally bug reports, wrong, if they complain about the quality of the distribution? -- Alexander -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* AW
Am Mittwoch, 25. Januar 2017, 14:30:29 CET schrieb Johannes Kastl:
You seem to get something fundamentally wrong.
Is it wrong to use a distribution, which has been announced as a rolling release, simply as a user and not as a contributor?
definitely not, but surely lessens one's status when making "quality of" statements. Everyone is welcome and one becomes a "contributor" merely by participating here in a "positive" manner.
Or are users, who don't contribute more than occasionally bug reports, wrong, if they complain about the quality of the distribution?
No, not wrong, but less likely to receive much help when presenting only a negative attitude. Then too, one must possess a somewhat "thick skin". -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 Photos: http://wahoo.no-ip.org/piwigo @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday, 25 January 2017 14:40:26 CET AW wrote:
Am Mittwoch, 25. Januar 2017, 14:30:29 CET schrieb Johannes Kastl:
You seem to get something fundamentally wrong.
Is it wrong to use a distribution, which has been announced as a rolling release, simply as a user and not as a contributor?
Or are users, who don't contribute more than occasionally bug reports, wrong, if they complain about the quality of the distribution?
by definition tumbleweed gives you the latest and greatest. It delivers what it advertises. Let us know if there is a distribution which can eliminate every possible bug from upstream (inc kde) insightful crtiques with evidence are good ; but it is a problem if users armed with nothing more than a couple of anecdotes and little evident expertise, stand on a soap box and defame a product. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
AW wrote:
Am Mittwoch, 25. Januar 2017, 14:30:29 CET schrieb Johannes Kastl:
You seem to get something fundamentally wrong.
Is it wrong to use a distribution, which has been announced as a rolling release, simply as a user and not as a contributor?
Actually I maintain a lot of notebooks of friends running Tumbleweed (simple XFCE, usual Internet and office use) and luckily they have no issues. I also run various systems important for me with Tumbleweed without issues. But on my own old laptop there are lots of annoying crashes in i915 graphics driver since update to kernel 4.8.x. Sometimes it stalls after starting lightdm but most times recovers after a few seconds. Tracebacks are written to logs. But I gave up adding them to openSUSE and upstream tickets. Ciao, Michael.
On Wednesday, 25 January 2017 19:04:25 CET Michael Ströder wrote:
But on my own old laptop there are lots of annoying crashes in i915 graphics driver since update to kernel 4.8.x. Sometimes it stalls after starting lightdm but most times recovers after a few seconds. Tracebacks are written to logs. But I gave up adding them to openSUSE and upstream tickets.
Ciao, Michael.
does changing to early mode setting or vice versa not change things -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
nicholas wrote:
On Wednesday, 25 January 2017 19:04:25 CET Michael Ströder wrote:
But on my own old laptop there are lots of annoying crashes in i915 graphics driver since update to kernel 4.8.x. Sometimes it stalls after starting lightdm but most times recovers after a few seconds. Tracebacks are written to logs. But I gave up adding them to openSUSE and upstream tickets.
does changing to early mode setting or vice versa not change things
Frankly I don't know what "early mode setting" is. But I'm eager to learn about it. But I've tested using i915.semaphores=1 or not and it does not make a difference (anymore). Ciao, Michael.
On Wed, 25 Jan 2017 12:25:47 +0100, AW wrote:
Am Mittwoch, 25. Januar 2017, 11:48:06 CET schrieb Oliver Neukum:
Am Mittwoch, den 25.01.2017, 11:42 +0100 schrieb AW:
Hi!
Current TW, wake up from s2disk no longer works. This has been an issue since some days.
On wakeup, the login screen appears, but is not responding. It disappears again, comes up again and is responding, I can type my pw. But after log in, plasmashell freezes.
Anybody else using s2disk?
Which graphics?
The usual culprit is the gfx driver, but we need to rule out user space. Does it crash if you do echo disk > /sys/power/state ?
If so, your best option is to bisect the kernel if you are using i915.
HTH Oliver
Intel graphics, probably i915.
Well, it means nothing more than a normal PC :) Please be specific a bit more about your hardware. There are various models with i915, and each behaves differently. But, the best would be to open a report on Bugzilla. Give the hwinfo output and the output of dmesg there.
echo disk > /sys/power/state
To do when? Before sending the PC into hibernate?
The above is essentially to trigger the hibernation manually but without systemd hooks. It's just to make sure that it's a kernel problem.
If so, your best option is to bisect the kernel if you are using i915.
There is a fundamental misunderstanding. I'm a user, and Tumbleweed was supposed to be a »rolling release«. I have no idea how to bisect a kernel.
At least you need to tell which kernel version worked and which doesn't. If the issue happened since "some days" ago, the change in the kernel side should be small, and we may have a chance to spot out easily. Once when we get such information, we can report it to upstream, so that they can start looking at the issue. thanks, Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Mittwoch, den 25.01.2017, 12:25 +0100 schrieb AW:
Intel graphics, probably i915.
Good.
echo disk > /sys/power/state
I should explain more. This will hibernate your machine in kernel space. It lacks most of the features s2disk provides, but a bare bones hibernation should work. If this works, we know s2disk itself is buggy. If this works, the kernel causes the problem.
To do when? Before sending the PC into hibernate?
Instead of.
If so, your best option is to bisect the kernel if you are using i915.
There is a fundamental misunderstanding. I'm a user, and Tumbleweed was supposed to be a »rolling release«. I have no idea how to bisect a kernel.
Your problem is limited to your hardware. I can hibernate. Presumably most people can, as we would have more reports otherwise. Problems specific to some hardware OpenQA cannot catch. Neither can I or anybody without your kind of hardware bisect the kernel. For us hibernate works under all kernel releases.
You may say »don't shoot the messenger« and indeed I don't aim at you, but at the Tumbleweed project:
- kmail / akonadi crashes since December 16th, there have been a couple of bugreports, see e.g. here: https://bugs.kde.org/show_bug.cgi?id=37473 4 The state of the KDE development didn't yet allow to take care, the bug still is »unconfirmed«.
- s2disk stopped working, not for the first time
- plasma used to freeze, maybe this was solved yesterday
This is not good enough for a rolling release, given other outages.
I really guess that people at Suse do their very best to iron out all the bugs which come from upstream, be it intel or kde. But if a new version of an intel i915 driver is crap or a KDE update unreliable, you can't release it in a rolling release.
I cannot speak for KDE. For i915 testing needs real hardware. If you want I can try to explain how bisecting is done. Regards Oliver -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Mittwoch, 25. Januar 2017, 14:49:41 CET schrieb Oliver Neukum:
Am Mittwoch, den 25.01.2017, 12:25 +0100 schrieb AW:
Intel graphics, probably i915.
Good.
echo disk > /sys/power/state
I should explain more. This will hibernate your machine in kernel space. It lacks most of the features s2disk provides, but a bare bones hibernation should work.
If this works, we know s2disk itself is buggy. If this works, the kernel causes the problem.
OK, # echo disk > /sys/power/state as root. Screen becomes black, LED for "on" goes out. After pressing the start button PC wakes up, desktop appears. But the desktop responds very slowly. After a while I typed into Yakuake # killall plasmashell plasmashell: Kein Prozess gefunden Plasmashell says »no process found«, so I guess it crashed. After #kstart plasmashell desktop is not back to normal, it still is lagging, but usuable. Gets better after some minutes. Maybe because I'm using two screens. HTH! However, thank you! Wouldn't it be an easy test just to install the latest 4.8 kernel, boot it and see how it works? Unfortunately, I don't know, where to get an older TW kernel. ...
Your problem is limited to your hardware.
This is a Lenovo Thinkpad, not really new: T450s. This has been sold two years ago a lot.
I can hibernate. Presumably most people can, as we would have more reports otherwise. Problems specific to some hardware OpenQA cannot catch.
Neither can I or anybody without your kind of hardware bisect the kernel. For us hibernate works under all kernel releases. ... I cannot speak for KDE. For i915 testing needs real hardware. If you want I can try to explain how bisecting is done.
This would be a "suspenseful" thing, but I'm on a very narrow landline (1 Mbit /s) today and downloading the kernel-sources and installing git is out of my time budget today. I'll send an email to you and Takashi with about 1 MB hwinfo. Again: Thank you for your help. -- Alexander -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, 25 Jan 2017 16:00:54 +0100, AW wrote:
Am Mittwoch, 25. Januar 2017, 14:49:41 CET schrieb Oliver Neukum:
Am Mittwoch, den 25.01.2017, 12:25 +0100 schrieb AW:
Intel graphics, probably i915.
Good.
echo disk > /sys/power/state
I should explain more. This will hibernate your machine in kernel space. It lacks most of the features s2disk provides, but a bare bones hibernation should work.
If this works, we know s2disk itself is buggy. If this works, the kernel causes the problem.
OK,
# echo disk > /sys/power/state
as root. Screen becomes black, LED for "on" goes out. After pressing the start button PC wakes up, desktop appears. But the desktop responds very slowly.
OK, and at this moment, do you see any kernel messages showing warning or such? Check the output of dmesg.
After a while I typed into Yakuake
# killall plasmashell plasmashell: Kein Prozess gefunden
Plasmashell says »no process found«, so I guess it crashed. After
#kstart plasmashell
desktop is not back to normal, it still is lagging, but usuable. Gets better after some minutes. Maybe because I'm using two screens.
HTH! However, thank you!
Wouldn't it be an easy test just to install the latest 4.8 kernel, boot it and see how it works? Unfortunately, I don't know, where to get an older TW kernel.
You can test my backup kernel repo, OBS home:tiwai:kernel:4.8: http://download.opensuse.org/repositories/home:/tiwai:/kernel:/4.8/ But, before trying that: which kernels did you test? Did it start breaking from 4.9.0? Or later version of 4.9.x? thanks, Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Mittwoch, 25. Januar 2017, 16:08:52 CET schrieb Takashi Iwai:
OK, and at this moment, do you see any kernel messages showing warning or such? Check the output of dmesg.
dmesg includes those lines after wakeup: [22470.597775] [drm] GPU HANG: ecode 8:0:0xba399353, in Xorg [1652], reason: Hang on render ring, action: reset [22470.597778] [drm] GPU hangs can indicate a bug anywhere in the entire gfx stack, including userspace. [22470.597780] [drm] Please file a _new_ bug report on bugs.freedesktop.org against DRI -> DRM/Intel [22470.597781] [drm] drm/i915 developers can then reassign to the right component if it's not a kernel issue. [22470.597782] [drm] The gpu crash dump is required to analyze gpu hangs, so please always attach it. [22470.597784] [drm] GPU crash dump saved to /sys/class/drm/card0/error [22470.597865] drm/i915: Resetting chip after gpu hang [22479.589147] drm/i915: Resetting chip after gpu hang [22480.078992] Uhhuh. NMI received for unknown reason 3c on CPU 0. [22480.078995] Do you have a strange power saving mode enabled? [22480.078997] Dazed and confused, but trying to continue [22491.589009] drm/i915: Resetting chip after gpu hang [22503.620918] drm/i915: Resetting chip after gpu hang [22515.588830] drm/i915: Resetting chip after gpu hang [22527.588757] drm/i915: Resetting chip after gpu hang [22539.588682] drm/i915: Resetting chip after gpu hang [22551.588603] drm/i915: Resetting chip after gpu hang [22562.596511] drm/i915: Resetting chip after gpu hang [22573.604415] drm/i915: Resetting chip after gpu hang [22584.580419] drm/i915: Resetting chip after gpu hang [22595.620296] drm/i915: Resetting chip after gpu hang [22607.588250] drm/i915: Resetting chip after gpu hang [22617.604150] drm/i915: Resetting chip after gpu hang [22629.604064] drm/i915: Resetting chip after gpu hang [22641.603976] drm/i915: Resetting chip after gpu hang [22651.619902] drm/i915: Resetting chip after gpu hang [22662.627872] drm/i915: Resetting chip after gpu hang [22675.587746] drm/i915: Resetting chip after gpu hang ============================================ dmesg | grep "error" [ 9.446992] tpm tpm0: A TPM error (6) occurred attempting to read a pcr value [ 9.453848] iwlwifi 0000:03:00.0: Direct firmware load for iwlwifi-7265D-26.ucode failed with error -2 [ 9.453861] iwlwifi 0000:03:00.0: Direct firmware load for iwlwifi-7265D-25.ucode failed with error -2 [ 9.453869] iwlwifi 0000:03:00.0: Direct firmware load for iwlwifi-7265D-24.ucode failed with error -2 [ 9.453876] iwlwifi 0000:03:00.0: Direct firmware load for iwlwifi-7265D-23.ucode failed with error -2 [21923.165360] tpm tpm0: A TPM error (6) occurred attempting to read a pcr value [22456.293200] tpm tpm0: A TPM error (6) occurred attempting to read a pcr value [22470.597784] [drm] GPU crash dump saved to /sys/class/drm/card0/error linux-k2bd:/home/AW # dmesg | grep "*ERROR*" [21923.880843] [drm:intel_dp_start_link_train [i915]] *ERROR* failed to enable link training [21923.965787] [drm:intel_dp_start_link_train [i915]] *ERROR* failed to start channel equalization [21930.417303] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun
You can test my backup kernel repo, OBS home:tiwai:kernel:4.8: http://download.opensuse.org/repositories/home:/tiwai:/kernel:/4.8/
But, before trying that: which kernels did you test? Did it start breaking from 4.9.0? Or later version of 4.9.x?
I'm not sure, but I guess, with 4.9.3. Loading your 4.8. kernel... -- Alexander -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, 25 Jan 2017 16:23:24 +0100, AW wrote:
Am Mittwoch, 25. Januar 2017, 16:08:52 CET schrieb Takashi Iwai:
OK, and at this moment, do you see any kernel messages showing warning or such? Check the output of dmesg.
dmesg includes those lines after wakeup:
[22470.597775] [drm] GPU HANG: ecode 8:0:0xba399353, in Xorg [1652], reason: Hang on render ring, action: reset
So it's clear that a GPU hang happens after the resume, yeah. A quick search showed the following upstream bug report: https://bugs.freedesktop.org/show_bug.cgi?id=98288 And a fix patch is suggested there. I can build a test kernel for you, but for that, I'd need a bug report in bugzilla.opensuse.org as the reference. Could you open a bug report please? thanks, Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Mittwoch, 25. Januar 2017, 16:28:34 CET schrieb Takashi Iwai:
I can build a test kernel for you, but for that, I'd need a bug report in bugzilla.opensuse.org as the reference. Could you open a bug report please?
https://bugs.freedesktop.org/show_bug.cgi?id=99535 Thank you! -- Alexander -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, 25 Jan 2017 16:46:15 +0100, AW wrote:
Am Mittwoch, 25. Januar 2017, 16:28:34 CET schrieb Takashi Iwai:
I can build a test kernel for you, but for that, I'd need a bug report in bugzilla.opensuse.org as the reference. Could you open a bug report please?
Oh, I didn't mean bugzilla.freedesktop.org, but our own bugzilla, bugzilla.opensuse.org... But never mind, I opened a bug by myself now :) https://bugzilla.opensuse.org/show_bug.cgi?id=1021921 Feel free to join there. thanks, Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, 25 Jan 2017 16:51:06 +0100, Takashi Iwai wrote:
On Wed, 25 Jan 2017 16:46:15 +0100, AW wrote:
Am Mittwoch, 25. Januar 2017, 16:28:34 CET schrieb Takashi Iwai:
I can build a test kernel for you, but for that, I'd need a bug report in bugzilla.opensuse.org as the reference. Could you open a bug report please?
Oh, I didn't mean bugzilla.freedesktop.org, but our own bugzilla, bugzilla.opensuse.org...
But never mind, I opened a bug by myself now :) https://bugzilla.opensuse.org/show_bug.cgi?id=1021921
Feel free to join there.
FYI, as mentioned in the bugzilla entry, the test kernel is ready. Please give it a try. Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Mittwoch, 25. Januar 2017, 22:24:39 CET schrieb Takashi Iwai:
On Wed, 25 Jan 2017 16:51:06 +0100,
Takashi Iwai wrote:
On Wed, 25 Jan 2017 16:46:15 +0100,
AW wrote:
Am Mittwoch, 25. Januar 2017, 16:28:34 CET schrieb Takashi Iwai:
I can build a test kernel for you, but for that, I'd need a bug report in bugzilla.opensuse.org as the reference. Could you open a bug report please?
Oh, I didn't mean bugzilla.freedesktop.org, but our own bugzilla, bugzilla.opensuse.org...
But never mind, I opened a bug by myself now :)
https://bugzilla.opensuse.org/show_bug.cgi?id=1021921
Feel free to join there.
FYI, as mentioned in the bugzilla entry, the test kernel is ready. Please give it a try.
Takashi
Yes, it works, s2disk = hibernate is back to normal. My apologies for the late answer, but kmail / akonadi is close to unusable due to permanent outages. Thank you very much, that was very fast work! -- Regards, Alexander -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
25.01.2017 18:00, AW пишет:
# echo disk > /sys/power/state
as root. Screen becomes black, LED for "on" goes out. After pressing the start button PC wakes up, desktop appears. But the desktop responds very slowly.
Do you see any (unusual) disk activity? Suspend to disk tries to flush cashes to reduce size of hibernate image, so some performance degradation due to excessive disk access shortly after resume is to be expected. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2017-01-25 18:12, Andrei Borzenkov wrote:
25.01.2017 18:00, AW пишет:
# echo disk > /sys/power/state
as root. Screen becomes black, LED for "on" goes out. After pressing the start button PC wakes up, desktop appears. But the desktop responds very slowly.
Do you see any (unusual) disk activity? Suspend to disk tries to flush cashes to reduce size of hibernate image, so some performance degradation due to excessive disk access shortly after resume is to be expected.
Actually, I see a lot of degradation in this respect, comparing Leap 42.2 to 13.1 (systemd vs pm utils). - -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAliJPu8ACgkQja8UbcUWM1zJSgEAh4kJfIQ0qwsWBUnHoqk83XLx FeAbMBYWj+fWqyPlRgcBAIGylYpaw3TqDI/nmt/a2z5IQh3xsuXTiH4FU/J4FSEq =HeJH -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2017-01-25 14:49, Oliver Neukum wrote:
I cannot speak for KDE. For i915 testing needs real hardware. If you want I can try to explain how bisecting is done.
I am interested in learning how to do bisecting, but for another issue and in Leap 42.2. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
Am 25.01.2017 um 11:42 schrieb AW:
Current TW, wake up from s2disk no longer works. This has been an issue since some days.
On wakeup, the login screen appears, but is not responding. It disappears again, comes up again and is responding, I can type my pw. But after log in, plasmashell freezes.
Probably related. I've activated "Ruhezustand" (German) which I suppose is "hibernate" in KDE/Tumbleweed. It doesn't work except that when it kicks in, keyboard entry is no longer recognized (keyboard seems dead). The mouse still works. Keyboard and mouse connected with cable. I can get back control of the computer by mouse-clicking "Standby" in KDE. The computer powers down. Switched on again, keyboard works as it should. System: Tumbleweed, updates as provided. cu Peter -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thursday, 26 January 2017 00:04:16 CET Peter Mc Donough wrote:
Am 25.01.2017 um 11:42 schrieb AW:
Current TW, wake up from s2disk no longer works. This has been an issue since some days.
On wakeup, the login screen appears, but is not responding. It disappears again, comes up again and is responding, I can type my pw. But after log in, plasmashell freezes.
Probably related. I've activated "Ruhezustand" (German) which I suppose is "hibernate" in KDE/Tumbleweed. It doesn't work except that when it kicks in, keyboard entry is no longer recognized (keyboard seems dead). The mouse still works. Keyboard and mouse connected with cable.
I can get back control of the computer by mouse-clicking "Standby" in KDE. The computer powers down. Switched on again, keyboard works as it should.
System: Tumbleweed, updates as provided.
cu Peter you updated with dup --no-allow-vendor-change suspend works normally? and what does journald say?
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 26.01.2017 um 06:42 schrieb nicholas:
On Thursday, 26 January 2017 00:04:16 CET Peter Mc Donough wrote:
Am 25.01.2017 um 11:42 schrieb AW:
Current TW, wake up from s2disk no longer works. This has been an issue since some days. [..] Probably related. I've activated "Ruhezustand" (German) which I suppose is "hibernate" in KDE/Tumbleweed. It doesn't work except that when it kicks in, keyboard entry is no longer recognized (keyboard seems dead). The mouse still works. Keyboard and mouse connected with cable. I can get back control of the computer by mouse-clicking "Standby" in KDE. The computer powers down. Switched on again, keyboard works as it should. System: Tumbleweed, updates as provided.
you updated with dup --no-allow-vendor-change
Yes
suspend works normally?
Test again. Setting one minute. Two options (German) "Standby" works as assumed "Ruhezustand" after one minute screen turns black but can be activated again with mouse-movements, keyboard seems dead. Computer-control returns when in KDE "Standby" cycle is run.
and what does journald say?
I noticed the problem but couldn't pin it to "hibernate" before I read this thread. journald might help, but "man journald" doesn't exist on my computer. So, which of the binary log-file in /var/log/journal, how do I open it and what will I be looking for? cu Peter -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 26.01.17 12:42 Peter Mc Donough wrote:
Test again. Setting one minute. Two options (German) "Standby" works as assumed "Ruhezustand" after one minute screen turns black but can be activated
Not sure, but I would guess "Ruhezustand" is not hibernation, but rather suspend to ram or similar. try with "systemctl hibernate" instead of the KDE options.
journald might help, but "man journald" doesn't exist on my computer. So, which of the binary log-file in /var/log/journal, how do I open it and what will I be looking for?
None. Use journalctl, probably with "-b" (to get the messages since the last boot) and grep for "hibernat" sudo journalctl -b |grep hibernat Johannes
On 2017-01-26 12:49, Johannes Kastl wrote: A comment.
sudo journalctl -b |grep hibernat
Instead of sudo, you can add your user to the group "systemd-journal", and then you can read the journal as that plain user. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On Thursday, 26 January 2017 12:49:50 CET Johannes Kastl wrote:
On 26.01.17 12:42 Peter Mc Donough wrote:
Test again. Setting one minute. Two options (German) "Standby" works as assumed "Ruhezustand" after one minute screen turns black but can be activated
Not sure, but I would guess "Ruhezustand" is not hibernation, but rather suspend to ram or similar.
try with "systemctl hibernate" instead of the KDE options.
journald might help, but "man journald" doesn't exist on my computer. So, which of the binary log-file in /var/log/journal, how do I open it and what will I be looking for?
None.
Use journalctl, probably with "-b" (to get the messages since the last boot) and grep for "hibernat"
sudo journalctl -b |grep hibernat
Johannes FYI there is a systemd journal icon in yast panel which you might find easier for exploration of the journal PS I stoped using hiberanation since it seems to have issues throught linux. I find the suspend to ram obviously easier and uses a trivial amount of power.
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 26.01.2017 um 12:49 schrieb Johannes Kastl:
On 26.01.17 12:42 Peter Mc Donough wrote:
Test again. Setting one minute. Two options (German) "Standby" works as assumed "Ruhezustand" after one minute screen turns black but can be activated
Not sure, but I would guess "Ruhezustand" is not hibernation, but rather suspend to ram or similar.
As I said, the two relevant options are "Standby" and "Ruhezustand" plus "Herunterfahren/power down" und "Neustart/restart", which are not relevant for that problem.
try with "systemctl hibernate" instead of the KDE options.
KDE provides it. I use its options or forget it, everything else is for testing purposes.
journald might help, but "man journald" doesn't exist on my computer. So, which of the binary log-file in /var/log/journal, how do I open it and what will I be looking for? None. Cool. Use journalctl, probably with "-b" (to get the messages since the last boot) and grep for "hibernat"
Thanks. YAST to the rescue! Thanks Carlos, nicolas output see below, one minute activation RAM 16GB - Swap 17GB, computer powered down, up. first 13:38:22 Standby second 13:42:30 Ruhezustand Failure at 13:42:39 cu Peter ----------------------- Jan 26 13:38:22 lux kernel: PM: Checking hibernation image partition /dev/sda1 Jan 26 13:38:22 lux kernel: PM: Looking for hibernation image. Jan 26 13:38:22 lux systemd[1]: Starting Resume from hibernation using device /dev/sda1... Jan 26 13:38:22 lux systemd-hibernate-resume[417]: Could not resume from '/dev/sda1' (8:1). Jan 26 13:38:22 lux systemd[1]: Started Resume from hibernation using device /dev/sda1. Jan 26 13:38:22 lux kernel: PM: Looking for hibernation image. Jan 26 13:42:30 lux.site systemd-sleep[2745]: INFO: running /usr/lib/systemd/system-sleep/grub2.sleep for hibernate Jan 26 13:42:39 lux.site kernel: PM: Creating hibernation image: Jan 26 13:42:39 lux.site systemd[1]: systemd-hibernate.service: Main process exited, code=exited, status=1/FAILURE Jan 26 13:42:39 lux.site systemd[1]: hibernate.target: Job hibernate.target/start failed with result 'dependency'. Jan 26 13:42:39 lux.site systemd[1]: systemd-hibernate.service: Unit entered failed state. Jan 26 13:42:39 lux.site systemd[1]: systemd-hibernate.service: Failed with result 'exit-code'. ------------ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thursday, 26 January 2017 14:12:40 CET Peter Mc Donough wrote:
output see below, one minute activation RAM 16GB - Swap 17GB, computer powered down, up. first 13:38:22 Standby second 13:42:30 Ruhezustand Failure at 13:42:39
cu Peter
----------------------- Jan 26 13:38:22 lux kernel: PM: Checking hibernation image partition /dev/sda1 Jan 26 13:38:22 lux kernel: PM: Looking for hibernation image. Jan 26 13:38:22 lux systemd[1]: Starting Resume from hibernation using device /dev/sda1... Jan 26 13:38:22 lux systemd-hibernate-resume[417]: Could not resume from '/dev/sda1' (8:1). Jan 26 13:38:22 lux systemd[1]: Started Resume from hibernation using device /dev/sda1. Jan 26 13:38:22 lux kernel: PM: Looking for hibernation image. Jan 26 13:42:30 lux.site systemd-sleep[2745]: INFO: running /usr/lib/systemd/system-sleep/grub2.sleep for hibernate Jan 26 13:42:39 lux.site kernel: PM: Creating hibernation image: Jan 26 13:42:39 lux.site systemd[1]: systemd-hibernate.service: Main process exited, code=exited, status=1/FAILURE Jan 26 13:42:39 lux.site systemd[1]: hibernate.target: Job hibernate.target/start failed with result 'dependency'. Jan 26 13:42:39 lux.site systemd[1]: systemd-hibernate.service: Unit entered failed state. Jan 26 13:42:39 lux.site systemd[1]: systemd-hibernate.service: Failed with result 'exit-code'.
------------ you should also show output of swapon --show cat /proc/cmdline what graphics card/driver you have installed and power saving utils?
hibernate issues are notoriously difficult to debug with many possibilities, im getting out of my depth here so carlos please take over! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 26.01.2017 um 15:04 schrieb nicholas:
On Thursday, 26 January 2017 14:12:40 CET Peter Mc Donough wrote: [...] you should also show output of swapon --show cat /proc/cmdline what graphics card/driver you have installed and power saving utils?
Ok, same procedure with additional features. Set "Ruhezustand" one minute, rebooted swapon -show Dateiname Typ Größe Benutzt Priorität /dev/sda2 partition 17830908 0 -1 ------------ cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-4.9.4-1-default root=UUID=5e01abdd-40ef-48d5-b80e-0badb32669fe resume=/dev/sda1 splash=verbose quiet showopts ------------- Graphics card AMD RX460, driver as provided by Tumbleweed power saving as provided by KDE/Tumblewed System updates as provided ---------- Status before "Ruhezustand" kicks in. Jan 26 18:07:43 lux kernel: PM: Checking hibernation image partition /dev/sda1 Jan 26 18:07:43 lux kernel: PM: Looking for hibernation image. Jan 26 18:07:43 lux systemd[1]: Created slice system-systemd\x2dhibernate\x2dresume.slice. Jan 26 18:07:43 lux systemd[1]: Starting Resume from hibernation using device /dev/sda1... Jan 26 18:07:43 lux systemd-hibernate-resume[343]: Could not resume from '/dev/sda1' (8:1). Jan 26 18:07:43 lux systemd[1]: Started Resume from hibernation using device /dev/sda1. Jan 26 18:07:43 lux kernel: PM: Looking for hibernation image. -------- Status "Ruhezustand" 1 min after it kicked in (18:21:00), keyboard control lost Jan 26 18:07:43 lux kernel: PM: Checking hibernation image partition /dev/sda1 Jan 26 18:07:43 lux kernel: PM: Looking for hibernation image. Jan 26 18:07:43 lux systemd[1]: Created slice system-systemd\x2dhibernate\x2dresume.slice. Jan 26 18:07:43 lux systemd[1]: Starting Resume from hibernation using device /dev/sda1... Jan 26 18:07:43 lux systemd-hibernate-resume[343]: Could not resume from '/dev/sda1' (8:1). Jan 26 18:07:43 lux systemd[1]: Started Resume from hibernation using device /dev/sda1. Jan 26 18:07:43 lux kernel: PM: Looking for hibernation image. Jan 26 18:21:00 lux.site systemd-sleep[2656]: INFO: running /usr/lib/systemd/system-sleep/grub2.sleep for hibernate Jan 26 18:21:12 lux.site kernel: PM: Creating hibernation image: Jan 26 18:21:12 lux.site systemd[1]: systemd-hibernate.service: Main process exited, code=exited, status=1/FAILURE Jan 26 18:21:12 lux.site systemd[1]: hibernate.target: Job hibernate.target/start failed with result 'dependency'. Jan 26 18:21:12 lux.site systemd[1]: systemd-hibernate.service: Unit entered failed state. Jan 26 18:21:12 lux.site systemd[1]: systemd-hibernate.service: Failed with result 'exit-code'. ---- Control gained by klicking "Standby" in KDE. cu Peter -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thursday, 26 January 2017 18:56:48 CET Peter Mc Donough wrote:
Am 26.01.2017 um 15:04 schrieb nicholas:
On Thursday, 26 January 2017 14:12:40 CET Peter Mc Donough wrote: [...] you should also show output of swapon --show cat /proc/cmdline what graphics card/driver you have installed and power saving utils?
Ok, same procedure with additional features.
Set "Ruhezustand" one minute, rebooted
swapon -show Dateiname Typ Größe Benutzt Priorität /dev/sda2 partition 17830908 0 -1 ------------
cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-4.9.4-1-default root=UUID=5e01abdd-40ef-48d5-b80e-0badb32669fe resume=/dev/sda1 splash=verbose quiet showopts -------------
Graphics card AMD RX460, driver as provided by Tumbleweed power saving as provided by KDE/Tumblewed System updates as provided ---------- Status before "Ruhezustand" kicks in.
Jan 26 18:07:43 lux kernel: PM: Checking hibernation image partition /dev/sda1 Jan 26 18:07:43 lux kernel: PM: Looking for hibernation image. Jan 26 18:07:43 lux systemd[1]: Created slice system-systemd\x2dhibernate\x2dresume.slice. Jan 26 18:07:43 lux systemd[1]: Starting Resume from hibernation using device /dev/sda1... Jan 26 18:07:43 lux systemd-hibernate-resume[343]: Could not resume from '/dev/sda1' (8:1). Jan 26 18:07:43 lux systemd[1]: Started Resume from hibernation using device /dev/sda1. Jan 26 18:07:43 lux kernel: PM: Looking for hibernation image. --------
Status "Ruhezustand" 1 min after it kicked in (18:21:00), keyboard control lost
Jan 26 18:07:43 lux kernel: PM: Checking hibernation image partition /dev/sda1 Jan 26 18:07:43 lux kernel: PM: Looking for hibernation image. Jan 26 18:07:43 lux systemd[1]: Created slice system-systemd\x2dhibernate\x2dresume.slice. Jan 26 18:07:43 lux systemd[1]: Starting Resume from hibernation using device /dev/sda1... Jan 26 18:07:43 lux systemd-hibernate-resume[343]: Could not resume from '/dev/sda1' (8:1). Jan 26 18:07:43 lux systemd[1]: Started Resume from hibernation using device /dev/sda1. Jan 26 18:07:43 lux kernel: PM: Looking for hibernation image. Jan 26 18:21:00 lux.site systemd-sleep[2656]: INFO: running /usr/lib/systemd/system-sleep/grub2.sleep for hibernate Jan 26 18:21:12 lux.site kernel: PM: Creating hibernation image: Jan 26 18:21:12 lux.site systemd[1]: systemd-hibernate.service: Main process exited, code=exited, status=1/FAILURE Jan 26 18:21:12 lux.site systemd[1]: hibernate.target: Job hibernate.target/start failed with result 'dependency'. Jan 26 18:21:12 lux.site systemd[1]: systemd-hibernate.service: Unit entered failed state. Jan 26 18:21:12 lux.site systemd[1]: systemd-hibernate.service: Failed with result 'exit-code'. ---- Control gained by klicking "Standby" in KDE.
cu Peter you appear to have swap on sda2, whilst trying to resume from resume=/dev/ sda1? this should be simple to fix, could you first CHECK your /etc/fstab entry for swap entry first, if given as uuid instead of sda you can cross ref using something like blkid
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 26.01.2017 um 19:25 schrieb nicholas:
On Thursday, 26 January 2017 18:56:48 CET Peter Mc Donough wrote:
Am 26.01.2017 um 15:04 schrieb nicholas:
On Thursday, 26 January 2017 14:12:40 CET Peter Mc Donough wrote: [...]
Jan 26 18:07:43 lux systemd-hibernate-resume[343]: Could not resume from '/dev/sda1' (8:1). [..]
you appear to have swap on sda2, whilst trying to resume from resume=/dev/ sda1? this should be simple to fix, could you first CHECK your /etc/fstab entry for swap entry first, if given as uuid instead of sda you can cross ref using something like blkid
You are right! I recently repartitioned and moved swap from sda1 to sda2. My Yast still doesn't like changing boot-parameters. I thought I could fix it by going to /etc/default/grub and change resume=/dev/sda1 to resume=dev/sda2 but after booting, it is still unchanged cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-4.9.4-1-default root=UUID=5e01abdd-40ef-48d5-b80e-0badb32669fe resume=/dev/sda1 splash=verbose quiet showopts I can pick the UUID of swap from /etc/fstab, but how can I insert it into the boot parameter if changing in /etc/default/grub doesn't work. Or what am I missing ? cu Peter -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thursday, 26 January 2017 22:35:34 CET Peter Mc Donough wrote:
Am 26.01.2017 um 19:25 schrieb nicholas:
On Thursday, 26 January 2017 18:56:48 CET Peter Mc Donough wrote:
Am 26.01.2017 um 15:04 schrieb nicholas:
On Thursday, 26 January 2017 14:12:40 CET Peter Mc Donough wrote: [...]
Jan 26 18:07:43 lux systemd-hibernate-resume[343]: Could not resume from '/dev/sda1' (8:1).
[..]
you appear to have swap on sda2, whilst trying to resume from resume=/dev/ sda1? this should be simple to fix, could you first CHECK your /etc/fstab entry for swap entry first, if given as uuid instead of sda you can cross ref using something like blkid
You are right! I recently repartitioned and moved swap from sda1 to sda2.
My Yast still doesn't like changing boot-parameters. I thought I could fix it by going to /etc/default/grub and change resume=/dev/sda1 to resume=dev/sda2
but after booting, it is still unchanged cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-4.9.4-1-default root=UUID=5e01abdd-40ef-48d5-b80e-0badb32669fe resume=/dev/sda1 splash=verbose quiet showopts
I can pick the UUID of swap from /etc/fstab, but how can I insert it into the boot parameter if changing in /etc/default/grub doesn't work. Or what am I missing ?
cu Peter you changed /etc/defualt/grub to read resume=/dev/sda2, then run grub2-mkconfig -o /boot/grub2/grub.cfg ?? there is no reason it wouldnt work.
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 26.01.2017 um 22:46 schrieb nicholas:
On Thursday, 26 January 2017 22:35:34 CET Peter Mc Donough wrote:
Am 26.01.2017 um 19:25 schrieb nicholas:
On Thursday, 26 January 2017 18:56:48 CET Peter Mc Donough wrote:
Am 26.01.2017 um 15:04 schrieb nicholas:
On Thursday, 26 January 2017 14:12:40 CET Peter Mc Donough wrote: [...]
Jan 26 18:07:43 lux systemd-hibernate-resume[343]: Could not resume from '/dev/sda1' (8:1).
[..]
you appear to have swap on sda2, whilst trying to resume from resume=/dev/ sda1? this should be simple to fix, could you first [...] you changed /etc/defualt/grub to read resume=/dev/sda2, then run grub2-mkconfig -o /boot/grub2/grub.cfg ?? there is no reason it wouldnt work.
BINGO (!) Problem solved, "Ruhezustand" and keyboard work as they should, below the last journalclt. Thanks Peter ------------------ journalctl -b |grep hibernat Jan 26 22:56:43 lux kernel: PM: Checking hibernation image partition /dev/sda2 Jan 26 22:56:43 lux kernel: PM: Looking for hibernation image. Jan 26 22:56:43 lux systemd[1]: Starting Resume from hibernation using device /dev/sda2... Jan 26 22:56:43 lux kernel: PM: Looking for hibernation image. Jan 26 22:56:43 lux systemd-hibernate-resume[344]: Could not resume from '/dev/sda2' (8:2). Jan 26 22:56:43 lux systemd[1]: Started Resume from hibernation using device /dev/sda2. Jan 26 22:59:24 lux.site systemd-sleep[2333]: INFO: running /usr/lib/systemd/system-sleep/grub2.sleep for hibernate Jan 26 23:00:20 lux.site kernel: PM: Creating hibernation image: Jan 26 23:00:20 lux.site systemd-sleep[2333]: INFO: running /usr/lib/systemd/system-sleep/grub2.sleep for hibernate Jan 26 23:00:20 lux.site systemd[1]: hibernate.target: Unit is bound to inactive unit systemd-hibernate.service. Stopping, too. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2017-01-26 15:04, nicholas wrote:
hibernate issues are notoriously difficult to debug with many possibilities, im getting out of my depth here so carlos please take over!
Unfortunately, I'm also new at debugging hibernation when systemd is in control. It does not print progress messages to the screen, we can find almost out nothing... In that log there is nothing, only that hibernation failed. Perhaps try "dmesg" at that point. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
Am 26.01.2017 um 23:07 schrieb Carlos E. R.:
On 2017-01-26 15:04, nicholas wrote:
hibernate issues are notoriously difficult to debug with many possibilities, im getting out of my depth here so carlos please take over!
Unfortunately, I'm also new at debugging hibernation when systemd is in control. It does not print progress messages to the screen, we can find almost out nothing... In that log there is nothing, only that hibernation failed.
Perhaps try "dmesg" at that point.
The problem on my computer was probably a moved swap partition, which is now registered where it should be. Problem disappeared Thanks Peter -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2017-01-26 23:13, Peter Mc Donough wrote:
Am 26.01.2017 um 23:07 schrieb Carlos E. R.:
On 2017-01-26 15:04, nicholas wrote:
hibernate issues are notoriously difficult to debug with many possibilities, im getting out of my depth here so carlos please take over!
Unfortunately, I'm also new at debugging hibernation when systemd is in control. It does not print progress messages to the screen, we can find almost out nothing... In that log there is nothing, only that hibernation failed.
Perhaps try "dmesg" at that point.
The problem on my computer was probably a moved swap partition, which is now registered where it should be. Problem disappeared
Yes, I read that minutes later :-) -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On Thursday, 26 January 2017 23:07:52 CET Carlos E. R. wrote:
On 2017-01-26 15:04, nicholas wrote:
hibernate issues are notoriously difficult to debug with many possibilities, im getting out of my depth here so carlos please take over!
Unfortunately, I'm also new at debugging hibernation when systemd is in control. It does not print progress messages to the screen, we can find almost out nothing... In that log there is nothing, only that hibernation failed.
Perhaps try "dmesg" at that point. yes the log was astonishingly useless, but we nailed it, read the more recent msgs -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (12)
-
Andrea Controzzi - LedMania.it -
Andrei Borzenkov -
AW -
Carlos E. R. -
jeroenmathonmac＠gmail.com -
Johannes Kastl -
Michael Ströder -
nicholas -
Oliver Neukum -
Patrick Shanahan -
Peter Mc Donough -
Takashi Iwai