Bug 14347 - xf86-video-sunffb fails in FFBDacSaveScreen when client disconnects
Summary: xf86-video-sunffb fails in FFBDacSaveScreen when client disconnects
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/other (show other bugs)
Version: 7.3 (2007.09)
Hardware: Other All
: medium normal
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL: http://bugs.debian.org/cgi-bin/bugrep...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-02-03 08:46 UTC by Brice Goglin
Modified: 2008-06-01 05:50 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
fix for Creator3D from Bernhard R. Link (593 bytes, patch)
2008-03-16 12:20 UTC, Brice Goglin
no flags Details | Splinter Review

Description Brice Goglin 2008-02-03 08:46:10 UTC
Bernhard R. Link and Adam Cécile (Le_Vert) both observed that the sunffb driver fails to initialize on their machine with both Xserver 1.3 and 1.4.

Bernhard has a Creator/Creator3D board and debugged this in details in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=455313
He says the crash occurs when the first client disconnects.

Adam has a SunBlade 1000 with two Sun Elite3D (same problem with a single board), log available at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=463794

Here's a backtrace:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xf7fce6b0 (LWP 10150)]
0xf78c94b4 in FFBDacSaveScreen (pFfb=0xf7d3b928, mode=0)
     at ../../src/ffb_dac.c:535
535	  tmp = DACCFG_READ(dac, FFBDAC_CFG_TGEN);  /* Get the timing information */
(gdb) bt full
#0  0xf78c94b4 in FFBDacSaveScreen (pFfb=0xf7d3b928, mode=0)
    at ../../src/ffb_dac.c:535
	tmp = 8192
	dac = (ffb_dacPtr) 0x0
#1  0xf78cc58c in FFBSaveScreen (pScreen=0x291ca8, mode=0)
    at ../../src/ffb_driver.c:1013
No locals.
#2  0xf78cba4c in FFBScreenInit (scrnIndex=0, pScreen=0x291ca8, argc=2, argv=0xffe59db4) at ../../src/ffb_driver.c:719
	pScrn = (ScrnInfoPtr) 0x1fb718
	pFfb = (FFBPtr) 0x1fc790
	ret = 1874096
	afb_fem = 655488
	visual = (VisualPtr) 0x1b96b4
#3  0x0003c098 in AddScreen (pfnInit=0xf78cb4a0 <FFBScreenInit>, argc=2, argv=0xffe59db4) at ../../dix/main.c:769
	i = 0
	scanlinepad = <value optimized out>
	format = <value optimized out>
	depth = <value optimized out>
	bitsPerPixel = 32
	k = <value optimized out>
	pScreen = (ScreenPtr) 0x291ca8
#4  0x000732a8 in InitOutput (pScreenInfo=0x1eb050, argc=2, argv=0xffe59db4)
    at ../../../../hw/xfree86/common/xf86Init.c:850
	i = 0
	j = <value optimized out>
	k = <value optimized out>
	scr_index = 2011216
	modulelist = <value optimized out>
	optionlist = (pointer *) 0xffe597e8
	layout = (screenLayoutPtr) 0x1c9800
	screenpix24 = <value optimized out>
	pix24 = <value optimized out>
	pix24From = <value optimized out>
	autoconfig = 1873920
	generation = 2
#5  0x0003c960 in main (argc=2, argv=0xffe59db4, envp=0x1)
     at ../../dix/main.c:369
	i = <value optimized out>
	error = -134346768
	alwaysCheckForInput = {0, 1}
Comment 1 Brice Goglin 2008-02-16 12:12:29 UTC
Adam Cécile says that the problem goes away when afbinit is installed. I am waiting for Bernhard opinion about this.

I think I will change "AFB firmware not loaded" from X_INFO to X_WARNING so that people have more chance of finding such a problem.

But I am wondering if it is actually possible to run without NoAccel and without the AFB firmware. It currently issues a warning in the log. But it cannot work for real and causes such crashes, we should make it an error.
Comment 2 Brice Goglin 2008-03-16 12:18:04 UTC
Bernhard does not seem to be helped by afbinit. But he wrote the attached patch to fix his problem. He says:

"The problem seems to be that FFBSaveScreen uses GET_FFB_FROM_SCREEN, which is #defined as ((FFBPtr)(s)->devPrivates[CreatorScreenPrivateIndex].ptr) but CreatorScreenPrivateIndex and devPrivates seem to be only set in ffb_accel, not by ffb_driver. When initializing the server that due to some strange reason causes no problem[1], but when the last client exists and the server is doing a reset, CreatorScreenPrivateIndex is 5 here and points to strange values (0 or 0x10000 and stuff like that) thus causing an segfault.

[1] On some other cards there might be no accelerator without additional
stuff, thus already segfaulting when starting the X server here. That
might exlain why it sometimes may already segfault when starting the
server and why that segfault at the start no longer happens with some
firmware package."
Comment 3 Brice Goglin 2008-03-16 12:20:37 UTC
Created attachment 15195 [details] [review]
fix for Creator3D from Bernhard R. Link
Comment 4 Julien Cristau 2008-06-01 05:50:43 UTC
On Sun, Mar 16, 2008 at 12:20:38 -0700, bugzilla-daemon@freedesktop.org wrote:

> --- Comment #3 from Brice Goglin <brice.goglin@ens-lyon.org>  2008-03-16 12:20:37 PST ---
> Created an attachment (id=15195)
>  --> (http://bugs.freedesktop.org/attachment.cgi?id=15195)
> fix for Creator3D from Bernhard R. Link
> 
this was included in davem's commit
843d93e775cd46a0e24e1a725594fa2d942f14ba


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.