You can clone with
HTTPS or Subversion.
Bumblebee has worked nicely for a while on my laptop (Alienware m14x) until recently (in hindsight, until I updated to kernel 3.11 probably). I'm using Fedora 19.
When bumblebee-nvidia (319.49-1) is installed, recovering from standy now takes 22s (instead of immediate when it's not installed).
Most of the time, I can run applications with optirun or primusrun, at least until the first time I put the laptop in standby. I haven't found an absolute pattern yet.
Sometimes trying to use optirun causes the error "Cannot access secondary GPU. Server terminated successfully". On other occasions I keep getting this message on regular intervals until I reboot:
Message from syslogd@atuin at Nov 15 20:29:37 ...
kernel:[ 6941.316073] BUG: soft lockup - CPU#3 stuck for 22s! [Xorg:4333]
(the 22s probably not by coincidence the time it takes to wake up from standby)
yum update bumblebee-nvidia
You may need to do a
yum clean all
if it can't find the new version. I have upgraded that package to version 331.20 so see if that helps with suspend.
I tested suspend on a fedora 20 beta laptop with this version installed and working and suspend/resume seemed to work ok.
Forgot to mention you will want to reboot after upgrading that package.
Thanks for the quick response. I didn't realise there was a more recent package. yum indeed only picked it up after a clean all.
And yes, standy/resume is working without delay again.
(the 22s delay did happen once more after a few tries, but I could not reproduce it)
optirun does work fine now (have to start bumblebeed by hand though). However if I do a standby/resume after using it, it stops working:
[ 597.225972] [ERROR]Cannot access secondary GPU - error: [XORG] (EE) Failed to load module "glamoregl" (module does not exist, 0)
[ 597.226009] [ERROR]Aborting because fallback start is disabled.
[ 157.348314] [ERROR]Cannot access secondary GPU - error: [XORG] (EE) Server terminated successfully (0). Closing log file.
[ 157.348343] [ERROR]Aborting because fallback start is disabled.
Also the fan starts being very active, so a reboot is still needed. Possibly related to #433 .
Still thanks, like this it's usable again.
Could the problem you are having with bumblebee not starting be related to this?
I would suggest trying to remove bumblebee rpm and installing again. Let me know if that helped?
I don't have the feeling that was related.
I un- and reinstalled package 3.2.1-4 (with yum... trying to remove the 3.2.1-2 with rpm said that package was not installed) and the dependencies (primus 0.8.09192013-1 and bumblebee-nvidia 331.20-1).
Sad to say that also the long resume time and the soft CPU lockup errors are back (already before I tried the reinstall).
I'd be glad to provide more details if that could be of any help with debugging the Fedora issues.
Hmnn. I have patched rpms I can put on the internet for #433
I have placed them here in case you think that might be affecting things:
My fedora 19 test laptop has this patched package. I use CentOS 6 on my main laptop system, also as of last night with 331.20 and was playing minecraft with it before I fell asleep.
Does it help if you boot into a older kernel. Like the oldest one in your grub menu?
Please provide pastebin's to
/var/log/Xorg.8.log and /var/log/messages
after trying to use optirun with something. Like "optirun -vv -b primus glxgears -info"
Installed the patched 0.6.0-8 modesetting rpm and I think it (almost) did the trick.
nvidia module gets loaded and removed as it should, /proc/acpi/bbswitch only returns ON while the card is actually working and I can use optirun every time without errors. Great :-)
Only weird behaviour still noticing now, is that if I use standby/resume before the first time I use optirun, I get the 22s resume again... as soon as optirun is used at least once, everything seems to work perfectly.
If still of any interest to you.
Are you still facing this latest weird issue? Anyway, I’m not sure whether we could do anything about it, I didn’t see anything in your log that could be related.
Yes, this issue still exists, but it's only a minor annoyance.
After a reboot, I have to remember to run optirun at least once, to prevent the next standby/wakeup to hang for 22s. Apart from that, everything is working fine.
This is the dmesg after a hanging wakeup:
Is still issue this here with recent packages?