SuperSavage/IXC 64 hassle making DRI and SELinux work together

[Joachim Frieben]

I am experimenting with DRI on my IBM Thinkpad T23 running FC4. For this
purpose, I rebuilt M. Harris' testing X.org 6.8.99.14 package with activated
"savage" DRI support. After starting the graphical environment, X reports
"(II) SAVAGE(0): Direct rendering enabled" which is rather satisfactory :)
In the beginning, "SELinux" used to be enabled by default. However, this
lead to segmentation faults when calling applications which depend on
OpenGL, e.g. in the case of "glxinfo". The corresponding "dmesg" entry
read:

"Unable to handle kernel paging request at virtual address e0c10000
printing eip:
e0a2e458 *pde = 1d11c067
Oops: 0002 [#1]
Modules linked in: nvram parport_pc lp parport autofs4 rfcomm l2cap
bluetooth sunrpc pcmcia ipt_REJECT ipt_state ip_conntrack iptable_filter
ip_tables ibm_acpi(U) kqemu(U) savage(U) drm(U) md5 ipv6 video button
battery ac yenta_socket rsrc_nonstatic pcmcia_core uhci_hcd shpchp hw_random
i2c_i801 i2c_core snd_intel8x0 snd_ac97_codec snd_seq_dummy snd_seq_oss
snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm
snd_timer snd soundcore snd_page_alloc e100
mii floppy dm_snapshot dm_zero dm_mirror ext3 jbd dm_mod
CPU:    0
EIP:    0060:[<e0a2e458>]    Tainted: P      VLI
EFLAGS: 00010282   (2.6.12-1.1398_FC4)
EIP is at savage_bci_emit_event+0x7e/0xe4 [savage]
eax: e0c10000   ebx: c0030000   ecx: d61a6000   edx: 00000002
esi: dacb7e00   edi: 00000135   ebp: 00000135   esp: ce70fef4
ds: 007b   es: 007b   ss: 0068
Process glxinfo (pid: 3338, threadinfo=ce70f000 task=d0614aa0)
Stack: badc0ded ce70ff20 cf8740e0 dacb7e00 ce6dfa20 e0a30274 ce70ff58
c01f7485       ce70ff58 00100100 00200200 00000003 00000000 00000003 e0a301bc
       e0a36638       00000042 e0a1ec0f bfb111a4 00000001 d5406000 d0614aa0
d0614aa0
       ce556fc0Call Trace:
 [<e0a30274>] savage_bci_event_emit+0xb8/0xe6 [savage]
 [<c01f7485>] selinux_file_ioctl+0xce/0x2d9
 [<e0a301bc>] savage_bci_event_emit+0x0/0xe6 [savage]
 [<e0a1ec0f>] drm_ioctl+0x98/0x1dc [drm]
 [<e0a1eb77>] drm_ioctl+0x0/0x1dc [drm]
 [<c01931b1>] do_ioctl+0x51/0x55
 [<c01932a7>] vfs_ioctl+0x50/0x1aa
 [<c019345e>] sys_ioctl+0x5d/0x6b
 [<c0103a51>] syscall_call+0x7/0xb
Code: e3 00 00 fe ff 81 eb 00 00 fe 3f 89 d8 0d 00 00 01 00 80 e2 02 0f 45
d8 ba 02 00 00 00 89 f0 ff 96 2c 01 00 00 8b 86 d0 00 00 00 <89> 18 83 c0 04
81 cf 00 00 00 98 89 38 89 e8 5b 5e 5f 5d c3 83"

There is a prior entry saying:

"mtrr: base(0xe4000000) is not aligned on a size(0x5000000) boundary"

The curious thing is that when "SELinux" is disabled at boot time through
option "selinux=disabled" in "", DRI works correctly. Sure, the 3D
performance is pretty poor, but anyway. Has anybody observed this behaviour,
too? Any clues how to make SELinux and DRI make play together peacefully?

[Daniel J Walsh]

jfrieben(a)freesurf.fr wrote:

> I am experimenting with DRI on my IBM Thinkpad T23 running FC4. For
> this
> purpose, I rebuilt M. Harris' testing X.org 6.8.99.14 package with activated
> "savage" DRI support. After starting the graphical environment, X reports
> "(II) SAVAGE(0): Direct rendering enabled" which is rather satisfactory :)
> In the beginning, "SELinux" used to be enabled by default. However, this
> lead to segmentation faults when calling applications which depend on
> OpenGL, e.g. in the case of "glxinfo". The corresponding "dmesg" entry
> read:
>
> "Unable to handle kernel paging request at virtual address e0c10000
> printing eip:
> e0a2e458 *pde = 1d11c067
> Oops: 0002 [#1]
> Modules linked in: nvram parport_pc lp parport autofs4 rfcomm l2cap
> bluetooth sunrpc pcmcia ipt_REJECT ipt_state ip_conntrack iptable_filter
> ip_tables ibm_acpi(U) kqemu(U) savage(U) drm(U) md5 ipv6 video button
> battery ac yenta_socket rsrc_nonstatic pcmcia_core uhci_hcd shpchp hw_random
> i2c_i801 i2c_core snd_intel8x0 snd_ac97_codec snd_seq_dummy snd_seq_oss
> snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm
> snd_timer snd soundcore snd_page_alloc e100
> mii floppy dm_snapshot dm_zero dm_mirror ext3 jbd dm_mod
> CPU:    0
> EIP:    0060:[<e0a2e458>]    Tainted: P      VLI
> EFLAGS: 00010282   (2.6.12-1.1398_FC4)
> EIP is at savage_bci_emit_event+0x7e/0xe4 [savage]
> eax: e0c10000   ebx: c0030000   ecx: d61a6000   edx: 00000002
> esi: dacb7e00   edi: 00000135   ebp: 00000135   esp: ce70fef4
> ds: 007b   es: 007b   ss: 0068
> Process glxinfo (pid: 3338, threadinfo=ce70f000 task=d0614aa0)
> Stack: badc0ded ce70ff20 cf8740e0 dacb7e00 ce6dfa20 e0a30274 ce70ff58
> c01f7485       ce70ff58 00100100 00200200 00000003 00000000 00000003 e0a301bc
>        e0a36638       00000042 e0a1ec0f bfb111a4 00000001 d5406000 d0614aa0
> d0614aa0
>        ce556fc0Call Trace:
>  [<e0a30274>] savage_bci_event_emit+0xb8/0xe6 [savage]
>  [<c01f7485>] selinux_file_ioctl+0xce/0x2d9
>  [<e0a301bc>] savage_bci_event_emit+0x0/0xe6 [savage]
>  [<e0a1ec0f>] drm_ioctl+0x98/0x1dc [drm]
>  [<e0a1eb77>] drm_ioctl+0x0/0x1dc [drm]
>  [<c01931b1>] do_ioctl+0x51/0x55
>  [<c01932a7>] vfs_ioctl+0x50/0x1aa
>  [<c019345e>] sys_ioctl+0x5d/0x6b
>  [<c0103a51>] syscall_call+0x7/0xb
> Code: e3 00 00 fe ff 81 eb 00 00 fe 3f 89 d8 0d 00 00 01 00 80 e2 02 0f 45
> d8 ba 02 00 00 00 89 f0 ff 96 2c 01 00 00 8b 86 d0 00 00 00 <89> 18 83 c0 04
> 81 cf 00 00 00 98 89 38 89 e8 5b 5e 5f 5d c3 83"
>
> There is a prior entry saying:
>
> "mtrr: base(0xe4000000) is not aligned on a size(0x5000000) boundary"
>
> The curious thing is that when "SELinux" is disabled at boot time through
> option "selinux=disabled" in "", DRI works correctly. Sure, the 3D
> performance is pretty poor, but anyway. Has anybody observed this behaviour,
> too? Any clues how to make SELinux and DRI make play together peacefully?
>
>
>   
>  
Are you seeing any AVC messages in /var/log/messages or 
/var/log/audit/audit.log?

--

[Joachim Frieben]

There are many AVC entries in both files "/var/log/messages" and
"/var/log/audit/audit.log". However, they do not seem to be related to the
use of DRM. In particular, there is no additional entry upon call of
"glxinfo" related to the SELinux framework, whereas there is some output to
"/var/log/dmesg". If "SELinux" had intercepted some unauthorized
access/action, it should at least have reported this somewhat more verbosely
instead of simply crashing the X server in the case of "glxgears" - right?
Here comes the snippet from "/var/log/messages" with AVC related stuff from
the system boot procedure:

"Jul 28 19:38:04 riemann kernel: audit(1122572272.500:3): avc:  denied  {
read write } for  pid=1879 comm="runlevel" name="utmp" dev=dm-0
ino=196617
scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:init_var_run_t
tclass=file
Jul 28 19:38:04 riemann kernel: audit(1122572272.500:4): avc:  denied  {
read }for  pid=1879 comm="runlevel" name="utmp" dev=dm-0 ino=196617
scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:init_var_run_t
tclass=file
Jul 28 19:38:04 riemann kernel: audit(1122572272.500:5): avc:  denied  {
read write } for  pid=1879 comm="runlevel" name="utmp" dev=dm-0
ino=196617
scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:init_var_run_t
tclass=file
Jul 28 19:38:04 riemann kernel: audit(1122572272.500:6): avc:  denied  {
read }for  pid=1879 comm="runlevel" name="utmp" dev=dm-0 ino=196617
scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:init_var_run_t
tclass=file
Jul 28 19:38:04 riemann kernel: SELinux: initialized (dev rpc_pipefs, type
rpc_pipefs), uses genfs_contexts".

[Daniel J Walsh]

jfrieben(a)freesurf.fr wrote:

> There are many AVC entries in both files "/var/log/messages"
> and
> "/var/log/audit/audit.log". However, they do not seem to be related to the
> use of DRM. In particular, there is no additional entry upon call of
> "glxinfo" related to the SELinux framework, whereas there is some output to
> "/var/log/dmesg". If "SELinux" had intercepted some unauthorized
> access/action, it should at least have reported this somewhat more verbosely
> instead of simply crashing the X server in the case of "glxgears" - right?
> Here comes the snippet from "/var/log/messages" with AVC related stuff from
> the system boot procedure:
>
> "Jul 28 19:38:04 riemann kernel: audit(1122572272.500:3): avc:  denied  {
> read write } for  pid=1879 comm="runlevel" name="utmp" dev=dm-0
> ino=196617
> scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:init_var_run_t
> tclass=file
> Jul 28 19:38:04 riemann kernel: audit(1122572272.500:4): avc:  denied  {
> read }for  pid=1879 comm="runlevel" name="utmp" dev=dm-0 ino=196617
> scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:init_var_run_t
> tclass=file
> Jul 28 19:38:04 riemann kernel: audit(1122572272.500:5): avc:  denied  {
> read write } for  pid=1879 comm="runlevel" name="utmp" dev=dm-0
> ino=196617
> scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:init_var_run_t
> tclass=file
> Jul 28 19:38:04 riemann kernel: audit(1122572272.500:6): avc:  denied  {
> read }for  pid=1879 comm="runlevel" name="utmp" dev=dm-0 ino=196617
> scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:init_var_run_t
> tclass=file
> Jul 28 19:38:04 riemann kernel: SELinux: initialized (dev rpc_pipefs, type
> rpc_pipefs), uses genfs_contexts".
>
>
>   
>  
This looks like you have some kind of labeleing problem.  utmp is labled 
init_var_run_t, it should be initrc_var_run_t
You may want to relabel.
Have you tried to boot with enforcing=0? 

Dan

--

[Joachim Frieben]

Hi Dan,

thanks a lot for pointing this out. However, this seems to be due to
"SELinux" being work in progress. I have reinstalled FC4 from scratch,
installed alle available updates, and still obtain the same AVC messages
without even touching DRI. However, here the good news: after reinstalling
FC4 from scratch, both of "xorg-x11-6.8.2-37" (FC4 updates) and
"xorg-x11-6.8.99.16-0.homebrewn" (derived from M. Harris unstable
"xorg-x11-6.8.99.14-3" SRPM) allow for direct rendering even when
"SELinux"
is active. The latter has the advantage of being up to date in terms of
OpenGL compatibility. It seems that the successive updates of various
packages, probably "audit" and "selinux-policy-targeted", messed up
the
system. I still have the "mtrr: base(0xe4000000) is not aligned on a
size(0x5000000) boundary" warning, but apparently, it does not matter.

Cheers,

-Joachim

>  This looks like you have some kind of labeleing problem.  utmp is
>  labled  init_var_run_t, it should be initrc_var_run_t
>  You may want to relabel.
>  Have you tried to boot with enforcing=0?
>
>  Dan
>
>  --
>
>
>  --
>  fedora-devel-list mailing list
>  fedora-devel-list(a)redhat.com
>  http://www.redhat.com/mailman/listinfo/fedora-devel-list

[Jerone Young]

I had your exact laptop about a few months ago. The DRI driver does
not support the mobile version of the Savage card. So your out of luck
when it comes to 3D support on your T23.

On 7/28/05, jfrieben(a)freesurf.fr <jfrieben(a)freesurf.fr&gt; wrote:
>  I am experimenting with DRI on my IBM Thinkpad T23 running FC4. For
> this
>  purpose, I rebuilt M. Harris' testing X.org 6.8.99.14 package with activated
>  "savage" DRI support. After starting the graphical environment, X reports
>  "(II) SAVAGE(0): Direct rendering enabled" which is rather satisfactory :)
>  In the beginning, "SELinux" used to be enabled by default. However, this
>  lead to segmentation faults when calling applications which depend on
>  OpenGL, e.g. in the case of "glxinfo". The corresponding "dmesg"
> entry read:
>  
>  "Unable to handle kernel paging request at virtual address e0c10000
>  printing eip:
>  e0a2e458 *pde = 1d11c067
>  Oops: 0002 [#1]
>  Modules linked in: nvram parport_pc lp parport autofs4 rfcomm l2cap
>  bluetooth sunrpc pcmcia ipt_REJECT ipt_state ip_conntrack iptable_filter
>  ip_tables ibm_acpi(U) kqemu(U) savage(U) drm(U) md5 ipv6 video button
>  battery ac yenta_socket rsrc_nonstatic pcmcia_core uhci_hcd shpchp hw_random
>  i2c_i801 i2c_core snd_intel8x0 snd_ac97_codec snd_seq_dummy snd_seq_oss
>  snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm
>  snd_timer snd soundcore snd_page_alloc e100
>  mii floppy dm_snapshot dm_zero dm_mirror ext3 jbd dm_mod
>  CPU:    0
>  EIP:    0060:[<e0a2e458>]    Tainted: P      VLI
>  EFLAGS: 00010282   (2.6.12-1.1398_FC4)
>  EIP is at savage_bci_emit_event+0x7e/0xe4 [savage]
>  eax: e0c10000   ebx: c0030000   ecx: d61a6000   edx: 00000002
>  esi: dacb7e00   edi: 00000135   ebp: 00000135   esp: ce70fef4
>  ds: 007b   es: 007b   ss: 0068
>  Process glxinfo (pid: 3338, threadinfo=ce70f000 task=d0614aa0)
>  Stack: badc0ded ce70ff20 cf8740e0 dacb7e00 ce6dfa20 e0a30274 ce70ff58
>  c01f7485       ce70ff58 00100100 00200200 00000003 00000000 00000003 e0a301bc
>         e0a36638       00000042 e0a1ec0f bfb111a4 00000001 d5406000 d0614aa0
>  d0614aa0
>         ce556fc0Call Trace:
>   [<e0a30274>] savage_bci_event_emit+0xb8/0xe6 [savage]
>   [<c01f7485>] selinux_file_ioctl+0xce/0x2d9
>   [<e0a301bc>] savage_bci_event_emit+0x0/0xe6 [savage]
>   [<e0a1ec0f>] drm_ioctl+0x98/0x1dc [drm]
>   [<e0a1eb77>] drm_ioctl+0x0/0x1dc [drm]
>   [<c01931b1>] do_ioctl+0x51/0x55
>   [<c01932a7>] vfs_ioctl+0x50/0x1aa
>   [<c019345e>] sys_ioctl+0x5d/0x6b
>   [<c0103a51>] syscall_call+0x7/0xb
>  Code: e3 00 00 fe ff 81 eb 00 00 fe 3f 89 d8 0d 00 00 01 00 80 e2 02 0f 45
>  d8 ba 02 00 00 00 89 f0 ff 96 2c 01 00 00 8b 86 d0 00 00 00 <89> 18 83 c0 04
>  81 cf 00 00 00 98 89 38 89 e8 5b 5e 5f 5d c3 83"
>  
>  There is a prior entry saying:
>  
>  "mtrr: base(0xe4000000) is not aligned on a size(0x5000000) boundary"
>  
>  The curious thing is that when "SELinux" is disabled at boot time through
>  option "selinux=disabled" in "", DRI works correctly. Sure, the 3D
>  performance is pretty poor, but anyway. Has anybody observed this behaviour,
>  too? Any clues how to make SELinux and DRI make play together peacefully?
>  
>  
>  --
>  fedora-devel-list mailing list
>  fedora-devel-list(a)redhat.com
>  http://www.redhat.com/mailman/listinfo/fedora-devel-list
>

[Jerone Young]

Forget what I said....you wow it now works .. coolness.

On 7/28/05, Jerone Young <jerone(a)gmail.com&gt; wrote:
>  I had your exact laptop about a few months ago. The DRI driver does
>  not support the mobile version of the Savage card. So your out of luck
>  when it comes to 3D support on your T23.
>  
>  On 7/28/05, jfrieben(a)freesurf.fr <jfrieben(a)freesurf.fr&gt; wrote:
>  > I am experimenting with DRI on my IBM Thinkpad T23 running FC4. For this
>  > purpose, I rebuilt M. Harris' testing X.org 6.8.99.14 package with activated
>  > "savage" DRI support. After starting the graphical environment, X reports
>  > "(II) SAVAGE(0): Direct rendering enabled" which is rather satisfactory
> :)
>  > In the beginning, "SELinux" used to be enabled by default. However, this
>  > lead to segmentation faults when calling applications which depend on
>  > OpenGL, e.g. in the case of "glxinfo". The corresponding "dmesg"
> entry read:
>  >
>  > "Unable to handle kernel paging request at virtual address e0c10000
>  > printing eip:
>  > e0a2e458 *pde = 1d11c067
>  > Oops: 0002 [#1]
>  > Modules linked in: nvram parport_pc lp parport autofs4 rfcomm l2cap
>  > bluetooth sunrpc pcmcia ipt_REJECT ipt_state ip_conntrack iptable_filter
>  > ip_tables ibm_acpi(U) kqemu(U) savage(U) drm(U) md5 ipv6 video button
>  > battery ac yenta_socket rsrc_nonstatic pcmcia_core uhci_hcd shpchp hw_random
>  > i2c_i801 i2c_core snd_intel8x0 snd_ac97_codec snd_seq_dummy snd_seq_oss
>  > snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm
>  > snd_timer snd soundcore snd_page_alloc e100
>  > mii floppy dm_snapshot dm_zero dm_mirror ext3 jbd dm_mod
>  > CPU:    0
>  > EIP:    0060:[<e0a2e458>]    Tainted: P      VLI
>  > EFLAGS: 00010282   (2.6.12-1.1398_FC4)
>  > EIP is at savage_bci_emit_event+0x7e/0xe4 [savage]
>  > eax: e0c10000   ebx: c0030000   ecx: d61a6000   edx: 00000002
>  > esi: dacb7e00   edi: 00000135   ebp: 00000135   esp: ce70fef4
>  > ds: 007b   es: 007b   ss: 0068
>  > Process glxinfo (pid: 3338, threadinfo=ce70f000 task=d0614aa0)
>  > Stack: badc0ded ce70ff20 cf8740e0 dacb7e00 ce6dfa20 e0a30274 ce70ff58
>  > c01f7485       ce70ff58 00100100 00200200 00000003 00000000 00000003 e0a301bc
>  >        e0a36638       00000042 e0a1ec0f bfb111a4 00000001 d5406000 d0614aa0
>  > d0614aa0
>  >        ce556fc0Call Trace:
>  >  [<e0a30274>] savage_bci_event_emit+0xb8/0xe6 [savage]
>  >  [<c01f7485>] selinux_file_ioctl+0xce/0x2d9
>  >  [<e0a301bc>] savage_bci_event_emit+0x0/0xe6 [savage]
>  >  [<e0a1ec0f>] drm_ioctl+0x98/0x1dc [drm]
>  >  [<e0a1eb77>] drm_ioctl+0x0/0x1dc [drm]
>  >  [<c01931b1>] do_ioctl+0x51/0x55
>  >  [<c01932a7>] vfs_ioctl+0x50/0x1aa
>  >  [<c019345e>] sys_ioctl+0x5d/0x6b
>  >  [<c0103a51>] syscall_call+0x7/0xb
>  > Code: e3 00 00 fe ff 81 eb 00 00 fe 3f 89 d8 0d 00 00 01 00 80 e2 02 0f 45
>  > d8 ba 02 00 00 00 89 f0 ff 96 2c 01 00 00 8b 86 d0 00 00 00 <89> 18 83 c0 04
>  > 81 cf 00 00 00 98 89 38 89 e8 5b 5e 5f 5d c3 83"
>  >
>  > There is a prior entry saying:
>  >
>  > "mtrr: base(0xe4000000) is not aligned on a size(0x5000000) boundary"
>  >
>  > The curious thing is that when "SELinux" is disabled at boot time through
>  > option "selinux=disabled" in "", DRI works correctly. Sure, the
> 3D
>  > performance is pretty poor, but anyway. Has anybody observed this behaviour,
>  > too? Any clues how to make SELinux and DRI make play together peacefully?
>  >
>  >
>  > --
>  > fedora-devel-list mailing list
>  > fedora-devel-list(a)redhat.com
>  > http://www.redhat.com/mailman/listinfo/fedora-devel-list
>  >
>