Summary: | xfce 4.2.2 + exa + MergedFB on Radeon 7500 crashes | ||
---|---|---|---|
Product: | xorg | Reporter: | Charles Cao <fatfatwolf> |
Component: | Server/Acceleration/EXA | Assignee: | Xorg Project Team <xorg-team> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | critical | ||
Priority: | high | CC: | benh |
Version: | 6.8.99.901 (6.9 RC1) | Keywords: | have-backtrace |
Hardware: | x86 (IA32) | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
Charles Cao
2005-10-28 09:39:41 UTC
Ok, this is a totally different backtrace than what you posted earlier. I don't trust the backtrace claiming pScrn is NULL when calling RADEONSetCursorPositionMerged() since I don't see how it could be non-NULL when callig RADEONSetCursorPosition() and magically become NULL. I suggest you add some debug (use ErrorF(), it works like printf) to radeon_mergedfb.c, in RADEONSetCursorPositionMerged() to see what's up, for example check if pScrn2 is NULL before it uses it. I suspect the problem is: if (info->useEXA) OUTREG(RADEON_CUR_OFFSET, info->cursorArea->offset + yorigin * stride); That code doesn't even test if info->cursorArea is NULL, which typically will happen after a VT switch due to a bug (we lose HW cursor) that we haven't fixed yet. In fact, I'm not sure why we can't just use info->cursor_offset for EXA exactly like we do for XAA, that's what we do in the non-mergedfb case. wow, it is actually the case. When I insert ErrorF, it tells me that in RADEONSetCursorPositionMerged pScrn is not NULL but info->CursorArea is. After I followed your suggestion, using info->cursor_offset instead of info->CursorArea->offset, it runs pretty well now. So I guess this bug is already solved... (In reply to comment #1) > Ok, this is a totally different backtrace than what you posted earlier. > > I don't trust the backtrace claiming pScrn is NULL when calling > RADEONSetCursorPositionMerged() since I don't see how it could be non-NULL when > callig RADEONSetCursorPosition() and magically become NULL. > > I suggest you add some debug (use ErrorF(), it works like printf) to > radeon_mergedfb.c, in RADEONSetCursorPositionMerged() to see what's up, for > example check if pScrn2 is NULL before it uses it. > > I suspect the problem is: > > if (info->useEXA) > OUTREG(RADEON_CUR_OFFSET, info->cursorArea->offset + yorigin * stride); > > That code doesn't even test if info->cursorArea is NULL, which typically will > happen after a VT switch due to a bug (we lose HW cursor) that we haven't fixed > yet. In fact, I'm not sure why we can't just use info->cursor_offset for EXA > exactly like we do for XAA, that's what we do in the non-mergedfb case. > > CVSROOT: /cvs/xorg Module name: xc Changes by: daenzer@gabe.freedesktop.org 05/11/08 05:35:23 Log message: 2005-11-08 Michel Daenzer <michel@daenzer.net> * programs/Xserver/hw/xfree86/drivers/ati/radeon_mergedfb.c: (RADEONSetCursorPositionMerged): bugzilla #4916 (https://bugs.freedesktop.org/show_bug.cgi?id=4916) Fix segfault with MergedFB and EXA enabled and HW cursor temporarily disabled. Modified files: ./: ChangeLog xc/programs/Xserver/hw/xfree86/drivers/ati/: radeon_mergedfb.c Revision Changes Path 1.1500 +8 -0 xc/ChangeLog http://cvs.freedesktop.org/xorg/xc/ChangeLog 1.14 +2 -2 xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_mergedfb.c http://cvs.freedesktop.org/xorg/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_mergedfb.c |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.