Bug 903360
| Summary: | ACPI device nodes lookup for the PCI bus type bug | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Gary Gatling <gsgatlin> | ||||||||
| Component: | kernel | Assignee: | Dave Airlie <airlied> | ||||||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
| Severity: | unspecified | Docs Contact: | |||||||||
| Priority: | unspecified | ||||||||||
| Version: | 18 | CC: | gansalmon, itamar, jonathan, kernel-maint, knabberknusperhaus, madhu.chinakonda, piruthiviraj, pv.bugzilla, s.binnie, stefano.sintoni.cnigroup, wendallc | ||||||||
| Target Milestone: | --- | ||||||||||
| Target Release: | --- | ||||||||||
| Hardware: | Unspecified | ||||||||||
| OS: | Unspecified | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2013-04-03 04:22:46 UTC | Type: | Bug | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
Gary Gatling
2013-01-23 19:46:32 UTC
I can confirm that gary's packages work well on my Lenovo Y580. It would be good if this patch is accepted. Dave, can you look this over? I know you're working in the optimus/switcheroo area, so you're better equipped to weigh in. 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. 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. 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. 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.) 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 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. 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. 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. 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> - 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. 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! 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. Sorry, should be: rpmbuild -ba --target=noarch kernel.spec and rpmbuild -ba --target=x86_64 kernel.spec to build new packages. 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
?
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. 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. @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. 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. (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. 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. @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. 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. Created attachment 710781 [details] correct patch from: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/?id=33f767d767e9a684e9cd60704d4c049a2014c8d5 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. +1 to include this into current fedora kernels, would bring relief to many people using lenovo laptops 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 ? +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 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. @ JB Efforts much appreciated for trying to bring to 3.8.5. kernel-3.8.5-201.fc18.x86_64.rpm fixes the problem on my Lenovo Y580 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 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). 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! 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. |