nouveau/ NV11: 3.12 freezes if X.org is started headless

[Dave Airlie]

On Wed, Nov 27, 2013 at 12:15 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
> On Tue, Nov 26, 2013 at 8:35 PM, Stefan Lippers-Hollmann <s.L-H at gmx.de> wrote:
>> Hi
>>
>> On Wednesday 27 November 2013, Ilia Mirkin wrote:
>>> On Tue, Nov 26, 2013 at 7:18 PM, Stefan Lippers-Hollmann <s.L-H at gmx.de> wrote:
>>> > Hi
>>> >
>>> > On Tuesday 26 November 2013, Ilia Mirkin wrote:
>>> >> On Tue, Nov 26, 2013 at 6:03 PM, Stefan Lippers-Hollmann <s.L-H at gmx.de> wrote:
>>> >> > v3.11 is fine, with and without monitor attached.
>>> >> > v3.12 is fine as long as X.org isn't started (but may fail to reboot
>>> >> >       cleanly). If a monitor is connected I don't observe any problems,
>>> >> >       it freezes without a monitor connected.
>>> >> > v3.13-rc1-95-gb975dc3 appears not to freeze without a monitor anymore
>>> >> >       (I didn't confirm that it's fine with a monitor attached), but I
>>> >> >       end up with the following Oops (this is before X.org is started).
>>>
>>> One more idea -- try it with nouveau.runpm=0 -- I've had some odd
>>> results with it on my older cards (but I don't remember hangs, but I
>>> also didn't spend a lot of time on it, just plopped the option in and
>>> moved on). This is a feature that got in in 3.12, and is really the
>>> only major nouveau-affecting change in that kernel for your card
>>> revision.
>>
>> You're spot on, that does the trick.
>
> Great to hear!
>
>>
>> # cat /sys/module/nouveau/parameters/agpmode
>> -1
>> # cat /sys/module/nouveau/parameters/runpm
>> 0
>>
>>   v3.13-rc1-95-gb975dc3
>> + http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=0397aaaa009092427dc60aea8b3c21c00526d8ba
>> + nouveau.runpm=0
>> is now stable, with and without a monitor attached; as is
>>
>>   3.12.1 || v3.12.1-62-g4615252 (stable-queue.git)
>> + nouveau.runpm=0
>>
>
> Dave, looking at the code, it seems like runtime pm should only be
> getting activated by default for optimus systems. Stefan's is clearly
> not one of those, neither is mine. Unfortunately I have no clue how
> the runtime pm subsystem works, but it seems like runtime_suspend()
> may be getting called directly, e.g. if there are no monitors attached
> to nouveau, perhaps as a result of nouveau_crtc_set_config in
> dispnv04/crtc.c. Does the same if (runpm == -1 && !optimus) return
> -EBUSY check belong in the runtime_suspend callback?

Either that or it needs to be calling some of the other runtime
interfaces instead of runtime_autosuspend

maybe that last pm_runtime_put_autosuspend should be just
pm_runtime_put, but that might need testing on an optimus system.

Dave.