Bug 21851

Summary: drm-next-radeon: r250 card unstable (regression)
Product: DRI Reporter: Stefan Dösinger <stefandoesinger>
Component: DRM/RadeonAssignee: Default DRI bug account <dri-devel>
Status: RESOLVED MOVED QA Contact:
Severity: normal    
Priority: medium    
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
dmesg output
none
Xorg output
none
lspci output none

Description Stefan Dösinger 2009-05-21 05:53:33 UTC 
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?
Comment 1 Stefan Dösinger 2009-05-21 05:55:15 UTC 
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.
Comment 2 Stefan Dösinger 2009-05-21 05:55:56 UTC 
Created attachment 26065 [details]
Xorg output

Same server start attempt where the dmesg came from
Comment 3 Stefan Dösinger 2009-05-21 05:57:42 UTC 
Created attachment 26066 [details]
lspci output
Comment 4 Jerome Glisse 2009-05-22 00:35:00 UTC 
It seems that the AGP is not working, does it works if you pass agpmode=-1 at an option to radeon module ?
Comment 5 Stefan Dösinger 2009-05-22 02:27:24 UTC 
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.
Comment 6 Martin Peres 2019-11-19 08:05:38 UTC 
-- 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.