Summary: | DRI with radeon7500 causes lockups | ||
---|---|---|---|
Product: | Mesa | Reporter: | Mateusz <mateusz> |
Component: | Drivers/DRI/R100 | Assignee: | Default DRI bug account <dri-devel> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | blocker | ||
Priority: | high | CC: | benh |
Version: | git | ||
Hardware: | x86 (IA32) | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
Mateusz
2004-11-03 11:04:21 UTC
does it also lockup if you disable tcl (tcl_mode=0)? What xorg version are you using? I am currently using mesa cvs from before 20040925 and it's working but lack something I guess, some software dont render textures correctly (Scorched3d,NeverWinter). I builded latest CVS and replaced that radeon_dri.so with the new one. Did ldconfig then restarted and with env tcl_mode=0 still get everything locking up. My Xorg is also from CVS (2004-10-31). I tried with cvs's drm and then 2.6.8 kernel's one, the same effect. ---------------------------------------------------------------------- There is also something strange for me that I dont understand, I used the same linux-dri-x86 config for both Mesa compilations and I get binary file sizes that differ in 6mb, what is more the new one is that smaller. The buggy one from latest CVS -rwxr-xr-x 1 root root 15M 2004-11-04 09:02 /usr/X11R6/lib/modules/dri/radeon_dri.so and the one from old Mesa is -rwxr-xr-x 1 mateusz mateusz 21M 2004-11-01 01:02 OLD-Mesa/Mesa/lib/radeon_dri.so # Configuration for linux-dri-x86 include $(TOP)/configs/linux-dri CONFIG_NAME = linux-dri-x86 PIC_FLAGS = ASM_FLAGS = -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM ASM_SOURCES = $(X86_SOURCES) DRM_SOURCE_PATH = /home/mateusz/DRI/drm SRD_DIRS = mesa DIR_DIRS = dri_client radeon r200 tdfx OPT_FLAGS = -O3 -march=athlon -pipe -Wall -fomit-frame-pointer all other configs are the same size for both Mesa versions. (In reply to comment #2) > I am currently using mesa cvs from before 20040925 and it's working but lack > something I guess, some software dont render textures correctly > (Scorched3d,NeverWinter). > I builded latest CVS and replaced that radeon_dri.so with the new one. > Did ldconfig then restarted and with env tcl_mode=0 still get everything locking > up. > My Xorg is also from CVS (2004-10-31). > I tried with cvs's drm and then 2.6.8 kernel's one, the same effect. > > ---------------------------------------------------------------------- > There is also something strange for me that I dont understand, I used the same > linux-dri-x86 config for both Mesa compilations and I get binary file sizes that > differ in 6mb, what is more the new one is that smaller. > > The buggy one from latest CVS > -rwxr-xr-x 1 root root 15M 2004-11-04 09:02 > /usr/X11R6/lib/modules/dri/radeon_dri.so > > and the one from old Mesa is > -rwxr-xr-x 1 mateusz mateusz 21M 2004-11-01 01:02 OLD-Mesa/Mesa/lib/radeon_dri.so > > # Configuration for linux-dri-x86 > include $(TOP)/configs/linux-dri > CONFIG_NAME = linux-dri-x86 > PIC_FLAGS = > ASM_FLAGS = -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM > ASM_SOURCES = $(X86_SOURCES) > DRM_SOURCE_PATH = /home/mateusz/DRI/drm > SRD_DIRS = mesa > DIR_DIRS = dri_client radeon r200 tdfx > OPT_FLAGS = -O3 -march=athlon -pipe -Wall -fomit-frame-pointer > > all other configs are the same size for both Mesa versions. > (In reply to comment #2) > I am currently using mesa cvs from before 20040925 and it's working but lack > something I guess, some software dont render textures correctly > (Scorched3d,NeverWinter). > I builded latest CVS and replaced that radeon_dri.so with the new one. > Did ldconfig then restarted and with env tcl_mode=0 still get everything locking > up. > My Xorg is also from CVS (2004-10-31). > I tried with cvs's drm and then 2.6.8 kernel's one, the same effect. > > ---------------------------------------------------------------------- > There is also something strange for me that I dont understand, I used the same > linux-dri-x86 config for both Mesa compilations and I get binary file sizes that > differ in 6mb, what is more the new one is that smaller. > > The buggy one from latest CVS > -rwxr-xr-x 1 root root 15M 2004-11-04 09:02 > /usr/X11R6/lib/modules/dri/radeon_dri.so > > and the one from old Mesa is > -rwxr-xr-x 1 mateusz mateusz 21M 2004-11-01 01:02 OLD-Mesa/Mesa/lib/radeon_dri.so > > # Configuration for linux-dri-x86 > include $(TOP)/configs/linux-dri > CONFIG_NAME = linux-dri-x86 > PIC_FLAGS = > ASM_FLAGS = -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM > ASM_SOURCES = $(X86_SOURCES) > DRM_SOURCE_PATH = /home/mateusz/DRI/drm > SRD_DIRS = mesa > DIR_DIRS = dri_client radeon r200 tdfx > OPT_FLAGS = -O3 -march=athlon -pipe -Wall -fomit-frame-pointer > > all other configs are the same size for both Mesa versions. > Just a me too post really. I tried to get my radeon 7500 working a couple of days ago and hit the same sort of problems. gears hung as soon as it started - No keyboard but could SSH into box which hung as I killed gears. ET/wolfenstein lock box totally as soon as they get to 3D bits. Q3 demo will last a few seconds rendering. geartrain is OK until I rotate it. For some reason marbleblast demo and fire work OK. Andy. I've tried newest Mesa CVS on a 7200sdr and can confirm some issues. If I start glxgears as the first OpenGL app, it instantly locks up. However, if I start QuakeIII first, it runs, and glxgears will run just fine later on. That's even true if I leave X, rmmod radeon and restart X, glxgears works, only after a reboot it will lock up again. Looks to me like some state never gets initialized. A potential fix has been checked in, could you please retry with newest CVS? I tried and it still locks up. (In reply to comment #6) > I tried and it still locks up. Yes it still locks up and from strace I can see it loops forever. But somewhing has changed now because previously I got gettimeofday({1099555005, 69646}, NULL) = 0 gettimeofday({1099555005, 69665}, {4294967236, 0}) = 0 beatween ioctl() calls.. in strace.log Now the strace looks like ioctl(4, 0x4008642a, 0xbffffa48) = 0 write(3, "\200\t\3\0\0\0\0\0\2\0`\0", 12) = 12 read(3, "\f\n\37\0\2\0`\0\0\0\0\0,\1,\1\0\0t\10\250 w\10\210\363"..., 32) = 32 read(3, "\1\0 \0\5\0\0\0\0\0\0\0\1\1\0\0\0\0\0\0,\1,\1\1\0\0\0\0"..., 32) = 32 read(3, "\1\0\0\0", 4) = 4 read(3, "\0\0\0\0,\1,\1", 8) = 8 read(3, "\0\0\0\0,\1,\1", 8) = 8 ioctl(4, 0x4008642a, 0xbffffa48) = 0 ioctl(3, FIONREAD, [0]) = 0 ioctl(4, 0x40106450, 0xbffff8f0) = 0 ioctl(4, 0xc0086451, 0xbffff9b8) = 0 ioctl(4, 0x40106450, 0xbffff930) = 0 ioctl(4, 0x40186448, 0xbffffab0) = 0 ioctl(4, 0xc0286429, 0xbffff390) = 0 ioctl(4, 0x40106450, 0xbfffd3f0) = 0 ioctl(4, 0x40106450, 0xbffff450) = 0 ioctl(4, 0x40106450, 0xbffffa70) = 0 ioctl(4, 0xc0086451, 0xbffffaa0) = 0 ioctl(4, 0xc010643a, 0xbffffab0) = 0 ioctl(4, 0x6447, 0) = 0 gettimeofday({1101672442, 574975}, NULL) = 0 gettimeofday({1101672442, 575002}, {4294967236, 0}) = 0 ioctl(3, FIONREAD, [0]) = 0 ioctl(4, 0x40106450, 0xbffff8f0) = 0 ioctl(4, 0xc0086451, 0xbffff9b8) = 0 ioctl(4, 0x40106450, 0xbffff930) = 0 ioctl(4, 0x40186448, 0xbffffab0) = 0 ioctl(4, 0x40106450, 0xbffff450) = 0 ioctl(4, 0x40106450, 0xbffffa70) = 0 ioctl(4, 0xc0086451, 0xbffffaa0) = 0 ioctl(4, 0xc0086451, 0xbffffaa0) = 0 ioctl(4, 0xc0086451, 0xbffffaa0) = 0 ioctl(4, 0xc0086451, 0xbffffaa0) = 0 ioctl(4, 0xc0086451, 0xbffffaa0) = 0 ioctl(4, 0xc0086451, 0xbffffaa0) = 0 .... and so on... filling free disk space... What steps I need to do in order to debug it more precisly ? (In reply to comment #7) > > I tried and it still locks up. > > Yes it still locks up and from strace I can see it loops forever. It's probably trying to getting a free buffer or something, and it will never get this if the gpu has locked up :(. > What steps I need to do in order to debug it more precisly ? You could try enabling debugging in the kernel module and then try to see at which point the gpu stops to respond (not easy). I'm really at a loss what's wrong. The problem only seems to affect 7500 cards. It works just fine with 7200 cards. That's really strange as the difference between 7500 and 7200 cards is almost zero, apart that the chip is built on a smaller process (on the top of my head, I can remember that the 7500 has the display controller of the 7000 (i.e. two heads), was rumoured to have a different memory controller, and the cards also have asynchronous memory/core clocks, which were reported to be very problematic (slower and/or lockups) with 7200 cards when people tried that. Oh and the 7500 has a fixed stencil buffer...). None of those changes should make a difference with regard to the 3d driver. Unless the asynchronous clock problems weren't actually fixed with the 7500, but require driver workarounds (but it seems strange that the lockups would now suddenly be triggered by the new emit code imho). if you are using xorg cvs or 6.8.x, try: option "DynamicClocks" "true" you may also want to try the patch I attached to bug 1912, however, try this variation (so it gets enabled on RV200 chips): case 0: /* Turn everything OFF (ForceON to everything)*/ - if ( !info->HasCRTC2 ) { + /* some non-mobility VE chips seem to have problems with the method of + * forcing everything on as per below; thus we revert to the old + * forceON behavior + */ + if (((info->ChipFamily == CHIP_FAMILY_RV100) || info->ChipFamily == CHIP_FAMILY_RV200) && (!info->IsMobility)) { + if (info->HasCRTC2) { + tmp = INPLL(pScrn, RADEON_SCLK_CNTL); + OUTPLL(RADEON_SCLK_CNTL, ((tmp & ~RADEON_DYN_STOP_LAT_MASK) | + RADEON_CP_MAX_DYN_STOP_LAT | + RADEON_SCLK_FORCEON_MASK)); + if (info->ChipFamily == CHIP_FAMILY_RV200) { + tmp = INPLL(pScrn, RADEON_SCLK_MORE_CNTL); + OUTPLL(RADEON_SCLK_MORE_CNTL, tmp + | RADEON_SCLK_MORE_FORCEON); + } + } + + tmp = INPLL(pScrn, RADEON_MCLK_CNTL); + OUTPLL(RADEON_MCLK_CNTL, (tmp | + RADEON_FORCEON_MCLKA | + RADEON_FORCEON_MCLKB | + RADEON_FORCEON_YCLKA | + RADEON_FORCEON_YCLKB | + RADEON_FORCEON_MC | + RADEON_FORCEON_AIC)); + + } else if ( !info->HasCRTC2 ) { tmp = INPLL(pScrn, RADEON_SCLK_CNTL); tmp |= (RADEON_SCLK_FORCE_CP | RADEON_SCLK_FORCE_HDP | RADEON_SCLK_FORCE_DISP1 | RADEON_SCLK_FORCE_TOP | if you try the patch I suggested, turn either use Option "dynamicclocks" "false" or remove the option altogether. (In reply to comment #10) > if you try the patch I suggested, turn either use > Option "dynamicclocks" "false" > or remove the option altogether. The Option "dynamicclocks" didnt work, I could not compile xorg with the patch cause now there is a bug in xorg's cvs xftdpy.c: In function `XftDefaultSubstitute': xftdpy.c:495: error: `FC_RGBA_UNKNOWN' undeclared (first use in this function) xftdpy.c:495: error: (Each undeclared identifier is reported only once xftdpy.c:495: error: for each function it appears in.) If You want to reproduce it follow http://incubator.vislab.usyd.edu.au/roller/page/Steve/20040909 I am using currently minimal version of xorg as on http://dri.sourceforge.net/cgi-bin/moin.cgi/Building and DRM from cvs -z3 -d:pserver:anonymous@cvs.freedesktop.org:/cvs/dri co drm on which patch will not apply. Could You give me directions How to debug kernel module drm ? (In reply to comment #11) > (In reply to comment #10) > > if you try the patch I suggested, turn either use > > Option "dynamicclocks" "false" > > or remove the option altogether. > > The Option "dynamicclocks" didnt work, > I could not compile xorg with the patch cause now there is a bug in xorg's cvs > > xftdpy.c: In function `XftDefaultSubstitute': > xftdpy.c:495: error: `FC_RGBA_UNKNOWN' undeclared (first use in this function) > xftdpy.c:495: error: (Each undeclared identifier is reported only once > xftdpy.c:495: error: for each function it appears in.) > > If You want to reproduce it follow > http://incubator.vislab.usyd.edu.au/roller/page/Steve/20040909 > > I am using currently minimal version of xorg > as on http://dri.sourceforge.net/cgi-bin/moin.cgi/Building > and DRM from > cvs -z3 -d:pserver:anonymous@cvs.freedesktop.org:/cvs/dri co drm > on which patch will not apply. the patch only applies to the DDX in xorg cvs. It should be pretty easy to apply it manually. another alternative is simply to comment out the call to RADEONSetDynamicClock() in radeon_driver.c: #if 0 if (xf86ReturnOptValBool(info->Options, OPTION_DYNAMIC_PM, FALSE)) { RADEONSetDynamicClock(pScrn, 1); } else { RADEONSetDynamicClock(pScrn, 0); } #endif > > Could You give me directions How to debug kernel module drm ? > (In reply to comment #12) > the patch only applies to the DDX in xorg cvs. It should be pretty easy to > apply it manually. another alternative is simply to comment out the call to > RADEONSetDynamicClock() in radeon_driver.c: > > #if 0 > if (xf86ReturnOptValBool(info->Options, OPTION_DYNAMIC_PM, FALSE)) { > RADEONSetDynamicClock(pScrn, 1); > } else { > RADEONSetDynamicClock(pScrn, 0); > } > #endif With the patch, now direct rendering works fine, thx Mass version move, cvs -> git |
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.