Fwd: X11 in a jail (was: Re: NFS mount inside jail fails)

[Doug Ambrisko]

Alexander Leidinger writes:
| Ooops, s/jails@/jail@/ ...
| 
| Quoting Doug Ambrisko <ambrisko at ambrisko.com> (from Wed, 25 May 2011  
| 09:42:20 -0700 (PDT)):
| 
| CCing jails@
| 
| > Alexander Leidinger writes:
| > | Quoting Doug Ambrisko <ambrisko at ambrisko.com> (from Thu, 19 May 2011
| > | 14:38:40 -0700 (PDT)):
| > |
| > | > Alexander Leidinger writes:
| > | > | On Thu, 19 May 2011 10:24:59 -0700 (PDT) Doug Ambrisko
| > | > | <ambrisko at ambrisko.com> wrote:
| > | > |
| > | > | > doesn't have access to it anymore either.  Running an X server in a
| > | > | > vimage has some issues.  Most are pretty easy to over-come.
| > | > |
| > | > | Are you using my patch
| > | > | (http://www.leidinger.net/FreeBSD/current-patches/0_jail.diff) + a
| > | > | custom devfs.rules to get the 2D part (the last time I tried the DRI
| > | > | part of my patch, it paniced the machine) of the X server working in a
| > | > | jail, or did you come up with something yourself? If it is the later, I
| > | > | would be interested how you did it.
| > | >
| > | > Nope, didn't know about it when I played with it.  I should try it.
| > | > I added
| > | > 	case PRIV_IO:
| > | > 		return (0);
| > | >
| > | > to kern_jail.c to get X to work.  This was with the Intel graphics.
| > | > The main problem I have now is on resume the X server dies and restarts.
| > | > I use xdm.  Without jail with vimage then it works okay.
| > |
| > | I use it without vimage in a jail. This is with a radeon card
| > | (corresponding kernel module loaded at boot to get 2D acceleration, as
| > | the X server obviously can not load modules in a jail).
| > |
| > | > My laptop can use either Intel or ATI graphics.  I just switched it to
| > | > ATI to see what happens.  I should try some more tests.  It seems
| > | > my BIOS likes to reset this setting and enable both :-(
| > | >
| > | > I don't seem to have panics.  This is with a month or so old -current.
| > |
| > | You do not allow access to the dri device, so I do not expect a panic.
| > | If you give access to the dri device (which can be enabled separately
| > | in my patch), I would not be surprised to see a panic (the last time I
| > | tried it is a year or two ago, I didn't take the time to investigate
| > | why it panics).
| >
| > Okay, I have an update.  With Intel graphics and using dri things
| > work better and I don't get panics.  I load drm.ko & i915.ko before
| 
| Just to make sure we talk about the same things:
| Did you configure the X server to use 3D (dri and glx in the modules  
| section, dri section in the X11 config, dri device visible in devfs)?  
| xdriinfo shows some valid hardware acceleration?

main% xdriinfo
Screen 0: i965
main% ls -lt /dev/dri
total 0
crw-rw----  1 root  wheel    0,  35 May 26 10:18 card0
main% 

from xorg.conf:
  Section "Module"
        Load  "record"
        Load  "glx"
        Load  "extmod"
        Load  "dri2"
        Load  "dri"
        Load  "dbe"
  EndSection

a part of Xorg.log
  (WW) intel(0): DRI2 requires UXA
  drmOpenDevice: node name is /dev/dri/card0
  drmOpenDevice: open result is 10, (OK)
  drmOpenDevice: node name is /dev/dri/card0
  drmOpenDevice: open result is 10, (OK)
  drmOpenByBusid: Searching for BusID pci:0000:00:02.0
  drmOpenDevice: node name is /dev/dri/card0
  drmOpenDevice: open result is 10, (OK)
  drmOpenByBusid: drmOpenMinor returns 10
  drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0
  (II) [drm] DRM interface version 1.2
  (II) [drm] DRM open master succeeded.
  (II) intel(0): [drm] Using the DRM lock SAREA also for drawables.
  (II) intel(0): [drm] framebuffer mapped by ddx driver
  (II) intel(0): [drm] added 1 reserved context for kernel
  (II) intel(0): X context handle = 0x1
  (II) intel(0): [drm] installed DRM signal handler
  (**) intel(0): Framebuffer compression enabled
  (**) intel(0): Tiling enabled
  (==) intel(0): VideoRam: 262144 KB
  (II) intel(0): Attempting memory allocation with tiled buffers.
  (II) intel(0): Tiled allocation successful.
  (II) intel(0): [drm] Registers = 0x00000000
  (II) intel(0): [drm] ring buffer = 0x00000000
  (II) intel(0): [drm] mapped front buffer at 0xd091a000, handle = 0x00000000
  (II) intel(0): [drm] mapped back buffer at 0xd271c000, handle = 0x00000000
  (II) intel(0): [drm] mapped depth buffer at 0xd2e9c000, handle = 0x00000000
  (II) intel(0): [drm] mapped classic textures at 0xd361c000, handle = 0x00000000
  (II) intel(0): [drm] Initialized kernel agp heap manager, 33554432
  (II) intel(0): [dri] visual configs initialized
 
| If yes, I definitively have to test the 3D part again with my radeon  
| (with a normal jail and with a vimage jail in case the normal jail  
| fails).
| 
| > starting the vimage jail.  X sees it and uses it.  This solves the
| > suspend/resume issue I had.  The dri issue also prevented suspend and
| > resume fail to work in a chroot.
| >
| > I have not tried switching to using the ATI option.  On a plus side
| > my laptop is running cooler and faster now.
| 
| If you didn't had loaded i915.ko before, you have at least 2D accel  
| now, and probably the power management of the chip got activated too.

Before neither were loaded until I added it.  Outside of a chroot
X will auto load it.

I agree that probably something else got activated to make suspend/resume
work.

Doug A.