On 6 December 2011 18:23, Pete Travis <lists(a)petetravis.com> wrote:
On Dec 6, 2011 7:52 AM, "R. G. Newbury"
<newbury(a)mandamus.org> wrote:
>
> On 12/05/2011 10:47 PM, Lawrence Graves<lgraves95(a)gmail.com>
> > On 12/05/2011 01:32 PM, R. G. Newbury wrote:
> >> > On 12/04/2011 09:44 PM, Lawrence Graves<lgraves95(a)gmail.com>
> > 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