linux-kernel - Re: [BISECTED] drm: random hang since 620f378 "drm: prune modes when ..."

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200912211606.43789.arnd@arndb.de>
Date:	Mon, 21 Dec 2009 16:06:43 +0000
From:	Arnd Bergmann <arnd@...db.de>
To:	Jesse Barnes <jbarnes@...tuousgeek.org>
Cc:	keithp@...thp.com, Daniel Vetter <daniel.vetter@...ll.ch>,
	linux-kernel@...r.kernel.org, Dave Airlie <airlied@...hat.com>,
	dri-devel@...ts.sourceforge.net
Subject: Re: [BISECTED] drm: random hang since 620f378 "drm: prune modes when ..."

On Thursday 17 December 2009 19:13:59 Jesse Barnes wrote:
> Another patch to try...

The machine has been working fine for almost two days with this.

> -
> -       if (IS_G4X(dev)) {
> -               u16 gcfgc;
> -
> -               /* Adjust render clock... */
> -               pci_read_config_word(dev->pdev, GCFGC, &gcfgc);
> -
> -               /* Down to minimum... */
> -               gcfgc &= ~GM45_GC_RENDER_CLOCK_MASK;
> -               gcfgc |= GM45_GC_RENDER_CLOCK_266_MHZ;
> -
> -               pci_write_config_word(dev->pdev, GCFGC, gcfgc);

Interestingly, I could not even find GCFGC in the public documentation,
but it also doesn't seem to be what it was in older chips.

The value in there is 0x0025, which does not make any sense whatsoever
according to the definitions in the header file. Writing
GM45_GC_RENDER_CLOCK_266_MHZ in there manually does not seem to have an
effect either, the machine does not crash and the value still remains
at 0x0025.

I tried "while true ; do sudo setpci -s 00:02.1 f0.W=0028 ; done".

I'll try the patch below next, not touching the register at all.

> -/* Note that no increase function is needed for this - increase_renderclock()
> - *  will also rewrite these bits
> - */
> -void intel_decrease_displayclock(struct drm_device *dev)
> -{
> -       if (IS_IRONLAKE(dev))
> -               return;
> -
> -       if (IS_I945G(dev) || IS_I945GM(dev) || IS_I915G(dev) ||
> -           IS_I915GM(dev)) {
> -               u16 gcfgc;
> -
> -               /* Adjust render clock... */
> -               pci_read_config_word(dev->pdev, GCFGC, &gcfgc);
> -
> -               /* Down to minimum... */
> -               gcfgc &= ~0xf0;
> -               gcfgc |= 0x80;
> -
> -               pci_write_config_word(dev->pdev, GCFGC, gcfgc);
> -       }
> -}

This does not do anything on G4X, right? I actually put this function
back in (still doesn't crash), but then I noticed that the registers
are not accessed at all on my machine in this function.

	Arnd

--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3792,7 +3792,7 @@ void intel_increase_renderclock(struct drm_device *dev, bool schedule)
 	}
 
 	/* Restore render clock frequency to original value */
-	if (IS_G4X(dev) || IS_I9XX(dev))
+	if (IS_I9XX(dev))
 		pci_write_config_word(dev->pdev, GCFGC, dev_priv->orig_clock);
 	else if (IS_I85X(dev))
 		pci_write_config_word(dev->pdev, HPLLCC, dev_priv->orig_clock);
@@ -3816,18 +3816,7 @@ void intel_decrease_renderclock(struct drm_device *dev)
 		return;
 	}
 
-	if (IS_G4X(dev)) {
-		u16 gcfgc;
-
-		/* Adjust render clock... */
-		pci_read_config_word(dev->pdev, GCFGC, &gcfgc);
-
-		/* Down to minimum... */
-		gcfgc &= ~GM45_GC_RENDER_CLOCK_MASK;
-		gcfgc |= GM45_GC_RENDER_CLOCK_266_MHZ;
-
-		pci_write_config_word(dev->pdev, GCFGC, gcfgc);
-	} else if (IS_I965G(dev)) {
+	if (IS_I965G(dev)) {
 		u16 gcfgc;
 
 		/* Adjust render clock... */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/