Bug 71455

Hi Bob,

Could you send me your kernel logs please? Extracting your vbios could also be of some help later on.

Is fan management really working properly for you? I know it is an old card and those were really running hot, but still!

Here is an additional data point. The problematic kernel sets 0xb20010f0 to 0x83ff03ff. The driver reports that the PWM is 100%. In fact it is 100% off. As can be expected, the temperature immediately begins repidly rising. Interestingly, the card seems to self protect by turning the fan on when the temperature gets above the "critical" temperature and restoring the default PWM (fan off). I suppose that is what "auto" means. The value in 0xb200010f0 never changes while the fan speed goes up and down. 
The blob sets the same mmio address to 0x81ff03ff and reports the fan to be 50%. I can't tell you if "100%" PWM is fan off on all NV cards. I'm sure you already know anyway. The fan speeds up significantly if the PWM setting is either 0x00007fff or 0x80007fff. 
I guess that's more than one data point. Other than that, I'm completely in the dark. However, I think I will patch my kernel so that it sets the PWM to 50% instead of 100%. 50% off is a lot better than 100% off.

Bob

The fan PWM setting is derived from priv->cstate. The value it gets from there is zero. So the setting of PWM for NV40 is working correctly, "inverting" the percent setting to get the value set in 0xb20010f0. Probably priv->cstate is never initialized. I'll bet that wasn't intentional.

Bob

Oh, the value reported by the driver for the PWM setting is the value before it is set by the driver. It doesn't say that in the kernel message.

(In reply to comment #3)
> The fan PWM setting is derived from priv->cstate. The value it gets from
> there is zero. So the setting of PWM for NV40 is working correctly,
> "inverting" the percent setting to get the value set in 0xb20010f0. Probably
> priv->cstate is never initialized. I'll bet that wasn't intentional.
> 
Not intentional. But also found and fixed already in -rc1.

Ben. 

> Bob

In view of Ben's comment, I am stopping further research. However, I will offer as a final remark that perfE.pstate = 0x20 on my card. It gets into nv40_clock_ctor but the fan speed is never set. According to nvbios, for this card the default setting for the fan speed is 50. 

Best Wishes,

Bob

Created attachment 113500 [details]
dmesg text

I am running a mid 2012 macbook pro. 650M nVidia chip. There is something funky with the glx rendering. I tried the various things in the troubleshooting guide and got no where. If need be I can email the following two images to the list but I thought I would save everyones mailboxes some bloat. 

https://www.flickr.com/photos/evanfoss/15912299653/
https://www.flickr.com/photos/evanfoss/16507165346/in/photostream/

For those in the far future who may find the above links dead the images show glxgears rendering at +3K frames a second. The glxgears window however has blocks missing with only a single pixel in each one being rendered.

I have tested the following kernel versions and found this to be true for all of the following. 

gentoo-sources-3.12.13
gentoo-sources-3.14.6
gentoo-sources-3.16.1

Bob, please confirm that newer kernels resolve this issue.

Evan, your issue is wholly unrelated to the original one. And most likely also fixed in newer kernels (large page size mismatch).

On Wed, Oct 28, 2015 at 12:38 AM,  <bugzilla-daemon@freedesktop.org> wrote:
> Comment # 8 on bug 71455 from Ilia Mirkin
>
> Bob, please confirm that newer kernels resolve this issue.
>
> Evan, your issue is wholly unrelated to the original one. And most likely
> also
> fixed in newer kernels (large page size mismatch).

Yes and it was dealt with by other people. (my thanks again by the way)

I think i attached it to this by accident before I put it with the right one.

> ________________________________
> You are receiving this mail because:
>
> You are on the CC list for the bug.

-- 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/72.