Bug 194043 - [regression] vesa driver freezes kernel on ATI Radeon 9200SE, often while scrolling
Summary: [regression] vesa driver freezes kernel on ATI Radeon 9200SE, often while scr...
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Brian Brock
URL:
Whiteboard: bzcl34nup
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-06-05 11:28 UTC by Alexandre Oliva
Modified: 2008-05-07 00:31 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2008-05-07 00:31:38 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
X log of a session that would eventually freeze (58.39 KB, text/plain)
2006-06-05 11:28 UTC, Alexandre Oliva
no flags Details
X logs from the earlier X builds, that never freeze and scroll fast (58.24 KB, text/plain)
2006-06-05 11:30 UTC, Alexandre Oliva
no flags Details

Description Alexandre Oliva 2006-06-05 11:28:52 UTC
+++ This bug was initially created as a clone of Bug #186442 +++

Description of problem:
After bug 186442 was fixed, I was able to start X with vesa mode (ATI Radeon
9200SE, running with vesa driver because of bug 181736).  

scrolling of a full-screen 1024x768 firefox are significant slower and my box
became crashy after this update.  The crashes don't seem to be fully repeatable,
but they're quite consistent; it's pretty difficult to avoid a total system
freeze after logging in, getting Firefox to visit a dozen web pages in separate
tabs, and then just going closing each one of them in a row.

Reverting to the following packages gets me fast scrolling and stability back:
xorg-x11-server-Xorg-1.0.1-9.x86_64.rpm
xorg-x11-drv-vesa-1.0.1.3-1.2.x86_64.rpm
xorg-x11-drv-keyboard-1.0.1.3-1.2.x86_64.rpm
xorg-x11-drv-mouse-1.0.4-1.x86_64.rpm

This is on x86_64, if it makes any difference.

I have tried this on an x86_64 notebook with an NVidia card, and I was not able
to trigger the problem.  I tried commenting out `Load "dri"', just in case, to
no avail.

Unfortunately the box becomes totally irresponsible when the problem shows up,
nothing is logged anywhere and I can't even ping it any more :-(

Version-Release number of selected component (if applicable):
xorg-x11-server-Xorg-1.1.0-2
xorg-x11-drv-vesa-1.2.0-1
xorg-x11-drv-keyboard-1.1.0-1
xorg-x11-drv-mouse-1.1.0-2

How reproducible:
Every time

Steps to Reproduce:
1.Upgrade to current rawhide
2.Restart X using the vesa driver

Actual results:
X starts fine, but scrolling graphical content on firefox is much slower than
before, and often gets the box to freeze.

Expected results:
Fast scrolling, no freezes.

Additional info:

Comment 1 Alexandre Oliva 2006-06-05 11:28:52 UTC
Created attachment 130488 [details]
X log of a session that would eventually freeze

Comment 2 Alexandre Oliva 2006-06-05 11:30:37 UTC
Created attachment 130489 [details]
X logs from the earlier X builds, that never freeze and scroll fast

Comment 3 Alexandre Oliva 2006-06-05 11:41:36 UTC
I forgot to mention the box that freezes with X in vesa mode is an SMP box,
maybe it makes a difference.

Since the kernel should never freeze, and I doubt it's actually some DRI feature
being (ab)used since VESA doesn't use DRI, I thought I'd Cc the kernel
maintainers, although the fact that older X doesn't trigger the problem kind of
points to X, and not the kernel.  It might be something new in X that triggers a
latent bug in the kernel, though.

Comment 4 Mike A. Harris 2006-06-07 07:37:08 UTC
Is this bug tracking the slow scrolling problem, or the crash problem?
Presumeably they are separate issues.

Comment 5 Alexandre Oliva 2006-06-07 13:48:02 UTC
I thought they were the same because I pretty much always got freezes while
scrolling.  But this morning I got a crash shortly after logging in, while
windows were still opening, no scrolling involved.  So I guess they may be
separate issues, indeed.  I'll create a separate bug for the slower scroll, even
though they might still be related.

Comment 6 Alexandre Oliva 2006-06-17 18:02:35 UTC
FWIW, I've tried to reproduce the bug after booting my Athlon64 X2 box with
maxcpus=1, and it didn't occur any more.

Comment 7 Mike A. Harris 2006-06-19 21:11:05 UTC
(In reply to comment #6)
> FWIW, I've tried to reproduce the bug after booting my Athlon64 X2 box with
> maxcpus=1, and it didn't occur any more.

Ok, it does sound like a kernel problem then, reassigning...


Comment 8 Alexandre Oliva 2006-07-27 04:40:44 UTC
Strictly speaking, this is not exactly a regression.  I tried the newer X with
an old kernel and it still crashed.  So it's just the new X exposing a bug that
had been latent in the kernel for quite a while.  Unfortunately I can't tell
whether the kernel prints anything to the console because I still haven't got a
serial cable :-(  These are getting extremely hard to find :-(

Comment 9 Bug Zapper 2008-04-03 17:19:21 UTC
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

Comment 10 Bug Zapper 2008-05-07 00:31:32 UTC
This bug has been in NEEDINFO for more than 30 days since feedback was
first requested. As a result we are closing it.

If you can reproduce this bug in the future against a maintained Fedora
version please feel free to reopen it against that version.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp


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