Re: Opera 9.51
On Tue, Jul 15, 2008 at 02:58:42PM +, Jack Malmostoso wrote: > On Tue, 15 Jul 2008 16:00:09 +0200, Christopher Judd wrote: > > > Does anyone have an idea as to what's going on here? > > I'd suggest you move your profile away and start from scratch. I've been > using 9.5x on AMD64 from the first experimental builds and it works just > fine. > > Alternatively, make sure it's not a plugin problem. It is almost always the flash player plugins fault when firefox or opera misbehave. Sometimes the acrobat plugin. Either way, its Adobes fault. It's always Adobe's fault. :) -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: nvidia and latest unstable kernel image
Seb wrote: On Tue, 15 Jul 2008 15:14:26 -0500, Mark Allums <[EMAIL PROTECTED]> wrote: [...] The kernel and the nvidia driver didn't get along at first, but the latest kernel patchlevel and the latest nvidia driver version now get along swimmingly. So make sure everything is up to date. Thanks for the feedback. Are you referring to sid or experimental packages? Lenny/testing with a sid kernel, at my desk. Any 2.6.25 kernel that has problems with nvidia drivers was sid/unstable at the time. I had the problem here on a 7800GT when I moved from 2.6.24 to 2.6.25. I was patient, and they went away when nvidia released their latest driver. I'm using 173.14.09 right now, it's on the main download page for non windows and betas on the nvidia website. Works great. Mark Allums -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: nvidia and latest unstable kernel image
On Tue, Jul 15, 2008 at 08:07:56AM -0500, Seb wrote: > On Tue, 15 Jul 2008 08:37:15 -0400, > [EMAIL PROTECTED] (Lennart Sorensen) wrote: > > [...] > > > It compiles and works fine on my machine with those headers. > > > All you should have to do is: > > > apt-get update > > apt-get install nvidia-kernel-source modules-assistant > > rm -rf /usr/src/modules/nvidia-kernel > > m-a prepare -t > > m-a a-i -t nvidia-kernel > > apt-get install nvidia-glx > > Thanks a lot Lennart, I've been doing a similar procedure (after > updating apt and removing the old nvidia stuff as you suggest): > > m-a -t -f clean,build,install nvidia > apt-get install nvidia-glx > > and the module builds, albeit with an error I described earlier about a > *stack-protector file or directory not being found. But it installs > fine. /etc/X11/xorg.conf is also set to use nvidia, as it has since > several kernels back in my sid system. However, when booting into the > new kernel, all I get is a 1 pixel band displayed along the top of the > screen. Downgrading to 169.12-1 (which means going back to the old > 2.6.24-1 Linux kernel), as Jaime suggested, is the only way to get a > working nvidia in this system. That's just a warning from the kernel headers. No idea what that stack protector thing is about. As for the one pixel thing, I have no idea. So far I have seen issues for some 6100 users and a few 6200 users as well. Everybody else seems very happy with the new driver. One 6200 user installed the 96xx legacy driver instead which solved their problem entirely (and for a 6xxx card there really is no reason to be using the newer driver that I know of). > I use a GeForce 6100 card. The only report I could find with this 1 > pixel issue is: > > http://www.nvnews.net/vbulletin/showthread.php?t=115209 > > I don't understand where the problem is, but I'll try with your exact > recipe and see what happens! I am not even sure what the problem looks like personally. I use a plain AGP GF6200 card in one machine, and so far it has been just fine. But that is on i386 not amd64. I might be able to stick the 6200 in a 64bit machine next week after I transfer a build server at work to a new machine, after which the old server can become my desktop machine (athlon 64 3500+) and would end up with the 6200 card in it driving my two monitors. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: nvidia and latest unstable kernel image
On Tue, 15 Jul 2008 15:14:26 -0500, Mark Allums <[EMAIL PROTECTED]> wrote: [...] > The kernel and the nvidia driver didn't get along at first, but the > latest kernel patchlevel and the latest nvidia driver version now get > along swimmingly. So make sure everything is up to date. Thanks for the feedback. Are you referring to sid or experimental packages? -- Seb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: nvidia and latest unstable kernel image
Hi, I still cannot use the new 2.6.25 kernel due to this problem with nvidia module, even with the recently available linux-headers-2.6.25-2-amd64 and image packages. I'm starting to think that these don't work with my card anymore. If anybody has any further tips, I'd be grateful for them. Thanks. The kernel and the nvidia driver didn't get along at first, but the latest kernel patchlevel and the latest nvidia driver version now get along swimmingly. So make sure everything is up to date. Mark Allums -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: hibernate, just a question
Am Dienstag, 15. Juli 2008 schrieb Jaime Ochoa Malagón: > As far as I remember hibernate fail with nvidia/¿ati? drivers because > the video card state wasn't saved, could that be the change? > Hmmm, yes, might be. The nvidia-driver was also renewed, just as the kernel. Although I blacklisted it, it might be, they changed the code within newer versions. Good idea ! But let us see, if someone else is knowing more. Cheers Hans > On 7/15/08, Hans-J. Ullrich <[EMAIL PROTECTED]> wrote: > > Hi all, > > > > I am using swsusp with hibernate. In the past I had the problem, when > > hibernate started, only hibernate-ram was working. Using hibernate-disk ( > > same as /usr/bin/hibernate), the contents of the memory was not written > > to disk. So it failed. > > > > Now I am wanderin, although I never changed the configuration and never > > changed the version of hibernate, suddenly it is working. > > > > So, glad everything is fine now, the situuation is not really satisfying, > > as I want to know, why it is working now. Maybe someone is knowing more. > > Was there something known in the past about it ? (there was a bugreport > > by me) Or have there been some changes to the kernel relating to this ? > > > > I would be pleased about every information, to learn what happened ! > > > > Kind regards > > > > Hans > > > > > > -- > > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > > with a subject of "unsubscribe". Trouble? Contact > > [EMAIL PROTECTED] > > -- > Perhaps the depth of love can be calibrated by the number of different > selves that are actively involved in a given relationship. > > Carl Sagan (Contact) > > Jaime Ochoa Malagón > Arquitecto de Soluciones > Cel: +52 (55) 1021 0774 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: hibernate, just a question
As far as I remember hibernate fail with nvidia/¿ati? drivers because the video card state wasn't saved, could that be the change? On 7/15/08, Hans-J. Ullrich <[EMAIL PROTECTED]> wrote: > Hi all, > > I am using swsusp with hibernate. In the past I had the problem, when > hibernate started, only hibernate-ram was working. Using hibernate-disk ( > same as /usr/bin/hibernate), the contents of the memory was not written to > disk. So it failed. > > Now I am wanderin, although I never changed the configuration and never > changed the version of hibernate, suddenly it is working. > > So, glad everything is fine now, the situuation is not really satisfying, as I > want to know, why it is working now. Maybe someone is knowing more. Was there > something known in the past about it ? (there was a bugreport by me) > Or have there been some changes to the kernel relating to this ? > > I would be pleased about every information, to learn what happened ! > > Kind regards > > Hans > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > -- Perhaps the depth of love can be calibrated by the number of different selves that are actively involved in a given relationship. Carl Sagan (Contact) Jaime Ochoa Malagón Arquitecto de Soluciones Cel: +52 (55) 1021 0774 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
hibernate, just a question
Hi all, I am using swsusp with hibernate. In the past I had the problem, when hibernate started, only hibernate-ram was working. Using hibernate-disk ( same as /usr/bin/hibernate), the contents of the memory was not written to disk. So it failed. Now I am wanderin, although I never changed the configuration and never changed the version of hibernate, suddenly it is working. So, glad everything is fine now, the situuation is not really satisfying, as I want to know, why it is working now. Maybe someone is knowing more. Was there something known in the past about it ? (there was a bugreport by me) Or have there been some changes to the kernel relating to this ? I would be pleased about every information, to learn what happened ! Kind regards Hans -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: EM64T compiling options?
There is an environment variable GOMP_AFFINITY in libgomp that binds threads to single cpus. Can I use it the same way with multi-cores (i.e GOMP_CPU_AFFINITY="0 1 2 3" in order to bind thread 1 to core 0 etc..)? Is this a good way to take advantage of the quad architecture? Emmanuel On Tue, 15 Jul 2008 16:24:49 +0200, "Thomas Preud'homme" <[EMAIL PROTECTED]> said: > The Tuesday 15 July 2008 15:46:06 E. Rens, you wrote : > > The loop sharing looks exciting but openmp seems difficult to use too. > > Does openmp replace pthreads or work in combination ? > > AFAIK it use pthread to work but it create all necessary pthread at > startup to > avoid creating them at each loop parallelization. It should work properly > with pthreads, it wouldn't be packaged with gcc if it wasn't the case. > However I didn't test this combination. > > openmp is really simple to use, easier than programming the same thing > with > pthreads. You can see examples on wikipedia : > > http://en.wikipedia.org/wiki/OpenMP > > The purpose is to do simple parallelization. If you want to write an > algorithm > which needs modification to support multi-cores, you have to do it > yourself > with pthreads. > > Regards > > > > > Emmanuel > > > -- > Thomas Preud'homme > > Why debian : http://www.debian.org/intro/why_debian > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Opera 9.51
On Tue, 15 Jul 2008 16:00:09 +0200, Christopher Judd wrote: > Does anyone have an idea as to what's going on here? I'd suggest you move your profile away and start from scratch. I've been using 9.5x on AMD64 from the first experimental builds and it works just fine. Alternatively, make sure it's not a plugin problem. -- Best Regards, Jack Linux user #264449 Powered by Debian Sid AMD64 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: EM64T compiling options?
The Tuesday 15 July 2008 15:46:06 E. Rens, you wrote : > The loop sharing looks exciting but openmp seems difficult to use too. > Does openmp replace pthreads or work in combination ? AFAIK it use pthread to work but it create all necessary pthread at startup to avoid creating them at each loop parallelization. It should work properly with pthreads, it wouldn't be packaged with gcc if it wasn't the case. However I didn't test this combination. openmp is really simple to use, easier than programming the same thing with pthreads. You can see examples on wikipedia : http://en.wikipedia.org/wiki/OpenMP The purpose is to do simple parallelization. If you want to write an algorithm which needs modification to support multi-cores, you have to do it yourself with pthreads. Regards > > Emmanuel -- Thomas Preud'homme Why debian : http://www.debian.org/intro/why_debian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: EM64T compiling options?
The loop sharing looks exciting but openmp seems difficult to use too. Does openmp replace pthreads or work in combination ? Emmanuel On Tue, 15 Jul 2008 14:55:24 +0200, "Thomas Preud'homme" <[EMAIL PROTECTED]> said: > The Tuesday 15 July 2008 14:39:41 Lennart Sorensen, You wrote : > > You almost certainly wouldn't. Very few people have any reason to write > > in assembly anymore. You might write a critical section of code in > > assembly, but all the glue ought to be in C, inluding anything to manage > > pthreads to do multiple threads, which is how you take advantage of > > multiple cores. > > You also can take a look at openmp which allow you to parallelize for > loops > and make easy synchronization. The support of openmp is included in > latests > gcc versions. > > > > > -- > > Len Sorensen > > > > -- > Thomas Preud'homme > > Why debian : http://www.debian.org/intro/why_debian > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Opera 9.51
Hi, everyone, I have Opera 9.51 (amd64 version) installed here, but it is unusable. It starts without error, and I can usually browse a page or two, but then it stalls, or at least becomes hideously slow. If I run top and then start Opera, it's CPU usage climbs to near 100% and the memory percentage seems to increase slowly as long as it is open. This doesn't happen with the 32-bit version that I have installed at home. Does anyone have an idea as to what's going on here? -Chris | Christopher Judd, Ph. D. [EMAIL PROTECTED] | IMPORTANT NOTICE: This e-mail and any attachments may contain confidential or sensitive information which is, or may be, legally privileged or otherwise protected by law from further disclosure. It is intended only for the addressee. If you received this in error or from someone who was not authorized to send it to you, please do not distribute, copy or use it or any attachments. Please notify the sender immediately by reply e-mail and delete this from your system. Thank you for your cooperation. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: nvidia and latest unstable kernel image
On Tue, 15 Jul 2008 08:37:15 -0400, [EMAIL PROTECTED] (Lennart Sorensen) wrote: [...] > It compiles and works fine on my machine with those headers. > All you should have to do is: > apt-get update > apt-get install nvidia-kernel-source modules-assistant > rm -rf /usr/src/modules/nvidia-kernel > m-a prepare -t > m-a a-i -t nvidia-kernel > apt-get install nvidia-glx Thanks a lot Lennart, I've been doing a similar procedure (after updating apt and removing the old nvidia stuff as you suggest): m-a -t -f clean,build,install nvidia apt-get install nvidia-glx and the module builds, albeit with an error I described earlier about a *stack-protector file or directory not being found. But it installs fine. /etc/X11/xorg.conf is also set to use nvidia, as it has since several kernels back in my sid system. However, when booting into the new kernel, all I get is a 1 pixel band displayed along the top of the screen. Downgrading to 169.12-1 (which means going back to the old 2.6.24-1 Linux kernel), as Jaime suggested, is the only way to get a working nvidia in this system. I use a GeForce 6100 card. The only report I could find with this 1 pixel issue is: http://www.nvnews.net/vbulletin/showthread.php?t=115209 I don't understand where the problem is, but I'll try with your exact recipe and see what happens! Thanks, -- Seb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: EM64T compiling options?
The Tuesday 15 July 2008 14:39:41 Lennart Sorensen, You wrote : > You almost certainly wouldn't. Very few people have any reason to write > in assembly anymore. You might write a critical section of code in > assembly, but all the glue ought to be in C, inluding anything to manage > pthreads to do multiple threads, which is how you take advantage of > multiple cores. You also can take a look at openmp which allow you to parallelize for loops and make easy synchronization. The support of openmp is included in latests gcc versions. > > -- > Len Sorensen -- Thomas Preud'homme Why debian : http://www.debian.org/intro/why_debian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: EM64T compiling options?
On Tue, Jul 15, 2008 at 11:37:52AM +0200, [EMAIL PROTECTED] wrote: > I'm migrating from an i686 to an EM64T machine (Intel core 2 quad) and > I'd like to know whether there are specific options that I can pass to > gcc for an optimization of my code or if everything is blindly set up. > How would I manage the 4 cpu cores if I was to write in assembly? You almost certainly wouldn't. Very few people have any reason to write in assembly anymore. You might write a critical section of code in assembly, but all the glue ought to be in C, inluding anything to manage pthreads to do multiple threads, which is how you take advantage of multiple cores. As for optimizing, there really aren't any options yet since there are very few amd64 designs so far and they all have the same instruction set and features pretty much and hence the code should be pretty much optimal for all of them (in as much as gcc produces optimal code for anything). -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: nvidia and latest unstable kernel image
On Mon, Jul 14, 2008 at 11:02:22PM -0500, Seb wrote: > I still cannot use the new 2.6.25 kernel due to this problem with nvidia > module, even with the recently available linux-headers-2.6.25-2-amd64 > and image packages. I'm starting to think that these don't work with my > card anymore. If anybody has any further tips, I'd be grateful for > them. Thanks. It compiles and works fine on my machine with those headers. All you should have to do is: apt-get update apt-get install nvidia-kernel-source modules-assistant rm -rf /usr/src/modules/nvidia-kernel m-a prepare -t m-a a-i -t nvidia-kernel apt-get install nvidia-glx Then go convince Xorg to actually use the nvidia driver by putting 'driver "nvidia"' in the appropriate section. Failing to delete any previous version of the module source can cause compile failures. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: EM64T compiling options?
Many thanks, I'll read your link with attention. Do you have further links on threads and IPC ? I'm thinking in rewriting an old and unfinished logical interpreter in C that used assembly code (nasm) for truth evaluation of the smallest elements. I'd like also to create a "small" database for prime numbers (using John Moyer's storage code) in order to test several things on prime numbers distribution. A+ Emmanuel On Tue, 15 Jul 2008 12:56:18 +0200, "Cyril Jaquier" <[EMAIL PROTECTED]> said: > Hi, > > > I'm migrating from an i686 to an EM64T machine (Intel core 2 quad) and > > I'd like to know whether there are specific options that I can pass to > > gcc for an optimization of my code or if everything is blindly set up. > > How would I manage the 4 cpu cores if I was to write in assembly? > > > > GCC has a lot of optimization/architecture flags. Just have a look here > [1]. However, this won't make your software use the 4 cores. > > You should use threads or multiple processes with IPC. I don't know what > you want to do but I think you should forget about writing in assembly > and use an higher level language. You probably don't need assembly at > all. Moreover, higher level language have sometimes concurrency and > synchronization facilities which will help you getting the most of your > 4 cores. > > Regards, > > Cyril Jaquier > > [1] http://gcc.gnu.org/onlinedocs/gcc/i386-and-x86_002d64-Options.html > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: EM64T compiling options?
Hi, I'm migrating from an i686 to an EM64T machine (Intel core 2 quad) and I'd like to know whether there are specific options that I can pass to gcc for an optimization of my code or if everything is blindly set up. How would I manage the 4 cpu cores if I was to write in assembly? GCC has a lot of optimization/architecture flags. Just have a look here [1]. However, this won't make your software use the 4 cores. You should use threads or multiple processes with IPC. I don't know what you want to do but I think you should forget about writing in assembly and use an higher level language. You probably don't need assembly at all. Moreover, higher level language have sometimes concurrency and synchronization facilities which will help you getting the most of your 4 cores. Regards, Cyril Jaquier [1] http://gcc.gnu.org/onlinedocs/gcc/i386-and-x86_002d64-Options.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
EM64T compiling options?
Hi, I'm migrating from an i686 to an EM64T machine (Intel core 2 quad) and I'd like to know whether there are specific options that I can pass to gcc for an optimization of my code or if everything is blindly set up. How would I manage the 4 cpu cores if I was to write in assembly? Thank you in advance for any link or information on this subject. Emmanuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: nvidia and latest unstable kernel image
I am on debian lenny amd64 shipped with an nvidia GeForce 6150, with 2.6.24 release I had no problem running nv driver, now I am 2.6.25 using nvidia proprietary driver with no problem at all. Dual head works fine too. I just followed this brief but operative how-to http://tinyplanet.ca/~lsorense/debian/debian-nvidia-dri-howto.html hope this helps 2008/7/15 Seb <[EMAIL PROTECTED]>: > Hi, > > I still cannot use the new 2.6.25 kernel due to this problem with nvidia > module, even with the recently available linux-headers-2.6.25-2-amd64 > and image packages. I'm starting to think that these don't work with my > card anymore. If anybody has any further tips, I'd be grateful for > them. Thanks. > > > Cheers, > > -- > Seb > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] > >
