Created attachment 75821 [details] kernel-log Hi, I have a problem that my nouveau driver does not properly load every time I boot my laptop. It either: - defaults to the vesa driver (always if my power cord is plugged into the laptop - starts nouveau but without the external monitor - starts nouveau WITH the external monitor (as it should be) (starting without the monitor attached and then connecting it always fails & crashes X) How/where can i find any help for this? Details: - Ubuntu 12.10. - card: VGA compatible controller: NVIDIA Corporation G86 [GeForce 8400M GT] (rev a1) - kernel 3.5.0-25-generic - X.Org X Server 1.13.0 Release Date: 2012-09-05 - all nv & nvidia drivers are blacklisted - the problem has grown worse over the last 2 years - motherboard replaced 2 years ago because of overheated nvidia card (waaranty)
Created attachment 75822 [details] dmesg
Hi Ronald Did you notice the lines [ 67.479198] NVRM: The NVIDIA GPU 0000:01:00.0 (PCI ID: 10de:0426) [ 67.479198] NVRM: installed in this system is not supported by the 304.64 [ 67.479198] NVRM: NVIDIA Linux driver release. Please see 'Appendix [ 67.479198] NVRM: A - Supported NVIDIA GPU Products' in this release's [ 67.479198] NVRM: README, available on the Linux driver download page [ 67.479198] NVRM: at www.nvidia.com. Fully(correctly) remove the blob and then try again
:-) You might have saved my live: after blacklisting these modules: blacklist vga16fb #blacklist nouveau #blacklist nouveau_drv blacklist rivafb blacklist nvidiafb blacklist rivatv blacklist nvidia my laptop magicaly boots correct, even WITH the powercord plugged which has not happened to me in over 2 years! I will test this this week and come back any way to report whether this is solved. Thank you very much!
(In reply to comment #3) > :-) You might have saved my live: after blacklisting these modules: > > blacklist vga16fb > #blacklist nouveau > #blacklist nouveau_drv > blacklist rivafb > blacklist nvidiafb > blacklist rivatv > blacklist nvidia > > my laptop magicaly boots correct, even WITH the powercord plugged which has > not happened to me in over 2 years! > > I will test this this week and come back any way to report whether this is > solved. > > Thank you very much! Good to hear everything works fine now. If you wish to continue using the nouveau driver please ensure that you remove (uninstall) nVidias driver and (re-) install mesa-libGL. This latter step will enable 3D acceleration with nouveau. If you need more specific instructions on this I would advice you to inquire with your distribution ``makers'', as this differs from distro to distro.
Well, it seemed that the first reboot was just sheer luck. After several more reboot the seem probleem seems to exist. I unstall nvidia-current now. But dmesg now reports: [ 44.306497] nouveau 0000:01:00.0: enabling device (0000 -> 0003) [ 44.306965] [drm] nouveau 0000:01:00.0: unsupported chipset 0xffffffff [ 44.307214] nouveau: probe of 0000:01:00.0 failed with error -22 See logs for more details, mesa-libgl seems to be installed: ||/ Name Version Architecture Description +++-========================-=================-=================-===================================================== ii libgl1-mesa-dri:i386 9.0.2-0ubuntu0.1 i386 free implementation of the OpenGL API -- DRI modules un libgl1-mesa-dri-experime <none> (no description available) ii libgl1-mesa-glx:i386 9.0.2-0ubuntu0.1 i386 free implementation of the OpenGL API -- GLX runtime un libgl1-mesa-glx-no-multi <none> (no description available) ii libglapi-mesa:i386 9.0.2-0ubuntu0.1 i386 free implementation of the GL API -- shared library ii libglu1-mesa:i386 9.0.0-0ubuntu1 i386 Mesa OpenGL utility library (GLU) ii mesa-utils 8.0.1+git20110129 i386 Miscellaneous Mesa GL utilities un mesag3 <none> (no description available) un xlibmesa-dri <none> (no description available) un xlibmesa3 <none> (no description available) I hope to hear.
Created attachment 75828 [details] kernel_log (replaces previous upload!)
Created attachment 75829 [details] Xorg-log (replaces previous upload!)
As mentioned previously Does it work reliably with the binary driver? (quite sure the answer is no looking at your initial dmesg log) Have you considered that the repair job may not be as perfect as you might have hoped?
Well, no the binary driver does not work properly as well. besides I prefer the nouveau driver. Reading the nouveau wiki I am pretty sure that my system is not properly cleaned from previously installed drivers like: /lib/modules/3.5.0-25-generic/kernel/drivers/net/ethernet/nvidia /lib/modules/3.5.0-25-generic/kernel/drivers/net/ethernet/nvidia/forcedeth.ko /lib/modules/3.5.0-25-generic/kernel/drivers/video/nvidia /lib/modules/3.5.0-25-generic/kernel/drivers/video/nvidia/nvidiafb.ko /usr/lib/xorg/modules/libnvidia-wfb.so.1 /usr/lib/xorg/modules/libnvidia-wfb.so.295.20 /usr/lib/xorg/modules/drivers/nvidia_drv.so But I am unsure how to remove them (other then apt-get remove) withotu breaking anything vital. Can't really find any info on the ubuntu help pages.
Well, i think i have now completely uninstalled all nvidia packages (eventhough I still find nvidia files): /lib/modules/3.5.0-25-generic/kernel/drivers/net/ethernet/nvidia /lib/modules/3.5.0-25-generic/kernel/drivers/net/ethernet/nvidia/forcedeth.ko /lib/modules/3.5.0-25-generic/kernel/drivers/video/nvidia /lib/modules/3.5.0-25-generic/kernel/drivers/video/nvidia/nvidiafb.ko /usr/lib/xorg/modules/libnvidia-wfb.so.1 /usr/lib/xorg/modules/libnvidia-wfb.so.295.20 /usr/lib/xorg/modules/drivers/nvidia_drv.so I as long as I keep my power-plug UNPLUGGED during boot the nouveau driver loads as normal. But when the power-cord is PLUGGED I get this error in xorg.0.log: [ 1.328023] nouveau 0000:01:00.0: enabling device (0000 -> 0003) [ 1.328497] [drm] nouveau 0000:01:00.0: unsupported chipset 0xffffffff [ 1.330177] nouveau: probe of 0000:01:00.0 failed with error -22 What can cause this? How can I solve this?
(In reply to comment #10) ... > /lib/modules/3.5.0-25-generic/kernel/drivers/net/ethernet/nvidia/forcedeth.ko I would personally (re)move everything _but_ the above file, with that said I'm not a debian person > I as long as I keep my power-plug UNPLUGGED during boot the nouveau driver > loads as normal. > > But when the power-cord is PLUGGED I get this error in xorg.0.log: > > [ 1.328023] nouveau 0000:01:00.0: enabling device (0000 -> 0003) > [ 1.328497] [drm] nouveau 0000:01:00.0: unsupported chipset 0xffffffff > [ 1.330177] nouveau: probe of 0000:01:00.0 failed with error -22 > > What can cause this? 99.99...% hardware issue > How can I solve this? Repair the machine or get a new one :) Note it may be something as simple as missing/loose ground within the laptop
(In reply to comment #11) > > 99.99...% hardware issue > That could well be, the issues kind of started around the time when I doubled the memory AND had my motherboard replaced due to the over-heating nvidia-card-problem. Thanks for all the effort. Is there anything I can help your team with?
Hi Ronald, I've the same problem. I've a Sony Vaio fz21m with 8400m gt Gpu. Now I tried Ubuntu 13.04 32bit. I had just displaced my Gpu beacause of high temperature (Sony warranty). I confirm you that when I start my system without power plugin inserted I can have a funcionally nouveau driver. When the power plugin is inserted I observe randomness: sometime start Vesa driver, sometime correctly nouveau driver. I also had observed nvidia problems (randomness start as well as nouveau). How did you solve this problem? I also read that the problem depend of xorg version and that it doesn't exist with Ubuntu 12.04-01 64bit. Thanks! Bye! Garuax (In reply to comment #12) > (In reply to comment #11) > > > > 99.99...% hardware issue > > > > That could well be, the issues kind of started around the time when I > doubled the memory AND had my motherboard replaced due to the over-heating > nvidia-card-problem. > > Thanks for all the effort. Is there anything I can help your team with?
Well, what I did to solve it was to completely (!!!) remove all traces of the binary nvidia driver, this is expained somewhere on the nouveau website. You really have to dig quite deep. Simply apt-get remove was not enough. Now i have it in a state that I can live with: - does not boot OK when powerplug is connected - but boot (in 99% of the cases) fine when powerplug is unplugged This was the best I could make of it. Hope this helps. Groeten, Ronald Verheul RonaldVerheul@yahoo.com ________________________________ From: "bugzilla-daemon@freedesktop.org" <bugzilla-daemon@freedesktop.org> To: rvhbox-freedesktop@yahoo.com Sent: Wednesday, April 17, 2013 6:12 PM Subject: [Bug 61731] Nouveau not working on second monitor Comment # 13 on bug 61731 from garuax Hi Ronald, I've the same problem. I've a Sony Vaio fz21m with 8400m gt Gpu. Now I tried Ubuntu 13.04 32bit. I had just displaced my Gpu beacause of high temperature (Sony warranty). I confirm you that when I start my system without power plugin inserted I can have a funcionally nouveau driver. When the power plugin is inserted I observe randomness: sometime start Vesa driver, sometime correctly nouveau driver. I also had observed nvidia problems (randomness start as well as nouveau). How did you solve this problem? I also read that the problem depend of xorg version and that it doesn't exist with Ubuntu 12.04-01 64bit. Thanks! Bye! Garuax (In reply to comment #12) > (In reply to comment #11) > > > > 99.99...% hardware issue > > > > That could well be, the issues kind of started around the time when I > doubled the memory AND had my motherboard replaced due to the over-heating > nvidia-card-problem. > > Thanks for all the effort. Is there anything I can help your team with? ________________________________ You are receiving this mail because: * You reported the bug.
(In reply to Ronald from comment #14) > Well, > > what I did to solve it was to completely (!!!) remove all traces of the > binary nvidia driver, this is expained somewhere on the nouveau website. You > really have to dig quite deep. Simply apt-get remove was not enough. > > Now i have it in a state that I can live with: > - does not boot OK when powerplug is connected > - but boot (in 99% of the cases) fine when powerplug is unplugged > > This was the best I could make of it. > Is this still a problem with a recent kernel? (3.17/3.18)
(In reply to Tobias Klausmann from comment #15) > Is this still a problem with a recent kernel? (3.17/3.18) I was actually trying to debug this driver-loading problem on & off for a while, and while I won't be running any more tests, I'd still like to see it resolved, if only for a sense of closure. The last test I ran was with v3.17-rc2 of the PAE kernel on Ubuntu 12.04, and the problem was still there at that point in time. I can't vouch for more recent changes though. One thing I eventually found out is that there's an even simpler workaround than unplugging the laptop during boot: try passing the "pci=bios" boot parameter to the kernel. I was keeping track of the tests at a Launchpad account, and I eventually sent a couple emails to the linux-pci mail list. You can tell I'm an amateur at systems debugging, especially in the beginning, but all those records are here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1009312 http://thread.gmane.org/gmane.linux.kernel.pci/33181 http://thread.gmane.org/gmane.linux.kernel.pci/34437 As for what causes it, I made several guesses that all eventually turned out wrong. It's just one more guess, but based on everything I figured out through the tests, I think there's some kind of race happening in or between the kernel & the BIOS pci initialization code. The earliest symptom in the logs is that there will be a ~30 ms gap between these two lines in dmesg (from the original reporter's in this thread): > [ 0.379459] pci 0000:01:00.0: reg 30: [mem 0x00000000-0x0001ffff pref] > [ 0.408041] pci 0000:00:01.0: PCI bridge to [bus 01-01] I think that's due to a timeout in pci link-retraining, but using an initscript to dump the GPU's pci config, I was able to find out that something is accidentally resetting or turning off the GPU prior to that. A race condition in the pci initialization might explain why the bug is intermittent and also why it's much more common in the x32 kernel (the smaller word length leading to more machine instructions something could wedge between?) I think the unplugging trick works by putting the PCI bus into a power-saving mode, which slows down the initialization enough to avoid a race.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/issues/37.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.