[HD3650] Kubuntu: garbage screen

Bug #368187 reported by pureblood on 2009-04-27
14
This bug affects 1 person
Affects Status Importance Assigned to Milestone
xserver-xorg-video-ati (Ubuntu)
Low
Unassigned

Bug Description

I am not sure if my problem has already been reported or not, but it is pretty nasty, so I am reporting it.
Basically, the radeon driver completely hangs my computer when the X server starts. The mouse seems working but the keyboard is completely irresponsive and the screen shows garbage as if the memory had not been initialized and still contains pieces from previous sessions. Connecting through ssh works though, so I can tell that kde 4.2 started fine and everything works ok. There is no sign of errors in the Xorg.0.log file. This happens as well with the installer cd for Jaunty.
I am using a fresh installation of Jaunty, and according to lspci, my graphic card identifier is
VGA compatible controller: ATI Technologies Inc RV635 PRO AGP [Radeon HD 3650]
There are a lot of forums describing different problems, and it took me a long time and tries to find a workaround. What worked was to disable DRI adding the line
Option "DRI" "off"
to the Device section of the /etc/X11/xorg.conf file. I am still confused about it though. I could not find any meaningful log in dmesg or in Xorg.0.log and the system does not seem to notice something is wrong while being basically completely locked. This problem was not present with the Intrepid version of Ubuntu. I also needed desperately to get the radeon driver to work since both radeonhd and fglrx do not support my dual monitor setup.
Bottom line, Jaunty does not work on my machine without very specific tweaking. I wish I could help more. Does this feel like an Xorg bug or a kernel bug?

Scott Howard (showard314) wrote :

I'm not sure if this is your problem, but see Bug #346028 and Bug #285603.

Maybe try this:

Michael Vanderheeren wrote on 2009-03-20: (permalink)

Just recovered my computer from the same problem. The bug is NOT in the usplash package. it's the AMD ATI driver called fglrx. Instead you should use for the moment the opensource driver. The following is a howto:

1. get into recovery mode (when grub loads, press ESC, select recovery mode)
2. choose to get NETROOT from the menu
3. sudo apt-get remove --purge xorg-driver-fglrx
4. sudo apt-get install xserver-xorg-video-ati
4. sudo reboot

Can you attach your Xorg.0.log file and the output from "lspci -vvnn"

Scott Howard (showard314) wrote :
affects: ubuntu → fglrx-installer (Ubuntu)
Changed in fglrx-installer (Ubuntu):
status: New → Confirmed
pureblood (freeseek) wrote :

No no no! This is not a duplicate of bug 346028! I am not using fglrx, I uninstalled and blacklisted it completely, and moreover, the problem happens by booting the jaunty cd installer, which loads the radeon driver by default. I am attaching the files that you asked. I also got these messages on dmesg, which might be related:
[166956.852166] mtrr: no MTRR for e0000000,10000000 found
[166958.278853] agpgart-intel 0000:00:00.0: AGP 3.0 bridge
[166958.278872] agpgart: Xorg tried to set rate=x12. Setting to AGP3 x8 mode.
[166958.278881] agpgart-intel 0000:00:00.0: putting AGP V3 device into 8x mode
[166958.278928] pci 0000:01:00.0: putting AGP V3 device into 8x mode
[166958.297434] [drm] Setting GART location based on new memory map
[166958.297440] [drm] Can't use AGP base @0xf8000000, won't fit
[166958.312326] [drm] Loading RV635 CP Microcode
[166958.312733] [drm] Loading RV635 PFP Microcode
[166958.327685] [drm] Resetting GPU
[166958.446006] [drm] writeback test failed 0 deadbeef
[167032.472527] [drm] Resetting GPU
[167032.568381] mtrr: MTRR 2 not used
[167034.046881] agpgart-intel 0000:00:00.0: AGP 3.0 bridge
[167034.046901] agpgart: Xorg tried to set rate=x12. Setting to AGP3 x8 mode.
[167034.046910] agpgart-intel 0000:00:00.0: putting AGP V3 device into 8x mode
[167034.046957] pci 0000:01:00.0: putting AGP V3 device into 8x mode
[167034.066431] [drm] Setting GART location based on new memory map
[167034.066436] [drm] Can't use AGP base @0xf8000000, won't fit
[167034.081321] [drm] Loading RV635 CP Microcode
[167034.081728] [drm] Loading RV635 PFP Microcode
[167034.096683] [drm] Resetting GPU
[167034.215462] [drm] writeback test failed 0 deadbeef
[167105.874990] [drm] Resetting GPU
[167105.969730] mtrr: MTRR 2 not used

pureblood (freeseek) wrote :
affects: fglrx-installer (Ubuntu) → xserver-xorg-video-ati (Ubuntu)
Bryce Harrington (bryce) on 2009-05-13
summary: - garbage screen with ati driver and Radeon HD 3650 on Jaunty
+ [HD3650] garbage screen
Bryce Harrington (bryce) on 2009-05-13
summary: - [HD3650] garbage screen
+ [HD3650] Kubuntu: garbage screen
Bryce Harrington (bryce) on 2009-05-15
tags: added: corruption
pvautrin (pvautrin) wrote :

I'm having the exact same problem as described by pureblood. Also using HD3650 AGP.
It's not Kubuntu Jaunty specific as I experienced it on Ubuntu 9.04 Amd64 fresh install, Mythbuntu 9.04 Amd64 fresh install and Ubuntu 9.04 live CD. Each time, fglrx is not enabled.
Interestingly, this problem only appeared when I replaced my motherboard from Asus K8N (NVIDIA nForce3) to Gigabyte GA-K8VM800M Rev1.x (VIA K8M800). But it doesn't seem to be related to the mainboard since pureblood is on an intel configuration.

Option "DRI" "off" did indeed restore desktop display but it's more a workaround than a solution.
Option "AGPMode" "8" did not help, and unfortunately my BIOS does not let me change any AGP settings (except voltage which is on default).

The on board video is supposedly disabled by the BIOS in the presence of an AGP card, but I'm not sure if linux correctly ignores it or not always completely...

dmesg, xorg.conf, Xorg.0.log and lspci -vvnn generated with Mythbuntu are in the attachment.

Bryce Harrington (bryce) on 2009-08-13
tags: added: kubuntu
pvautrin (pvautrin) wrote :

I've been experimenting with the r6xx rewrite OSS drivers under development and I still get the same display problem, except that the display is now completely black.
http://www.phoronix.com/forums/showthread.php?t=18072

The keyboard is still responsive though, as I was able to type commands (in the dark) and generate the attached logs. I still get the welcome sound so Ubuntu is loading fine, except for the display.

Hope this helps to identify any commonalities/differences

pvautrin (pvautrin) wrote :

Further to the above tests, I wanted to check if Karmic would solve the issue but it's actually even worse.
I tried the live CD of Karmic Alpha5 for AMD64 and not only the screen stays black, but there seems to be an init sequence repeating over and over (from observing cursor changes) and if you let a few sequences run, Ctrl+Alt+F1 is no longer responsive. On the second try, I pressed quicker and was able to copy the logs (in attachment).

A difference of interest with Karmic is this one additional dmesg line that I noticed since it also appeared on screen just before the black screen:
[ 0.120997] pci 0000:00:00.0: BAR 0: address space collision on of device [0xe0000000-0xe3ffffff]
This same address space is mentioned towards the end when drm fails:
[ 96.398561] [drm] Can't use AGP base @0xe0000000, won't fit

Then, I took my old hardy CD (AMD64), did the same try and everything worked (logs attached as well). So I don't know what differences were introduced since hardy but it could be worth looking into the diffs for extra information.
For the sake of comparison, I captured the ressources tabs of WinXP SP3 device manager, where I saw that the particular [0xe0000000-0xe3ffffff] was used by three devices: the HD3650 AGP, CPU to AGP Ctlr and PCI bus.

I'm not sure what else I can do to give this bug more importance. One thing for sure is with my hardware, I cannot do fresh install of either jaunty or karmic, so this is a pretty severe bug for me, and since it worked with hardy, it's actually a regression. I'm no expert but since the address space collision happens this early in the log, isn't it more a kernel bug than a ati driver bug?

Let me know if I can help...

pvautrin (pvautrin) wrote :

As seen on a similar "address space collision" bug, I attach some more logs of iomem and ioports for each of the tested configurations, which I hope can be of some help
Thanks for reading this

Pauli (paniemin) wrote :

Can you try Option "BusType" "PCIE" in xorg.conf?

Looks like it is possible bug in your main board AGP driver or AGP bridge.

pvautrin (pvautrin) wrote :

Thanks Pauli,
I was recommended this option some time ago and indeed it restores display (forgot to mention it on this thread).
This problem appeared when I changed motherboard. I was able to access xorg.conf of my installation of Jaunty with Ctrl+Alt+F1. But the issue is that I don't think it's possible to edit xorg.conf with a live CD, so this means no fresh install for me.
Moreover, a number of 3D programs/applications fail and I suspect it comes from this workaround situation.
Do you mean it's a bug in the BIOS? Any reason why Windows is not suffering from this?

On Tue, Sep 15, 2009 at 3:16 PM, pvautrin <email address hidden> wrote:

> Thanks Pauli,
> I was recommended this option some time ago and indeed it restores display
> (forgot to mention it on this thread).
> This problem appeared when I changed motherboard. I was able to access
> xorg.conf of my installation of Jaunty with Ctrl+Alt+F1. But the issue is
> that I don't think it's possible to edit xorg.conf with a live CD, so this
> means no fresh install for me.
> Moreover, a number of 3D programs/applications fail and I suspect it comes
> from this workaround situation.
>
Do you mean it's a bug in the BIOS? Any reason why Windows is not suffering
> from this?
>
>
Windows has driers from manufactures who know how their hardware works (or
should know) so windows drivers have good chance of not hitting problems.

Problem is not bios but how AGP bridge and GPU work together when
reading/writing data to system memory with GPU.

>
--
> [HD3650] Kubuntu: garbage screen
> https://bugs.launchpad.net/bugs/368187
> You received this bug notification because you are a direct subscriber
> of the bug.
>

pvautrin (pvautrin) wrote :

I compared again all the logs from hardy, jaunty and karmic and indeed the only differences are about AGP aperture.

Even though size and address are detected correctly in dmesg (and iomem/ioports are in line with WinXP), ...
[ 0.004000] Checking aperture...
[ 0.004000] Node 0: aperture @ e0000000 size 64 MB
[ 0.480127] agpgart-amd64 0000:00:00.0: AGP bridge [1106/0204]
[ 0.483619] agpgart-amd64 0000:00:00.0: AGP aperture is 64M @ 0xe0000000

... the resource allocation fails.
Hardy
[ 31.135720] PCI: Using ACPI for IRQ routing
[ 31.135723] PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report
[ 31.135735] PCI: Cannot allocate resource region 0 of device 0000:00:00.0
Jaunty
[ 0.470669] PCI: Using ACPI for IRQ routing
[ 0.470681] pci 0000:00:00.0: BAR 0: can't allocate resource
Karmic
[ 0.120980] PCI: Using ACPI for IRQ routing
[ 0.120997] pci 0000:00:00.0: BAR 0: address space collision on of device [0xe0000000-0xe3ffffff]
[ 0.121059] pci 0000:00:00.0: BAR 0: can't allocate resource
Jaunty with acpi=off option in grub's menu.lst
[ 0.261932] ACPI: Interpreter disabled.
[ 0.264037] pci 0000:00:00.0: BAR 0: can't allocate resource

So this is probably why drm fails later on
[ 30.201734] [drm] Can't use AGP base @0xe0000000, won't fit

Pureblood, you have the same drm error, can you check if you also have the allocation error before that in your dmesg?

As for the Xorg.0.log, the only error I found is with aperture size detection (32M instead of 64M)
(II) RADEON(0): [agp] 32768 kB allocated with handle 0x00000001

I tried Option "GARTSize" "64" but although 64M get allocated, it still results in a black screen, probably because the issue happens before.

So, is this enough information to determine in which part of the code the bug lies?
If it's really due to xserver-xorg-video-ati (Ubuntu), can we assign the appropriate people now?
If not, should another bug be opened in the correct bug tracker? Would that be bugs.freedesktop.org? bugzilla.kernel.org?

Pauli (paniemin) wrote :

You should increase your BIOS AGP apperture sizes to see if it helps. The
PCI error looks like some conflict in how acpi wants to handle card in PCI
mode which causes problems because agpgart has already reserved the memory
area. (PCI bar is usually defaulting to 256M which is a lot more than 64M
agp setting you have.)

On Wed, Sep 16, 2009 at 11:02 AM, pvautrin <email address hidden> wrote:

> I compared again all the logs from hardy, jaunty and karmic and indeed
> the only differences are about AGP aperture.
>
> Even though size and address are detected correctly in dmesg (and
> iomem/ioports are in line with WinXP), ...
> [ 0.004000] Checking aperture...
> [ 0.004000] Node 0: aperture @ e0000000 size 64 MB
> [ 0.480127] agpgart-amd64 0000:00:00.0: AGP bridge [1106/0204]
> [ 0.483619] agpgart-amd64 0000:00:00.0: AGP aperture is 64M @ 0xe0000000
>
> ... the resource allocation fails.
> Hardy
> [ 31.135720] PCI: Using ACPI for IRQ routing
> [ 31.135723] PCI: If a device doesn't work, try "pci=routeirq". If it
> helps, post a report
> [ 31.135735] PCI: Cannot allocate resource region 0 of device
> 0000:00:00.0
> Jaunty
> [ 0.470669] PCI: Using ACPI for IRQ routing
> [ 0.470681] pci 0000:00:00.0: BAR 0: can't allocate resource
> Karmic
> [ 0.120980] PCI: Using ACPI for IRQ routing
> [ 0.120997] pci 0000:00:00.0: BAR 0: address space collision on of
> device [0xe0000000-0xe3ffffff]
> [ 0.121059] pci 0000:00:00.0: BAR 0: can't allocate resource
> Jaunty with acpi=off option in grub's menu.lst
> [ 0.261932] ACPI: Interpreter disabled.
> [ 0.264037] pci 0000:00:00.0: BAR 0: can't allocate resource
>
> So this is probably why drm fails later on
> [ 30.201734] [drm] Can't use AGP base @0xe0000000, won't fit
>
> Pureblood, you have the same drm error, can you check if you also have
> the allocation error before that in your dmesg?
>
> As for the Xorg.0.log, the only error I found is with aperture size
> detection (32M instead of 64M)
> (II) RADEON(0): [agp] 32768 kB allocated with handle 0x00000001
>
> I tried Option "GARTSize" "64" but although 64M get allocated, it still
> results in a black screen, probably because the issue happens before.
>
>
> So, is this enough information to determine in which part of the code the
> bug lies?
> If it's really due to xserver-xorg-video-ati (Ubuntu), can we assign the
> appropriate people now?
> If not, should another bug be opened in the correct bug tracker? Would that
> be bugs.freedesktop.org? bugzilla.kernel.org?
>
> --
> [HD3650] Kubuntu: garbage screen
> https://bugs.launchpad.net/bugs/368187
> You received this bug notification because you are a direct subscriber
> of the bug.
>

pvautrin (pvautrin) wrote :

Pauli,

Unfortunately there's no such setting in my BIOS (GA-K8VM800M Rev1.x)

Now I'm confused about which memory area you are refering to.

iomem/ioports give the following memory areas (same in WinXP)

d0000000-dfffffff : PCI Bus 0000:01
  d0000000-dfffffff : 0000:01:00.0
    d0000000-dfffffff : radeon
e0000000-e3ffffff : GART
  e0000000-e3ffffff : aperture
e4000000-e5ffffff : PCI Bus 0000:01
  e4000000-e401ffff : 0000:01:00.0
  e5000000-e500ffff : 0000:01:00.0
    e5000000-e500ffff : radeon
  e5010000-e5013fff : 0000:01:00.1
    e5010000-e5013fff : ICH HD audio

03c0-03df : vga+
9000-9fff : PCI Bus 0000:01
  9000-90ff : 0000:01:00.0
    9000-90ff : radeon

And early in Xorg.0.log, I can see
(--) PCI:*(0@1:0:0) ATI Technologies Inc RV635 PRO AGP [Radeon HD 3650] rev 0, Mem @ 0xd0000000/268435456, 0xe5000000/65536, I/O @ 0x00009000/256, BIOS @ 0x????????/131072

So the 64M (e0000000-e3ffffff) is the AGP aperture, while the 256M (d0000000-dfffffff) is a different area that seems to be called video RAM or framebuffer according to these lines
(II) RADEON(0): Detected total video RAM=524288K, accessible=262144K (PCI BAR=262144K)
(II) RADEON(0): [drm] framebuffer handle = 0xd0000000

Nevertheless, you mention a conflict between agpgart and acpi, and the allocation error happens after "Using ACPI for IRQ routing", even with acpi=off option.
So does this mean the bug is in acpi? Can we point the relevant devs to this thread for comments/solution?

Thanks for your time

pureblood, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p xserver-xorg-video-ati REPLACE-WITH-BUG-NUMBER

Please note, given that the information from the prior release is already available, doing this on a release prior to the development one would not be helpful.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs

Changed in xserver-xorg-video-ati (Ubuntu):
importance: Undecided → Low
status: Confirmed → Incomplete
pureblood (freeseek) wrote :

I am sorry, but I have moved away from ATI and NVIDIA graphic cards. I have
had enough of their faulty drivers. Life is much better with Intel. As far
as I am concerned, the bug can be closed. -Giulio

On Tue, Jan 7, 2014 at 7:11 PM, Christopher M. Penalver <
<email address hidden>> wrote:

> pureblood, this bug was reported a while ago and there hasn't been any
> activity in it recently. We were wondering if this is still an issue? If
> so, could you please test for this with the latest development release
> of Ubuntu? ISO images are available from http://cdimage.ubuntu.com
> /daily-live/current/ .
>
> If it remains an issue, could you please run the following command in
> the development release from a Terminal
> (Applications->Accessories->Terminal), as it will automatically gather
> and attach updated debug information to this report:
>
> apport-collect -p xserver-xorg-video-ati REPLACE-WITH-BUG-NUMBER
>
> Please note, given that the information from the prior release is
> already available, doing this on a release prior to the development one
> would not be helpful.
>
> Thank you for your understanding.
>
> Helpful bug reporting tips:
> https://wiki.ubuntu.com/ReportingBugs
>
> ** Changed in: xserver-xorg-video-ati (Ubuntu)
> Importance: Undecided => Low
>
> ** Changed in: xserver-xorg-video-ati (Ubuntu)
> Status: Confirmed => Incomplete
>
> ** Attachment removed: "iomem_ioports.tar.gz"
>
> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/368187/+attachment/716880/+files/iomem_ioports.tar.gz
>
> ** Attachment removed: "18-08-2009 tests.tar.gz"
>
> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/368187/+attachment/677023/+files/18-08-2009%20tests.tar.gz
>
> ** Attachment removed: "bug_368187.tar"
>
> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/368187/+attachment/647921/+files/bug_368187.tar
>
> ** Attachment removed: "karmic_etc.tar.gz"
>
> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/368187/+attachment/714617/+files/karmic_etc.tar.gz
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/368187
>
> Title:
> [HD3650] Kubuntu: garbage screen
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/368187/+subscriptions
>

pureblood, this bug report is being closed due to your last comment https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/368187/comments/16 regarding you no longer have the hardware. For future reference you can manage the status of your own bugs by clicking on the current status in the yellow line and then choosing a new status in the revealed drop down box. You can learn more about bug statuses at https://wiki.ubuntu.com/Bugs/Status. Thank you again for taking the time to report this bug and helping to make Ubuntu better. Please submit any future bugs you may find.

Changed in xserver-xorg-video-ati (Ubuntu):
status: Incomplete → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers