On 12/05/2011 10:47 PM, Lawrence Graveslgraves95@gmail.com
On 12/05/2011 01:32 PM, R. G. Newbury wrote:
On 12/04/2011 09:44 PM, Lawrence Graveslgraves95@gmail.com
On 12/04/2011 07:44 AM, Ian Malone wrote:
1 Add rdblacklist=nouveau to kernel grub line (done)
< big snip>
18 Reboot to check.
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.
This brings to mind the Holmes Corrollary to Murphy's Laws: "Any law of chemistry or physics to the contrary notwithstanding, if it happened, it must be possible". This is very weird.
Can you at least report that some of the steps worked??? Did the reboot at step 4 work? (The vesa driver only step). Did you at least see the nvidia driver loaded at step 8? Did startx get you to the graphical desktop in step 9?
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...
Geoff
On Dec 6, 2011 7:52 AM, "R. G. Newbury" newbury@mandamus.org wrote:
On 12/05/2011 10:47 PM, Lawrence Graveslgraves95@gmail.com
On 12/05/2011 01:32 PM, R. G. Newbury wrote:
On 12/04/2011 09:44 PM, Lawrence Graveslgraves95@gmail.com
On 12/04/2011 07:44 AM, Ian Malone wrote:
1 Add rdblacklist=nouveau to kernel grub line (done)
< big snip>
18 Reboot to check.
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.
This brings to mind the Holmes Corrollary to Murphy's Laws: "Any law of chemistry or physics to the contrary notwithstanding, if it happened, it must be possible". This is very weird.
Can you at least report that some of the steps worked??? Did the reboot at step 4 work? (The vesa driver only step). Did you at least see the nvidia driver loaded at step 8? Did startx get you to the graphical desktop in step 9?
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...
Geoff
-- users mailing list users@lists.fedoraproject.org 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
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.
You might have a hardware conflict with the wireless card, or not. There are a number of ways to troubleshoot this, the simplest of which is physically removing the wifi card. It's usually a few screws for the plastic cover, one or two screws for the ~1in by ~2in card, and antenna cables you should probably tape to insulate. This may help: http://support.dell.com/support/edocs/systems/ins9400/en/sm/index.htm
With the last two Fedora releases, installing kmod-nvidia has automagickally ran dracut and appended my grub entry. Likewise, removing it has revoked 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.
HTH, Pete
On 6 December 2011 18:23, Pete Travis lists@petetravis.com wrote:
On Dec 6, 2011 7:52 AM, "R. G. Newbury" newbury@mandamus.org wrote:
On 12/05/2011 10:47 PM, Lawrence Graveslgraves95@gmail.com
On 12/05/2011 01:32 PM, R. G. Newbury wrote:
On 12/04/2011 09:44 PM, Lawrence Graveslgraves95@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)
On 6 December 2011 21:40, Ian Malone ibmalone@gmail.com wrote:
On 6 December 2011 18:23, Pete Travis lists@petetravis.com wrote:
On Dec 6, 2011 7:52 AM, "R. G. Newbury" newbury@mandamus.org wrote:
On 12/05/2011 10:47 PM, Lawrence Graveslgraves95@gmail.com
On 12/05/2011 01:32 PM, R. G. Newbury wrote:
On 12/04/2011 09:44 PM, Lawrence Graveslgraves95@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
Hi, Lawrence was able to send me some pictures of the X log (aside, I realise it's tricky to work on the system when X wont start, simplest way to get round this if you're able to get a command line is to take copies of the file via the cp command. Anyway, back to the point...)
Typed out it looks like this (after the preamble): (==) Log file: "/var/log/Xorg.0.log", Time: Tue Dec 6 15:17:51 (==) Using config file: "/etc/X11/xorg.conf" (==) Using config directory: "/etc/X11/xorg.conf.d" (==) Using system config directory: "/usr/share/X11/xorg.conf.d" (EE) NVIDIA(0): Failed to get supported display device(s) (EE) NVIDIA(0): No display devices found for this X screen. (EE) Screen(s) found, but none have a usable configuration.
Fatal server error: no screens found
...followed by X giving up and closing the log.
The machine is a Dell Inspiron 9400, with NVIDIA Go 7900 chipset, some googling suggests (as in fact John Pilkington suggested a while back) that this is an Nvidia 290 problem, https://bbs.archlinux.org/viewtopic.php?pid=1022749 and reverting to the 285 driver, i.e. downgrade to the packages: kmod-nvidia-285.05.09 and xorg-x11-drv-nvidia-285
On 12/06/2011 06:52 AM, R. G. Newbury wrote:
On 12/05/2011 10:47 PM, Lawrence Graveslgraves95@gmail.com
On 12/05/2011 01:32 PM, R. G. Newbury wrote:
> On 12/04/2011 09:44 PM, Lawrence Graveslgraves95@gmail.com >>> >> On 12/04/2011 07:44 AM, Ian Malone wrote: > > 1 Add rdblacklist=nouveau to kernel grub line (done)
< big snip>
> 18 Reboot to check.
I'm going to try this on my failed F16 install (desktop) because I'm using nVidia by editing the line at boot. If it works, and I add it to grub.conf, do I have to rebuild grub.cfg as well?
-
Ian Malone -
Joe Zeff -
Pete Travis -
R. G. Newbury