[Fwd: xorg Digest, Vol 36, Issue 5]
Regina
regina.apel at gmx.de
Thu Jul 3 02:35:54 PDT 2008
-------- Original-Nachricht --------
Betreff: xorg Digest, Vol 36, Issue 5
Datum: Tue, 01 Jul 2008 10:29:13 -0700
Von: xorg-request at lists.freedesktop.org
Antwort an: xorg at lists.freedesktop.org
An: xorg at lists.freedesktop.org
Send xorg mailing list submissions to
xorg at lists.freedesktop.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freedesktop.org/mailman/listinfo/xorg
or, via email, send a message with subject or body 'help' to
xorg-request at lists.freedesktop.org
You can reach the person managing the list at
xorg-owner at lists.freedesktop.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of xorg digest..."
Today's Topics:
1. DRM 2.3.1, kernel backtrace (Marty Jack)
2. Re: error while running Xorg on ARM platform (Adam Jackson)
3. RE: EXA Migration (Michel D?nzer)
4. Patch to not fork/exec xkbcomp on X Server initialization
(Paulo Cesar Pereira de Andrade)
----------------------------------------------------------------------
Message: 1
Date: Tue, 01 Jul 2008 12:38:14 -0400
From: Marty Jack <martyj19 at comcast.net>
Subject: DRM 2.3.1, kernel backtrace
To: xorg at lists.freedesktop.org
Message-ID: <486A5D76.8000402 at comcast.net>
Content-Type: text/plain; charset=ISO-8859-1
With libdrm 2.3.1 posted this morning,
make
init 3
make check
results in backtrace in kern.log
Thanks for all your good work.
Jul 1 08:41:45 linux kernel: idr_remove called for id=2147483647 which is not allocated.
Jul 1 08:41:45 linux kernel: Pid: 17243, comm: lt-updatedraw Not tainted 2.6.25.9 #1
Jul 1 08:41:45 linux kernel: [<c01f802d>] idr_remove+0x7d/0x160
Jul 1 08:41:45 linux kernel: [<c0250e35>] drm_rmdraw+0x45/0x90
Jul 1 08:41:45 linux kernel: [<c02519a0>] drm_ioctl+0x1a0/0x2c0
Jul 1 08:41:45 linux kernel: [<c0154cfc>] handle_mm_fault+0xfc/0x590
Jul 1 08:41:45 linux kernel: [<c0250df0>] drm_rmdraw+0x0/0x90
Jul 1 08:41:45 linux kernel: [<c0171d28>] vfs_ioctl+0x78/0x90
Jul 1 08:41:45 linux kernel: [<c0171f8b>] do_vfs_ioctl+0x24b/0x290
Jul 1 08:41:45 linux kernel: [<c0164dac>] do_sys_open+0xbc/0xe0
Jul 1 08:41:45 linux kernel: [<c017200d>] sys_ioctl+0x3d/0x70
Jul 1 08:41:45 linux kernel: [<c0102eae>] sysenter_past_esp+0x5f/0x85
Jul 1 08:41:45 linux kernel: [<c0380000>] packet_setsockopt+0x120/0x340
Jul 1 08:41:45 linux kernel: =======================
------------------------------
Message: 2
Date: Tue, 01 Jul 2008 12:53:33 -0400
From: Adam Jackson <ajax at nwnk.net>
Subject: Re: error while running Xorg on ARM platform
To: Azza Kamal <eng_azza_kamal at hotmail.com>
Cc: xorg at freedesktop.org
Message-ID: <1214931213.24769.158.camel at localhost.localdomain>
Content-Type: text/plain
On Tue, 2008-07-01 at 15:44 +0000, Azza Kamal wrote:
> Hello all,
> I nearly have successed in cross cmpiling Xorg for ARM platform but
> unfortunately I got this error when trying to execute Xorg on the
> target board
>
> Fatal server error:xf86EnableIOPorts: Failed to set IOPL for I/O
ARM doesn't even have i/o space, does it?
- ajax
------------------------------
Message: 3
Date: Tue, 01 Jul 2008 19:17:04 +0200
From: Michel D?nzer <michel at tungstengraphics.com>
Subject: RE: EXA Migration
To: Shachar Kaufman <shachar.kaufman at gmail.com>
Cc: xorg at lists.freedesktop.org
Message-ID: <1214932624.22068.159.camel at thor.sulgenrain.local>
Content-Type: text/plain; charset=UTF-8
On Tue, 2008-07-01 at 19:32 +0300, Shachar Kaufman wrote:
> > No straightforward way I'm afraid[0]. It sounds like what you'd want is
> > a variation of "always" which doesn't move pixmaps out of video RAM for
> > fallbacks, which should be easy to add.
>
> But this wouldn't allocate pixmaps in vram? That is, pixmaps would
> still be allocated in system ram and on the first operation -
> migrated, never to return. I would like to avoid the first transfer as
> well.
Then it sounds like you want a migration scheme which just always moves
all the pixmaps to VRAM no matter what.
> > [0] With current EXA, you could plug in your own allocation/migration
> > logic via the CreatePixmap hook and friends, but that seems like
> > overkill here...
>
> That sounds more like it. Suppose I imitate default CreatePixmap
> behavior in the appropriate EXA hook, except that allocation would be
> in vram.
Note that unless you can always fit all pixmaps allocated by clients
into VRAM or can tolerate BadAlloc protocol errors when they don't,
pixmaps will still need to be evicted to system RAM sometimes.
> How would I then hook into migration logic?
The core migration logic is inactive when the driver provides a
CreatePixmap hook, it's all up to the driver then.
--
Earthling Michel D?nzer | http://tungstengraphics.com
Libre software enthusiast | Debian, X and DRI developer
------------------------------
Message: 4
Date: Tue, 01 Jul 2008 14:05:11 -0300
From: Paulo Cesar Pereira de Andrade <pcpa at mandriva.com.br>
Subject: Patch to not fork/exec xkbcomp on X Server initialization
To: xorg at lists.freedesktop.org
Message-ID: <486A63C7.5070607 at mandriva.com.br>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
I talked with Peter Hutterer in the weekend about a patch I was working
on, to not fork/exec xkbcomp.
I worked on it, because after some profiling, it seems xkb initialization
takes around 60% of the time required to start the X Server. Initially I
wrote it as an optional patch for server 1.4 branch, but yesterday I rewrote
it almost from scratch, to not be optional and also adapted it to git
master.
I changed it to not conditional because the involved code is somewhat
of a mess already :-), but the fact that it fallbacks to /tmp to create
the xkbcomp output is a security risk, as it probably will be doing it
as root, and not only would it follow symlinks, it would also remove the
symlink after possibly making some damage, leaving no trace of what was
wrong...
I am posting it for review as there may exist yet problems. I ran with
a 1.4 server and a git-master server and it appears to be correct, but
may be it will not work correctly with multiple input devices, etc.
Also, the code for invocation of xkbcomp from xkb/ddxList.c probably
should
be removed, as xkeyboard-config installation should take care of installing
the *.dir files, and the X Server should really just fail to initialize
xkb if those files don't exist.
There is still a lot of parsing done by the xkb code, that allocates
like 6k strings, and does significantly more realloc's, that maybe could
somehow be optimized to read "compiled" data from the disk, so that
xkb would not be anymore the culprit of most slow X Server initializations.
Paulo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: server-1.4-branch-0001-Don-t-fork-exec-xkbcomp-if-a-cache-file-exists.patch
Type: text/x-patch
Size: 22947 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xorg/attachments/20080701/2db3d268/attachment.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: master-0001-Don-t-fork-exec-xkbcomp-if-a-cache-file-exists.patch
Type: text/x-patch
Size: 18454 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xorg/attachments/20080701/2db3d268/attachment-0001.bin
------------------------------
_______________________________________________
xorg mailing list
xorg at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
End of xorg Digest, Vol 36, Issue 5
***********************************
More information about the xorg
mailing list