All of lore.kernel.org
 help / color / mirror / Atom feed
* [Bug 17702] New: Stable2.6.35.x  kernel regression: KMS/xorg fails to start, xorg log ending as DRI2 starts
@ 2010-09-03  6:54 bugzilla-daemon
  2010-09-03  7:19 ` [Bug 17702] " bugzilla-daemon
                   ` (8 more replies)
  0 siblings, 9 replies; 10+ messages in thread
From: bugzilla-daemon @ 2010-09-03  6:54 UTC (permalink / raw)
  To: dri-devel

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-dri@kernel-bugs.osdl.org
        ReportedBy: 1i5t5.duncan@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
--

^ permalink raw reply	[flat|nested] 10+ messages in thread
end of thread, other threads:[~2010-09-05 22:10 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-09-03  6:54 [Bug 17702] New: Stable2.6.35.x kernel regression: KMS/xorg fails to start, xorg log ending as DRI2 starts bugzilla-daemon
2010-09-03  7:19 ` [Bug 17702] " bugzilla-daemon
2010-09-03 21:24 ` bugzilla-daemon
2010-09-03 22:52 ` bugzilla-daemon
2010-09-03 23:06 ` bugzilla-daemon
2010-09-05  9:11 ` bugzilla-daemon
2010-09-05 10:36 ` bugzilla-daemon
2010-09-05 10:43 ` bugzilla-daemon
2010-09-05 22:10 ` bugzilla-daemon
2010-09-05 22:10 ` bugzilla-daemon

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.