On Monday 28 December 2009, Jesse Barnes wrote:
This code should be completely gone in Eric's drm-intel-next branch
(from
git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel.git), so
hopefully when that lands upstream (if it hasn't already) things will
be solid for you.
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... */
-
On Monday 21 December 2009 16:06:43 Arnd Bergmann wrote:
- if (IS_G4X(dev)) {
- u16 gcfgc;
-
- /* Adjust render clock... */
- pci_read_config_word(dev-pdev, GCFGC, gcfgc);
-
- /* Down to minimum... */
- gcfgc =
On Thursday 17 December 2009 19:13:59 Jesse Barnes wrote:
Ok, I'll try that. The problem is keeping me from doing any useful
upstream kernel work on my main machine, so I'm rather motivated ;-)
Another patch to try...
Thanks!
It's running fine so far, uptime 90 minutes together with
On Wed, 16 Dec 2009 22:41:27 +
Arnd Bergmann a...@arndb.de wrote:
On Wednesday 16 December 2009 21:36:36 Arnd Bergmann wrote:
On Wednesday 16 December 2009 21:30:05 Jesse Barnes wrote:
But you're sure powersave=0 was solid? Hmm...
It's hard to be sure when it sometimes takes a day
On Thursday 17 December 2009, Jesse Barnes wrote:
It does very little else that should affect things. You're sure
reverting the commit makes things ok?
No, not sure. But I've been running the kernel before that commit
for days without ever seeing a crash. 2.6.31 (also without that
commit but
On Thu, 17 Dec 2009 18:52:02 +0100
Arnd Bergmann a...@arndb.de wrote:
On Thursday 17 December 2009, Jesse Barnes wrote:
It does very little else that should affect things. You're sure
reverting the commit makes things ok?
No, not sure. But I've been running the kernel before that commit
Hi,
You can disable most of that code by loading i915 with 'powersave=0'.
If that patch really is at fault the powersave=0 should work around the
issue as well.
It's been implicated in another issue (some display flicker and
underruns) so I'm pretty sure there's something wrong with it in
On Tuesday 15 December 2009, Arnd Bergmann wrote:
On Monday 14 December 2009, Jesse Barnes wrote:
This patch removes the suspect portion of the dynamic clock control
code. Hopefully it'll be as stable as powersave=0 in your config
(assuming powersave=0 works :).
Ok, great! The machine
On Wed, 16 Dec 2009 21:20:34 +
Arnd Bergmann a...@arndb.de wrote:
On Wednesday 16 December 2009 20:18:23 Jesse Barnes wrote:
On Wed, 16 Dec 2009 14:53:11 +0100
Arnd Bergmann a...@arndb.de wrote:
It's working fine so far, no more crashes, but I supposed this
effectively disables
On Wednesday 16 December 2009 21:36:36 Arnd Bergmann wrote:
On Wednesday 16 December 2009 21:30:05 Jesse Barnes wrote:
But you're sure powersave=0 was solid? Hmm...
It's hard to be sure when it sometimes takes a day before a
broken version crashes. I can keep running this kernel with and
On Wednesday 16 December 2009 21:30:05 Jesse Barnes wrote:
But you're sure powersave=0 was solid? Hmm...
It's hard to be sure when it sometimes takes a day before a
broken version crashes. I can keep running this kernel with and
without powersave=0 some more and tell you if it stays
On Wednesday 16 December 2009 20:18:23 Jesse Barnes wrote:
On Wed, 16 Dec 2009 14:53:11 +0100
Arnd Bergmann a...@arndb.de wrote:
It's working fine so far, no more crashes, but I supposed this
effectively disables the power saving on my card again, right?
The patch just disables one
On Monday 14 December 2009, Jesse Barnes wrote:
This patch removes the suspect portion of the dynamic clock control
code. Hopefully it'll be as stable as powersave=0 in your config
(assuming powersave=0 works :).
Ok, great! The machine is still running fine with powersave=0 so
far. I'll try
On Mon, 14 Dec 2009 07:54:05 +1000
Dave Airlie airl...@redhat.com wrote:
On Sun, 2009-12-13 at 21:31 +, Arnd Bergmann wrote:
On Sunday 13 December 2009 20:00:18 Daniel Vetter wrote:
On Sun, Dec 13, 2009 at 12:30:25PM +, Arnd Bergmann wrote:
And now it's obvious that my computer
On Mon, 14 Dec 2009 20:38:09 +
Arnd Bergmann a...@arndb.de wrote:
On Monday 14 December 2009 18:20:15 Jesse Barnes wrote:
You can disable most of that code by loading i915 with
'powersave=0'. If that patch really is at fault the powersave=0
should work around the issue as well.
Ok,
On Monday 14 December 2009 18:20:15 Jesse Barnes wrote:
You can disable most of that code by loading i915 with 'powersave=0'.
If that patch really is at fault the powersave=0 should work around the
issue as well.
Ok, I'll try that and let you know. Running the kernel before your
patch has not
On Sun, Dec 13, 2009 at 12:30:25PM +, Arnd Bergmann wrote:
And now it's obvious that my computer hates me. 12 hours of uptime, one reboot
to check the old other version is broken, it crashes. I reboot into the
good version, send out the above email and the next minute it crashes again.
On Sunday 13 December 2009 12:18:24 Arnd Bergmann wrote:
On Wednesday 09 December 2009 05:38:07 Dave Airlie wrote:
On Wed, 2009-12-09 at 00:07 +0100, Arnd Bergmann wrote:
On Tuesday 08 December 2009, Dave Airlie wrote:
Sorry for blaming the wrong patch, especially if it already
On Wednesday 09 December 2009 05:38:07 Dave Airlie wrote:
On Wed, 2009-12-09 at 00:07 +0100, Arnd Bergmann wrote:
On Tuesday 08 December 2009, Dave Airlie wrote:
Sorry for blaming the wrong patch, especially if it already caused a
lot
of work. I'll try blaming ec2a4c3fdc8
On Sun, 2009-12-13 at 21:31 +, Arnd Bergmann wrote:
On Sunday 13 December 2009 20:00:18 Daniel Vetter wrote:
On Sun, Dec 13, 2009 at 12:30:25PM +, Arnd Bergmann wrote:
And now it's obvious that my computer hates me. 12 hours of uptime, one
reboot
to check the old other version
On Sunday 13 December 2009 20:00:18 Daniel Vetter wrote:
On Sun, Dec 13, 2009 at 12:30:25PM +, Arnd Bergmann wrote:
And now it's obvious that my computer hates me. 12 hours of uptime, one
reboot
to check the old other version is broken, it crashes. I reboot into the
good version,
On Tue, 2009-12-08 at 22:59 +0100, Arnd Bergmann wrote:
On Monday 07 December 2009, Arnd Bergmann wrote:
After upgrading one of my machines to 2.6.32, I saw hangs after one to
thirty minutes after
booting, with random data written to parts of the frame buffer. I've
bisected it down
to
On Tuesday 08 December 2009, Dave Airlie wrote:
Sorry for blaming the wrong patch, especially if it already caused a lot
of work. I'll try blaming ec2a4c3fdc8 drm/i915: get the bridge device
once now, that is the next-best candidate that my bisection pointed to,
but I'll do more
On Monday 07 December 2009, Arnd Bergmann wrote:
After upgrading one of my machines to 2.6.32, I saw hangs after one to thirty
minutes after
booting, with random data written to parts of the frame buffer. I've bisected
it down
to 620f37811d drm: prune modes when output is disconnected.,
After upgrading one of my machines to 2.6.32, I saw hangs after one to thirty
minutes after
booting, with random data written to parts of the frame buffer. I've bisected
it down
to 620f37811d drm: prune modes when output is disconnected., which was merged
in 2.6.32-rc1. Connecting a serial
26 matches
Mail list logo
