[9fans] [frank@inua.be: Re: no frame buffer]

[9fans] [frank@inua.be: Re: no frame buffer]

[frank]

I don't see a follow-up on this topic... I hope someone still has an
idea.

----- Forwarded message from frank@inua.be -----

From: frank@inua.be
To: 9fans@9fans.net
Subject: Re: [9fans] no frame buffer
X-Virus-Scanned: Debian amavisd-new at mfilter3-v.gandi.net
Mail-Followup-To: 9fans@9fans.net
X-Virus-Scanned: clamav-milter 0.95.2 at lrelay02.edpnet.net
X-Virus-Status: Clean
X-BeenThere: 9fans@9fans.net
X-Mailman-Version: 2.1.10
Reply-To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.9fans.net>
List-Unsubscribe: <http://mail.9fans.net/options/9fans>,
	<mailto:9fans-request@9fans.net?subject=unsubscribe>
List-Archive: <http://mail.9fans.net/private/9fans>
List-Post: <mailto:9fans@9fans.net>
List-Help: <mailto:9fans-request@9fans.net?subject=help>
List-Subscribe: <http://mail.9fans.net/listinfo/9fans>,
	<mailto:9fans-request@9fans.net?subject=subscribe>

On Mon, May 24, 2010 at 12:00:14AM +0100, Ethan Grammatikidis wrote:
> Is it possible to limit the frame rate aux/vga sets? The reason I'm
> asking is:

No idea.

>> Whatever I use for monitor (vesa, vga) or vgasize, the
>> screen just turns black and the led of the monitor is blinking.
>
> I've had quite a lot of CRT monitors in the past. Many of them were
> detected as being more capable than they really were, so X would set the
> frame rate too high. A black screen with blinking led was a common
> symptom of that.

The same box with the same CRT runs X in 1280x1024x16 (didn't try
1600x1200).

Regarding Plan 9, I also tested it with:

- a plain old VGA monitor: just a blank screen
- a flat panel (vga connector): blank screen, "no signal"

Can it be that this is a driver issue?

I already tried to get more information using the -v and -V options of
aux/vga. With -m vesa, I always got the following, no matter what
resolution I asked:

main->snarf
vesa->snarf
vmf 100 vmdf 0 vf1 0 vbw 0
main->load
+vgactlw type vesa
-vgactlw type vesa

I also thought that I might get around it by using a specific
bios-string (-b option to aux/vga) but I don't know what I could
possibly use.

What can I do to debug this further?


Kind regards,

--
Frank Lenaerts ---------------------------------------- frank@inua.be



----- End forwarded message -----

--
Frank Lenaerts ---------------------------------------- frank@inua.be

Re: [9fans] [frank@inua.be: Re: no frame buffer]

[erik quanstrom]

On Wed May 26 12:33:49 EDT 2010, frank@inua.be wrote:
> I don't see a follow-up on this topic... I hope someone still has an
> idea.

not really.  you may wish to double-check the vga register
settings.  not sure about crt[13].
sometimes aux/vga -l text works when nothing else
does.

- erik

Re: [9fans] [frank@inua.be: Re: no frame buffer]

[frank]

On Wed, May 26, 2010 at 08:00:59PM -0400, erik quanstrom wrote:
> On Wed May 26 12:33:49 EDT 2010, frank@inua.be wrote:
> > I don't see a follow-up on this topic... I hope someone still has an
> > idea.
>
> not really.  you may wish to double-check the vga register

I used aux/vga -ip with some different resolutions. The only strange
thing I see is that under "dbdumpmode" "frequency=100" always comes
back.

> settings.  not sure about crt[13].

What do you mean with "crt[13]"?

> sometimes aux/vga -l text works when nothing else
> does.

I had already tried that, but it doesn't work either.

It seems I can stop searching. I have an identical box running Linux
and used lspci, which gave me some more info compared to the pci -v
output on Plan 9:

...
00:01.1 VGA compatible controller [0300]: National Semiconductor Corporation Geode GX2 Graphics Processor [100b:0030] (prog-if 00 [VGA controller])
	Subsystem: National Semiconductor Corporation Geode GX2 Graphics Processor [100b:0030]
	Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Region 0: Memory at 41000000 (32-bit, non-prefetchable) [size=16M]
	Region 1: Memory at 40ffc000 (32-bit, non-prefetchable) [size=16K]
	Region 2: Memory at 40ff8000 (32-bit, non-prefetchable) [size=16K]
	Region 3: Memory at 40ff4000 (32-bit, non-prefetchable) [size=16K]
	Kernel modules: gxfb
...

I googled for AMD GX2 graphics processor and the first result led to:
http://plan9.bell-labs.com/wiki/plan9/Supported_PC_hardware/index.html

...
The following cards are known not to work with VESA:

...snip...
    * AMD Geode GX2. Blank screen. Bug identified by Russ Cox, but hard to solve.
...


Too bad, but at least, I learned something. I'll use a Via Epia box as
terminal to start learning the rest;-)

> - erik

--
Frank Lenaerts ---------------------------------------- frank@inua.be

Re: [9fans] [frank@inua.be: Re: no frame buffer]

[David du Colombier]

> I googled for AMD GX2 graphics processor and the first result led to:
> http://plan9.bell-labs.com/wiki/plan9/Supported_PC_hardware/index.html
>
> ...
> The following cards are known not to work with VESA:
>
> ...snip...
>     * AMD Geode GX2. Blank screen. Bug identified by Russ Cox, but hard to
> solve. ...

I am the one who wrote that on the Plan 9 Wiki.

I encountered this problem with my WYSE Winterm 9150SE
two years ago.

Russ Cox helped me to work on that problem.

As far I remember, the problem is the function vbecall
(/sys/src/cmd/aux/vga/vesa.c) never return.

VESA call need to switch to real mode, but getting out
from it only work on some machines.

According to Russ Cox, the fix is to change the
kernel's bios execution to use either VM86 mode
or a software x86 emulator.

--
David du Colombier

Re: [9fans] [frank@inua.be: Re: no frame buffer]

[erik quanstrom]

> I am the one who wrote that on the Plan 9 Wiki.
>
> I encountered this problem with my WYSE Winterm 9150SE
> two years ago.
>
> Russ Cox helped me to work on that problem.
>
> As far I remember, the problem is the function vbecall
> (/sys/src/cmd/aux/vga/vesa.c) never return.
>
> VESA call need to switch to real mode, but getting out
> from it only work on some machines.
>
> According to Russ Cox, the fix is to change the
> kernel's bios execution to use either VM86 mode
> or a software x86 emulator.

are you sure that that still applies now that
interrupts are really turned off for vbe calls?

one way to tell the difference between stuck
in vbe land and hosed video is if ^T^Tr works,
it's just bad mode setting.

- erik