Usuarios con una SiS650: hay esperanza
Paseandome un poco por la página del bien amado Thomas Winischhofer me he encontrado con esta noticia: "Currently, I am busy rewriting the 2D acceleration part for the 315 and 330 series to use a new kind of command queue mode (VRAM queue). Works already, but requires some testing before I will release the code. The reason for this is the simple fact that it is much easier to write a DRI driver for 315/330 with this VRAM queue mode. But beware, I do not intend to write such a driver myself, so any respective questions will remain unanswered. In other news, SiS dropped the 660, M660, 760, M760 (which were announced back in March 2003) and released the 661FX, M661FX and 741 instead. While the 660 and 760 were supposed to contain a Xabre GPU core, the new chips actually, once again, recycle the old 315 core; in other words, graphics-wise they will be quite compatible to the 650/M650/651. I haven't got any information from SiS yet, so the driver right now guesses what these chips are capable of (such as assuming that they have 2 video overlays, etc). Stay tuned. Update on its way." Propongo empezar a intentar presionar un poco a SiS para que realice ya de una vez unos drivers DRI para las series 315/330 (Xq resulta muy triste no contar con aceleración 3D en nuestro tan querido GNU/Linux). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#179455: marked as done (xserver-xfree86: buglet in modeline processing in r128_drv.o)
Your message dated Fri, 22 Aug 2003 13:29:42 +0100 (BST) with message-id <[EMAIL PROTECTED]> and subject line bug resolved with upstream has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) -- Received: (at submit) by bugs.debian.org; 2 Feb 2003 12:47:07 + >From [EMAIL PROTECTED] Sun Feb 02 06:47:06 2003 Return-path: <[EMAIL PROTECTED]> Received: from salmon.pepperfish.net [195.149.39.195] by master.debian.org with esmtp (Exim 3.12 1 (Debian)) id 18fJWb-0008Ca-00; Sun, 02 Feb 2003 06:47:05 -0600 Received: from localhost ([127.0.0.1]) by salmon.pepperfish.net with esmtp (Exim 3.35 #1 (Debian)) id 18fJWC-0005Ws-00 for <[EMAIL PROTECTED]>; Sun, 02 Feb 2003 12:46:40 + Date: Sun, 2 Feb 2003 12:46:40 + (GMT) From: Vivek <[EMAIL PROTECTED]> X-X-Sender: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: xserver-xfree86: buglet in modeline processing in r128_drv.o Message-ID: <[EMAIL PROTECTED]> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1782332633-133280896-104419=:11772" X-Scanner: not scanned. Delivered-To: [EMAIL PROTECTED] X-Spam-Status: No, hits=-1.2 required=5.0 tests=SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.41 X-Spam-Level: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to [EMAIL PROTECTED] for more info. ---1782332633-133280896-104419=:11772 Content-Type: TEXT/PLAIN; charset=US-ASCII Package: xserver-xfree86 Version: 4.1.0-16 Severity: normal Hi - I noticed that the 4.1 r128_drv.o module was ignoring everything except the X and Y resolutions of the modes in my X86Config file - the module seems to grab just the X and Y resolutions, and throw away all the other data, including the dotclock supplied by the user. This means that you get misleading errors in your X logs as the module silently throws away your dotclock and timings, substitutes its own (often generating ridiculously high refresh rates) and the xserver then rejects the mode as being out of range. a) it dumps a list of known modes, with suitable dot clocks for a 60Hz display, in your Xlogs b) It respects your modeline, provided it meets the usual "monitor can cope" requirements. c) you get a more verbose commentary on which modes were accepted/rejected and why. On my thinkpad A20p this allows me to get at the lower resolution modes, esp 720x576 @ 60Hz, which then allows me to get S-Video output going to the TV. (Yay). There's still a slight bug: switching modes often leaves the display scrambled, but prodding the "lid closed" cutout switch cures this. The 4.2 r128_driver.c appears to do pretty much the same thing wrt to modelines. Hope this is of some use. 01:00.0 VGA compatible controller: ATI Technologies Inc Rage Mobility M3 AGP 2x (rev 02) 01:00.0 Class 0300: 1002:4c46 (rev 02) # File generated by xf86config. # # Copyright (c) 1999 by The XFree86 Project, Inc. # # Permission is hereby granted, free of charge, to any person obtaining a # copy of this software and associated documentation files (the "Software"), # to deal in the Software without restriction, including without limitation # the rights to use, copy, modify, merge, publish, distribute, sublicense, # and/or sell copies of the Software, and to permit persons to whom the # Software is furnished to do so, subject to the following conditions: # # The above copyright notice and this permission notice shall be included in # all copies or substantial portions of the Software. # # THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR # IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, # FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL # THE XFREE86 PROJECT BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, # WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF # OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE # SOFTWARE. # # Except as contained in this notice, the name of the XFree86 Project shall # not be used in advertising or otherwise to promote the sale, use or other # dealings in this Software without prior written authorization from the # XFree86 Project. # # ** # Refer to the XF86Config(4/5) man page for details ab
Bug#206790: missing file on install of 4.2.1-10
Package: xserver-common Version: N/A; reported 2003-08-23 Severity: grave Justification: renders package unusable During install of xserver-common (4.2.1-10) I get this error: /var/lib/dpkg/info/xserver-common.postinst: line 263: /var/lib/xfree86/Xwrapper.config.roster: No such file or directory I have no /var/lib/xfree86, neither does dpkg think I should. -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux davidoff.xs4all.nl 2.4.21 #1 Sun Aug 10 21:09:09 CEST 2003 i586 Locale: LANG=C, LC_CTYPE=C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#117913: xserver-xfree86: [mga] screen freezes when xdm-managed session exits on MGA G550 AGP
I'm not convinced Felix's bug is the same as mine -- my problems were with gdm rather than xdm (which has always cooperated quite nicely, thank you ;-)), and have been better since 4.2.0. (I have seen some other gdm weirdness on this machine in later tests, but no server crashes or hangs.) On a whim, I tried the option you suggested to see if it did anything about the current gdm lossage (not noticing when I logged out); unsurprisingly, it had no effect. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#138195: why not just use symlinks correctly?
On Thu, 21 Aug 2003, Branden Robinson wrote:
> Out of curiosity, how can doing the chdir() break anything? A relative
> symlink has to be resolved relative to the directory in which the
Because now you're in a different directory than you expect. However,
since this is just exec()ing the X server, it won't affect xsession
scripts. If you're dumb enough to use relative paths in your XF86Config,
it might break that. It might also displace coredumps.
I should stress that I don't think the chdir is a big problem, but
merely that there is what I consider to be a more elegant way to resolve
bug 138195.
> symlink resides. If the symlink lived on a filesystem that were mounted
> noexec, the execv() should probably fail regardless of whether a chdir()
> precedes it or not.
Nope, any way you do the execv(), it will succeed. The permissions (and
mount status) of the symlink are irrelevant; only those of the resolved
file are used.
> Again, I had you confused with the submitter; sorry. Complaining about
> my solution after the bug is resolved does still feel like armchair
> quarterbacking, but I wouldn't have griped about it if it had occurred
I thought armchair programming was what Free Software was all about? At
least that's what they told me on Slashdot...;)
> If you can satisfy my curiosity above, I'd be happy to apply your
> patches. Please keep in mind that my goal with xserver-wrapper.c is to
> be very paranoid, as it runs setuid root. Any reasonable precautions we
> can take within this program, we should.
>From a security standpoint, I would prefer my solution because it does
less (not that I think the chdir() is actually dangerous, but that the
fewer things that happen, the less likely we are to cause a problem).
> If you (or anyone else reading this on debian-x) would like to audit the
> code for possible misuse of static buffers, I'd appreciate it. It would
> be a good thing to have done before sarge freezes.
Patch attached. Here's what's in it:
- the xserver buffer has an off-by-one from NUL-terminating readlink()
result (this is the one I sent before)
- var/value buffers had off-by-one from NUL-terminating read strings
- whitespace truncating could cause off-the-beginning problems; if the
entire value was spaces, then i would decrement to before the array
and place a NUL character
- I tried to remove sections where magic numbers had to line up; this
happened by:
- using sizeof(xserver) and sizeof(line) in the code instead of 1024
- defining X_WRAPPER_CONFIG_KEYLEN and X_WRAPPER_CONFIG_VALLEN and
using them (both for declarations and in the sscanf call).
- getting rid of strncasecmp in favor of strcasecmp; we're already
guaranteed that both strings are NUL-terminated, so it buys us
nothing
- got rid of useless comparison of strlen(value) to 256, even though
sscanf guarantees NUL-termination at 256
I don't think any of the overflows are exploitable, but it's good to
plug them just in case. The removal of magic numbers is purely
stylistic, but should prevent magic-number differences from causing any
future overflows. The drawback is that the code is slightly less
readable (see the sscanf call, which is forced to use macro stringify
trickery).
-Peff--- xserver-wrapper.c.orig 2003-08-22 00:45:08.0 -0400
+++ xserver-wrapper.c 2003-08-22 01:27:33.0 -0400
@@ -118,6 +118,11 @@
#define TRUE 1
#endif
+#define X_WRAPPER_CONFIG_KEYLEN 64
+#define X_WRAPPER_CONFIG_VALLEN 256
+#define STRINGIFY(x) #x
+#define STRINGIFY_VAL(x) STRINGIFY(x)
+
typedef enum {
RootOnly,
Console,
@@ -176,9 +181,8 @@
struct stat statbuf;
char xserver[1024];
char line[1024];
- char var[64];
- char value[256];
- int length;
+ char var[X_WRAPPER_CONFIG_KEYLEN+1];
+ char value[X_WRAPPER_CONFIG_VALLEN+1];
int i;
int intval;
char *val;
@@ -192,33 +196,30 @@
if (cf) {
/* parse it */
-val = fgets(line, 1024, cf);
+val = fgets(line, sizeof(line), cf);
while (val != NULL) {
var[0] = '\0';
value[0] = '\0';
- if (sscanf(line, " %64[A-Za-z0-9_] = %256[A-Za-z0-9_ -] ",
+ if (sscanf(line,
+" %" STRINGIFY_VAL(X_WRAPPER_CONFIG_KEYLEN) "[A-Za-z0-9_]"
+" = %" STRINGIFY_VAL(X_WRAPPER_CONFIG_VALLEN) "[A-Za-z0-9_ -] ",
var, value) > 0) {
/* truncate extra spaces at end of value */
-length = strlen(value);
-if (length > 256) {
- length = 256;
-}
-for (i = (length - 1); (value[i] == ' '); i--) {
+for(i = strlen(value) - 1; i >= 0 && value[i] == ' '; i--)
value[i] = '\0';
-}
/* DEBUG (void) fprintf(stderr, "var: %s, value: %s.\n", var, value);
*/
-if (strncasecmp(var, "allowed_users", 64) == 0) {
+if (strcasecmp(var, "allowed_users") == 0) {
level = getSecLevel(value);
/* DEBUG (void) fprintf(stderr, "security level set to %d\n",
l
Re: Running X server chroot?
On Thu, Aug 21, 2003 at 04:24:46PM -0500, Branden Robinson wrote: > (Hmm, maybe you could use tmpfs for /tmp, and mount the same one in both > the real root and the chroot? I've never tried this myself.) Doesn't help as tmpfs instances are compeltly separate. You could mount --bind the real /tmp into the chroot /tmp - but then you've lost all benefits of the chroot vs tmpfile races at least..
Usuarios con una SiS650: hay esperanza
Paseandome un poco por la página del bien amado Thomas Winischhofer me he encontrado con esta noticia: "Currently, I am busy rewriting the 2D acceleration part for the 315 and 330 series to use a new kind of command queue mode (VRAM queue). Works already, but requires some testing before I will release the code. The reason for this is the simple fact that it is much easier to write a DRI driver for 315/330 with this VRAM queue mode. But beware, I do not intend to write such a driver myself, so any respective questions will remain unanswered. In other news, SiS dropped the 660, M660, 760, M760 (which were announced back in March 2003) and released the 661FX, M661FX and 741 instead. While the 660 and 760 were supposed to contain a Xabre GPU core, the new chips actually, once again, recycle the old 315 core; in other words, graphics-wise they will be quite compatible to the 650/M650/651. I haven't got any information from SiS yet, so the driver right now guesses what these chips are capable of (such as assuming that they have 2 video overlays, etc). Stay tuned. Update on its way." Propongo empezar a intentar presionar un poco a SiS para que realice ya de una vez unos drivers DRI para las series 315/330 (Xq resulta muy triste no contar con aceleración 3D en nuestro tan querido GNU/Linux).
Bug#179455: marked as done (xserver-xfree86: buglet in modeline processing in r128_drv.o)
Your message dated Fri, 22 Aug 2003 13:29:42 +0100 (BST) with message-id <[EMAIL PROTECTED]> and subject line bug resolved with upstream has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) -- Received: (at submit) by bugs.debian.org; 2 Feb 2003 12:47:07 + >From [EMAIL PROTECTED] Sun Feb 02 06:47:06 2003 Return-path: <[EMAIL PROTECTED]> Received: from salmon.pepperfish.net [195.149.39.195] by master.debian.org with esmtp (Exim 3.12 1 (Debian)) id 18fJWb-0008Ca-00; Sun, 02 Feb 2003 06:47:05 -0600 Received: from localhost ([127.0.0.1]) by salmon.pepperfish.net with esmtp (Exim 3.35 #1 (Debian)) id 18fJWC-0005Ws-00 for <[EMAIL PROTECTED]>; Sun, 02 Feb 2003 12:46:40 + Date: Sun, 2 Feb 2003 12:46:40 + (GMT) From: Vivek <[EMAIL PROTECTED]> X-X-Sender: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: xserver-xfree86: buglet in modeline processing in r128_drv.o Message-ID: <[EMAIL PROTECTED]> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1782332633-133280896-104419=:11772" X-Scanner: not scanned. Delivered-To: [EMAIL PROTECTED] X-Spam-Status: No, hits=-1.2 required=5.0 tests=SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.41 X-Spam-Level: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to [EMAIL PROTECTED] for more info. ---1782332633-133280896-104419=:11772 Content-Type: TEXT/PLAIN; charset=US-ASCII Package: xserver-xfree86 Version: 4.1.0-16 Severity: normal Hi - I noticed that the 4.1 r128_drv.o module was ignoring everything except the X and Y resolutions of the modes in my X86Config file - the module seems to grab just the X and Y resolutions, and throw away all the other data, including the dotclock supplied by the user. This means that you get misleading errors in your X logs as the module silently throws away your dotclock and timings, substitutes its own (often generating ridiculously high refresh rates) and the xserver then rejects the mode as being out of range. a) it dumps a list of known modes, with suitable dot clocks for a 60Hz display, in your Xlogs b) It respects your modeline, provided it meets the usual "monitor can cope" requirements. c) you get a more verbose commentary on which modes were accepted/rejected and why. On my thinkpad A20p this allows me to get at the lower resolution modes, esp 720x576 @ 60Hz, which then allows me to get S-Video output going to the TV. (Yay). There's still a slight bug: switching modes often leaves the display scrambled, but prodding the "lid closed" cutout switch cures this. The 4.2 r128_driver.c appears to do pretty much the same thing wrt to modelines. Hope this is of some use. 01:00.0 VGA compatible controller: ATI Technologies Inc Rage Mobility M3 AGP 2x (rev 02) 01:00.0 Class 0300: 1002:4c46 (rev 02) # File generated by xf86config. # # Copyright (c) 1999 by The XFree86 Project, Inc. # # Permission is hereby granted, free of charge, to any person obtaining a # copy of this software and associated documentation files (the "Software"), # to deal in the Software without restriction, including without limitation # the rights to use, copy, modify, merge, publish, distribute, sublicense, # and/or sell copies of the Software, and to permit persons to whom the # Software is furnished to do so, subject to the following conditions: # # The above copyright notice and this permission notice shall be included in # all copies or substantial portions of the Software. # # THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR # IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, # FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL # THE XFREE86 PROJECT BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, # WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF # OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE # SOFTWARE. # # Except as contained in this notice, the name of the XFree86 Project shall # not be used in advertising or otherwise to promote the sale, use or other # dealings in this Software without prior written authorization from the # XFree86 Project. # # ** # Refer to the XF86Config(4/5) man page for details a
Bug#206790: missing file on install of 4.2.1-10
Package: xserver-common Version: N/A; reported 2003-08-23 Severity: grave Justification: renders package unusable During install of xserver-common (4.2.1-10) I get this error: /var/lib/dpkg/info/xserver-common.postinst: line 263: /var/lib/xfree86/Xwrapper.config.roster: No such file or directory I have no /var/lib/xfree86, neither does dpkg think I should. -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux davidoff.xs4all.nl 2.4.21 #1 Sun Aug 10 21:09:09 CEST 2003 i586 Locale: LANG=C, LC_CTYPE=C
Bug#117913: xserver-xfree86: [mga] screen freezes when xdm-managed session exits on MGA G550 AGP
I'm not convinced Felix's bug is the same as mine -- my problems were with gdm rather than xdm (which has always cooperated quite nicely, thank you ;-)), and have been better since 4.2.0. (I have seen some other gdm weirdness on this machine in later tests, but no server crashes or hangs.) On a whim, I tried the option you suggested to see if it did anything about the current gdm lossage (not noticing when I logged out); unsurprisingly, it had no effect. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
