Re: K8S Pro (S2882UG3NR) + Sil 3114 (Raid 1) + Sarge

2004-10-26 Thread Lennart Sorensen
On Tue, Oct 26, 2004 at 10:56:59PM -0500, Ron Johnson wrote:
> > Well software raid is defined as raid that does the calculations in
> > software (on your cpu), while hardware raid does the calculations using
> > custom circuitry or a dedicated cpu running some software (firmware).
> > 
> > If I have to waste cpu time on raid, I at least want to be able to see
> > the code running on my cpu and perhaps be able to improve on it.  That
> > is the difference.
> 
> Ummm, but with true h/w RAID, you are *not* wasting main CPU time
> on it.  On "enterprise systems", the SCSI card itself doesn't even 
> know that it's talking to a RAID set, since the SCSI cards connect
> to a "RAID controller", which the SCSI disks also plug into.

Exactly.  Hardware raid is great.  It's the proprietary cards that use
software raid I don't like wasting my cpu on.

Len Sorensen




Re: K8S Pro (S2882UG3NR) + Sil 3114 (Raid 1) + Sarge

2004-10-26 Thread Ron Johnson
On Tue, 2004-10-26 at 23:28 -0400, Lennart Sorensen wrote:
> On Sun, Oct 24, 2004 at 08:28:35PM -0500, Ron Johnson wrote:
> > Isn't *all* real h/w RAID "just secret proprietary software" on
> > the RAID controller?  Whether it be in flash or an EEPROM, real 
> > h/w RAID controllers have a dedicated (usually specialized) CPU
> > for handling the RAID calculations, SCSI commands, RAM cache, etc.
> > 
> > Thats why when you call up IBM, HP or Sun with a disk-related issue,
> > they ask you if your SCSI cards & RAID controllers are at the latest
> > ROM version.
> 
> Well software raid is defined as raid that does the calculations in
> software (on your cpu), while hardware raid does the calculations using
> custom circuitry or a dedicated cpu running some software (firmware).
> 
> If I have to waste cpu time on raid, I at least want to be able to see
> the code running on my cpu and perhaps be able to improve on it.  That
> is the difference.

Ummm, but with true h/w RAID, you are *not* wasting main CPU time
on it.  On "enterprise systems", the SCSI card itself doesn't even 
know that it's talking to a RAID set, since the SCSI cards connect
to a "RAID controller", which the SCSI disks also plug into.

A good example of this is/was the DEC/Compaq HSZ controllers.
These are 1-Up rack-mounted computers dedicated only to managing
SCSI disks in RAID configurations.  512MB battery-backed RAM, the
ability to join with another controller in a dual-redundant mode
(so that you had an effective 1GB of cache).  I don't know how 
things worked in Digital Unix, but under VMS, you connect to it
via SET HOST/HSZ to configure it.  You could also plug a VT-220
terminal directly into it.  Very convenient for initial configur-
ation.

Oh, and it worked with shared-disk VMS clustering.

-- 
-
Ron Johnson, Jr.
Jefferson, LA USA
PGP Key ID 8834C06B

"Never for the sake of peace and quiet deny your convictions."
Dag Hammarskjold



signature.asc
Description: This is a digitally signed message part


Re: K8S Pro (S2882UG3NR) + Sil 3114 (Raid 1) + Sarge

2004-10-26 Thread Lennart Sorensen
On Sun, Oct 24, 2004 at 08:28:35PM -0500, Ron Johnson wrote:
> Isn't *all* real h/w RAID "just secret proprietary software" on
> the RAID controller?  Whether it be in flash or an EEPROM, real 
> h/w RAID controllers have a dedicated (usually specialized) CPU
> for handling the RAID calculations, SCSI commands, RAM cache, etc.
> 
> Thats why when you call up IBM, HP or Sun with a disk-related issue,
> they ask you if your SCSI cards & RAID controllers are at the latest
> ROM version.

Well software raid is defined as raid that does the calculations in
software (on your cpu), while hardware raid does the calculations using
custom circuitry or a dedicated cpu running some software (firmware).

If I have to waste cpu time on raid, I at least want to be able to see
the code running on my cpu and perhaps be able to improve on it.  That
is the difference.

Len Sorensen




Re: ld segfaults, BFD 2.15 assertion fail

2004-10-26 Thread foo
It turns out there was a missing
#include 

It works now.

-ryan




Re: ld segfaults, BFD 2.15 assertion fail

2004-10-26 Thread Kurt Roeckx
On Tue, Oct 26, 2004 at 03:51:48PM -0400, [EMAIL PROTECTED] wrote:
> 
> So it appears there's a problem with TLS.  I should note that this
> problem started happening when libc6 was updated a couple of weeks ago.
> I noticed that moved a lot of libraries from /lib/tls to /lib, so it
> seems that that's where the real problem is.  When I upgraded to
> libc6_2.3.2.ds1-17, running the program gave me the error:

Since libc6_2.3.2.ds1-17 it's nptl only on amd64 since we don't
support the older than 2.6 kernels.  This seems to have triggered
some bugs.  But only a few it seems.


Kurt




Re: ld segfaults, BFD 2.15 assertion fail

2004-10-26 Thread foo
I found a patch that's supposed to solve the problem, from here:
http://sources.redhat.com/ml/binutils/2004-09/msg00299.html
which I found from here:
http://sources.redhat.com/bugzilla/show_bug.cgi?id=414

The patched ld no longer segfaults, instead giving:

/usr/bin/gcc -o molmol -I../../tools/include -I../../sg/include -I../../include 
 -I../../../Mesa-2.4/include -O2 -D_GNU_SOURCE -I/usr/include/GL 
-I/usr/X11R6/include MolMol.o MolInit.o ../../lib/libcip.a ../../lib/libcmd.a 
../../lib/libui.a ../../lib/libgraph.a ../../lib/libio.a ../../lib/libpu.a 
../../lib/libcalc.a ../../lib/libprim.a ../../lib/libdata.a ../../lib/libattr.a 
../../lib/libfileio.a ../../lib/libos.a ../../sg/lib/libsg.a 
../../tools/lib/libtools.a ../../tiff-v3.4/libtiff/libtiff.a 
../../../jpeg-6a/libjpeg.a ../../../libpng-0.89c/libpng.a 
../../../zlib-1.0.4/libz.a /usr/X11R6/lib/libGLw.a -L../../../Mesa-2.4/lib 
-L/usr/X11R6/lib -lGL -lGLU -lXm -lXmu -lXt -lXpm -lX11 -lXext -lm -lc -lieee
../../lib/libos.a(GFile.o)(.text+0x67): In function `raiseError':
: warning: `sys_errlist' is deprecated; use `strerror' or `strerror_r' instead
/usr/bin/ld: ): TLS definition in %B section 0X0.0007FBFFFE87P-1022 mismatches 
non-TLS reference in %B
/lib/libc.so.6: could not read symbols: Bad value
collect2: ld returned 1 exit status

So it appears there's a problem with TLS.  I should note that this
problem started happening when libc6 was updated a couple of weeks ago.
I noticed that moved a lot of libraries from /lib/tls to /lib, so it
seems that that's where the real problem is.  When I upgraded to
libc6_2.3.2.ds1-17, running the program gave me the error:

//usr/local/molmol/molmol.lnx: relocation error: //usr/local/molmol/molmol.lnx: 
symbol errno, version GLIBC_2.2.5 not defined in file libc.so.6 with link time 
reference

And then I tried to recompile and got the linker error, etc.  I should
note that this binary was not compiled against glibc 2.2.5, but rather
2.3.2.ds1-13.0.0.1, so the error is kind of confusing.

So is there something wrong with libc6 or what?  How can I make this
work?

Thanks,
-ryan




some processes having large memory footprints

2004-10-26 Thread Richard Wohlstadter
Hello all,
I'm new with the AMD64 debian port and had some questions I'm hoping 
someone out there can answer for me.  One thing I noticed after 
installing the AMD64 port on our opterons is that some processes seem to 
have very large memory footprints on the system.  For example, sshd 
instances are taking 26m virtual, bash taking 8m, ntpd taking 11m.  Does 
this have to do with how these binaries are allocating their data 
structures and since I'm pure 64 bit they suck up more memory?  Just 
seems like alot of waste(although resident memory usage is more in line 
with what 32bit machines use).  Thanks for any input anyone can share 
regarding this.

Rich



Beginner question about pure64 vs. sarge vs. gcc3.4

2004-10-26 Thread Steffen Schwigon
Hi!

[ I'm new to 64bit, but read amd64 HOWTO and the like ]

I want to setup a Debian/Sarge-like system on my Athlon64fx. I tried
an install of "sarge" with a Debian-Installer-CD. The install itself
looked good, but it couldn't write a correct boot loader, neither GRUB
nor LILO. The MBR became corrupted.

The questions:

1. Is the recommended method an installation via bootstrapping
   into a chroot based on a classic 32bit system?
   (The Installer ran good, maybe I just forgot something. The 32bit
   installer installed GRUB without problems.)

2. After the broken MBR, I wanted to boot from the install CD with
   parameter "root=/dev/...". That didn't work. I tried different
   names: /dev/hda6, /dev/sda6, /dev/discs/disc0/part6, but always get
   kernel panic "Unable to mount root fs".

   Is this possible in any way? It seems to need some modules for my
   SATA harddisc. So maybe it won't work with the kernel on CD.

(Greeti+Tha)nX
Steffen
-- 
Steffen Schwigon <[EMAIL PROTECTED]>
Dresden Perl Mongers 




Re: Recommended Graphics card for OpenGL (was Matrox P650 / Athlon 64)

2004-10-26 Thread Thomas J. Zeeman

Hi,

> I wonder whether anyone knows (if any) graphics board can be bought
> which also has complete source code for reasonable, even average,
> performance OpenGL (Mesa) which also works on pure64?  Presumably
> nVidia has released some source code, but from my limited experience
> with nVidia graphics on 32bit laptops, not all the source code was
> released.
> [snip]
> ps. currently using a Matrox G550 graphics card.

If the G550 does not perform as good as you want it to with OpenGL then I
think there is hardly a card that is going to fit the "complete open
source" requirement.
Possibly the Ati 8500 or derivatives up until the 9200 could do the job,
but I don't know for sure.

For nVidia there is no OSS driver with working, accelerated 3D, only a
closed source. nVidia is the only one with a driver for AMD64 available
though.

regards,
Thomas




Re: Recommended Graphics card for OpenGL (was Matrox P650 / Athlon 64)

2004-10-26 Thread Cameron Patrick
Gaius Mulley wrote:

> I wonder whether anyone knows (if any) graphics board can be bought
> which also has complete source code for reasonable, even average,
> performance OpenGL (Mesa) which also works on pure64?

I've had good luck with the Radeon 9200 in a number of 32-bit machines
(though I've no idea how well they'd work on AMD64).  The driver is
completely open source and supports 2D and 3D acceleration.  The
higher end Radeons have no 3D support under Linux except for ATI's
proprietary 32-bit-only drivers.

Cheers,

Cameron.



signature.asc
Description: Digital signature


Recommended Graphics card for OpenGL (was Matrox P650 / Athlon 64)

2004-10-26 Thread Gaius Mulley
"Thomas J. Zeeman" <[EMAIL PROTECTED]> writes:

> Hi,
> 
> > So, I conclude that waiting some time before actually trying to install
> > 64bit on my machine is a good idea?
> >
> >  What do you think, can I expect support for my graphic-card provided by a
> > 64bit-X-Server at some time in the future, as some of the older
> > Matrox-cards are supported in 32 bit?
> 
> If you can afford to wait for more than 12 months or even longer before
> Matrox finally decides to publish a working amd64-enabled driver, then I
> would say it is a good idea.
> For me it was not. I wanted to be able to have a working machine with X.
> I checked which manufacturer did more than pay lip-service and ended up
> with a list containing only nVidia.
> 
> Also, don't hold your breath for OSS drivers. The existing ones are for a
> completely different GPU-architecture (the G-series) for which they
> published enough documentation to get OSS drivers to be created.
> The new Parhelia-chip is 'classified' and I do not think they want to
> disclose any documentation even if you are willing to sign NDAs.

Hi,

I wonder whether anyone knows (if any) graphics board can be bought
which also has complete source code for reasonable, even average,
performance OpenGL (Mesa) which also works on pure64?  Presumably
nVidia has released some source code, but from my limited experience
with nVidia graphics on 32bit laptops, not all the source code was
released.

Also I'd like to report that pure64 works out of the box on (another)
ASUS SK8V (VIA K8T400) with a 248 Opteron and it flies - great work
folks,

Thanks Gaius

ps. currently using a Matrox G550 graphics card.




buildd failure for amd64 - floating point encoding?

2004-10-26 Thread Helen Faulkner
Please CC to me - I'm not subscribed to the list.
I am maintaining a new package, labplot, that is failing, at its first upload, 
to build on amd64 (among other things).  I believe the problem is that there is 
no floating point encoding being defined for that architecture, which is leading 
to an undefined type of struct later on.

The program defines the floating point encoding in the included cdf library like 
this (from cdf/cdfdist.h, line 437 onwards):

/*
* Floating-point encodings.
*   1..Sun, SGi, IBM-RS, HP, NeXT, Macintosh
*   2..DECstation, IBM-PC, Alpha (OSF/1), Alpha (OpenVMS - IEEE_FLOAT)
*   3..VAX, Alpha (OpenVMS - D_FLOAT)
*   4..Alpha (OpenVMS - G_FLOAT)
*/
#if 
defined(sun)||defined(MIPSEB)||defined(IBMRS)||defined(HP)||defined(NeXT)||defined(mac)||defined(POWERPC)
#  define FP1cpu
#endif

#if 
defined(MIPSEL)||defined(IBMPC)||defined(alphaosf)||defined(alphavmsI)||defined(posixSHELLalphaI)
#  define FP2cpu
#endif

#if defined(vax)||defined(alphavmsD)||defined(posixSHELLalphaD)
#  define FP3cpu
#endif
#if defined(alphavmsG)||defined(posixSHELLalphaG)
#  define FP4cpu
#endif
Does anyone know whether amd64 uses the same encoding as one of these examples? 
What I am hoping is that amd64 uses the same floating point encoding as one of 
the archs this code already works for, and that it's therefore only a matter of 
fixing the #if statements above to include the amd64 case.

The FP*cpu definition is used later, (see below, from cdf/cdflib.h, line 400 
onwards) to define the data structs.  Hopefully one of these will work for amd64.

If anyone can help with a suggestion, that would be great.
Thank you,
Helen.
/**
* Floating-point structures.
**/
#if defined(FP1cpu)
  struct fp1struct4 {
uInt s : 1, e1 : 7, e0 : 1, m2 : 7, m1 : 8, m0 : 8;
  };
  struct fp2struct4 {
uInt m0 : 8, m1 : 8, e0 : 1, m2 : 7, s : 1, e1 : 7;
  };
  struct fp34struct4 {
uInt e0 : 1, m2 : 7, s : 1, e1 : 7, m0 : 8, m1 : 8;
  };
  struct fp1struct8 {
uInt s : 1, e1 : 7, e0 : 4, m6 : 4, m5 : 8,
 m4 : 8, m3 : 8, m2 : 8, m1 : 8, m0 : 8;
  };
  struct fp2struct8 {
uInt m0 : 8, m1 : 8, m2 : 8, m3 : 8, m4 : 8,
 m5 : 8, e0 : 4, m6 : 4, s : 1, e1 : 7;
  };
  struct fp3struct8 {
uInt e0 : 1, m6 : 7, s : 1, e1 : 7, m4 : 8,
 m5 : 8, m2 : 8, m3 : 8, m0 : 8, m1 : 8;
  };
  struct fp4struct8 {
uInt e0 : 4, m6 : 4, s : 1, e1 : 7, m4 : 8,
 m5 : 8, m2 : 8, m3 : 8, m0 : 8, m1 : 8;
  };
#endif
#if defined(FP2cpu)
  struct fp1struct4 {
uInt e1 : 7, s : 1, m2 : 7, e0 : 1, m1 : 8, m0 : 8;
  };
  struct fp2struct4 {
uInt m0 : 8, m1 : 8, m2 : 7, e0 : 1, e1 : 7, s : 1;
  };
  struct fp34struct4 {
uInt m2 : 7, e0 : 1, e1 : 7, s : 1, m0 : 8, m1 : 8;
  };
  struct fp1struct8 {
uInt e1 : 7, s : 1, m6 : 4, e0 : 4, m5 : 8,
 m4 : 8, m3 : 8, m2 : 8, m1 : 8, m0 : 8;
  };
  struct fp2struct8 {
uInt m0 : 8, m1 : 8, m2 : 8, m3 : 8, m4 : 8,
 m5 : 8, m6 : 4, e0 : 4, e1 : 7, s : 1;
  };
  struct fp3struct8 {
uInt m6 : 7, e0 : 1, e1 : 7, s : 1, m4 : 8,
 m5 : 8, m2 : 8, m3 : 8, m0 : 8, m1 : 8;
  };
  struct fp4struct8 {
uInt m6 : 4, e0 : 4, e1 : 7, s : 1, m4 : 8,
 m5 : 8, m2 : 8, m3 : 8, m0 : 8, m1 : 8;
  };
#endif
#if defined(FP3cpu)
  struct fp1struct4 {
uInt e1 : 7, s : 1, m2 : 7, e0 : 1, m1 : 8, m0 : 8;
  };
  struct fp2struct4 {
uInt m0 : 8, m1 : 8, m2 : 7, e0 : 1, e1 : 7, s : 1;
  };
  struct fp34struct4 {
uInt m2 : 7, e0 : 1, e1 : 7, s : 1, m0 : 8, m1 : 8;
  };
  struct fp1struct8 {
uInt e1 : 7, s : 1, m6 : 4, e0 : 4, m5 : 8,
 m4 : 8, m3 : 8, m2 : 8, m1 : 8, m0 : 8;
  };
  struct fp2struct8 {
uInt m0 : 8, m1 : 8, m2 : 8, m3 : 8, m4 : 8,
 m5 : 8, m6 : 4, e0 : 4, e1 : 7, s : 1;
  };
  struct fp3struct8 {
uInt m6 : 7, e0 : 1, e1 : 7, s : 1, m4 : 8,
 m5 : 8, m2 : 8, m3 : 8, m0 : 8, m1 : 8;
  };
  struct fp4struct8 {
uInt m6 : 4, e0 : 4, e1 : 7, s : 1, m4 : 8,
 m5 : 8, m2 : 8, m3 : 8, m0 : 8, m1 : 8;
  };
#endif
#if defined(FP4cpu)
  struct fp1struct4 {
uInt e1 : 7, s : 1, m2 : 7, e0 : 1, m1 : 8, m0 : 8;
  };
  struct fp2struct4 {
uInt m0 : 8, m1 : 8, m2 : 7, e0 : 1, e1 : 7, s : 1;
  };
  struct fp34struct4 {
uInt m2 : 7, e0 : 1, e1 : 7, s : 1, m0 : 8, m1 : 8;
  };
  struct fp1struct8 {
uInt e1 : 7, s : 1, m6 : 4, e0 : 4, m5 : 8,
 m4 : 8, m3 : 8, m2 : 8, m1 : 8, m0 : 8;
  };
  struct fp2struct8 {
uInt m0 : 8, m1 : 8, m2 : 8, m3 : 8, m4 : 8,
 m5 : 8, m6 : 4, e0 : 4, e1 : 7, s : 1;
  };
  struct fp3struct8 {
uInt m6 : 7, e0 : 1, e1 : 7, s : 1, m4 : 8,
 m5 : 8, m2 : 8, m3 : 8, m0 : 8, m1 : 8;
  };
  struct fp4struct8 {
uInt m6 : 4, e0 : 4, e1 : 7, s : 1, m4 : 8,