X11 problem with dom0 pvops kernel on Xen 4.0.1

X11 problem with dom0 pvops kernel on Xen 4.0.1

[John McDermott (US Navy Employee)]

Xen Developers,

I have encountered what appears to be an interesting video or DRM problem while
attempting to install Fedora 13 as an HVM, using a 2.6.32.18 PVOPS dom0, running
on Xen 4.0.1 on Fedora 13. Using virt-install --nographics, it reaches the point
following the XML display of the boot guest configuration and then hangs with
garbage displayed on my remote xterm console. (Virt-install --vnc dies also.) My
serial console shows a bunch of

(XEN) HVM2: int13_harddisk: function 41, unmapped device for ELDL=81

and then some

(XEN) vlapic.c:702:d2 Local APIC Write to read-only register 0x30

error messages.

The hardware is a Dell Precision 690 with an Intel E6320 processor (I don't
think this is the issue) and an nVidia Quadro NVS 285, which X11 reports as
nVidia NV 44. Plain old Fedora 13 uses the nouveau driver with no problems. Udev
tells me it is version 153. The problem remains even with the kernel booted nopat.

Some pretty good folks on Xen Users have looked at this and no fix was suggested.

If anyone is interested in looking at all of the dumps, serial output,
dmidecode, X11 output, etc. for this machine, I'd be happy to provide it out of
band.

Sincerely,

John McDermott
-- 
What is the formal meaning of the one-line program

#include "/dev/tty"
?

Re: X11 problem with dom0 pvops kernel on Xen 4.0.1

[Konrad Rzeszutek Wilk]

On Tue, Sep 07, 2010 at 12:53:50PM -0400, John McDermott (US Navy Employee) wrote:
> Xen Developers,
> 
> I have encountered what appears to be an interesting video or DRM problem while
> attempting to install Fedora 13 as an HVM, using a 2.6.32.18 PVOPS dom0, running
> on Xen 4.0.1 on Fedora 13. Using virt-install --nographics, it reaches the point
> following the XML display of the boot guest configuration and then hangs with
> garbage displayed on my remote xterm console. (Virt-install --vnc dies also.) My
> serial console shows a bunch of
> 
> (XEN) HVM2: int13_harddisk: function 41, unmapped device for ELDL=81
> 
> and then some
> 
> (XEN) vlapic.c:702:d2 Local APIC Write to read-only register 0x30
> 
> error messages.
> 
> The hardware is a Dell Precision 690 with an Intel E6320 processor (I don't
> think this is the issue) and an nVidia Quadro NVS 285, which X11 reports as
> nVidia NV 44. Plain old Fedora 13 uses the nouveau driver with no problems. Udev
> tells me it is version 153. The problem remains even with the kernel booted nopat.

Uh, can you explain this in more detail? Are you passing through your NVidia card?

Re: X11 problem with dom0 pvops kernel on Xen 4.0.1

[John McDermott (U.S. Navy Employee)]

On Sep 20, 2010, at 10:48 AM, Konrad Rzeszutek Wilk wrote:

> On Tue, Sep 07, 2010 at 12:53:50PM -0400, John McDermott (US Navy Employee) wrote:
>> Xen Developers,
>> 
>> I have encountered what appears to be an interesting video or DRM problem while
>> attempting to install Fedora 13 as an HVM, using a 2.6.32.18 PVOPS dom0, running
>> on Xen 4.0.1 on Fedora 13. Using virt-install --nographics, it reaches the point
>> following the XML display of the boot guest configuration and then hangs with
>> garbage displayed on my remote xterm console. (Virt-install --vnc dies also.) My
>> serial console shows a bunch of
>> 
>> (XEN) HVM2: int13_harddisk: function 41, unmapped device for ELDL=81
>> 
>> and then some
>> 
>> (XEN) vlapic.c:702:d2 Local APIC Write to read-only register 0x30
>> 
>> error messages.
>> 
>> The hardware is a Dell Precision 690 with an Intel E6320 processor (I don't
>> think this is the issue) and an nVidia Quadro NVS 285, which X11 reports as
>> nVidia NV 44. Plain old Fedora 13 uses the nouveau driver with no problems. Udev
>> tells me it is version 153. The problem remains even with the kernel booted nopat.
> 
> Uh, can you explain this in more detail? Are you passing through your NVidia card?

@Konrad, no pass through, thanks. I assume the default PVOPS DRM/KMS is what is happening. I am using both nomodset and nopat, so based on what I see on the Xenwiki about DRM and PVOPS, it should just work. However, all of my code-level experience is inside the hypervisor, so I am accepting the kernel as a black box. I am hoping it is just a problem-exists-between-keyboard-and-chair, but I can't find anything along those lines and I already got some pretty expert help from the Xen users list.

Should I try the drm.debug flag? I think maybe there is also an apic_debug flag?


The kernels boot fine, including video, as dom0. In fact, running as dom0, they forward X11 no problem. When I install an F13 image as a pvops domU, the domU cannot start X. I agree that sounds like an attempt to pass-through is somehow screwing things up, but I have not configured the guest for pass through.

Is there a known-good F13 image I could try to install, in case the one I am trying is somehow wrong for this?

----
What is the formal meaning of the one-line program
#include "/dev/tty"

J.P. McDermott				building 12
Code 5542					mcdermott@itd.nrl.navy.mil
Naval Research Laboratory	voice: +1 202.404.8301
Washington, DC 20375, US	fax:   +1 202.404.7942

Re: X11 problem with dom0 pvops kernel on Xen 4.0.1

[Konrad Rzeszutek Wilk]

> The kernels boot fine, including video, as dom0. In fact, running as dom0, they forward X11 no problem. When I install an F13 image as a pvops domU, the domU cannot start X. I agree that sounds like an attempt to pass-through is somehow screwing things up, but I have not configured the guest for pass through.

Ok, so your problems have nothing to do with DRM/KMS nor X if you see X working
as Dom0 on your machine. You don't need those nopat, nomodeset options - those are only
needed if you can't get X working under Dom0 and we need to troubleshoot what is happening.

> 
> Is there a known-good F13 image I could try to install, in case the one I am trying is somehow wrong for this?

Well, the normal F13 works for me.. but maybe I am installing it differently than you.

What does 'lspci -vvv' and 'dmesg' show you under you DomU? And also can you attach
the 'Xorg.0.log' from DomU?

Re: X11 problem with dom0 pvops kernel on Xen 4.0.1

[John McDermott (U.S. Navy Employee)]

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


On Sep 20, 2010, at 5:24 PM, Konrad Rzeszutek Wilk wrote:

>> The kernels boot fine, including video, as dom0. In fact, running as dom0, they forward X11 no problem. When I install an F13 image as a pvops domU, the domU cannot start X. I agree that sounds like an attempt to pass-through is somehow screwing things up, but I have not configured the guest for pass through.
> 
> Ok, so your problems have nothing to do with DRM/KMS nor X if you see X working
> as Dom0 on your machine. You don't need those nopat, nomodeset options - those are only
> needed if you can't get X working under Dom0 and we need to troubleshoot what is happening.

@Konrad, thanks, I will remove those options.

> 
>> 
>> Is there a known-good F13 image I could try to install, in case the one I am trying is somehow wrong for this?
> 
> Well, the normal F13 works for me.. but maybe I am installing it differently than you.
> 
> What does 'lspci -vvv' and 'dmesg' show you under you DomU? And also can you attach
> the 'Xorg.0.log' from DomU?

@Konrad, I posted a tarball earlier that has that stuff in it. Perhaps our uber-paranoid firewall stripped it. I resend here:


[-- Attachment #2: xenpro-dump.tgz --]
[-- Type: application/octet-stream, Size: 78066 bytes --]

[-- Attachment #3: Type: text/plain, Size: 255 bytes --]




----
What is the formal meaning of the one-line program
#include "/dev/tty"

J.P. McDermott				building 12
Code 5542					mcdermott@itd.nrl.navy.mil
Naval Research Laboratory	voice: +1 202.404.8301
Washington, DC 20375, US	fax:   +1 202.404.7942








[-- Attachment #4: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: X11 problem with dom0 pvops kernel on Xen 4.0.1

[Boris Derzhavets]

[-- Attachment #1.1: Type: text/plain, Size: 2311 bytes --]

> When I install an F13 image as a pvops domU, the domU cannot start X. 

Are you saying that virt-install F13 via local Apache Mirror or NFS share fails to run
in Gnome env ?

What you mean saying "F13 image"  ? How it was created ?

Boris.




--- On Tue, 9/21/10, John McDermott (U.S. Navy Employee) <john.mcdermott@nrl.navy.mil> wrote:

From: John McDermott (U.S. Navy Employee) <john.mcdermott@nrl.navy.mil>
Subject: Re: [Xen-devel] X11 problem with dom0 pvops kernel on Xen 4.0.1
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xensource.com
Date: Tuesday, September 21, 2010, 8:22 AM


On Sep 20, 2010, at 5:24 PM, Konrad Rzeszutek Wilk wrote:

>> The kernels boot fine, including video, as dom0. In fact, running as dom0, they forward X11 no problem. When I install an F13 image as a pvops domU, the domU cannot start X. I agree that sounds like an attempt to pass-through is somehow screwing things up, but I have not configured the guest for pass through.
> 
> Ok, so your problems have nothing to do with DRM/KMS nor X if you see X working
> as Dom0 on your machine. You don't need those nopat, nomodeset options - those are only
> needed if you can't get X working under Dom0 and we need to troubleshoot what is happening.

@Konrad, thanks, I will remove those options.

> 
>> 
>> Is there a known-good F13 image I could try to install, in case the one I am trying is somehow wrong for this?
> 
> Well, the normal F13 works for me.. but maybe I am installing it differently than you.
> 
> What does 'lspci -vvv' and 'dmesg' show you under you DomU? And also can you attach
> the 'Xorg.0.log' from DomU?

@Konrad, I posted a tarball earlier that has that stuff in it. Perhaps our uber-paranoid firewall stripped it. I resend here:




----
What is the formal meaning of the one-line program
#include "/dev/tty"

J.P. McDermott                building 12
Code 5542                    mcdermott@itd.nrl.navy.mil
Naval Research Laboratory    voice: +1 202.404.8301
Washington, DC 20375, US    fax:   +1 202.404.7942








-----Inline Attachment Follows-----

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel



      

[-- Attachment #1.2: Type: text/html, Size: 3305 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: X11 problem with dom0 pvops kernel on Xen 4.0.1

[John McDermott (U.S. Navy Employee)]

[-- Attachment #1.1: Type: text/plain, Size: 1217 bytes --]


On Sep 21, 2010, at 8:29 AM, Boris Derzhavets wrote:

> > When I install an F13 image as a pvops domU, the domU cannot start X. 
> 
> Are you saying that virt-install F13 via local Apache Mirror or NFS share fails to run
> in Gnome env ?

@Boris, I am running KDE. Does pvops only work on Gnome?

> What you mean saying "F13 image"  ? How it was created ?
> 
> Boris.

@Boris, good question. I think this is where my problem lies, because my knowledge of making guest images is 2 years out of date and based on Xen 3.0, i.e. building them by hand, using dd and loopback. For pvops guests, I am currently using the network install images from the Fedora website, as in download/.../Fedora/13/x86_64/os. I prefer to bring up a minimal system and add just the packages I need to get things working, so I know exactly what is installed. Is that a problem?

Also, the HVM install is from an .iso image on the local disk.

John




----
What is the formal meaning of the one-line program
#include "/dev/tty"

J.P. McDermott				building 12
Code 5542					mcdermott@itd.nrl.navy.mil
Naval Research Laboratory	voice: +1 202.404.8301
Washington, DC 20375, US	fax:   +1 202.404.7942








[-- Attachment #1.2: Type: text/html, Size: 4878 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: X11 problem with dom0 pvops kernel on Xen 4.0.1

[Boris Derzhavets]

[-- Attachment #1.1: Type: text/plain, Size: 2173 bytes --]

I just hate KDE (sorry). What you did should work on KDE

Could you try bring up local Apache :-

#  service httpd start 
# mkdir /var/www/html/f13
# mount -o loop,ro f13.iso  /var/www/html/f13

It creates local mirror at http://IP-Dom0/f13 . Just launch browser to this URL
and make sure.

Run :-

virt-install -n VF13 -r 1024 --vnc -f /dev/sdb7 -l http://IP-Dom0/f13 --debug

I did this install 1000 times and never had a problems with F13,12,11 PV DomUs
creating when Gnome (KDE) is fine at Xen Dom0 ( up to 4.0.1)

Boris.



--- On Tue, 9/21/10, John McDermott (U.S. Navy Employee) <john.mcdermott@nrl.navy.mil> wrote:

From: John McDermott (U.S. Navy Employee) <john.mcdermott@nrl.navy.mil>
Subject: Re: [Xen-devel] X11 problem with dom0 pvops kernel on Xen 4.0.1
To: "Boris Derzhavets" <bderzhavets@yahoo.com>
Cc: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>, xen-devel@lists.xensource.com
Date: Tuesday, September 21, 2010, 8:49 AM


On Sep 21, 2010, at 8:29 AM, Boris Derzhavets wrote:
> When I install an F13 image as a pvops domU, the domU cannot start X. 

Are you saying that virt-install F13 via local Apache Mirror or NFS share fails to run
in Gnome env ?

@Boris, I am running KDE. Does pvops only work on Gnome?

What you mean saying "F13 image"  ? How it was created ?

Boris.

@Boris, good question. I think this is where my problem lies, because my knowledge of making guest images is 2 years out of date and based on Xen 3.0, i.e. building them by hand, using dd and loopback. For pvops guests, I am currently using the network install images from the Fedora website, as in download/.../Fedora/13/x86_64/os. I prefer to bring up a minimal system and add just the packages I need to get things working, so I know exactly what is installed. Is that a problem?
Also, the HVM install is from an .iso image on the local disk.
John




----What is the formal meaning of the one-line program#include "/dev/tty"
J.P. McDermott				building 12Code 5542					mcdermott@itd.nrl.navy.milNaval Research Laboratory	voice: +1 202.404.8301Washington, DC 20375, US	fax:   +1 202.404.7942











      

[-- Attachment #1.2: Type: text/html, Size: 5361 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: X11 problem with dom0 pvops kernel on Xen 4.0.1

[John McDermott (U.S. Navy Employee)]

[-- Attachment #1.1: Type: text/plain, Size: 1246 bytes --]


On Sep 21, 2010, at 9:32 AM, Boris Derzhavets wrote:

> I just hate KDE (sorry). What you did should work on KDE

@Boris, its ok, I  hate metacity ;-) Thanks, I will continue with KDE focus-follows-mouse ...

> 
> Could you try bring up local Apache :-

@Boris, sorry, we are not allowed to run web servers on individual machines inside our firewall. It really makes software development difficult. I will go talk to our admin to see about getting permission to run one locally.

> 
> # service httpd start 
> # mkdir /var/www/html/f13
> # mount -o loop,ro f13.iso  /var/www/html/f13
> 
> It creates local mirror at http://IP-Dom0/f13 . Just launch browser to this URL
> and make sure.
> 
> Run :-
> 
> virt-install -n VF13 -r 1024 --vnc -f /dev/sdb7 -l http://IP-Dom0/f13 --debug
> 
> I did this install 1000 times and never had a problems with F13,12,11 PV DomUs
> creating when Gnome (KDE) is fine at Xen Dom0 ( up to 4.0.1)
> 
> Boris.
> 
> 

----
What is the formal meaning of the one-line program
#include "/dev/tty"

J.P. McDermott				building 12
Code 5542					mcdermott@itd.nrl.navy.mil
Naval Research Laboratory	voice: +1 202.404.8301
Washington, DC 20375, US	fax:   +1 202.404.7942








[-- Attachment #1.2: Type: text/html, Size: 5836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: X11 problem with dom0 pvops kernel on Xen 4.0.1

[Konrad Rzeszutek Wilk]

On Tue, Sep 21, 2010 at 08:22:19AM -0400, John McDermott (U.S. Navy Employee) wrote:
> 
> On Sep 20, 2010, at 5:24 PM, Konrad Rzeszutek Wilk wrote:
> 
> >> The kernels boot fine, including video, as dom0. In fact, running as dom0, they forward X11 no problem. When I install an F13 image as a pvops domU, the domU cannot start X. I agree that sounds like an attempt to pass-through is somehow screwing things up, but I have not configured the guest for pass through.
> > 
> > Ok, so your problems have nothing to do with DRM/KMS nor X if you see X working
> > as Dom0 on your machine. You don't need those nopat, nomodeset options - those are only
> > needed if you can't get X working under Dom0 and we need to troubleshoot what is happening.
> 
> @Konrad, thanks, I will remove those options.
> 
> > 
> >> 
> >> Is there a known-good F13 image I could try to install, in case the one I am trying is somehow wrong for this?
> > 
> > Well, the normal F13 works for me.. but maybe I am installing it differently than you.
> > 
> > What does 'lspci -vvv' and 'dmesg' show you under you DomU? And also can you attach
> > the 'Xorg.0.log' from DomU?
> 
> @Konrad, I posted a tarball earlier that has that stuff in it. Perhaps our uber-paranoid firewall stripped it. I resend here:
> 

Got it.

Couple of things that glare at tme:
 (XEN) CPU0: VMX disabled by BIOS.
 (XEN) VMX: failed to initialise.
 (XEN) Intel machine check reporting enabled
 (XEN) I/O virtualisation disabled

So, no VMX == no HVM. And also no VT-d enabled. Which means when you
installed FC13 you were doing PV install (which is OK). If you want to
run HVM guests you will need to enable the VMX option "Virtualization" in the BIOS.

Next glaring thing. Your Dom0 Xorg log show that:
 [  1836.298] drmOpenByBusid: drmOpenMinor returns 7
 [  1836.298] drmOpenByBusid: drmGetBusid reports pci:0000:02:00.0
 [  1836.298] (EE) [drm] failed to open device
 [  1836.298] (WW) Falling back to old probe method for fbde

Xorg Nouveau driver tried to use the drm device but failed. This is
due to the fact that the nouvoua driver API is off-sync with the Xorg driver.
The in-kernel drivers shows:
pci 0000:02:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[drm] nouveau 0000:02:00.0: Detected an NV50 generation card (0x092980a2)
[drm] Initialized nouveau 0.0.15 20090420 for 0000:02:00.0 on minor 0

while the Xorg is:
[  1836.294] (II) Loading /usr/lib64/xorg/modules/drivers/nouveau_drv.so
[  1836.294] (II) Module nouveau: vendor="X.Org Foundation"
[  1836.294]    compiled for 1.8.2, module version = 0.0.16
[  1836.294]    Module class: X.Org Video Driver
[  1836.294]    ABI class: X.Org Video Driver, version 7.0

See the 0.0.15 and 0.0.16? They need to be in sync - and if you try just to
change the version in either file and see how that works - it wont (I tried).
You can get the DRM backport kernel drivers I did and I believe they are 0.0.16,
but that tree is a bit crusty (look up details on the PVOPS DRM wiki).

Either way, this is not a big problem - you are running X under Dom0, so
things are peachy.

The Xorg from the guest side shows this:
154 [    49.161] (EE) FBDEV(0): FBIOBLANK: Invalid argument

which is harmless. It basically is trying to see if it can suspend the screen,
similary to DPMS. Well, it really does not matter as the screen it has is
a VNC window, so...

The way you start you X by doing 'startx' is not kosher anymore. The Kernel
ModeSetting put things on its head such that you need to be more careful. The proper
way is to do 'exec /sbin/init 5' or 'telinit 5' in your VNC window for the guest.
That should work.


The "xenpro-guest-alpha.lspci.out" you attached is definitly not from your guest.
Can you re-run it on the guest?

I am curious to see your screenshots of your VNC window and the xterm from your
guest.
> 
> 
> ----
> What is the formal meaning of the one-line program
> #include "/dev/tty"
> 
> J.P. McDermott				building 12
> Code 5542					mcdermott@itd.nrl.navy.mil
> Naval Research Laboratory	voice: +1 202.404.8301
> Washington, DC 20375, US	fax:   +1 202.404.7942
> 
> 
> 
> 
> 
> 
> 

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: X11 problem with dom0 pvops kernel on Xen 4.0.1

[John McDermott (U.S. Navy Employee)]

On Sep 21, 2010, at 10:58 AM, Konrad Rzeszutek Wilk wrote:

> On Tue, Sep 21, 2010 at 08:22:19AM -0400, John McDermott (U.S. Navy Employee) wrote:
>> 
>> On Sep 20, 2010, at 5:24 PM, Konrad Rzeszutek Wilk wrote:
>> 
>>>> The kernels boot fine, including video, as dom0. In fact, running as dom0, they forward X11 no problem. When I install an F13 image as a pvops domU, the domU cannot start X. I agree that sounds like an attempt to pass-through is somehow screwing things up, but I have not configured the guest for pass through.
>>> 
>>> Ok, so your problems have nothing to do with DRM/KMS nor X if you see X working
>>> as Dom0 on your machine. You don't need those nopat, nomodeset options - those are only
>>> needed if you can't get X working under Dom0 and we need to troubleshoot what is happening.
>> 
>> @Konrad, thanks, I will remove those options.
>> 
>>> 
>>>> 
>>>> Is there a known-good F13 image I could try to install, in case the one I am trying is somehow wrong for this?
>>> 
>>> Well, the normal F13 works for me.. but maybe I am installing it differently than you.
>>> 
>>> What does 'lspci -vvv' and 'dmesg' show you under you DomU? And also can you attach
>>> the 'Xorg.0.log' from DomU?
>> 
>> @Konrad, I posted a tarball earlier that has that stuff in it. Perhaps our uber-paranoid firewall stripped it. I resend here:
>> 
> 
> Got it.
> 
> Couple of things that glare at tme:
> (XEN) CPU0: VMX disabled by BIOS.

@Konrad,  I just found this out when trying to do the screen capture, just before your email arrived
.
What is really happening on the newer custom machine is a flakey BIOS. The dump is from this newer machine, which is a hand-me-down from other projects that have more $. When we first inherited it, we had no idea what the motherboard could do, so I first installed Fedora on this box and ran

# grep vmx /proc/cpuinfo

to see if the BIOS even knew about VT. At that time, /proc/cpuinfo listed 8 lines of flags _with_ vmx. So I switched to using it, thinking my problem was with the older NV44 based card. So this machine is flakey in the BIOS and has been put up for adoption by other non-Xen projects at  our lab.

I am switching back to the older Dell machine and will get you a dump and screen capture of that one asap.

John

<snip>

----
What is the formal meaning of the one-line program
#include "/dev/tty"

J.P. McDermott				building 12
Code 5542					mcdermott@itd.nrl.navy.mil
Naval Research Laboratory	voice: +1 202.404.8301
Washington, DC 20375, US	fax:   +1 202.404.7942

Re: X11 problem with dom0 pvops kernel on Xen 4.0.1

[John McDermott (U.S. Navy Employee)]

Xen Developers,

I am posting this last note to provide closure for others who search this thread some time in the future. Konrad's correction that you should not use raw `startx` allowed me to proceed. PEBCAK. Using the runlevel has allowed me to resolve all other problems, except not being able to depmod a nouveau driver. Both pvops and hvm guests run just fine, with lots of interesting XEN messages on my serial console. So we can add nVidia Quadro NVS 285 to the list of cards that work with pvops dom0. I have not been able to fix the nouveau problem, but video runs ok without it. I have no idea what is wrong with the BIOS in the newer machine and will not debug. 

Thanks to Konrad and Boris for teaching an old dog new tricks.

Sincerely,

John


On Sep 21, 2010, at 10:58 AM, Konrad Rzeszutek Wilk wrote:

> The way you start you X by doing 'startx' is not kosher anymore. The Kernel
> ModeSetting put things on its head such that you need to be more careful. The proper
> way is to do 'exec /sbin/init 5' or 'telinit 5' in your VNC window for the guest.
> That should work.

----
What is the formal meaning of the one-line program
#include "/dev/tty"

J.P. McDermott				building 12
Code 5542					mcdermott@itd.nrl.navy.mil
Naval Research Laboratory	voice: +1 202.404.8301
Washington, DC 20375, US	fax:   +1 202.404.7942