HI. My first contact with Linux was in Conectiva, so I have an attachment to the Mageia (all dessedentes Conectiva, it is what is doing the best job)! I've been using the "Manjaro linux" (liked it), so I chose to use the Cauldron! Installed "Bumblebee-Nvidia" in my notebook, is working, but I had problems. Both in Manjaro, openSUSE, and Fedora my battery lasts for 2 hours, but the Mageia it does not come in 40 minutes! I also noticed that when I run the command "optirun" he activates the card nvidia normally, but after I close the nvidia card program continues on (without nessecidade), I realize that the noise, heat, and the battery that only lasts 15 minutes with the nvidia card activated! Reproducible: Steps to Reproduce:
Indeed, that's an issue that I have had since we switched to kernel 3.19.x. Sadly I haven't had the time to dig further to understand what broke the feature, but I plan to after Mageia 5 gets released. In the meantime, here is a workaround. After you have used the Nvidia card, you need to force unloading the driver with: # rmmod nvidia Then you can turn the card OFF manually using bbswitch: # tee <<<OFF /proc/acpi/bbswitch
Priority: Normal => HighHardware: x86_64 => AllAssignee: bugsquad => rverscheldeSummary: Bumblebee (excessive battery consumption). => Bumblebee does not turn the discrete card off after using it (leads to excessive battery consumption)Severity: normal => major
For the reference, I reported the issue upstream, but did not get much feedback so far: https://github.com/Bumblebee-Project/Bumblebee/issues/632
Whiteboard: (none) => MGA5TOO FOR_ERRATA
I changed the Kernel for 3.14 the mageia 4, and really improved a lot (since spent 1 hour battery, and has a further 40 minutes forecasts), it has already improved a lot, as it resolves the problem with 3.19, I change back! Thanks!
Same issue for me on dell latitude Intel Ivybridge + nvidia. Nvidia card keeps activated after running optirun command.
CC: (none) => jcldc13
Whiteboard: MGA5TOO FOR_ERRATA => MGA5TOO IN_ERRATA
The workaround works for me. Strange that "modprobe -r nvidia" fails while "rmmod nvidia" works!
Status: NEW => ASSIGNEDCC: (none) => lists.jjorge
(In reply to José Jorge from comment #5) > The workaround works for me. Strange that "modprobe -r nvidia" fails while > "rmmod nvidia" works! Even stranger is that bumblebee code seems to do rmmod, see line 99 : https://github.com/Bumblebee-Project/Bumblebee/blob/master/src/module.c
CC: (none) => luke.nukem.jones
As discussed with Luke, there's likely a mismatch between the name of the X11 driver (nvidia-current) and the name that bumblebee uses (nvidia-current in some places, nvidia in /etc/bumblebee/xorg.conf.nvidia). It could be that changing /etc/bumblebee/xorg.conf.nvidia would be enough, will have to try.
Has anyone checked the permissions on everything? Modprobe configs?
Perhaps in /etc/modprobe.d/bumblebee.conf add alias nvidia nvidia-current There may also be an option that can be used.
(In reply to Luke Jones from comment #9) > Perhaps in /etc/modprobe.d/bumblebee.conf add > > alias nvidia nvidia-current > > There may also be an option that can be used. Also add: remove nvidia rmmod nvidia To the same config, that should enable use of modprobe -R (which then invokes rmmod). I'm 50% sure this will help.
Created attachment 7233 [details] Proposed new /etc/modprobe.d/bumblebee.conf This should completely fix all cases. In the event that another nvidia driver version is loaded, for example "nvidia-340" then a new remove needs to be added, eg; remove nvidia-340 rmmod nvidia
Thanks a lot Luke! I added your fix in SVN and cauldron and pushed update candidates for Mageia: bumblebee-3.2.1-14.20150120.3.mga5 bumblebee-nouveau-3.2.1-14.20150120.3.mga5 bumblebee-nvidia-3.2.1-14.20150120.3.mga5.nonfree David and Samuel, it would be great if you could also test the new packages (they contain the fix in comment 11 but also some packaging rework, so things could break :)).
CC: (none) => geiger.david68210, stormi
Tested mga5_64, new bumblebee-3.2.1-15.20150120.1.mga5 with bumblebee-nvidia-3.2.1-15.20150120.1.mga5.nonfree seems to work fine for me. Nothing to report for now and no regression found!! very excellent!! Thank you very much Luke Jones for your patch :) ------------------------------------ $ glxspheres64 Polygons in scene: 62464 Visual ID of window: 0xa7 Context is Direct OpenGL Renderer: Mesa DRI Intel(R) Sandybridge Mobile 60.934914 frames/sec - 62.940892 Mpixels/sec $ cat /proc/acpi/bbswitch 0000:01:00.0 OFF $ ------------------------------------ ------------------------------------ $ primusrun glxspheres64 Polygons in scene: 62464 Visual ID of window: 0xa7 Context is Direct OpenGL Renderer: GeForce 610M/PCIe/SSE2 62.362512 frames/sec - 64.415486 Mpixels/sec $ cat /proc/acpi/bbswitch 0000:01:00.0 ON $ ------------------------------------ Turn off primusrun gives now: $ cat /proc/acpi/bbswitch 0000:01:00.0 OFF $
Version: Cauldron => 5Whiteboard: MGA5TOO IN_ERRATA => IN_ERRATA
Thanks David. Before assigning to QA I'd like to work on a new version to improve the %pre script: %pre %_pre_groupadd %{name} if [ "$1" -eq "1" ]; then users=$(getent passwd | awk -F: '$3 >= 500 && $3 < 60000 {print $1}') for user in $users; do gpasswd -a $user bumblebee done /usr/sbin/update-alternatives --set gl_conf %{_sysconfdir}/ld.so.conf.d/GL/standard.conf fi Colin, would you know how to improve the "users" variable that currently parses all users above 500? 500 should be dehardcoded I guess, or how is it handled in other packages to make sure that it works for both old configs (first UID is 500) and new ones (first UID is 1000)?
CC: (none) => mageia
I pushed a new update which removes the hack mentioned in comment 14, and instead adds a README.install.urpmi to tell the user that they should add themselves to the bumblebee group. It's an additional step for them, but it's better than adding half of the system-reserved users to the bumblebee group. Also, trying to use bumblebee without being in the group produces a meaningful message saying that the user should check that they are in the bumblebee group. New packages: bumblebee-3.2.1-15.20150120.2.mga5 bumblebee-nouveau-3.2.1-15.20150120.2.mga5 bumblebee-nvidia-3.2.1-15.20150120.2.mga5.nonfree
Assigning to QA. Advisory: ========= Updated bumblebee packages fix discrete card not being unloaded after usage The bumblebee packages as provided in Mageia 5 were not using the correct reference for the nvidia driver, so the latter could not be properly offloaded after closing all processes using the discrete card. This issue has been fixed, as well as a too greedy installation script that could add system-specific users to the bumblebee group. Session users will now need to add themselves manually to the bumblebee group, as advised by a post-installation message. The primus package was also updated to include an upstream bugfix (GH-163) and so that the 64-bit version recommends the 32-bit library, needed to play 32-bit games e.g. on Steam. References: - https://github.com/amonakov/primus/issues/163 SRPMs: ====== core: - bumblebee-3.2.1-15.20150120.2.mga5 - primus-0.1-3.20150328.1.mga5 nonfree: - bumblebee-3.2.1-15.20150120.2.mga5.nonfree - primus-0.1-3.20150328.1.mga5.nonfree RPMs: ===== bumblebee-3.2.1-15.20150120.2.mga5 bumblebee-nouveau-3.2.1-15.20150120.2.mga5 bumblebee-nvidia-3.2.1-15.20150120.2.mga5.nonfree primus-0.1-3.20150328.1.mga5 primus-nouveau-0.1-3.20150328.1.mga5 primus-nvidia-0.1-3.20150328.1.mga5.nonfree libprimus-0.1-3.20150328.1.mga5 lib64primus-0.1-3.20150328.1.mga5 Testing procedure: ================== - This requires an "optimus" laptop, i.e. a laptop with both an integrated Intel chipset and an Nvidia discrete GPU. - Install bumblebee with "urpmi bumblebee", select either -nouveau or -nvidia (first one is the libre driver, second one nonfree). - Run applications with "optirun <command>" or "primusrun <command>" - While the applications run, "cat /proc/acpi/bbswitch" should say "ON", and when the applications are stopped, it should say "OFF". With the version in Core Release, it would stay on "ON".
Assignee: rverschelde => qa-bugsQA Contact: (none) => rverschelde
Whiteboard: IN_ERRATA => IN_ERRATA has_procedure
Note: ===== Test case applies only to proprietary Nvidia drivers (Nvidia-current for eg), the nouveau drivers do not change their module names and are unloaded correctly.
Tested mga5_64, new bumblebee-3.2.1-15.20150120.2.mga5 with bumblebee-nvidia-3.2.1-15.20150120.2.mga5.nonfree seems to work fine for me. Same for primus and primus-nvidia. - bumblebee-3.2.1-15.20150120.2.mga5 - bumblebee-nvidia-3.2.1-15.20150120.2.mga5.nonfree - primus-0.1-3.20150328.1.mga5 - primus-nvidia-0.1-3.20150328.1.mga5.nonfree - lib64primus-0.1-3.20150328.1.mga5 - libprimus-0.1-3.20150328.1.mga5 ------------------------------------ $ glxspheres64 Polygons in scene: 62464 Visual ID of window: 0xa7 Context is Direct OpenGL Renderer: Mesa DRI Intel(R) Sandybridge Mobile 60.617339 frames/sec - 62.612862 Mpixels/sec $ cat /proc/acpi/bbswitch 0000:01:00.0 OFF $ ------------------------------------ ------------------------------------ $ primusrun glxspheres64 Polygons in scene: 62464 Visual ID of window: 0xa7 Context is Direct OpenGL Renderer: GeForce 610M/PCIe/SSE2 62.374546 frames/sec - 64.427916 Mpixels/sec $ cat /proc/acpi/bbswitch 0000:01:00.0 ON $ ------------------------------------ Turn off primusrun gives now: $ cat /proc/acpi/bbswitch 0000:01:00.0 OFF $
URL: (none) => MGA5-64-OK
Whiteboard: IN_ERRATA has_procedure => IN_ERRATA has_procedure MGA5-64-OKURL: MGA5-64-OK => (none)
Whiteboard: IN_ERRATA has_procedure MGA5-64-OK => IN_ERRATA has_procedure MGA5-64-OK advisory
CC: (none) => davidwhodgins, sysadmin-bugsKeywords: (none) => validated_update
An update for this issue has been pushed to Mageia Updates repository. http://advisories.mageia.org/MGAA-2015-0194.html
Resolution: (none) => FIXEDStatus: ASSIGNED => RESOLVED