-
Notifications
You must be signed in to change notification settings - Fork 130
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can't insert kernel module after turning on discrete card #4
Comments
To repeat myself, the methods used in various laptops are vendor-specific and undocumented. AFAIK there is no way to know exactly what methods to use to correctly turn the GPU off and on again. The "off" methods are guessed by their name and shown to "work" in that they decrease the power usage. We do not know if this is the correct way to turn it off, and do not know the necessary steps to turn it off again. IMO the only way to do this correctly is to reverse-engineer the process directly in Windows using ACPI debugging tools available in Checked Builds of Windows. Unfortunately, I do not have access to such builds (they are available for MSDN subscribers). |
acpidump is your friend ! In fact, reversing in the only correct way to do it. |
Sorry for bothering, but how to use it? I'll work on it by myself... I've created the DSL files with: now what...? |
You have to read the DSDT and SSDT files looking for the commands that power on/off your card and then reverse them. I'm doing this for as much models as possible, but I'm lacking time. |
It seems that _OFF and _ON work (the led on the laptop changes color and the battery lasts much more), but after turning on the card it's impossibile to modprobe nvidia driver: the output is Is there a way to find which command combination is the right one? |
The only way to do it is reversing, but I think that you're problem isn't related to the ACPI calls. Can you upload the /etc/X11/xorg.conf.nvidia file ? |
Here is the xorg.conf.nvidia generated by bumblebee: Section "DRI" Section "ServerLayout" Section "Module" Section "Files" Section "Device" Section "Screen" Section "Extensions" Section "Monitor" |
Could you try to replace CRT-0 by DFP-0 and see if there is any changes ? And could you upload the Xorg.1.log file ? |
Changing to DFP-0 doesn't change anything (I changed to CRT-0 to see if anything's was different). BTW, the Xorg.1.log says: "Invalid ConnectedMonitor request; request was for 'DFP-0', but the valid display devices are 'CRT-0'." Here's the Xorg.1.log file after a clean reboot: [ 207.102] 207.624 xf86OpenConsole: setpgid failed: Operation not permitted |
Ok, replace DFP-0 by CRT-0 and upload the new Xorg.1.log |
Here it is. Now I have an error on nvidia driver... very strange... [ 1573.867] |
1574.862 NVIDIA: Failed to load the NVIDIA kernel module. Please check your The problem is here effectively. What gives the system's kernel log ? (dmesg) |
well... I really don't understand... I have rebooted the system and I don't find the previous error. Moreover I get this one: |
Hum... It seems that something replaced your xorg.conf.nividia. Could you sudo edit it and replace DFP-0 by CRT-0 and try again ? |
I think the problem does not belong to the Xorg side. Even without bumblebee enabled you can turn on/off the card but then you can't insert the nvidia kernel module (or any other) is like the kernel knows the card is there but cannot identify it. The last was a guess, I'm not a kernel expert but seems that the problem is in the kernel side. |
You're probably right, I didn't see he was using an 2.6.37 kernel... Maybe with a 2.6.38 one or 2.639... |
I'm using 2.6.39. Had no luck. Maybe if you don't remove the nvidia module before turning off? Make sure it's not used by bumblebee or any other X server or your system will freeze. I remember I could turn off, then on and be capable of using it again, could not reproduce that again )': Maybe a firmware issue? |
I can confirm: no change with kernel 2.6.39. |
Try this: There is a sort of database with all DSDTs submitted so far. |
Done. Thank you! |
Resolve install failure
Now I think this issue become relevant since we are able to actually use the discrete card without a hardware mux (thanks to Bumblebee). So here comes the second part of the problem: turning the discrete card back on and be able to use it.
I've called method "_SB.PCI0.P0P1.PEGP._OFF" to turn off the card. It worked fine since the power consumption went down about 30% ~ 40%
When calling "_SB.PCI0.P0P1.PEGP._ON" (I was guessing about the on) i got the card back consuming power, the kernel recognizes it "lspci -k" lists it and the modules available to use with it but when i try to modprobe nvidia module or nouveau module I got an error: No Such Device (the nouveau driver actually prints nothing but is not loaded)
I'm using a Dell Vostro 3500 and the DSDT.dsl and SSDT tables are listed according to http://linux-hybrid-graphics.blogspot.com/ in the Launchpad tracker:
https://bugs.launchpad.net/lpbugreporter/+bug/752542/+attachment/2149902/+files/Vostro%203550.tar.gz
I'm not looking for a solution to my case in particular but for an increasing number of users. Here is a GitHub issue that was opened in Martin's bumblebee tracker: https://github.com/MrMEEE/bumblebee/issues/229
Apparently there are some steps missing in turning on/off discrete card.
Thank you very much for your effort and we are almost there in Optimus support
The text was updated successfully, but these errors were encountered: