[Xorg-driver-geode] source of -AMD freeze narrowed down to two items

[Gideon Romm]

That would explain why ddcprobe works -> it continues to use vm86, afaik.

-Gadi

On Jan 3, 2008 8:20 AM, Martin-Éric Racine <q-funk at iki.fi> wrote:
> Hello everyone,
>
> After much discussion with Debian/Ubuntu maintainers, one thing transpired:
>
> Bugs experienced on hardware booting off a General Software BIOS might
> be a red herring, because the -AMD code works fine on other BIOSes and
> when compiled against older X server core.
>
> The real cause seems to be that since X server 1.3, the default
> behavior under the hood has changed: whereas we used to employ vm86
> until 1.2, we now employ x86emu since 1.3. This is necessary to, among
> other things, make a one-size-fits-all server core compiled as x86_32
> binary to work on x86_64 kernels.
>
> Julien Cristau thus hinted that tracing xf86emu and finding out what
> makes it fail on General Software might be a more productive approach
> than trying to to nit pick our -AMD driver code. He suggests that
> x86emu simply managed to expose bugs in GSW that make it crash rather
> than recover gracefully.
>
> The end result will probably involve two actions:
>
> 1. fix x86emu to not make it fail on GSW.
> 2. fix GSW to recover rather than fail, when some fishy BIOS probing
> takes place.
>
> The first point involves people on this list, while the second one
> involves General software engineers.
>
> The next step will involve finding a way to integrate the VSA code to
> the LinuxBIOS target for GX/LX, to help hardware vendors who prefer LB
> firmware get a solid performance.
>
> Cheers!
> --
> Martin-Éric Racine
> http://q-funk.iki.fi
> _______________________________________________
> Xorg-driver-geode mailing list
> Xorg-driver-geode at lists.x.org
> http://lists.x.org/mailman/listinfo/xorg-driver-geode
>