[9fans] Parallels Vesa driver question
Daniel Lyons
I installed Plan 9 under Parallels 3 back in November of last year and
it worked without a hitch. I tried to install another copy tonight and
the bitmapped display isn't working in the new one, I just get a pure
black screen after any aux/vga command that it thinks will succeed. I
found I can reproduce that behavior by building and running a new
kernel in the old install. Any ideas what has happened since November
in the kernel with respect to Vesa and Parallels? I'd be more than
happy to debug this issue if I could get a little guidance. I didn't
see anything in the archives about this problem. Alternatively, does
anyone know if Parallels 4 works with a current kernel? If so I'll
probably just upgrade to that; I've been holding off for a good reason
to.
Thanks,
—
Daniel Lyons
erik quanstrom
two things: mtrr and adding a vesaflush command. it doesn't quite make
sense to me that this would break parallels, unless there is something
funky about
- mtrr ranges with parallels.
- parallels vesa
- plan 9 vesa support
the easiest thing to do would be to comment out vesaflush and
see what happens. without pawing through the standard, it may
be that vesaflush is optionally supported and parallels doesn't support it.
- erik
; diff -c vgavesa.c /n/sourcesdump/2008/1101/plan9/sys/src/9/pc/vgavesa.c
vgavesa.c:13,21 - /n/sourcesdump/2008/1101/plan9/sys/src/9/pc/vgavesa.c:13,18
#include <cursor.h>
#include "screen.h"
-
- static void *hardscreen;
-
#define WORD(p) ((p)[0] | ((p)[1]<<8))
#define LONG(p) ((p)[0] | ((p)[1]<<8) | ((p)[2]<<16) | ((p)[3]<<24))
#define PWORD(p, v) (p)[0] = (v); (p)[1] = (v)>>8
vgavesa.c:83,89 - /n/sourcesdump/2008/1101/plan9/sys/src/9/pc/vgavesa.c:80,86
}
static void
- vesalinear(VGAscr *, int, int)
+ vesalinear(VGAscr* scr, int, int)
{
int i, mode, size;
uchar *p;
vgavesa.c:130,169 - /n/sourcesdump/2008/1101/plan9/sys/src/9/pc/vgavesa.c:127,135
size = ROUND(size, 1024*1024);
havesize:
- if(size > 16*1024*1024) /* probably arbitrary; could increase */
- size = 16*1024*1024;
- hardscreen = vmap(paddr, size);
- mtrr(paddr, size, "wc");
- // vgalinearaddr(scr, paddr, size);
+ vgalinearaddr(scr, paddr, size);
}
- static void
- vesaflush(VGAscr *scr, Rectangle r)
- {
- int t, w, wid, off;
- ulong *hp, *sp, *esp;
-
- if(rectclip(&r, scr->gscreen->r) == 0)
- return;
-
- hp = hardscreen;
- sp = (ulong*)(scr->gscreendata->bdata + scr->gscreen->zero);
- t = (r.max.x * scr->gscreen->depth + 2*BI2WD-1) / BI2WD;
- w = (r.min.x * scr->gscreen->depth) / BI2WD;
- w = (t - w) * BY2WD;
- wid = scr->gscreen->width;
- off = r.min.y * wid + (r.min.x * scr->gscreen->depth) / BI2WD;
-
- hp += off;
- sp += off;
- esp = sp + Dy(r) * wid;
- while(sp < esp){
- memmove(hp, sp, w);
- hp += wid;
- sp += wid;
- }
- }
-
VGAdev vgavesadev = {
"vesa",
0,
vgavesa.c:174,178 - /n/sourcesdump/2008/1101/plan9/sys/src/9/pc/vgavesa.c:140,145
0,
0,
0,
- vesaflush,
+ 0,
};
Daniel Lyons
Thanks for your speedy assistance! I think the two things are closely
interrrelated via the global variable hardscreen. Reverting this file
solved the problem. I wouldn't be surprised if there were something
weird about Parallels' MTRR support, and since this isn't the current
version it's not likely to get any better. If anyone's using Parallels
4 and not running into this issue, I'd love to know.
Also, are the old sources available online somewhere so I can do this
kind of diff in the future on my own?
Thanks again,
—
Daniel Lyons
Steve Simon
> kind of diff in the future on my own?
you can use history(1) and yesterday(1) against sources.
9fs sources
history -D sourcesdump /n/sources/plan9/sys/src/9/pc/vgavesa.c
-Steve
erik quanstrom
>
> Thanks for your speedy assistance! I think the two things are closely
> interrrelated via the global variable hardscreen. Reverting this file
> solved the problem. I wouldn't be surprised if there were something
> weird about Parallels' MTRR support, and since this isn't the current
> version it's not likely to get any better. If anyone's using Parallels
> 4 and not running into this issue, I'd love to know.
you're welcome.
but if you wouldn't mind, would you try the new source but modify
it by replacing the vgavesaflush in the following diff with "0"?
> > vgavesa.c:174,178 - /n/sourcesdump/2008/1101/plan9/sys/src/9/pc/
> > vgavesa.c:140,145
> > 0,
> > 0,
> > 0,
> > - vesaflush,
> > + 0,
> > };
the reason for this test would be to see if the problem is with vesaflush
or the mtrrs.
- erik
Daniel Lyons
On Aug 2, 2009, at 3:41 PM, erik quanstrom wrote:
>> Erik,
>>
>> Thanks for your speedy assistance! I think the two things are closely
>> interrrelated via the global variable hardscreen. Reverting this file
>> solved the problem. I wouldn't be surprised if there were something
>> weird about Parallels' MTRR support, and since this isn't the current
>> version it's not likely to get any better. If anyone's using
>> Parallels
>> 4 and not running into this issue, I'd love to know.
>
> you're welcome.
>
> but if you wouldn't mind, would you try the new source but modify
> it by replacing the vgavesaflush in the following diff with "0"?
Yes, this alone is not sufficient to fix the problem, which I believe
confirms your suspicion that there is a defect in either Parallel's
MTRR or Plan 9's Vesa MTRR. My money would be on Parallels, since they
have a reputation for building the VM to support Windows first.
Again, thanks! Hopefully I'll be able to afford a copy of the new
version of Parallels in a little while and perhaps that will help
further isolate the problem.
—
Daniel Lyons
Balwinder S Dheeman
A new faster vesa driver was added a few days ago, see
http://www.google.com/search?q=group%3A+comp.os.plan9+faster+vesa+driver
I also faced a similar problem on Plan9 running under QEMU, switching
back to xga solved the problem temporally, but this, skipping over and,
or ignoring bugs or compatibility issues in a new driver is definitely
not a solution :(
--
Balwinder S "bdheeman" Dheeman Registered Linux User: #229709
Anu'z Linux@HOME (Unix Shoppe) Machines: #168573, 170593, 259192
Chandigarh, UT, 160062, India Plan9, T2, Arch/Debian/FreeBSD/XP
Home: http://werc.homelinux.net/ Visit: http://counter.li.org/
Richard Miller
> version of Parallels in a little while and perhaps that will help
> further isolate the problem.
It's not just Parallels. The new vgavesa also fails to work on
my VIA Epia MS10000 motherboard - even with the "vesaflush" table
entry removed.
I think the mtrr is not safe for all hardware variants.
erik quanstrom
strange.
could one of you having trouble with vesa + mtrr try
vesa + the pat patch on sources in the saved patch
directory?
- erik
ron minnich
Would it be possible to get:
- output from pci so we can see what memory ranges are in use on your machine
- how much memory
- what the mtrrs look like once set up
ron
ge...@plan9.bell-labs.com
The new vesa driver will only use mtrrs if the cpuid
instruction says that they exist.
David Leimbach
Daniel Lyons
On Aug 3, 2009, at 10:30 AM, ron minnich wrote:
> Given these systems with mtrr issues.
>
> Would it be possible to get:
> - output from pci so we can see what memory ranges are in use on
> your machine
0.2.0: vid 03.00.00 1ab8/1131 11 0:00004001 256 1:c0000000 16777216
2:00004401 16
0.3.0: brg 06.80.00 1ab8/1112 9
0.30.0: brg 06.00.00 8086/1130 255
0.31.0: brg 06.01.00 8086/2440 255
0.31.1: disk 01.01.80 8086/244b 255 4:00005001 16
0.31.5: aud 04.01.00 8086/2445 9 0:00005401 256 1:00005801 64
0.5.0: net 02.00.00 10ec/8029 10 0:00004c01 32
> - how much memory
256 MB, but that's arbitrary; just the preference I have set in
Parallels.
> - what the mtrrs look like once set up
I don't know how to obtain this information, but would be glad to
supply it. Also, forgive my ignorance, but isn't there a chicken-and-
egg problem, since if the MTRRs are set up in vgavesa.c, my display is
unusable? Or is there a special way to bail out to the text mode when
the display is screwed up?
Thanks again,
—
Daniel Lyons
Daniel Lyons
Wow.... Where's parallels 4. I doubt I qualify for a free one. And VMWare Fusion really sucks with Plan 9 at the moment :-(
Bakul Shah
> Wow.... Where's parallels 4. I doubt I qualify for a free one. And VMWare
> Fusion really sucks with Plan 9 at the moment :-(
qemu works well enough for me on FreeBSD & Linux but not on a
Mac. VirtualBox doesn't run plan9 but it runs FreeBSD, Linux
and Windows fairly well so may be there is hope. There is an
open source version of VirtualBox that might be worth
tinkering with.
Daniel Lyons
On Aug 3, 2009, at 5:20 AM, erik quanstrom wrote:
> strange.
>
> could one of you having trouble with vesa + mtrr try
> vesa + the pat patch on sources in the saved patch
> directory?
I fear I may not have applied the patch correctly:
/sys/src/9/pc% mk CONF=pcf
8c -FTVw devarch.c
devarch.c:733 not enough function arguments: cpuid
devarch.c:733 argument prototype mismatch "IND ULONG" for "IND INT":
cpuid
devarch.c:739 argument prototype mismatch "INT" for "IND CHAR": cpuid
devarch.c:739 not enough function arguments: cpuid
devarch.c:739 argument prototype mismatch "IND ULONG" for "IND INT":
cpuid
devarch.c:869 function args not checked: mtrrprint
devarch.c:951 function args not checked: mtrr
mk: 8c -FTVw devarch.c : exit status=rc 1227: 8c 1229: error
I copied /n/sources/patch/saved/pat/*.[ch] to /sys/src/9/pc ... What
is the correct procedure here?
Thanks again,
—
Daniel Lyons
erik quanstrom
>
> /sys/src/9/pc% mk CONF=pcf
> 8c -FTVw devarch.c
> devarch.c:733 not enough function arguments: cpuid
> devarch.c:733 argument prototype mismatch "IND ULONG" for "IND INT":
> cpuid
> devarch.c:739 argument prototype mismatch "INT" for "IND CHAR": cpuid
> devarch.c:739 not enough function arguments: cpuid
> devarch.c:739 argument prototype mismatch "IND ULONG" for "IND INT":
> cpuid
> devarch.c:869 function args not checked: mtrrprint
> devarch.c:951 function args not checked: mtrr
> mk: 8c -FTVw devarch.c : exit status=rc 1227: 8c 1229: error
>
> I copied /n/sources/patch/saved/pat/*.[ch] to /sys/src/9/pc ... What
> is the correct procedure here?
your procedure was correct — assuming that the patch was made
against the current sources snapshot. a more robust but
much more involved technique is to diff the x.c s against the x.c.orig s and
apply those diffs to your current setup.
i dropped a devarch.c in /n/sources/contrib/quanstro/devarch.c. hopefully
that will make things easier.
- erik
David Leimbach
ron minnich
> I don't know how to obtain this information, but would be glad to supply it.
> Also, forgive my ignorance, but isn't there a chicken-and-egg problem, since
> if the MTRRs are set up in vgavesa.c, my display is unusable? Or is there a
> special way to bail out to the text mode when the display is screwed up?
Change the code to tell you what it would do to the mtrrs and then not
start up graphics but exit instead.
ron
Bakul Shah
>
> On Tue, Aug 4, 2009 at 12:25 AM, Bakul Shah
> > wrote:
>
> > On Mon, 03 Aug 2009 20:12:08 PDT David Leimbach <lei...@gmail.com>
> > wrote:
> > > Wow.... Where's parallels 4. I doubt I qualify for a free one. And
> > VMWare
> > > Fusion really sucks with Plan 9 at the moment :-(
> >
> > qemu works well enough for me on FreeBSD & Linux but not on a
> > Mac. VirtualBox doesn't run plan9 but it runs FreeBSD, Linux
> > and Windows fairly well so may be there is hope. There is an
> > open source version of VirtualBox that might be worth
> > tinkering with.
> >
> > I was considering giving qemu a try on the mac. I believe there's a mac
> centric front-end for it even.
It's called Q. Don't bother.
> In fact, how much of virtualbox is using qemu?
I think vbox devices and recompiler are based on qemu but I
don't really know. IIRC early qemu did seem to have similar
issues with plan9.
Since other OSes run pretty well, my guess is something plan9
depends on heavily has to be emulated (due to memory layout
assumptions or something).
David Leimbach
Bakul Shah
>
> On Tue, Aug 4, 2009 at 8:20 AM, Bakul Shah
> > wrote:
...
> > I think vbox devices and recompiler are based on qemu but I
> > don't really know. IIRC early qemu did seem to have similar
> > issues with plan9.
> >
> > Since other OSes run pretty well, my guess is something plan9
> > depends on heavily has to be emulated (due to memory layout
> > assumptions or something).
> >
>
> I've also tried Minix and QNX and both have problems on Virtual Box. Which
> other OSes did you try? Linux and windows work but they're like necessary
> to even claim you can do anything virtualization wise.
>
> Dave
Just FreeBSD, linux and Windows.
Anyway, a couple of areas to look into, if you want plan9 on
vbox: try changing the memory layout of plan9 or figure out
what qemu did to make plan9 run well and apply that change to
vbox.
erik quanstrom
> vbox: try changing the memory layout of plan9 or figure out
> what qemu did to make plan9 run well and apply that change to
> vbox.
what makes you think its a memory layout issue?
- erik
Bakul Shah
I can no longer remember but I think the following played some
part in thinking that. Qemu internals document (on qemu.org):
For system emulation, QEMU uses the mmap() system call to
emulate the target CPU MMU. It works as long the emulated
OS does not use an area reserved by the host OS (such as
the area above 0xc0000000 on x86 Linux).
Elsewhere it says
Achieving self-virtualization is not easy because there
may be address space conflicts. QEMU solves this problem
by being an executable ELF shared object as the
ld-linux.so ELF interpreter. That way, it can be
relocated at load time.
It was a hypothesis and it could be all wet.