I am experimenting with DRI on my IBM Thinkpad T23 running FC4. For this
purpose, I rebuilt M. Harris' testing X.org 188.8.131.52 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
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
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
[<e0a30274>] savage_bci_event_emit+0xb8/0xe6 [savage]
[<e0a301bc>] savage_bci_event_emit+0x0/0xe6 [savage]
[<e0a1ec0f>] drm_ioctl+0x98/0x1dc [drm]
[<e0a1eb77>] drm_ioctl+0x0/0x1dc [drm]
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?
After applying yesterday's rawhide to my iBook, the system is quite
thoroughly toasted. After yum was finished, ssh'ing into the
machine no longer worke, and neither did logging in at the local
console. Rebooting the machine hangs after the initrd is processed,
seemingly failing to execute /sbin/init.
My suspicion is that a very low level library is botched (glibc or
selinux). Trying to chroot() into the system from an old YDL 3.0
install CD (the only CD what would boot on PPC I found on short
notice) fails, just producing segfaults, but YDL 3.0 is quite
old, of course, and still running 2.4. Will try and get a
FC4 install CD today and try again.
PS: The system does not use selinux.
Le mercredi 06 juillet 2005 à 22:17 +0200, David Jez a écrit :
> > Well, Fedora already has its share of ugly fonts with wide unicode
> > coverage. As we're only talking about a single character here, that does
> > not seem too difficult to create (just add a black diamond to a question
> > mark), I'd suggest you just get it into dejavu and I'll get the new
> > dejavu version into Fedora Extras.
> > If you're quick it'll be available for users by early august.
> As you wish...
James Cloos already proposed to work on it. I must say it's great to
have a reactive font project instead of packaging and installing scores
of incomplete/different/frozen fonts just to get good glyph coverage.
And I hope this thread will inspire more people on the CCd lists to work
is there a known issue with RPM's sqlite backend?
I've switched my RPM database to sqlite and now
I see strange dependency problems when installing
# rpm -F xorg-x11-*
error: Failed dependencies:
/usr/sbin/chkfontpath is needed by xorg-x11-6.8.2-45.x86_64
# ls -l /usr/sbin/chkfontpath
-rwxr-xr-x 1 root root 17288 Mar 3 21:03 /usr/sbin/chkfontpath
# rpm -ql chkfontpath
// Bernardo Innocenti - Develer S.r.l., R&D dept.
While Pegasos II is not officially support as a PPC platform, some minor
would make it more friendly out-of-the-box for Pegasos II hackers. Would
kindly consider the following changes:
1. Kernel config
CONFIG_SERIO_I8042=y (or m)
(Pegasos II uses AMIGA partitioning and IBM AT PS/2 style mouse and
2. (This part is hard, I'm not sure I understand the issues myself -
it's necessary to avoid Pegasos II people
from having to rebuild from kernel source.) Pegasos II needs a
zImage.initrd.chrp kernel to boot (i.e. a combined
zImage.chrp & initrd) instead of a separate vmlinux + initrd, therefore
some additional object files need to be
distributed with the kernel package. I do not understand exactly why
yaboot (patched with Amiga partition support)
does not work with separate vmlinux and initrd on Pegasos II so at the
moment zImage.initrd.chrp is needed.
(Does this make sense?) I need a package which allows me to create a
zImage.initrd.chrp from vmlinux and a separate
initrd. Debian has a mkvmlinuz deb which attempts to do this - it
doesn't work for me.
Apparently, some binary .o/.a files that are created during the kernel
build which lie in arch/ppc/boot (CHRP bootstrap, OpenFirmware
utilities) are combined with vmlinux and a ramdisk image to create
zImage.initrd.chrp. I'll try to analyze the build process
a bit more to see what exactly is needed to convert vmlinux +
ramdisk.image.gz into zImage.initrd.chrp, but I thought I'd
throw this out first for the lists wisdom.
I would really like to open this up to the discussion for the users and
developers of Fedora. This feature is very ingrained in a lot of our
muscle memories, deeply embedded in our internal and external
documentation for not just end users but entry level admins, group
admins, and a myriad of folks that really do have a use for the
terminal. Sure you can just as easily get to it by selecting it from a
menu, so that actually goes in my favor. If we're trying to 'protect'
the user, why have it in the menu at all? If the end user that Gnome
seems to care about won't notice, why not leave it so that the people
who have a clue and have the capability of helping out don't get pissed
off by yet another 'lets break history in favor of some "usability" we
think is right for the fabled holy grail of an end user'.
This is yet another move in a long history of Gnome moves that makes me
wish somebody forked gnome a while ago and removed all these stupid
'save the end user from themselves' changes. For god sakes, make a 'end
user safe' UI that has all these things in it, and then make a 'real
user' UI that actually allows work to be done in the way that it has
been done for years.
Jesse Keating RHCE (http://geek.j2solutions.net)
Fedora Legacy Team (http://www.fedoralegacy.org)
GPG Public Key
Was I helpful? Let others know: