Re: NetBSD-6.0_Beta - No X11 with Xen

[eric%cirr.com@localhost (Eric Schnoebelen)]

[copied to port-xen%netbsd.org@localhost, where more of the Xen gurus may
see this.]

Sad Clouds writes:
- Hi, I've set NetBSD-6.0_Beta amd64 port. I use the following
- in /boot.cfg to load Xen:
- 
- menu=Xen3:modules enabled;load /netbsd-XEN3_DOM0;multiboot /xen.gz
- dom0_mem=1024M console=vga -- console=pc
- 
- On boot I have /etc/rc.d/gdm run to start display manager. For some
- reason it doesn't come up with Xen, i.e. process is running but there
- is no X11.

Have you checked /var/log/Xorg.0.log, to see what it might have
to say?

- This used to work on NetBSD-5.1 simply with 
- 
- menu=Xen3:load /netbsd-XEN3_DOM0;multiboot /xen.gz dom0_mem=1024M
- 
- I've been playing around with console= parameters, but just can't get
- it to work. Any ideas?

I suspect that the XEN3_DOM0 kernels no longer allow the mapping
of the frame buffer space.  I see the same thing trying to use
the xen hypervisor and 6.0_BETA XEN3_DOM0 kernels on my laptop.
(the laptop hasn't been able to boot a generic kernel since
somewhere in 4.99.?? days. The hypervisor provides enough
abstraction that all works when using a XEN3_DOM0 kernel.)

Curently, the above laptop is running 5.99.52. I have a newer kernel
on there (5.99.62), but I don't remember if X worked with it or
not.

When attempting to start X on the 6.0_BETA kernel, I see the
radeonhd driver attempting to map memory space to read the BIOS
of the card, and failing.  I wonder if XEN3_DOM0 has lost
''options INSECURE'' at some point, causing X to fail to load.
(aka, defaulting to ''kern.securelevel = 1'', which would
prohibit applications from direct memory access, and thus the X
server from manipulating the PCI frame buffer.)

I hope this helps,
        Eric

--
Eric Schnoebelen                eric%cirr.com@localhost         
http://www.cirr.com
  How many seconds are there in a year?  If I tell you there are 3.155  x
  10^7, you won't even try to remember it.  On the other hand, who could
  forget that, to within half a percent, pi seconds is a nanocentury.  
                        -- Tom Duff, Bell Labs