This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 903360 - ACPI device nodes lookup for the PCI bus type bug
ACPI device nodes lookup for the PCI bus type bug
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
18
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Dave Airlie
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-01-23 14:46 EST by Gary Gatling
Modified: 2013-04-03 00:22 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-04-03 00:22:46 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
fixes bug in drivers/acpi/glue.c (905 bytes, patch)
2013-01-23 14:46 EST, Gary Gatling
no flags Details | Diff
Fix for certian laptop models kernel bug 3.8 series (3.99 KB, patch)
2013-03-09 16:33 EST, Gary Gatling
no flags Details | Diff
correct patch (2.47 KB, patch)
2013-03-15 14:05 EDT, Gary Gatling
no flags Details | Diff

  None (edit)
Description Gary Gatling 2013-01-23 14:46:32 EST
Created attachment 686239 [details]
fixes bug in drivers/acpi/glue.c

Description of problem:

Using Red Hat Linux on certain motherboards, the discrete video card cannot be used. An error message is displayed on the console at startup:

[    4.501782] nouveau 0000:01:00.0: Invalid ROM contents
[    4.501813] [drm] nouveau 0000:01:00.0: ... BIOS signature not found
[    4.501814] [drm] nouveau 0000:01:00.0: No valid VBIOS image found
[    4.501839] vga_switcheroo: disabled


Such motherboards cannot access the discrete video card to access their hybrid graphics with the nouveau driver. This problem is caused by a bug in the Linux kernel. It will possibly be fixed in kernel 3.8 or 3.9 but older kernels, such as the one in fedora 18, kernel 3.7.2-204.fc18.x86_64 still contain this flaw.

Version-Release number of selected component (if applicable):

Kernel 3.7.2-204.fc18.x86_64 and all older Red Hat kernels are affected by this problem.

How reproducible:

Obtain one of the following P.C. systems. Others may be affected. This is all we know of so far:

Lenovo IdeaPad Y470
Lenovo IdeaPad Y480
Lenovo IdeaPad Y570
LENOVO IDEAPAD Y570 /* sys-product-name: PIQY0 */
Lenovo IdeaPad Y580
PSPLBE-01V00HFR      /* TOSHIBA SATELLITE P870 */
Lenovo G580
Lenovo G780

Steps to Reproduce:
1. Boot system. Notice how you receive error message about invalid nouveau rom at boot.
2. Attempt to access your hybrid graphics through such popular software as bumblebee. It will not work because the vga_switcheroo function in the kernel is disabled. Thus, a second x windows screen cannot be created and the discrete video card is not able to be used.
  
Actual results:

[gsgatlin@y470 ~]$ optirun glxgears
[   72.307547] [ERROR]Cannot access secondary GPU - error: [XORG] (EE) Failed to load module "mouse" (module does not exist, 0)

[   72.307667] [ERROR]Aborting because fallback start is disabled.


Expected results:

[gsgatlin@y470 ~]$ optirun glxgears

(A window opens with spinning GLX gears in it)

http://i.imgur.com/mLCadjJ.png

(I versioned my test kernel "205")

Additional info:

This issue is in a bugzilla upstream:

https://bugzilla.kernel.org/show_bug.cgi?id=42696

A fix was decided upon here for 3.8 or 3.9:

https://patchwork.kernel.org/patch/1917651/

This issue was first discovered a while back and was discussed on these discussion threads:

https://github.com/Bumblebee-Project/Bumblebee-old/issues/149
https://github.com/Bumblebee-Project/bbswitch/issues/2

I have a patch for this problem that was created by Lekensteyn, one of the bumblebee developers who has looked deeply into this problem. I will attach it to this bug report. I have verified that this fixes the issues on a Lenovo Y470 running fedora 18. Someone else has verified this fixes the issues on a Lenovo Y580 with fedora 18. I will test the RHEL 6 kernel next to see if this patch also fixes that distros kernel. If it does, I will file a separate bugzilla report about that within a few days.
Comment 1 Piruthiviraj Natarajan 2013-01-23 22:07:35 EST
I can confirm that gary's packages work well on my Lenovo Y580. It would be good if this patch is accepted.
Comment 2 Josh Boyer 2013-01-24 09:20:53 EST
Dave, can you look this over?  I know you're working in the optimus/switcheroo area, so you're better equipped to weigh in.
Comment 3 Phil V 2013-03-09 14:59:36 EST
Any news?

I have this same bug with Toshiba Satellite P870-BT3G22.

optirun glxgears -info
[  103.289035] [ERROR]Cannot access secondary GPU - error: [XORG] (EE) Failed to load module "mouse" (module does not exist, 0)

[  103.289092] [ERROR]Aborting because fallback start is disabled.
Comment 4 Gary Gatling 2013-03-09 16:33:27 EST
Created attachment 707591 [details]
Fix for certian laptop models kernel bug 3.8 series

This patch changed a bit for the 3.8 kernel. So here is the patch.
Comment 5 Gary Gatling 2013-03-09 16:42:02 EST
I have created test kernels based on this patch here:

http://install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee/kernelbug/fedora18-bz903360/

Also, I have acquired a used Lenovo ideapd Y470 to donate to Red Hat to help get this issue solved for https://bugzilla.redhat.com/show_bug.cgi?id=907241

Waiting to hear back if its better to wait until RHEL 7 comes out or if its ok to mail it now and they could keep it long enough to test with a potential RHEL 7 bugzilla report.

Little bit of an update on whats going on.
Comment 6 Phil V 2013-03-09 23:07:57 EST
Gary I have run the following:

rpm -Uvh kernel-devel-3.8.1-202.bz903360.fc18.x86_64.rpm kernel-headers-3.8.1-202.bz903360.fc18.x86_64.rpm 
rpm -ivh kernel-3.8.1-202.bz903360.fc18.x86_64.rpm 
reboot

but regret that the results are the same as before:

$ optirun glxgears -info
[   97.384631] [ERROR]Cannot access secondary GPU - error: [XORG] (EE) Failed to load module "mouse" (module does not exist, 0)

[   97.384722] [ERROR]Aborting because fallback start is disabled.
[a@localhost ~]$ uname -a
Linux localhost.localdomain 3.8.1-202.bz903360.fc18.x86_64 #1 SMP Tue Mar 5 15:03:25 EST 2013 x86_64 x86_64 x86_64 GNU/Linux

Was there something else I should have done?
How can I provide more specific information?

Also no better results from the acpi-handle-hack-...1.fc18  (Your webpage suggested that it was just for RHEL but it said .fc18 so I gave it a try.)
Comment 7 Phil V 2013-03-09 23:21:40 EST
dmesg reports switcheroo enabled. Have not tested yet.
Oddly the videocard temperature sensor no longer appears in the gkrellm list of available sensors.

$ dmesg |grep -i vga
[    0.312504] vgaarb: device added: PCI:0000:00:02.0,decodes=io+mem,owns=io+mem,locks=none
[    0.312511] vgaarb: device added: PCI:0000:01:00.0,decodes=io+mem,owns=none,locks=none
[    0.312514] vgaarb: loaded
[    0.312515] vgaarb: bridge control possible 0000:01:00.0
[    0.312517] vgaarb: no bridge control possible 0000:00:02.0
[    0.711836] fb0: EFI VGA frame buffer device
[    2.651201] fb: conflicting fb hw usage inteldrmfb vs EFI VGA - removing generic driver
[    2.652651] VGA switcheroo: detected Optimus DSM method \_SB_.PCI0.PEG0.PEGP handle
[    2.671003] vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=none:owns=io+mem
[    2.671006] vgaarb: transferring owner from PCI:0000:00:02.0 to PCI:0000:01:00.0
[    4.751096] vga_switcheroo: enabled
[    7.025329] bbswitch: Found integrated VGA device 0000:00:02.0: \_SB_.PCI0.GFX0
[    7.025336] bbswitch: Found discrete VGA device 0000:01:00.0: \_SB_.PCI0.PEG0.PEGP
[    7.034138] vga_switcheroo: disabled
[   95.933822] VGA switcheroo: detected Optimus DSM method \_SB_.PCI0.PEG0.PEGP handle
[   97.000967] vga_switcheroo: enabled
Comment 8 Gary Gatling 2013-03-09 23:26:02 EST
Hello.

Due to this bug:

https://github.com/Bumblebee-Project/Bumblebee/issues/298

optirun will not work on fedora 18 with the nouveau drivers.

It does work on Fedora 17 and RHEL 6.

To test on Fedora 18, you must use the proprietary nvidia drivers as described at:

 
http://techies.ncsu.edu/wiki/bumblebee#Nvidia_drivers

Or we need to figure out how to fix issue 298 at github.

Sorry about that.
Comment 9 Gary Gatling 2013-03-09 23:32:10 EST
Fedora 17 test kernels (with the 3.7 patch) are at:

http://install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee/kernelbug/fedora17-bz903360/

If that helps.
Comment 10 Phil V 2013-03-10 03:14:20 EDT
Gary, 'optirun glxgears' now works on Toshiba P870-BT3G22! Thank you so much!

after installing the packages from the bumblebee repo, your kernels, and 
yum -y --nogpgcheck install http://install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee-nonfree/fedora18/noarch/bumblebee-nonfree-release-1.0-1.noarch.rpm
yum install bumblebee-nvidia
reboot

'optirun glxgears' now works! Thank you so much for your work!

Q: How do we reproduce this for future kernels though?
I've looked inside the .rpm and it's not clear how to proceed.
If this will be mainstreamed quickly I suppose I don't need to know ;)


FYI:
time glxspheres -f 1000 >> glxspheres.log
time optirun glxspheres -f 1000 >> glxspheres.log
time glxspheres -f 10000 >> glxspheres.log
time optirun glxspheres -f 10000 >> glxspheres.log

shows that when considering user+system time, using the discrete graphics card puts a 4% - 7% extra overhead on the cpu.
Comment 11 Gary Gatling 2013-03-10 05:28:28 EDT
Here is the diff in the spec file for the kernel:

[gsgatlin@localhost specs]$ diff kernel.spec-bug kernel.spec-bugfix
37,38d36
< %define buildid .bz903360
< 
67c65
< %global baserelease 202
---
> %global baserelease 201
761d758
< Patch25100: PCI-ACPI-Rework-ACPI-device-nodes-lookup-for-the-PCI-bus-type.patch
1468c1465
< ApplyPatch PCI-ACPI-Rework-ACPI-device-nodes-lookup-for-the-PCI-bus-type.patch
---
> 
2326,2328d2322
< * Tue Mar 5 2013 Gary Gatling  <gsgatlin@ncsu.edu> - 3.8.1-202
< > - Add patch to fix optimus issues (rhbz 903360)
< 


Basically, add the "%define buildid .bz903360" line near where it tells you to add that. Bump the "%global baserelease" by +1. Then add the lines for 
"PatchXXXXX" and "ApplyPatch"

I made it be the last patch. But it can probably work in any order.

I have no idea when this might get fixed. So you might need to build your own kernels for a while. Cheers.
Comment 12 Phil V 2013-03-10 14:38:01 EDT
I was hoping there would be a Gatling gun for patched linux kernels.



Until then, for kernel-building-newbies, which instructions on kernel building do you recommend?

If I follow http://fedoraproject.org/wiki/Building_a_custom_kernel

it says, 
'Enable the appropriate source repositories with the --enablerepo switch.'

what are the 'appropriate source repositories' in this case?
bumblebee's ? linux kernel ? both?

Thank you for your help!
Comment 13 Gary Gatling 2013-03-10 14:55:46 EDT

Well, what I do, is enable the /etc/yum.repos.d/fedora-updates-testing.repo

file by editing it and changing

enabled=0

to 

enabled=1

Then I 

yum update kernel

But I answer "n" to downloading it. I make a note of the version that is coming out soon. I re-edit /etc/yum.repos.d/fedora-updates-testing.repo, change it back to enabled=0, then I do a yum clean all.


Next, Google the kernel version and find a package to download.

Next, I install the package:

rpm -ivh kernel-X.X.X-XXX.fc18.src.rpm


Add the patch file to the SOURCES directory. Fix up the spec file as described above. Next I do:

rpmbuild -ba --target=noarch

wait a long time...

Then do

rpmbuild -ba --target=x86_64

and then after a while all the rpms should be built. Hope that helps. I'm honestly not sure what you need to do with a vanilla kernel from kernel.org. Sorry about that.
Comment 14 Gary Gatling 2013-03-10 14:57:34 EDT
Sorry, should be:

rpmbuild -ba --target=noarch kernel.spec

and


rpmbuild -ba --target=x86_64 kernel.spec

to build new packages.
Comment 15 Phil V 2013-03-10 15:21:22 EDT
Gary,
does
     'Google the kernel version and find a package to download.'
mean
     'manually download the fedora .rpm ?'

And would that be the same as 

yumdownloader --disablepresto  kernel

?
Comment 16 Gary Gatling 2013-03-10 15:38:30 EDT
I guess maybe it would be?


yumdownloader --source kernel

as a regular user.

But it did not work for me for some reason. So by google I mean manually download it from some web site such as:

http://pkgs.org/

After constructing a search string in google.com based on what the package name should be. Maybe it will work for you though?

I'm sorry. There are probably better ways to do this. But I'm kind of new around here and I'm not one of the kernel maintainers. I just maintain one package so far in fedora. I actually use RHEL 6 as my main OS at work and at home and I only put fedora on my spare to get ready for RHEL 7 whenever it comes out. But I also do want to help out the fedora community and stay on top of where Red Hat is going. So I'm both a RHEL and a fedora user I guess.

If I used fedora as my main desktop I'd be compiling these kernels way more often but I find the environment to be too volatile to use as my main OS on my laptop. I'm really sorry about that. I do own two (now 3, one I'm giving to Red Hat) such affected laptops so I do want to get this bug fixed. If you check

http://install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee/kernelbug/fedora18-bz903360/

every so often there will probably be new kernels there fairly often as I continue to try to develop various hybrid graphics rpm packages for fedora/RHEL until optimus is more "officially" supported. Just can't make any promises about how often that would be.

Hope that helps.
Comment 17 Piruthiviraj Natarajan 2013-03-11 22:41:52 EDT
It doesn't appear to be much of an interest from the fedora kernel team regarding this bug, even though there is a patch already available.
Comment 18 Piruthiviraj Natarajan 2013-03-11 22:45:14 EDT
@gary 
Do you mind adding your kernel related binaries in a seperate repo? It would be easier for the user until this gets fixed by rafel.
Comment 19 Gary Gatling 2013-03-11 22:56:38 EDT
Hmnn. Yeah. I guess if you put:

exclude=kernel*

in all the various repo files but a "lenovo kernel" repo file or whatever that might work. It could get behind / out of date fairly quickly but that could also make it easier for me also just for testing stuff. I will work on trying to set that up this week if there is time.
Comment 20 Josh Boyer 2013-03-12 08:31:37 EDT
(In reply to comment #17)
> It doesn't appear to be much of an interest from the fedora kernel team
> regarding this bug, even though there is a patch already available.

We have over 1000 bugs for 3 people to work on.  Sometimes bugs get missed.

Looking over this again, the patch pointed to might work but it isn't upstream and the upstream maintainers said it isn't the proper solution.
Comment 21 Gary Gatling 2013-03-12 09:54:08 EDT
Josh,

I completely understand. I filed this bug more as a "this is a problem" kind of thing so that whenever they fix it upstream, you guys could determine if this would work as a backport kind of fix. Not sure if it would get fixed in Linux 3.9. Or if it did, if the last patch I uploaded would be appropriate.

Thanks a lot for looking into it. I can still compile my own kernels when I need to for fedora. I'm not smart enough to create or understand these patches however. :) Cheers.
Comment 22 Piruthiviraj Natarajan 2013-03-13 12:35:58 EDT
@Josh
Not that I try to belittle your efforts, I understand your situation, But a simple message(like how the upstream didn't prefer the solution) about what's going on would have been sufficient for people who follow this bug report.You asked Dave to look into this bug, but how will we know what going on if there is no message after months of waiting. 

@gary
For doing a vanilla kernel compilation all you need to do is to strip out all the patches which are Fedora specific from the .spec file and apply the only ones which are essential to proper building, even though I would not prefer this solution.
For having the vanilla kernel feel, I always stick with Arch Linux kernel, which has almost like no patches compared to Fedora or Debian.


For all this time there there was a workaround for this bug, but with kernel 3.9 there doesn't seems to be one until now.
Comment 23 Piruthiviraj Natarajan 2013-03-15 02:53:28 EDT
The issue is fixed in 3.9 rc2 in arch linux mainline kernel from upstream. Still don't know which commit fixed it. Have  not tried in Fedora, So its matter of time it gets backported to older kernels.
Comment 25 Gary Gatling 2013-03-15 14:10:23 EDT
Good afternoon.

I have just discovered this patch I have uploaded from Peter Wu in the githunb issue on this subject today. He is the person who first identified this bug.

Here is the URL for the commit:


http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=33f767d767e9a684e9cd60704d4c049a2014c8d5

I have created test kernels at:

http://install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee/kernelbug/fedora18-bz903360/

I have verified this fixed the issue on fedora 18 Linux distro with a Lenovo Ideapad Y470 notebook computer.

Thank you for your consideration.
Comment 26 Lukas Lueg 2013-03-16 09:14:28 EDT
+1 to include this into current fedora kernels, would bring relief to many people using lenovo laptops
Comment 27 Stefano Sintoni 2013-03-19 11:49:07 EDT
I have one Lenovo W530 with this problem when I try to force the NVIDIA-only from BIOS (discrete adapter)
I use FC18 and kernel 3.8.3-201.
Someone has already configured the NVIDIA K2000M on Lenovo W530 ?
Comment 28 Phil V 2013-03-24 22:23:26 EDT
+1 to include this into current fedora kernels, would bring relief to many people using Toshiba laptops as well.


http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=33f767d767e9a684e9cd60704d4c049a2014c8d5
Comment 29 Josh Boyer 2013-03-25 10:52:26 EDT
I've asked the upstream stable maintainers if they would be willing to bring this into 3.8.5.  Let's see what they say before we bring it into Fedora as a stand-alone patch.
Comment 30 Piruthiviraj Natarajan 2013-03-25 11:44:27 EDT
@ JB
Efforts much appreciated for trying to bring to 3.8.5.
Comment 31 Lukas Lueg 2013-03-29 18:21:19 EDT
kernel-3.8.5-201.fc18.x86_64.rpm fixes the problem on my Lenovo Y580
Comment 32 Fedora Update System 2013-04-01 09:29:48 EDT
kernel-3.8.5-201.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/kernel-3.8.5-201.fc18
Comment 33 Fedora Update System 2013-04-01 18:33:39 EDT
Package kernel-3.8.5-201.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing kernel-3.8.5-201.fc18'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-4645/kernel-3.8.5-201.fc18
then log in and leave karma (feedback).
Comment 34 Gary Gatling 2013-04-02 20:40:34 EDT
Hello. BY the time I could log in, the karma was at 3. But this fixes my issues on a Lenovo ideapad y470 notebook. Thank you SO much!
Comment 35 Fedora Update System 2013-04-03 00:22:48 EDT
kernel-3.8.5-201.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.