Bug 29166

Output of: hwinfo --gfx
-----------------------
20: PCI 105.0: 0300 VGA compatible controller (VGA)             
  [Created at pci.318]
  Unique ID: ul7N.mN63ZvBe5x4
  Parent ID: vSkL.4UFp5fHqms6
  SysFS ID: /devices/pci0000:00/0000:00:01.0/0000:01:05.0
  SysFS BusID: 0000:01:05.0
  Hardware Class: graphics card
  Model: "ATI Radeon XPRESS 200 5A61 (PCIE)"
  Vendor: pci 0x1002 "ATI Technologies Inc"
  Device: pci 0x5a61 "Radeon XPRESS 200 5A61 (PCIE)"
  SubVendor: pci 0x1462 "Micro-Star International Co., Ltd."
  SubDevice: pci 0x7254 
  Driver: "radeon"
  Driver Modules: "drm"
  Memory Range: 0xd0000000-0xdfffffff (ro,non-prefetchable)
  I/O Ports: 0xee00-0xeeff (rw)
  Memory Range: 0xfdef0000-0xfdefffff (rw,non-prefetchable)
  Memory Range: 0xfde00000-0xfde1ffff (ro,non-prefetchable,disabled)
  IRQ: 17 (38276 events)
  I/O Ports: 0x3c0-0x3df (rw)
  Module Alias: "pci:v00001002d00005A61sv00001462sd00007254bc03sc00i00"
  Driver Info #0:
    XFree86 v4 Server Module: radeon
  Driver Info #1:
    XFree86 v4 Server Module: fglrx
    3D Support: yes
    Extensions: dri
  Config Status: cfg=no, avail=yes, need=no, active=unknown
  Attached to: #10 (PCI bridge)

Primary display adapter: #20

Probably this won't really help, but I try:
From my feeling it happens more often when the desktop system is under bigger workload, when using GTK applications and when saving Files from them (thus during file system activities).

(In reply to comment #2)
> From my feeling it happens more often when the desktop system is under bigger
> workload, when using GTK applications and when saving Files from them (thus
> during file system activities).

... while running KDE 4.4.5 and now 4.4.93 (compositing deactivated).

I'm getting the same.  It is very similar to bug
https://bugzilla.novell.com/show_bug.cgi?id=615649.  I have also logged this on https://bugzilla.novell.com/show_bug.cgi?id=605478.

I was originally getting 2 types of freezes:
* one, a complete freeze, where the computer still had my windows visible, but
the mouse pointer would not move, nor would the computer respond to any key
strokes.  The only way forward was to power down.
* the other where one by one, applications stopped responding.  The mouse
pointer still moved, it was usually possible to change desktops, but it was not
possible to open new windows. Some windows would continue to respond for a long
time (minutes) such as terminal windows.  Most others would not.  It was
possible using CTRL-SHIFT-F1 etc to swap to the standard consoles and log in. 
But attempts to shut down were unsuccessful.  You might get the shutdown
message, but then no further response.  Eventually the only way forward was to
power down.

Using "nomodeset" at boot time seemed to prevent the first of these 2 - the
complete freeze.  Given that bug 615649 talked about the Intel video driver
being part of the culprit, I installed the ATI proprietary driver.  But this
did not prevent the freezes (but it did improve video performance enormously).

As is the system is essentially unusable.  I have reverted to my 11.2
installation (I have it on a separately bootable partition).  This is the
system I have been using for almost a year.  Prior to that a Dell Inspiron
notebook running 11.1.

A little about my computer.  It is a Dell Studio XPS with an i7 920 core CPU,
8GB Ram, twin 640 GB (mirrored using Dells SATA Bios) WD disks, a Radeon HD4550
graphics card, internal Bluetooth and IEEE 1394, a DVD+-RW, Gigabit network
card, 82801 Sound card and a CX 23885 TV card.

I know that my hardware is different (Radeon chipset) but the fact that 2 chipsets are experiencing the same symptoms might be useful information for people trying to debug this issue.  i.e. the problem probably doesn't lie in the graphics driver chipset specific code.  Even more so since people with Intel graphics cards seem to be experiencing the same.

GPU lockups are generally the result of feeding the card some command sequence it doesn't like.  So, the problem is mostly likely in the 2D or 3D accel code in the ddx and mesa.  Different versions of those drivers may submit slightly different sequences of commands one of which is enough to make the GPU unhappy.

(In reply to comment #5)
> GPU lockups are generally the result of feeding the card some command sequence
> it doesn't like.  So, the problem is mostly likely in the 2D or 3D accel code
> in the ddx and mesa.  Different versions of those drivers may submit slightly
> different sequences of commands one of which is enough to make the GPU unhappy.

I got it, but from the bug reporter's point of few: How can we figure this out?
What do you recommend to one who doesn't have a driver development environment set up? I even don't know, which else component to report this against (2 D acceleration, the hang occurs even with 3D compositing disabled).

(In reply to comment #5)
> GPU lockups are generally the result of feeding the card some command sequence
> it doesn't like.  So, the problem is mostly likely in the 2D or 3D accel code
> in the ddx and mesa.

Once more: This point of view isn't still shure. I'm quite new in using ATI graphics hardware, but I remember a bug I reported for the Intel graphical driver, where X was hanging and the problem has been definitely in the driver, even if the Intel graphics driver developers found it late, because it has been some kind of pitfall and tricky. There were also similar circumstances as for the chipset this is initially reported for here, that they tested on newer hardware and noone else had a testsystem with an older graphics chip they officially supported, but were't really testing.

Another reason why first point at the driver: I have the OS with the same repositories (kernel, X, Mesa etc., KDE and GNOME) installed on two different systems, on with ATI using the ATI driver, the second with NVidia using the nouveau driver, bot with compositing and 3D acceleration disabled. The mentioned problem occurs only on the ATI system, it didn't happen even once on the nouveau side. I do not say, that the problem is therefore in the driver, only, that it is most probable from what I have seen.

Finding lockups it tricky, especially if they are not readily reproduceable.  It sounds like you can rule out the 3D driver.  Is this a recent regression?  If so, what kernel and ddx (xf86-video-ati) last worked?  You might try different versions of the kernel and ddx to see if you can narrow down when the problem started.

(In reply to comment #9)
> ... Is this a recent regression? 
> If so, what kernel and ddx (xf86-video-ati) last worked?  You might try
> different versions of the kernel and ddx to see if you can narrow down when the
> problem started.

I'm not sure, since I've been using this hardware not such a long time.
What I know is that the hang definitely occured beginning from OpenSUSE 11.3 Factory x86_64 (installed with latest repository state from upstream on Nov 03 2009):
- kernel 2.6.32-rc5-git3 + several patches,
- xf86-video-ati 6.12.4,
up to now, OpenSUSE 11.3 Final with latest updates:
- xf86-video-ati 6.13.1,
- kernel-desktop-2.6.34.

Mass closure: This bug has been untouched for more than six years, and is not
obviously still valid. Please reopen this bug or file a new report if you continue to experience issues with current releases.