Re: vesa display codes (Etch Xorg memory leak?)
On Mon, May 21, 2007 at 07:44:14PM -0500, Owen Heisler wrote: Anyway, I tried some other video= lines and nothing makes any difference. I tried vesafb, rivafb, and nvidiafb for the driver and both 1024x768 (vga=791 works fine) and 1280x960 for the resolution (all combinations for rivafb and nvidiafb, not vesafb:1024x768 I think). I don't know if it is relevant, but once the system is booted, I can load a nvidiafb module, but not either of vesafb and rivafb. That's normal. vesafb is compiled in (not a module) and rivafb is not compiled at all. Like I said, this isn't really a problem; if I just need to make a custom kernel, I'll drop it for now and maybe later... sometime... Here is what I would try: 1. A simple vga= to the kernel (vga=791 should give 1024x764-16bpp). If this works you only need to find the correct parameter to get the right resolution (though it is already better than 640x480). 2. Find out what the correct driver for your video card is. AFAIR rivafb is only for *very* old cards. The newer ones should work with the nvidiafb. 3. Put nvidiafb in your initrd and boot with the correct video=nvidiafb:... option. You must google for the exact parameters to pass as they might be different from other drivers. 1. with the correct parameter might be enough, but if it doesn't work or doesn't give the desired resolution you might experiment with 2. and 3. None of them involves kernel compilation. Regards, Andrei -- If you can't explain it simply, you don't understand it well enough. (Albert Einstein) signature.asc Description: Digital signature
Re: vesa display codes (Etch Xorg memory leak?)
On Tue, 2007-05-22 at 09:33 +0300, Andrei Popescu wrote: On Mon, May 21, 2007 at 07:44:14PM -0500, Owen Heisler wrote: Anyway, I tried some other video= lines and nothing makes any difference. I tried vesafb, rivafb, and nvidiafb for the driver and both 1024x768 (vga=791 works fine) and 1280x960 for the resolution (all combinations for rivafb and nvidiafb, not vesafb:1024x768 I think). I don't know if it is relevant, but once the system is booted, I can load a nvidiafb module, but not either of vesafb and rivafb. That's normal. vesafb is compiled in (not a module) and rivafb is not compiled at all. Okay Like I said, this isn't really a problem; if I just need to make a custom kernel, I'll drop it for now and maybe later... sometime... Here is what I would try: 1. A simple vga= to the kernel (vga=791 should give 1024x764-16bpp). If this works you only need to find the correct parameter to get the right resolution (though it is already better than 640x480). There doesn't seem to be a correct vga= parameter for 1280x960. 2. Find out what the correct driver for your video card is. AFAIR rivafb is only for *very* old cards. The newer ones should work with the nvidiafb. Mine is not old, so nvidiafb should be correct. 3. Put nvidiafb in your initrd and boot with the correct video=nvidiafb:... option. You must google for the exact parameters to pass as they might be different from other drivers. I've tried video=nvidiafb:1280x960 and I seem to just get the default resolution. So I need a full framebuffer mode line, I guess. In order to figure out what I need to use, I need this information (as provided by XFree86): Modeline 1280x960 DCF HR SH1 SH2 HFL VR SV1 SV2 VFL see http://www.linux.com/howtos/Framebuffer-HOWTO-18.shtml (old) 1. with the correct parameter might be enough, but if it doesn't work or doesn't give the desired resolution you might experiment with 2. and 3. None of them involves kernel compilation. 3 it is. Thanks signature.asc Description: This is a digitally signed message part
Re: vesa display codes (Etch Xorg memory leak?)
On Tue, May 22, 2007 at 07:24:40AM -0500, Owen Heisler wrote: There doesn't seem to be a correct vga= parameter for 1280x960. I was suggesting 791 as it is still better then the default and you can see something happening (I just hate it when I mess with options and I see no change :)) I've tried video=nvidiafb:1280x960 and I seem to just get the default resolution. So I need a full framebuffer mode line, I guess. In order to figure out what I need to use, I need this information (as provided by XFree86): Modeline 1280x960 DCF HR SH1 SH2 HFL VR SV1 SV2 VFL see http://www.linux.com/howtos/Framebuffer-HOWTO-18.shtml (old) Did you include the nvidiafb module in your initrd? I run yaird and don't know how to do this for initramfs-tools. If yes then you could (again) try a resolution like 1024x768, just to see your changes are going to the right place and then see how to get to the right resolution. Regards, Andrei -- If you can't explain it simply, you don't understand it well enough. (Albert Einstein) signature.asc Description: Digital signature
Re: vesa display codes (Etch Xorg memory leak?)
On Tue, 2007-05-22 at 18:56 +0300, Andrei Popescu wrote: On Tue, May 22, 2007 at 07:24:40AM -0500, Owen Heisler wrote: There doesn't seem to be a correct vga= parameter for 1280x960. I was suggesting 791 as it is still better then the default and you can see something happening (I just hate it when I mess with options and I see no change :)) Oh, I've been using vga=791 for a while now. Just wondering if I can get 1280x960 instead! :) And yes, I agree: when I change something I'd really like to see /something/, whether a change for the better, for the worse, or even just some cryptic (or not) error. I've tried video=nvidiafb:1280x960 and I seem to just get the default resolution. So I need a full framebuffer mode line, I guess. In order to figure out what I need to use, I need this information (as provided by XFree86): Modeline 1280x960 DCF HR SH1 SH2 HFL VR SV1 SV2 VFL see http://www.linux.com/howtos/Framebuffer-HOWTO-18.shtml (old) Did you include the nvidiafb module in your initrd? I run yaird and don't know how to do this for initramfs-tools. If yes then you could (again) try a resolution like 1024x768, just to see your changes are going to the right place and then see how to get to the right resolution. I've never done anything with initrd stuff before, but I see that /etc/initramfs-tools/initramfs.conf contains: # MODULES: [ most | netboot | dep | list ] # most - Add all framebuffer, acpi, filesystem, and harddrive drivers. MODULES=most So I assume that nvidiafb is in there. But when I look inside /boot/initrd* at lib/modules/*/kernel/drivers/video, I see only: vga16fb.ko and vgastate.ko So I add nvidiafb to /etc/initramfs-tools/modules, run update-initramfs -u (this is fun) and now nvidia is also listed. Now I reboot and try video=nvidiafb:1280x960 and video=nvidiafb:1024x768 and get something slightly worse than the default with both. Do I need more after video=? signature.asc Description: This is a digitally signed message part
Re: vesa display codes (Etch Xorg memory leak?)
On Tue, May 22, 2007 at 06:28:50PM -0500, Owen Heisler wrote: So I add nvidiafb to /etc/initramfs-tools/modules, run update-initramfs -u (this is fun) and now nvidia is also listed. Now I reboot and try video=nvidiafb:1280x960 and video=nvidiafb:1024x768 and get something slightly worse than the default with both. Do I need more after video=? I don't know. Try (as root) 'modinfo nvidiafb' and google. Regards, Andrei -- If you can't explain it simply, you don't understand it well enough. (Albert Einstein) signature.asc Description: Digital signature
Re: vesa display codes (Etch Xorg memory leak?)
On Sun, May 20, 2007 at 11:06:39PM -0400, cga2000 wrote: I tried: video=rivafb:1280x960 video=vesafb:1280x960 but neither worked. You do realize that you may need to compile a custom kernel to enable support for a given video card..? Not necessarily. It should work if you inlcude the module in your initrd. Regards, Andrei -- If you can't explain it simply, you don't understand it well enough. (Albert Einstein) signature.asc Description: Digital signature
Re: vesa display codes (Etch Xorg memory leak?)
On Mon, May 21, 2007 at 02:44:29AM EDT, Andrei Popescu wrote: On Sun, May 20, 2007 at 11:06:39PM -0400, cga2000 wrote: I tried: video=rivafb:1280x960 video=vesafb:1280x960 but neither worked. You do realize that you may need to compile a custom kernel to enable support for a given video card..? Not necessarily. It should work if you inlcude the module in your initrd. How is the initrd going to help if the module does not exist in the first place? What I was saying is that support for his card may have been included in whatever kernel he's using .. either built-in or as a module. The other aspect is that initrd or not .. I have never managed to get the frame buffer console to start when using atyfb instead of the generic vesa when compiling it as a module. But that's a separate issue. Thanks, cga -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: vesa display codes (Etch Xorg memory leak?)
On Mon, May 21, 2007 at 08:18:37AM -0400, cga2000 wrote: On Mon, May 21, 2007 at 02:44:29AM EDT, Andrei Popescu wrote: On Sun, May 20, 2007 at 11:06:39PM -0400, cga2000 wrote: I tried: video=rivafb:1280x960 video=vesafb:1280x960 but neither worked. You do realize that you may need to compile a custom kernel to enable support for a given video card..? Not necessarily. It should work if you inlcude the module in your initrd. How is the initrd going to help if the module does not exist in the first place? You're right, the rivafb module is not compiled, but vesafb is compiled in and it should work with the correct vga=... There is a nvidiafb module, maybe the OP can try that? What I was saying is that support for his card may have been included in whatever kernel he's using .. either built-in or as a module. Sorry, I thought you were telling him he needs to recompile the kernel. I missed the may. Regards, Andrei -- If you can't explain it simply, you don't understand it well enough. (Albert Einstein) signature.asc Description: Digital signature
Re: vesa display codes (Etch Xorg memory leak?)
On Mon, May 21, 2007 at 12:35:57PM EDT, Andrei Popescu wrote: On Mon, May 21, 2007 at 08:18:37AM -0400, cga2000 wrote: On Mon, May 21, 2007 at 02:44:29AM EDT, Andrei Popescu wrote: On Sun, May 20, 2007 at 11:06:39PM -0400, cga2000 wrote: I tried: video=rivafb:1280x960 video=vesafb:1280x960 but neither worked. You do realize that you may need to compile a custom kernel to enable support for a given video card..? Not necessarily. It should work if you inlcude the module in your initrd. How is the initrd going to help if the module does not exist in the first place? You're right, the rivafb module is not compiled, but vesafb is compiled in and it should work with the correct vga=... This actually should work if both vesafb and the native driver (in this instance rivafb) are compiled in. Would allow you to switch on the fly (in grub) by specifying: kernel ... video=vesafb:1024x768 kernel ... video=rivafb:1024x768 .. so you can use either with the same kernel. The above would be clean and simple .. but I'm not sure that's the way things work (haven't tested it) .. It would help if the OP could explain _how_ it doesn't work. _Owen_, What do you get .. a kernel oops .. a black screen of death .. a vga console with oversized fonts ..? With little detail about what's happening .. I would suggest building a kernel with support for you hardware built in .. rather than provided via a module. That's how I eventually got this to work with a 2.4.27 kernel atyfb/mach64. There is a nvidiafb module, maybe the OP can try that? What I was saying is that support for his card may have been included in whatever kernel he's using .. either built-in or as a module. Sorry, I thought you were telling him he needs to recompile the kernel. I missed the may. I suspect that debian kernels are compiled w/o native driver support because the sum total of all the specific drivers ends up support only a subset of the hundreds or video cards chipsets available .. and since once they're present they would appear to preempt vesa support .. So, I would say I am reasonably confident he will end up making his own custom kernel if he wants to use the native driver for his video card. If you can't explain it simply, you don't understand it well enough. (Albert Einstein) So that's where I ran into this little jewel, then. Actually grepped my fortune database for it the other day to check on the exact wording. Thanks, cga -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: vesa display codes (Etch Xorg memory leak?)
On Mon, 2007-05-21 at 19:27 -0400, cga2000 wrote: _Owen_, What do you get .. a kernel oops .. a black screen of death .. a vga console with oversized fonts ..? With any video= parameter, I get the default resolution (640x480/80x25, I suppose), just like there was no vga= or video= parameter appended to the kernel boot line. With little detail about what's happening .. I would suggest building a kernel with support for you hardware built in .. rather than provided via a module. That's how I eventually got this to work with a 2.4.27 kernel atyfb/mach64. ... I suspect that debian kernels are compiled w/o native driver support because the sum total of all the specific drivers ends up support only a subset of the hundreds or video cards chipsets available .. and since once they're present they would appear to preempt vesa support .. So, I would say I am reasonably confident he will end up making his own custom kernel if he wants to use the native driver for his video card. Yeah, last time I compiled a custom kernel was back when I first started using Linux, with Fedora Core... I thought I had to for some hardware problem or something... (New to Linux, and impressed that everything just worked even when using the latest kernel, and compiled by me who knew nothing about it) I was glad to discover later that it wasn't really necessary. And now my policy is to use stock kernels in Debian unless I absolutely have to use a custom kernel, because it simplifies things so much. (Wait, maybe it's a lot easier on Debian, using deb sources... perhaps I'll investigate sometime.) :) And this isn't really a problem: it just bugs me that I have to wait for my CRT monitor to switch resolutions when switching between X and other consoles. Anyway, I tried some other video= lines and nothing makes any difference. I tried vesafb, rivafb, and nvidiafb for the driver and both 1024x768 (vga=791 works fine) and 1280x960 for the resolution (all combinations for rivafb and nvidiafb, not vesafb:1024x768 I think). I don't know if it is relevant, but once the system is booted, I can load a nvidiafb module, but not either of vesafb and rivafb. Why am I not getting any errors? I can't find anything in /var/log, searching for video or nvidia. Hopefully this is irrelevant: the root fs is encrypted on top of RAID5. Like I said, this isn't really a problem; if I just need to make a custom kernel, I'll drop it for now and maybe later... sometime... Thanks signature.asc Description: This is a digitally signed message part
Re: vesa display codes (Etch Xorg memory leak?)
On Sun, 2007-05-20 at 01:10 -0400, cga2000 wrote: On Sat, May 19, 2007 at 07:33:51PM EDT, Owen Heisler wrote: On Sat, 2007-05-19 at 19:10 -0400, Greg Folkert wrote: On Fri, 2007-05-18 at 00:10 -0400, Greg Folkert wrote: On Thu, 2007-05-17 at 18:34 -0500, Owen Heisler wrote: On Thu, 2007-05-17 at 16:02 -0400, Greg Folkert wrote: http://www.gregfolkert.net/info/vesa-display-codes.html Very helpful! Although no 1280x960 (grr) unfortunately. Is there any way to get that? vbetool is supposed to do it. Or hwinfo --vbe But they aren't exactly 100%, as I haven't been able to get the info out of the hardware yet. FYI, I've updated the page and now lists a few things to get other modes. Though the framebuffer howtos have not really been updated since 2000 or 2001. video=:xres:,yres:,depth:,left:,right:,hslen:,upper:,lower:,vslen: It looks like I need something like this: Modeline 1280x1024 DCF HR SH1 SH2 HFL VR SV1 SV2 VFL Is there some way to get that from xorg? Oh .. maybe, $ modeline2fb Same fbset package as the other stuff previously mentioned. Mind if I add snippets of you two posts to Owen to that Vesa Mode Page? -- greg, [EMAIL PROTECTED] PGP key: 1024D/B524687C 2003-08-05 Fingerprint: E1D3 E3D7 5850 957E FED0 2B3A ED66 6971 B524 687C Alternate Fingerprint: 09F9 1102 9D74 E35B D841 56C5 6356 88C0 signature.asc Description: This is a digitally signed message part
Re: vesa display codes (Etch Xorg memory leak?)
On Sun, May 20, 2007 at 12:01:18PM EDT, Greg Folkert wrote: [..} Mind if I add snippets of you two posts to Owen to that Vesa Mode Page? Not in principle naturally. Just that I'd be a little concerned about the contents of my posts possibly misleading others .. A clear case of I don't understand it well enough to explain it .. to paraphrase A. Einstein, I think. I wish I had more solid knowledge of these aspects. Obviously, since I have not one but two systems that work flawlessly with the atyfb driver and a mach64, albeit somewhat differently (see below) .. I am in a good position to provide you with any files on my system that you think might be of interest. In any event, I should probably mention one other thing that I have read/heard on the subject, which is that if both vesa and the native driver are enabled in your kernel config, the native driver wins. This may be useful since grub lets you easily change your boot options on the fly .. eg. to recover from a messed up situation. Also, I am currently setting up an etch system on the same laptop and after my posting late last night, I noticed that my grub menu entries for the etch system do not specify anything regarding the fb console at all..! No video=atyfb or specifying the dimensions of my display in pixels. And yet, the laptop boots by default into its native 1400x1050 mode. No artifacts .. a perfect display as on a bran new high-end hardware terminal. This, btw is with the more recent 2.6.20 kernel (I typically run sarge with a 2.4.27 custom kernel). I also vaguely remember that, much to my delight, the 1400x1050 mode was already defined in the source file that contains all the modelines. But I had to compile custom kernels over and over for a number of other reasons .. so I'm not sure any more whether the kernel config I started off with had ati support enabled by default or if I had to enable it myself. The former, I think. Rather revealing of the maturity of the atyfb driver..! I requested from the ubuntu folks that they add this mode to their live system cd at least .. and possibly the installer .. to no avail .. that was about two years ago. Do you have access to a system where you could run some tests with possibly another video card than my old mach64..? I was thinking if you had some hands-on experience of this not so well documented area .. it might help clarify the process .. correct possible errors and omissions on my part .. make sure there is no miscommunication .. as well as .. if you are successful .. being able to add at least one video card to your database of video cards that we know for a fact are fully supported by a native driver. I should also add that from the user angle the results in my case were well worth the effort since the only (major where I am concerned) visual difference between my linux console and a full-screen xterm on my etch system is the fact that the linux console is limited to 16 colors rather than xterm's 256. Unfortunately, although I have fiddled with a couple of programs that let you dump an fb console to a file I have not been successful and so I do not have screenshots to prove it. Sorry about the vagueness/verbosity of the above but that's just about all I have been able to figure out so far. If I understood the fb console a bit better, I would be a lot more terse and I might consider updating that obsolete Framebuffer Console HOWTO. Regrettably, I have never had the time to work and play with the code of at least my own video card's driver. Oh, if you do decide to add something to your web page, please let me know and I'll be glad to take a look. Thanks, cga -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: vesa display codes (Etch Xorg memory leak?)
On Sun, 2007-05-20 at 17:25 -0400, cga2000 wrote: On Sun, May 20, 2007 at 12:01:18PM EDT, Greg Folkert wrote: Mind if I add snippets of you two posts to Owen to that Vesa Mode Page? Not in principle naturally. [snip] Oh, if you do decide to add something to your web page, please let me know and I'll be glad to take a look. I'll just pass then. -- greg, [EMAIL PROTECTED] PGP key: 1024D/B524687C 2003-08-05 Fingerprint: E1D3 E3D7 5850 957E FED0 2B3A ED66 6971 B524 687C Alternate Fingerprint: 09F9 1102 9D74 E35B D841 56C5 6356 88C0 signature.asc Description: This is a digitally signed message part
Re: vesa display codes (Etch Xorg memory leak?)
On Sun, 2007-05-20 at 01:10 -0400, cga2000 wrote: On Sat, May 19, 2007 at 07:33:51PM EDT, Owen Heisler wrote: On Sat, 2007-05-19 at 19:10 -0400, Greg Folkert wrote: On Fri, 2007-05-18 at 00:10 -0400, Greg Folkert wrote: On Thu, 2007-05-17 at 18:34 -0500, Owen Heisler wrote: On Thu, 2007-05-17 at 16:02 -0400, Greg Folkert wrote: http://www.gregfolkert.net/info/vesa-display-codes.html Very helpful! Although no 1280x960 (grr) unfortunately. Is there any way to get that? vbetool is supposed to do it. Or hwinfo --vbe But they aren't exactly 100%, as I haven't been able to get the info out of the hardware yet. FYI, I've updated the page and now lists a few things to get other modes. Though the framebuffer howtos have not really been updated since 2000 or 2001. video=:xres:,yres:,depth:,left:,right:,hslen:,upper:,lower:,vslen: It looks like I need something like this: Modeline 1280x1024 DCF HR SH1 SH2 HFL VR SV1 SV2 VFL Is there some way to get that from xorg? Oh .. maybe, $ modeline2fb Same fbset package as the other stuff previously mentioned. A list of the available video drivers here (?): http://linux-fbdev.sourceforge.net/driverlist.php I tried: video=rivafb:1280x960 video=vesafb:1280x960 but neither worked. signature.asc Description: This is a digitally signed message part
Re: vesa display codes (Etch Xorg memory leak?)
On Sun, May 20, 2007 at 07:25:41PM EDT, Owen Heisler wrote: [..] A list of the available video drivers here (?): http://linux-fbdev.sourceforge.net/driverlist.php I tried: video=rivafb:1280x960 video=vesafb:1280x960 but neither worked. You do realize that you may need to compile a custom kernel to enable support for a given video card..? Something else that I didn't mention. I was never able get the framebuffer console to initialize correctly when support for my card was specified via a M module. This may no longer be the case .. maybe I didn't do it right .. but I recommend you specify an * in your kernel's config .. meaning built-in support. I have a feeling the above page is not current. It says kernel 2.4 on each and every line and that's hardly bleeding edge. Obviously, developers are not all that interested in 2-3 year old kernels. On the other hand, after all the time I spent looking for solutions to my problem, I'd say some of the names on that page look familiar and I'm sure that even if one person in particular doesn't or no longer supports the particular driver you're interested in .. they would gladly direct you to the current maintainer should you decide to email them directly. They don't have such a large user base so someone genuinely interested who might dig up some real problem or other is usually of interest to them. But I would make sure to identify the correct party before emailing them. The output of $ lspci -vv and a quick peek at a recent kernel's ../drivers/ video subtree .. might help (?) Be aware that the video card is sometimes not the end of the story. This was the case with my mach64 where some versions were fully supported and others weren't .. because a different version of the chip that the card uses (or a different chip altogether) can make all the difference. Good luck with it and you're welcome to get back to me on/off-list if you think I may be able to help. Thanks, cga -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: vesa display codes (Etch Xorg memory leak?)
On Fri, 2007-05-18 at 00:10 -0400, Greg Folkert wrote: On Thu, 2007-05-17 at 18:34 -0500, Owen Heisler wrote: On Thu, 2007-05-17 at 16:02 -0400, Greg Folkert wrote: http://www.gregfolkert.net/info/vesa-display-codes.html Very helpful! Although no 1280x960 (grr) unfortunately. Is there any way to get that? vbetool is supposed to do it. Or hwinfo --vbe But they aren't exactly 100%, as I haven't been able to get the info out of the hardware yet. Okay hwinfo --vbe doesn't mention 1280x960 here either. signature.asc Description: This is a digitally signed message part
Re: vesa display codes (Etch Xorg memory leak?)
On Sat, 2007-05-19 at 17:09 -0500, Owen Heisler wrote: On Fri, 2007-05-18 at 00:10 -0400, Greg Folkert wrote: On Thu, 2007-05-17 at 18:34 -0500, Owen Heisler wrote: On Thu, 2007-05-17 at 16:02 -0400, Greg Folkert wrote: http://www.gregfolkert.net/info/vesa-display-codes.html Very helpful! Although no 1280x960 (grr) unfortunately. Is there any way to get that? vbetool is supposed to do it. Or hwinfo --vbe But they aren't exactly 100%, as I haven't been able to get the info out of the hardware yet. Okay hwinfo --vbe doesn't mention 1280x960 here either. FYI, I've updated the page and now lists a few things to get other modes. Though the framebuffer howtos have not really been updated since 2000 or 2001. -- greg, [EMAIL PROTECTED] PGP key: 1024D/B524687C 2003-08-05 Fingerprint: E1D3 E3D7 5850 957E FED0 2B3A ED66 6971 B524 687C Alternate Fingerprint: 09F9 1102 9D74 E35B D841 56C5 6356 88C0 signature.asc Description: This is a digitally signed message part
Re: vesa display codes (Etch Xorg memory leak?)
On Sat, 2007-05-19 at 19:10 -0400, Greg Folkert wrote: On Fri, 2007-05-18 at 00:10 -0400, Greg Folkert wrote: On Thu, 2007-05-17 at 18:34 -0500, Owen Heisler wrote: On Thu, 2007-05-17 at 16:02 -0400, Greg Folkert wrote: http://www.gregfolkert.net/info/vesa-display-codes.html Very helpful! Although no 1280x960 (grr) unfortunately. Is there any way to get that? vbetool is supposed to do it. Or hwinfo --vbe But they aren't exactly 100%, as I haven't been able to get the info out of the hardware yet. FYI, I've updated the page and now lists a few things to get other modes. Though the framebuffer howtos have not really been updated since 2000 or 2001. video=:xres:,yres:,depth:,left:,right:,hslen:,upper:,lower:,vslen: It looks like I need something like this: Modeline 1280x1024 DCF HR SH1 SH2 HFL VR SV1 SV2 VFL Is there some way to get that from xorg? And what do I use for the framebuffer device (video=)? Thanks signature.asc Description: This is a digitally signed message part
Re: vesa display codes (Etch Xorg memory leak?)
On Sat, 2007-05-19 at 18:33 -0500, Owen Heisler wrote: video=:xres:,yres:,depth:,left:,right:,hslen:,upper:,lower:,vslen: It looks like I need something like this: Modeline 1280x1024 DCF HR SH1 SH2 HFL VR SV1 SV2 VFL Is there some way to get that from xorg? And what do I use for the framebuffer device (video=)? I don't know. Exactly why I said they have really been updated since 2000 or 2001. -- greg, [EMAIL PROTECTED] PGP key: 1024D/B524687C 2003-08-05 Fingerprint: E1D3 E3D7 5850 957E FED0 2B3A ED66 6971 B524 687C Alternate Fingerprint: 09F9 1102 9D74 E35B D841 56C5 6356 88C0 signature.asc Description: This is a digitally signed message part
Re: vesa display codes (Etch Xorg memory leak?)
On Sat, May 19, 2007 at 07:33:51PM EDT, Owen Heisler wrote: On Sat, 2007-05-19 at 19:10 -0400, Greg Folkert wrote: On Fri, 2007-05-18 at 00:10 -0400, Greg Folkert wrote: On Thu, 2007-05-17 at 18:34 -0500, Owen Heisler wrote: On Thu, 2007-05-17 at 16:02 -0400, Greg Folkert wrote: http://www.gregfolkert.net/info/vesa-display-codes.html Very helpful! Although no 1280x960 (grr) unfortunately. Is there any way to get that? vbetool is supposed to do it. Or hwinfo --vbe But they aren't exactly 100%, as I haven't been able to get the info out of the hardware yet. FYI, I've updated the page and now lists a few things to get other modes. Though the framebuffer howtos have not really been updated since 2000 or 2001. video=:xres:,yres:,depth:,left:,right:,hslen:,upper:,lower:,vslen: It looks like I need something like this: Modeline 1280x1024 DCF HR SH1 SH2 HFL VR SV1 SV2 VFL Is there some way to get that from xorg? And what do I use for the framebuffer device (video=)? I missed the earlier posts on this thread so this is a bit of a shot in the dark. Please ignore if this is .. er .. off topic :-) I believe video= is card-specific and you need to specify the name of the kernel video driver that supports your card .. if there is one, that is. I have an antique laptop with an ATI Mach64 card which is fully supported by the atyfb driver. So I specify this in my grub menu file: kernel /boot/vmlinuz-2.4.27.041213.2 root=/dev/hda11 ro video=atyfb:1400x1050 In other words, I do not use the generic vga/vesa driver .. the one that has the vga=791 .. etc. syntax .. but rather one that's specific to my hardware. The reason I use it rather than the generic is that among other things it lets me run a 1400x1050 linux console which happens to be the native mode of my laptop's panel, taking care of the blurred fonts I was getting with other modes available with the generic driver such as 1024x768 .. Makes a huge difference. It also gives me twice the real-estate ~1.4M vs. ~0.7M pixels or so .. while maintaining the correct 4:3 ratio as opposed to the wide-screen mode of 1280x1024 that I used for a while with the generic driver. In order to get this to work I had to do a bit of kernel configuration to enable support for my card .. add the 1400x1050 mode to some file or other in the ../drivers/ sub-directory of the kernel source tree .. I think this file is common to all the different drivers .. and naturally build a custom kernel. Depending on your card .. which kernel you are using .. who built it .. whether he enabled the driver that you need .. the mode you plan to use .. all the above may not even be necessary. And then again your particular card may not be supported .. in which case you're out of luck and will have to stick with the generic driver until someone adds support for your particular hardware. Unfortunately, I don't know of a site that has the list of currently supported cards and which particular module supports each of them. In any case, the semi-obsolete framebuffer console HOWTO is worth a read. Other places to look for additional info: $ man fbset $ man 5 fb.modes You probably need to do an apt-get install fbset of similar to have access to these documents on your machine. HTH Thanks, cga -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: vesa display codes (Etch Xorg memory leak?)
On Sat, May 19, 2007 at 07:33:51PM EDT, Owen Heisler wrote: On Sat, 2007-05-19 at 19:10 -0400, Greg Folkert wrote: On Fri, 2007-05-18 at 00:10 -0400, Greg Folkert wrote: On Thu, 2007-05-17 at 18:34 -0500, Owen Heisler wrote: On Thu, 2007-05-17 at 16:02 -0400, Greg Folkert wrote: http://www.gregfolkert.net/info/vesa-display-codes.html Very helpful! Although no 1280x960 (grr) unfortunately. Is there any way to get that? vbetool is supposed to do it. Or hwinfo --vbe But they aren't exactly 100%, as I haven't been able to get the info out of the hardware yet. FYI, I've updated the page and now lists a few things to get other modes. Though the framebuffer howtos have not really been updated since 2000 or 2001. video=:xres:,yres:,depth:,left:,right:,hslen:,upper:,lower:,vslen: It looks like I need something like this: Modeline 1280x1024 DCF HR SH1 SH2 HFL VR SV1 SV2 VFL Is there some way to get that from xorg? Oh .. maybe, $ modeline2fb Same fbset package as the other stuff previously mentioned. Thanks, cga -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch Xorg memory leak?
On Sun, May 13, 2007 at 07:51:18AM -0400, Douglas Allan Tutty wrote: Over time, xorg takes up more and more memory. On my i386, I only have 64 MB of ram so I can only run X for about 45 minutes before the system thrashes. Eventually, Xorg dies but doesn't release the screen. If I let the system sit for about 60 minutes, the thrashing subsides and I can ssh in and reboot to get my screen back. Hard on the disk, but the i386 is only a client box. On my amd64 Athlon64, I have 1 GB of ram so can run xorg; I haven't left this computer run long enough to run out of memory and thrash since its my main box; it gets turned off at night and through the day acts as a server. In the evening if I want to access the big screen, I'll run X for a couple of hours. This happens irrespective of window manager or DTE; on the i386 icewm takes up less memory so Xorg will run longer before thrashing than if I'm running xfce. It also happens if I don't use a wm at all and just run rxvt. Is anyone else seeing this? Is it fixed in Lenny/Sid? Any plans to fix it for Etch? Update: Tried the vesa xorg driver. No difference except that after I exit X back to CLI, my console colours are messed up; I guess the vesa driver didn't restore the hardware; I'll try a reboot. I also made some progress that may help with reproducability: startx rxvt and run nice top. shrink so just watch the header info e.g. swap used ssh titan -f /usr/bin/kpdf open a long file view each page in turn As each new page is viewed, xorg uses more memory, and swap goes up. Its as if xorg is using memory to hold the image for the new page and isn't releasing the memory used to hold the old page. I conjuecture that its holding all viewed pages in memory. Doug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch Xorg memory leak?
Package: xserver-xorg-core Running up-to-date Etch. Over time, xorg takes up more and more memory. I have two computers: rocky: PII-233 with 64 MB ram running i386 titan: Athlon64 with 1 GB ram running amd64 On my i386, I only have 64 MB of ram so I can only run X for about 45 minutes before the system thrashes. Eventually, Xorg dies but doesn't release the screen. If I let the system sit for about 60 minutes, the thrashing subsides and I can ssh in and reboot to get my screen back. Hard on the disk, but the i386 is only a client box. On my amd64 Athlon64, I have 1 GB of ram so can run xorg; I haven't left this computer run long enough to run out of memory and thrash since its my main box; it gets turned off at night and through the day acts as a server. In the evening if I want to access the big screen, I'll run X for a couple of hours. This happens irrespective of window manager or DTE; on the i386 icewm takes up less memory so Xorg will run longer before thrashing than if I'm running xfce. It also happens if I don't use a wm at all and just run rxvt. Tried the vesa xorg driver instead of the trident with no change. Here's a concrete example of the problem. This is run on my i386 (rocky) and titan is my main Athlon64 amd64 box. startx rxvt and run nice top. shrink so just watch the header info e.g. swap used ssh titan -f /usr/bin/kpdf open a long file view each page in turn As each new page is viewed, xorg uses more memory, and swap goes up. Its as if xorg is using memory to hold the image for the new page and isn't releasing the memory used to hold the old page. I conjuecture that its holding all viewed pages in memory. On the amd64, I have the xorg metapackage installed. However, on the i386 I am very tight on disk space so only have what's needed: xserver-xorg-video-vesa xserver-xorg-video-trident with everything on which they depend. xorg.conf is generated by debconf. I added a virtual line but removing that makes no difference. Thanks, Doug. --- here's my xorg.conf # /etc/X11/xorg.conf (xorg X Window System server configuration file) # # This file was generated by dexconf, the Debian X Configuration tool, using # values from the debconf database. # # Edit this file with caution, and see the /etc/X11/xorg.conf manual page. # (Type man /etc/X11/xorg.conf at the shell prompt.) # # This file is automatically updated on xserver-xorg package upgrades *only* # if it has not been modified since the last upgrade of the xserver-xorg # package. # # If you have edited this file but would like it to be automatically updated # again, run the following command: # sudo dpkg-reconfigure -phigh xserver-xorg Section Files FontPath/usr/share/fonts/X11/misc FontPath/usr/X11R6/lib/X11/fonts/misc FontPath/usr/share/fonts/X11/cyrillic FontPath/usr/X11R6/lib/X11/fonts/cyrillic FontPath/usr/share/fonts/X11/100dpi/:unscaled FontPath/usr/X11R6/lib/X11/fonts/100dpi/:unscaled FontPath/usr/share/fonts/X11/75dpi/:unscaled FontPath/usr/X11R6/lib/X11/fonts/75dpi/:unscaled FontPath/usr/share/fonts/X11/Type1 FontPath/usr/X11R6/lib/X11/fonts/Type1 FontPath/usr/share/fonts/X11/100dpi FontPath/usr/X11R6/lib/X11/fonts/100dpi FontPath/usr/share/fonts/X11/75dpi FontPath/usr/X11R6/lib/X11/fonts/75dpi # path to defoma fonts FontPath/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType EndSection Section Module Loadbitmap Loadddc Loaddri Loadextmod Loadfreetype Loadglx Loadint10 Loadvbe EndSection Section InputDevice Identifier Generic Keyboard Driver kbd Option CoreKeyboard Option XkbRules xorg Option XkbModel pc101 Option XkbLayout us EndSection Section InputDevice Identifier Configured Mouse Driver mouse Option CorePointer Option Device/dev/input/mice Option Protocol ImPS/2 Option Emulate3Buttons true EndSection Section Device Identifier Trident Microsystems 3DImage 9750 Driver trident BusID PCI:1:1:0 VideoRam4096 EndSection Section Monitor Identifier Samtron 76V Option DPMS HorizSync 30-70 VertRefresh 50-160 EndSection Section Screen Identifier Default Screen Device Trident Microsystems 3DImage 9750 Monitor Samtron 76V DefaultDepth24 SubSection Display Depth 1 Modes
Re: Etch Xorg memory leak?
On Fri, May 18, 2007 at 09:18:01PM -0400, Douglas Allan Tutty wrote: Package: xserver-xorg-core Sorry for the noise. I thought I'd turn my question into a bug report but sent it here instead of bugs by accident. Doug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch Xorg memory leak?
On Fri, May 18, 2007 at 09:24:37PM -0400, Douglas Allan Tutty wrote: On Fri, May 18, 2007 at 09:18:01PM -0400, Douglas Allan Tutty wrote: Package: xserver-xorg-core Sorry for the noise. I thought I'd turn my question into a bug report but sent it here instead of bugs by accident. Don't forget to tag it with a severity. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Etch Xorg memory leak?
On Sun, May 13, 2007 at 02:43:15PM +0200, Hervé Piedvache wrote: Le dimanche 13 mai 2007, Douglas Allan Tutty a écrit : I'm having trouble with Xorg under Etch i386 and similar annoyance under amd64. Over time, xorg takes up more and more memory. On my i386, I only have I had the same trouble was my video driver which made that ... Switch to last version of nvidia solved the trouble for me ! But under i386 its not nvidia but trident. All the same, I'll try vesa and see if I can get adequate resolution and refresh. I don't want to trade eyestrain for Xstrain. Any idea what the root problem is? Doug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch Xorg memory leak?
On Sun, May 13, 2007 at 10:22:00AM -0500, Mumia W.. wrote: On 05/13/2007 06:51 AM, Douglas Allan Tutty wrote: I'm having trouble with Xorg under Etch i386 and similar annoyance under amd64. Over time, xorg takes up more and more memory. [...] I also installed Etch on a computer that has only 64MB of RAM, and I haven't noticed this problem. As Hervé Piedvache suggested, it looks like it's related to the video driver. Try out the VESA driver and see if the problem recurs. Would if I could. On the i386, dpkg-reconfigure xserver-xorg asks if I want automatic video device yes/no, saying that no allows me to choose the appropriate driver. I choos no and still get no choice. I change trident to vesa in the xorg.conf and startx complains no such driver. I read man xorg.conf and under see also, it lists vesa(4) as well trident(4). I try man vesa, no manual entry. I try man trident and get a man page. It seems that debian's i386 Etch doesn't include vesa or something else screwy is going on. Continuing to focus on the i386 box with 64 MB ram (the one that eventually dies from Parkinson's law): Its day-to-day perpose is as a slim client to my other (Athlon64) box. It doesn't have the resourses to run anything big on its own. So to read a pdf I use ssh and run kpdf on the athlon box. I can read for about 20 minutes (15 pages or so) before the box dies. Thanks, Doug. FYI, here's my xorg.conf. # /etc/X11/xorg.conf (xorg X Window System server configuration file) # # This file was generated by dexconf, the Debian X Configuration tool, using # values from the debconf database. # # Edit this file with caution, and see the /etc/X11/xorg.conf manual page. # (Type man /etc/X11/xorg.conf at the shell prompt.) # # This file is automatically updated on xserver-xorg package upgrades *only* # if it has not been modified since the last upgrade of the xserver-xorg # package. # # If you have edited this file but would like it to be automatically updated # again, run the following command: # sudo dpkg-reconfigure -phigh xserver-xorg Section Files FontPath/usr/share/fonts/X11/misc FontPath/usr/X11R6/lib/X11/fonts/misc FontPath/usr/share/fonts/X11/cyrillic FontPath/usr/X11R6/lib/X11/fonts/cyrillic FontPath/usr/share/fonts/X11/100dpi/:unscaled FontPath/usr/X11R6/lib/X11/fonts/100dpi/:unscaled FontPath/usr/share/fonts/X11/75dpi/:unscaled FontPath/usr/X11R6/lib/X11/fonts/75dpi/:unscaled FontPath/usr/share/fonts/X11/Type1 FontPath/usr/X11R6/lib/X11/fonts/Type1 FontPath/usr/share/fonts/X11/100dpi FontPath/usr/X11R6/lib/X11/fonts/100dpi FontPath/usr/share/fonts/X11/75dpi FontPath/usr/X11R6/lib/X11/fonts/75dpi # path to defoma fonts FontPath/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType EndSection Section Module Loadbitmap Loadddc Loaddri Loadextmod Loadfreetype Loadglx Loadint10 Loadvbe EndSection Section InputDevice Identifier Generic Keyboard Driver kbd Option CoreKeyboard Option XkbRules xorg Option XkbModel pc101 Option XkbLayout us EndSection Section InputDevice Identifier Configured Mouse Driver mouse Option CorePointer Option Device/dev/input/mice Option Protocol ImPS/2 Option Emulate3Buttons true EndSection Section Device Identifier Trident Microsystems 3DImage 9750 Driver trident BusID PCI:1:1:0 VideoRam4096 EndSection Section Monitor Identifier Samtron 76V Option DPMS HorizSync 30-70 VertRefresh 50-160 EndSection Section Screen Identifier Default Screen Device Trident Microsystems 3DImage 9750 Monitor Samtron 76V DefaultDepth24 SubSection Display Depth 1 Modes 1024x768 EndSubSection SubSection Display Depth 4 Modes 1024x768 EndSubSection SubSection Display Depth 8 Modes 1024x768 EndSubSection SubSection Display Depth 15 Modes 1024x768 EndSubSection SubSection Display Depth 16 Modes 1024x768 EndSubSection SubSection Display Depth 24 Modes
Re: Etch Xorg memory leak?
On Thu, May 17, 2007 at 12:17:34PM -0400, Douglas Allan Tutty wrote: On Sun, May 13, 2007 at 10:22:00AM -0500, Mumia W.. wrote: On 05/13/2007 06:51 AM, Douglas Allan Tutty wrote: Try out the VESA driver and see if the problem recurs. Would if I could. On the i386, dpkg-reconfigure xserver-xorg asks if I want automatic video device yes/no, saying that no allows me to choose the appropriate driver. I choos no and still get no choice. I change trident to vesa in the xorg.conf and startx complains no such driver. I read man xorg.conf and under see also, it lists vesa(4) as well trident(4). I try man vesa, no manual entry. I try man trident and get a man page. It seems that debian's i386 Etch doesn't include vesa or something else screwy is going on. What xserver-xorg-video-* packages do you have installed? Cheers, Tom -- Thou hast seen nothing yet. -- Miguel de Cervantes signature.asc Description: Digital signature
Re: Etch Xorg memory leak?
On Thu, May 17, 2007 at 05:31:09PM +0100, Tom Furie wrote: On Thu, May 17, 2007 at 12:17:34PM -0400, Douglas Allan Tutty wrote: On Sun, May 13, 2007 at 10:22:00AM -0500, Mumia W.. wrote: On 05/13/2007 06:51 AM, Douglas Allan Tutty wrote: Try out the VESA driver and see if the problem recurs. What xserver-xorg-video-* packages do you have installed? Thanks, Sorry about that. I'll install the vesa driver. I don't have -all since everthing won't fit on my 850 MB hard drive. Doug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch Xorg memory leak?
On Thu, 2007-05-17 at 12:58 -0400, Douglas Allan Tutty wrote: On Thu, May 17, 2007 at 05:31:09PM +0100, Tom Furie wrote: On Thu, May 17, 2007 at 12:17:34PM -0400, Douglas Allan Tutty wrote: On Sun, May 13, 2007 at 10:22:00AM -0500, Mumia W.. wrote: On 05/13/2007 06:51 AM, Douglas Allan Tutty wrote: Try out the VESA driver and see if the problem recurs. What xserver-xorg-video-* packages do you have installed? Thanks, Sorry about that. I'll install the vesa driver. I don't have -all since everthing won't fit on my 850 MB hard drive. You might also want to try the frame buffer interface. By adding a mode to your kernel stanza in grub... LILO I haven't used in years. So you'll have to finger that out yourself if you use it. But I have made a small webpage to describe the VESA video modes, with an example on the bottom. Then selecting yes to Do you want to use the framebuffer interface question during: dpkg-reconfigure -plow xserver-xorg http://www.gregfolkert.net/info/vesa-display-codes.html And, yes, I have started rebuilding my website. Though it'll be slow. -- greg, [EMAIL PROTECTED] PGP key: 1024D/B524687C 2003-08-05 Fingerprint: E1D3 E3D7 5850 957E FED0 2B3A ED66 6971 B524 687C Alternate Fingerprint: 09F9 1102 9D74 E35B D841 56C5 6356 88C0 signature.asc Description: This is a digitally signed message part
Re: vesa display codes (Etch Xorg memory leak?)
On Thu, 2007-05-17 at 16:02 -0400, Greg Folkert wrote: http://www.gregfolkert.net/info/vesa-display-codes.html Very helpful! Although no 1280x960 (grr) unfortunately. Is there any way to get that? signature.asc Description: This is a digitally signed message part
Re: vesa display codes (Etch Xorg memory leak?)
On Thu, 2007-05-17 at 18:34 -0500, Owen Heisler wrote: On Thu, 2007-05-17 at 16:02 -0400, Greg Folkert wrote: http://www.gregfolkert.net/info/vesa-display-codes.html Very helpful! Although no 1280x960 (grr) unfortunately. Is there any way to get that? vbetool is supposed to do it. Or hwinfo --vbe But they aren't exactly 100%, as I haven't been able to get the info out of the hardware yet. -- greg, [EMAIL PROTECTED] PGP key: 1024D/B524687C 2003-08-05 Fingerprint: E1D3 E3D7 5850 957E FED0 2B3A ED66 6971 B524 687C Alternate Fingerprint: 09F9 1102 9D74 E35B D841 56C5 6356 88C0 signature.asc Description: This is a digitally signed message part
Etch Xorg memory leak?
I'm having trouble with Xorg under Etch i386 and similar annoyance under amd64. Over time, xorg takes up more and more memory. On my i386, I only have 64 MB of ram so I can only run X for about 45 minutes before the system thrashes. Eventually, Xorg dies but doesn't release the screen. If I let the system sit for about 60 minutes, the thrashing subsides and I can ssh in and reboot to get my screen back. Hard on the disk, but the i386 is only a client box. On my amd64 Athlon64, I have 1 GB of ram so can run xorg; I haven't left this computer run long enough to run out of memory and thrash since its my main box; it gets turned off at night and through the day acts as a server. In the evening if I want to access the big screen, I'll run X for a couple of hours. This happens irrespective of window manager or DTE; on the i386 icewm takes up less memory so Xorg will run longer before thrashing than if I'm running xfce. It also happens if I don't use a wm at all and just run rxvt. Is anyone else seeing this? Is it fixed in Lenny/Sid? Any plans to fix it for Etch? Thanks, Doug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch Xorg memory leak?
I had the same trouble was my video driver which made that ... Switch to last version of nvidia solved the trouble for me ! regards, Le dimanche 13 mai 2007, Douglas Allan Tutty a écrit : I'm having trouble with Xorg under Etch i386 and similar annoyance under amd64. Over time, xorg takes up more and more memory. On my i386, I only have 64 MB of ram so I can only run X for about 45 minutes before the system thrashes. Eventually, Xorg dies but doesn't release the screen. If I let the system sit for about 60 minutes, the thrashing subsides and I can ssh in and reboot to get my screen back. Hard on the disk, but the i386 is only a client box. On my amd64 Athlon64, I have 1 GB of ram so can run xorg; I haven't left this computer run long enough to run out of memory and thrash since its my main box; it gets turned off at night and through the day acts as a server. In the evening if I want to access the big screen, I'll run X for a couple of hours. This happens irrespective of window manager or DTE; on the i386 icewm takes up less memory so Xorg will run longer before thrashing than if I'm running xfce. It also happens if I don't use a wm at all and just run rxvt. Is anyone else seeing this? Is it fixed in Lenny/Sid? Any plans to fix it for Etch? Thanks, Doug. -- Hervé Piedvache
Re: Etch Xorg memory leak?
On 05/13/2007 06:51 AM, Douglas Allan Tutty wrote: I'm having trouble with Xorg under Etch i386 and similar annoyance under amd64. Over time, xorg takes up more and more memory. [...] I also installed Etch on a computer that has only 64MB of RAM, and I haven't noticed this problem. As Hervé Piedvache suggested, it looks like it's related to the video driver. Try out the VESA driver and see if the problem recurs. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: xserver-xorg memory leak
On Sun, Feb 25, 2007 at 08:26:03PM -0500, Kamaraju S Kusumanchi wrote: Bill Moseley wrote: Every once in a while my desktop machine becomes unresponsive and top shows that Xorg is using all my memory. Are there any errors in the log files such as /var/log/Xorg.0.log ? What is your video card, what driver are you using? Are you tracking etch or sid? No errors in my Xorg.0.log files that are not normal (e.g. (EE) AIGLX: Screen 1 is not DRI capable). I'm running a Matrox G550 with Xinerama. Tracking sid. It would be nice if the Xorg log file had time stamps. Any suggestions what to do next time I see Xorg using a lot of memory? Think running lsof or pmap would reveal anything useful? -- Bill Moseley [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: xserver-xorg memory leak
On Sun, Feb 25, 2007 at 10:23:09PM -0500, Roberto C. Sanchez wrote: Firefox? I haven't seen it in a while, but I used to occasionally see my machine get *really* slow and when I would do a top, X was chewing everything up. However, if I closed Firefox (or killed it), things would return to normal. Firefox was not running. I've also had Firefox eat memory. I think it was due to too many extensions loaded, though. -- Bill Moseley [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
xserver-xorg memory leak
This is just a probe to see if anyone else is having problems with Xorg eating memory. Every once in a while my desktop machine becomes unresponsive and top shows that Xorg is using all my memory. I was out of town and ssh'ing into my machine every day or so and it was fine, except today I was running mutt on that machine and noticed mutt got killed a few times -- and again Xorg was consuming all memory, so I killed it.[1] I see this bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=326956 And I do have a background script that loads a new root window image every five minutes. But, I don't normally notice that the memory increases that much. The machine (and Xorg) have been running for about two months, so it's odd that all of the sudden it eats memory. I just loaded an image 1000 times (using display -window root test.jpg) and watched top, but no growth in memory. This is what it is like after that, which is normal: PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 5407 root 5 -10 105m 36m 73m S 1.3 4.1 2:21.97 Xorg So it doesn't seem like it's my background image problem. Any other ideas what might be the problem? ii xserver-xorg 7.1.0-11 the X.Org X server ii xserver-xorg-core 1.1.1-15 X.Org X server -- core server [1] By the way, when I remotely kill xorg my monitors no longer are controlled by dpms -- so they power on. (when I came home my monitors were indeed no longer in sleep mode.) Can I remotely run startx or is there a utility to remotely force my monitors to sleep mode when not running the xserver? -- Bill Moseley [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: xserver-xorg memory leak
Bill Moseley wrote: Every once in a while my desktop machine becomes unresponsive and top shows that Xorg is using all my memory. Are there any errors in the log files such as /var/log/Xorg.0.log ? What is your video card, what driver are you using? Are you tracking etch or sid? raju -- Kamaraju S Kusumanchi http://www.people.cornell.edu/pages/kk288/ http://malayamaarutham.blogspot.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: xserver-xorg memory leak
On Sun, Feb 25, 2007 at 05:05:31PM -0800, Bill Moseley wrote: This is just a probe to see if anyone else is having problems with Xorg eating memory. Every once in a while my desktop machine becomes unresponsive and top shows that Xorg is using all my memory. Firefox? I haven't seen it in a while, but I used to occasionally see my machine get *really* slow and when I would do a top, X was chewing everything up. However, if I closed Firefox (or killed it), things would return to normal. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Xorg Memory Leak
Top reports Xorg using 90% of RAM and processes get killed. All swap is being used, but vmstat isn't showing that much so and si paging. Load average every once in a while will shoot up to 25 or so. I can find a few posts about memory leaks, but not may responses. And one memory leak bug report in xserver-xorg. I do have a script that updates my root window with an image every five minutes, which is also what but 326956 reports. Anyone else experiencing Xorg eating memory? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=326956 -- Bill Moseley [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Now xinerma is busted (Was: Xorg Memory Leak)
Pardon me for a second. Shit, shit shit! Ok, Now after a fresh dist-upgrade and a reboot only one of my monitors is running. This really sucks. For one thing when I upgraded to Xorg it decided to make my main monitor (the screen that comes up in text mode before running the xserver) the secondary monitor when Xorg is running. For the life of me, I couldn't get the config to do it the other way, so I swapped my monitor cables on my G550 card. But, now with the second monitor not starting with xinerama, without xinerama running Xorg using the secondary port on the card for the main monitor (which isn't working) and I get a window manager-less screen on the working monitor. In other words, I have to use xinerama, and poke around in the dark (literally) with my mouse to find windows that open on what xorg thinks is my main window. Enough with the ranting. What can I use to test my second monitor port on the G550 card to see if it's just xorg now enabling the second port, or if the card if busted? Is there a good place to get xorg support? Thanks, Here's my xorg.conf, if anyone is curious. # XF86Config-4 (XFree86 X server configuration file) generated by dexconf, the # Debian X Configuration tool, using values from the debconf database. # # Edit this file with caution, and see the XF86Config-4 manual page. # (Type man XF86Config-4 at the shell prompt.) # # This file is automatically updated on xserver-xfree86 package upgrades *only* # if it has not been modified since the last upgrade of the xserver-xfree86 # package. # # If you have edited this file but would like it to be automatically updated # again, run the following commands as root: # # cp /etc/X11/XF86Config-4 /etc/X11/XF86Config-4.custom # md5sum /etc/X11/XF86Config-4 /var/lib/xfree86/XF86Config-4.md5sum # dpkg-reconfigure xserver-xfree86 Section Files FontPath/usr/lib/X11/fonts/Speedo FontPath/usr/lib/X11/fonts/misc FontPath/usr/lib/X11/fonts/100dpi FontPath/usr/lib/X11/fonts/75dpi EndSection Section Module LoadGLcore Loadbitmap Loaddbe Loadddc Loaddri Loadextmod Loadfreetype Loadglx Loadint10 # not in old bumby Loadrecord Loadspeedo Loadtype1 Loadvbe # not in old bumby EndSection Section InputDevice Identifier Generic Keyboard Driver keyboard Option CoreKeyboard Option XkbRules xfree86 Option XkbModel pc104 # pc105 on bumby Option XkbLayout us EndSection Section InputDevice Identifier Configured Mouse Driver mouse Option CorePointer Option Device/dev/psaux Option Protocol ImPS/2 Option Emulate3Buttons true Option ZAxisMapping 4 5 EndSection # Video Card- Section Device Identifier Matrox G550[0] Driver mga Screen 0 BusID PCI:1:0:0 Option AGPMode 4 Option HWcursor EndSection Section Device Identifier Matrox G550[1] Driver mga Screen 1 BusID PCI:1:0:0 Option AGPMode 4 Option HWcursor EndSection #- Monitors - Section Monitor Identifier SonyG500 HorizSync 30-107 VertRefresh 50-85 Option DPMS DisplaySize 400 300 # 15.57 x 11.76 EndSection Section Monitor Identifier Dell21 HorizSync 30-107 Option DPMS VertRefresh 50-85 #VertRefresh 50-80 DisplaySize 362 273 # 14.25 x 10.75 EndSection Section Screen Identifier LeftScreen Device Matrox G550[0] Monitor SonyG500 DefaultDepth24 SubSection Display Depth 24 Modes 1280x960 1024x768 EndSubSection EndSection Section Screen Identifier RightScreen Device Matrox G550[1] Monitor Dell21 DefaultDepth24 SubSection Display Depth 24 Modes 1280x960 1024x768 EndSubSection EndSection Section ServerLayout Identifier Default Layout # Option Xinerama on Screen 0 LeftScreen 0 0 Screen 1 RightScreen RightOf LeftScreen InputDevice Generic Keyboard InputDevice Configured Mouse EndSection Section DRI Mode0666 EndSection -- Bill Moseley [EMAIL
Re: Now xinerma is busted (Was: Xorg Memory Leak)
Whew. Panic time is over. The drivers from the Matrox site fixed everything. Yea Matrox! Xorg put my monitors back in the right order and both monitors are working. -- Bill Moseley [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
