On Wed, 6 Nov 2002, Alan Hourihane wrote:
> I've tracked down why the radeon driver and XAA don't get on since
> the addition of *LineLimits code.
>
> Michel added code to ask the loader to try and load v1.1.0 of XAA,
> and if that failed ask for v1.0.0. The code here is fine, but the
> loader in-built into XFree86 isn't.
>
> When unloading the module for 1.1.0 - something goes wrong. So on
> the subsequent load of 1.0.0 the instruction pointers to the
> XAACreateInfoRec() and so on are screwed up, and when we hit that
> call it SEGV's.
>
> The simple fix is to bundle libxaa.a from 4.2.99.2 with the extras.sh
> package. Jose - could you do this ?
>
> A hack to the loader to stop it unloading modules shows that somethings
> broken in the loader. With this hack, we never really unload the first
> instance of the 1.0.0 module, so it works
>
> I'm checking into the loader a little more.
To add a data point to this theory...
I've run into a problem before where reloading a module caused xfree86-gdb
to produce incorrect stack traces. This happened, e.g. if there was a
Load "GLcore" in the config before Load "glx" which meant GLcore was
loaded and then reloaded when the glx module was loaded.
I also had a report where loading extmod twice caused a SEGV -- triggered
on vt switches, iirc. This happened when a user had something like this
in the config:
Load "extmod"
SubSection "extmod"
Option "omit XFree86-DGA"
EndSubSection
Here the SubSection caused extmod to be reloaded. Perhaps the first
problem was a problem in xfree86-gdb, but it seemed in general that
function pointers were getting confused when a module was reloaded.
--
Leif Delgass
http://www.retinalburn.net
---
This sf.net email is sponsored by: See the NEW Palm
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
