beige g3 rage II xf4.0.1 and miBoot
Michael Schmitz
schmitz at zirkon.biophys.uni-duesseldorf.de
Tue Oct 3 00:24:40 EST 2000
> > Which isn't exactly the same because the problem only manifests with
> > conflicting PCI resources set up before the kernel starts. And that -so
> > far- only happened with some Mach64 based Macs.
> >
> > aty128fb not having any problem doesn't prove atyfb can't have these
> > problems on Intel, too.
>
> AFAIK Kostas was talking about the problem that if you don't specify the bus
> ID when using an fbdev driver, X disables the graphics chip because no driver
> claims it. And he wondered why this locks the machine on PPC while it only
> makes the server fail on i386. Right, Kostas?
My answer would be similar - with UseFBDev, the X server handles color
maps and mode switching via the kernel driver (at least for mach64,
didn't check r128). A failed PCI access in a kernel driver results in a
panic on PPC (machine check). It may be caught and handled by a signal on
x86 (simple bus error?).
Michael
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
More information about the Linuxppc-dev
mailing list