2.6.0-test1 + matroxfb = unuusable VC

2.6.0-test1 + matroxfb = unuusable VC

[Michel Eyckmans (MCE)]

Greetz,

I'm using (or rather: trying to use) matroxfb on 2.6.0-test1 (2.5.72 had 
the same problems) and am seeing the following:

 - The initial boot console works fine, but all other consoles have 
   scrolling problems. The area to the right of any scrolled text is 
   most often coloured white, whereas it should be black. When using vi, 
   it's even worse: white rectangles all over the place.

 - Right after switching from X to a text console, the fill color is not
   white, but sort of a folded ghost image of part of my X display;

 - Scrolling is not continuous: keep <enter> pushed down, and every so 
   often a jump of about 1/3 of the hight of the screen occurs, combined
   with a few lines that do use the correct black background;

 - Backspacing only works when the cursor is positioned at the end of the 
   command line. Anywhere else the positions to the right of the cursor 
   are not repainted.

I'm using these settings: video=matroxfb:vesa:0x11A,fh:92k,fv:160"

  MCE

Re: 2.6.0-test1 + matroxfb = unuusable VC

[Jurriaan]

From: Michel Eyckmans (MCE) <mce@pi.be>
Date: Sat, Jul 19, 2003 at 12:39:43AM +0200
> 
> Greetz,
> 
> I'm using (or rather: trying to use) matroxfb on 2.6.0-test1 (2.5.72 had 
> the same problems) and am seeing the following:
> 
>  - The initial boot console works fine, but all other consoles have 
>    scrolling problems. The area to the right of any scrolled text is 
>    most often coloured white, whereas it should be black. When using vi, 
>    it's even worse: white rectangles all over the place.
> 
>  - Right after switching from X to a text console, the fill color is not
>    white, but sort of a folded ghost image of part of my X display;
> 
>  - Scrolling is not continuous: keep <enter> pushed down, and every so 
>    often a jump of about 1/3 of the hight of the screen occurs, combined
>    with a few lines that do use the correct black background;
> 
>  - Backspacing only works when the cursor is positioned at the end of the 
>    command line. Anywhere else the positions to the right of the cursor 
>    are not repainted.
> 
> I'm using these settings: video=matroxfb:vesa:0x11A,fh:92k,fv:160"
> 
I can't say that I see any of that.

I'm using a G450 (AGP) on a KT400 chipset, XP-2600 cpu.

This is my kernel boot line:

kernel /boot/vmlinuz-260test1ac2 root=/dev/hda1 video=matroxfb:xres:1600,yres:1280,depth:16,pixclock:4116,left:304,right:64,upper:46,lower:1,hslen:192,vslen:3,fv:85 hdb=scsi apm=power-off ide0=ata66

Consoles, X, Xv for watching videos in X - it all works fine.

CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_AGP=y
CONFIG_AGP_VIA=y
CONFIG_DRM=y
CONFIG_DRM_MGA=y
CONFIG_RAW_DRIVER=y

CONFIG_FB=y
CONFIG_VIDEO_SELECT=y
CONFIG_FB_MATROX=y
CONFIG_FB_MATROX_G450=y
CONFIG_FB_MATROX_G100=y
CONFIG_VGA_CONSOLE=y
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_PCI_CONSOLE=y
CONFIG_FONTS=y
CONFIG_FONT_SUN12x22=y
CONFIG_LOGO=y
CONFIG_LOGO_LINUX_MONO=y
CONFIG_LOGO_LINUX_VGA16=y
CONFIG_LOGO_LINUX_CLUT224=y

This works for me.

Kind regards,
Jurriaan
-- 
management n.
1. Corporate power elites distinguished primarily by their distance from
actual productive work and their chronic failure to manage (see also suit).
Spoken derisively, as in "Management decided that ...". 2. Mythically, a
vast bureaucracy responsible for all the world's minor irritations.
Hackers' satirical public notices are often signed `The Mgt'; this derives
from the "Illuminatus" novels (see the Bibliography in Appendix C).
Debian (Unstable) GNU/Linux 2.5.75 4112 bogomips load av: 1.59 2.09 1.47

Re: 2.6.0-test1 + matroxfb = unuusable VC

[nick black]

Michel Eyckmans (MCE) assumed the extended riemann hypothesis and showed:
> I'm using (or rather: trying to use) matroxfb on 2.6.0-test1 (2.5.72 had 
> the same problems) and am seeing the following:
> 
>  - The initial boot console works fine, but all other consoles have 
>    scrolling problems. The area to the right of any scrolled text is 
>    most often coloured white, whereas it should be black. When using vi, 
>    it's even worse: white rectangles all over the place.
> 
>  - Right after switching from X to a text console, the fill color is not
>    white, but sort of a folded ghost image of part of my X display;

<snip>

i'm seeing the exact same issues.  i use to see similar problems in late
2.4's with agp turned on, where turning off agp sorted out the issue.
using 2.6 (test1-ac2), it happens whether agp is turned on or not.

some info:  (cmdline, dmesg, config, lspci -v -v for bridge/card):

video=matroxfb:vesa:0x1bb

PCI: No IRQ known for interrupt pin A of device 01:00.0. Please try 
	using pci=biosirq.
matroxfb: Matrox G400 (AGP) detected
matroxfb: MTRR's turned on
matroxfb: 1280x1024x24bpp (virtual: 1280x4368)
matroxfb: framebuffer at 0xD0000000, mapped to 0xe0805000, size 33554432
Console: switching to colour frame buffer device 160x64
fb0: MATROX VGA frame buffer device

CONFIG_FB=y
CONFIG_VIDEO_SELECT=y
CONFIG_FB_MATROX=y
CONFIG_FB_MATROX_G450=y
CONFIG_FB_MATROX_G100=y
CONFIG_VGA_CONSOLE=y
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_PCI_CONSOLE=y
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
CONFIG_LOGO=y
CONFIG_LOGO_LINUX_MONO=y
CONFIG_LOGO_LINUX_VGA16=y
CONFIG_LOGO_LINUX_CLUT224=y

01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 04)
			(prog-if 00 [VGA])
        Subsystem: Matrox Graphics, Inc. Millennium G400 Dual Head Max
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
			Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
			<TAbort- <MAbort- >SERR- <PERR-
        Latency: 32 (4000ns min, 8000ns max), cache line size 08
        Interrupt: pin A routed to IRQ 0
        Region 0: Memory at d0000000 (32-bit, prefetchable) [size=32M]
        Region 1: Memory at d2000000 (32-bit, non-prefetchable) [size=16K]
        Region 2: Memory at d3000000 (32-bit, non-prefetchable) [size=8M]
        Expansion ROM at <unassigned> [disabled] [size=64K]
        Capabilities: [dc] Power Management version 2
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,
				D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [f0] AGP version 2.0
                Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans-
				64bit- FW- AGP3- Rate=x1,x2,x4
                Command: RQ=32 ArqSz=0 Cal=0 SBA+ AGP+ GART64- 64bit- FW- 
				Rate=x1

00:00.0 Host bridge: VIA Technologies, Inc. VT8377 [KT400 AGP] Host Bridge
        Subsystem: VIA Technologies, Inc. VT8377 [KT400 AGP] Host Bridge
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
			Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
			<TAbort- <MAbort+ >SERR- <PERR-
        Latency: 8
        Region 0: Memory at c0000000 (32-bit, prefetchable) [size=256M]
        Capabilities: [a0] AGP version 3.5
                Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans-
				64bit- FW- AGP3- Rate=x1,x2,x4
                Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- 
				Rate=<none>
        Capabilities: [c0] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,
				D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

-- 
nick black <dank@reflexsecurity.com>
"np:  nondeterministic polynomial-time
the class of dashed hopes and idle dreams." - the complexity zoo

Re: 2.6.0-test1 + matroxfb = unuusable VC

[James Simmons]

> I'm using (or rather: trying to use) matroxfb on 2.6.0-test1 (2.5.72 had 
> the same problems) and am seeing the following:

Been away from my email for a time. I have a new laptop so I can get busy 
:-) I have this card at home so I can play with it this week end.

Re: 2.6.0-test1 + matroxfb = unuusable VC

[Michel Eyckmans (MCE)]

> > Actually, no. I've been stuck at 2.5.46 for *ages* due to a never ending 
> > succession of driver issues (still not all solved by the way). 2.5.72 was 
> > the next kernel I could actually try to use. A lot of change takes place
> > over that many kernel revisions.
>
> Which drivers issues ?

Nothing to worry about anymore. There were some matroxfb ones 
(oopses at boot only when actively using matroxfb, for instance) 
but also a ton of non-video related stuff: whenever one thing got 
fixed, something had been broken in the mean time. Some of it still 
not solved, by the way, (aha152x anyone?).

The matrox oopses were solved already before I applied Petr's 
matroxfb-2.5.72.gz patch.

MCE

Re: 2.6.0-test1 + matroxfb = unuusable VC

[nick black]

Michel Eyckmans (MCE) assumed the extended riemann hypothesis and showed:
> >  Anyway, can you try applying matroxfb-2.5.72.gz from 
> > ftp://platan.vc.cvut.cz/pub/linux/matrox-latest to your tree (you can
> > enable only matroxfb after patching, no other fbdev will work) and retry
> > tests?
> 
> YES! No more ghost X image, no more white rectangles, no more sudden 
> jump scrolling, and a backspace key that actually works again.

indeed, this patch also fixes all strange behavior i was seeing when
applied to 2.6.0-test1-ac3 yesterday; i haven't noticed a problem yet.
james, if you have time to pull the old behavior apart and push patches
for testing that may have been missed, i've got two cards that are fixed
by this patch.

-- 
nick black <dank@reflexsecurity.com>
"np:  nondeterministic polynomial-time
the class of dashed hopes and idle dreams." - the complexity zoo

Re: 2.6.0-test1 + matroxfb = unuusable VC

[James Simmons]

> > Are you sure it was matroxfb and not DRI what changed?
> 
> Actually, no. I've been stuck at 2.5.46 for *ages* due to a never ending 
> succession of driver issues (still not all solved by the way). 2.5.72 was 
> the next kernel I could actually try to use. A lot of change takes place
> over that many kernel revisions.

Which drivers issues ?
 
> jump scrolling, and a backspace key that actually works again. Please 
> do consider pushing (some of) this to Linus for inclusion into the 
> 2.6.0.test series!

So bug fixes in the orginal driver must of been dropped. 

Re: 2.6.0-test1 + matroxfb = unuusable VC

[Petr Vandrovec]

On 25 Jul 03 at 0:17, Michel Eyckmans (MCE) wrote:
> >  Anyway, can you try applying matroxfb-2.5.72.gz from 
> > ftp://platan.vc.cvut.cz/pub/linux/matrox-latest to your tree (you can
> > enable only matroxfb after patching, no other fbdev will work) and retry
> > tests?
> 
> YES! No more ghost X image, no more white rectangles, no more sudden 
> jump scrolling, and a backspace key that actually works again. Please 
> do consider pushing (some of) this to Linus for inclusion into the 
> 2.6.0.test series!

Impossible. It reverts huge parts of the fbdev API almost completely to 
the 2.4.x state, and I was already outvoted in that vote couple of 
times since January.

BTW, with my patch accented characters works correctly only on VT1.
I'm not sure how it behaves on Linus tree...

And I'm not saying that there are no bugs in the matroxfb which is in
Linus's kernel. But as nobody even answered my question I sent out on 
monday whether it is correct that FBIOGETCMAP ioctl can overwrite arbitrary 
kernel memory, I kinda lost an interest in the stock fbdev...

                                           Best regards,
                                                Petr Vandrovec

Re: 2.6.0-test1 + matroxfb = unuusable VC

[Michel Eyckmans (MCE)]

> Are you sure it was matroxfb and not DRI what changed?

Actually, no. I've been stuck at 2.5.46 for *ages* due to a never ending 
succession of driver issues (still not all solved by the way). 2.5.72 was 
the next kernel I could actually try to use. A lot of change takes place
over that many kernel revisions.

But "never mind" (although... :-), because...

>  Anyway, can you try applying matroxfb-2.5.72.gz from 
> ftp://platan.vc.cvut.cz/pub/linux/matrox-latest to your tree (you can
> enable only matroxfb after patching, no other fbdev will work) and retry
> tests?

YES! No more ghost X image, no more white rectangles, no more sudden 
jump scrolling, and a backspace key that actually works again. Please 
do consider pushing (some of) this to Linus for inclusion into the 
2.6.0.test series!

Thanks,

 MCE

Re: 2.6.0-test1 + matroxfb = unuusable VC

[Petr Vandrovec]

On 24 Jul 03 at 1:05, Michel Eyckmans (MCE) wrote:
> > > In this case, does it happen if you exit X, or only if you are switching
> > > to the console while X are active? If it happens only in second case, then
> > > it is bug (I believe fixed long ago) in XFree mga driver: it was sometime
> >
> > it is the latter case, thanks for the info!  regardless, the 2.6.0-test1
> > problems continue; i'll update my x this evening if my version doesn't
> > contain the fix.
> 
> After reading this, I enthousiastically upgraded from Xfree 4.2.0 to 
> 4.3.0, but nothing changed. :-( The problem is indeed X-related, but 
> refuses to go away after the upgrade.
> 
> Also, I've had 4.2.0 and several earlier X versions working just fine
> with the "old" matroxfb in the same setup that I'm using now. Was there 
> a bug workaround for this issue in the old driver? If so, is there any
> hope of it returning?

Are you sure it was matroxfb and not DRI what changed? I do not know
about any changes... But in the past (2.4.x) if XFree would set videomode
through /dev/fbX while being invisible (but with controlling tty), nothing
would change on display, as only videomode for XFree's VT would change. 
Now when there is no such virtualization, XFree server can change videomode 
of your actually visible console by mistake, while your VT could still
cache its idea of screen somewhere. But it does not look very possible,
you would probably notice that display resolution changed behind you...

Anyway, can you try applying matroxfb-2.5.72.gz from 
ftp://platan.vc.cvut.cz/pub/linux/matrox-latest to your tree (you can
enable only matroxfb after patching, no other fbdev will work) and retry
tests? Except other things it restores /dev/fbX behavior from 2.4.x
kernels. I have running XFree (Debian unstable, G550, gnome2, since last
week with metacity WM, with sawfish2 before) & VMware in the 
background while being at textual console all the time, and I see no 
strange rectangles on the screen...
                                                Petr
                                                

Re: 2.6.0-test1 + matroxfb = unuusable VC

[Michel Eyckmans (MCE)]

Greetz,

> > In this case, does it happen if you exit X, or only if you are switching
> > to the console while X are active? If it happens only in second case, then
> > it is bug (I believe fixed long ago) in XFree mga driver: it was sometime
>
> it is the latter case, thanks for the info!  regardless, the 2.6.0-test1
> problems continue; i'll update my x this evening if my version doesn't
> contain the fix.

After reading this, I enthousiastically upgraded from Xfree 4.2.0 to 
4.3.0, but nothing changed. :-( The problem is indeed X-related, but 
refuses to go away after the upgrade.

Also, I've had 4.2.0 and several earlier X versions working just fine
with the "old" matroxfb in the same setup that I'm using now. Was there 
a bug workaround for this issue in the old driver? If so, is there any
hope of it returning?

MCE

Re: 2.6.0-test1 + matroxfb = unuusable VC

[nick black]

Petr Vandrovec assumed the extended riemann hypothesis and showed:
> In this case, does it happen if you exit X, or only if you are switching
> to the console while X are active? If it happens only in second case, then
> it is bug (I believe fixed long ago) in XFree mga driver: it was sometime

it is the latter case, thanks for the info!  regardless, the 2.6.0-test1
problems continue; i'll update my x this evening if my version doesn't
contain the fix.

-- 
nick black <dank@reflexsecurity.com>
"np:  nondeterministic polynomial-time
the class of dashed hopes and idle dreams." - the complexity zoo

Re: 2.6.0-test1 + matroxfb = unuusable VC

[Petr Vandrovec]

On 21 Jul 03 at 14:33, nick black wrote:
> Petr Vandrovec assumed the extended riemann hypothesis and showed:
> > I do not think that it has anything to do with AGP, as matroxfb does not
> > initiate any AGP transfers. 
> 
> indeed, the issue would only happen after switching from x back to
> console.  regardless, not building agp worked aorund the 2.4 problem for
> me.

In this case, does it happen if you exit X, or only if you are switching
to the console while X are active? If it happens only in second case, then
it is bug (I believe fixed long ago) in XFree mga driver: it was sometime
reprogramming color depth and line length in the accelerator even when
inactive (Gnome1 clock applet running in top right corner was known to
trigger this, depending on clock settings matroxfb would cease to
work in one second or (up to) one minute after VT switch, depending on clock
applet setting... it is possible that it happened only with kernel mga dri
driver active, but I'm not 100% sure).

I know no other workaround than using same color depth and same xres_virtual
(vxres on fbdev & desktop width in X) in X and on the console.
                                                    Best regards,
                                                        Petr Vandrovec
                                                        vandrove@vc.cvut.cz
                                                        

Re: 2.6.0-test1 + matroxfb = unuusable VC

[nick black]

Petr Vandrovec assumed the extended riemann hypothesis and showed:
> I do not think that it has anything to do with AGP, as matroxfb does not
> initiate any AGP transfers. 

indeed, the issue would only happen after switching from x back to
console.  regardless, not building agp worked aorund the 2.4 problem for
me.

> > some info:  (cmdline, dmesg, config, lspci -v -v for bridge/card):
> > video=matroxfb:vesa:0x1bb
> 
> I think that you are using fbset somewhere in your initscripts. Either
> do not do that, or apply 
> ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/matroxfb-2.5.72.gz.

i am pretty sure no fbset is being employed; i find no reference to it
in /etc, nor does it seem to be installed anywhere.  i certainly haven't
set it up myself on this machine.

> And reconfigure your system to assign IRQ to the AGP devices too.
> matroxfb uses it for delivering some notifications to the userspace
> programs...
> >         Interrupt: pin A routed to IRQ 0
> ... if it hooked IRQ0 as MGA interrupt, anything can happen.

is this a bios issue?  if not, need i try anything save the suggested
irq=pcibios?  i'll report once i get home and can try things out;
thanks!

-- 
nick black <dank@reflexsecurity.com>
"np:  nondeterministic polynomial-time
the class of dashed hopes and idle dreams." - the complexity zoo

Re: 2.6.0-test1 + matroxfb = unuusable VC

[Petr Vandrovec]

On 21 Jul 03 at 17:45, nick black wrote:

> i'm seeing the exact same issues.  i use to see similar problems in late
> 2.4's with agp turned on, where turning off agp sorted out the issue.
> using 2.6 (test1-ac2), it happens whether agp is turned on or not.

I do not think that it has anything to do with AGP, as matroxfb does not
initiate any AGP transfers. 
 
> some info:  (cmdline, dmesg, config, lspci -v -v for bridge/card):
> 
> video=matroxfb:vesa:0x1bb

I think that you are using fbset somewhere in your initscripts. Either
do not do that, or apply 
ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/matroxfb-2.5.72.gz.

> PCI: No IRQ known for interrupt pin A of device 01:00.0. Please try 
>     using pci=biosirq.

And reconfigure your system to assign IRQ to the AGP devices too.
matroxfb uses it for delivering some notifications to the userspace
programs...

>         Interrupt: pin A routed to IRQ 0

... if it hooked IRQ0 as MGA interrupt, anything can happen.
                                                Best regards,
                                                    Petr Vandrovec
                                                    vandrove@vc.cvut.cz