You are not logged in.
Nope. Anything you install via yaourt goes through pacman, and should show up in your logs.
I double checked, and I found my fez installation (AUR through yaourt) in my log.
Try (re)installing the latest non-testing version of all related software (linux, nvidia, nvidia-libgl, nvidia-utils, systemd).
If the error shows up, check your X logs (/var/log/Xorg.0.log) and system logs (sudo journalctl -xn).
I think the error you got was unrelated to the issue in this topic.
Offline
I just tried nvidia 325.15-1 with Linux 3.11.1-1, and it didn't work. Same error as OP. Maybe I will try ck later, when I'm not in a defeatist mood.
[ 34.636] (EE) NVIDIA(0): Failed to initialize the NVIDIA GPU at PCI:1:0:0. Please
[ 34.636] (EE) NVIDIA(0): check your system's kernel log for additional error
[ 34.636] (EE) NVIDIA(0): messages and refer to Chapter 8: Common Problems in the
[ 34.636] (EE) NVIDIA(0): README for additional information.
[ 34.636] (EE) NVIDIA(0): Failed to initialize the NVIDIA graphics device!
[ 34.636] (EE) NVIDIA(0): Failing initialization of X screen 0
[ 34.636] (II) UnloadModule: "nvidia"
[ 34.636] (II) UnloadSubModule: "shadow"
[ 34.636] (II) UnloadSubModule: "wfb"
[ 34.636] (II) UnloadSubModule: "fb"
[ 34.636] (EE) Screen(s) found, but none have a usable configuration.
Offline
Thanks TBoshoven. I did and get the same error.
I just tried nvidia 325.15-1 with Linux 3.11.1-1, and it didn't work. Same error as OP. Maybe I will try ck later, when I'm not in a defeatist mood.
[ 34.636] (EE) NVIDIA(0): Failed to initialize the NVIDIA GPU at PCI:1:0:0. Please [ 34.636] (EE) NVIDIA(0): check your system's kernel log for additional error [ 34.636] (EE) NVIDIA(0): messages and refer to Chapter 8: Common Problems in the [ 34.636] (EE) NVIDIA(0): README for additional information. [ 34.636] (EE) NVIDIA(0): Failed to initialize the NVIDIA graphics device! [ 34.636] (EE) NVIDIA(0): Failing initialization of X screen 0 [ 34.636] (II) UnloadModule: "nvidia" [ 34.636] (II) UnloadSubModule: "shadow" [ 34.636] (II) UnloadSubModule: "wfb" [ 34.636] (II) UnloadSubModule: "fb" [ 34.636] (EE) Screen(s) found, but none have a usable configuration.
vimtutorial - VIMperator - vimprobable2
Offline
I have a Y500 and the -ck packages work for me without issue (as of yet).
The core packages do not - I get a fast crash without persistence mode with the core packages. If I turn on persistence mode, I get a fallen off the bus issue with the core packages.
If anyone is trying the -ck method, verify you have booted a -ck kernel before trying to load/use nvidia-ck
Offline
Check if booting with rcutree.rcu_idle_gp_delay=1 or running
sudo tee /sys/module/rcutree/parameters/rcu_idle_gp_delay <<<1
before loading the nvidia kernel module makes things better.
This fixed it for me. Thanks for tip.
Offline
It's working now \o/
But I have one more question, does anyone was able to have the SLI working again?
I am always having this same error no matter what config I try on xorg.conf
6.871] (**) NVIDIA(0): Option "SLI" "on"
[ 6.871] (**) NVIDIA(0): NVIDIA SLI auto-select rendering option.
[ 6.871] (**) NVIDIA(0): Enabling 2D acceleration
[ 11.615] (EE) NVIDIA(0): Failed to find a valid SLI configuration.
[ 11.615] (EE) NVIDIA(0): Invalid SLI configuration 1 of 1:
[ 11.615] (EE) NVIDIA(0): GPUs:
[ 11.615] (EE) NVIDIA(0): 1) NVIDIA GPU at PCI:1:0:0
[ 11.615] (EE) NVIDIA(0): 2) NVIDIA GPU at PCI:2:0:0
[ 11.615] (EE) NVIDIA(0): Errors:
[ 11.615] (EE) NVIDIA(0): - Trouble accessing PCI Config Space
[ 11.615] (WW) NVIDIA(0): Failed to find a valid SLI configuration for the NVIDIA
[ 11.615] (WW) NVIDIA(0): graphics device PCI:1:0:0. Please see Chapter 29:
[ 11.615] (WW) NVIDIA(0): Configuring SLI and Multi-GPU FrameRendering in the README
[ 11.615] (WW) NVIDIA(0): for troubleshooting suggestions.
any ideas?
Offline
I just tested on linux-lts 3.10.12 and I custom compiled (not really custom since it's based on repo-ck configs, but nonetheless doesn't exist in a repo) a linux-lts-ck 3.10.12. Both have the driver fall off the bus. So the systemd update isn't really doing much.
Last edited by vishwin (2013-09-25 04:31:29)
ThinkPad W550s: Intel Core i7-5500U | 8 GB DDR3L RAM | Nvidia Quadro K620M 2 GB DDR3 VRAM | 128 GB SSD | 1 TB WD Blue HDD
Retired: Lenovo IdeaPad Y580
Offline
Anyone using SLI here?
I am still facing the same issue when trying to configure SLI.
[ 11.615] (EE) NVIDIA(0): - Trouble accessing PCI Config Space
[ 11.615] (WW) NVIDIA(0): Failed to find a valid SLI configuration for the NVIDIA
[ 11.615] (WW) NVIDIA(0): graphics device PCI:1:0:0. Please see Chapter 29:
[ 11.615] (WW) NVIDIA(0): Configuring SLI and Multi-GPU FrameRendering in the README
[ 11.615] (WW) NVIDIA(0): for troubleshooting suggestions.
Offline
I have to say, that I can't update to more current kernel/nvidia combination either. Currently I'm on 3.11.0-1 together with nVidia 325.15-1. This combination works flawlessly. Updating to a newer version of nvidia / linux however caused the same issues than before, fan speeding up during booting and whole system is down after 10 sec.
Offline
There is a new BETA driver! If anyone has time to test it with a regular kernal and report back, that would be great!
Offline
There is a new BETA driver! If anyone has time to test it with a regular kernal and report back, that would be great!
One report from the nvidia forum thread indicates that the bug is not fixed. I haven't seen anyone claim otherwise.
Offline
Tested it, does not work. Also, there was some Talk on the Nvidia Forums about why it does not work with newer kernels, but i cannot find the post…
Offline
Ugh...this is absolutely ridiculous.
Offline
Old but gold,
F_ck you Nvidia! By Linus; http://www.youtube.com/watch?v=IVpOyKCNZYw
Offline
Funny thing noticed:
I've already settled for starting kdm manually after log-in.. but now I wanted to try Gnome because I'm getting a little bit pissed off by KDE's slowness, and I noticed, that Gnome is not starting... it ends with these messages in journalctl
okt 18 18:35:26 destiny kernel: nvidia 0000:01:00.0: irq 48 for MSI/MSI-X
okt 18 18:35:26 destiny kernel: ACPI Warning: \_SB_.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20130517/nsarguments-95)
.... [9 times the same]
okt 18 18:35:26 destiny kernel: ACPI Warning: \_SB_.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20130517/nsarguments-95)
okt 18 18:35:27 destiny kernel: nvidia 0000:02:00.0: irq 49 for MSI/MSI-X
okt 18 18:35:27 destiny systemd-logind[391]: Removed session 8.
This is on Linux 3.11-1 + nVidia 325.15-7.. KDM + KDE working normally if I start them with delay after boot, GDM/Gnome/Unity end up with these messages...
TBoshoven or anyone else on Y500, are you seeing these too or Gnome starts alright for you? And has anyone tried linux 3.12 with latest nvidia-beta if it isn't resolved yet?
Offline
I have not experienced this issue since the 3.11.1 kernel, until today. I want to point out that I do not understand why it would happen as there were no changes to my system. I have had several reboots since the 3.11.6 kernel without any problems. Then suddenly now I got the exact same symptoms again. I start X from console after boot, but my computer just died. When I turned on my laptop again, X started normally without any issue. I also made another reboot where I made sure to start X as soon as I could, and it launched without issue.
So the problem is definitely not solved, but obviously difficult to nail down since the nvidia devs have yet to solve the problem. I will also report this on the nvidia forum.
Offline
On W530 with K2000M it works with linux-ck-ivybridge (3.11.6-1) and nvidia-ck-ivybridge (325.15-8), hovever it needs rcutree.rcu_idle_gp_delay=1 as a kernel option in grub.
I've tried several reboots and logouts (I have kde (kdm)). So far, it always worked.
Offline
Check if booting with rcutree.rcu_idle_gp_delay=1 or running
sudo tee /sys/module/rcutree/parameters/rcu_idle_gp_delay <<<1
before loading the nvidia kernel module makes things better.
This solved my problem.
Linux lhjins14d 3.11.6-1-ARCH #1 SMP PREEMPT Fri Oct 18 23:22:36 CEST 2013 x86_64 GNU/Linux
Offline
We're 2 months on from the posts i'm quoting (though the thread still active) so I probably shouldn't bother making these corrections... but i can't shake the need to so here we go.
I'm having problems understanding this method.It looks like they are using a patched version of Linux 3.9 to fix bbswitch, but this problem only started in Linux 3.10
...
EDIT: Since part of the thread was split off and binned, to summarize: the solution worked because it was Linux 3.9 as I suspected.
Yes, I didn't quite see why the method in the manjaro forums would be considered a workaround as it was simply a patched 3.9 kernel. Since nobody that are suffering from this issue seem to be having a problem with the 3.9 kernel, it would seem unnecessary to do this in the first place.
No, the problem did not only start in Linux 3.10. Early 3.8 kernels and extremely early 3.9 kernels were not affected, but later point releases were.
For example, for the 3.8 series, the issue started happening at 3.8.5.
So it was in fact completely necessary for the 3.9.11 kernel that was provided.
I don't see a manual patch there; only binary packages which seem to contain Linux 3.9 .
...
Otherwise, a better workaround (no untrusted binary packages) for this specific issue is just to keep using Linux 3.9 .
If you inspect the thread a little closer you'll find Just 2 posts prior to the one referenced I provided a link to the source packages.
So yeah, all irrelevant now, but I don't like the implication that I provided a 'bogus' or 'fake' solution. I didn't.
xfce | compiz | gmrun | urxvt | chromium | geany | aqualung | vlc | geeqie
Offline
No, the problem did not only start in Linux 3.10. Early 3.8 kernels and extremely early 3.9 kernels were not affected, but later point releases were.
For example, for the 3.8 series, the issue started happening at 3.8.5.
This is the first time I see this (I maintain primus, contributed to Bumblebee, and kept an eye on this issue). IIRC in 3.8.5 a different bug appeared, preventing the kernel from detecting the ACPI handle for the discrete GPU, and thus breaking bbswitch and nvidia drivers on some laptops (but in a different manner). If what you say is true, and you have a laptop that exhibits the same breakage (NVRM messages such as "rm_init_adapter failed" and/or "GPU has fallen off the bus", but bbswitch is able to find the ACPI handle), would you mind git-bisecting the 3.8.x and 3.9.x release branches to find breaking commits? When the issue appeared on 3.10, I bisected mainline tree to an RCU commit that I wouldn't expect to be backported to 3.8 and 3.9.
Edit: read the manjaro thread. Korrode, you're confusing two different issues. The manjaro thread is about ACPI regression in the kernel. This one is not.
Last edited by amonakov (2013-11-06 18:56:34)
Offline
Hi all,
I just installed again Archlinux on my Y500 after a while with windows 8, and everything looks great, including SLI.
has anyone know about this fix on nvidia? or was done by the linux kernel developers?
Offline
If you've read this thread, you'll see that the issues seems to have resolved itself for most after the 3.11.1 kernel. I don't recall seeing any mentions of people experiencing this problem with the 3.12 kernel.
Offline
If you've read this thread, you'll see that the issues seems to have resolved itself for most after the 3.11.1 kernel. I don't recall seeing any mentions of people experiencing this problem with the 3.12 kernel.
Still doesn't work for me. I'm not alone either, judging by the Nvidia thread.
Offline
A workaround has been found for this over in the Nvidia thread. The problem seems to not occur when using 1000Hz timer ticks.
CONFIG_HZ_1000=y
CONFIG_HZ=1000
I still get issues with suspending/resuming my machine, but I can successfully run nvidia. This workaround is likely sufficient for bumblebee users.
Offline
amonakov wrote:Check if booting with rcutree.rcu_idle_gp_delay=1 or running
sudo tee /sys/module/rcutree/parameters/rcu_idle_gp_delay <<<1
before loading the nvidia kernel module makes things better.
This fixed it for me. Thanks for tip.
This solves the problem for me too, but only temporily.
What i did:
- I restarted and put "nomodeset 3 " in the syslinux parameters
- entered the root rescue console that appears.
- did tee /sys/module/rcutree/parameters/rcu_idle_gp_delay <<<1
- Control+D (exit), continue boot
- logged in, everything fine.
If I restart and boot normally the same crash occurs, I get to the point were slim is supposed to start and the laptop switches off.
Is there anything i can do to not have to enter the command on each start in this complicated way?
Offline