[9fans] rio startup fails in VMWare Fusion 2.0.0

[Gary V. Vaughan]

...so I thought I'd upgrade to the latest and greatest Fusion release,
but things are even worse.

If I boot from the iso, and select option '2' for the livecd option
and taking the defaults of ps2 mouse, 640x480x8 resolution and xga
monitor, I get the following error messages:

aux/vga: vgactlw: <linear 0x3e80000 0x0>: unknown vmware id 0740
rio: can't open display: initdisplay /dev/draw/new: no frame buffer
init: rc exit status: rio 9: display open

And then the boot sequence starts /bin/rc, and I get a 'term%' prompt.

Is this also related to bit rotted vmware drivers?

Cheers,
Gary

[Federico G. Benavento]

try "vesa" for monitor and play with different resolutions
"aux/vga -m vesa -p" should give you some info.

...so I thought I'd upgrade to the latest and greatest Fusion release, but
things are even worse.
If I boot from the iso, and select option '2' for the livecd option and
taking the defaults of ps2 mouse, 640x480x8 resolution and xga monitor, I
aux/vga: vgactlw: <linear 0x3e80000 0x0>: unknown vmware id 0740
rio: can't open display: initdisplay /dev/draw/new: no frame buffer
init: rc exit status: rio 9: display open
And then the boot sequence starts /bin/rc, and I get a 'term%' prompt.
Is this also related to bit rotted vmware drivers?
Cheers,
Gary
--
Read my blog: http://blog.azazil.net \' )
And my other blog: http://www.machaxor.net =( \
...and my book: http://sources.redhat.com/autobook _(~_)'

[Gary V. Vaughan]

Hi Frederico,

Thanks for the response!

Post by Federico G. Benavento

Post by Gary V. Vaughan
...so I thought I'd upgrade to the latest and greatest Fusion
release, but
things are even worse.
If I boot from the iso, and select option '2' for the livecd option and
taking the defaults of ps2 mouse, 640x480x8 resolution and xga monitor, I
aux/vga: vgactlw: <linear 0x3e80000 0x0>: unknown vmware id 0740
rio: can't open display: initdisplay /dev/draw/new: no frame buffer
init: rc exit status: rio 9: display open
And then the boot sequence starts /bin/rc, and I get a 'term%' prompt.
Is this also related to bit rotted vmware drivers?

try "vesa" for monitor and play with different resolutions
"aux/vga -m vesa -p" should give you some info.

Using "vesa" for monitor along with all of the resolutions I tried
actually
hangs (i.e. I don't even get a text-mode term% prompt), as does "aux/
vga -m vesa -p"
if I type it at the text mode prompt.

Cheers,
Gary

[erik quanstrom]

Post by Gary V. Vaughan
Using "vesa" for monitor along with all of the resolutions I tried
actually
hangs (i.e. I don't even get a text-mode term% prompt), as does "aux/
vga -m vesa -p"
if I type it at the text mode prompt.

ah! vmware seems to be doing a much
better job these days of emulating real
live hardware!

- erik

[Richard Miller]

   aux/vga: vgactlw: <linear 0x3e80000 0x0>: unknown vmware id 0740

It was picking up the wrong pci device - 15AD/0740 is a "virtual machine
communication interface", not the virtual vga controller.

Fixed by new version of /sys/src/9/pc/vgavmware.c now on sources.

[Rodolfo kix García]

Thanks Richard.

Post by Richard Miller

   aux/vga: vgactlw: <linear 0x3e80000 0x0>: unknown vmware id 0740

It was picking up the wrong pci device - 15AD/0740 is a "virtual machine
communication interface", not the virtual vga controller.
Fixed by new version of /sys/src/9/pc/vgavmware.c now on sources.

[Ben Calvert]

Am encountering the same problem, even though i've just pulled down
the latest sources. Is there something special i should be doing?

thanks,

ben

Post by Rodolfo kix García
Thanks Richard.

Post by Richard Miller

  aux/vga: vgactlw: <linear 0x3e80000 0x0>: unknown vmware id
0740

It was picking up the wrong pci device - 15AD/0740 is a "virtual machine
communication interface", not the virtual vga controller.
Fixed by new version of /sys/src/9/pc/vgavmware.c now on sources.

--
Rodolfo García AKA kix
http://www.kix.es/

[erik quanstrom]

Post by Ben Calvert
Am encountering the same problem, even though i've just pulled down
the latest sources. Is there something special i should be doing?
thanks,
ben

the kernels on sources have not been rebuilt since this
patch was put up so it's pretty likely that the kernel on
the cd is also older than the patch, too. the solution is
to build your own kernel, but this may be difficult if you
don't have a running machine.

- erik

[Ben Calvert]

well, i have a prompt.

i'll google about and see if i come up with instructions for compiling
the kernel...

Post by erik quanstrom

Post by Ben Calvert
Am encountering the same problem, even though i've just pulled down
the latest sources. Is there something special i should be doing?
thanks,
ben

the kernels on sources have not been rebuilt since this
patch was put up so it's pretty likely that the kernel on
the cd is also older than the patch, too. the solution is
to build your own kernel, but this may be difficult if you
don't have a running machine.
- erik

[Ben Calvert]

Actually, maybe i'm not being fully clear --

rio starts up during the install, but i get the 'vmware id 0740' error
when logging on afterwards.

Post by erik quanstrom

Post by Ben Calvert
Am encountering the same problem, even though i've just pulled down
the latest sources. Is there something special i should be doing?
thanks,
ben

the kernels on sources have not been rebuilt since this
patch was put up so it's pretty likely that the kernel on
the cd is also older than the patch, too. the solution is
to build your own kernel, but this may be difficult if you
don't have a running machine.
- erik

[Tharaneedharan Vilwanathan]

hi all,
not sure if this discussion is continued elsewhere, but i thought i will
share what i found.

i just installed vmware fusion 2.0.1 (128865), downloaded new plan9 CD image
(that probably geoff made yesterday and the one that probably has richard's
vmware vga fix) and tried to install plan9.

vgasize: 640x480x8, monitor: xga - this combo works
vgasize: 1024x768x8, monitor: xga - this combo works

i tried 1280x1024x8 and 1280x1024(?!). it seems to hang. no luck with vesa
also.

is anyone able to get any better resolution with vmware fusion in mac (or
parallels for mac 4.0, if it works for plan9)?

i have 1920x1200 widescreen LCD monitor with DVI and i would like to make
good use of more screen space. so i am trying to go up as much as possible.

with parallels for mac 3.0, i was able to use 1920x1200 but i used this
setup sparingly so far. i also noticed mouse jumps, poor performance or slow
screen updates (e.g. if i open acme window, it would sometimes take 10+
seconds to show the prompt) and some other incomplete screen draw, etc

any help appreciated.

thanks
dharani

Post by Ben Calvert
Actually, maybe i'm not being fully clear --
rio starts up during the install, but i get the 'vmware id 0740' error when
logging on afterwards.

Post by erik quanstrom

Post by Ben Calvert
Am encountering the same problem, even though i've just pulled down
the latest sources. Is there something special i should be doing?
thanks,
ben

the kernels on sources have not been rebuilt since this
patch was put up so it's pretty likely that the kernel on
the cd is also older than the patch, too. the solution is
to build your own kernel, but this may be difficult if you
don't have a running machine.
- erik

[Richard Miller]

Post by Tharaneedharan Vilwanathan
vgasize: 640x480x8, monitor: xga - this combo works
vgasize: 1024x768x8, monitor: xga - this combo works
i tried 1280x1024x8 and 1280x1024(?!). it seems to hang. no luck with vesa
also.
is anyone able to get any better resolution with vmware fusion in mac (or
parallels for mac 4.0, if it works for plan9)?

Native resolution on new macbook works with fusion. I added to /lib/vgadb:

macbook=1280x800
include=1152x768

If resolution 1280x1024x8 doesn't work for you, it's worth trying other depths
x16 x24 or x32.

[Jeff Sickel]

Post by Richard Miller

Post by Tharaneedharan Vilwanathan
vgasize: 640x480x8, monitor: xga - this combo works
vgasize: 1024x768x8, monitor: xga - this combo works
i tried 1280x1024x8 and 1280x1024(?!). it seems to hang. no luck with vesa
also.
is anyone able to get any better resolution with vmware fusion in mac (or
parallels for mac 4.0, if it works for plan9)?

Native resolution on new macbook works with fusion. I added to /lib/
macbook=1280x800
include=1152x768
If resolution 1280x1024x8 doesn't work for you, it's worth trying other depths
x16 x24 or x32.

I still recomend keeping the VMware Plan 9 instance as a console (text
only) and using drawterm to connect in--much more responsive and gives
clean access back to your host filesystem.

The docs on creating a stand alone cpu server help getting the
configuration to work.

-jas

[Tharaneedharan Vilwanathan]

hi jeff,

i agree. somewhere down the line, i will probably stick to this method.

but my problem is i use inferno and acme in inferno a lot. to the extent i
tested so far, drawterm, 9vx are all so slow in updating inferno screen (i
think it becomes a matter of screen area updates all the time instead of any
optimized updates like in case of, say, a rio text window). since i use
inferno a lot in plan9 and since the lag is very noticeable, i am just
trying to find out a way.

btw, is there any opportunity for optimization in draw operations that will
help? or it is already optimized? is it possible to lower the no of bits per
pixel in inferno and will it lead to any gain in performance?

thanks
dharani


I still recomend keeping the VMware Plan 9 instance as a console (text only)

and using drawterm to connect in--much more responsive and gives clean
access back to your host filesystem.
The docs on creating a stand alone cpu server help getting the
configuration to work.
-jas

[Charles Forsyth]

Post by Tharaneedharan Vilwanathan
tested so far, drawterm, 9vx are all so slow in updating inferno screen (i

i tried running inferno in an 1152x900 x8r8g8b8 within 9vx. (the window is
controlled by rio in 9vx but even then emu's draw operations go direct to the 9vx kernel
via draw.) this is on a 1.2Ghz core duo on ubuntu 8.04. it "didn't seem too bad"
(ie, not unusable) but it probably isn't as responsive as under plan 9 proper
and if you're used to that you probably would notice the difference.
i can't easily run them side by side for direct comparison.

inferno applications will be drawing via Inferno's /dev/draw, with a screen
implementation that ships updated rectangles to plan 9's using its 'y' and 'v' operations.
the buffer size is determined by plan 9's iounit.
inferno (on Plan 9 and thus 9vx) can be set to use plan 9's /dev/draw
directly, so inferno applications will be bypassing emu's /dev/draw.
it's a proof-of-concept scheme (ie, too many limitations at the moment
for real use -- not because of draw but window management). i tried my script
to run charon that way, under 9vx, and it was much, much worse than
under wm through inferno's own draw, so that's not an immediate fix.
it was really very bad.
(by the way, the only significant reason for inferno's current indirection on plan 9
is to ensure the same draw code is used and tested in all implementations.)

[Tharaneedharan Vilwanathan]

hi charles,
thanks for the details.

via draw.) this is on a 1.2Ghz core duo on ubuntu 8.04. it "didn't seem

Post by Charles Forsyth
too bad"
(ie, not unusable) but it probably isn't as responsive as under plan 9 proper

yes, in cases like this, it is usable but the noticeable lag and the
relatively slow updates make me feel uncomfortable, particularly since i try
to use this kind of setup all the time, as opposed to sporadic use. also, i
think the issue becomes more severe for higher bits-per-pixel and higher
screen resolution, say 1920x1200.

btw, i was always happy with the speed at which plan9 updates screen (as
much as i like plan9 graphics interface itself). the screen updates are not
too fast, not too slow. i used to feel too fast screen updates are not good
for good experience (for development at least). i am also happy with the
speed at which inferno draw runs on top of plan9 when plan9 runs natively.
the cases where i see noticeable differences are like
vmware-fusion/parallels, drawterm, remote plan9 terminal over network in
which inferno is started, etc.

Post by Charles Forsyth
and if you're used to that you probably would notice the difference.
i can't easily run them side by side for direct comparison.
inferno applications will be drawing via Inferno's /dev/draw, with a screen
implementation that ships updated rectangles to plan 9's using its 'y' and 'v' operations.
the buffer size is determined by plan 9's iounit.
inferno (on Plan 9 and thus 9vx) can be set to use plan 9's /dev/draw
directly, so inferno applications will be bypassing emu's /dev/draw.
it's a proof-of-concept scheme (ie, too many limitations at the moment
for real use -- not because of draw but window management). i tried my script
to run charon that way, under 9vx, and it was much, much worse than
under wm through inferno's own draw, so that's not an immediate fix.
it was really very bad.
(by the way, the only significant reason for inferno's current indirection on plan 9
is to ensure the same draw code is used and tested in all implementations.)

is this something that was introduced in vita nuova's release? from what i
remember from inferno BU times, i think inferno used plan9's draw directly
since there was (almost?) no difference at that time.

thanks
dharani

[Tharaneedharan Vilwanathan]

hi richard,
i tried various combinations:

1280x1024
1280x800
1152x768
1920x1200

(i tried combinations like with x8, x24, x32 (not x16 i think)). nothing
seems to help. 1920x1200 looked like it turned the graphics mode on but then
it crashed.

btw, what was your plan9.ini config? did it look like:

vgasize=1280x800
monitor=macbook (or xga?, sorry i am not sure about this)

and, since we are in VM, does the native resolution really matter? my
thinking was, basically VM provides memory space and the graphics driver in
guest OS thinks this is its frame buffer. when a draw happens, the guest
OS's window gets updated. am i right or wrong?

regards
dharani

Post by Richard Miller

Post by Tharaneedharan Vilwanathan
vgasize: 640x480x8, monitor: xga - this combo works
vgasize: 1024x768x8, monitor: xga - this combo works
i tried 1280x1024x8 and 1280x1024(?!). it seems to hang. no luck with

vesa

Post by Tharaneedharan Vilwanathan
also.
is anyone able to get any better resolution with vmware fusion in mac (or
parallels for mac 4.0, if it works for plan9)?

macbook=1280x800
include=1152x768
If resolution 1280x1024x8 doesn't work for you, it's worth trying other depths
x16 x24 or x32.

[Richard Miller]

Post by Tharaneedharan Vilwanathan
vgasize=1280x800
monitor=macbook (or xga?, sorry i am not sure about this)

Before changing vgadb, I had success with:

vgasize=1280x768x24
monitor=cinema

Post by Tharaneedharan Vilwanathan
and, since we are in VM, does the native resolution really matter? my
thinking was, basically VM provides memory space and the graphics driver in
guest OS thinks this is its frame buffer. when a draw happens, the guest
OS's window gets updated. am i right or wrong?

Sorry, I don't know the details. When you're not running fullscreen, there
is obviously no real connection between the actual screen resolution and what
the vm is simulating.

[Tharaneedharan Vilwanathan]

hi richard,
thanks for the info. both 1280x768x8 and 1280x768x24 work for me. i am
working on some (unrelated) issues, after which i will try more
combinations.

thanks
dharani

Post by Richard Miller

Post by Tharaneedharan Vilwanathan
vgasize=1280x800
monitor=macbook (or xga?, sorry i am not sure about this)

vgasize=1280x768x24
monitor=cinema

Post by Tharaneedharan Vilwanathan
and, since we are in VM, does the native resolution really matter? my
thinking was, basically VM provides memory space and the graphics driver

in

Post by Tharaneedharan Vilwanathan
guest OS thinks this is its frame buffer. when a draw happens, the guest
OS's window gets updated. am i right or wrong?

Sorry, I don't know the details. When you're not running fullscreen, there
is obviously no real connection between the actual screen resolution and what
the vm is simulating.

[Skip Tavakkolian]

if you setup dedicated machines for cpu+auth and fs, then booting a pc kernel
on a vmware and booting from fs works very well as a term.

Post by Tharaneedharan Vilwanathan
hi jeff,
i agree. somewhere down the line, i will probably stick to this method.
but my problem is i use inferno and acme in inferno a lot. to the extent i
tested so far, drawterm, 9vx are all so slow in updating inferno screen (i
think it becomes a matter of screen area updates all the time instead of any
optimized updates like in case of, say, a rio text window). since i use
inferno a lot in plan9 and since the lag is very noticeable, i am just
trying to find out a way.
btw, is there any opportunity for optimization in draw operations that will
help? or it is already optimized? is it possible to lower the no of bits per
pixel in inferno and will it lead to any gain in performance?
thanks
dharani
I still recomend keeping the VMware Plan 9 instance as a console (text only)

and using drawterm to connect in--much more responsive and gives clean
access back to your host filesystem.
The docs on creating a stand alone cpu server help getting the
configuration to work.
-jas