-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

On Nov 18, 2006, at 18:22, Johan Wall=E9n wrote:

> Michael Lorenz <macallan@netbsd.org> writes:
>
>> Argh, I knew I forgot something.
>> The original radeonfb didn't allow mmap()ing any PCI resources, so I
>> added support for that but made it optional to avoid breaking the
>> behaviour the author intended.
>> So what's missing in GENERIC is
>> options		RADEONFB_MMAP_BARS
>> then X should Just Work and radeonfb should restore the video mode=20
>> when
>> X exits so the console should be usable again.
>
> With that option, X outputs a little bit more information before it
> fails:
>
> (II) Setting vga for screen 0.
> (II) RADEON(0): MMIO registers at 0xb0000000
> (WW) xf86EnableIO 3
> (II) xf86EnableIO: ffffffff
> (WW) Can't map IO space!
>
> Fatal server error:
> xf86MapVidMem: could not mmap screen [s=3D10000,a=3Db0000000] (Invalid=20=

> argument)

The warning about IO space is harmless - the radeon driver doesn't need=20=

it. The real error though - could be the old radeon-mmap()s-too-much=20
bug.

There are two ways this could have happened.
First ( and easiest to check ) - XFree86 might have changed a BAR for=20
whatever reason, then the mmap() attempt will fail
Second ( and more likely ) - the PCI range at 0xb0000000 isn't really=20
64kB. I remember a bug in the radeon driver ( thought I fixed it in=20
- -current a few months ago ) - the driver would always try to mmap a=20
register range of 64kB even on cards that have only 16kB registers -=20
since we allow mmap()ing only resources that actually belong to the=20
display controller this would fail.

> When radeonfb attaches, it messes up the console completely for a
> moment (strange colours, and it seems like many small copies of the
> console are displayed).  After that, everything looks normal.

radeonfb changes video modes in several steps with plenty of debug=20
output in between, I meant to clean that up but didn't get around to=20
actually do it yet.

> (The console *is* usable after X fails, which was not the case last=20
> year.)

At least something :)
The problem is that many XFree86 ( and Xorg is no better here, quite=20
the opposite actually ) drivers don't properly restore whatever video=20
mode they found when starting - they just assume that everyone uses VGA=20=

text mode and vgahw will take care of that.
Radeonfb just intercepts ioctl(WSDISPLAYIO_SMODE) and restores the=20
video mode when switching back to WSDISPLAYIO_MODE_EMUL ( which happens=20=

when X exits ).

have fun
Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iQEVAwUBRV+dXMpnzkX8Yg2nAQL1+wf+IgseZsornyOiIddp7QzHbQp99T3cIWiI
zOm8nAAn+yjP/9ET8rBtT3vsgSBd/uuHWG0DVeAEUU+T9GDZF+vdO/nQb8UcOPk4
uZ97cPKv+X9M3tNMnQgiiuJxHgw3kqf3AjlF6IyWwYpyPrf0BH8jG23ee4b2BWdp
ZjlwqPdVvNmBWgvZy8rfalIqypo8RlylQi35JiMy6s6h2g7+Ap3Hu8EDxiPNwvfu
M01JBJxXjhb3fc2Un3IDBHDYHJO+b/hkBLwopkwOBx0JtXoUu7bCrCqupHWjn4hW
oXx3WkjMfsFrGLeEUXNulYRU+Xd2B8X2wUCzFAxq4veg7UQT84HtCA=3D=3D
=3DPI0a
-----END PGP SIGNATURE-----