audio performance.

[C Wakefield]

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]

Re: Intel Core2Duo (T7400)

[Gabor Gombas]

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]

Re: forcedeth generates Invalid MAC address message

[Jaime Ochoa Malagón]

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=14331&highlight=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)

[Lennart Sorensen]

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

[Jaime Ochoa Malagón]

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)

[Jaime Ochoa Malagón]

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: openoffice locks graphic video ???

[Jan-Benedict Glaw]

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-f; 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  key to move the window around
(Windowmaker: Hit  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: openoffice locks graphic video ???

[Hans-J. Ullrich]

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-f; 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).
> > >
> > > 
> > >
> > > 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 ???

[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-f; 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).
> >
> > 
> >
> > 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 ???

[Hans-J. Ullrich]

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-f; 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).
>
> 
>
> 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: Intel Core2Duo (T7400)

[Lennart Sorensen]

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 ???

[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-f; 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). 


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: How to shift backwards on nvidia's driver?

[Hans-J. Ullrich]

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 ???

[Jochen Schulz]

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-f; 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]
 


signature.asc
Description: Digital signature

Re: openoffice locks graphic video ???

[Hans-J. Ullrich]

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-f; 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 below  >  Extras > 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]

* "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-f; 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 ???

[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-f; 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]
>  


-- 
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: How to shift backwards on nvidia's driver?

[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



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Intel Core2Duo (T7400)

[Rob Sims]

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: openoffice locks graphic video ???

[Hans-J. Ullrich]

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-f; 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: openoffice locks graphic video ???

[Jochen Schulz]

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-f; 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]
 


signature.asc
Description: Digital signature

openoffice locks graphic video ???

[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-f; 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: How to shift backwards on nvidia's driver?

[Lennart Sorensen]

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]

Re: Intel Core2Duo (T7400)

[Lennart Sorensen]

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: forcedeth generates Invalid MAC address message

[Lennart Sorensen]

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)

[Gabor Gombas]

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: How to shift backwards on nvidia's driver?

[Hans-J. Ullrich]

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: How to shift backwards on nvidia's driver?

[Keith Schweikhard]

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: forcedeth generates Invalid MAC address message

[Keith Schweikhard]

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]