Re: forcedeth generates Invalid MAC address message
On Sunday 11 November 2007, Douglas A. Tutty wrote: On Sun, Nov 11, 2007 at 04:29:54PM -0800, Keith Schweikhard wrote: No luck on the MAC addresses being printed on the bottom. I've tried to locate the chip on the IEEE website without luck. It looks like the MAC address that is getting posted on both machines is in a reverse byte order. When I call up the MAC address on the Windows side of the computer the byte order is reversed. As a result, the first three bytes of my MAC address are 00-1B-38. According to IEEE these MAC addresses are assigned to COMPAL ELECTRONICS TECHNOLOGIC CO., LTD. Judging from what I am reading, Nvidia chips had issues with reporting their MAC addresses. As a result, forcedeth swaps the bytes. The board in the computer claims to be Nvidia, but the chip is registered to Compal. In looking up the chipset in hardware for linux http://hardware4linux.info/component/15830/ I get pointed to a different driver for the NIC. (r8169) But the kernel does not seem realize this during the boot process. As a result, it calls forcedeth and forcedeth swaps the byte order. I am baffled on how to override this selection. I've already tried blacklisting forcedeth in /etc/modprobe.d/blacklist and adding r8169 into /etc/modules but it seems to load the forcedeth module regardless of the fact that it is blacklisted. I have also tried moving forcedeth.ko from the kernel/drivers/net/ directory but without luck. forcedeth gets loaded as a module anyway. This problem happens as soon as forcedeth tries to initialize the NIC. I'm not certain what to try next. Any suggestions? Either the forcedeth module is built into the kernel or is being loaded by udev. If its loaded by udev, if you turn off networking, you should be able to rmmod the forcedeth module, then insmod the r8169 and see if it works. That would be the first step. Then, I guess you'd need to reconfigure the initrd to load the r8169 module instead of the forcedeth (i.e. remove the forcedeth module from the initrd altogether). Doug. Thanks for the information. I finally got forcedeth to quit coming up by removing it from initrd. Unfortunately, the r8169 module will not communicate with the nic. I'm going to need to keep working at that one. The good news is that the wireless card now works so I can at least configure the system to run using a consistent IP. I'm going to have to keep hacking at the NIC to see if there is a driver out there that fixes the problem as time permits. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to shift backwards on nvidia's driver?
On Sunday 11 November 2007, Kenward Vaughan wrote: Hello, According to your email you are running the 100.14.11 nvidia drivers. In looking at sid the latest drivers are 100.14.19. I am currently running these drivers on my nvidia cards and am having no problems with instability. You may want to try the newer drivers before trying to revert. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to shift backwards on nvidia's driver?
Am Montag 12 November 2007 schrieb Kenward Vaughan: Hi, I'm in the predicament of needing to have OpenGL working on my box, which already has the latest X updates (this is in Sid). The instability issues exists with the driver I have, so I need to back down to one which doesn't show the problem. I'm running with the nv server at the moment. I have the 100.14.11 driver installed. Is nvidia-glx the server itself, or which server component is used with that? I am uncertain exactly how to do this. It seems that I would have to downgrade a lot of files. Or does the Nvidia legacy driver from their site work with the current xserver components? Would it be better/easier to create a fresh base to work from? Thanks, Kenward -- The church says the earth is flat, but I know that it is round, for I have seen the shadow on the moon, and I have more faith in a shadow than in the church.--Ferdinand Magellan Hi Kenward, I am having much problems with nvidias driver higher than 100.14.09. My system freezes unexpectly. This is caused by the binary part of the nvidia driver and effects mostly 64-bit systems. Not every graphic card is effected, but mine is. Others reported of the freeze, too, (there are some reports of it on Nvidias linux site). Although other people might report, the driver is stable, I say: It is NOT. The same driver is running on my 32-bit system stable, but i repeat: Other people report about the same problems. My card is a Nvidia 7300 Go. I suggest, to get back to 100.14.09 (you can get all packages at snapshots.debian.net) and revert to this driver, which is reported by everyone to be very stable. Just take a look at my reports in this forum, too. The bug is in the binary part of Nvidias driver, not in the Debian part. Good luck Hans P.S. the latest drver 100.14.23 (only downloadable at Nvidia) seem to be more stable again, but I sometimes saw some weired effects (i.e. the screen went down dark for a second) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intel Core2Duo (T7400)
On Thu, Nov 08, 2007 at 09:31:31AM -0500, Lennart Sorensen wrote: I don't consider it a real issue either, but it is still something. I am not sure why sparc tends to run 32bit for most programs and only 64bit for select cases where it helps. Certainly x86_64 seems to be better than i386 in just about all cases. Taking the same code, going from 32-bit to 64-bit will cause a slowdown, period. The only way to overcome that is if you can write better code in 64-bit mode than you could in 32-bit mode. There are apps that indeed benefit from directly accessing more than 2G of address space and therefore can use simpler algorithms in 64-bit mode, but they are rare (at least on desktop). AMD knew all this and they also knew they have to counter-balance the slowdown if they ever wanted 64-bit to became the norm, so they did a smart trick and doubled the register set size in 64-bit mode. Since i386 is a very register-starved architecture, that move indeed helped a lot by making it much easier for compilers to generate better code. So it's not only in 64-bit mode you can keep more variables in registers but also it is easier to write good compilers for 64-bit mode. AFAIK Sparc (and basycally any other 64-bit capable processor) offers the same number of registers in both 32-bit and 64-bit mode, so there is nothing that could balance the slowdown caused by going 64-bit. And even if they wanted to use the same trick as AMD it would not help as Sparc already has enough registers - adding more would give a much much smaller performance gain than it did for x86_64. I hope they come out with a way faster improved CPU before then. Hehe, they could introduce a new 32-bit mode that has the same number of registers as the 64-bit mode has. OTOH marketing people would have a really tough time to push down such a change on consumers' throats... Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: forcedeth generates Invalid MAC address message
On Sun, Nov 11, 2007 at 04:29:54PM -0800, Keith Schweikhard wrote: No luck on the MAC addresses being printed on the bottom. I've tried to locate the chip on the IEEE website without luck. It looks like the MAC address that is getting posted on both machines is in a reverse byte order. When I call up the MAC address on the Windows side of the computer the byte order is reversed. As a result, the first three bytes of my MAC address are 00-1B-38. According to IEEE these MAC addresses are assigned to COMPAL ELECTRONICS TECHNOLOGIC CO., LTD. Judging from what I am reading, Nvidia chips had issues with reporting their MAC addresses. As a result, forcedeth swaps the bytes. The board in the computer claims to be Nvidia, but the chip is registered to Compal. In looking up the chipset in hardware for linux http://hardware4linux.info/component/15830/ I get pointed to a different driver for the NIC. (r8169) But the kernel does not seem realize this during the boot process. As a result, it calls forcedeth and forcedeth swaps the byte order. I am baffled on how to override this selection. I've already tried blacklisting forcedeth in /etc/modprobe.d/blacklist and adding r8169 into /etc/modules but it seems to load the forcedeth module regardless of the fact that it is blacklisted. I have also tried moving forcedeth.ko from the kernel/drivers/net/ directory but without luck. forcedeth gets loaded as a module anyway. This problem happens as soon as forcedeth tries to initialize the NIC. I'm not certain what to try next. Any suggestions? The nvidia MAC has for many years now for some stupid reason had it's MAC address stored in reverse order on almost all boards that use it (not sure if the documentation was confusing or what). As a result the driver has had to reverse it before using it. A few months ago some board makers decided to fix the problem and start storing the MAC in the correct order which of course now breaks all existing drivers that know the MAC address is in reverse order. The kernel developers are aware of this and are trying to come up with a way for the driver to detect which way the address is stored and do the right thing based on it. Any solution is going to appear at earliest in 2.6.24 as far as I can tell. You can do a search of lkml (linux kernel mailing list) to get more details on it. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intel Core2Duo (T7400)
On Mon, Nov 12, 2007 at 02:46:00PM +0100, Gabor Gombas wrote: Taking the same code, going from 32-bit to 64-bit will cause a slowdown, period. The only way to overcome that is if you can write better code in 64-bit mode than you could in 32-bit mode. There are apps that indeed benefit from directly accessing more than 2G of address space and therefore can use simpler algorithms in 64-bit mode, but they are rare (at least on desktop). AMD knew all this and they also knew they have to counter-balance the slowdown if they ever wanted 64-bit to became the norm, so they did a smart trick and doubled the register set size in 64-bit mode. Since i386 is a very register-starved architecture, that move indeed helped a lot by making it much easier for compilers to generate better code. So it's not only in 64-bit mode you can keep more variables in registers but also it is easier to write good compilers for 64-bit mode. They also deprecated MMX and x87 (hence reducing the old crap to carry around on centext switches), and switched to sse match (which is much faster and not stack based), and add some new instructions that can help code in general. That almost certainly is much more important than the register count. As far back as the Pentium Pro the pipeline's out of order execution had a large register rename file which allowed it to do speculative execution. It also allowed skipping stack accesses to memory by simply renaming the old register into an unused spot in the register file boing by the assumption that stuff put on the stack is often needed again soon, so rather than putting it in memory, just keep it in an unused virtual register. As a result the Pentium Pro and most newer x86 processors actually already perform as if they had more registers than the architecture does in most cases. I am not saying adding registers wasn't a good idea, but I think people are highly over estimating their significance. I guess a simple way to test is to convince the compiler that the 64bit mode has the same number of registers as 32bit mode and then compiling software that way and comparing the result in 32 and 64bit mode when both have the same register count. Shouldn't be too hard to do for someone that understands gcc's code (which is not me). AFAIK Sparc (and basycally any other 64-bit capable processor) offers the same number of registers in both 32-bit and 64-bit mode, so there is nothing that could balance the slowdown caused by going 64-bit. And even if they wanted to use the same trick as AMD it would not help as Sparc already has enough registers - adding more would give a much much smaller performance gain than it did for x86_64. I don't think the sparc added any really useful new instructions in 64bit mode. I believe it mainly just added 64bit versions of the instructions where needed. Hehe, they could introduce a new 32-bit mode that has the same number of registers as the 64-bit mode has. OTOH marketing people would have a really tough time to push down such a change on consumers' throats... Given the amount of ram in your average desktop is getting close to requiring a 64bit OS, there is really no point designing anything new with 32bit operation in mind. People have to switch to 64bit OSs if they want to be able to use more ram within the next year or so. But then again who knows. Perhaps 2GB of ram really is all anyone will ever need. :) -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to shift backwards on nvidia's driver?
On Mon, Nov 12, 2007 at 09:29:54AM +0100, Hans-J. Ullrich wrote: I am having much problems with nvidias driver higher than 100.14.09. My system freezes unexpectly. This is caused by the binary part of the nvidia driver and effects mostly 64-bit systems. Not every graphic card is effected, but mine is. Others reported of the freeze, too, (there are some reports of it on Nvidias linux site). Although other people might report, the driver is stable, I say: It is NOT. The same driver is running on my 32-bit system stable, but i repeat: Other people report about the same problems. My card is a Nvidia 7300 Go. I suggest, to get back to 100.14.09 (you can get all packages at snapshots.debian.net) and revert to this driver, which is reported by everyone to be very stable. Just take a look at my reports in this forum, too. The bug is in the binary part of Nvidias driver, not in the Debian part. Well reverting requires reverting xorg too, so perhaps the problem is nvidia screwed up something to do with the new xorg protocol. Good luck Hans P.S. the latest drver 100.14.23 (only downloadable at Nvidia) seem to be more stable again, but I sometimes saw some weired effects (i.e. the screen went down dark for a second) Well hopefully it will be packaged soon. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
openoffice locks graphic video ???
I have now experienced this three (3) times; so, it is chronic : However, it is intermittent. Sometimes, when opening and/or manipulating an XLS created on winders; the desktop freezes. The mouse pointer moves; but, no alt-tab; no menuse; no ctrl-fkeys; nothing. When I ssh into this box, the CLI works fine. I restart gdm; and I kill gdm; but, the frozen desktop video remains on the screen. So far, when this happens, the only solution is a full system reboot. What do you think? -- Best Regards, helices - Dare to fix things before they break . . . - Our capacity for understanding is inversely proportional to how much we think we know. The more I know, the more I know I don't know . . . -- signature.asc Description: Digital signature
Re: openoffice locks graphic video ???
helices: Sometimes, when opening and/or manipulating an XLS created on winders; the desktop freezes. The mouse pointer moves; but, no alt-tab; no menuse; no ctrl-fkeys; nothing. Did you check /var/log/syslog and (IIRC) /var/log/xorg.0.log? Another thing that comes to my mind: OOo has an option whether to use OpenGL for some documents. I have never seen a document use OpenGL, but turning this option off may help you. J. -- I am on the payroll of a company to whom I owe my undying gratitude. [Agree] [Disagree] http://www.slowlydownward.com/NODATA/data_enter2.html signature.asc Description: Digital signature
Re: openoffice locks graphic video ???
Am Montag 12 November 2007 schrieb helices: I have now experienced this three (3) times; so, it is chronic : However, it is intermittent. Sometimes, when opening and/or manipulating an XLS created on winders; the desktop freezes. The mouse pointer moves; but, no alt-tab; no menuse; no ctrl-fkeys; nothing. When I ssh into this box, the CLI works fine. I restart gdm; and I kill gdm; but, the frozen desktop video remains on the screen. So far, when this happens, the only solution is a full system reboot. What do you think? Do you use nvidia drivers higher than 100.14.09 ? And did you activate 3D in OpenOfficeOrg settings ? Regards Hans -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intel Core2Duo (T7400)
On Mon, Nov 12, 2007 at 09:46:57AM -0500, Lennart Sorensen wrote: Given the amount of ram in your average desktop is getting close to requiring a 64bit OS, there is really no point designing anything new with 32bit operation in mind. People have to switch to 64bit OSs if they want to be able to use more ram within the next year or so. I have and use 6GB in a 32 bit machine, and have for years. Sure, no one process can use 3GB, (3/1 user/kernel split) but the machine handles two 3G processes just fine. I believe the limit for machines like this is 64G. -- Rob signature.asc Description: Digital signature
Re: How to shift backwards on nvidia's driver?
On Mon, 2007-11-12 at 09:29 +0100, Hans-J. Ullrich wrote: Am Montag 12 November 2007 schrieb Kenward Vaughan: Hi, I'm in the predicament of needing to have OpenGL working on my box, which already has the latest X updates (this is in Sid). The instability issues exists with the driver I have, so I need to back down to one which doesn't show the problem. I'm running with the nv server at the moment. I have the 100.14.11 driver installed. Is nvidia-glx the server itself, or which server component is used with that? I am uncertain exactly how to do this. It seems that I would have to downgrade a lot of files. Or does the Nvidia legacy driver from their site work with the current xserver components? Would it be better/easier to create a fresh base to work from? Thanks, Kenward -- The church says the earth is flat, but I know that it is round, for I have seen the shadow on the moon, and I have more faith in a shadow than in the church.--Ferdinand Magellan Hi Kenward, I am having much problems with nvidias driver higher than 100.14.09. My system freezes unexpectly. This is caused by the binary part of the nvidia driver and effects mostly 64-bit systems. Not every graphic card is effected, but mine is. Others reported of the freeze, too, (there are some reports of it on Nvidias linux site). Although other people might report, the driver is stable, I say: It is NOT. The same driver is running on my 32-bit system stable, but i repeat: Other people report about the same problems. My card is a Nvidia 7300 Go. I suggest, to get back to 100.14.09 (you can get all packages at snapshots.debian.net) and revert to this driver, which is reported by everyone to be very stable. This is the point I am unsure of--what packages do I install? Would they be only the nvidia-kernel/glx pkgs. or a wider assortment of things? As Len pointed out (and what I'm concerned with, considering potential downtime), will all of Xorg wind up being involved? (This comes from having another kernel on board with the 9755 driver, which fails to work with X.) Does the back-peddling involve some forced installs using dpkg? Just take a look at my reports in this forum, too. I'll search for them. The bug is in the binary part of Nvidias driver, not in the Debian part. Understood. Good luck Thanks! Hans P.S. the latest drver 100.14.23 (only downloadable at Nvidia) seem to be more stable again, but I sometimes saw some weired effects (i.e. the screen went down dark for a second) I may try it for fun. :) -- The church says the earth is flat, but I know that it is round, for I have seen the shadow on the moon, and I have more faith in a shadow than in the church.--Ferdinand Magellan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: openoffice locks graphic video ???
* Jochen Schulz [EMAIL PROTECTED] [2007:11:12:17:17:30+0100] scribed: helices: Sometimes, when opening and/or manipulating an XLS created on winders; the desktop freezes. The mouse pointer moves; but, no alt-tab; no menuse; no ctrl-fkeys; nothing. Did you check /var/log/syslog Around that last time, there is this: kernel: npviewer.bin[4954]: segfault at f609e8d8 rip f609e8d8 rsp ffaa6bdc error 15 and (IIRC) /var/log/xorg.0.log? Also, at the end of Xorg.0.log.old, there are ~300 pairs of this: SetGrabKeysState - disabled SetGrabKeysState - enabled Another thing that comes to my mind: OOo has an option whether to use OpenGL for some documents. I have never seen a document use OpenGL, but turning this option off may help you. J. -- I am on the payroll of a company to whom I owe my undying gratitude. [Agree] [Disagree] http://www.slowlydownward.com/NODATA/data_enter2.html -- Best Regards, helices - Dare to fix things before they break . . . - Our capacity for understanding is inversely proportional to how much we think we know. The more I know, the more I know I don't know . . . -- signature.asc Description: Digital signature
Re: openoffice locks graphic video ???
* Hans-J. Ullrich [EMAIL PROTECTED] [2007:11:12:17:31:27+0100] scribed: Am Montag 12 November 2007 schrieb helices: I have now experienced this three (3) times; so, it is chronic : However, it is intermittent. Sometimes, when opening and/or manipulating an XLS created on winders; the desktop freezes. The mouse pointer moves; but, no alt-tab; no menuse; no ctrl-fkeys; nothing. When I ssh into this box, the CLI works fine. I restart gdm; and I kill gdm; but, the frozen desktop video remains on the screen. So far, when this happens, the only solution is a full system reboot. What do you think? Do you use nvidia drivers higher than 100.14.09 ? And did you activate 3D in OpenOfficeOrg settings ? Yes, it is nvidia. I do not have graphical access right now. How can I check this via CLI? -- Best Regards, helices - Dare to fix things before they break . . . - Our capacity for understanding is inversely proportional to how much we think we know. The more I know, the more I know I don't know . . . -- signature.asc Description: Digital signature
Re: openoffice locks graphic video ???
Am Montag 12 November 2007 schrieb helices: * Hans-J. Ullrich [EMAIL PROTECTED] [2007:11:12:17:31:27+0100] scribed: Am Montag 12 November 2007 schrieb helices: I have now experienced this three (3) times; so, it is chronic : However, it is intermittent. Sometimes, when opening and/or manipulating an XLS created on winders; the desktop freezes. The mouse pointer moves; but, no alt-tab; no menuse; no ctrl-fkeys; nothing. When I ssh into this box, the CLI works fine. I restart gdm; and I kill gdm; but, the frozen desktop video remains on the screen. So far, when this happens, the only solution is a full system reboot. What do you think? Do you use nvidia drivers higher than 100.14.09 ? And did you activate 3D in OpenOfficeOrg settings ? Yes, it is nvidia. I do not have graphical access right now. How can I check this via CLI? Do not know. Check out, which driver it is. If it is version higher than 100.14.09, than downgrade to 100.14.09 (and xorg to 7.2). If the error is still sthere (what suppose will not be), you got the reason. If it is still there, you can easily upgrade and the error is in OOO itself. The setting of 3D is in OOO-Settings. I cannot tell, as I use the German version. Look in OOO belowExtras Settings OpenOffice.org View (this is Ansicht here) Good luck Hans -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: openoffice locks graphic video ???
helices: * Jochen Schulz [EMAIL PROTECTED] [2007:11:12:17:17:30+0100] scribed: helices: Sometimes, when opening and/or manipulating an XLS created on winders; the desktop freezes. The mouse pointer moves; but, no alt-tab; no menuse; no ctrl-fkeys; nothing. Did you check /var/log/syslog Around that last time, there is this: kernel: npviewer.bin[4954]: segfault at f609e8d8 rip f609e8d8 rsp ffaa6bdc error 15 This appears to be related to nspluginwrapper and /may/ be the cause of your X lockup. and (IIRC) /var/log/xorg.0.log? Also, at the end of Xorg.0.log.old, there are ~300 pairs of this: SetGrabKeysState - disabled SetGrabKeysState - enabled Googling suggests these are a sign of a buggy video driver, but I don't really know. J. -- I have been manipulated and permanently distorted. [Agree] [Disagree] http://www.slowlydownward.com/NODATA/data_enter2.html signature.asc Description: Digital signature
Re: How to shift backwards on nvidia's driver?
Am Montag 12 November 2007 schrieb Kenward Vaughan: On Mon, 2007-11-12 at 09:29 +0100, Hans-J. Ullrich wrote: Am Montag 12 November 2007 schrieb Kenward Vaughan: Hi, I'm in the predicament of needing to have OpenGL working on my box, which already has the latest X updates (this is in Sid). The instability issues exists with the driver I have, so I need to back down to one which doesn't show the problem. I'm running with the nv server at the moment. I have the 100.14.11 driver installed. Is nvidia-glx the server itself, or which server component is used with that? I am uncertain exactly how to do this. It seems that I would have to downgrade a lot of files. Or does the Nvidia legacy driver from their site work with the current xserver components? Would it be better/easier to create a fresh base to work from? Thanks, Kenward -- The church says the earth is flat, but I know that it is round, for I have seen the shadow on the moon, and I have more faith in a shadow than in the church.--Ferdinand Magellan Hi Kenward, I am having much problems with nvidias driver higher than 100.14.09. My system freezes unexpectly. This is caused by the binary part of the nvidia driver and effects mostly 64-bit systems. Not every graphic card is effected, but mine is. Others reported of the freeze, too, (there are some reports of it on Nvidias linux site). Although other people might report, the driver is stable, I say: It is NOT. The same driver is running on my 32-bit system stable, but i repeat: Other people report about the same problems. My card is a Nvidia 7300 Go. I suggest, to get back to 100.14.09 (you can get all packages at snapshots.debian.net) and revert to this driver, which is reported by everyone to be very stable. This is the point I am unsure of--what packages do I install? Would they be only the nvidia-kernel/glx pkgs. or a wider assortment of things? As Len pointed out (and what I'm concerned with, considering potential downtime), will all of Xorg wind up being involved? (This comes from having another kernel on board with the 9755 driver, which fails to work with X.) Does the back-peddling involve some forced installs using dpkg? Just take a look at my reports in this forum, too. I'll search for them. The bug is in the binary part of Nvidias driver, not in the Debian part. Understood. Good luck Thanks! Hans P.S. the latest drver 100.14.23 (only downloadable at Nvidia) seem to be more stable again, but I sometimes saw some weired effects (i.e. the screen went down dark for a second) I may try it for fun. :) -- The church says the earth is flat, but I know that it is round, for I have seen the shadow on the moon, and I have more faith in a shadow than in the church.--Ferdinand Magellan Just put this in /etc/apt/sources.list # sources of packages which are no more in the repository deb http://snapshot.debian.net/archive pool nvidia-graphics-drivers deb-src http://snapshot.debian.net/archive pool nvidia-graphics-drivers Then do apt-get update. Now you can install the correct version. It is a little tricky, when you use aptitude, as aptitude tries to correct things automatically. You have to choose manually all dependecies. If you forget one, aptitude will correct it, and you have to start again. If everything works, let aptitude hold the nvidia-packages. So they will never be overwritten, even when upgrading. If you want to upgrade them later, you can relaese them manually again. Good luck Hans -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: openoffice locks graphic video ???
* Hans-J. Ullrich [EMAIL PROTECTED] [2007:11:12:18:53:47+0100] scribed: Am Montag 12 November 2007 schrieb helices: * Hans-J. Ullrich [EMAIL PROTECTED] [2007:11:12:17:31:27+0100] scribed: Am Montag 12 November 2007 schrieb helices: I have now experienced this three (3) times; so, it is chronic : However, it is intermittent. Sometimes, when opening and/or manipulating an XLS created on winders; the desktop freezes. The mouse pointer moves; but, no alt-tab; no menuse; no ctrl-fkeys; nothing. When I ssh into this box, the CLI works fine. I restart gdm; and I kill gdm; but, the frozen desktop video remains on the screen. So far, when this happens, the only solution is a full system reboot. What do you think? Do you use nvidia drivers higher than 100.14.09 ? And did you activate 3D in OpenOfficeOrg settings ? Yes, it is nvidia. I do not have graphical access right now. How can I check this via CLI? Do not know. Check out, which driver it is. If it is version higher than 100.14.09, than downgrade to 100.14.09 (and xorg to 7.2). snip / OK. I do NOT know which driver I am using. Here is what xorg.conf says about the video card: nVidia Corporation NV41 [Quadro FX 3450/4000 SDI] I did NOT install any special drivers. Somehow, video just worked when I installed etch. How do I find out the answers to what you are asking? -- Best Regards, helices - Dare to fix things before they break . . . - Our capacity for understanding is inversely proportional to how much we think we know. The more I know, the more I know I don't know . . . -- signature.asc Description: Digital signature
Re: Intel Core2Duo (T7400)
On Mon, Nov 12, 2007 at 09:40:40AM -0700, Rob Sims wrote: I have and use 6GB in a 32 bit machine, and have for years. Sure, no one process can use 3GB, (3/1 user/kernel split) but the machine handles two 3G processes just fine. I believe the limit for machines like this is 64G. Sure, but 32bit vista and Xp don't do PAE (and it is a slight performance hit to use PAE anyhow). -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: openoffice locks graphic video ???
Am Montag 12 November 2007 schrieb helices: * Hans-J. Ullrich [EMAIL PROTECTED] [2007:11:12:18:53:47+0100] scribed: Am Montag 12 November 2007 schrieb helices: * Hans-J. Ullrich [EMAIL PROTECTED] [2007:11:12:17:31:27+0100] scribed: Am Montag 12 November 2007 schrieb helices: I have now experienced this three (3) times; so, it is chronic : However, it is intermittent. Sometimes, when opening and/or manipulating an XLS created on winders; the desktop freezes. The mouse pointer moves; but, no alt-tab; no menuse; no ctrl-fkeys; nothing. When I ssh into this box, the CLI works fine. I restart gdm; and I kill gdm; but, the frozen desktop video remains on the screen. So far, when this happens, the only solution is a full system reboot. What do you think? Do you use nvidia drivers higher than 100.14.09 ? And did you activate 3D in OpenOfficeOrg settings ? Yes, it is nvidia. I do not have graphical access right now. How can I check this via CLI? Do not know. Check out, which driver it is. If it is version higher than 100.14.09, than downgrade to 100.14.09 (and xorg to 7.2). snip / OK. I do NOT know which driver I am using. Here is what xorg.conf says about the video card: nVidia Corporation NV41 [Quadro FX 3450/4000 SDI] I did NOT install any special drivers. Somehow, video just worked when I installed etch. How do I find out the answers to what you are asking? Hmm, you could see it, if you start aptitude or synaptic. It will show you the installed version of the package. I suggest, to read the documentation about package handling, especially about apt and aptitude. Package handling is important in all linux, and in Debian, too. (that is my personal opinion). Good luck Hans -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: openoffice locks graphic video ???
* Hans-J. Ullrich [EMAIL PROTECTED] [2007:11:12:20:23:52+0100] scribed: Am Montag 12 November 2007 schrieb helices: * Hans-J. Ullrich [EMAIL PROTECTED] [2007:11:12:18:53:47+0100] scribed: Am Montag 12 November 2007 schrieb helices: * Hans-J. Ullrich [EMAIL PROTECTED] [2007:11:12:17:31:27+0100] scribed: Am Montag 12 November 2007 schrieb helices: I have now experienced this three (3) times; so, it is chronic : However, it is intermittent. Sometimes, when opening and/or manipulating an XLS created on winders; the desktop freezes. The mouse pointer moves; but, no alt-tab; no menuse; no ctrl-fkeys; nothing. When I ssh into this box, the CLI works fine. I restart gdm; and I kill gdm; but, the frozen desktop video remains on the screen. So far, when this happens, the only solution is a full system reboot. What do you think? Do you use nvidia drivers higher than 100.14.09 ? And did you activate 3D in OpenOfficeOrg settings ? Yes, it is nvidia. I do not have graphical access right now. How can I check this via CLI? Do not know. Check out, which driver it is. If it is version higher than 100.14.09, than downgrade to 100.14.09 (and xorg to 7.2). snip / OK. I do NOT know which driver I am using. Here is what xorg.conf says about the video card: nVidia Corporation NV41 [Quadro FX 3450/4000 SDI] I did NOT install any special drivers. Somehow, video just worked when I installed etch. How do I find out the answers to what you are asking? Hmm, you could see it, if you start aptitude or synaptic. It will show you the installed version of the package. I suggest, to read the documentation about package handling, especially about apt and aptitude. Package handling is important in all linux, and in Debian, too. (that is my personal opinion). According to Xorg.0.log: (II) LoadModule: nv (II) Loading /usr/lib/xorg/modules/drivers/nv_drv.so (II) Module nv: vendor=X.Org Foundation According to aptitude: xserver-xorg-video-nv1:1.2.0-3 How does this relate to your suggested versions? -- Best Regards, helices - Dare to fix things before they break . . . - Our capacity for understanding is inversely proportional to how much we think we know. The more I know, the more I know I don't know . . . -- signature.asc Description: Digital signature
Re: openoffice locks graphic video ???
Am Montag 12 November 2007 schrieb helices: * Hans-J. Ullrich [EMAIL PROTECTED] [2007:11:12:20:23:52+0100] scribed: Am Montag 12 November 2007 schrieb helices: * Hans-J. Ullrich [EMAIL PROTECTED] [2007:11:12:18:53:47+0100] scribed: Am Montag 12 November 2007 schrieb helices: * Hans-J. Ullrich [EMAIL PROTECTED] [2007:11:12:17:31:27+0100] scribed: Am Montag 12 November 2007 schrieb helices: I have now experienced this three (3) times; so, it is chronic : However, it is intermittent. Sometimes, when opening and/or manipulating an XLS created on winders; the desktop freezes. The mouse pointer moves; but, no alt-tab; no menuse; no ctrl-fkeys; nothing. When I ssh into this box, the CLI works fine. I restart gdm; and I kill gdm; but, the frozen desktop video remains on the screen. So far, when this happens, the only solution is a full system reboot. What do you think? Do you use nvidia drivers higher than 100.14.09 ? And did you activate 3D in OpenOfficeOrg settings ? Yes, it is nvidia. I do not have graphical access right now. How can I check this via CLI? Do not know. Check out, which driver it is. If it is version higher than 100.14.09, than downgrade to 100.14.09 (and xorg to 7.2). snip / OK. I do NOT know which driver I am using. Here is what xorg.conf says about the video card: nVidia Corporation NV41 [Quadro FX 3450/4000 SDI] I did NOT install any special drivers. Somehow, video just worked when I installed etch. How do I find out the answers to what you are asking? Hmm, you could see it, if you start aptitude or synaptic. It will show you the installed version of the package. I suggest, to read the documentation about package handling, especially about apt and aptitude. Package handling is important in all linux, and in Debian, too. (that is my personal opinion). According to Xorg.0.log: (II) LoadModule: nv (II) Loading /usr/lib/xorg/modules/drivers/nv_drv.so (II) Module nv: vendor=X.Org Foundation According to aptitude: xserver-xorg-video-nv1:1.2.0-3 How does this relate to your suggested versions? No, I see, you have running no glx driver. The required driver in xorg.conf must be named nvidia. So, you can forget my suggestions and ideas. You have no nvidia-glx driver installed. If you might run with nvias accelerated drivers, you first should have good knowledge about package handling. Sorry, I could not help you. Best regards Hans Hans -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: openoffice locks graphic video ???
On Mon, 2007-11-12 10:04:54 -0600, helices [EMAIL PROTECTED] wrote: I have now experienced this three (3) times; so, it is chronic : However, it is intermittent. Sometimes, when opening and/or manipulating an XLS created on winders; the desktop freezes. The mouse pointer moves; but, no alt-tab; no menuse; no ctrl-fkeys; nothing. When I ssh into this box, the CLI works fine. I restart gdm; and I kill gdm; but, the frozen desktop video remains on the screen. So far, when this happens, the only solution is a full system reboot. Just for the records, I've seen that, too, several times. Usually, that happened when I pressed the Alt key to move the window around (Windowmaker: Hit Alt and grab the window anywhere.) In these situations, the menu's File part got blue, but the rest of the menu didn't show up. Mouse movement was sssowww, and the mouse pointer didn't leave the screen (dual-head configuration with xinerama, drivers are s3virge and i810.) Oh, and that wasn't on a x86_64 system, but on a simple plain 3GHz Pentium 4. Killing OOo alone didn't ever help, I needed to shutdown the X11 server and restart it (usually blindly, since I needed to kill -9 it.) However, I haven't seen that during the last few weeks. Probably there's a version of OOo in Debian unstable that fixes it, or at least mostly. MfG, JBG -- Jan-Benedict Glaw [EMAIL PROTECTED] +49-172-7608481 Signature of:Don't believe in miracles: Rely on them! the second : signature.asc Description: Digital signature
Re: Intel Core2Duo (T7400)
On 11/12/07, Gabor Gombas [EMAIL PROTECTED] wrote: On Thu, Nov 08, 2007 at 09:31:31AM -0500, Lennart Sorensen wrote: I don't consider it a real issue either, but it is still something. I am not sure why sparc tends to run 32bit for most programs and only 64bit for select cases where it helps. Certainly x86_64 seems to be better than i386 in just about all cases. Taking the same code, going from 32-bit to 64-bit will cause a slowdown, period. The only way to overcome that is if you can write better code in 64-bit mode than you could in 32-bit mode. There are apps that indeed benefit from directly accessing more than 2G of address space and therefore can use simpler algorithms in 64-bit mode, but they are rare (at least on desktop). In my opinion certainly all the applications wrote in the past has no designed to use 64 bits operations and many algorithms could have beneffits of this, if in the same bus (64 bits) are you only use 32= bits operands there is no gain at all... The plus is involved in move and operate data at double rate 64/32 if the code is rarely doing this we have this slowdown, obviously thats not true if its not a full 64 bits REAL bus... And (this is only my knowledge from 8085 - 8088/80188 old procesors) the pointers to the data are in many cases relatives and not necesarily should be so long, if this is not true now let me know, I just presume that the nowadays procesors still have the ugly segment registers... AMD knew all this and they also knew they have to counter-balance the slowdown if they ever wanted 64-bit to became the norm, so they did a smart trick and doubled the register set size in 64-bit mode. Since i386 is a very register-starved architecture, that move indeed helped a lot by making it much easier for compilers to generate better code. So it's not only in 64-bit mode you can keep more variables in registers but also it is easier to write good compilers for 64-bit mode. AFAIK Sparc (and basycally any other 64-bit capable processor) offers the same number of registers in both 32-bit and 64-bit mode, so there is nothing that could balance the slowdown caused by going 64-bit. And even if they wanted to use the same trick as AMD it would not help as Sparc already has enough registers - adding more would give a much much smaller performance gain than it did for x86_64. I hope they come out with a way faster improved CPU before then. Hehe, they could introduce a new 32-bit mode that has the same number of registers as the 64-bit mode has. OTOH marketing people would have a really tough time to push down such a change on consumers' throats... Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- 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 Integrated Technology Tel: (55) 52 54 26 10
Re: forcedeth generates Invalid MAC address message
On 11/12/07, Keith Schweikhard [EMAIL PROTECTED] wrote: On Sunday 11 November 2007, Douglas A. Tutty wrote: On Sun, Nov 11, 2007 at 04:29:54PM -0800, Keith Schweikhard wrote: No luck on the MAC addresses being printed on the bottom. I've tried to locate the chip on the IEEE website without luck. It looks like the MAC address that is getting posted on both machines is in a reverse byte order. When I call up the MAC address on the Windows side of the computer the byte order is reversed. As a result, the first three bytes of my MAC address are 00-1B-38. According to IEEE these MAC addresses are assigned to COMPAL ELECTRONICS TECHNOLOGIC CO., LTD. Judging from what I am reading, Nvidia chips had issues with reporting their MAC addresses. As a result, forcedeth swaps the bytes. The board in the computer claims to be Nvidia, but the chip is registered to Compal. In looking up the chipset in hardware for linux http://hardware4linux.info/component/15830/ I get pointed to a different driver for the NIC. (r8169) But the kernel does not seem realize this during the boot process. As a result, it calls forcedeth and forcedeth swaps the byte order. I am baffled on how to override this selection. I've already tried blacklisting forcedeth in /etc/modprobe.d/blacklist and adding r8169 into /etc/modules but it seems to load the forcedeth module regardless of the fact that it is blacklisted. I have also tried moving forcedeth.ko from the kernel/drivers/net/ directory but without luck. forcedeth gets loaded as a module anyway. This problem happens as soon as forcedeth tries to initialize the NIC. I'm not certain what to try next. Any suggestions? Either the forcedeth module is built into the kernel or is being loaded by udev. If its loaded by udev, if you turn off networking, you should be able to rmmod the forcedeth module, then insmod the r8169 and see if it works. yeap I couln't answer before because I don't remember udev... to fix the random choice of ethX there is a file in /etc/udev*/*net* in that file the MAC is stored and could make some noise, try to erase the lines to test... That would be the first step. Then, I guess you'd need to reconfigure the initrd to load the r8169 module instead of the forcedeth (i.e. remove the forcedeth module from the initrd altogether). Doug. Thanks for the information. I finally got forcedeth to quit coming up by removing it from initrd. Unfortunately, the r8169 module will not communicate with the nic. I'm going to need to keep working at that one. The good news is that the wireless card now works so I can at least configure the system to run using a consistent IP. I'm going to have to keep hacking at the NIC to see if there is a driver out there that fixes the problem as time permits. -- 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 Integrated Technology Tel: (55) 52 54 26 10
Re: Intel Core2Duo (T7400)
On Mon, Nov 12, 2007 at 03:36:27PM -0600, Jaime Ochoa Malag?n wrote: In my opinion certainly all the applications wrote in the past has no designed to use 64 bits operations and many algorithms could have beneffits of this, if in the same bus (64 bits) are you only use 32= bits operands there is no gain at all... The plus is involved in move and operate data at double rate 64/32 if the code is rarely doing this we have this slowdown, obviously thats not true if its not a full 64 bits REAL bus... And (this is only my knowledge from 8085 - 8088/80188 old procesors) the pointers to the data are in many cases relatives and not necesarily should be so long, if this is not true now let me know, I just presume that the nowadays procesors still have the ugly segment registers... Yes they have the segment registers, but they only apply in real mode. In protected mode the cpu has a flat memory model instead and uses memory mapping and other tricks to manage memory access. 32bit protected mode provides a flat 4GB address space. PAE allows the OS to map memory up to 64GB into the 4GB address space of a given application, so that even though a single application only has a 4GB address space, the system can have up to 64GB of memory to use for running multiple applications (and caching and other OS related uses). In 64bit mode you get a flat 64bit memory space, although current CPUs only support 48bits or something like that, and ignore the high bits for now, which means you could use all your ram for a single application. Neither 32 nor 64bit mode use the segment registers at all (or at least not the way they were used in real mode). The i386 and above support 32bit protected mode. The 286 had a different protected mode that provided a 24bit flat memory model (this clearly shows in the 32bit page tables since you have a 16bit value in one place, an 8bit value somewhere else and finally another 8bit value yet somewhere else all in one structure to provide the 32bit address of the page. It's been a while since I looked at that stuff). In protected mode all pointers are full addresses in general (although you certainly can still use offsets from a register too, and often do). Given the register offset accesses on x86, you probably don't get quite the same hit on performance that you would on 64bit RISC designs where the general model seems to be you move data between memory addresses and registers, and then operate on the registers and then move data to memory again. Even those do tend to have the ability to refer to the address in a register though so you still don't have to always use 64bit memory addresses to refer to memory. x86 also has variable length instructions, where RISC would make all instructions 32bit or 64bit long. I am not sure if the instructions have changed length on x86_64 at all compared to x86. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: forcedeth generates Invalid MAC address message
FYI On 11/12/07, Mike Cruz [EMAIL PROTECTED] wrote: I found a fix on the Debian forums. http://forums.debian.net/viewtopic.php?t=14331highlight=forcedeth You edit your /etc/udev/rules.d/z25_persistent-net.rules file. remove all old entries your not using then add this one ( SUBSYSTEM==net, DRIVERS==forcedeth, NAME=eth0 ). this worked like a charm on my server AMD64 kernel 2.6.18* Mike -- 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 Integrated Technology Tel: (55) 52 54 26 10
Re: Intel Core2Duo (T7400)
On Mon, Nov 12, 2007 at 09:46:57AM -0500, Lennart Sorensen wrote: They also deprecated MMX and x87 (hence reducing the old crap to carry around on centext switches), and switched to sse match (which is much faster and not stack based), and add some new instructions that can help code in general. AFAIK SSE is also available in 32-bit mode so that is no reason why x86_64 should be faster. That almost certainly is much more important than the register count. As far back as the Pentium Pro the pipeline's out of order execution had a large register rename file which allowed it to do speculative execution. It also allowed skipping stack accesses to memory by simply renaming the old register into an unused spot in the register file boing by the assumption that stuff put on the stack is often needed again soon, so rather than putting it in memory, just keep it in an unused virtual register. As a result the Pentium Pro and most newer x86 processors actually already perform as if they had more registers than the architecture does in most cases. Again this is a reason why new 32-bit processors are faster than old 32-bit processors, but not a reason why x86_64 mode should be faster than i386 mode on the same processor. I am not saying adding registers wasn't a good idea, but I think people are highly over estimating their significance. I don't have numbers so I can't really argue, but that is the largest visible difference between the two modes. I guess a simple way to test is to convince the compiler that the 64bit mode has the same number of registers as 32bit mode and then compiling software that way and comparing the result in 32 and 64bit mode when both have the same register count. Shouldn't be too hard to do for someone that understands gcc's code (which is not me). I don't think it would be that easy, but the idea is interesting. Given the amount of ram in your average desktop is getting close to requiring a 64bit OS, there is really no point designing anything new with 32bit operation in mind. People have to switch to 64bit OSs if they want to be able to use more ram within the next year or so. You said Sparc/Solaris; I don't know the current top-of-line configs but several hundred gigabytes of memory should not present a problem for a really high-end Sun server and as you said most of the userspace is still 32-bit... The kernel of course must be 64-bit, but that's not a problem even if 64-bit mode is significanlty slower since applications do not spend too much time in the kernel (and if they do that's almost certainly a bug). But back to the original issue: x86_64 is _NOT_ faster because it is using 64-bit addressing - quite the contrary, that alone would have made it slower than 32-bit mode. But AMD also did a lot of other modifications that they _could_ have also enabled in 32-bit mode but they simply choose not to, because otherwise they could not have sold their 64-bit processors. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
audio performance.
Dear all, I have a Soundblaster Audigy LS that I use for sound. (the on-board Intel HD audio device (driver - snd-hda-intel) was unreliable a year ago when I did my first install.) It works fine for system sounds and the occasional movie, but playing some mp3's I find extraneous sounds creeping in. This is not new, however, as this noise has been there from the start of using the Soundblaster. So now I'm trying to track down the source of the noise. I have an AMDX2 running on an Asus M2NPV-VM. kernel: amd64.x2 2.6.22-2-amd64 #1 SMP currently the soundcard is at IRQ 16 In Kcontrol I've enabled: realtime priority full duplex This has made no difference that I can detect. I assume that playing mp3's shouldn't be the cause of the noise? If anyone can give me a leg up on this, that would be great. Thanks, Chris W. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
