[SOLVED] nVidia Optimus / Bumblebee not working; Unknown header type 7f
SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
nVidia Optimus / Bumblebee not working; Unknown header type 7f
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.
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:
ERROR: could not insert 'nvidia': No such device
However, I see the nvidia module in /lib/modules/3.9.10/kernel/drivers/video/, so I'm at a loss to explain this.
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.
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:
[ERROR]Cannot access secondary GPU - error: [XORG] (EE) NVIDIA(0): Failed to assign any connected display devices to X screen 0
[ERROR]Aborting because fallback start is disabled.
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?
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.
Option "AutoAddDevices" "false"
Option "AutoAddGPU" "false"
VendorName "NVIDIA Corporation"
# If the X server does not automatically detect your VGA device,
# you can manually set it here.
# To get the BusID prop, run `lspci | egrep 'VGA|3D'` and input the data
# as you see in the commented example.
# This Setting may be needed in some platforms with more than one
# nvidia card, which may confuse the proprietary driver (e.g.,
# trying to take ownership of the wrong device). Also needed on Ubuntu 13.04.
# BusID "PCI:01:00:0"
# Setting ProbeAllGpus to false prevents the new proprietary driver
# instance spawned to try to control the integrated graphics card,
# which is already being managed outside bumblebee.
# This option doesn't hurt and it is required on platforms running
# more than one nvidia graphics card with the proprietary driver.
# (E.g. Macbook Pro pre-2010 with nVidia 9400M + 9600M GT).
# If this option is not set, the new Xorg may blacken the screen and
# render it unusable (unless you have some way to run killall Xorg).
Option "ProbeAllGpus" "false"
Option "NoLogo" "true"
Option "UseEDID" "false"
Option "UseDisplayDevice" "none"
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:
[ 116.231746] bbswitch: version 0.7
[ 116.231750] bbswitch: Found integrated VGA device 0000:00:02.0: \_SB_.PCI0.GFX0
[ 116.231753] bbswitch: Found discrete VGA device 0000:01:00.0: \_SB_.PCI0.PEG0.PEGP
[ 116.231959] bbswitch: detected an Optimus _DSM function
[ 116.231965] bbswitch: Succesfully loaded. Discrete card 0000:01:00.0 is on
[ 116.235161] bbswitch: disabling discrete graphics
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:
failed to load PRIMUS_LOAD_GLOBAL
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:
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.
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.