I think I have the answer (below).
Deron Meranda wrote:
On Tue, Jul 1, 2008 at 3:59 PM, Steve Dowe <steve.dowe@xxxxxxxxxxx> wrote:
http://shaver.off.net/diary/2008/05/25/fsyncers-and-curveballs/
Good link, but I think it is entirely unrelated to this. <snip>
Sorry, I misunderstood the reason that you mentioned FF originally.
I wonder if disabling SMP at boot has any affect? Use
the "nosmp" boot-time kernel option. Note though that if
you're running with only one cpu and Xorg goes wild, you
may not be able to ssh or do anything else, depending
where at in the kernel this problem is occurring.
Actually, I don't think it's kernel based. But your original
suggestion about 2D acceleration was right on the mark, at least as far
as my testing goes.
My card is a Diamond Stealth ATI X1050; which is really a
vendor repackaging of an ATI RV350 AS [Radeon 9550],
an AGP version. It also supposedly has this as its chipset:
"ATI Radeon 9600 AS (AGP)" (ChipID = 0x4153)
and yours is a:
01:05.0 VGA compatible controller: ATI Technologies Inc RS690M [Radeon X1200
Series]
(--) RADEON(0): Chipset: "ATI Radeon X1200" (ChipID = 0x791f)
It looks like we have quite different ATI cards; but I don't know
my Radeon product line very well.
Indeed, and the only similarity between our systems is the driver,
despite being 32 vs 64 bit.
# grep -i cursor /var/log/Xorg.0.log
(II) RADEON(0): Using hardware cursor 0 (scanline 1602)
(II) RADEON(0): Using hardware cursor 1 (scanline 1604)
Presumably this is influenced by the display dimensions and refresh rate?
You're using hardware-assisted cursor/pointer; which is the
default. I think the scanline numbers indicate at which point
in the screen refresh cycle that the interrupt will be generated
(but I'm kind of guessing here). It's not too important.
If you disable hardware cursors in your xorg.conf, those
lines should not appear in the log file.
I didn't check this, but I did enable these options in my "Device"
section in xorg.conf:
Option "SWcursor" "on"
Option "NoAccel" "on"
.. and then restarted X. Boy, imagine life without hardware
acceleration (no, don't!!). I had complete success with this config -
no hanging issue despite really, /really/ trying to upset X with my
mouse pointer. It just wouldn't hang, but I knew I was working it hard
as my cpu fan speed increased :)
It will be interesting if NoAccel works. Of course that's quite a
drastic workaround and may make your system seem very
sluggish. But it could give a clue if the system behaves differently.
Given the above, I then re-enabled hardware acceleration but retained my
software cursor and restarted X. The result? I managed to hang X
within a few minutes of (frantically) drag-resizing a firefox window.
And my mouse pointer completely disappeared this time, which confirms
that it was running in sw mode.
Unfortunately the system hanging on me is one of my primary
workstations and I don't have the luxury of being able to
tweak and play with different options as much; especially
since having to do a hard reboot is so disruptive.
That's ok - my work laptop doesn't mind ;-)
(I will say that I haven't had a lockup in about 3 days now;
previously I'd see lockups 3 or 4 times a day. I do stay up
to date on patches, but the only things recently which seem
even remotely plausible are a HAL and libsysfs update and
some SELinux policies. I may just be lucky, we'll see how
long my system stays up).
In case it hangs again, try:
Option "AccelMethod" "EXA"
.. in xorg.conf (in the Device section). This is a new acceleration
architecture which, while apparently not as mature (i.e. field-tested)
as XAA (the default acceleration architecture), seems to at least hold
up to my slipshod X testing method in this case.
I've had an interesting evening researching this, which I wouldn't have
had were it not for your suggestions.
For more info on the changes in the radeon driver, check the Change Log
of the xorg-x11-drv-ati-6.8.0-14.fc9 package (via Yum/Yumex), together
with these links:
-
http://linux.softpedia.com/get/System/Hardware/ATI-Open-Source-Video-Driver-35337.shtml
- http://zerias.blogspot.com/2008/02/amd-more-open-licensed-goodies.html
- http://www.botchco.com/agd5f/ (http://www.botchco.com/agd5f/?p=6)
- http://lists.freedesktop.org/archives/xorg/2008-February/032992.html
From those, you should be able to establish a good idea of the recent
(5 month) history of this driver development and the issues faced by
those involved.
Thanks again for your help and suggestions.
Steve
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
