Re: Intel 965G: i915_dispatch_cmdbuffer failed (2.6.19-rc2)
On Tue, Oct 24, 2006 at 02:21:42PM +0200, Avi Kivity wrote: Ryan Richter wrote: I had heard something previously about i965_dri.so maybe getting miscompiled, but I hadn't followed up on it until now. I rebuilt it with an older gcc, and now it's all working great! Sorry for the wild goose chase. It was probably me. I had the same experience, except that I recompiled using the system compiler. Possibly it got updated between the distro compilation of the driver and my own. So I don't think there's a need to try to reproduce it as it was probably fixed in gcc already. https://bugs.freedesktop.org/show_bug.cgi?id=8384 It worked for me when I recompiled with -fno-strict-aliasing (or with an older gcc - 3.4 rather than 4.1). -ryan - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Intel 965G: i915_dispatch_cmdbuffer failed (2.6.19-rc2)
On Fri, Oct 20, 2006 at 12:43:44PM +0100, Keith Whitwell wrote:
Ryan Richter wrote:
On Wed, Oct 18, 2006 at 07:54:41AM +0100, Keith Whitwell wrote:
This is all a little confusing as the driver doesn't really use that
path in normal operation except for a single command - MI_FLUSH, which
is shared between the architectures. In normal operation the hardware
does the validation for us for the bulk of the command stream. If there
were missing functionality in that ioctl, it would be failing
everywhere, not just in this one case.
I guess the questions I'd have are
- did the driver work before the kernel upgrade?
- what path in userspace is seeing you end up in this ioctl?
- and like Keith, what commands are you seeing?
The final question is interesting not because we want to extend the
ioctl to cover those, but because it will give a clue how you ended up
there in the first place.
Here's a list of all the failing commands I've seen so far:
3a440003
d70003
2d010003
e5b90003
2e730003
8d8c0003
c10003
d90003
be0003
1e3f0003
Ryan,
Those don't look like any commands I can recognize. I'm still confused
how you got onto this ioctl in the first place - it seems like something
pretty fundamental is going wrong somewhere. What would be useful to me
is if you can use GDB on your application and get a stacktrace for how
you end up in this ioctl in the cases where it is failing?
Additionally, if you're comfortable doing this, it would be helpful to
see all the arguments that userspace thinks its sending to the ioctl,
compared to what the kernel ends up thinking it has to validate. There
shouldn't ever be more than two dwords being validated at a time, and
they should look more or less exactly like {0x0203, 0}, and be
emitted from bmSetFence().
All of your other wierd problems, like the assert failures, etc, make me
wonder if there just hasn't been some sort of build problem that can
only be resolved by clearing it out and restarting.
It wouldn't hurt to just nuke your current Mesa and libdrm builds and
start from scratch - you'll probably have to do that to get debug
symbols for gdb anyway.
I had heard something previously about i965_dri.so maybe getting
miscompiled, but I hadn't followed up on it until now. I rebuilt it
with an older gcc, and now it's all working great! Sorry for the wild
goose chase.
Thanks,
-ryan
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Intel 965G: i915_dispatch_cmdbuffer failed (2.6.19-rc2)
On Fri, Oct 20, 2006 at 06:51:01PM +0100, Keith Whitwell wrote: Ryan Richter wrote: On Fri, Oct 20, 2006 at 12:43:44PM +0100, Keith Whitwell wrote: Ryan Richter wrote: On Wed, Oct 18, 2006 at 07:54:41AM +0100, Keith Whitwell wrote: All of your other wierd problems, like the assert failures, etc, make me wonder if there just hasn't been some sort of build problem that can only be resolved by clearing it out and restarting. It wouldn't hurt to just nuke your current Mesa and libdrm builds and start from scratch - you'll probably have to do that to get debug symbols for gdb anyway. I had heard something previously about i965_dri.so maybe getting miscompiled, but I hadn't followed up on it until now. I rebuilt it with an older gcc, and now it's all working great! Sorry for the wild goose chase. Out of interest, can you try again with the original GCC and see if the problem comes back? Which versions of GCC are you using? The two gcc versions are the 4.1 (miscompiles) and 3.4 (OK) from Debian unstable. I had originally compiled it myself with gcc-4.1 because the Debian libgl1-mesa-dri package didn't build i965_dri.so until I submitted a build patch to them to have it built. They released a new package a few days ago with i965_dri.so included, presumably built with the same gcc-4.1, the default cc on Debian unstable. I had exactly the same problems with my own version and theirs. I rebuilt it again today with CC=gcc-3.4 and now everything works great. I saved a copy of the old i965_dri.so, so I can verify in the next few days that replacing it breaks things again. Let me know if you want copies of these files to examine. -ryan - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Intel 965G: i915_dispatch_cmdbuffer failed (2.6.19-rc2)
On Wed, Oct 18, 2006 at 07:54:41AM +0100, Keith Whitwell wrote: This is all a little confusing as the driver doesn't really use that path in normal operation except for a single command - MI_FLUSH, which is shared between the architectures. In normal operation the hardware does the validation for us for the bulk of the command stream. If there were missing functionality in that ioctl, it would be failing everywhere, not just in this one case. I guess the questions I'd have are - did the driver work before the kernel upgrade? - what path in userspace is seeing you end up in this ioctl? - and like Keith, what commands are you seeing? The final question is interesting not because we want to extend the ioctl to cover those, but because it will give a clue how you ended up there in the first place. Here's a list of all the failing commands I've seen so far: 3a440003 d70003 2d010003 e5b90003 2e730003 8d8c0003 c10003 d90003 be0003 1e3f0003 -ryan - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Intel 965G: i915_dispatch_cmdbuffer failed (2.6.19-rc2)
On Sat, Oct 14, 2006 at 11:15:23AM -0700, Keith Packard wrote:
On Fri, 2006-10-13 at 15:45 -0400, Ryan Richter wrote:
I have a new Intel 965G board, and I'm trying to get DRI working.
Direct rendering is enabled, but all GL programs crash immediately.
The message 'DRM_I830_CMDBUFFER: -22' is printed on the tty, and the
kernel says:
[drm:i915_cmdbuffer] *ERROR* i915_dispatch_cmdbuffer failed
The 915 DRM validates commands sent to the card from the application to
ensure they aren't directing the card to access memory outside of the
graphics area. At present the module validates only 915/945 commands
correctly and the 965 uses slightly different commands. I haven't walked
over the entire GL library, but it seems possible that this error is
being caused by the mis-validation of the command stream. We need to
update the DRM driver to reflect the new commands, but in the meanwhile,
you might try disabling the validation in the kernel (which will expose
your system to a local root compromise) and seeing if that doesn't
eliminate this message.
So do I want something like
static int do_validate_cmd(int cmd)
{
return 1;
}
in i915_dma.c?
Thanks,
-ryan
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Intel 965G: i915_dispatch_cmdbuffer failed (2.6.19-rc2)
On Wed, Oct 18, 2006 at 06:27:42AM +0800, Keith Packard wrote:
On Tue, 2006-10-17 at 13:40 -0400, Ryan Richter wrote:
So do I want something like
static int do_validate_cmd(int cmd)
{
return 1;
}
in i915_dma.c?
that will certainly avoid any checks. Another alternative is to printk
the cmd which fails validation so we can see what needs adding here.
With just the above, running a GL client (even glxinfo) locks up the
display such that it can't be recovered without a reboot. It doesn't
kill the machine, though. What looks like a 64x64 block of garbage
appears on the screen. The kernel says
[drm:i915_wait_irq] *ERROR* i915_wait_irq: EBUSY -- rec: 0 emitted: 2
If instead I change the validate_cmd function to:
static int validate_cmd(int cmd)
{
int ret = do_validate_cmd(cmd);
if(!ret)
printk(validate_cmd( %x ): %d\n, cmd, ret);
return 1;
}
I get basically the same behavior, but different output:
validate_cmd( 1e3f0003 ): 0
validate_cmd( 1e3f0003 ): 0
validate_cmd( d90003 ): 0
validate_cmd( d90003 ): 0
validate_cmd( d70003 ): 0
validate_cmd( d90003 ): 0
validate_cmd( d90003 ): 0
validate_cmd( d90003 ): 0
validate_cmd( d90003 ): 0
validate_cmd( 8d8c0003 ): 0
validate_cmd( d70003 ): 0
[drm:i915_batchbuffer] *ERROR* i915_batchbuffer called without lock held
Thanks,
-ryan
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Intel 965G: i915_dispatch_cmdbuffer failed (2.6.19-rc2)
I have a new Intel 965G board, and I'm trying to get DRI working. Direct rendering is enabled, but all GL programs crash immediately. The message 'DRM_I830_CMDBUFFER: -22' is printed on the tty, and the kernel says: [drm:i915_cmdbuffer] *ERROR* i915_dispatch_cmdbuffer failed Additionally, glxinfo says (in addition to its normal output): glxinfo: bufmgr_fake.c:1245: bmReleaseBuffers: Assertion `intel-locked' failed. This is with 2.6.19-rc2 (and -rc1). Here's a .config and dmesg: # # Automatically generated make config: don't edit # Linux kernel version: 2.6.19-rc2 # Fri Oct 13 13:42:19 2006 # CONFIG_X86_64=y CONFIG_64BIT=y CONFIG_X86=y CONFIG_ZONE_DMA32=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_MMU=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_CMPXCHG=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_DMI=y CONFIG_AUDIT_ARCH=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set # CONFIG_POSIX_MQUEUE is not set # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set # CONFIG_IKCONFIG is not set # CONFIG_CPUSETS is not set CONFIG_RELAY=y CONFIG_INITRAMFS_SOURCE= CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y # CONFIG_SYSCTL_SYSCALL is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set # CONFIG_KMOD is not set CONFIG_STOP_MACHINE=y # # Block layer # CONFIG_BLOCK=y CONFIG_LBD=y # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=anticipatory # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_VSMP is not set # CONFIG_MK8 is not set CONFIG_MPSC=y # CONFIG_GENERIC_CPU is not set CONFIG_X86_L1_CACHE_BYTES=128 CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_X86_INTERNODE_CACHE_BYTES=128 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_MICROCODE=y CONFIG_MICROCODE_OLD_INTERFACE=y # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set CONFIG_X86_HT=y CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_MTRR=y CONFIG_SMP=y # CONFIG_SCHED_SMT is not set CONFIG_SCHED_MC=y CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set CONFIG_PREEMPT_BKL=y # CONFIG_NUMA is not set CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 CONFIG_RESOURCES_64BIT=y CONFIG_NR_CPUS=8 # CONFIG_HOTPLUG_CPU is not set CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y CONFIG_IOMMU=y # CONFIG_CALGARY_IOMMU is not set CONFIG_SWIOTLB=y CONFIG_X86_MCE=y CONFIG_X86_MCE_INTEL=y # CONFIG_X86_MCE_AMD is not set # CONFIG_KEXEC is not set # CONFIG_CRASH_DUMP is not set CONFIG_PHYSICAL_START=0x20 CONFIG_SECCOMP=y # CONFIG_CC_STACKPROTECTOR is not set # CONFIG_HZ_100 is not set # CONFIG_HZ_250 is not set CONFIG_HZ_1000=y CONFIG_HZ=1000 # CONFIG_REORDER is not set CONFIG_K8_NB=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_ISA_DMA_API=y CONFIG_GENERIC_PENDING_IRQ=y # # Power management options # CONFIG_PM=y CONFIG_PM_LEGACY=y # CONFIG_PM_DEBUG is not set # CONFIG_PM_SYSFS_DEPRECATED is not set # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y # CONFIG_ACPI_AC is not set # CONFIG_ACPI_BATTERY is not set CONFIG_ACPI_BUTTON=y CONFIG_ACPI_VIDEO=y # CONFIG_ACPI_HOTKEY is not set CONFIG_ACPI_FAN=y # CONFIG_ACPI_DOCK is not set CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_THERMAL=y # CONFIG_ACPI_ASUS is not set # CONFIG_ACPI_IBM is not set # CONFIG_ACPI_TOSHIBA is not set CONFIG_ACPI_BLACKLIST_YEAR=0 # CONFIG_ACPI_DEBUG is not set CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_SYSTEM=y CONFIG_X86_PM_TIMER=y # CONFIG_ACPI_CONTAINER
R200 lockup (was Re: DRI/X error resolution)
On Thu, Sep 21, 2006 at 11:23:08PM -0500, Stephen Olander Waters wrote: Hey, Did they ever fix that bug you reported here? http://lkml.org/lkml/2005/5/11/121 I'm having the same problem! Argh! No, sad to say it still happens to us too. Argh is right! I'll cc this to dri-devel and lkml in case anyone wants to try hunting the bug again. FWIW, I'm still seeing the ioctl(5, 0x6444, 0) / SIGALARM behavior I reported originally. This has continued to happen regularly with all 2.6 kernels up to 2.6.17.6 and Xfree/X.org up to 6.9. -ryan - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R200 lockup (was Re: DRI/X error resolution)
On Thu, Sep 21, 2006 at 11:54:01PM -0500, Stephen Olander Waters wrote: Here is the bug I'm working from (includes hardware, software, etc.): https://bugs.freedesktop.org/show_bug.cgi?id=6111 DRI will work if you set: Option BusType PCI ... but that's not a real solution. :) Oh, wow. I had no idea there was a workaround. What kind of performance hit does that entail? R200 performance is pretty dismal to begin with, but it would be awfully nice to not have all our workstations crashing all the time... I wonder why that works. What chipset do you use? All our machines are AMD 8151. I'm about to leave town for several days, but I'll try that when I return. Cheers, -ryan - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R200 lockup (was Re: DRI/X error resolution)
On Fri, Sep 22, 2006 at 03:29:48PM +1000, Dave Airlie wrote: On 9/22/06, Ryan Richter [EMAIL PROTECTED] wrote: On Thu, Sep 21, 2006 at 11:54:01PM -0500, Stephen Olander Waters wrote: Here is the bug I'm working from (includes hardware, software, etc.): https://bugs.freedesktop.org/show_bug.cgi?id=6111 DRI will work if you set: Option BusType PCI ... but that's not a real solution. :) I really think this more AGP related a bug in the driver for the VIA AGP chipsets what AGP chipset are you guys using? AMD 8151 here. I have yet to try Option BusType PCI, so I can't say if that works here (it'll be a week or so before I have a chance to try). -ryan - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI lockup on R200, 2.6.11.7
So I just got around to testing this today. Using NO_TCL locks the
machine immediately:
[drm:drm_lock_take] *ERROR* 4 holds heavyweight lock
X isn't spinning the CPU, but the overall effect is the same. When I
move the mouse it's doing:
ioctl(5, 0x4008642a, 0x7448)= ? ERESTARTSYS (To be restarted)
--- SIGIO (I/O possible) @ 0 (0) ---
select(7, [5 6], NULL, NULL, {0, 0})= 1 (in [6], left {0, 0})
rt_sigprocmask(SIG_BLOCK, [IO], [IO], 8) = 0
read(6, \10\3\4\0, 64)= 4
rt_sigprocmask(SIG_BLOCK, [], [IO], 8) = 0
select(1024, [6], NULL, NULL, {0, 0}) = 0 (Timeout)
rt_sigreturn(0x1) = -1 EINTR (Interrupted system call)
ioctl(5, 0x4008642a, 0x7448)= ? ERESTARTSYS (To be restarted)
Also, I tried to kill X using a sysrq-k and got:
SysRq : SAK
Badness in set_palette at drivers/char/vt.c:2918
Call Trace:8022391c{set_palette+60}
802244db{__handle_sysrq+107}
80195bd5{write_sysrq_trigger+53}
80166510{vfs_write+192}
8013{sys_write+83} 8010d13a{system_call+126}
-ryan
---
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI lockup on R200, 2.6.11.7
On Sun, May 15, 2005 at 11:38:28AM +0100, Dave Airlie wrote: If you are using bash: export tcl_mode=0 glxinfo will show that tcl is off: NO-TCL in the renderer string. start your programm from this shell and it should run in sw-tcl mode. Are you using r200_dri.so compiled from current mesa-cvs repository? @dri-devel: or is Debians XFree 4.3 too old to use current dri drivers? with XF4.3 you might need to use RADEON_NO_TCL=1 instead, I've no idea when we changed it over... XF4.3 will have issues in the userspace DRI driver that can crash a machine, it is old old old... I don't think changing the kernel will make it any more stable/unstable.. Hmm... $ export tcl_mode=0 $ export RADEON_NO_TCL=1 $ glxinfo|grep -i tcl OpenGL renderer string: Mesa DRI R200 20020827 AGP 1x TCL ? Thanks, -ryan --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393alloc_id=16281op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI lockup on R200, 2.6.11.7
On Sun, May 15, 2005 at 11:38:28AM +0100, Dave Airlie wrote: with XF4.3 you might need to use RADEON_NO_TCL=1 instead, I've no idea Nevermind, it's R200_NO_TCL=1. I'll start testing this out on Monday. By the way, what is TCL? :) -ryan --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393alloc_id=16281op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI lockup on R200, 2.6.11.7
On Sat, May 14, 2005 at 12:50:51PM +0200, Andreas Stenglein wrote: Does the lockup occur when disabling hw-tcl? This is part of X, right? Can you explain how to do that? :) Thanks, -ryan --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393alloc_id=16281op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI lockup on R200, 2.6.11.7
On Sat, May 14, 2005 at 09:00:47PM +0200, khaqq wrote: The easiest way is probably to use DRIConf available at : http://dri.freedesktop.org/wiki/DriConf I'm using Xfree 4.3 (Debian sid), so I don't think that will work. Is this even applicable to this version of X? -ryan --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393alloc_id=16281op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI lockup on R200, 2.6.11.7
On Thu, Apr 28, 2005 at 09:22:36AM +0100, Dave Airlie wrote: On 4/26/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Using 2.6.11.7, I'm experiencing the same problem as reported here: http://lkml.org/lkml/2005/3/12/99 Except it happens for me after X is running. X locks up, only the mouse pointer moves, X spins doing this: --- SIGALRM (Alarm clock) @ 0 (0) --- rt_sigreturn(0xe) = -1 EBUSY (Device or resource busy) ioctl(5, 0x6444, 0) = -1 EBUSY (Device or resource busy) ioctl(5, 0x6444, 0) = -1 EBUSY (Device or resource busy) Another one today, but it's a little different now. I got to see this happen from the beginning today. A few minutes before the crash, 3D operations become very slow. When X hangs, it's now doing this: --- SIGALRM (Alarm clock) @ 0 (0) --- rt_sigreturn(0xe) = -1 EBUSY (Device or resource busy) ioctl(5, 0xc0406429, 0x7490)= -1 EBUSY (Device or resource busy) ioctl(5, 0xc0406429, 0x7490)= -1 EBUSY (Device or resource busy) It seems to only happen when there are two or more opengl programs running. I killed X again, but the machine was still very slow. Investigating, I found the two GL processes still running, both eating lots of cycles. Before I could find out what they were doing, xdm restarted X, which caused a machine reset. I know this because I was (confusedly) stracing the new X as it was coming up. X was stat(2)ing the video driver modules right before the reset... -ryan --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393alloc_id=16281op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI lockup on R200, 2.6.11.7
On Thu, Apr 28, 2005 at 09:22:36AM +0100, Dave Airlie wrote: 2.6.12 should fix this, there is patch at: http://drm.bkbits.net:8080/drm-linus/[EMAIL PROTECTED] Another crash today, same thing. It seems to have made it less common, though (maybe). One thing that was different was that this time killing X didn't reset the machine. -ryan --- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
