Edit 2: for anyone facing issues with new kernel and nvidia just put rcutree.rcu_idle_gp_delay=1 on the kernel boot line and it will work perfectly.
Not quite.
I recently realized that I could no longer get by with nouveau, so I went on a mission to somehow get the proprietary Nvidia driver to work.
So I started by starting X manually, which has been required for me in the past, for some odd reason I never figure out. Didn't make a difference.
Then I tried removing the secondary video card. Didn't make a difference, though it also did in the past.
Then I stumbled upon the "rcutree.rcu_idle_gp_delay" kernel parameter. Didn't make a difference.
Then I removed the secondary video card again, and this time I could start X.
However, I do now have a perfectly fine and quite expensive video card lying around doing nothing, but worse yet, I still have issues with screen tearing. I never did figure out how to fix that, which is why that last time things went haywire, I decided to settle for the nouveau driver.
Worse yet, Nvidia is aware of the problems, and have been for quite a while, regarding the GT 650m and have decided to do... Yes, you guessed it. NOTHING!
In short, I'm in tears. I need the proprietary driver due to the need to hardware acceleration and other stuff, and of course it works, though now I only have half the power and can't even watch a movie without getting a headache.
I considered starting a thread here at the forum... again... people at this forum after all are rather clever, but I have more or less come to the conclusion that the problem can't be solved.
Well, end of rant I suppose, just wanted to say that while "rcutree.rcu_idle_gp_delay" helps, there are still significant issues, for me at least, and the only solution seem to be to not use a laptop with the gt 650m card, and possible other similar cards.
Best regards
Edit:
The screen tearing section in this guide http://www.supaevensteven.com/2014/03/l … 4-lts.html may have helped that particular issue a bit, though not completely solved.
After updating to kernel 3.13 and nvidia driver I can't get a virtual console, Arch boots and freeze on the boot, but keyboard responses because if I try Ctrl+Alt+Del it reboots but I can't get a console to log in even if I disable the login manager, I always have to use the installation pen drive to downgrade the kernel and nvidia.
Anyone have this issue?Edit 1: Ok, now I have VC
Edit 2: for anyone facing issues with new kernel and nvidia just put rcutree.rcu_idle_gp_delay=1 on the kernel boot line and it will work perfectly.
Thank you! I am so sick and tired of Nvidia, but this solved my problem! I get to update to a new kernel now...imagine that.
For my own knowledge, what exactly does this parameter do? And, if it is this simple, why isn't it built into the driver?
]]>Edit 1: Ok, now I have VC
Edit 2: for anyone facing issues with new kernel and nvidia just put rcutree.rcu_idle_gp_delay=1 on the kernel boot line and it will work perfectly.
]]>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?
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.
]]>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.
]]>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.
]]>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.
]]>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
]]>I've tried several reboots and logouts (I have kde (kdm)). So far, it always worked.
]]>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.
]]>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?
]]>F_ck you Nvidia! By Linus; http://www.youtube.com/watch?v=IVpOyKCNZYw
]]>