https://bugzilla.kernel.org/show_bug.cgi?id=17702
Summary: Stable2.6.35.x kernel regression: KMS/xorg fails to
start, xorg log ending as DRI2 starts
Product: Drivers
Version: 2.5
Kernel Version: 2.6.35.4
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Video(DRI - non Intel)
AssignedTo: drivers_video-...@kernel-bugs.osdl.org
ReportedBy: 1i5t5.dun...@cox.net
Regression: Yes
Created an attachment (id=28912)
--> (https://bugzilla.kernel.org/attachment.cgi?id=28912)
config 2.6.35
This regression is quite interesting as it may have to do with the recent xorg
related security fix, tho I've not fully bisected it yet.
Until a few days ago, I had been running a late (around the last rc) 2.6.35 git
kernel. I tried upgrading to 2.6.36-rc3, and everything was fine until I tried
to start X. It froze, but the kernel was still alive, and with a magic-SRQ-R,
I could get it to take a three-finger salute and reboot. (When such things
happened before KMS, I could often get a text terminal back, but I've not
figured out how with KMS, blind-switching to VT-1 and blind-issuing a "reset"
command doesn't work like it often used to when X was frozen but the kernel was
still responsive. Any hints?) So wanting a kernel safe from that security
vuln, I tried the latest stable, 2.6.35.4, and it had a very similary problem!
So I tried reverting to 2.6.35 (which I had been running only a handful of
commits behind for some weeks, but which has that security vuln), and IT WORKED
FINE!
That means the regression is post 2.6.35 in both the stable series (2.6.35.4 at
least) and Linus/Head (2.6.36-rc3 at least) affected! I've not yet bisected
beyond that, as I decided that now that I know it's a stable series bug, I
should file it, and get the process started, but I do plan to (tho these things
seem to invariably happen when I'm short on time, important conference coming
up this weekend and full schedule next week, so just when I get to it is a
question).
Hardware is a now older dual socket Opteron 290, AGP based graphics, Tyan s2885
mobo, running a fairy new Radeon hd4650 graphics card. Note that this IS an
AGP... probably not a lot of folks running that new a card on AGP, that the
chipset is the original AMD 8xx series, with the AGPGART based IOMMU, and that
it's a dual-socket-dual-core CPU arrangement. In case it matters (bandwidth?)
dual displays as well, 1920x1080 (full hd), stacked for 1920x2160, connected
via dual dvi ports on the card.
Software: Gentoo/~amd64, native kernel/xorg freedomware Radeon driver, KMS.
Versions should be pretty close to current: xorg-server-1.9.0,
xf86-video-ati-6.13.1, mesa-7.8.2, libdrm-2.4.21-r1. kde-4.5.0 as the xorg
desktop environment, all compiled with gcc-4.5.x (currently 4.5.1 tho I don't
believe I recompiled the entire system after 4.5.1, as I did after 4.5.0).
Here's the lines surrounding the freeze from the xorg log:
[ 501.005] (II) RADEON(0): mem size init: gart size :7dff000 vram size:
s:40000000 visible:3f7d7000
[ 501.005] (II) RADEON(0): EXA: Driver will allow EXA pixmaps in VRAM
[ 501.010] (**) RADEON(0): Display dimensions: (480, 270) mm
[ 501.010] (**) RADEON(0): DPI set to (101, 203)
[ 501.010] (II) Loading sub module "fb"
[ 501.010] (II) LoadModule: "fb"
[ 501.011] (II) Loading /usr/lib64/xorg/modules/libfb.so
[ 501.046] (II) Module fb: vendor="X.Org Foundation"
[ 501.046] compiled for 1.9.0, module version = 1.0.0
[ 501.046] ABI class: X.Org ANSI C Emulation, version 0.4
[ 501.046] (II) Loading sub module "ramdac"
[ 501.046] (II) LoadModule: "ramdac"
[ 501.046] (II) Module "ramdac" already built-in
[ 501.046] (II) RADEON(0): GPU accel disabled or not working, using shadowfb
for KMS
[ 501.046] (II) Loading sub module "shadow"
[ 501.046] (II) LoadModule: "shadow"
[ 501.047] (II) Loading /usr/lib64/xorg/modules/libshadow.so
[ 501.055] (II) Module shadow: vendor="X.Org Foundation"
[ 501.055] compiled for 1.9.0, module version = 1.1.0
[ 501.055] ABI class: X.Org ANSI C Emulation, version 0.4
[ 501.055] (--) Depth 24 pixmap format is 32 bpp
That's the end of the last error log, tho it often gets in two more lines, here
filled in from the current (working) xorg launch on 2.6.35.
[ 118.405] (II) RADEON(0): [DRI2] Setup complete
[ 118.405] (II) RADEON(0): [DRI2] DRI driver: r600
Here's the next few lines in the sequence from the working log, AFTER the point
at which it freezes with the bad kernels.
[ 118.406] (II) RADEON(0): Front buffer size: 17280K
[ 118.406] (II) RADEON(0): VRAM usage limit set to 920646K
[ 118.428] (==) RADEON(0): Backing store disabled
[ 118.428] (II) RADEON(0): Direct rendering enabled
[ 118.434] (II) RADEON(0): Setting EXA maxPitchBytes
[ 118.434] (II) EXA(0): Driver allocated offscreen pixmaps
[ 118.434] (II) EXA(0): Driver registered support for the following
operations:
[ 118.434] (II) Solid
[ 118.434] (II) Copy
[ 118.434] (II) Composite (RENDER acceleration)
[ 118.434] (II) UploadToScreen
[ 118.434] (II) DownloadFromScreen
[ 118.434] (II) RADEON(0): Acceleration enabled
[ 118.434] (==) RADEON(0): DPMS enabled
[ 118.434] (==) RADEON(0): Silken mouse enabled
[ 118.435] (II) RADEON(0): Set up textured video
[ 118.435] (II) RADEON(0): RandR 1.2 enabled, ignore the following RandR
disabled message.
So it looks pretty clear to me that as soon as it inits DRI2, it freezes.
Unfortunately, neither Option "NoAccel" nor Option "DRI" "0" in the xorg.conf.d
file containing the graphics device config, seem to do anything, so I've not
yet tested an X start with that off. I'll have to turn OpenGL effects off in
KDE from a working kernel, then reboot to the bad kernel to see if it gets any
farther without OpenGL immediately activated.
config-2.6.35 attached.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
