Bug#242664: xserver-xfree86: x-based apps take way too long to open, and the load goes up to 2-5
Ce jour Wed, 05 May 2004, Michel Dänzer a dit: On Wed, 2004-05-05 at 06:58, [EMAIL PROTECTED] wrote: Le Tue, Apr 20, 2004 at 21:46:02 -0500, Branden Robinson a écrit: [...] you asked me once on #debian-devel if it was the server or the clients that drove up the load, i had replied to you it was the clients. it's still true, as i see openbox and other clients use up a lot of cpu starting up. All the apps you've mentioned use Xft and fontconfig; does the problem also occur with clients that don't use those? hmm, come to think if it, i don't think they do. no, they don't. e.g., eximon opens just as quickly as ever (athena widgets, ick). i was starting to think along those lines in fact, but more fonts in general, than fontconfig and xft... strange thing is, when an x session has been running for a bit, it takes slightly less time of the application had already been open beforehand. i'll have to look into the fonts more. i think you may be onto something. i'll keep you informed -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer -- @@-@@ | ,''`. http://www.debian.org/ | http://www.nuit.ca/ | | : :' : Debian GNU/Linux| http://simonraven.nuit.ca/ | | `. `' | PGP key fingerprint (new one): | | `- | 7C49 FD9C 1054 7300 3B7B| | | 8BF4 6A88 7AE2 711D F097| @@-@@ signature.asc Description: Digital signature
Bug#242664: xserver-xfree86: x-based apps take way too long to open, and the load goes up to 2-5
Ce jour Wed, 05 May 2004, Michel Dänzer a dit: On Wed, 2004-05-05 at 06:58, [EMAIL PROTECTED] wrote: Le Tue, Apr 20, 2004 at 21:46:02 -0500, Branden Robinson a écrit: [...] All the apps you've mentioned use Xft and fontconfig; does the problem also occur with clients that don't use those? well, i tried regenerating the font.cache-1 files, including removing my ~/.font-cache-1 (or whatever) and wow, so far everything started up within a (very few) minutes of me doing 'startx'. sometimes i feel like such a dufus... -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer -- @@-@@ | ,''`. http://www.debian.org/ | http://www.nuit.ca/ | | : :' : Debian GNU/Linux| http://simonraven.nuit.ca/ | | `. `' | PGP key fingerprint (new one): | | `- | 7C49 FD9C 1054 7300 3B7B| | | 8BF4 6A88 7AE2 711D F097| @@-@@ signature.asc Description: Digital signature
Bug#242664: xserver-xfree86: x-based apps take way too long to open, and the load goes up to 2-5
Ce jour Wed, 05 May 2004, Michel Dänzer a dit: as a fix, i propose having fc-cache -f run every few days, or once a week or something, maybe once a month even, from a cron job. -- @@-@@ | ,''`. http://www.debian.org/ | http://www.nuit.ca/ | | : :' : Debian GNU/Linux| http://simonraven.nuit.ca/ | | `. `' | PGP key fingerprint (new one): | | `- | 7C49 FD9C 1054 7300 3B7B| | | 8BF4 6A88 7AE2 711D F097| @@-@@ signature.asc Description: Digital signature
Bug#242664: xserver-xfree86: x-based apps take way too long to open, and the load goes up to 2-5
Le Tue, Apr 20, 2004 at 21:46:02 -0500, Branden Robinson a écrit: [...] ok, further to our convo a couple of weeks ago (?), i've been testing the dfsg versioned .debs, and i still get the same symptoms, but the load doesn't go as high, nor does it take 5-10 minutes, but does take longer than a minute to open an x-based app. i've tried both the dri-enabled xserver i have installed (from michel daenzer's archive) and the distributed one, and both behave similarly. load hovers around 1-3 instead of 2-5, and like i said, about 1 minute or sometimes more (depending on the application). the wait is a noticable one. for instance gnome takes 10+ minutes to start, instead of about 5+ minutes. you asked me once on #debian-devel if it was the server or the clients that drove up the load, i had replied to you it was the clients. it's still true, as i see openbox and other clients use up a lot of cpu starting up. i'm re-installing 4.3.0-5 again as that's the last one that behaved as expected. oh and a hardware change: more RAM was added, that might account for the less slowness change, but i had 216 MB before, and now it's 448 MB RAM. i kind of doubt that would change things much, except for less swapping (i have background daemons running). again, it's an 8500, with an ati rage lt pro card (and first time i noticed this behaviour i was running off of controlfb / fbdev xserver driver (the onboard video basically). -- G. Branden Robinson|Imagination was given man to Debian GNU/Linux |compensate for what he is not, and [EMAIL PROTECTED] |a sense of humor to console him for http://people.debian.org/~branden/ |what he is. -- @@-@@ | ,''`. http://www.debian.org/ | http://www.nuit.ca/ | | : :' : Debian GNU/Linux| http://simonraven.nuit.ca/ | | `. `' | PGP key fingerprint (new one): | | `- | 7C49 FD9C 1054 7300 3B7B| | | 8BF4 6A88 7AE2 711D F097| @@-@@ signature.asc Description: Digital signature
Bug#242664: xserver-xfree86: x-based apps take way too long to open, and the load goes up to 2-5
On Wed, 2004-05-05 at 06:58, [EMAIL PROTECTED] wrote: Le Tue, Apr 20, 2004 at 21:46:02 -0500, Branden Robinson a écrit: [...] ok, further to our convo a couple of weeks ago (?), i've been testing the dfsg versioned .debs, and i still get the same symptoms, but the load doesn't go as high, nor does it take 5-10 minutes, but does take longer than a minute to open an x-based app. i've tried both the dri-enabled xserver i have installed (from michel daenzer's archive) and the distributed one, and both behave similarly. load hovers around 1-3 instead of 2-5, and like i said, about 1 minute or sometimes more (depending on the application). the wait is a noticable one. for instance gnome takes 10+ minutes to start, instead of about 5+ minutes. you asked me once on #debian-devel if it was the server or the clients that drove up the load, i had replied to you it was the clients. it's still true, as i see openbox and other clients use up a lot of cpu starting up. All the apps you've mentioned use Xft and fontconfig; does the problem also occur with clients that don't use those? -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
Bug#242664: xserver-xfree86: x-based apps take way too long to open, and the load goes up to 2-5
On mar, 2004-20-04 at 21:46 -0500, Branden Robinson wrote: tag 242664 + moreinfo thanks On Wed, Apr 07, 2004 at 11:43:38PM +, simon raven wrote: x-based apps take way too long to open, and the load goes up to 2-5. i explain further: for example, i opened gq (an LDAP browser/db editor) a few minutes ago, it took all of 3-8 seconds to open, whereas with 4.3.0-6 or -7, it takes several minutes to open, and the load goes up to 3 or 4. if i open say, firefox, it takes a good 5 minutes, and the load goes up to 4 or 5. - % time mozilla-firefox selected locale: en-US mozilla-firefox 26.64s user 3.69s system 54% cpu 56.143 total - this is in -5. and the load: 1.32 0.81 0.64 also, can you tell me what would cause this, if you have an idea on what this might be? I notice neither lspci nor the X server saw any PCI video devices on your machine. Uh no, just controlfb at the time.. what's that have to do with the x-clients taking minutes to open? What is your hardware? If I had to guess, I'd say it was an OldWorld PowerMac, maybe even a NuBus machine. Yes it's an oldworld, an 8500. No, definitely not a nubus ;). it's not G3 upgraded either. Just a 604e daughtercard pulled from an UMAX box. VGA-compatible devices on PCI bus: There were very few changes in 4.3.0-6: Yes, and 4.3.0-6 was behaving the same way. -5 worked as expected. The only one of the above that affected the X server was the sunffb item, and it only affected SPARCs (by allowing them to compile the sources again). Yes, but i noticed the exact same behaviour with controlfb, fbdev x driver, and x clients taking minutes to open. I have an ATI card now, and I don't see the same thing happening. the problem is either a) with the hardware, b) the fbdev driver + controlfb (which is known to be rather fucked, TMK) c) something else. Are you still having this problem with 4.3.0-7? Not currently, since I'm using the .dfsg. named .debs, and I put -5 on hold until the recent upgrades (the dfsg .debs). but I've been using -5, plus the DRI server from people.d.o/~daenzer/, since i got the ATI card. -- G. Branden Robinson|Imagination was given man to Debian GNU/Linux |compensate for what he is not, and [EMAIL PROTECTED] |a sense of humor to console him for http://people.debian.org/~branden/ |what he is. signature.asc Description: This is a digitally signed message part
Bug#242664: xserver-xfree86: x-based apps take way too long to open, and the load goes up to 2-5
tag 242664 + moreinfo thanks On Wed, Apr 07, 2004 at 11:43:38PM +, simon raven wrote: x-based apps take way too long to open, and the load goes up to 2-5. i explain further: for example, i opened gq (an LDAP browser/db editor) a few minutes ago, it took all of 3-8 seconds to open, whereas with 4.3.0-6 or -7, it takes several minutes to open, and the load goes up to 3 or 4. if i open say, firefox, it takes a good 5 minutes, and the load goes up to 4 or 5. - % time mozilla-firefox selected locale: en-US mozilla-firefox 26.64s user 3.69s system 54% cpu 56.143 total - this is in -5. and the load: 1.32 0.81 0.64 also, can you tell me what would cause this, if you have an idea on what this might be? I notice neither lspci nor the X server saw any PCI video devices on your machine. What is your hardware? If I had to guess, I'd say it was an OldWorld PowerMac, maybe even a NuBus machine. VGA-compatible devices on PCI bus: There were very few changes in 4.3.0-6: xfree86 (4.3.0-6) unstable; urgency=medium * Urgency due to fix for FTBFS on SPARC. * Fix build-server rule to copy a hardlinked source tree for the debugging server build exactly as the normal build rule does; the clever tricks undertaken to conserve inodes did not work properly (thanks, Daniel Jacobowitz). - debian/rules * Fix build-server's stamp rule to depend on patch-audit's stamp rule, not patch-audit itself (thanks, Daniel Jacobowitz). - debian/rules * Fix yet another incorrect usage of printf. Aggressive line-wrapping at 80 columns considered harmful! - debian/xlibs.bug * Flesh out elographics driver manpage, courtesy of Lee Maguire. (Closes: #236388) - debian/patches/075_elographics_improve_manpage.diff * Update examples and information in xdm's Xservers file to give sysadmins more detailed and accurate advice, and to use XFree86 4.x's -depth option in the examples instead of XFree86 3.x's -bpp option. Thanks to Frank Murphy for pointing out how long in the tooth this information had become. (Closes: #237878) - debian/patches/905_debian_xdm.diff * Drop xlibs's conflicts/replaces relationship with xlib6 (the old, no-longer-maintained, security-hole-ridden libc5 version of the X libraries from XFree86 3.3.6), because it is spurious. There is no file overlap and no particular reason to force xlib6 off the system, apart from the sheer insanity of keeping libraries with known security holes on the system. However, that's the user's decision. (Closes: #236780) - debian/control * Revert patch applied in 4.3.0-3 to enhance the sunffb driver; unfortunately, it does not build. (Closes: #236705) + Apply patch by David S. Miller to implement XAA and Render support in the sunffb driver. - debian/patches/073_sunffb_xaa_render_fb_support.diff: deleted * Fix IGNORE_MANFIEST_CHANGES logic to properly distinguish diff's exit codes, and work as intended. Thanks to Daniel Schepler for bringing this problem to my attention. (Closes: #238080) - debian/rules -- Branden Robinson [EMAIL PROTECTED] Tue, 16 Mar 2004 15:44:17 -0500 The only one of the above that affected the X server was the sunffb item, and it only affected SPARCs (by allowing them to compile the sources again). Are you still having this problem with 4.3.0-7? -- G. Branden Robinson|Imagination was given man to Debian GNU/Linux |compensate for what he is not, and [EMAIL PROTECTED] |a sense of humor to console him for http://people.debian.org/~branden/ |what he is. signature.asc Description: Digital signature
Processed: Re: Bug#242664: xserver-xfree86: x-based apps take way too long to open, and the load goes up to 2-5
Processing commands for [EMAIL PROTECTED]: tag 242664 + moreinfo Bug#242664: xserver-xfree86: x-based apps take way too long to open, and the load goes up to 2-5 Tags were: sid Tags added: moreinfo thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Bug#242664: xserver-xfree86: x-based apps take way too long to open, and the load goes up to 2-5
Package: xserver-xfree86 Version: 4.3.0-5 Severity: important Tags: sid x-based apps take way too long to open, and the load goes up to 2-5. i explain further: for example, i opened gq (an LDAP browser/db editor) a few minutes ago, it took all of 3-8 seconds to open, whereas with 4.3.0-6 or -7, it takes several minutes to open, and the load goes up to 3 or 4. if i open say, firefox, it takes a good 5 minutes, and the load goes up to 4 or 5. - % time mozilla-firefox selected locale: en-US mozilla-firefox 26.64s user 3.69s system 54% cpu 56.143 total - this is in -5. and the load: 1.32 0.81 0.64 also, can you tell me what would cause this, if you have an idea on what this might be? thanks, simon -- Package-specific info: Contents of /var/lib/xfree86/X.roster: xserver-xfree86 X server symlink status: lrwxrwxrwx1 root root6 2004-03-20 17:19 /etc/X11/X - X.orig /etc/X11/X target does not match checksum in /var/lib/xfree86/X.md5sum. (NOTE: X.orig is the distributed xserver) Contents of /var/lib/xfree86/XF86Config-4.roster: xserver-xfree86 VGA-compatible devices on PCI bus: XFree86 X server configuration file status: -rw-r--r--1 root root 2886 2004-03-30 23:59 /etc/X11/XF86Config-4 Contents of /etc/X11/XF86Config-4: # File generated by Xautoconfig. Section ServerLayout Identifier XFree86 Configured Screen 0 Screen0 0 0 InputDevice Mouse0 CorePointer InputDevice Keyboard0 CoreKeyboard EndSection Section Files FontPath /usr/lib/X11/fonts/Type1 FontPath /usr/lib/X11/fonts/Speedo FontPath /usr/lib/X11/fonts/misc FontPath /usr/lib/X11/fonts/75dpi FontPath /usr/lib/X11/fonts/100dpi FontPath /usr/X11R6/lib/X11/fonts/TrueType/larabie-straight # RgbPath is the location of the RGB database. Note, this is the name of the # file minus the extension (like .txt or .db). There is normally # no need to change the default. # Multiple FontPath entries are allowed (they are concatenated together) # By default, Red Hat 6.0 and later now use a font server independent of # the X server to render fonts. RgbPath /usr/X11R6/lib/X11/rgb # if the local font server has problems, we can fall back on these EndSection Section Module Loaddbe Loadextmod Loadfbdevhw Loadglx Loadrecord Loadfreetype Loadtype1 LoadGLcore Loadbitmap Loadddc #Loaddri Loadint10 Loadspeedo # Loadvbe EndSection Section InputDevice Identifier Keyboard0 Driver keyboard # Change XkbModel to macintosh_old if you are using # the deprecated adb keycodes. Option XkbRules xfree86 Option XkbModel pc105 Option XkbLayout ca EndSection Section InputDevice Identifier Mouse0 Driver mouse Option Protocol IMPS/2 Option Device/dev/input/mice EndSection Section Monitor Identifier Monitor0 UseModesModes0 ModelName Multiple Scan-15 Option DPMS HorizSync 31-57 VertRefresh 60-75 VendorName Apple ModeLine 1024x768/70Hz 75 1024 1048 1184 1328 768 771 777 806 -HSync -VSync EndSection Section Modes Identifier Modes0 # Generated # D: 57.110 MHz, H: 49.575 kHz, V: 74.325 Hz Modeline 832x624 57.110 832 864 928 1152 624 625 628 667 -HSync -VSync EndSection Section Device Identifier Card0 # We couldn't determine the BusID of your video card. So we will use # the fbdev driver Option ShadowFB true Option fbdev /dev/fb0 Driver fbdev #BusID 0:0:0 vendorname Apple boardname control Option BackingStore true EndSection Section Screen Identifier Screen0 Device Card0 Monitor Monitor0 DefaultDepth24 SubSection Display Depth 8 Modes 1024x768/70Hz 640x480 #Modes 832x624 Virtual 0 0 EndSubSection SubSection Display Depth 16 Modes 1024x768/70Hz 640x480 #Modes 832x624 Virtual 0 0 EndSubSection SubSection Display Depth 24 #Modes 1024x768/70Hz 640x480 Modes 832x624 Virtual 0 0 EndSubSection EndSection #Section DRI # Group 0 # Mode 0666 #EndSection /etc/X11/XF86Config-4 does not match checksum in /var/lib/xfree86/XF86Config-4.md5sum. Contents of most recent
