Re: Kernel crash with xf86-video-ati-6.8.0 on -current

[Michael Lorenz <macallan%netbsd.org@localhost>]

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

Hello,

On Jun 17, 2008, at 14:09, Peter Bex wrote:
> On Mon, Jun 16, 2008 at 10:11:29PM -0400, Michael Lorenz wrote:
> > Weird. All genfb does when switching back to WSDISPLAYIO_MODE_EMUL is
> > to redraw the console. Could you please have a look at your Xorg.
> > 0.log and check if X changed any BARs?
>
> What would that look like in the log?  (no idea what a BAR is)

PCI devices have registers that contain base addresses for the card's  
memory or IO resources. These registers are known as Base Address  
Registers, or BARs. You can look at them using pcictl and X will also  
dump them in its log. What I'd like you to do is to use pcictl to  
look up which memory ranges your graphics card uses and then compare  
that to what Xorg uses.

> > If it did and couldn't be arsed to restore them on exit then both  
> > genfb and radeonfb would
> > crash & burn. I added protection against that to machfb, maybe the  
> > other PCI framebuffer drivers could use it too.
>
> Attached is a diff of the outputs of an Xorg run using
> xf86-video-ati-6.6.3nb1 (the working driver) and
> xf86-video-ati-6.8.0nb1 (the broken driver).
>
> I don't know a lot about this stuff, but one thing looks interesting:
> The broken one finds a Linear framebuffer at 0x0000000098000000 while
> the working one finds the framebuffer at 0x98000000.

So one added support for 64bit PCI addresses. Not relevant for any  
Mac we support right now but the right typo at the wrong place might  
screw things up.
Did you get any compiler warnings when building the driver? I  
wouldn't be surprised if the driver implicitly assumes little endian  
64bit types.

> If this is wrong, though, should it be able to trigger a kernel crash?

Not really.
As I said, the only way I can think of how X would be able to crash  
the kernel on exit would be by messing with the graphics controller's  
BARs. Actually I don't see any reason to allow that anymore, apart  
from very few, very specific and very non-mainstream cases NetBSD  
should configure all PCI devices properly even if the firmware  
doesn't, maybe we should just get rid of it and fix the Xserver  
instead if that's really the problem.

have fun
Michael

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iQEVAwUBSFjgEspnzkX8Yg2nAQKyXAf+JO/Dwz8N2mJy0D39DNt+lpb6tVwmpym0
/svoFzE8s4yhl0Ryssqb2Lscj8eN9drnHSrAN0X2MrVCSZQK7LUaRgmCLZS5yPSm
wJjWi8lReQRlJhtDMQOEwXVU+JSr0STlRVbZ5sU+/HYzeQ/0qoAj49vKkoBhRgyY
YFtZT0QLgLLHciyTI7vAtIMjf9KPjKl5uu+7HZUl+y7lt2op4PjT3v1Ibw++Y13s
ZtQm0HrzC5UQKTzMaWvvHorATYIlTvyTNOAKd/5olOacju+KTxzWvBvuO5tihhMs
DnUftBlQwjhWf2sz7MEOCO4wDUOrGkolCWTwmU5MxEaGGytCn2rCXQ==
=HJqK
-----END PGP SIGNATURE-----