Subject: Re: The radeon framebuffer device panics init (on i386)
To: Vincent <email@example.com>
From: Michael Lorenz <firstname.lastname@example.org>
Date: 12/19/2006 02:08:19
-----BEGIN PGP SIGNED MESSAGE-----
On Dec 19, 2006, at 01:51, Vincent wrote:
> Michael Lorenz hat diese W=C3=B6rter geschrieben:
>> Radeonfb has absolutely nothing to do with X.
> Well, to some extent, it does. Just because it has to do with graphics=20=
Not really. XFree doesn't know or care about radeonfb, it only ever=20
makes a difference if you want to use the wsfb driver ( read=20
unaccelerated, dumb but more or less hardware-independent framebuffer=20
driver for XFree )
>> Yup, happens when no console output device attaches.
> Yet, I cannot fathom why a failing radeonfb should prevent wscons to=20=
> attach to vga!
Because radeonfb attached where vga would attach. They can't both muck=20=
around with the same device at the same time. Only this time radeonfb=20
aborted while attaching so vga didn't get its chance.
>> Hard to tell. For some reason radeonfb can't map your BIOS and barfs=20=
>> about that - not sure why.
>> Do you have 'options RADEON_BIOS_INIT' in your kernel? Try without =
> I try with and without. Same effect.
This is strange...
>> Then, please post the output of 'pcictl pci1 dump -d 0' - this should=20=
>> dump your graphics controller's PCI config space - might contain a=20
>> hint why the BIOS couldn't be mapped.
> If you say it might help=E2=80=A6
Indeed it does:
> Expansion ROM Base Address: 0x00000000
So that's why your video BIOS can't be mapped - no sane address in the=20=
Not sure why radeonfb would insist on trying to map it even without=20
RADEON_BIOS_INIT though, it shouldn't really need it.
I'll have a look at the driver, this shouldn't happen when it's not=20
going to use the BIOS.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
-----END PGP SIGNATURE-----