On 07-Jul-2000 Petr Vandrovec wrote:
> thunder7@xs4all.nl wrote:
>
>> I've just switched from a G200 to G400, and I now see fbcon
>> corruption
>> about once a minute (lines from another console, lines from another
>> console halfway between lines on the current console, ugly black and
>> white patters that look very wrong, lines that were previously on
>> other consoles, you name it I see it).
>
>> c:\utility\linux\loadlin\loadlin c:\utility\linux\loadlin\2217pre9
>> root=/dev/hda1 video=matrox:vesa:0x11E,fv:80
>
>> mode "1600x1200-80"
>> # D: 205.846 MHz, H: 99.347 kHz, V: 79.989 Hz
>> geometry 1600 1200 1600 5241 16
>> timings 4858 272 48 32 5 152 5
>> accel true
>> rgba 5/11,6/5,5/0,0/0
>> endmode
>
>> To illustrate, I had to press ^L in vim at least 10 times while
>> composing this :-(
>
> Terje Gjosater later wrote:
>
>> I see similar fbcon corruption in 2.4.0-test1-ac13 and
>> 2.4.0-test2-pre4
>> with G400. No problems with my old G200. X is XFree86-4.0.1.
>
> Hi,
> up to now nobody pointed to me that such problem exists. I'm using
> dualhead
> G400 in daily usage (but with 1024x768 and either 8 (console) or
> 16bpp (fbtv))
> and I did never saw this problem...
>
> Are you using plain kernels or not? In 2.4.0 I even have no idea
> how this
> can happen, as complete console system have to acquire console_lock
> and locks
> interrupts, so if you see line from another VT on your screen, you
> must have
> really screwed your kernel (or is it just garbage?)...
>
> In 2.2.x, locking is more lowlatency safe, so it is possible that
> often
> printk() from irq routines on such system can screw your display -
> but in
> such case you should see often deadlocks with no activity (PCI bus
> lockup).
>
> Also, do not use XFree 4.x.x with matroxfb. I did not investiage it
> personally yet, but today I received one bugreport that XFree 4.0.1
> screwes
> Matrox drawing engine and does not return it to safe state on switch
> from
> X back to console... Maybe 'options "fbdev"' is enough to fix this,
> maybe
> not (I hope that if you are using X4.x.x, you are using this option
> and
> that you are using X4.x.x which understand fbdev accel type
> G400_ACCEL).
>
> In global, I have no idea how this could happen... Can you try
> 'fbset -accel off', maybe it fixes your troubles. But I really have
> no
> idea... Also, try it without X. Maybe X overclocks your drawing
> engine...
>
My problem (horisontal bands of garbage vhen scrolling in a VT with
matroxfb and XFree86-4.x.x) disappeared after I upgraded the XFree86
RPMS from XFree86-*-4.0.1-1mdk to XFree86-*-4.0.1-2mdk (from
Mandrake-devel). I changed back to XFree86-*-4.0.1-1mdk again, and the
corruption came back, so it was probably not a kernel problem at all.
Terje Gjøsæter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jul 07 2000 - 21:00:21 EST