NVRM: failed to copy vbios to system memory. (Probable regression in ACPI since acpi-handle-hack fix) #628
Comments
|
@ArchangeGabriel - Here are the results of the requested infos: ` |
|
OK, so please do: And then paste here the added lines between the two dmesg as well as optirun output and content of |
|
@ArchangeGabriel dmesg diff: |
ArchangeGabriel
changed the title
|
OK, I’ve edited your message to keep only the interesting parts of it. So, this definitively looks like a regression in DSM handling, probably because of upstream fix for laptop needing acpi-handle-hack. @Lekensteyn This should be reported to kernel, against ACPI, right? Will you have some free time to look at this soon? |
|
Hi, I tested bumblebee 3.2.1 with Nvidia 346.47 on 3.16.7 kernel. I'm not sure what additional info should I provide here for helping further debugging this issue. |
|
You should first report the latest issue against bbswitch. Once solved, if it still doesn’t work, you might open an issue against bumblebee again, or against nvidia or kernel depending on what @Lekensteyn will say. Also, @Lekensteyn, any idea for the original issue here? |
|
@ArchangeGabriel I think my both issues (bbswitch & bumblebee) have the same root cause: video HW related ACPI calls not working OK on Asus EB1033. Now, as it looks like highest probability is in regression in Linux ACPI subsystem. Nvidia even mentioned this in their readme: VBIOS problem is result of underlying kernel/BIOS ACPI issues. What You think? |
|
Quite good analysis, but you’re wrong: Windows adds things to ACPI beyond specifications that most vendor implements and also Nvidia Optimus ACPI stuff is (was?) beyond specifications. And most vendors don’t respect specs anyway… So, either Linux ACPI is broken or incomplete, or your ACPI/BIOS is broken. But please open an issue against bbswitch to stop polluting this one that is normally not correlated and to get Lekensteyn. |
|
The handle (also, let's keep the discussion here to keep all information at one place) |
|
OK @Lekensteyn, but take care of the original reporter problem too. ;) |
|
Pls find decompiled DSDT/SSDT tables. |
|
I think GitHub doesn’t handle attachments. |
|
Oh - sorry for that. I wasn't aware of this. |
|
Bruno, Peter |
|
Peter is the one with enough knowledge to work on this, but he seems busy/away currently (like I was until today)… |
|
@warpme Could you open an issue here https://github.com/Bumblebee-Project/bbswitch/issues? Copy over the important part of your message plus link to the file. After that, I will clean this thread to keep only original poster issue. |
|
@Eccawchkup @warpme What the status here? |
|
I have also noticed exactly the same error in the OP after updating nvidia and bumblebee packages from Debian stable repository (bumblebee=3.2.1-7 and nvidia-driver=340.96-1) to the stable-backports versions (bumblebee=3.2.1-13 Since using the APT I had to upgrade both packages (and its dependencies), so I'm not sure which of them introduced the problem. Downgrading the packages back to its stable versions made the bumblebee integration work again. Is there anything I can do to help debug this problem (ie: building and installing the bumblebee from a specific git commit/branch, or anything else)? |
|
First of all, you can use bumblebee from jessie-backports with the drivers from jessie, there's no hard-dependency. Bumblebee in jessie-backports is basically the same version as the dev branch here on Github. Most importantly, we ship this in the README.debian in bumblebee's package: Jessie's kernel is 3.16, so please try that workaround and see if it helps you. |
|
@bluca Thanks for the answer! The workaround worked, sorry for posting here without checking the README file. Just a small question, does the configuration change fixes the problem or, by any way, it activates somekind of compatibility mode (with performance impact)? Thanks! |
|
I have not delved deeper into this issue since it doesn't happen anymore after kernel 3.19, so there's not much point in investigating it IMHO. As the others already said, it's probably something to do with ACPI and bbswitch. |
|
I'am not quite sure that this is the right thread, but I've run into the same issue with Fedora 24 (so linux kernel version is 4.7.5 > 3.19) and Geforce GT 540M: It fails with this error messages either with Driver=nvidia or Driver=nouveau. $ lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09)
01:00.0 VGA compatible controller: NVIDIA Corporation GF108M [GeForce GT 540M] (rev a1)
$ cat /proc/driver/nvidia/version
NVRM version: NVIDIA UNIX x86_64 Kernel Module 367.44 Wed Aug 17 22:24:07 PDT 2016My bumblbee.conf is (comments deleted): [bumblebeed]
VirtualDisplay=:8
KeepUnusedXServer=false
ServerGroup=bumblebee
TurnCardOffAtExit=false
NoEcoModeOverride=false
Driver=nvidia
[optirun]
VGLTransport=proxy
AllowFallbackToIGC=false
[driver-nvidia]
KernelDriver=nvidia
Module=nvidia
PMMethod=none
LibraryPath=/usr/lib64/nvidia-bumblebee:/usr/lib/nvidia-bumblebee:/usr/lib64:/usr/lib
XorgModulePath=/usr/lib64/nvidia-bumblebee/xorg,/usr/lib64/xorg/modules
XorgConfFile=/etc/bumblebee/xorg.conf.nvidia
[driver-nouveau]
KernelDriver=nouveau
PMMethod=auto
XorgConfFile=/etc/bumblebee/xorg.conf.nouveauIf there is any workarounds, let me know, please =) |
|
Hey, I've already tried to add the kernel-parameter "rcutree.rcu_idle_gp_delay=1" and I've also added the recommended ScreenSection with (Identifier "Default Screen") and (Device "DiscreteNvidia") to my xorg.conf.nvidia file. Is there anything more I can try? Thanks |
|
Those 2 workarounds solved the issue for everyone who has reported this to us on Debian. Is using the kernel from jessie-backports an option for you? |
|
I'm still getting this issue with kernel 4.12.7 on Gentoo. |
An user reported an issue with a Legacy Optimus setup, Asus UX50V with
NVIDIA Corporation G98M [GeForce G 105M]. I’m opening this issue for him, so that the discussion can take place here and maybe @Lekensteyn for instance could help at some point if ACPI appears to be indeed the root cause.The error is reported in Xorg.8.log by NVIDIA being unable to load the card and asking to look at dmesg, and they are the following interesting lines:
Note this is not #455, since the first line doesn’t appear in this case. This issue has often been seen as an issue with ACPI, either with the acpi-handle-hack in bbswitch and the corresponding issue upstream.
I think next step is to try with nouveau.
So, @Eccawchkup, could you report the result of the following commands:
Also, if you’re new to GitHub and Markdown, please take a look at the GitHub markdown syntax for posting logs and results in the good way.
The text was updated successfully, but these errors were encountered: