Created attachment 23832 [details] Xorg.0.log HD 3650 Forwarded from Ubuntu bug https://bugs.launchpad.net/bugs/341681 Starting X just gives a black screen, and the log is filling up with: (EE) RADEON(0): Idle timed out, resetting engine... A forum post (from another guy) indicates that removing 2 GB (from 4 GB) of RAM from the laptop fixes a similar issue with -radeonhd, but this has not been confirmed by the reporter on -ati. Another thing that looks contradicting in the log: (EE) RADEON(0): [dri] RADEONDRIGetVersion failed to open the DRM [dri] Disabling DRI. ... (==) RADEON(0): Will attempt to use R6xx/R7xx EXA support if DRI is enabled. (**) RADEON(0): Using EXA acceleration architecture He also tried to force XAA in xorg.conf: (**) RADEON(0): Option "AccelMethod" "XAA" but it does not take effect. Is it supported? The driver is built from git 945ccbbd4fa2b65ccdfb23716c178c95b036734d
Does: Option "DRI" "FALSE" in the device section of the config fix the problem?
Created attachment 23833 [details] [review] posible fix Does this patch help?
According to: https://lists.ubuntu.com/archives/jaunty-changes/2009-March/007167.html Kernel support is coming soon, now that the git snapshot of xf86-video-ati is in. But probably the driver shouldn't fail in the case that kernel lacks the needed drm bits. [right: a proposed patch was already offered while I'm writing this] XAA won't be supported on r600/r700 AFAIK.
(In reply to comment #3) > Kernel support is coming soon, now that the git snapshot of xf86-video-ati is > in. But probably the driver shouldn't fail in the case that kernel lacks the > needed drm bits. [right: a proposed patch was already offered while I'm writing > this] This case actually has nothing to do with the DRI per se, it's that the engine isn't idle for whatever reason in this case. Since we aren't using the engine when the dri is disabled and don't really know what state it's in, we can ignore it.
I was part of the original bug submission that was pushed by Tormod. I think my log was that one he attached to this bug. I am new to linux, but I have been struggling with this issue for over a month now. If I can help by trying out fixes, and sending information back, please let me know. Thank you.
Created attachment 23839 [details] Xorg.0.log with 2GB RAM (Ubuntu 8.10)
I just attached an Xorg.0.log from a successful startup with only 2 GB of RAM installed. This system is identical to the system that produced the first log (Toshiba Satellite A355-S6935), I just removed a stick of RAM. Comparing the two logs shows that video memory is detected incorrectly when 4 GB of RAM are installed. The machine has 512 MB of video memory, but when 4 GB of RAM are installed 4194303K of video RAM are detected.
Created attachment 23924 [details] Xorg.0.log after Jaunty update. Still not screen. Different error. I upgraded Jaunty and the ATI Mobility Radeon HD 3650 is still not functioning. The Xorg.0.log is attached. Thank you.
Created attachment 23925 [details] [review] workaround (In reply to comment #8) > Created an attachment (id=23924) [details] > Xorg.0.log after Jaunty update. Still not screen. Different error. > > I upgraded Jaunty and the ATI Mobility Radeon HD 3650 is still not functioning. > Weird. the MC is busy, This is also probably related to why you were getting engine idle errors previously. Is this from a fresh boot or had you been running fglrx previously? This patch will work around this mc idle, but it may have problems when writing the new fb location. Let me know how it goes.
That last Xorg.0.log was the .old. After trying to boot with "ati" in the xorg.conf, I have to boot in safe mode, drop to command line, and add "vesa" back to xorg.conf. Then I open the Xorg.0.log.old and attach it. I haven't tried fglrx in a while. You'll have to forgive me. I am not that experienced with linux. Can you describe to me how to apply the patch you attached. Thank you.
Jeff, I'll make patched packages in my PPA.
(In reply to comment #11) > Jeff, I'll make patched packages in my PPA. > Great. Thanks. I'll watch for them.
Created attachment 23933 [details] New PPA installed - Xorg.0.log - HD 3650 I installed the new driver from the PPA. The Xorg.0.log is attached. It booted to an unresponsive black screen. Thanks.
Created attachment 23943 [details] HD 3650 - ati works after removing 2GB (out of 4GB) of RAM The ati driver for the ATI Mobility Radeon HD 3650 works after removing 2GB of RAM. The Xorg.0.log is attached. Someone else posted this the other day. Does this shine any light on the issue with this card? Thank you.
It's been quiet on this. Is there any new information on this bug? I'm still carrying around half of my RAM. Thank you.
Alex, I vaguely remembered that we had the same issue with radeonhd with an Asus Laptop, that only worked with only 2GB installed. Now, found on our wiki http://www.x.org/wiki/radeonhd : Newer ASUS laptops with more than 2GB of memory. There are several reports about getting RadeonHD (or any graphics driver) to work on Linux on ASUS laptops with M72, M82 and possibly other chipsets when more than 2GB of RAM is installed. This is very likely not a graphics driver issue. For now the only work around is to reduce the amount of RAM installed to 2GB or less. AFAIK we still weren't able to find a reasonable solution for that. Just for information
Thanks Matthias. I wonder if it's an mtrr issue with the bios? Are there any options in your bios related to memory setup?
I tested again with all 4GB of RAM. It still boots to an unresponsive black screen. The Xorg.0.log is attached. Regarding the BIOS, I do not see any options for adjusting RAM. I tried all the menus I could access, but I did not see anything. The BIOS I am running seems to have very few options. It is Phoenix SecureCore Setup Utility - BIOS version 1.7. Thank you.
Created attachment 24676 [details] Testing ATI driver with 4GB of RAM.
The bios is setting up the mtrrs wrong. The fix is to enable the MTRR cleanup support (CONFIG_MTRR_SANITIZER) option in the kernel: http://lists.opensuse.org/radeonhd/2009-05/msg00070.html
this is a bios issue that needs to be fixed in the kernel.
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.