[9fans] keyboard problems after aux/vga

[9fans] keyboard problems after aux/vga

[Tim Wiess]

9fans,
i recently swapped my old terminal out for a small VIA EPIA M1000
based system.  everything's working well when i boot straight up into
rc, but as soon as i start vga (vesa mode) the system stops receiving
keyboard input.  i'm trying to track this down right now, but i'm not
too familiar with VBE so i thought i'd solicit any suggestions from
the group first.  is there any reason that touching the VBE registers
would cause this?  there's no mouse cursor either, but that may be a
seperate issue.

i know others have run P9 on EPIA systems successfully, so this
could all be the result something funky with my setup....

thanks.

tim

Re: [9fans] keyboard problems after aux/vga

[erik quanstrom]

vesa is tough.  the first thing i would check is if X11 runs in vesa mode
under linux on this machine.

if vesa memory isn't where the driver expects or is a different size, you are
likely to overwrite something important.  are you trying the lowest vesa resolution?

- erik

Re: [9fans] keyboard problems after aux/vga

[Tim Wiess]

> vesa is tough.  the first thing i would check is if X11 runs in vesa mode
> under linux on this machine.
>
> if vesa memory isn't where the driver expects or is a different size, you are
> likely to overwrite something important.  are you trying the lowest vesa resolution?

    i've tried a variety of resolutions with the same results.
    i'll try X/vesa and see what happens....

Re: [9fans] keyboard problems after aux/vga

[ron minnich]

On 11/19/06, Tim Wiess <tim@nop.cx> wrote:
> > vesa is tough.  the first thing i would check is if X11 runs in vesa mode
> > under linux on this machine.
> >
> > if vesa memory isn't where the driver expects or is a different size, you are
> > likely to overwrite something important.  are you trying the lowest vesa resolution?
>
>     i've tried a variety of resolutions with the same results.
>     i'll try X/vesa and see what happens....

One thing that is very useful when debugging problems with vga etc. is
to have a serial console. Any chance you can set this up?

we hit this all the time with linuxbios; at some point, serial console
will save your life.

ron

Re: [9fans] keyboard problems after aux/vga

[Tim Wiess]

>>     i've tried a variety of resolutions with the same results.
>>     i'll try X/vesa and see what happens....
>
> One thing that is very useful when debugging problems with vga etc. is
> to have a serial console. Any chance you can set this up?
>
> we hit this all the time with linuxbios; at some point, serial console
> will save your life.

    yeah, i did set that up recently. interesting thing is that input is also
    lost on the console when i start vga.

    X/vesa does indeed work on this machine. so i guess i'll have to
    start looking at the vesa specs.

    tim

Re: [9fans] keyboard problems after aux/vga

[erik quanstrom]

a sure sign your kernel has executed the dread HCF instruction. ;-)
i don't know if this applies but you may want to check the xorg
drivers for references to your particular machine.

- erik

On Sun Nov 19 22:11:07 EST 2006, tim@nop.cx wrote:
>     yeah, i did set that up recently. interesting thing is that input is also
>     lost on the console when i start vga.
>
>     X/vesa does indeed work on this machine. so i guess i'll have to
>     start looking at the vesa specs.
>
>     tim

Re: [9fans] keyboard problems after aux/vga

[lucio]

[-- Attachment #1: Type: text/plain, Size: 1070 bytes --]

Don't count on HCF.  I have a Plan 9 server that loses the keyboard
quite a long way into (idle) operation and eventually also loses the
serial console keyboard, but is still accessible via telnet/ssh and
cpu.  And that is strictly in text display mode.  Mind you, I ought to
refresh my memory, in case it's making that up.

While on the subject of erratic keyboard behaviour, I have long last
seen the console keyboard strangeness where on an arbitrary sixteen
character boundary the keyboard handler seems to insert a character
from the previous line.  More likely, it's an off-by-one error that
skips past an existing character on input.  Here, backspace seems,
strangely, to be a contributing factor, but one seldom remembers what
exactly had happened on the previous line.  I use the console a lot
less than I used to, for totally external reasons, so it's been a
while since this bit me.

I also have a workstation that frequently doubles keystrokes (in RIO),
if anyone is interested in such oddities.  VESA does not feature here
at all.

++L

[-- Attachment #2: Type: message/rfc822, Size: 2834 bytes --]

From: erik quanstrom <quanstro@coraid.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] keyboard problems after aux/vga
Date: Sun, 19 Nov 2006 22:21:45 -0500
Message-ID: <2cee08563904ec4e6458c65ec233eaf8@coraid.com>

a sure sign your kernel has executed the dread HCF instruction. ;-)
i don't know if this applies but you may want to check the xorg
drivers for references to your particular machine.

- erik

On Sun Nov 19 22:11:07 EST 2006, tim@nop.cx wrote:
>     yeah, i did set that up recently. interesting thing is that input is also
>     lost on the console when i start vga.
>
>     X/vesa does indeed work on this machine. so i guess i'll have to
>     start looking at the vesa specs.
>
>     tim

Re: [9fans] keyboard problems after aux/vga

[Tim Wiess]

got some more time today to get back to this...
it turned out that the problem was that the PIT had just stopped
counting, after vga went into realmode when writing to /dev/realmode.
so all of the timers keyed off of timerintr were not being triggered,
such as the keyboard, uart and mouse cursor timers.

i don't have any docs on the machine's southbridge (VT8235) to
determine if there is something special that needs to be done in this
case, but manually reinitializing the PIT after coming back from
realmode does fix the problem.

i'll keep investigating....
any other thoughts/suggestions appreciated.

tim

Re: [9fans] keyboard problems after aux/vga

[Tim Wiess]

> a sure sign your kernel has executed the dread HCF instruction. ;-)

    actually the system is still operational, the mouse sort of works
    and it continues to responds to pings. the kernel also responds
    to a ctl-alt-del.


> i don't know if this applies but you may want to check the xorg
> drivers for references to your particular machine.

    yeah, i was planning on scanning through those also.