Bug 183074

Summary: dri module results in a non-working X on ATI mobility M300
Product: [Fedora] Fedora Reporter: darrell pfeifer <darrellpf>
Component: xorg-x11-drv-atiAssignee: X/OpenGL Maintenance List <xgl-maint>
Status: CLOSED DUPLICATE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhide   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-03-06 22:36:01 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Xorg.0.log when dri module is loaded
none
Xorg.0.log when dri module is commented out (X works, for comparison)
none
Current xorg.conf file (only diff between working and not working is the dri module commented out)
none
rpm -qa of the X files
none
/var/log/messages (no apparent errors here)
none
lspci output none

Description darrell pfeifer 2006-02-26 00:15:39 UTC
Description of problem:

On an Inspiron 9300 with the following chipset:

(--) Chipset ATI Radeon Mobility M300 (M22) 5460 (PCIE) found

X fails to start, leaving a black screen with no access to alternate consoles.

Version-Release number of selected component (if applicable):

I installed FC5 test 3 which contained the problem. I also upgraded to the
rawhide of Feb 25, 2006. Test 2 also had the same problem


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

The X error log shows that it is failing to open /dev/dri/card0

Commenting out the dri module in xorg.conf results in a working X.

system-config-display is overly kind and will re-add the dri module back in,
which results in a non-working X again.

Comment 1 Mike A. Harris 2006-02-27 16:17:39 UTC
After ensuring you have updated to all the latest rpms in fedora devel, please
attach your X server log and config file from the problematic invocation, as
individual uncompressed file attachments using the link below.

Also attach your /var/log/messages from boot time on to the problem occurance,
and the output of:

lspci -vvn
rpm -qa |grep xorg |sort
uname -a

Thanks in advance.

Comment 2 darrell pfeifer 2006-02-28 00:56:18 UTC
Created attachment 125365 [details]
Xorg.0.log when dri module is loaded

Comment 3 darrell pfeifer 2006-02-28 00:57:29 UTC
Created attachment 125366 [details]
Xorg.0.log when dri module is commented out (X works, for comparison)

Comment 4 darrell pfeifer 2006-02-28 00:58:48 UTC
Created attachment 125367 [details]
Current xorg.conf file (only diff between working and not working is the dri module commented out)

Comment 5 darrell pfeifer 2006-02-28 00:59:59 UTC
Created attachment 125368 [details]
rpm -qa of the X files

Comment 6 darrell pfeifer 2006-02-28 01:00:54 UTC
Created attachment 125369 [details]
/var/log/messages (no apparent errors here)

Comment 7 darrell pfeifer 2006-02-28 01:01:53 UTC
Created attachment 125370 [details]
lspci output

Comment 8 darrell pfeifer 2006-02-28 01:04:57 UTC
Updated to latest Fedora devel (no X stuff or kernel changed)
Attached X server log that failed and also an X server log with DRI removed.
Attached the X config file. The only difference between the non-workging and
working versions was commenting out the dri module to get a working X.
Attached the /var/log/messages. It doesn't show anything unusual. I booted at
runlevel 3, did a startx from root. Had to reboot via power button after X fails.
Attached the lspci, and rpm output.

uname -a gives:

Linux localhost.localdomain 2.6.15-1.1977_FC5 #1 Thu Feb 23 14:53:53 EST 2006
i686 i686 i386 GNU/Linux

This kernel version encounted the grubby scriptlet problem in the rpm file, so I
edited in the grub boot paragraph by hand. 


Comment 9 Mike A. Harris 2006-03-06 22:36:01 UTC
Ok, this appears to be a bug in the radeon kernel DRM module.  We're going to
remove r300+ support from the kernel module, as the userland driver is
unstable and also not being shipped...



*** This bug has been marked as a duplicate of 182196 ***