[gentoo-amd64] partly OT: nvidia 6600GT

[gentoo-amd64] partly OT: nvidia 6600GT

[Thierry de Coulon]

Hello. I think this topic is partly OT because it's not directly 
gentoo-related but it might be amd64 related so...

I've struggled for two weeks to have my gentoo-amd64 running various OpenGL 
games. Dome did run, other crashed in various ways: either a stuck computer, 
usually seeming related to a soud and/or I/O conflict, or sometimes simply a 
total reset. And it was the same thing with Gentoo (32/64), SuSE (32/64) and 
Debian/Mepis (32 bit)

The setup was a Tyan k8w-s2875ANRF board and an AGP Gainward with an nvidia 
6600GT chip.

In the end, I removed the card and pulled an Asus nvidia 5700 based graphic 
card out of another computer and see: everything's running fine - and I'd 
even say movement is smoother, despite the fact that the 6600GT is given as 
much faster.

Now, I put the 6600GT in the other computer (a P4) and tested that computer 
(not with gentoo, actually with SuSE): no problem.

So, I am wondering what causes the conflict: the board, the opterons, 
Gainward's card?
Has anyone a 6600GT running fine ona  double opteron?

Thierry

-- 
The problem with the world is stupidity. Not saying there should be a
capital punishment for stupidity, but why don't we just take the
safety labels off of everything and let the problem solve itself?
Frank Zappa
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] partly OT: nvidia 6600GT

[Hemmann, Volker Armin]

On Saturday 25 February 2006 21:04, Thierry de Coulon wrote:

>
> In the end, I removed the card and pulled an Asus nvidia 5700 based graphic
> card out of another computer and see: everything's running fine - and I'd
> even say movement is smoother, despite the fact that the 6600GT is given as
> much faster.
>

if the 6600GT needs more current, I would say it is an overloaded PSU.
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] partly OT: nvidia 6600GT

[Thierry de Coulon]

On Saturday 25 February 2006 23.51, Hemmann, Volker Armin wrote:
> On Saturday 25 February 2006 21:04, Thierry de Coulon wrote:
> > In the end, I removed the card and pulled an Asus nvidia 5700 based
> > graphic card out of another computer and see: everything's running fine -
> > and I'd even say movement is smoother, despite the fact that the 6600GT
> > is given as much faster.
>
> if the 6600GT needs more current, I would say it is an overloaded PSU.

It does (requires a hard disk connector), however the PSU for the Tyan board 
is a 460W and I think (I must check) the one for the Gigagbyte/P4 is only 
300W.
But thanks for that hint, it's agood idea - I'll take a look

Thierry

-- 
The problem with the world is stupidity. Not saying there should be a
capital punishment for stupidity, but why don't we just take the
safety labels off of everything and let the problem solve itself?
Frank Zappa
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: partly OT: nvidia 6600GT

[Duncan]

Thierry de Coulon posted <200602252104.35727.tcoulon@decoulon.ch>,
excerpted below,  on Sat, 25 Feb 2006 21:04:35 +0100:

> So, I am wondering what causes the conflict: the board, the opterons, 
> Gainward's card?
> Has anyone a 6600GT running fine ona  double opteron?

It could be the marginal timings between the card and the board (and the
main memory).  Sending signals of hundreds of megahertz thru not only a
hard-wired (and factory tweakable) mainboard, and a similar expansion
card, but thru the slot connector, is inherently an unstable situation. 
Some cards will simply cause problems with some boards, even tho both are
within spec and "work" in general, and there's not much that can be done
about it except switch things out to get something that works.

Of course, timings on a dual CPU board are going to be even more finely
tuned, and memory as well has signals at hundreds of megahertz, and a
socket that introduces a slight bit of variability in capacitance and
connectivity on each conductor -- that can make HUGE difference at
hundreds of megahertz radio frequency.

Power, as already mentioned, is probably a more common issue than this,
but...

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: partly OT: nvidia 6600GT

[Peter Humphrey]

On Sunday 26 February 2006 09:57, Duncan wrote:

> Of course, timings on a dual CPU board are going to be even more finely
> tuned, and memory as well has signals at hundreds of megahertz, and a
> socket that introduces a slight bit of variability in capacitance and
> connectivity on each conductor -- that can make HUGE difference at
> hundreds of megahertz radio frequency.

Which reminds me of a problem I had a few years ago which was solved by 
moving a card to another slot. When clutching at straws ...

-- 
Rgds
Peter
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: partly OT: nvidia 6600GT

[Roy Wright]

Peter Humphrey wrote:

>Which reminds me of a problem I had a few years ago which was solved by 
>moving a card to another slot. When clutching at straws ...
>
>  
>
I had a similar problem last year, turned out the 6800GT wasn't all the
way into the connector.  When I would tighten the hold down screw, the
opposite end would raise just a little (~1/16").  Removed and reinstalled
the board three times before I caught it...


-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: Re: partly OT: nvidia 6600GT

[Duncan]

Roy Wright posted <4401999F.9080507@cisco.com>, excerpted below,  on Sun,
26 Feb 2006 06:05:51 -0600:

> Peter Humphrey wrote:
> 
>>Which reminds me of a problem I had a few years ago which was solved by 
>>moving a card to another slot. When clutching at straws ...
>>
> I had a similar problem last year, turned out the 6800GT wasn't all the
> way into the connector.  When I would tighten the hold down screw, the
> opposite end would raise just a little (~1/16").  Removed and reinstalled
> the board three times before I caught it...

It's observed that the following discussion probably isn't new to many,
but perhaps some haven't thought about all the complex cross-effects in
this way before...

Actually, if you read the troubleshooting info with quite a number of
items, both reseating and trans-slotting are officially recommended
troubleshooting methods.

Over months or years of on/off cycling and other hot/cold cycles, not only
is it possible for cards (and connectors) to work loose, but an oxidation
layer may form preventing a decent connection.  Again, at the frequencies
many computer components operate at, the problem may not be simply lack of
a good DC electronic connection, but the fact that the changing
conditions takes a connection or set of connections out of capacitance
spec, sometimes causing an entirely separate resonance at an unintended
frequency.  Capacitance of course allows current to jump to parallel but
not directly connected circuit traces, and there are often lots of those
on a circuit board.  The circuit of a specified frequency intended to be
completed over one set of physically connected leads may end up entirely
transmutated as a parallel circuit develops resonating frequency
capacitance, changing the character and details of the transmitted data
entirely and wrecking havoc.

Note that as memory speeds have increased, mobo makers have had to go to
increasing lengths to ensure such interference and cross-echo patterns
don't develop.  Properly terminated data circuits aren't just a SCSI
thing, and many a board design has been delayed or even ultimately junked
as it simply couldn't handle the memory and other signal timings, and keep
trans-circuit resonance and feedback, to within acceptable tolerance
levels.

Anyway...  something as simple as reseating a card, due to the friction of
the connector spring pins against the exposed board traces, will often
scratch away that oxidation and return the various circuits to designed
operating parameters in both DC resistance and RF capacitance, within and
across circuits.  That's often all that's needed, and the reason just
taking something apart, finding nothing visibly wrong, giving up and
putting it back together "without changing anything", actually allows some
things to work again.

As for trans-slotting, it's less common in modern boards, but it was quite
common a few years ago for only 1-2 slots out of 3-5 to be fully
"pci-master" capable.  Anything using heavy data transfers could often
make use of pci-master, offloading work from the CPU under certain
conditions, altho the most common use was data transfer between harddrives
-- if both were in PCI-master slots, or one was and the other was onboard,
the chipset could often handle data transfer between them without direct
CPU intervention, once the transfer was initially setup.

Additionally, the PCI spec has four interrupt channels, normally staggered
so a different one will be in each slot of the first four -- a fifth slot
shares placement with the fourth, in most cases, and will work best  when
purposed to something (like a video card) not normally requiring
interrupts.  This is because while all four interrupts are available and
exposed to all slots, most cards only use one primary interrupt pin, in a
standardized location, altho some will allow use of a second for
flexibility and many multifunction cards use two or more if all functions
are enabled.  Most new mobos come with a diagram of their PCI interrupt
layout per slot, and specifically advise trying a different slot if a card
doesn't work as expected, thereby causing it to utilize a different one of
the four PCI interrupts.

Finally, there are intercard proximity factors as well.  Of course,
there's pure physical space requirements -- some cards simply don't fit
next to each other or for sound cards and the like, plus PATA/SATA drives
and even interface cards with detached plugs, attached cabling simply
won't reach to all possible slots.  Heat and ventilation are another major
factor.  However, the same cross-circuit inductive and capacitive effects
outlined above can play a factor here, as well.  This can be as simple and
easily recognized as a buzz on your sound card when it's too close to
another specific card, or as difficult and unintuitive to recognize as 
memory issues or disk storage errors.  One particular thing that we've not
had to worry about for a few years (due to dedicated AGP slots) that we'll
have to start worrying about again as PCI-Express becomes more common is
video card placement, as those have all sorts of RF things going on, with
both high data rate memory access, and high frequency video signalling. 
Get those signals cross-interfering with something like memory/CPU
channels or CPU/CPU interconnects (AMD's hypertransport, and Via has a
similar technology for northbridge/southbridge interconnects, among
others), or an add-on SATA/PATA/SCSI interface card, and there could be
/major/ data integrity issues to worry about!

It should be quite obvious by now that mobo designers certainly don't have
it easy, these days!  Sure, they deal with lower frequencies than CPUs and
graphics chips deal with, and don't have the intricate logic and heat
dissipation layout issues that those guys do.  However, the frequencies
they do deal with are quite high enough to cause **MAJOR** cross-circuit
interference design issues, particularly over the trace length of
centimetres they deal with, as opposed to the nanometre/micrometre scales
a chip designer deals with.  As I said, it's not unusual at all for a mobo
design to simply not be able to handle the necessary timing demands placed
upon it, and either be limited to the low end of an offered range (those
mobos that are certified for PC2700 memory or less, because they simply
can't handle PC3200), or end up entirely rejected due to stability issues.

Under this sort of tight timing requirements, it's actually a wonder we
don't have more cards that simply won't work right in certain boards,
while they work just fine in others.  That alone is tribute in itself to
the wonders of human engineering genius, both in design, and in the
ability to actually implement said design in an assembly-line environment
to within the required tolerances, without costing us several thousand
dollars for the mother-board alone!

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: Re: partly OT: nvidia 6600GT

[Hemmann, Volker Armin]

On Sunday 26 February 2006 15:19, Duncan wrote:

when your father told you 'teaching is a good way to learn', he also should 
have told you 'Make it short' and 'stay at the subject and don't stroll away' 
or 'you will loose audience' and will be known as 'babbling duncan'.


Sometimes your mails are really informative - put this information is usually 
lost in lots and lots of text.
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: Re: Re: partly OT: nvidia 6600GT

[Duncan]

Hemmann, Volker Armin posted
<200602261739.23000.volker.armin.hemmann@tu-clausthal.de>, excerpted
below,  on Sun, 26 Feb 2006 17:39:22 +0100:

> On Sunday 26 February 2006 15:19, Duncan wrote:
> 
> when your father told you 'teaching is a good way to learn', he also should 
> have told you 'Make it short' and 'stay at the subject and don't stroll away' 
> or 'you will loose audience' and will be known as 'babbling duncan'.

'Tis my curse.  Perhaps too many "Write X pages on subject Y" assignments
as I kid.  I didn't /used/ to be this overly verbose. =8^(

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] partly OT: nvidia 6600GT

[Alastair Murray]

Thierry de Coulon wrote:
> I've struggled for two weeks to have my gentoo-amd64 running various OpenGL 
> games. 
<snip>
> with an nvidia 
> 6600GT chip.
<snip>

Seeing as you don't mention it in your post, which drivers and which 
version are you using?

Alastair Murray.
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] partly OT: nvidia 6600GT

[Thierry de Coulon]

On Sunday 26 February 2006 11.45, Alastair Murray wrote:
> Thierry de Coulon wrote:
> > I've struggled for two weeks to have my gentoo-amd64 running various
> > OpenGL games.
>
> <snip>
>
> > with an nvidia
> > 6600GT chip.
>
> <snip>
>
> Seeing as you don't mention it in your post, which drivers and which
> version are you using?
>
> Alastair Murray.

I use the nvidia drivers that emerge proposes (once unmasked):

nvidia drivers: 2.0.1 NVIDIA 81.78
X version: Xorg Version 6.8.2
kernel: 2.6.15-gentoo-r5
Gentoo Base System version 1.6.14

I'll take a look at the way tha card was plugged in. As for changing slot...  
it's an AGP card and I have but one slot :)

Thierry

-- 
The problem with the world is stupidity. Not saying there should be a
capital punishment for stupidity, but why don't we just take the
safety labels off of everything and let the problem solve itself?
Frank Zappa
-- 
gentoo-amd64@gentoo.org mailing list