[9fans] Scrolling considered harmful

[t***@polynum.com]

Hello,

I had already reported that a machine froze hard when manipulating
windows under rio.

Indeed, nasty things arise when some program is spitting a huge amount
of text; window is blocking while there is more; I then, in the middle
of the process, switch to scrolling.

The nasty thing is writing in memory in the wrong place, since the
machine is hard frozen, and even soft reboot does no cure (I need to
halt and switch power off to have a really cold reboot).

Is somebody knowledgeable with this part of the code, to have clues
about where to search for the fault?

TIA

[erik quanstrom]

Post by t***@polynum.com
I had already reported that a machine froze hard when manipulating
windows under rio.
Indeed, nasty things arise when some program is spitting a huge amount
of text; window is blocking while there is more; I then, in the middle
of the process, switch to scrolling.
The nasty thing is writing in memory in the wrong place, since the
machine is hard frozen, and even soft reboot does no cure (I need to
halt and switch power off to have a really cold reboot).
Is somebody knowledgeable with this part of the code, to have clues
about where to search for the fault?

what driver are you using? i assume that this is the standard pc kernel?

- erik

[t***@polynum.com]

Post by erik quanstrom

Post by t***@polynum.com
Indeed, nasty things arise when some program is spitting a huge amount
of text; window is blocking while there is more; I then, in the middle
of the process, switch to scrolling.
The nasty thing is writing in memory in the wrong place, since the
machine is hard frozen, and even soft reboot does no cure (I need to
halt and switch power off to have a really cold reboot).

what driver are you using? i assume that this is the standard pc kernel?

Yes, it is the standard pc kernel. And I'm using vesa:

mouseport=ps2
monitor=vesa
vgasize=800x600x16

with a:

ATI Technologies Radeon 9200SE 5964 (rev. 0x01)

BTW, I had no problem before having to change the monitor. The new one
is a 20" LCD, and the thing can "decide" parameters on its own. With the
old monitor, I had not this...

Since the new monitor is also with "screen" ratio (1600x900), I wonder
if my untouched:

vgasize=800x600x16

can not be a problem (because I can also switch to scrolling and
resizing the window because lines wrap...). If the ratio is not to its
taste, there may be a buffer reserved for some size, with the hardware
(monitor/card) deciding for something else?

[erik quanstrom]

Post by t***@polynum.com
ATI Technologies Radeon 9200SE 5964 (rev. 0x01)
BTW, I had no problem before having to change the monitor. The new one
is a 20" LCD, and the thing can "decide" parameters on its own. With the
old monitor, I had not this...
Since the new monitor is also with "screen" ratio (1600x900), I wonder
vgasize=800x600x16
can not be a problem (because I can also switch to scrolling and
resizing the window because lines wrap...). If the ratio is not to its
taste, there may be a buffer reserved for some size, with the hardware
(monitor/card) deciding for something else?

i have seen that some ati cards are not happy with some modes.
you may wish to try cinap's realemu which is at

9fs atom # srv $nflag -q tcp!atom.9atom.org atom &&
# mount $nflag /srv/atom /n/atom atom
/n/atom/plan9/386/bin/aux/realemu

if realemu is run before aux/vga, you may have better luck.
some bioses allow one to set the amount of video memory.
that might be worth checking, too.

- erik

[t***@polynum.com]

Post by erik quanstrom

Post by t***@polynum.com
Since the new monitor is also with "screen" ratio (1600x900), I wonder
vgasize=800x600x16
can not be a problem (because I can also switch to scrolling and
resizing the window because lines wrap...). If the ratio is not to its
taste, there may be a buffer reserved for some size, with the hardware
(monitor/card) deciding for something else?

i have seen that some ati cards are not happy with some modes.
you may wish to try cinap's realemu which is at
9fs atom # srv $nflag -q tcp!atom.9atom.org atom &&
# mount $nflag /srv/atom /n/atom atom
/n/atom/plan9/386/bin/aux/realemu
if realemu is run before aux/vga, you may have better luck.
some bioses allow one to set the amount of video memory.
that might be worth checking, too.

Thanks again! I will do that when I have a slot of time (maybe some
days; but I will try and report).

[erik quanstrom]

I have retrieved atom aux/realemu and I will have to test.
But before, I will have to read the aux/vga sources to understand what
it expects. Because aux/vga -p gives me all the informations about the
vesa supported modes of the card, and even the monitor settings (I
wonder that the problem is here, that is monitor and card "discuss" and
the software is not part of the discussion). The informations (vesa: the

the problem is that the VBE calls that are used to set up
various video modes jump to vendor-provided real mode
code that is often buggy. the reason for emulation is
(a) to avoid problems associated with real-mode code
triggering interrupts the partial real-mode implementation

the 9 kernels provide is not prepared to handle, and
(b) to avoid invalid accesses caused by buggy real-mode
code.

yes it sounds implausable that the vendor code could be
that broken, but it's true!

- erik

[t***@polynum.com]

Post by erik quanstrom
the problem is that the VBE calls that are used to set up
various video modes jump to vendor-provided real mode
code that is often buggy. the reason for emulation is
(a) to avoid problems associated with real-mode code
triggering interrupts the partial real-mode implementation
the 9 kernels provide is not prepared to handle, and
(b) to avoid invalid accesses caused by buggy real-mode
code.

I will first master vgadb, plan9.ini and aux/vga to get a more sensible
vgasize. And afterwards I will insert aux/realemu to see if the freeze
do not happen again.

[t***@polynum.com]

So I have read the various man pages (starting from plan9.ini that only
sets environment values) to vga.

If I understand correctly, the vesa adjusting is only done if the
monitor variable is set to 'vesa', value that do not appear in the
database.

Previously, I have used other values for monitor, trying to match "more"
the monitor capacities. This ended up using vga.

With 'vesa', there is a setting done that is visibly "sent" to the
monitor by the video card (the monitor starts self-adjusting) and the
problem disappears. I have then set vgasize to the maximum value
reported by the VESA modes of the Radeon video card, and what is
announced to be supported by the monitor (the diverse informations
gathered from "aux/vga -p" could allow to add some entries to the video
database).

So, lesson: with a modern monitor, set monitor='vesa' to let the
software/video_card/monitor adjust themselves accordingly.

[t***@polynum.com]

Post by erik quanstrom
i have seen that some ati cards are not happy with some modes.
you may wish to try cinap's realemu which is at
9fs atom # srv $nflag -q tcp!atom.9atom.org atom &&
# mount $nflag /srv/atom /n/atom atom
/n/atom/plan9/386/bin/aux/realemu
if realemu is run before aux/vga, you may have better luck.
some bioses allow one to set the amount of video memory.
that might be worth checking, too.

I have retrieved atom aux/realemu and I will have to test.

But before, I will have to read the aux/vga sources to understand what
it expects. Because aux/vga -p gives me all the informations about the
vesa supported modes of the card, and even the monitor settings (I
wonder that the problem is here, that is monitor and card "discuss" and
the software is not part of the discussion). The informations (vesa: the
RADEON card; edid: the monitor 1600x900):

vesa flag Ulinear|Hlinear
vesa sig VESA 2.0
vesa oem ATI RADEON 9200 1.0
vesa vendor ATI Technologies Inc.
vesa product V280
vesa rev 01.00
vesa cap 8-bit-dac
vesa mem 134217728
vesa mode 0x6a 800x600x4 m4 planar
vesa mode 0x102 800x600x4 m4 planar
vesa mode 0x104 1024x768x4 m4 planar
vesa mode 0x182 320x200x8 m8 packed
vesa mode 0x10d 320x200x15 r5g5b5 direct
vesa mode 0x10e 320x200x16 r5g6b5 direct
vesa mode 0x10f 320x200x24 r8g8b8 direct
vesa mode 0x120 320x200x32 x8r8g8b8 direct
vesa mode 0x192 320x240x8 m8 packed
vesa mode 0x193 320x240x15 r5g5b5 direct
vesa mode 0x194 320x240x16 r5g6b5 direct
vesa mode 0x195 320x240x24 r8g8b8 direct
vesa mode 0x196 320x240x32 x8r8g8b8 direct
vesa mode 0x1a2 400x300x8 m8 packed
vesa mode 0x1a3 400x300x15 r5g5b5 direct
vesa mode 0x1a4 400x300x16 r5g6b5 direct
vesa mode 0x1a5 400x300x24 r8g8b8 direct
vesa mode 0x1a6 400x300x32 x8r8g8b8 direct
vesa mode 0x1b2 512x384x8 m8 packed
vesa mode 0x1b3 512x384x15 r5g5b5 direct
vesa mode 0x1b4 512x384x16 r5g6b5 direct
vesa mode 0x1b5 512x384x24 r8g8b8 direct
vesa mode 0x1b6 512x384x32 x8r8g8b8 direct
vesa mode 0x1c2 640x350x8 m8 packed
vesa mode 0x1c3 640x350x15 r5g5b5 direct
vesa mode 0x1c4 640x350x16 r5g6b5 direct
vesa mode 0x1c5 640x350x24 r8g8b8 direct
vesa mode 0x1c6 640x350x32 x8r8g8b8 direct
vesa mode 0x100 640x400x8 m8 packed
vesa mode 0x183 640x400x15 r5g5b5 direct
vesa mode 0x184 640x400x16 r5g6b5 direct
vesa mode 0x185 640x400x24 r8g8b8 direct
vesa mode 0x186 640x400x32 x8r8g8b8 direct
vesa mode 0x101 640x480x8 m8 packed
vesa mode 0x110 640x480x15 r5g5b5 direct
vesa mode 0x111 640x480x16 r5g6b5 direct
vesa mode 0x112 640x480x24 r8g8b8 direct
vesa mode 0x121 640x480x32 x8r8g8b8 direct
vesa mode 0x103 800x600x8 m8 packed
vesa mode 0x113 800x600x15 r5g5b5 direct
vesa mode 0x114 800x600x16 r5g6b5 direct
vesa mode 0x115 800x600x24 r8g8b8 direct
vesa mode 0x122 800x600x32 x8r8g8b8 direct
vesa mode 0x105 1024x768x8 m8 packed
vesa mode 0x116 1024x768x15 r5g5b5 direct
vesa mode 0x117 1024x768x16 r5g6b5 direct
vesa mode 0x118 1024x768x24 r8g8b8 direct
vesa mode 0x123 1024x768x32 x8r8g8b8 direct
vesa mode 0x107 1280x1024x8 m8 packed
vesa mode 0x119 1280x1024x15 r5g5b5 direct
vesa mode 0x11a 1280x1024x16 r5g6b5 direct
vesa mode 0x11b 1280x1024x24 r8g8b8 direct
vesa mode 0x124 1280x1024x32 x8r8g8b8 direct
vesa mode 0x109 132x25x4 m4 text
vesa mode 0x10a 132x43x4 m4 text
vesa mode 0x130 132x44x4 m4 text
edid mfr IVM
edid serialstr 1103020910036
edid name PLE2008HDS
edid product 21404
edid serial 10036
edid version 1.3
edid mfrdate 2012.9
edid size (cm) 45x25
edid gamma 2.20
edid vert (Hz) 55-76
edid horz (Hz) 30000-84000
edid pclkmax 170000000
edid flags activeoff
edid ***@60Hz
clock=25.175
shb=648 ehb=792 ht=800
vrs=490 vre=492 vt=525
hsync=- vsync=-
edid ***@73Hz
clock=31.5
shb=648 ehb=824 ht=832
vrs=489 vre=492 vt=520
hsync=- vsync=-
edid ***@75Hz
clock=31.5
shb=640 ehb=840 ht=840
vrs=481 vre=484 vt=500
hsync=- vsync=-
edid ***@56Hz
clock=36
shb=800 ehb=1024 ht=1024
vrs=601 vre=603 vt=625
hsync=+ vsync=+
edid ***@60Hz
clock=40
shb=800 ehb=1056 ht=1056
vrs=601 vre=605 vt=628
hsync=+ vsync=+
edid ***@72Hz
clock=50
shb=800 ehb=1040 ht=1040
vrs=637 vre=643 vt=666
hsync=+ vsync=+
edid ***@75Hz
clock=49.5
shb=800 ehb=1056 ht=1056
vrs=601 vre=604 vt=625
hsync=+ vsync=+
edid ***@60Hz
clock=65
shb=1024 ehb=1344 ht=1344
vrs=771 vre=777 vt=806
hsync=- vsync=-
edid ***@70Hz
clock=75
shb=1024 ehb=1328 ht=1328
vrs=771 vre=777 vt=806
hsync=- vsync=-
edid ***@75Hz
clock=78.75
shb=1024 ehb=1312 ht=1312
vrs=769 vre=772 vt=800
hsync=+ vsync=+
edid ***@75Hz
clock=135
shb=1280 ehb=1688 ht=1688
vrs=1025 vre=1028 vt=1066
hsync=+ vsync=+
edid ***@60Hz
clock=97.75
shb=1648 ehb=1680 ht=1760
vrs=903 vre=908 vt=926
hsync=+ vsync=-

To be continued:

1) How to fill vgadb.
2) What to pass to aux/vga to not be in 640x480x8 because termrc fails to
this default.