Bug 13180

References : http://lkml.org/lkml/2009/4/27/290

On Sunday 07 June 2009, Niel Lambrechts wrote:
> Rafael J. Wysocki wrote:
> 
> I have not seen the same problem in later levels up to rc8, and there
> has been quite a few more drm patches. I think this one can be closed
> and I will log a new entry if it happens again.

Reopening at the reporter's request.

The problem may be caused by the PAT issues that have patches available (e.g. bug #13884).

Created attachment 22570 [details]
i915_gem_idle warning (2.6.30.2 stable)

Created attachment 22571 [details]
i915_gem_idle warning (2.6.31-rc2)

Created attachment 22572 [details]
i915_gem_idle warning (2.6.31-rc4)

Hi,

I originally noticed warnings as attached - after having an issue where Xorg became 100% busy. I use hibernate almost daily, so it could be that these problems originate from hibernate or suspend-to-ram. The logged warnings however do not occur directly after resuming.

There have also been a few occurrences of soft-locked blank Xorg screens on my laptop- although they were not always accompanied by these warnings (note, I have not seen them on 2.6.30.3 yet, which I upgraded to a day or so ago).

I will also try 2.6.31-rc5 based on Raphael's comment around PAT.

Regards,
Niel

Sorry, I should have mentioned that I upgraded to 2.6.30.4 shortly after 2.6.30.3 - I will be testing this as well.

Hi,

I got a similar WARNING after telinit 3 (I gave the command via the network, the display was sleeping in the kdm login screen). x86_64 kernel 2.6.30.5, intel driver 2.7.1, UXA, no KMS. CONFIG_SUSPEND is not set, CONFIG_HIBERNATION is not set.

Created attachment 22921 [details]
another i915_gem_idle warning

Not quite enough info here to distinguish whether this warning is caused by a hung GPU or unflushed buffers. For the latter case, that should be fixed with:

ommit 99fcb766a3a50466fe31d743260a3400c1aee855
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sun Feb 7 16:20:18 2010 +0100

    drm/i915: Update write_domains on active list after flush.
    
    Before changing the status of a buffer with a pending write we will await
    upon a new flush for that buffer. So we can take advantage of any flushes
    posted whilst the buffer is active and pending processing by the GPU, by
    clearing its write_domain and updating its last_rendering_seqno -- thus
    saving a potential flush in deep queues and improves flushing behaviour
    upon eviction for both GTT space and fences.
    
    In order to reduce the time spent searching the active list for matching
    write_domains, we move those to a separate list whose elements are
    the buffers belong to the active/flushing list with pending writes.
    
    Orignal patch by Chris Wilson <chris@chris-wilson.co.uk>, forward-ported
    by me.
    
    In addition to better performance, this also fixes a real bug. Before
    this changes, i915_gem_evict_everything didn't work as advertised. When
    the gpu was actually busy and processing request, the flush and subsequent
    wait would not move active and dirty buffers to the inactive list, but
    just to the flushing list. Which triggered the BUG_ON at the end of this
    function. With the more tight dirty buffer tracking, all currently busy and
    dirty buffers get moved to the inactive list by one i915_gem_flush operation.
    
    I've left the BUG_ON I've used to prove this in there.
    
    References:
      Bug 25911 - 2.10.0 causes kernel oops and system hangs
      http://bugs.freedesktop.org/show_bug.cgi?id=25911
    
      Bug 26101 - [i915] xf86-video-intel 2.10.0 (and git) triggers kernel oops
                  within seconds after login
      http://bugs.freedesktop.org/show_bug.cgi?id=26101