I tried the drivers in the kernel, 2.4.17-pre8, with Torsten's
DRIVER_CTX_CTOR/DTOR fixes for SiS. I'm running XFree 4.1 from Red Hat
7.2.
I can confirm that this now allows me to get accelerated 3d with my
system, which is (selected lines from XFree startup):
(--) PCI:*(1:0:0) SiS 630 rev 49, Mem @ 0xd0000000/27, 0xdd000000/17, I/O
@ 0xd000/7
i.e. SiS630. I AM running with the SiS FB compiled into the kernel, which
works great for me (no segfaults oopsen whatever).
HOWEVER, any 3D program locks up after a certain amount of time.
Including the Mesa-demos package programs, tuxracer, chromium etc. (all
opengl programs that come with Red Hat). It SEEMS like the lockups are
due to interaction, i.e. keyboard or mouse. If I leave the keyboard and
mouse alone it looks like they'll run a lot longer.
When I say 'locks up' I mean: has control of X, isn't making any apparent
progress. Ctrl-Alt-F1 (switch consoles) doesn't work, but SysRq does. I
can SAK out back to the frame buffer.
I did some debugging and I found that the program is hanging in drm_drv.h
in the DRM(lock) function (from kernel sources, the only difference
between kernel and xf code is stuff enclosed in non-enabled ifdefs) at the
following schedule():
if ( DRM(lock_take)( &dev->lock.hw_lock->lock,
lock.context ) ) {
dev->lock.pid = current->pid;
dev->lock.lock_time = jiffies;
atomic_inc( &dev->counts[_DRM_STAT_LOCKS] );
break; /* Got lock */
}
/* Contention */
---> here schedule();
if ( signal_pending( current ) ) {
ret = -ERESTARTSYS;
break;
}
I put get_cycles around this schedule to see how long it sleeps in
general... and in this case, it slept until after the SAK was pressed,
most of the time it was returning 'interrupted' (i.e. ret != 0) after
about 1 million ticks (1.4 GHZ machine ~= 1ms?).
I wonder though, with only 'teapot' from Mesa-demos running, I saw that it
was sending a constant stream of ioctl(lock) requests, all of which were
returning 'interrupted'. Is this program contending with itself for the
lock, what's going in here? I can provide a complete printk trace or
strace if desired.
David
P.S. Why doesn't DRM use regular linux locking primitives? It looks like
DRM is recreating the wheel W.R.T spinlocks, and they're in C rather than
asm... I'm actually stupid, so actually there's probably a very good
reason :-)
--
/==============================\
| David Mansfield |
| [EMAIL PROTECTED] |
\==============================/
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
