On 6 December 2011 18:23, Pete Travis <lists@xxxxxxxxxxxxxx> wrote: > On Dec 6, 2011 7:52 AM, "R. G. Newbury" <newbury@xxxxxxxxxxxx> wrote: >> >> On 12/05/2011 10:47 PM, Lawrence Graves<lgraves95@xxxxxxxxx> >> > On 12/05/2011 01:32 PM, R. G. Newbury wrote: >> >> > On 12/04/2011 09:44 PM, Lawrence Graves<lgraves95@xxxxxxxxx> >> > After doing all the above from 1-18, it is still doing the same thing >> > and gave me the same screen as when I first start this journey. >> >> >> I didn't closely follow the beginning of the thread. Could you repeat >> what hardware you are using, and confirm the distro level (F15 I think) >> and kernel. I am interested in confirming the video chipset and the >> wireless chipset, since *something* weird is going on, involving those... >> > I've had some very frustrating problems with making GPUs work, learned a > little, and experienced an incredible amount of guidance and patience from > the Fedora community along the way. I'll throw out a couple observations > I've made that may help. > > With the last two Fedora releases, installing kmod-nvidia has automagickally > ran dracut and appended my grub entry. Likewise, removing it has revoked After the last upgrade I had to do this manually. > those changes, as far as I can tell. If you need to remove the nvidia > drivers for testing, I would suggest using this command: > yum remove $(rpm -qa | grep nvidia) > Try the section inside the parentheses by itself to see what's going on. > After you remove the packages, you will need to reboot for the changes to > take effect. > > It is also a good idea to install akmod-nvidia with kmod-nvidia. The driver > needs to be built for a specific kernel, and when they get out of sync, this > will fill in the gaps. > > Experimenting with kernel parameters can be diagnostically useful, or > provide a workaround. To use them, when grub presents the menu of kernels to > boot, press 'e' to edit, then add them to the line that begins with 'linux.' > A few I've found useful when troubleshooting are: > 1 - boots to a fallback root console. You have probably already found > something like this. > nomodeset - disables kernel modesetting, changing how the kernel works with > the GPU and it's driver. I don't understand it well enough to offer a more > technical explanation, but I know its worth a try with and without it. > > acpi=off - disables advanced power management features. Laptops are > especially prone to poor acpi implementations. I have to use this to boot > with the nvidia drivers on my MSI laptop. I also noticed that this disables > suspend and causes the power button to instantly drop power to the system, > so press it with caution with acpi disabled. > > One more thing - I can't recall if the default nouveau drivers didn't work > for you, or if you weren't happy with them. At the very least, we should be > able to get vesa drivers working for you. > I assume the nouveau drivers are working, otherwise he wouldn't have been able to take those screenshots, and all the X logs I've seen from Lawrence so far show nouveau being loaded. Which brings me on to... Quick note on Xorg logs: if X isn't starting because of a driver problem the log will record the problem. However as I said, I haven't seen one yet which didn't indicate nouveau. I tried to indicate we need a log from the computer when nvidia is failing to load, but perhaps I should have gone into more detail. In F16 they get called /var/log/Xorg.N.log where N is a number starting at 0. And they get overwritten at each restart, which is why I was asking for a copy from when the system is failing to start X, by the time you've rebooted with the nouveau driver and logged back in it's gone. For similar reasons screenshots from a running X session aren't going to give much that can't simply be sent as copies of the text files. So either: We need a copy made during a session where X fails to start. We need a copy of one of the other attempts, if X tries a few times it will create a new one for each attempt, /var/log/Xorg.1.log to /var/log/Xorg.5.log, these may be left over when you start X again with nouveau. $ ls /var/log/Xorg.*.log -lhrt should give an indication of what logs are remaining and when they're from. A log from a failed start attempt will probably contain at least some indicators of what's going wrong, if not the exact problem. It's best to try and get this before starting to mess with aerials and things. Okay, with that said, checking the nvidia modules are installed: $ ls /lib/modules/$(uname -r)/extra/nvidia/ -l total 16400 -rw-r--r--. 1 root root 16769688 Nov 23 14:39 nvidia.ko $ ls /usr/lib64/xorg/modules/extensions/nvidia -l total 8508 lrwxrwxrwx. 1 root root 16 Nov 27 16:23 libglx.so -> libglx.so.290.10 lrwxrwxrwx. 1 root root 16 Nov 27 16:23 libglx.so.1 -> libglx.so.290.10 -rwxr-xr-x. 1 root root 8392712 Nov 17 02:06 libglx.so.290.10 lrwxrwxrwx. 1 root root 23 Nov 27 16:23 libnvidia-wfb.so -> libnvidia-wfb.so.290.10 lrwxrwxrwx. 1 root root 23 Nov 27 16:23 libnvidia-wfb.so.1 -> libnvidia-wfb.so.290.10 -rwxr-xr-x. 1 root root 295416 Nov 18 2010 libnvidia-wfb.so.290.10 $ modprobe nvidia (Normally we'd run this as root, but just want to see any errors) -- imalone -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
