Bug 29005

Created attachment 36941 [details]
dmesg from 2.6.34-1-amd64

Created attachment 36942 [details]
Xorg log

Created attachment 36943 [details]
output of intel_gpu_dump

Note that /sys/kernel/debug/dri/0/i915_error_state didn't report any problem.

Created attachment 36944 [details]
Backtrace that appeared in dmesg a bit later

It's probably related to the bug since it talks about Ironlake, but I don't see why it appeared later (30s-1mn later or so) and I don't see if it's a oops or what else.

I wonder if the backtrace is a soft-lockup from:

while ((I915_READ(transconf_reg) & TRANS_STATE_ENABLE) == 0)
    ;

I think there are reasonable similarities between this and bug 28911.

Created attachment 36959 [details] [review]
Experimental patch

Created attachment 36961 [details] [review]
Another minor patch in the vicinity.

Created attachment 36962 [details] [review]
And a cleanup patch!

Applied all 3 patches on top of 2.6.35-rc4, no change.

By the way, your first patch wrongly removes the semi-colon at the end of the while loop. And I had to remove the call to intel_update_fbc() since it's not there in 2.6.35-rc4. Do you need me to test your patches on top of another drm tree?

I can confirm that this is a soft lockup, I found the message in another instance of the backtrace in dmesg.

(In reply to comment #9)
> Applied all 3 patches on top of 2.6.35-rc4, no change.

Ok, something a bit more sinister then.
 
> By the way, your first patch wrongly removes the semi-colon at the end of the
> while loop. And I had to remove the call to intel_update_fbc() since it's not
> there in 2.6.35-rc4. Do you need me to test your patches on top of another drm
> tree?

I tend to work against Eric's drm-intel-next unless I am targetting a stable tree.

Keith mentioned that he has seen some spurious hangs on DPMS-on on gm45, so we may be doing something wrong on the common DP paths -- which is drifting away from the original bug...

Created attachment 37568 [details] [review]
1280901139-8922-1-git-send-email-airlied@gmail.com

Can you please test this patch by Dave Airlie? Thanks.

Tested the patch on top of 2.6.35-rc4, no change.

I have an E6510 with an intel core i5 processor and intel integrated graphics. I believe the hardware is the same as yours.

For me, this issue was solved in the latest drm-intel-next kernel. I had to revert a patch which caused a regression giving me a blank screen on boot (see https://bugzilla.kernel.org/show_bug.cgi?id=16496), but now the VGA output works without problems.

It pays to be cautious and not assume that the same model from the same manufacturer contains the same components. Lenovo, for example, is infamous for shipping wildly different configurations under the same model number, and they all seem to fail in different ways.

Thanks for the feedback, as indeed quite a few patches for Arrandale are now upstream in drm-core-next (and drm-intel-next) and now seems to be a good point to check whether one of those holds the fix.

It might indeed be possible that the e6510 is slightly different from the e6410. There is also a bug about a black screen when resuming from suspend, and the fix that is reported to work for the e6410 doesn't solve the issue on my e6510. Anyway, here's the output from sudo lshw :
*-cpu
          description: CPU
          product: Intel(R) Core(TM) i5 CPU       M 520  @ 2.40GHz
          vendor: Intel Corp.
          physical id: 4
          bus info: cpu@0
          version: 6.5.2
          serial: 0002-0652-0000-0000-0000-0000
          slot: CPU 1
          size: 2399MHz
          capacity: 4GHz

If you need somebody to test patches, let me know. 

(In reply to comment #14)
> It pays to be cautious and not assume that the same model from the same
> manufacturer contains the same components. Lenovo, for example, is infamous for
> shipping wildly different configurations under the same model number, and they
> all seem to fail in different ways.
> 
> Thanks for the feedback, as indeed quite a few patches for Arrandale are now
> upstream in drm-core-next (and drm-intel-next) and now seems to be a good point
> to check whether one of those holds the fix.

And here's the info about the gpu:

*-display
             description: VGA compatible controller
             product: Core Processor Integrated Graphics Controller
             vendor: Intel Corporation
             physical id: 2
             bus info: pci@0000:00:02.0
             version: 02
             width: 64 bits
             clock: 33MHz
             capabilities: msi pm bus_master cap_list rom
             configuration: driver=i915 latency=0
             resources: irq:48 memory:90000000-903fffff memory:80000000-8fffffff ioport:70b0(size=8)

Indeed, drm-core-next gives a blank screen at boot, and it finally works after reverting the commit specified in https://bugzilla.kernel.org/show_bug.cgi?id=16496

Looks like we can close this bug? I'll subscribe to the above one.

Thankyou Brice and Corona for testing the patches and reporting back.