From: <rm...@ea...> - 2001-03-07 00:02:20
|
My system is a dual celeron 433 with 128MB ram, and a Voodoo5, linux 2.4.2-ac12 kernel running Debian unstable. With cvs, 2001/03/06, with merged tdfx-3-1-0-branch, I am having a number of problems. It compiled and installed without any errors, but in quake 1 and chromium bsu it's rendering anything textured in brilliant shades of blue. Untextured mostly looks fine. Lament screensaver is red with blue highlights. glxinfo is also segfaulting in the list of GL extensions. I'm also occaisionally seeing messages in syslog like this: Mar 6 14:59:12 leng kernel: [drm:drm_release] *ERROR* Process 954 dead, freeing lock for context 3 I wondered if it might be the drm being out of date, so tried installing the module from dri cvs, only to have depmod curl up in a ball and start crying. depmod -e depmod: *** Unresolved symbols in /lib/modules/2.4.2-ac12/kernel/drivers/char/drm/tdfx.o depmod: tdfx_agp_unbind_memory depmod: tdfx_agp_bind_memory depmod: tdfx_agp_allocate_memory depmod: tdfx_agp_free_memory So what obvious thing did I miss? Anything else I should try? Any other information you need? Oh, and amusing aside, other than overwhelming blueness, things seem to work reasonably well in quakeforge. Even a 5% speedup on timedemo demo1. :) Thanks! Ragnvald Maartmann-Moe IV |
From: Rik F. <fa...@va...> - 2000-08-18 00:27:37
|
On Thu 17 Aug 2000 17:35:22 -0400, Gareth Hughes <ga...@va...> wrote: > Rik Faith wrote: > > > > What if I lump core dumps with hangs? do you want to keep those separate, > > too? > > > > X core dump or hang > > Client core dump or hang > > Kernel panic or system hang > > That's a nicer breakdown. Sorry to be pedantic, but we might want to > keep kernel oopses and panics separate again, so we'd have: > > X core dump or hang > Client core dump or hang > Full system hang/bus lockup (power cycle to fix etc) > Kernel panic or oops > > -- Gareth Often it's impossible to tell the difference. E.g., a panic leads to a lockup, or a lockup would have caused a panic if only syslogd could write it out to a file. |
From: Rik F. <fa...@va...> - 2000-08-18 00:55:52
|
On Thu 17 Aug 2000 20:39:22 -0400, Gareth Hughes <ga...@va...> wrote: > Rik Faith wrote: > > > > Often it's impossible to tell the difference. E.g., a panic leads to a > > lockup, or a lockup would have caused a panic if only syslogd could write > > it out to a file. > > I was thinking that it might be nice to differentiate when you know for > sure it's a panic or an oops, rather than just bundling those bugs in > with the system hang ones. If you can't tell, it would go in the system > hang category. What do you think? I think that the fewer choices we have, the more accurate the reporting will be. We'll be using the categorization to get an idea of how severe the bug is. It seems to me that if it's an oops, panic, or complete system hang, it's a pretty bad bug (although, I grant you that oops are by far the easiest to fix). |
From: Rik F. <fa...@va...> - 2000-10-09 12:22:15
|
On Mon 9 Oct 2000 13:49:20 +1100, Gareth Hughes <ga...@va...> wrote: > What's the policy to get this fixed? I've submitted a support request > on SourceForge, but is there a faster way to get this fixed? There is an irc channel that some SF folks hang out on (I think a pointer to it is on the main SF page). I've had sporadically quicker results from the irc channel than from support requests. |
From: Rik F. <fa...@va...> - 2000-11-16 14:44:37
|
On Thu 16 Nov 2000 11:27:14 +1100, Gareth Hughes <ga...@va...> wrote: > Rik Faith wrote: > > > > > The trunk is currently sync'd with 2.4.0-test11-pre5 and won't work > > > with kernels prior to 2.4.0-test11-pre1. > > I've tried to remain vigilant about taking these updates onto the > branches. Typically, it just requires a merge from the trunk in > .../linux/drm/kernel and that's it. If we try and keep all the branches > up to date, then people will fairly quickly determine that they have to > update their kernel to match. If we keep the "blessed" version > consistent across all branches hopefully these problems will be > minimized. This would also allow us to clearly advertise the version of > 2.4.0 that must be used with anything from DRI CVS. > > Comments? We can make this part of the DRI development process and thus > clearly document it. The only caveat I have is that there are different and possibly conflicting reasons for upgrading the kernel modules on the trunk vs. on a branch: 1) Syncs with the trunk are usually driven by Linus' release plans. In this case, Linus has said that he wants to release 2.4.0 within the next 1-2 months, so we really have to hurry to get everything tested and patched. 2) On a branch, I can envision the driving goal to be to complete some unrelated part of the driver for a deliverable, and that fiddling with a kernel module sync and kernel upgrade may take away precious development time from that goal. I'd be in favor of pushing all kernel module changes that occur on the trunk into the branches asap, assuming there are no constraints such as those in #2 above. [Everyone needs to remember that the trunk is the only "blessed" version, and that ANYTHING on a branch is completely unsupported and may require more digging and more fiddling to get working. That may include tracking kernels at a different rate than for the trunk.] |
From: Rik F. <fa...@va...> - 2000-12-19 16:19:48
|
On Tue 19 Dec 2000 10:22:49 +1100, Gareth Hughes <ga...@va...> wrote: > Does anyone have any objections to me resyncing the trunk with the > latest kernel sources? Please. Note that the wait queues have moved to using a linked list that will need some special backward-compatibility handling (i.e., probably by defining the same macro in the compat-pre24.h file that 2.4.0-test* is currently using -- that would avoid #ifdef's in the code). |
From: Rik F. <fa...@va...> - 2000-12-29 04:46:16
|
On Sat 23 Dec 2000 17:47:34 +1100, Gareth Hughes <ga...@va...> wrote: > Has anyone been getting mail from dri-patches? It's been around five > days since I got a CVS update notification, and I've done several > checkins since then. Checkins haven't been working since the 18th -- see other email regarding this. Bug reports to dri-patches worked on the 26th. Mail sent directly to the dri-patches list didn't work today. Argh. See http://www.geocrawler.com/lists/3/SourceForge/678/0/ for a recent list. |
From: Rik F. <fa...@va...> - 2001-01-08 20:13:19
|
On Tue 9 Jan 2001 05:25:31 +1100, Gareth Hughes <ga...@va...> wrote: > <faq> > If your logs and informative programs such as glxinfo suggest that the > DRI is initialized but you only get "Indirect" rendering, you should > verify that you have set the DRI permissions correctly. If you want to > grant direct rendering access to anyone, not just clients with superuser > privileges, then make sure your XF86Config file has the following > section: > > Section "DRI" > Mode 0666 > EndSection > > For more information, see the DRI User's Guide. > </faq> Sorry for picking on the wording, but I think it's important to make people understand two things about the DRI: 1) Direct-rendering access is always restricted to authenticated X clients (i.e., the DRI respects xauth), regardless of the mode of the /dev/dri/card* device. 2) We support an intermediate between "root only" and "everyone": the user can specify a group of users who are allowed to use direct rendering, e.g., Section "DRI" Group "driusers" Mode 0660 EndSection This is in the FAQ, but I'm worried that the change in wording will make people misunderstand the capabilities available. |
From: <dax...@gu...> - 2001-01-08 21:51:00
|
Rik Faith said once upon a time (Mon, 8 Jan 2001): > Sorry for picking on the wording, but I think it's important to make > people understand two things about the DRI: > 1) Direct-rendering access is always restricted to authenticated X > clients (i.e., the DRI respects xauth), regardless of the mode of > the /dev/dri/card* device. > 2) We support an intermediate between "root only" and "everyone": > the user can specify a group of users who are allowed to use > direct rendering, e.g., > > Section "DRI" > Group "driusers" > Mode 0660 > EndSection > > This is in the FAQ, but I'm worried that the change in wording will make > people misunderstand the capabilities available. On a Red Hat 7 (and up), the permissions on on /dev/dri/* are 600, and have the OWNERSHIP of whoever logged in at the console. If there isn't anybody currently logged in at the console, the ownership is "root". Shouldn't this configuration enable DRI to work in the most secure method? Shouldn't this enable DRI to work without the need for the "Section "DRI"....blah blah Mode 660..blah" addition to your XF86Config file? On my RH7, I *STILL* had to add the Section "DRI", mode 0666" to my XF86Config file. Why is this? Are there improper assumptions being made by the X server? Dax |
From: Daryll S. <da...@va...> - 2001-01-08 22:31:37
|
On Mon, Jan 08, 2001 at 02:51:15PM -0700, dax...@gu... wrote: > On a Red Hat 7 (and up), the permissions on on /dev/dri/* are 600, and > have the OWNERSHIP of whoever logged in at the console. If there isn't > anybody currently logged in at the console, the ownership is "root". > > Shouldn't this configuration enable DRI to work in the most secure method? > > Shouldn't this enable DRI to work without the need for the "Section > "DRI"....blah blah Mode 660..blah" addition to your XF86Config file? > > On my RH7, I *STILL* had to add the Section "DRI", mode 0666" to my > XF86Config file. Why is this? Are there improper assumptions being made > by the X server? Red Hat didn't understand the security model and their setup is somewhat broken. The problem is that the X server will recreate the device with the permissions specified when it restarts. The DRI section really does need to be included in the config file. I assume Red Hat will fix this problem in their next release, since I've talked to them about it. - |Daryll |
From: Rik F. <fa...@va...> - 2001-01-24 02:12:44
|
On Wed 24 Jan 2001 13:08:31 +1100, Gareth Hughes <ga...@va...> wrote: > Yes, absolutely. I think I suggested the DRICheckVersion()-like calls > should only take a major and a minor number, to allow the semantics you > describe above. I didn't mean to take credit for the semantics -- they were proposed by you and Keith and others. I just wanted to point out that I thought we had agreed on those semantics, so we should be able to eliminate testing patchlevel in the code. |
From: Rik F. <fa...@va...> - 2001-01-24 02:27:44
|
On Wed 24 Jan 2001 13:20:20 +1100, Gareth Hughes <ga...@va...> wrote: > Rik Faith wrote: > > > > On Wed 24 Jan 2001 12:54:02 +1100, > > Gareth Hughes <ga...@va...> wrote: > > > Do you mind if I update the LINUX_KERNEL_VERSION tests to use the > > > KERNEL_VERSION() macro? > > > > Please do _NOT_ do this. It was like that and caused a world of > > problems (e.g., when the stand-alone version doesn't pick up the > > KERNEL_VERSION macro because the header files are layed out differently > > in that kernel vs. the one that we test with). > > What about defining KERNEL_VERSION if is isn't already defined? Other > code in the kernel does this... There was a problem with doing that because it has to be done early and then the kernel might define it later (at which time, it's already defined). You can try it -- you might have changed enough that it works now. But try the stand-alone version with both 2.2 and 2.4. I guess I don't see why it's worth doing _any_ work to use KERNEL_VERSION. It doesn't provide any benefit that a comment won't provide (and even that isn't necessary for people with 16 fingers :). |
From: Rik F. <fa...@va...> - 2001-01-24 02:33:12
|
On Wed 24 Jan 2001 13:29:42 +1100, Gareth Hughes <ga...@va...> wrote: > Rik Faith wrote: > > > > There was a problem with doing that because it has to be done early and > > then the kernel might define it later (at which time, it's already > > defined). You can try it -- you might have changed enough that it works > > now. But try the stand-alone version with both 2.2 and 2.4. > > > > I guess I don't see why it's worth doing _any_ work to use > > KERNEL_VERSION. It doesn't provide any benefit that a comment won't > > provide (and even that isn't necessary for people with 16 fingers :). > > I was just thinking of keeping things consistent (ie. doing what the > rest of the kernel code does). But it doesn't. Some drivers use LINUX_VERSION_CODE and others use KERNEL_VERSION. > I don't really care that much, and as you say, there are so many more > important things to do ;-) |
From: Rik F. <fa...@va...> - 2001-01-24 10:20:10
|
On Wed 24 Jan 2001 16:39:49 +1100, Gareth Hughes <ga...@va...> wrote: > I'm sure everyone who's ported the DRI to a non-x86 platform has come > across the following problem. You can see that combining these two > macros will lead to interesting results... > > #ifndef DRM_CAS > #define DRM_CAS(lock,old,new,ret) do { ret=1; } while (0) /* FAST LOCK > FAILS */ > #endif > > #define DRM_SPINLOCK_TAKE(spin,val) \ > do { \ > DRM_CAS_RESULT(__ret); \ > int cur; \ > do { \ > cur = (*spin).lock; \ > DRM_CAS(spin,cur,val,__ret); \ > } while (__ret); \ > } while(0) > > This should compile nicely to: > > char __ret; > do { > __ret = 1; > } while ( __ret ); > > Perhaps we should think about enforcing DRM_CAS to be defined on all > platforms? While the goal is to implement DRM_CAS on all platforms, our original thought was that the DRI should still work (and be slower) during the development stages on new platforms before DRM_CAS is implemented. First, we should move away from the DRM_CAS __ret semantics to the cmpxchg semantics used in the kernel. Then the while loop compares old with new. The solution to this particular problem is either to: 1) leave DRM_CAS (or cmpxchg) undefined to force people to define it before doing anything else, or 2) to make is so that DRM_SPINLOCK_* is defined differently if DRM_CAS isn't defined. Early on, we wanted to make it as easy as possible to get the DRI working on a new platform. Now, however, there are many examples in the kernel of how to implements cmpxchg/DRM_CAS, so this particular problem shouldn't be a difficulty. Therefore, I'm inclined to #1. |
From: Rik F. <fa...@va...> - 2001-02-14 14:24:29
|
On Wed 14 Feb 2001 15:16:07 +1100, Gareth Hughes <ga...@va...> wrote: > Keith Whitwell wrote: > > > > > > tdfx_drv.c: > > > > > > > > #include <linux/config.h> > > > > #include "tdfx.h" > > > > #include "drmP.h" > ^^^^^^^^^^^^^^^^^ > > Notice no "#define __NO_VERSION__"... > > > > > tdfx_drm.c: > > > > > > > > #define __NO_VERSION__ > > > > #include "tdfx.h" > > > > #include "drmP.h" > > And here we do have one... > > > Is there any reason to maintain two .c files? > > __NO_VERSION__ isn't used in 2.4 anymore, and I'd be really happy to see > _drm.c and _drv.c merged into a single file. Comments, Rik? It was convenient when the code was larger. I'm in favor of merging them if it makes things clearer, easier, etc. This should be the case even for drivers that are not as trivial as tdfx. |
From: Rik F. <fa...@va...> - 2001-02-17 10:55:16
|
On Sat 17 Feb 2001 19:18:11 +1100, Gareth Hughes <ga...@va...> wrote: > xc/programs/Xserver/render/picture.c on the mga-1-0-0-branch is version > 1.1.1.4.somthing, while the version on the trunk is 1.2. 'cvs log > picture.c' reveals the following: > > ... > sarea-1-0-0-branch: 1.1.1.5.0.8 > mga-1-0-0-20010215-merge: 1.1.1.5 > mga-1-0-0-20010215-freeze: 1.1.1.4.4.1 > ... > X_4_0_2-20001221-merge: 1.1.1.5 > X_4_0_2: 1.1.1.5 > ... > X_4_0_1g-20001130-merge: 1.1.1.4 > X_4_0_1g: 1.1.1.4 > X_4_0_1f-20001130-merge: 1.1.1.3 > X_4_0_1f: 1.1.1.3 > X_4_0_1e-20001107-merge: 1.1.1.3 > X_4_0_1e: 1.1.1.3 > X_4_0_1d-20001107-merge: 1.2 > X_4_0_1d: 1.1.1.3 > ... > > We see the 4.0.1d made a version 1.2, while all the ones after that made > versions 1.1.1.something. Perhaps this file (and others) weren't fixed > by Rik's work? Argh. I fixed all the files that were missing a branch: field that had a head: field of 1.1 -- those are the only files we've seen the CVS bug with. However, this file has no branch: tag BUT it has a head: tag of 1.2. I think it should have a branch: tag of 1.2.2. David, do you agree? I'll search for other files like this one. |
From: Rik F. <fa...@va...> - 2001-02-17 15:33:36
|
On Sat 17 Feb 2001 19:18:11 +1100, Gareth Hughes <ga...@va...> wrote: > xc/programs/Xserver/render/picture.c on the mga-1-0-0-branch is version > 1.1.1.4.somthing, while the version on the trunk is 1.2. 'cvs log > picture.c' reveals the following: > > ... > sarea-1-0-0-branch: 1.1.1.5.0.8 > mga-1-0-0-20010215-merge: 1.1.1.5 > mga-1-0-0-20010215-freeze: 1.1.1.4.4.1 > ... > X_4_0_2-20001221-merge: 1.1.1.5 > X_4_0_2: 1.1.1.5 > ... > X_4_0_1g-20001130-merge: 1.1.1.4 > X_4_0_1g: 1.1.1.4 > X_4_0_1f-20001130-merge: 1.1.1.3 > X_4_0_1f: 1.1.1.3 > X_4_0_1e-20001107-merge: 1.1.1.3 > X_4_0_1e: 1.1.1.3 > X_4_0_1d-20001107-merge: 1.2 > X_4_0_1d: 1.1.1.3 > ... > > We see the 4.0.1d made a version 1.2, while all the ones after that made > versions 1.1.1.something. Perhaps this file (and others) weren't fixed > by Rik's work? Ok, I've fixed 62 additional files that weren't in the first set: $ cvs log -N -r1.2.2.1 -r1.3 \ | agrep -d'$$' '^branch:$' \ | agrep -d'$$' '^head: 1\.2$' \ | agrep -d'$$' 'revision 1\.2\.2\.1' \ | agrep -v -d'$$' 'revision 1\.3' \ | fgrep 'Working file:' \ | sed 's,Working file: ,,' \ | fgrep -v /Attic/ \ > /tmp/OUTPUT-1.2.2 $ for i in `cat /tmp/OUTPUT-1.2.2`; do echo $i cvs admin -b1.2.2 $i done Note that it's extremely important that NO ONE ever runs a 'cvs admin' command without extensive discussion. Also, if you used Gareth's quick work around, remember to use -A when you 'cvs update' to remove the sticky tag. I'm doing another update and make World now... |
From: Kevin E M. <ma...@va...> - 2001-02-17 17:19:30
|
On Sat, Feb 17, 2001 at 10:34:24AM -0500, Rik Faith wrote: > On Sat 17 Feb 2001 19:18:11 +1100, > Gareth Hughes <ga...@va...> wrote: > > xc/programs/Xserver/render/picture.c on the mga-1-0-0-branch is version > > 1.1.1.4.somthing, while the version on the trunk is 1.2. 'cvs log > > picture.c' reveals the following: > > > > ... > > sarea-1-0-0-branch: 1.1.1.5.0.8 > > mga-1-0-0-20010215-merge: 1.1.1.5 > > mga-1-0-0-20010215-freeze: 1.1.1.4.4.1 > > ... > > X_4_0_2-20001221-merge: 1.1.1.5 > > X_4_0_2: 1.1.1.5 > > ... > > X_4_0_1g-20001130-merge: 1.1.1.4 > > X_4_0_1g: 1.1.1.4 > > X_4_0_1f-20001130-merge: 1.1.1.3 > > X_4_0_1f: 1.1.1.3 > > X_4_0_1e-20001107-merge: 1.1.1.3 > > X_4_0_1e: 1.1.1.3 > > X_4_0_1d-20001107-merge: 1.2 > > X_4_0_1d: 1.1.1.3 > > ... > > > > We see the 4.0.1d made a version 1.2, while all the ones after that made > > versions 1.1.1.something. Perhaps this file (and others) weren't fixed > > by Rik's work? > > Ok, I've fixed 62 additional files that weren't in the first set: > > $ cvs log -N -r1.2.2.1 -r1.3 \ > | agrep -d'$$' '^branch:$' \ > | agrep -d'$$' '^head: 1\.2$' \ > | agrep -d'$$' 'revision 1\.2\.2\.1' \ > | agrep -v -d'$$' 'revision 1\.3' \ > | fgrep 'Working file:' \ > | sed 's,Working file: ,,' \ > | fgrep -v /Attic/ \ > > /tmp/OUTPUT-1.2.2 > > $ for i in `cat /tmp/OUTPUT-1.2.2`; do > echo $i > cvs admin -b1.2.2 $i > done > > Note that it's extremely important that NO ONE ever runs a 'cvs admin' > command without extensive discussion. > > Also, if you used Gareth's quick work around, remember to use -A when > you 'cvs update' to remove the sticky tag. > > I'm doing another update and make World now... I just finished a complete "make World", and it appears to be working again. Thanks Rik!! Kevin |
From: Gareth H. <ga...@va...> - 2001-02-17 17:25:23
|
Kevin E Martin wrote: > > I just finished a complete "make World", and it appears to be working > again. Thanks Rik!! Thanks for taking care of this, Rik! Do we know how to prevent this from happening again? -- Gareth |
From: Gareth H. <ga...@va...> - 2001-03-07 02:20:59
|
rm...@ea... wrote: > > I'm also occaisionally seeing messages in syslog like this: > > Mar 6 14:59:12 leng kernel: [drm:drm_release] *ERROR* Process 954 dead, freeing lock for context 3 This is not a bug. This isn't even an error. You get this when you Ctrl-C an application rather than letting it shutdown normally. Rik, can we get rid of this message? I'm a little tired of seeing bug reports about it :-) -- Gareth |
From: Gareth H. <ga...@va...> - 2001-03-07 04:10:31
|
rm...@ea... wrote: > > My system is a dual celeron 433 with 128MB ram, and a Voodoo5, linux 2.4.2-ac12 kernel running Debian unstable. > > With cvs, 2001/03/06, with merged tdfx-3-1-0-branch, I am having a number of problems. It compiled and installed without any errors, but in quake 1 and chromium bsu it's rendering anything textured in brilliant shades of blue. Untextured mostly looks fine. Lament screensaver is red with blue highlights. I'll take a look. Can you remind me where I can get a copy of Chromium BSU? -- Gareth |
From: Iain T. <Iai...@nt...> - 2001-03-07 05:42:22
|
On Wed, 7 Mar 2001, Gareth Hughes wrote: > I'll take a look. Can you remind me where I can get a copy of > Chromium BSU? http://www.reptilelabour.com/software/chromium/download.htm -- Regards, Iai...@di.... My website: http://www.warwick.ac.uk/~csuli/ XMMS not playing |
From: Gareth H. <ga...@va...> - 2001-03-07 07:30:31
|
Gareth Hughes wrote: > > rm...@ea... wrote: > > > > My system is a dual celeron 433 with 128MB ram, and a Voodoo5, linux 2.4.2-ac12 kernel running Debian unstable. > > > > With cvs, 2001/03/06, with merged tdfx-3-1-0-branch, I am having a number of problems. It compiled and installed without any errors, but in quake 1 and chromium bsu it's rendering anything textured in brilliant shades of blue. Untextured mostly looks fine. Lament screensaver is red with blue highlights. > > I'll take a look. Can you remind me where I can get a copy of Chromium > BSU? There'll both fine here on my V5. It sounds like it's a V3-specific issue... -- Gareth |
From: Gareth H. <ga...@va...> - 2001-03-07 07:40:42
|
Gareth Hughes wrote: > > Gareth Hughes wrote: > > > > rm...@ea... wrote: > > > > > > My system is a dual celeron 433 with 128MB ram, and a Voodoo5, linux 2.4.2-ac12 kernel running Debian unstable. > > > > > > With cvs, 2001/03/06, with merged tdfx-3-1-0-branch, I am having a number of problems. It compiled and installed without any errors, but in quake 1 and chromium bsu it's rendering anything textured in brilliant shades of blue. Untextured mostly looks fine. Lament screensaver is red with blue highlights. > > > > I'll take a look. Can you remind me where I can get a copy of Chromium > > BSU? > > There'll both fine here on my V5. It sounds like it's a V3-specific > issue... Sorry, you have a V5 as well... Have you tried a full rebuild and reinstall? -- Gareth |
From: Alan H. <aho...@va...> - 2001-03-07 08:53:21
|
On Tue, Mar 06, 2001 at 07:03:55PM -0500, rm...@ea... wrote: > depmod -e > depmod: *** Unresolved symbols in /lib/modules/2.4.2-ac12/kernel/drivers/char/drm/tdfx.o > depmod: tdfx_agp_unbind_memory > depmod: tdfx_agp_bind_memory > depmod: tdfx_agp_allocate_memory > depmod: tdfx_agp_free_memory > My fault. Just comitted the fixes now. Alan. |