On Friday 10 June 2005 11:09, Jon Smirl wrote: > Linux only allows one device driver to attach to a device like the > radeon. Right now this driver is radeonfb. When DRM loads it uses the > radeon hardware without attaching to it and informing the kernel. What > DRM is doing is not compatible with hotplug. DRM enables the > framebuffer without reserving it's PCI address. Since the kernel > doesn't know about this a hotplug device can get assigned an address > on top of the framebuffer. That would cause a hardware conflict and > probably result in a reboot. > > My solution to this is to make radeon DRM depend on radeonfb. radeonfb > properly attaches to the device and marks everything in use. I chose > this method because Xegl wants radeonfb loaded and this scheme has > minimal code impact.
This seems like an odd solution. Why wouldn't you just enable multiple drivers to attach to the device? > Can everyone please try this patch out and see if loading radeonfb > causes any problems on your system. Having radeonfb loaded on x86 is > not a normal case. Radeon Xegl is going to depend on having both > radeon and radeonfb loaded so I need to know if this will cause > problems. Last time I tried it, the console went blank (except for the cursor) somewhere during runlevel 3 bringup, so I rebooted blind and went back to a kernel without radeonfb. > For a quicker check you can just do modprobe radeonfb from a console > (not a xterm). That will load the current radonfb driver but it will > also blank your console font. The blank is from a problem in radeonfb > that is fixed in the patch. Type /sbin/setsysfont and the font will be > restored and you can then check for any other issues. ~ % ls /sbin/setsysfont ls: /sbin/setsysfont: No such file or directory Where do I get this utility, and when can I expect this fix in a stable kernel? - ajax
pgp0wEsYcLYW4.pgp
Description: PGP signature
