I've updated my KMS test setup to jglisse's drm-next-radeon branch(b1e6187f5ad3c8b836a68009006584337d914e99) and DDX(fba534017e581fcd9b9e49ba0b281fb500f576a7), and now the framebuffer console and X server became highly unstable. The framebuffer console very often causes kernel panics. When I compile the modules into the kernel and boot with radeon.modeset=1, the kernel switches successfully to the DRM provided framebuffer, writes "Initialized radeon 2.0.0 20080528 for 0000:01:00.0 on minor 0" and then panics. I can successfully load the module with modesetting enabled by hand after a full bootup(without an X server). However, the kernel panics whenever I run a gentoo init script from /etc/init.d/. I suspect the crashes are related - right after the kernel boot my initrd would show the password prompt for the LUKS harddrive encryption. If I avoid running one of the scripts and start the X server, the X server complains that it cannot find any mode. Sometimes the framebuffer is restored correctly, and sometimes I get another fault, but the system is still usable via ssh. I'll attach dmesg, Xorg output and lspci output. This is a regression from David Airlie's modesetting kernel and DDX. Those ran stably, and the X server started successfully. Is there a direct relation between these versions? Might a git bisect work?
Created attachment 26064 [details] dmesg output This is after successfully loading radeon.ko with modesetting on and trying to start the X server. The server start failed(no modes), and the framebuffer was *not* restored.
Created attachment 26065 [details] Xorg output Same server start attempt where the dmesg came from
Created attachment 26066 [details] lspci output
It seems that the AGP is not working, does it works if you pass agpmode=-1 at an option to radeon module ?
You're up to something. Yes, agpmode=-1 makes it work. I can run gentoo init scripts without crashes and the X server starts. 3D also works.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/46.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.