I had this working last month, but I just did a fresh install of Slackware64-14.0 so I had to reinstall it again. In that time, I see both the software and the Optimus wiki page for Slackware has been updated, and after following the instructions to the letter, it's not working.

I have a multilib enabled system, so I was very careful to use COMPAT32=yes on all the packages that were noted for it. Everything compiled and installed find, with no errors or anything. After starting bumblebeed and running optirun glxspheres, it always uses the Intel graphics instead.

I thought that perhaps something in the updated driver may not like the 3.2.29 kernel that comes with the default install, so I tried installing the 3.9.10 kernel from -current (keeping my old one of course), and rebuilt the bbswitch and nvidia-kernel packages, but after installing them it had no effect.

When I look at the output of lspci -v, directly below the nVidia line I see the following error:

!!! Unknown header type 7f

And if I try to modprobe nvidia, it says the module can't be found, although I see it listed under the modules folder.

So now I'm not sure where to go from here. Any help will be appreciated, as always.

Hmm.... lets start with the simple stuff... you have xf86-video-nouveau-blacklist installed correct?

The how-to and this readme should match up, but when in doubt... follow the README
https://github.com/jgeboski/Bumblebe.../master/README

I'll look back over the readme and how-to to see if somehow, something got missed tho.

That's correct, I installed it from the Slackware disc before beginning the procedure.

I looked through the README link you posted and from what I can tell it does indeed match up with what's on the wiki page. One thing I noticed was that not all of the packages were indicated to need 32 bit compatibility, and I only used the COMPAT32=yes option on the ones that were mentioned to have that option.

One other thing I thought I would mention was the problem I solved last month when I got this working the first time, in this thread. I had a segmentation fault issue when starting bumblebeed and we found it was required to use version 0.4.2 of libbsd rather than the 0.5.1 that came with the other files. I noticed this time that libbsd is now at version 0.6.0, which compiled and installed successfully, and I have not had that issue this time, so my thought was that this newer version had fixed whatever problem we had the last time.

When I run modprobe nvidia, I get this exact error:

However, I see the nvidia module in /lib/modules/3.9.10/kernel/drivers/video/, so I'm at a loss to explain this.

Hope that helps, and thanks for the reply!

Can you check /var/log/packages and be sure about the nouveau blacklist...

Going from here, and a fuzzy memory, that was what happens when its not blacklisted. I remember installing the blacklist, only to have slackpkg reinstall it because I forgot to blacklist the pkg.

http://docs.slackware.com/howtos:har...aphics_drivers

No problem, I actually did that before replying just to be extra sure. When I run find /var/log/packages -name *nouveau* I get the following two results:

I thought this should be the expected result, because the blacklist does not remove nouveau, only prevents it from loading during boot, correct?

On my system, it replaced it. Just removepkg the xf86-video-nouveau package to be sure, you may need to remove it twice, and reinstall the blacklist one. I think, since you did installpkg instead of upgradepkg, you now have both packages when you should only have one.

If my memory is not totally shot, I did that, made sure the blacklist file was in /etc/modprobe, and it all started working after a reboot.

OK, I tried this out, removed both nouveau packages, and reinstalled the blacklist package from the disc, and confirmed it worked by checking the output of find /var/log/packages -name *nouveau* to make sure I only saw the blacklist package listed. I also see a file BLACKLIST-nouveau.conf under /etc/modprobe.d/, containing the line blacklist nouveau.

After a reboot, I still see the !!! Unknown header 7f in the lspci output, and I get the same error when trying to run modprobe nvidia, so it appears to have made no change.

Any other ideas?

Well, I've been trying to work this out on my own over the last couple of days, and I just had an update.

Since I had this working before the latest update to the Bumblebee-SlackBuilds repository, I decided to try to downgrade to the 319.32 nvidia driver to see if that changed anything. I built it from the files on SlackBuilds.org, removed the nvidia-bumblebee and nvidia-kernel packages for the 325 driver, and installed these older 319 packages, and after a reboot the nvidia module seems to be loading correctly from what I can tell, so it seems like there's something up with this latest nvidia driver.

So after that, I went into X to try optirun glxspheres again, and now instead of rendering on the Intel hardware, it fails with the following error:

All the fixes I've found in regards to this error involved changing a parameter in /etc/bumblebee/xorg.conf.nvidia, but my file already has the recommended setting.

I suppose my next option is to start tinkering with these .conf files to see if I can make any progress, but I'll have to figure out which one does what first.

Just out of curiosity, if anyone has had success installing these latest updates and getting them working, I'd be interested to know. It seems like if there was a problem with the latest nvidia driver, it would have been caught when they were putting all the information together on the wiki, so I'm curious if I'm the only one having an issue with these new versions?

I had not updated to the lastest beta nvidia yet, so I reverted my github if you need it:

https://github.com/WhiteWolf1776/Bumblebee-SlackBuilds

Can you post your /etc/bumblebee/xorg.conf.nvidia up just to be sure... everything I see is also dealing with that file.

I'm built and running currently with slackware64-current / multilib and using exactly what is in my github repo.

Well I worked on this all day today, and I found something I missed earlier but it seems to not have helped. There was a little note about having to rebuild mesa on Slackware 14.0 and earlier, so I followed the instructions in the README, but it didn't fix the problem.

So I'm currently back on the 325.08 driver, directly from the repo in the wiki, along with the rebuilt mesa-compat32 from the README. If I run optirun glxspheres, it only renders on the Intel hardware. I still cannot load the nvidia module because it says it's not found, even if I give the full path to it.

Here's my /etc/bumblebee/xorg.conf.nvidia file, as requested.

I'm pleased to report that I finally figured out how to get this working!

First of all, my idea about the cause of the problem was incorrect. I thought that the nvidia kernel module was not loading, because I did not see it in the output of lsmod, and I could not load it manually. What really confused me was the output of dmesg | grep NVIDIA, which showed the following:

Looked like the nvidia module was indeed loading, and I didn't see any errors about it failing.

While I was poking around in the logs this morning, it finally dawned on me to take a look at the output of dmesg | grep bbswitch, and I saw this:

I had already discovered that bbswitch is what allows the enabling/disabling of the GPU, but after giving this some thought, I think it does its job by loading and unloading the kernel module as it is needed. That would explain why I didn't see it in the output of lsmod.

I was still suspicious about the whole Mesa library, and while I had taken great care to make sure I did it correctly, I decided to take another look at it. I thought I should give this new primus a try, as I had been using optirun during my testing, just to see if I get different results. While optirun would just render on the Intel hardware, primusrun actually gave this interesting error:

A little searching seemed to connect this error with the Mesa library, which made me think I was on the right track. I went through the whole rebuilding of the mesa-compat32 packages that's talked about here, which required a little inspiration to fill in the missing parts, but while pondering it this morning a light bulb came on...maybe I need to rebuild them both?

So, I rebuilt the 64-bit Mesa package as well, and after installing it...it works! This particular step is mentioned in the wiki, but doesn't go into detail about it, and the README on github didn't make it clear to a less experienced slacker that rebuilding both was mandatory. So, in order to help anyone that runs into this problem, here's a little more detail about this section of the installation.

How I Fixed The Problem

Take note that I'm running Slackware64 14.0 multilib, so if you're running something different you'll most likely have to modify these steps to your particular system. Be careful!

First, I needed some packages from the 32-bit version of Slackware, which can be downloaded from the website. Change into the mesa directory under Bumblebee-SlackBuilds, and issue the following commands:
Next, I had to run the commands mentioned in the README. I like to move them from /tmp into the build directory so I have them for later, which has been incredibly helpful on numerous occasions.
Now, because I'm running Slackware64 14.0 with multilib, I have to run both of the SlackBuild scripts included.
Then I had to upgrade the 64-bit Mesa package that came with the install, and also Alien Bob's mesa-compat32 package that was installed with the multilib procedure. Note the percent signs, which are necessary because the newly rebuilt packages have different names.
And I believe that was it. After doing this, I started X again, and primusrun glxspheres is now rendering on the nvidia GPU. This was the only part of the install that threw me off, I followed all the other steps listed on the Slackware optimus wiki page exactly as they are.

One thing that I noticed when upgrading the mesa-compat32 package, was that a single file was deleted called libEGL.so, so I now only have the 64-bit version of this file. I'm not sure if this could be a problem down the road, so if anyone could shed some light on this it would be appreciated.

One last observation, was that the original error !!! Unknown header 7f still appears in the output of lspci, even though everything is working correctly. I'm not sure what this means exactly, but it doesn't appear to cause any problems.

Thank you WhiteWolf1776 for helping me out with this issue. I would guess I'm not the only one that has run into this little problem, so hopefully this will help others to get this working.

Happy you found it Sorry, I had assumed you had recompiled both mesa packages, not just the compat32 one... but that is what I get for assuming again.

14.1 will, thankfully, not require any mucking around with mesa, but I will update the how-to and add some of your points to the troubleshooting bit.

full steam ahead.

That's alright, I'm sure it would have been obvious to the veterans, but I'm still figuring all these bits and pieces out. It was a good training exercise, for sure!

Do you happen to know anything about the libEGL.so file that was deleted during the mesa-compat32 upgrade? I'm a little concerned that only having the 64-bit version of that file might break something later, but I couldn't find out much about it.

I'm sorry, not sure about that lib. So far I have played about every 3d game I have tho, without fail, steam apps, etc.

If you get a chance, please check:
http://docs.slackware.com/howtos:har...ling_bumblebee

and let me know if the primus instructions are clear. Sometimes I don't know what is clear to folks and what isn't

I had a chance to look at your edits, and I do think it's more clear now.

I might recommend breaking the mesa-compat32 command off into its own block and placing it below the warning though, so it stands out more.

Thank you very much for updating that!