[<<][pool][>>][..]
Sun Mar 7 11:26:08 CET 2010

The 64-bit problem

To be honest, it's quite a mess still.  Especially if you want to use
binary packages.  I'm thinking about switching back to 32 bit for day
to day work.

You need a 64-bit kernel if you want to use all your _physical_ memory
at or above 4 gig.  A 64-bit userland is only useful for applications
that need a _virtual_ address space that's more than 4 gig.  I don't
have such applications, so there should be no problem sticking to
32bit.

( There are other advantages to 64-bit intel which are due to it
having twice as much registers so in theory it should be faster.. )

 1. Root filesystem

The main idea is to use a chroot to host a 32-bit base filesystem.  To
make the original root accessible it's simplest to mount it twice.
Make sure that the 2nd time doesn't perform an fsck at boot time.

/dev/mapper/vg1-root /            ext3 errors=remount-ro 0 1  # check in pass 1
/dev/mapper/vg1-root /i686/x86_64 ext3 errors=remount-ro 0 0  # don't check


 2. Kernel

The kernel should run as 64-bit to give full access to the memory
range for services that can use it.

The problem is then: how to give the 32-bit system access to the
hardware?  The most important parts are display and audio.  Let's
investigate.

Playback mp3 file from schroot.  This seems to work, but it's using
OSS instead of Alsa.  Mounting udev twice doesn't seem to work: it's a
tmpfs.  Workaround: create device nodes manually:

zni:/i686/dev# cp -av /dev/snd .
`/dev/snd' -> `./snd'
`/dev/snd/controlC1' -> `./snd/controlC1'
`/dev/snd/pcmC1D3p' -> `./snd/pcmC1D3p'
`/dev/snd/pcmC0D0c' -> `./snd/pcmC0D0c'
`/dev/snd/pcmC0D0p' -> `./snd/pcmC0D0p'
`/dev/snd/controlC0' -> `./snd/controlC0'
`/dev/snd/pcmC0D1p' -> `./snd/pcmC0D1p'
`/dev/snd/pcmC0D2c' -> `./snd/pcmC0D2c'
`/dev/snd/seq' -> `./snd/seq'
`/dev/snd/timer' -> `./snd/timer'

Need to set DISPLAY variable using localhost TCP instead of unix
sockets.

(i686)tom@zni:~$ export DISPLAY=:0

XV seems to work:

(i686)root@zni:/# xvinfo
X-Video Extension version 2.2
screen #0
  Adaptor #0: "Radeon Textured Video"
    number of ports: 16
    port base: 57
...

Making /tmp/.X11-unix available on the chroot also solves the X
DISPLAY=:0 issue.


Then, direct rendering.

(i686)tom@zni:~$ glxinfo
Error: unable to open display :0

This is because the unix socket is not available.  Changing to UDP
solves it though.  Then let's see if direct rendering works:

(i686)tom@zni:~$ glxinfo |grep why
direct rendering: No (If you want to find out why, try setting LIBGL_DEBUG=verbose)
(i686)tom@zni:~$ LIBGL_DEBUG=verbose glxinfo |less
libGL: XF86DRIGetClientDriverName: 4.3.0 r600 (screen 0)
libGL: OpenDriver: trying /usr/lib/dri/r600_dri.so
libGL error: dlopen /usr/lib/dri/r600_dri.so failed (/usr/lib/dri/r600_dri.so: cannot open shared object file: No such file or directory)
libGL error: unable to load driver: r600_dri.so

Trying update:

(i686)root@zni:/x86_64/home/tom# apt-get install libdrm-intel1 libdrm-radeon1 libdrm2 libgimp2.0 libgl1-mesa-dev libgl1-mesa-dri libgl1-mesa-glx  libglu1-mesa libglu1-mesa-dev mesa-common-dev mesa-utils

After that it starts to go seriously wrong: hard lockups.  I don't
feel like working around driver bugs so mission aborted.

Current conclusion: video bugs prevent this to work.




[Reply][About]
[<<][pool][>>][..]