You are not logged in.
@yourself
Not sure what. Just thought that polling might cause errors if conflicting with something else.
Anyway - using pm-utils with systemd and it happened to me yesterday. Lost all my chromium tabs so pretty irritated right now.
I have to find a way to tell systemd to stop using pm-utils.
But the bug still exists.
Offline
Our X crash backtrace looks eerily similar to these:
https://bugs.archlinux.org/task/30921
https://bugs.freedesktop.org/show_bug.cgi?id=52496
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=681796
https://bugs.launchpad.net/bugs/956071
The issue seems to lie in the Synaptics driver.
A fix has being proposed. Let's see if that helps.
Maybe downgrading xf86-input-synaptics will work..?
Last edited by yourself (2012-08-31 22:37:42)
Offline
I'd like to report the same problem as https://bbs.archlinux.org/viewtopic.php … 5#p1151895 (Should this go on a different thread?)
My system takes a whole minute to go from GDM to the desktop. Note: I switched to booting with systemd recently.
To my memory, it's been this slow for a long time and I decided to try and fix it yesterday. Since then I've been tearing my hair trying to find solutions online.
Offline
I'd like to report the same problem as https://bbs.archlinux.org/viewtopic.php … 5#p1151895 (Should this go on a different thread?)
My system takes a whole minute to go from GDM to the desktop. Note: I switched to booting with systemd recently.
To my memory, it's been this slow for a long time and I decided to try and fix it yesterday. Since then I've been tearing my hair trying to find solutions online.
Well, this seems to be unrelated to the one we're having here so yes, it probably should go to a different thread.
Offline
Guys and girls, the stipulation that this whole mess was caused by the synaptics driver seems to be confirmed! I have downgraded to xf86-input-synaptics-1.5.99.902-1 and I am currently at 33 hours of uptime without any mishaps!
Please downgrade to xf86-input-synaptics-1.5.99.902-1 and confirm that this is indeed the solution.
Fingers crossed!
Offline
I have downgraded to xf86-input-synaptics-1.5.99.902-1 and I am currently at 33 hours of uptime without any mishaps!
Just to make sure: you have acpid on your system and (pm-)suspend your computer by closing the lid (defined in /etc/acpid/eventhandler or something like that). Then you wake up your computer by opening the lid. With all the current packages (xserver xf86-intel etc) and with the xf86-input-synaptics-1.5.99.902-1 driver, this is not giving the random crashes anymore that used to occur shortly after resuming? Let me know if you reach something like 60-80 hours without those random crashes after suspend.
Last edited by btorb (2012-09-02 09:33:58)
Offline
yourself wrote:I have downgraded to xf86-input-synaptics-1.5.99.902-1 and I am currently at 33 hours of uptime without any mishaps!
Just to make sure: you have acpid on your system and (pm-)suspend your computer by closing the lid (defined in /etc/acpid/eventhandler or something like that). Then you wake up your computer by opening the lid. With all the current packages (xserver xf86-intel etc) and with the xf86-input-synaptics-1.5.99.902-1 driver, this is not giving the random crashes anymore that used to occur shortly after resuming? Let me know if you reach something like 60-80 hours without those random crashes after suspend.
Yes. I am using stock pm-suspend with acpid's /etc/acpi/handler.sh calling pm-suspend on lid close and have disabled XFCE's actions on lid-close.
Of course, I strongly believe that either XFCE-pm or GNOME-pm would work since it's not them causing the problem (as it seems) but the synaptics driver. I have stayed with acpid since it provides system-wide power management without the need of XFCE of GNOME.
I am suspending/resuming by closing/opening the lid, all other packages are current and I am not having random crashes and suspend problems (so far - 36 hours uptime).
Offline
Please downgrade to xf86-input-synaptics-1.5.99.902-1 and confirm that this is indeed the solution.
Downgraded yesterday, and so far +24 hours and several dozen suspend-resume cycles and no problems yet. Since on my system it was more related to the number of times I suspended rather than amount of time, I'd say it's looking very good.
Of course, I strongly believe that either XFCE-pm or GNOME-pm would work since it's not them causing the problem (as it seems) but the synaptics driver.
I'm using XFCE's Power Manager, not acpid and no problems.
I have to admit that I'm very surprised by the cause/solution. I was leaning towards the kernel and thinkpad acpi specific modules and definitely didn't suspect a link between Synaptics and the lid/button. But whatever, as long as there's a fix.
Last edited by dschrute (2012-09-02 12:27:41)
Offline
If downgrading to xf86-input-synaptics-1.5.99.902-1 really fixes the problem for everybody, I think I should mark this thread as solved. Any objections?
Offline
If downgrading to xf86-input-synaptics-1.5.99.902-1 really fixes the problem for everybody, I think I should mark this thread as solved. Any objections?
Wait a little longer. i sometimes had the first crash after >60 hours. I just downgraded the driver and will report back in a few days. I hope you're correct about this fix!
Offline
Guess I spoke too soon, it just happened again. It's definitely not a frequent so far with the older version of Synaptics, but on my system it isn't a 100% fix.
Offline
Guess I spoke too soon, it just happened again. It's definitely not a frequent so far with the older version of Synaptics, but on my system it isn't a 100% fix.
Does your X still crash or is it something else? Search for /var/log/X.0.log or something maybe you can find the backtrace. Is the backtrace the same?
Did this problem start at a specific point in time or have you had it as long as you can remember?
Offline
Does your X still crash or is it something else? Search for /var/log/X.0.log or something maybe you can find the backtrace. Is the backtrace the same?
Nothing unusual in X.0.log. I'll have to go back + check pm-suspend.log more closely, but a quick check didn't show anything unusual.
Did this problem start at a specific point in time or have you had it as long as you can remember?
Not sure what you mean exactly. I've had the problem about as long as you, but on my system it would happen about every 5 to 6 suspends/hibernates regardless of overall time since the previous time it happened. I've had it happen 3 times in one day prior to downgrading Synaptics.
After the downgrade things definitely got better, since I was able to suspend at least a couple dozen times before it happened, but when it did it was exactly the same...Power light on steady rather than flashing, dumped back to Slim login. After logging back in XFCE was not quite right, reboot and the suspend finished.
So for me it looks like there is something else that might trigger it.
Offline
Nothing unusual in X.0.log. I'll have to go back + check pm-suspend.log more closely, but a quick check didn't show anything unusual.
Please also check /var/log/Xorg.1.log, /var/log/Xorg.2.log and maybe /var/log/Xorg.0.log.old, etc... Also, avoid running a display manager (which relaunches X upon crash and overwrites your log) and instead, for now, just run startx.
Did this problem start at a specific point in time or have you had it as long as you can remember?
Not sure what you mean exactly. I've had the problem about as long as you, but on my system it would happen about every 5 to 6 suspends/hibernates regardless of overall time since the previous time it happened. I've had it happen 3 times in one day prior to downgrading Synaptics.
After the downgrade things definitely got better, since I was able to suspend at least a couple dozen times before it happened, but when it did it was exactly the same...Power light on steady rather than flashing, dumped back to Slim login. After logging back in XFCE was not quite right, reboot and the suspend finished.So for me it looks like there is something else that might trigger it.
Well, since it got better this means that this specific version of the synaptics driver has another 'version' of the bug but which surfaces more rarely. Try even older versions and see what happens... As far as I'm concerned, I'm at 50 hours of uptime with no problems, so I'm keeping my fingers crossed.
Offline
Is this working? The system crashed again for me -- I am not running ACPID - I tried disabling gnome power manager settings too.
Offline
Is this working? The system crashed again for me -- I am not running ACPID - I tried disabling gnome power manager settings too.
Did you properly downgrade? I reached 100+ hours before having to reboot for an unrelated reason!
Offline
That doesn't necessarily mean anything. I haven't downgraded yet, and I regularly reach 100+ hours
$ uptime
12:50:09 up 5 days, 1:02, 4 users, load average: 1.06, 0.92, 0.83
Offline
OK, I removed the SOLVED from the title, although I haven't encountered anything like it since downgrading and the bug surfaced in my case every 20-24 hours like clockwork..!! I will keep looking, however, if anything should happen under the proposed 'solution'....
Offline
Another thing I noticed is -- this happens more when I close the lid and plug in the AC power just when it's about to go to sleep. I have been trying to avoid that for now -- let's see how long that works.
Offline
$ uptime
23:36:46 up 6 days, 11:49, 5 users, load average: 0.98, 0.95, 0.86
Still haven't downgraded or anything. This is not an abnormal situation for me. I always have the laptop plugged in, I basically use it as a desktop. I wonder if that has something to do with my unusually low failure rate?
Offline
Still haven't downgraded or anything. This is not an abnormal situation for me. I always have the laptop plugged in, I basically use it as a desktop. I wonder if that has something to do with my unusually low failure rate?
When you say that you use your laptop like a desktop, what do you mean? Because as far as I'm concerned, in order to make the bug surface all I have to do is regular sleep/suspend cycles by closing/opening the lid for about 20-24 hours (not continually, but in uptime terms) and absolutely *NO* reboots or X killings.
Last edited by yourself (2012-09-10 07:54:47)
Offline
Oh, I just mean it's always plugged in. I don't shut it down or anything. Incidentally, the thing happened again last night, after those 6 days of uptime.
Offline
Oh, I just mean it's always plugged in. I don't shut it down or anything. Incidentally, the thing happened again last night, after those 6 days of uptime.
Please, avoid using a display manager such a gdm and start your graphical session by issuing 'startx' at the command line (do not do this as root, do this as your own user. You may also need to insert the appropriate launcher in your ~/.xinitrc for your specific session) so that, when your session goes down in flames you will have access to the complete /var/log/Xorg.0.log...
Then, post it here.
Then, ???
Then, profit ;-)
Offline
20:05:19 up 4 days, 20:58, 1 user, load average: 0.11, 0.22, 0.33
Seems to me that this is working now -- but I have done 2 things. I am not using pm-suspend. I am suspending using systemd every time I want to suspend. Not close the lid.
Offline
I am not using pm-suspend. I am suspending using systemd every time I want to suspend. Not close the lid.
This is indeed the good work around: not using the lid anymore. I'm still using pm-utils but only suspend/hibernate via keybindings and wait for the system to be suspended before closing the lid. Never had any crashes again.
Offline