Bug 152542 - Radeon 7500 laptop stalls/corruption/crash
Radeon 7500 laptop stalls/corruption/crash
Product: Fedora
Classification: Fedora
Component: xorg-x11 (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: X/OpenGL Maintenance List
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2005-03-30 00:57 EST by Warren Togami
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-04-17 01:49:21 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
radeon-6.8.2-crash.jpg (52.61 KB, image/jpeg)
2005-03-30 00:57 EST, Warren Togami
no flags Details

  None (edit)
Description Warren Togami 2005-03-30 00:57:56 EST
Description of problem:
After upgrading FC3 to the xorg-6.8.2 update, things seemed fine until I closed
my radeon 7500 laptop lid.  (It worked fine exactly this way thousands of times
with the older xorg.  It doesn't suspend, only backlight off.)  When I opened it
again the screen looked like the attached photo.

It seemed that the system died (no keyboard buttons made any effect), but I
could move a corrupted looking mouse cursor.  Only thing I could do was force a

Version-Release number of selected component (if applicable):

How reproducible:
Comment 1 Warren Togami 2005-03-30 00:57:56 EST
Created attachment 112447 [details]
Comment 2 Warren Togami 2005-04-06 06:03:04 EDT
oddly I haven't been able to reproduce this ever again.  closing WORKSFORME
Comment 3 Warren Togami 2005-04-07 05:10:06 EDT
Crap... spoke too soon.  Something seems to be corrupting something.  Two
incidents today:

1) For several days of uptime it was stable with kernel-2.6.11-1.8_FC3 with
heavy use of unplugging AC, plugging again, closing lid and opening lid.  Then
suddenly the computer locked up.
2) In another occurance after bootup and GNOME login, the screen would go blank
for no apparent reason then come back in response to slight movement of the
laptop.  These type of messages happened in dmesg when this happened.

Apr  6 21:26:15 localhost kernel: psmouse.c: TouchPad at isa0060/serio1/input0
lost synchronization, throwing 3 bytes away.
Apr  6 21:26:15 localhost kernel: psmouse.c: TouchPad at isa0060/serio1/input0
lost sync at byte 1
Apr  6 21:26:15 localhost last message repeated 2 times
Apr  6 21:26:15 localhost kernel: psmouse.c: TouchPad at isa0060/serio1/input0 -
driver resynched.

After this happened a few times, the screen came back with all graphics slightly
corrupted.  Somewhere between uncorrupted and the screenshot above.  The system
did not lockup though.  I managed to install memtest86+ and the latest
kernel-2.6.11-1.12_FC3 then reboot.

3) Booted into kernel-2.6.11-1.12_FC3, and after a few minutes of GNOME the
screen totally locked up like in Comment #1.

After all three occurances, the laptop screen refused to light when the laptop
is turned on.  Forced power off would be necessary.  Power-on would again fail
to turn on the laptop screen.  Forced power off, waiting 30 seconds, then
poweron would allow the screen to light again.

Now testing it with DRI disabled in /etc/X11/xorg.conf, and so far it seems
totally stable.

I am guessing that these issues are from the FC3 upgrade to
xorg-x11-6.8.2-1.FC3.13 because things seemed fine with the 2.6.11 kernel prior
to the xorg update.  However I am not willing to totally rule out that the
kernel is involved somehow.
Comment 4 Mike A. Harris 2005-04-08 01:20:59 EDT
kernel-2.6.10-1.770_FC3 is the current FC3 kernel from what I can tell.

Please update the fedora release to "devel" if you're using rawhide kernel
or other components from Fedora development.  Alternatively, confirm
the problem on stock FC3 system with only FC3 updates applied (without
anything from FC-devel).  This way we can establish a reproduceable
test case with a sane base OS.

Thanks in advance.
Comment 5 Warren Togami 2005-04-08 02:37:10 EDT
This is the kernel from FC3 updates/testing.  No packages from rawhide at all. 
But yes I should retest with kernel-2.6.10-1.770_FC3 too in order to totally
isolate xorg-x11 as the cause.
Comment 6 Mike A. Harris 2005-04-08 04:25:45 EDT
Thanks warren.  Please update the status with your results once you
have a chance to test kernel-2.6.10-1.770_FC3.  The additional feedback
will be useful for troubleshooting.

Comment 7 JD Smith 2005-04-11 13:44:40 EDT
I have a non-mobile Radeon 7500 on my Athlon SMP machine, and I also experienced
hard lockups after upgrading to xorg-x11-6.8.2-1.FC3.13.  Downgrading to the FC3
base *xorg* packages has fixed the problem.  
Comment 8 Warren Togami 2005-04-11 15:05:37 EDT
JD Smith, I suspect your problem is actually Bug 141295, and might be a separate
issue.  Please test that by seeing if disabling DRI with the latest xorg-x11
worksaround that problem.
Comment 9 Mike A. Harris 2005-04-15 07:30:25 EDT
xorg-x11-6.8.2-22 has various bug fixes for Radeon, including a fix in
the VT switching code used to save/restore state.  We believe this
may fix the issue.  Please upgrade to this release and provide feedback.

If the problem persists, change the bug state back to ASSIGNED, or
close it as RAWHIDE if the issue is now resolved.

Setting status to "MODIFIED", and awaiting testing results.

Thanks in advance.
Comment 10 Warren Togami 2005-04-16 22:19:59 EDT
I rebuilt xorg-x11-6.8.2-24 on FC3 and after some testing this problem remains.
 Disabling DRI seems to avoid the problem entirely.  See reproduce sequence below.

I have confirmed that the kernel seems not to be the issue as there is identical
behavior between these three versions:

Reproduce Sequence:
1) Boot laptop into X.  gdm login screen is fine.
2) Tap the laptop or bounce it gently.
3) Screen goes blank but laptop remains on.  Does not respond to ping.
4) Tap it a few more times and about 30 seconds later laptop comes back to life.
 ping works again, screen contents look corrupted but with refresh it seems to
work again.  Although sometimes it doesn't come back at all.  Sometimes it comes
back, but one VT text terminal keyboard is dead while others are working.

At this point a complete poweroff and waiting 30 seconds is necessary.  If you
don't, then all subsequent tests (like with DRI disabled, or in a VT terminal
with X killed) will fail in the same way.  Booting fresh with DRI disabled X, or
with no X, seems to avoid this behavior when I tap it.

The "tap or bounce" reproduce procedure points at hardware trouble, however I am
unable to reproduce this behavior in Windows running on the same laptop.
Comment 11 Mike A. Harris 2005-04-17 01:38:21 EDT
What do you mean by "tap it a few times"?  Hit it with your hand on the side,
like the Sanford and Son table?  Also "bounce" means what exactly?  Do you
mean bouncing your legs up and down with the laptop on your legs makes it
lock up?
Comment 12 Mike A. Harris 2005-04-17 01:49:21 EDT
I just discussed this with Warren in IRC.  He indicated to me that
he does indeed mean "tapping the side of it" locks the machine up.

If bouncing a laptop on your leg or tapping the side of it makes it
lock up, bring the machine back to the vendor for a replacment, and
hope that it is under warranty.

Closing as NOTABUG
Comment 13 Warren Togami 2005-04-17 01:58:43 EDT
Light tap on the hand or lifting it up can cause it to lockup/crash, but only
when DRI is enabled.  Neither Linux w/o DRI nor Windows on this laptop crashes
when subjected to this test.  Given these baffling test results I am not 100%
certain it is hardware trouble.  Will do a bit more tests before talking to IBM
for repair service...

Comment 14 Warren Togami 2005-04-18 05:14:34 EDT
Crap, this is definitely some kind of hardware failure.  It happens in
xorg-x11-6.8.1-12.FC3.21 too with DRI enabled.  This has just been a horrible
coincidence that it began at the same time I upgraded to 6.8.2.

Note You need to log in before you can comment on or make changes to this bug.