Re: Bug 648732 – Intel wireless broken on 11n for many users

[Ian Malone]

On 6 December 2011 18:23, Pete Travis <lists at petetravis.com> wrote:

> On Dec 6, 2011 7:52 AM, "R. G. Newbury" <newbury at mandamus.org> wrote:
>>
>> On 12/05/2011 10:47 PM, Lawrence Graves<lgraves95 at gmail.com>
>> > On 12/05/2011 01:32 PM, R. G. Newbury wrote:
>> >> >  On 12/04/2011 09:44 PM, Lawrence Graves<lgraves95 at 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