Possible to git-bisect which commit caused your problem?

Maybe next week. Looks like you can't reproduce it, right?

yeah, we have no G35 machine for reproduce. Better to try if current master fixed your problem.

Intel has no G35 machine, so driver development is done without hardware? You must be kidding.

And the "winner" is:

commit 4a42b01f5ee5a673716d6959dfe0e693b037eb48
Author: Keith Packard <keithp@keithp.com>
Date:   Sat Feb 16 18:16:12 2008 -0800

    Decode DSPCLK_GATE, dump PIPE*STAT, MI_MODE, MI_DISPLAY_POWER_DOWN, MI_ARB_STATE, MI_RDRET_STATE, ECOSKPD


Current master (66cdccb021a4748b2af41e415c36ed58ca808df6) didn't resolve the issue.

Have you turned on "ModeDebug"? Could you paste your X log?

ModeDebug was not turned on. I'll attach logfiles with ModeDebug on and off. The freeze happens with both variants.

Created attachment 14579 [details]
Xorg.0.log.freeze

Created attachment 14580 [details]
Xorg.0.log.freeze.ModeDebug

Stefan, are you sure you bisected correctly?  The commit you pointed at should only have had an effect if you had modedebug enabled, and more than that, it just reads some extra registers, so it shouldn't have any side effects anyway.

Jesse, yes, I double checked this since I couldn't believe it first either. 
i830CompareRegsToSnapshot() and i830TakeRegSnapshot(), which access i830_snapshot[] (altered by the commit) are also called when ModeDebug is not turned on.

But I was told today, that I am testing on a pre-production system (with DVI+VGA onboard). So in case, you cannot reproduce this issue, I suggest to close the bugreport as INVALID and we can easily plug in an ATI PCIe card instead. :-)

Stefan, in the end of #14559, you meant commit from my dmi quirk patch caused your problem as it's here. But now you bisect to keith's debug patch, i'm little confused which one is the real culprit.

Revert keith's debug patch resolves your problem? If yes, How about try to comment each line of below to find out which one causes hang?

+  DEFINEREG2(DSPCLK_GATE_D, i830_debug_dspclk_gate_d),
    ...
+  DEFINEREG2(PIPEASTAT, i830_debug_pipestat),
    ...
+  DEFINEREG2(PIPEBSTAT, i830_debug_pipestat),
    ...
+    DEFINEREG(MI_MODE),
+    DEFINEREG(MI_DISPLAY_POWER_DOWN),
+    DEFINEREG(MI_ARB_STATE),
+    DEFINEREG(MI_RDRET_STATE),
+    DEFINEREG(ECOSKPD),

We're received one G35, gordon will try to reproduce this one anyway.

oh, that's #14552 as in your first report.

(In reply to comment #12)
> Stefan, in the end of Bug #14552, you meant commit from my dmi quirk patch
> caused your problem as it's here. 

No, at this point I didn't bisect yet, which commit broke it. See also my first comment of this bugreport.

> But now you bisect to keith's debug patch, i'm little confused which one
> is the real culprit.

Keith's one.

> Revert keith's debug patch resolves your problem? If yes, How about try to
> comment each line of below to find out which one causes hang?
> 
> +  DEFINEREG2(DSPCLK_GATE_D, i830_debug_dspclk_gate_d),
>     ...
> +  DEFINEREG2(PIPEASTAT, i830_debug_pipestat),
>     ...
> +  DEFINEREG2(PIPEBSTAT, i830_debug_pipestat),
>     ...
> +    DEFINEREG(MI_MODE),
> +    DEFINEREG(MI_DISPLAY_POWER_DOWN),
> +    DEFINEREG(MI_ARB_STATE),
> +    DEFINEREG(MI_RDRET_STATE),
> +    DEFINEREG(ECOSKPD),

Will try this.

> We're received one G35, gordon will try to reproduce this one anyway.

Thanks!

I can't reproduce this on the Asus G35 board.

Ok. I finally found it. It's this line:

  DEFINEREG(MI_DISPLAY_POWER_DOWN),

If I comment it the machine no longer freezes.

(In reply to comment #15)
> I can't reproduce this on the Asus G35 board.

You know that G35 (0x2982) is 965G compatible (at least the driver handles it so) and not G33CLASS compatible, right? Sure that your G35 has the Device ID 0x2982? Of course it would be possible that the MI_DISPLAY_POWER_DOWN register is still missing on my preproduction machine or located at a different position. :-(

(In reply to comment #11)
> i830CompareRegsToSnapshot() and i830TakeRegSnapshot(), which access
> i830_snapshot[] (altered by the commit) are also called when ModeDebug is
> not turned on.

I'm wondering why this is done. Is there missing a 

  if (pI830->debug_modes) { ... } 

around these calls? 

I'm also wondering why it still works for the first Xserver startup.

Oh, yeah, some of those registers are Crestline only. I'll bet attempting to read them on G35 will cause failure...

(In reply to comment #19)
> Oh, yeah, some of those registers are Crestline only. I'll bet attempting to
> read them on G35 will cause failure...
Right, in

  Intel 965 Express Chipset Family and Intel G35 Express Chipset Graphics
  Controller PRM --> 8.12.1 MI_DISPLAY_POWER_DOWN ...

this register is marked as "DevCL only". Looks like a found a driver bug and
it's not related to the pre-production system I'm testing on. :-)

(In reply to comment #17)
> You know that G35 (0x2982) is 965G compatible (at least the driver handles it
> so) and not G33CLASS compatible, right? Sure that your G35 has the Device ID
> 0x2982? 
Right. My G35 is 0x2982 (rev 03).

(In reply to comment #21)
> Right. My G35 is 0x2982 (rev 03).
Mine is "rev 1". But see also commenta #19/20. 

I've commented out MI_DISPLAY_POWER_DOWN in master. Thanks.

Thanks.

*** Bug 14784 has been marked as a duplicate of this bug. ***

*** Bug 15923 has been marked as a duplicate of this bug. ***