Andrew Cagney <andrew.cagney%gmail.com@localhost> writes: > On 19 November 2014 18:52, Greg Troxel <gdt%ir.bbn.com@localhost> wrote: >> My impression is that the dom0 has access to all the PCI devices and >> therefore mostly should behave like a non-xen kernel. However, xen >> usage tends to be serverish, where many don't want X, so it's not so >> well shaken out. > > Interesting, running multiple vms on a laptop isn't that unusual. I > should be looking again at VirtualBox (fpkgsrc/wip/... doesn't build > and is very old) or something else? xen on a laptop isn't really that odd. I just meant that as far as I could tell, most netbsd xen users tended to run a server with no X. This really should work ok. I suspect it's easier to fix whatever X issues are happening than to get virtualbox up to date. >> One wrinkle is how xen uses the console and hands it off to the dom0. >> That could be leaving the console in a bad state. It might be possible >> to tell xen to use a serial port, but you might not have a serial port. >> You might try not trying to change the text console font, but only to do >> X11. > > btw, I'm not directly changing the console font/resolution, the kernel > is; recent "fix" - the 720p screen finally does 720p correctly. OK. I was really trying to suggest keeping everything as vanilla as possible, to stay on paths that might be better debugged. >> My advice is to first make sure you can run X11 satisfactorily on the >> same machine, booting a GENERIC kernel instead of xen and the dom0. >> This is the normal recovery/fallback config, and there is an example in >> boot.cfg(5). Maybe you already did this. > > the generic version of the kernel works pretty well. So that leaves you with either 1. xen booting is doing something to the video hw that causes problems 2. xen kernel and GENERIC have different options and you need one that's missing 3. xen vs GENERIC is different in some way that's problematic 4. xen is not providing adequate hw access to the dom0 I would guess either 1 or 2. You might also try X under dom0 on some other machines. If we figure out that it's only a few that are trouble, that would provide valuable clues.
Attachment:
pgp5WlZlbJnYh.pgp
Description: PGP signature