[BUG 2.6.38] drm/i915: rampant video-corruption on Intel 865G

[BUG 2.6.38] drm/i915: rampant video-corruption on Intel 865G

[René Herman]

Good day.

2.6.38 (-final) unfortunately is largely unusable on Intel 865G, and 
more old Intel graphics hardware as reported for example for Debian on 
855G at:

http://www.linux-archive.org/debian-kernel/503229-bug-619022-linux-image-2-6-38-1-686-screen-corruption-i855.html

Most web pages won't render without corrupting, nor does scrolling a 
terminal a few times. I see from the above Debian report that it is/was 
known but it's indeed not fixed in final on 855/865 by anything which 
may have happened in response.

I do not have the time currently to fully bisect this and I assume it's 
known what the culprit is going to be anyway; I could revert specific 
commits on command and/or test fixes on top of 2.6.38-final; for know 
I've simply reverted to 2.6.37.4 where everything is fine.

(PS: most people using graphics hardware this plain/old will not deeply 
care for graphics; I in fact once bought the machine specifically with 
the "well supported, no-thrills" basic, integrated Intel graphics as a 
reason but it has given me only grief in that department, with years of 
X11 instability. This older hardware seems to receive little or no 
testing from the Intel graphics developers and if it's holding back 
development, I expect most users would not not mind or even welcome it 
being split of into a separate, maintained but no longer "improved" 
driver, both kernel- and X11-side).

00:00.0 Host bridge: Intel Corporation 82865G/PE/P DRAM 
Controller/Host-Hub Interface (rev 02)
00:02.0 VGA compatible controller: Intel Corporation 82865G Integrated 
Graphics Controller (rev 02)
00:03.0 PCI bridge: Intel Corporation 82865G/PE/P PCI to CSA Bridge (rev 02)
00:06.0 System peripheral: Intel Corporation 82865G/PE/P Processor to 
I/O Memory Interface (rev 02)
00:1d.0 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB 
UHCI Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB 
UHCI Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB 
UHCI Controller #3 (rev 02)
00:1d.3 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB 
UHCI Controller #4 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB2 
EHCI Controller (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev c2)
00:1f.0 ISA bridge: Intel Corporation 82801EB/ER (ICH5/ICH5R) LPC 
Interface Bridge (rev 02)
00:1f.1 IDE interface: Intel Corporation 82801EB/ER (ICH5/ICH5R) IDE 
Controller (rev 02)
00:1f.2 IDE interface: Intel Corporation 82801EB (ICH5) SATA Controller 
(rev 02)
00:1f.3 SMBus: Intel Corporation 82801EB/ER (ICH5/ICH5R) SMBus 
Controller (rev 02)
00:1f.5 Multimedia audio controller: Intel Corporation 82801EB/ER 
(ICH5/ICH5R) AC'97 Audio Controller (rev 02)
02:01.0 Ethernet controller: Intel Corporation 82547EI Gigabit Ethernet 
Controller

Regards,
Rene

Re: [BUG 2.6.38] drm/i915: rampant video-corruption on Intel 865G

[René Herman]

On 03/24/2011 08:21 AM, Chris Wilson wrote:

Thanks for the reply. I see that:

> commit 29c5a587284195278e233eec5c2234c24fb2c204
> Author: Chris Wilson<chris@chris-wilson.co.uk>
> Date:   Thu Mar 17 15:23:22 2011 +0000
>
>      drm/i915: Fix tiling corruption from pipelined fencing

is not in Linus' tree, so I haven't been able to confirm yet. I do 
suppose that one should fix things even without the X11 changes? If not, 
I'd still have a problem until those have made their way through the 
distributions...

Regards,
Rene.

Re: [BUG 2.6.38] drm/i915: rampant video-corruption on Intel 865G

[René Herman]

On 03/24/2011 09:00 AM, Chris Wilson wrote:

>> I do suppose that one [ the kernel one] should fix things even
>> without the X11 changes? If not, I'd still have a problem until
>> those have made their way through the distributions...
>
> No, the bugs are distinct, but very similar in appearance, and both
> updates are required.

That won't do then, will it? Kernel 2.6.38 then requires a new and not 
even released user space whereas 2.6.37 works fine. I suppose the fix 
will from the kernel side then need to be reverting to .37 behaviour, at 
least on the affected hardware? (855 and 865 at least).

Regards,
Rene