system freeze when using ati radeon 7000 with xorg "ati" driver
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| Envy |
Undecided
|
Unassigned | ||
| xserver-xorg-driver-ati |
Fix Released
|
Medium
|
||
| xorg (Ubuntu) |
Medium
|
Unassigned | ||
| xserver-xorg-driver-ati (Ubuntu) |
Undecided
|
Unassigned | ||
| xserver-xorg-video-ati (Ubuntu) |
Medium
|
Unassigned |
Bug Description
Ubuntu freezes randomly when using the radeon or ati Xorg driver with Radeon 7000 cards. After disabling dri in Xorg.conf the system does not freeze anymore.
This happens in Hoary, Breezy, Dapper.
I have some additional information.
What is happening is that X is trying to open /dev/dri/card0. For some weird
reason the open fails. (Giving an unknown error code 999 according to the
logs.) Instead of failing gracfully and not loading dri, it trys to go on from
there and nothing comes up.
I am attaching the log file, a list of the permissions on the device and a copy
of dmesg from that system.
I have tested the 8k stacks issue and it is not the cause of this problem.
Created an attachment (id=346)
Radeon 7000 Xorg.0.log with failure error messages.
Here is the log file for the Radeon 7000 dri problem. Look for /dev/dri/card0
to find where it is choking.
Created an attachment (id=347)
Listing on the permissions for /dev/dri/card0
Here are the permissions listed for /dev/dri/card0. They appear to be correct.
Created an attachment (id=348)
The dmesg log from the system with the problem
This is the dmesg log from the system with the problem. I suspect it is a bug
with the SiS AGP chip on the motherboard, but I am not certain.
I think I have a cause now.
The SiS 741 AGP chipset is not supported. Instead of figuring that out and
giving an "unsupported message", it just goes out to lunch.
As Bender would say "We're boned!".
|
#7 |
Could you remove the agp from your kernel and try running your Radeon in PCI
mode? You may need to set Option "BusType" "PCI" in the Driver section of
xorg.conf, but probably not at this point. If that resolves the issue, I'll
close the bug assuming that it's AGP at fault like you say.
I am having this issue on my system with a Radeon 9200SE, but only with Load
"glx"; "dri" by itself is fine, but that doesn't enable the GLX extention.
The display freezes and I suspect the system itself continues to run
(network/HD activity; I should test w/ audio playing, but I don't want to
reboot ATM).
Interestingly, my PC is similar to the one nastos said he had working...
Motherboard: Asus K8V
CPU: Athlon64 3200+
AGP Bridge: 0000:00:00.0 Host bridge: VIA Technologies, Inc. VT8385 [K8T800
AGP] Host Bridge (rev 01)
I think this makes it unlikely that the problem is that particular AGP
bridge...
dmesg output:
+mtrr: 0xe8000000,
+[drm] Initialized radeon 1.11.0 20020828 on minor 0: ATI Technologies Inc
RV280 [Radeon 9200 SE]
+mtrr: 0xe8000000,
+agpgart: Found an AGP 3.5 compliant device at 0000:00:00.0.
+agpgart: Putting AGP V3 device at 0000:00:00.0 into 0x mode
+agpgart: Putting AGP V3 device at 0000:01:00.0 into 0x mode
+[drm] Loading R200 Microcode
Other relevant debug info will be attached... but I'm suspecting the 0x
stuff...
Created an attachment (id=475)
gdb attach & bt of X
Created an attachment (id=476)
kdm log
Created an attachment (id=477)
Xorg logfile
|
#13 |
(In reply to comment #2)
> I have some additional information.
>
> What is happening is that X is trying to open /dev/dri/card0. For some weird
> reason the open fails. (Giving an unknown error code 999 according to the
> logs.) Instead of failing gracfully and not loading dri, it trys to go on from
> there and nothing comes up.
>
> I am attaching the log file, a list of the permissions on the device and a copy
> of dmesg from that system.
>
> I have tested the 8k stacks issue and it is not the cause of this problem.
does the error message go away in case you don't specify the BusID ?
/* here it does */
All of these reports look like AGP driver bugs to me. The first two are SiS
chipsets resulting in hangs. The third is a newer VIA AGPv3 chipset with a v3
card, with visible agp issues in the dmesg ("Putting AGP V3 device at
0000:00:00.0 into 0x mode"). I would suggest that these issues get reported to
the linux kernel bugzilla.
magilus (magilus) wrote : | #15 |
Hi,
my system freezed often when using gnome since I upgraded to hoary. I have an
AMD Athlon XP 2600+, 512 MB takems memory, an CLUB-3D Radeon 7000 and a PC-Chips
M848A.
I exchanged everything excluding my graphic card, my motherboard and my cpu.
Now, I edited my /etc/X11/xorg.conf file and changed the Driver entry in the
Device section from "ati" to "vesa". Now my system doesn't freeze. That's
because I think that it's a bug in the xorg package in Ubuntu.
It would be great when you fix it.
Thanks,
Martin
John Steele Scott (toojays) wrote : | #16 |
This sounds like what I'm encountering. The lockup seems random, but so far we
have not been able to go for more than an hour or so without it occuring. I have
tried a Radeon 7000 and a Radeon 7200 in this system; both cause a lockup. With
a Radeon 9200, the problem does not occur.
The system is an Athon 64 3200+, but we are running Hoary x86 on it. Motherboard
is an Epox E9NDA3+, which uses the nForce 3 chipset. I will attach a sample
Xorg.log and xorg.conf. It didn't seem to me that there were any clues in the
Xorg.log.
Martin: It might be interesting to know if you can reproduce the lockup if you
switch back to the ati driver, but set the UseFBDev option in xorg.conf.
(Unfortunately that's going to help me, as this system uses MergedFB.)
John Steele Scott (toojays) wrote : | #17 |
Created an attachment (id=2490)
xorg.conf used with Radeon 7000/7200
John Steele Scott (toojays) wrote : | #18 |
Created an attachment (id=2491)
Xorg.log when running Xorg with a Radeon 7000
magilus (magilus) wrote : | #19 |
Hi,
I just edited my xorg.conf, added UseFBDev, changed the driver to "ati" again
and now the system isn't freezing anymore.
Thanks,
Martin
magilus (magilus) wrote : | #20 |
Hi,
it isn't right what I just said. It freezed after adding comment #4 so the
UseFBDev option in xorg.conf didn't help at my computer.
Martin
David Vanderson (david-vanderson) wrote : | #21 |
I believe I'm hitting this bug as well. The system freezes (no kernel panic or
anything) shortly after starting the X server with the "ati" driver. Using the
"vesa" driver hasn't shown this. I have only found one possible clue. With the
"ati" driver, I start gdm. Then at the login screen I hit ctrl-alt-backspace.
I get this in /var/log/messages:
Jun 21 10:58:55 neasw3 kernel: __iounmap: bad address ffffff0010223000
Each time I ctrl-alt-backspace I get the same error with the same address. With
the "vesa" driver, I think I got this once, but not in response to anything, and
I can't seem to replicate it. Hopefully soon I'll get some time to try newer
xorg versions and other things. Is there any combinations of kernels and
whatnot that would be more useful for me to test?
uname -a : Linux neasw3 2.6.10-5-amd64-xeon #1 SMP Tue Jun 7 08:58:02 UTC 2005
x86_64 GNU/Linux
lspci :
0000:00:00.0 Host bridge: Intel Corp. Server Memory Controller Hub (rev 09)
0000:00:02.0 PCI bridge: Intel Corp. Memory Controller Hub PCI Express Port A0
(rev 09)
0000:00:1d.0 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #1
(rev 02)
0000:00:1d.1 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #2
(rev 02)
0000:00:1d.7 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB2 EHCI
Controller (rev 02)
0000:00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev c2)
0000:00:1f.0 ISA bridge: Intel Corp. 82801EB/ER (ICH5/ICH5R) LPC Bridge (rev 02)
0000:00:1f.1 IDE interface: Intel Corp. 82801EB/ER (ICH5/ICH5R) Ultra ATA 100
Storage Controller (rev 02)
0000:00:1f.2 IDE interface: Intel Corp. 82801EB (ICH5) Serial ATA 150 Storage
Controller (rev 02)
0000:01:00.0 PCI bridge: Intel Corp. PCI Bridge Hub A (rev 09)
0000:01:00.1 PIC: Intel Corp. PCI Bridge Hub I/OxAPIC Interrupt Controller A
(rev 09)
0000:01:00.2 PCI bridge: Intel Corp. PCI Bridge Hub B (rev 09)
0000:01:00.3 PIC: Intel Corp. PCI Bridge Hub I/OxAPIC Interrupt Controller B
(rev 09)
0000:02:04.0 Ethernet controller: Intel Corp. 82541GI/PI Gigabit Ethernet
Controller (rev 05)
0000:04:03.0 Ethernet controller: Intel Corp. 82541GI/PI Gigabit Ethernet
Controller (rev 05)
0000:04:0d.0 VGA compatible controller: ATI Technologies Inc Radeon RV100 QY
[Radeon 7000/VE]
I'll attach dmesg output and /var/log/
David Vanderson (david-vanderson) wrote : | #22 |
Created an attachment (id=2810)
dmesg showing restarting gdm
David Vanderson (david-vanderson) wrote : | #23 |
Created an attachment (id=2811)
Xorg.0.log with vesa driver
David Vanderson (david-vanderson) wrote : | #24 |
Created an attachment (id=2812)
Xorg.0.log with ati driver
This is curios:
(WW) RADEON(0): Bad V_BIOS checksum
Daniel Stone (daniels) wrote : | #25 |
the 'bad VBIOS checksum' warning isn't anything to worry about. the fix for
this has been committed to X.Org HEAD, so should be in Breezy soon.
magilus (magilus) wrote : | #26 |
Not fixed in Breezy yet.
I have the same problem, mine only happens on SMP kernels. I used to have this
problem with fedora but they solved there. I followed the bug in the fedora
bugzilla system when (I just recently turned to the Ubuntu). Also I think that
the bug 15433 (http://
this one.
Adachiworld (adachiworld) wrote : | #28 |
I have the same problem.. here
https:/
same problem and they seem to have fixed it.. I'am a newbie so I don't really
know what to do.. This seems also an interesting page:
https:/
Thanks
Daniel Stone (daniels) wrote : | #29 |
fixed in dapper
Is there a possibility to backport the solution to "breezy"? How can I get my
machine to work now?
magilus (magilus) wrote : | #31 |
The bug also appears in Dapper Drake.
magilus (magilus) wrote : | #32 |
The bug still appears in Dapper, it is a must fix!
Changed in xorg: | |
status: | Unconfirmed → Confirmed |
magilus (magilus) wrote : | #33 |
Just reopened upstream bug report: https:/
magilus (magilus) wrote : | #34 |
Disabling the dri solves the problem. Any chance to disable dri automatically when a radeon 7000 card is detected?
(In reply to comment #14)
> All of these reports look like AGP driver bugs to me. The first two are SiS
> chipsets resulting in hangs. The third is a newer VIA AGPv3 chipset with a v3
> card, with visible agp issues in the dmesg ("Putting AGP V3 device at
> 0000:00:00.0 into 0x mode"). I would suggest that these issues get reported
to the linux kernel bugzilla.
i have a onboard radeon 7000M (IBM xSeries 226 - appears to be PCI in
documentation). Following your comments i have compiled the 2.6.15.4 with
agpgart modules all disabled. With DRI and GLX extensions loaded, the Xorg 6.9
(Debian testing) the screen get's black (no image). Without the glx extensions,
it runs but no DRI.
I have experienced a lot lockups with this video onboard in this machine. I have
tried a lot configurations and i just get it to run secure (but a lot slow in
windows management, especially with a complex wallpaper) without DRI and GLX.
Created an attachment (id=4619)
dmesg
the dmesg after the Xorg loaded with dri and glx loaded
Created an attachment (id=4620)
xorg.conf
My xorg.conf
Created an attachment (id=4621)
Xorg.0.log
My Xorg process get full CPU usage with DRI.
joel@venus:
23:17:21 up 16 min, 1 user, load average: 1,01, 0,79, 0,38
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
joel pts/0 192.168.0.11 23:05 0.00s 5.07s 0.12s w
joel@venus:
This is the system iddle.
top - 23:18:07 up 17 min, 1 user, load average: 1.00, 0.82, 0.40
Tasks: 78 total, 2 running, 76 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.4% us, 23.9% sy, 0.0% ni, 75.2% id, 0.5% wa, 0.0% hi, 0.0% si
Mem: 2075672k total, 150028k used, 1925644k free, 2788k buffers
Swap: 1004052k total, 0k used, 1004052k free, 74868k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
4653 root 25 0 37632 5204 3196 R 93.8 0.3 7:40.19 Xorg
4769 joel 15 0 2196 1020 768 R 8.5 0.0 0:00.32 top
1 root 16 0 1924 648 556 S 0.0 0.0 0:00.48 init
2 root RT 0 0 0 0 S 0.0 0.0 0:00.00 migration/0
3 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/0
4 root RT 0 0 0 0 S 0.0 0.0 0:00.00 migration/1
5 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/1
Based with some bugs related to multi processor, i compiled a new kernel without
SMP: still locks with dri and glx.
Them i disabled the HyperThreading in the BIOS, and with this new kernel (non
SMP) the problem appears to have disappeared. Now it's working.
Changed in xorg: | |
assignee: | daniels → nobody |
description: | updated |
Changed in xserver-xorg-driver-ati: | |
status: | Confirmed → Fix Released |
Changed in xserver-xorg-driver-ati: | |
status: | Fix Released → Confirmed |
Changed in xserver-xorg-driver-ati: | |
assignee: | nobody → me-phoks |
Changed in xserver-xorg-driver-ati: | |
assignee: | me-phoks → nobody |
status: | Confirmed → Rejected |
status: | Rejected → Needs Info |
magilus (magilus) wrote : | #113 |
Okay, a .deb which includes the patch from http://
http://
Diffs and soucecode are available from here: http://
The packages are for Edgy only.
magilus (magilus) wrote : | #114 |
Benjamin Herrenschmidt: The patched package froze my system when running "glxgears" ( I did not saw the gears, there was only a black screen in the window, then it froze )
magilus (magilus) wrote : | #115 |
Lol, sorry. I was confused.
For me, it does not freezy globally with and without your patch since I upgraded to Edgy. It would be interesting to hear from Sylvek if the patch solves the issue or not solves the issue.
But when I run glxgears it crashes using the patch and not using the patch. But I think that this is an other problem since my system does not freeze at my everyday work anymore.
ok thks for everything! .. i'm going to try your path now with basic xorg configuration.
Driver "ati" and BusID "PCI:1:0:0" only.
presently the glxgears works but i get this warning.
libGL warning: 3D driver claims to not support visual 0x4b
Ok, all of those 3d/glxgears problems are unrelated. If you have a specific problem, please open a separate report (and feel free to CC me). At this point, we are trying to chase down the long standing random system lockup issue that has been plaguing M6, M7 and radeon 7xxx users.
The patch seem indeed confirm the reported lockups with M6, M7 and radeon 7000 so far. David will probably do a new stable release of the radeon driver including it. I recommend that Ubuntu updates dapper and edgy drivers with that fix and close this bug.
since september, 18th my xorg don't crash ...
Jacob Winski (winski) wrote : | #122 |
September 22, 2006. As of this day, my computer *still* crashes from this bug.
OS: Ubuntu Dapper
Video Card: Radeon Mobility M6 LY
xserver-
xserver-
(newest as of today)
xorg.conf (truncated):
Driver "ati"
BusID "PCI:1:0:0"
Option "DynamicClocks" "on"
...
Identifier "Generic Monitor"
Option "DPMS"
HorizSync 28-49
VertRefresh 43-72
Sylvek, what version of xorg are you using? What OS are you using? Any help would be appreciated.
magilus (magilus) wrote : | #123 |
The bug seems to be fixed in *Edgy*, not in Dapper. As a temporary solution you may want to disable dri.
Disabling DRI will not fix it. It will still occasionally lockup (depending on the machine and other ramdom circumstances). Ubuntu should definitely apply this patch on dapper. Dave is about to release a new stable version of the ATI driver which includes it too.
i attach my Xorg -version
i use Ubuntu Edgy under Sony VIAO Z1RMP
Changed in xserver-xorg-driver-ati: | |
importance: | Untriaged → Medium |
status: | Unconfirmed → Confirmed |
Jacob Winski (winski) wrote : | #126 |
I just wanted to confirm that disabling DRI will NOT fix this bug. Hopefully someone can put the patched version of the ati drvers in the ubuntu repositories.
I confirm that disabling DRI do not fix this bug. ^ ^
but since i path my ati driver all works properly.
Martijn Vermaat (mvermaat) wrote : | #128 |
We might still be looking at different bugs here. For me (on a system with Radeon 7200), the lockups were happening quite often (most sessions within a few minutes), but disabling DRI did fix the problem entirely. No lockups at all after disabling DRI (for a few months).
magilus (magilus) wrote : | #129 |
>We might still be looking at different bugs here. For me (on a system with >Radeon 7200), the lockups were happening quite often (most sessions within a >few minutes), but disabling DRI did fix the problem entirely. No lockups at all >after disabling DRI (for a few months).
same here. additional, the ati driver in edgy fixed the problem without the patch.
Binh Trinh (beango) wrote : | #130 |
seems that the patch solved my freezing problems in edgy
thanks martin for providing the binaries
Jacob Winski (winski) wrote : | #131 |
any hope of seeing this fix in dapper?
Changed in xserver-xorg-video-ati: | |
status: | Needs Info → In Progress |
due to a simple misunderstanding with upstream, the patch for this bug has been applied with yesterday upload of the ati driver in edgy.
Changed in xserver-xorg-video-ati: | |
status: | In Progress → Fix Released |
Jacob Winski (winski) wrote : | #133 |
Backport to Dapper of xserver-
-> Considering xserver-xorg-dev (>= 1:1.1.1)
Tried versions: 1:1.0.2-0ubuntu10.4 1:1.0.2-0ubuntu10
-> Does not satisfy version, not trying
E: Could not satisfy build-dependency.
So my guess is that this fix will not make it into Dapper? I was hoping that I would not need to upgrade to a non-stable release.
The edgy package is based on X 7.1 and can't just be used 'as-is' on 7.0, but the fix itself is a simple patch that could easily be applied to dapper version of the driver
Paul Dufresne (paulduf) wrote : | #135 |
I find it hard to tell if bug #151219 is a duplicate.
151219 is linked to upstream bug:
https:/
Someone more knowledgeable could confirm it is a duplicate?
Robert Knight (robertknight) wrote : | #136 |
> but the fix itself is a simple patch that could easily be applied to dapper version of the driver
The Xorg 7.1 code looks quite different from the 7.0 code to me. Anyhow, a stable version of the Xorg 7.0 ati driver which includes the memory map fixes has been published upstream (version 6.5.8.1). I would really appreciate it if that could be made available for Ubuntu Dapper. Seriously, I will be willing to make a charitable donation a developer's beer fund.
Can I also request that the importance of this bug be raised. This can lock up affected PCs (of which there are many in existence) frequently.
I am using Kubuntu Dapper as a platform for KDE development and something in the latest Qt release seems to trigger this lockup very frequently.
Switching to EXA accelerations helps - although EXA support seems to have many rough edges in the X.org 7.0, so much so that using it for day to day desktop work can be a little painful.
Robert Knight (robertknight) wrote : | #137 |
I have discussed the matter with David Airlie, who maintains the xorg ati driver. He told me that Ubuntu have added quite a number of patches to the ati driver, and it isn't a straightforward matter - for someone who is not familiar with the X code at least (ie. myself) - to find a patch in the x.org git tree and apply it to the Ubuntu version of the driver.
I did have a look at both codebases, and I really was way out of my depth.
The short story is that I upgraded to 'Edgy' where the issue has been fixed, much as I would have preferred a "safe and stable" release on my main machine.
This bug is very serious, and I strongly suggest upgrading its severity.
Benjamin Herrenschmidt (benh-kernel) wrote : Re: [Bug 16873] Re: system freeze when using ati radeon 7000 with xorg "ati" driver | #138 |
On Thu, 2006-11-16 at 16:29 +0000, Robert Knight wrote:
> I have discussed the matter with David Airlie, who maintains the xorg
> ati driver. He told me that Ubuntu have added quite a number of patches
> to the ati driver, and it isn't a straightforward matter - for someone
> who is not familiar with the X code at least (ie. myself) - to find a
> patch in the x.org git tree and apply it to the Ubuntu version of the
> driver.
>
> I did have a look at both codebases, and I really was way out of my depth.
> The short story is that I upgraded to 'Edgy' where the issue has been fixed, much as I would have preferred a "safe and stable" release on my main machine.
>
> This bug is very serious, and I strongly suggest upgrading its severity.
well, I've told ubuntu folks I know my feeling on the matter several
times. I beleive that they should use the latest stable driver release
in dapper too...
Ben.
Nicola Ferralis (feranick) wrote : | #139 |
I hate to sound redundant. As much as I love to use Ubuntu, I need to have Dapper functional on my Poweredge server (running ATI). Edgy doesn't provide me the LTS, so I simply can't upgrade. Sure, I can run in vesa, it's a server anyway. But at that point do I really need to run Ubuntu?
I hope the fix will applied to Dapper soon. Otherwise, what's the point of advertise that release as having "Long Term Support"?
Paul Dufresne (paulduf) wrote : | #140 |
I am afraid, as I did too before, misunderstand the meaning Ubuntu give to Long Term Support.
Please read:
https:/
Markus Kienast (elias1884) wrote : | #141 |
The bug persists in Dapper!
Vaio - PCG C1 MHP
Radeon Mobility M6 LY
Driver ati + dri (standard installation)
Will try non-dri and stuff soon.
Unfortunately I can't tell with which update this bug appeared, but it was in Sept. 2005.
By they way, buttons in gnome show some distortion sometimes, which seems to be related to this bug. Ever since I saw this distortion, my system is freezing every once in a while. The distortion is regular. Black or gray pixels every 10-20 pixels in both axis. I will be more specific later and try to provide a screenshot.
This really should be fixed. Especially for the server people. I have a Poweredge server as well and I can't connect to it any more after the last update. This was a Debian sarge to etch update = xf86 to xorg update, so this bug seems to be hitting not just Ubuntu.
Anyhow, I would like this to be fixed in Dapper also!
I understand long term support differently either!
PS.: It took me until now to figure out, that it was not my hardware's fault. I bought a new Laptop in the meantime because I believed otherwise and I rely on Linux.
Tormod Volden (tormodvolden) wrote : | #142 |
Modified the patch from comment #83 to apply cleanly on Dapper.
Tormod Volden (tormodvolden) wrote : | #143 |
> This really should be fixed. Especially for the server people.
This will most probably not be SRU'ed for Dapper, since it can be worked around using the "vesa" driver (or just disabling DRI in some cases) - which should work fine especially for server people.
For the Dapper desktop users with this problem, can you try this package? (It has the above patch)
Changed in xserver-xorg-driver-ati: | |
status: | Unknown → Fix Released |
Tormod Volden (tormodvolden) wrote : | #144 |
Any Dapper users left, who can test the patched package in the previous comment?
Changed in xserver-xorg-driver-ati: | |
status: | Confirmed → Needs Info |
Jared Allen (en0k-13) wrote : | #145 |
I've had the same problem with hard lock-ups using the "ati" driver with a Radeon 9700pro on a clean install of dapper. It still froze up when I upgraded to edgy, no difference. The system completely locks up. Nothing ever appears in the logs, but the freezing is consistent. When I switched from the ati driver to the vesa driver every worked fine, video refresh sucked of course, but it worked. Switch back to the ati and I froze within 15min. Finally I just installed the fglrx driver from the xorg-driver-fglrx package which has been working fine.
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon R300 ND [Radeon 9700 Pro]
01:00.1 Display controller: ATI Technologies Inc Radeon R300 [Radeon 9700 Pro] (Secondary)
srfeo (sgreszcz) wrote : | #146 |
I applied the updated .deb two days ago, switched back to the "ati" driver from "vesa" and so far have not seen any harware lockups like when I first installed Dapper. This is my video hardware:
0000:01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility M6 LY
metti (marc-michaelsen) wrote : | #147 |
I had the same Problem as described above, on an updated edgy with a 7500 and the radeon driver.
But only when I've tried to start a application that uses opengl like glxgears/info when I added "load dri" to my xorg.conf.
I've found a way to circumvent crashes while anyhow using dri module.
I've found out that the module "GLcore" interferes with "dri".
"GLcoere" is not needed for opengl and direct rendering so I deactivated it and lo and behold it all works wthout crashes and 3d is working perfectly smooth.
I'am using an ati 7500 with radeon driver on a thinkpad t41.
AIGLX works stable with beryl.
magilus (magilus) wrote : | #148 |
> But only when I've tried to start a application that uses opengl like glxgears/info when I added "load dri" to my xorg.conf.
See bug 61137. The bug this bug report is about has been fixed in Edgy.
Timo Aaltonen (tjaalton) wrote : | #149 |
closing bogus component
Changed in xorg: | |
status: | Needs Info → Rejected |
Changed in envy: | |
status: | New → Invalid |
Changed in xserver-xorg-driver-ati: | |
status: | New → Unknown |
Changed in xserver-xorg-driver-ati: | |
status: | Unknown → Fix Released |
Henrik Nilsen Omma (henrik) wrote : | #150 |
removing dapper milestone
Timo Aaltonen (tjaalton) wrote : | #151 |
fixed ages ago.
Changed in xserver-xorg-driver-ati: | |
status: | New → Fix Released |
Changed in xserver-xorg-video-ati (Ubuntu): | |
assignee: | nobody → dazanova (dazanova) |
Tormod Volden (tormodvolden) wrote : | #152 |
dazanova, you only assign bugs to yourself if you are working on a fix for it.
Changed in xserver-xorg-video-ati (Ubuntu): | |
assignee: | dazanova (dazanova) → nobody |
Changed in xserver-xorg-driver-ati: | |
importance: | Unknown → Medium |
Changed in xserver-xorg-driver-ati: | |
importance: | Medium → Unknown |
Changed in xserver-xorg-driver-ati: | |
importance: | Unknown → Medium |
I am experiencing similar things. I have three systems
with ATI Radeon 7000. On two systems, that both use an
ASUS P4S800D-E (SIS655TX) the system freezes when X
tries to load. By freezes, I mean: (i) ctrl-alt-backspace
does not kill X, (ii) ctrl-alt-del does not reboot the
machine, (iii) can no longer ping the card, etc...
Commenting out the 'Load dri' line solves the problem.
The third system though, is an AMD Athlon 64 on an
ASUS K8V board, and everything loads fine with dri.