hardware independent hinv

hardware independent hinv

[Ariel Faigon]

Just forwarding since it sounds someone hopes that Linux/MIPS
will some day have a HW independent hinv... - Ariel

----- Forwarded message from Dave Olson -----

>From olson@anchor  Mon May 12 13:50:21 1997
Date: Mon, 12 May 1997 13:50:18 -0700
From: olson@anchor (Dave Olson)
Message-Id: <199705122050.NAA26767@anchor.engr.sgi.com>
To: olson@anchor (Dave Olson), scotth@sgi.com
Subject: Re: missing machfile
Cc: swmgr@swmgr, breyer@swmgr, ariel@cthulhu
References: <199705121525.IAA23143@swmgr.engr.sgi.com>
    <199705121714.KAA23773@anchor.engr.sgi.com>
    <199705121854.LAA18312@anchor.engr.sgi.com>

|  I would assume that hinv is hardware-dependent, because of the
|  mapping issues?  Or is it table driven off of an analogue of the machtab?

Still all compiled in.  Bug/rfe open for years now about making it table
driven.

|  Unfortunately, nothing better is generally available across
|  platforms and releases.

Yes, and that's something that would be nice to fix.  Maybe linux will
do it, and we can copy them.

|  D> Lots, for any non-trivial app.  They don't have to, but often want to.
|  
|  ???  Non-trivial as in "big and powerful", or as in "gets close to
|  the hardware"?  I would argue that emacs and perl both fit the

Both/either.  Not all  big apps, of course.

|  I was looking at the options to uname, specifically "-p".  Based
|  upon the man page, shouldn't `uname -p` return "mips3" instead of
|  "mips" for my IP22?  That is one obvious meaning for:

Yes, but then you break even more of the configure scripts.  Again,
a no-win situation.

|  I was just curious is there was somehow we could make life easier
|  for configure scripts to port software for IRIX...  On the other
|  hand, we generally only get bad comments about /bin/install, and at
|  least we *don't* get comments like:

|  # AIX cpp loses on an empty file, so make sure it contains at least a newline.
Using cpp is a horrible solution...

|  It is hard to add functionality without breaking stuff.

A programmer's lament, if I ever heard one!

Dave Olson, Silicon Graphics   Guru and busybody at large
http://reality.sgi.com/olson   olson@sgi.com

----- End of forwarded message from Dave Olson -----

-- 
Peace, Ariel

hardware independent hinv

[Ariel Faigon]

Just forwarding since it sounds someone hopes that Linux/MIPS
will some day have a HW independent hinv... - Ariel

----- Forwarded message from Dave Olson -----

From olson@anchor  Mon May 12 13:50:21 1997
Date: Mon, 12 May 1997 13:50:18 -0700
From: olson@anchor (Dave Olson)
Message-Id: <199705122050.NAA26767@anchor.engr.sgi.com>
To: olson@anchor (Dave Olson), scotth@sgi.com
Subject: Re: missing machfile
Cc: swmgr@swmgr, breyer@swmgr, ariel@cthulhu
References: <199705121525.IAA23143@swmgr.engr.sgi.com>
    <199705121714.KAA23773@anchor.engr.sgi.com>
    <199705121854.LAA18312@anchor.engr.sgi.com>

|  I would assume that hinv is hardware-dependent, because of the
|  mapping issues?  Or is it table driven off of an analogue of the machtab?

Still all compiled in.  Bug/rfe open for years now about making it table
driven.

|  Unfortunately, nothing better is generally available across
|  platforms and releases.

Yes, and that's something that would be nice to fix.  Maybe linux will
do it, and we can copy them.

|  D> Lots, for any non-trivial app.  They don't have to, but often want to.
|  
|  ???  Non-trivial as in "big and powerful", or as in "gets close to
|  the hardware"?  I would argue that emacs and perl both fit the

Both/either.  Not all  big apps, of course.

|  I was looking at the options to uname, specifically "-p".  Based
|  upon the man page, shouldn't `uname -p` return "mips3" instead of
|  "mips" for my IP22?  That is one obvious meaning for:

Yes, but then you break even more of the configure scripts.  Again,
a no-win situation.

|  I was just curious is there was somehow we could make life easier
|  for configure scripts to port software for IRIX...  On the other
|  hand, we generally only get bad comments about /bin/install, and at
|  least we *don't* get comments like:

|  # AIX cpp loses on an empty file, so make sure it contains at least a newline.
Using cpp is a horrible solution...

|  It is hard to add functionality without breaking stuff.

A programmer's lament, if I ever heard one!

Dave Olson, Silicon Graphics   Guru and busybody at large
http://reality.sgi.com/olson   olson@sgi.com

----- End of forwarded message from Dave Olson -----

-- 
Peace, Ariel

Re: hardware independent hinv

[Mike Shaver]

Thus spake Ariel Faigon:
> Just forwarding since it sounds someone hopes that Linux/MIPS
> will some day have a HW independent hinv... - Ariel

Do they need more than the /proc stuff?
Larry has a perl version of hinv that reads from /proc/whatever, I
seem to recall.

Mike

-- 
#> Mike Shaver (shaver@ingenia.com) Ingenia Communications Corporation 
#>                   Welcome to the technocracy.
#>                                                                     
#> "you'd be so disappointed
#>              to find out that the magic was not
#>                          really meant for you" - OLP

Re: hardware independent hinv

[Ralf Baechle]

> Just forwarding since it sounds someone hopes that Linux/MIPS
> will some day have a HW independent hinv... - Ariel

Larry has shown me a perl script on his Linux/i386 box which does just
this.  I intend to supply the information required by such a script
via the proc filesystem.

  Ralf

> ----- Forwarded message from Dave Olson -----
> 
> >From olson@anchor  Mon May 12 13:50:21 1997
> Date: Mon, 12 May 1997 13:50:18 -0700
> From: olson@anchor (Dave Olson)
> Message-Id: <199705122050.NAA26767@anchor.engr.sgi.com>
> To: olson@anchor (Dave Olson), scotth@sgi.com
> Subject: Re: missing machfile
> Cc: swmgr@swmgr, breyer@swmgr, ariel@cthulhu
> References: <199705121525.IAA23143@swmgr.engr.sgi.com>
>     <199705121714.KAA23773@anchor.engr.sgi.com>
>     <199705121854.LAA18312@anchor.engr.sgi.com>
> 
> |  I would assume that hinv is hardware-dependent, because of the
> |  mapping issues?  Or is it table driven off of an analogue of the machtab?
> 
> Still all compiled in.  Bug/rfe open for years now about making it table
> driven.
> 
> |  Unfortunately, nothing better is generally available across
> |  platforms and releases.
> 
> Yes, and that's something that would be nice to fix.  Maybe linux will
> do it, and we can copy them.
> 
> |  D> Lots, for any non-trivial app.  They don't have to, but often want to.
> |  
> |  ???  Non-trivial as in "big and powerful", or as in "gets close to
> |  the hardware"?  I would argue that emacs and perl both fit the
> 
> Both/either.  Not all  big apps, of course.
> 
> |  I was looking at the options to uname, specifically "-p".  Based
> |  upon the man page, shouldn't `uname -p` return "mips3" instead of
> |  "mips" for my IP22?  That is one obvious meaning for:

Q: what exactly does that IP?? notation stand for?  Internal model names,
CPU modules, ???

> Yes, but then you break even more of the configure scripts.  Again,
> a no-win situation.

You're absolutely right.  For just that reason I changed the output for
little endian MIPS boxes from mipsel to mips a long time ago though
mipsel is logic when thinking of the generic GNU configuration names.

> |  I was just curious is there was somehow we could make life easier
> |  for configure scripts to port software for IRIX...  On the other
> |  hand, we generally only get bad comments about /bin/install, and at
> |  least we *don't* get comments like:

After the last few days I can say that porting to IRIX is a quite boring
job; most things just work.  Only ssh makes problem.  Solved by using
GCC (snapshot) instead of SGI's cc.

> Using cpp is a horrible solution...

Tell the people who invented imake ...

> |  It is hard to add functionality without breaking stuff.
> 
> A programmer's lament, if I ever heard one!

Or break what's broken ...

  Ralf

Re: hardware independent hinv

[Miguel de Icaza]

> > Just forwarding since it sounds someone hopes that Linux/MIPS
> > will some day have a HW independent hinv... - Ariel
> 
> Do they need more than the /proc stuff?
> Larry has a perl version of hinv that reads from /proc/whatever, I
> seem to recall.

Yesterday I went to see some guy running the University's new Origin
machine, and they showed me some monitoring tools on IRIX, very
impressive tools.  I want them on Linux :-).

There was this lovely tool that showed the memory map, with the
details on the usage.  You could click on say, Emacs, and get a map of
where Emacs pages were, and it seemed like it could read the symbol
table information from the process as well (it showed: "No symbols for
this page").

I also saw some printed slides on some program that seemed to let you
move related functions together in the binary to avoid page faults.
Can not really tell, as they were flipping trough them really quick.

I remember attending a presentation at Usenix where they talked about
this very feature.  This is something else we want in our binutils.

Miguel.

Re: hardware independent hinv

[David S. Miller]

   Date: Wed, 28 May 1997 12:42:17 -0500
   From: Miguel de Icaza <miguel@nuclecu.unam.mx>

   I also saw some printed slides on some program that seemed to let
   you move related functions together in the binary to avoid page
   faults.  Can not really tell, as they were flipping trough them
   really quick.

   I remember attending a presentation at Usenix where they talked
   about this very feature.  This is something else we want in our
   binutils.

The solaris dynamic linker does this at run time, it collapses
together only the functions/data which your program could ever
reference into one contiguous chunk of pages.  I haven't worked out
the complete set of details of how this is done completely at run
time, and efficiently as well, but I have spoken to Eric Youngdale and
other Linux userland experts about this trick.

Re: hardware independent hinv

[Larry McVoy]

: Just forwarding since it sounds someone hopes that Linux/MIPS
: will some day have a HW independent hinv... - Ariel

Here's my first pass at it.  It certainly isn't complete but it is a 
start.  We could evolve Linux' /proc to fully handle this.

#!/usr/bin/perl -w

# Try and emulate SGI's hinv command
# We want to figure out the following:
# CPU type, mhz, memory, busses, floppies, disks, tapes, cdroms, ttys,
# networks, graphics.

# indy ~ hinv
# Iris Audio Processor: version A2 revision 4.1.0
# 1 175 MHZ IP22 Processor
# FPU: MIPS R4000 Floating Point Coprocessor Revision: 0.0
# CPU: MIPS R4400 Processor Chip Revision: 6.0
# On-board serial ports: 2
# On-board bi-directional parallel port
# Data cache size: 16 Kbytes
# Instruction cache size: 16 Kbytes
# Secondary unified instruction/data cache size: 1 Mbyte on Processor 0
# Main memory size: 64 Mbytes
# Vino video: unit 0, revision 0
# Integral ISDN: Basic Rate Interface unit 0, revision 1.0
# XPI FDDI controller: xpi0, firmware version 9601221233, SAS
# Integral Ethernet: ec0, version 1
# Integral SCSI controller 0: Version WD33C93B, revision D
#  Disk drive: unit 2 on SCSI controller 0
#  Disk drive: unit 1 on SCSI controller 0
# Graphics board: Indy 24-bit

# i586 ~ hinv
# Main memory size: 24 Mbytes
# 1 GenuineIntel 586 processor
# 1 16450 serial port
# 2 16550A serial ports
# 1 post-1991 82077 floppy controller
# 1 1.44M floppy drive
# 1 vga+ graphics device
# 1 keyboard
# 2 ethernet interfaces
#   eth0: 3Com 3c595 Vortex 100baseTX
#   eth2: 3c509
# 1 SCSI tape 1 SCSI cdrom 2 SCSI disks
#   QUANTUM  EMPIRE_1080S
#   HP       C3725S
#   ARCHIVE  VIPER 150  21531
#   TOSHIBA  CD-ROM XM-3501TA
# PCI bus devices:
#    SCSI storage controller: NCR 53c810 (rev 2).
#    Ethernet controller: 3Com 3C595 100bTX (rev 0).
#    VGA compatible device: S3 Inc. Vision 964-P (rev 0).
#    IDE interface: Intel 82371 Triton PIIX (rev 2).
#    ISA bridge: Intel 82371 Triton PIIX (rev 2).
#    Host bridge: Intel 82437 (rev 2).

open(FD, "dmesg|") || die "no dmesg";
while (<FD>) {
	@_ = split;
	if (/^Memory:/) {
		$_[1] =~ s|.*/||;
		$_[1] =~ s|k$||;
		$_[1] /= 1024;
		$mem = "Main memory size: $_[1] Mbytes\n";
	} elsif (/^tty/) {
		$ttys{$_[$#_]}++;
	} elsif (/^Floppy/) {
		$floppy{$_[$#_]}++;
	} elsif (/^FDC /) {
		s/.*is a //;
		chop;
		$fdc{$_}++;
	} elsif (/^scsi : detected/) {
		$scsi = $_;
	} elsif (/^eth\d.* at /) {
		s/\s*at .*//;
		push(@eth, $_);
	} 
}
open(FD, "/proc/cpuinfo");
while (<FD>) {
	@_ = split;
	if (/cpu/) {
		$cpu = $_[$#_];
	}
	if (/vendor/) {
		$cpus{"$_[$#_] $cpu"}++;
	}
}
open(FD, "/proc/ioports");
while (<FD>) {
	if (/kbd/ || /keyboard/) {
		$kbd++;
	} elsif (/vga/) {
		@_ = split;
		$graphics{$_[$#_]}++;
	}
}

print $mem if (defined $mem);
foreach $key (keys %cpus) {
	print "$cpus{$key} $key processor";
	print $cpus{$key} > 1 ? "s\n" : "\n";
}
foreach $key (keys %ttys) {
	print "$ttys{$key} $key serial port";
	print $ttys{$key} > 1 ? "s\n" : "\n";
}
foreach $key (keys %fdc) {
	print "$fdc{$key} $key floppy controller";
	print $fdc{$key} > 1 ? "s\n" : "\n";
}
foreach $key (keys %floppy) {
	print "$floppy{$key} $key floppy drive";
	print $floppy{$key} > 1 ? "s\n" : "\n";
}
foreach $key (keys %graphics) {
	print "$graphics{$key} $key graphics device";
	print $graphics{$key} > 1 ? "s\n" : "\n";
}
if (defined $kbd) {
	print "$kbd keyboard";
	print $kbd > 1 ? "s\n" : "\n";
}
if ($#eth > -1) {
	$n = $#eth + 1;
	print "$n ethernet interface";
	print $n > 1 ? "s\n" : "\n";
	foreach $eth (@eth) {
		print "  $eth";
	}
}
if (defined $scsi) {
	$scsi =~ s/.*detected //;
	$scsi =~ s/ total.//;
	print $scsi;
	open(FD, "/proc/scsi/scsi");
	$_ = <FD>;
	while (<FD>) {
		next unless /Vendor/;
		s/.*Vendor:\s*//;
		s/\s*Rev:.*//;
		s/Model:\s*//;
		print "  $_";
	}
}

open(FD, "/proc/pci");
$done = 0;
while (<FD>) {
	if (/^\s*Bus/) {
		if ($done == 0) {
			print "PCI bus devices:\n";
			$done++;
		}
		$_ = <FD>;
		print;
	}
}

Re: hardware independent hinv

[Larry McVoy]

: Just forwarding since it sounds someone hopes that Linux/MIPS
: will some day have a HW independent hinv... - Ariel

Here's my first pass at it.  It certainly isn't complete but it is a 
start.  We could evolve Linux' /proc to fully handle this.

#!/usr/bin/perl -w

# Try and emulate SGI's hinv command
# We want to figure out the following:
# CPU type, mhz, memory, busses, floppies, disks, tapes, cdroms, ttys,
# networks, graphics.

# indy ~ hinv
# Iris Audio Processor: version A2 revision 4.1.0
# 1 175 MHZ IP22 Processor
# FPU: MIPS R4000 Floating Point Coprocessor Revision: 0.0
# CPU: MIPS R4400 Processor Chip Revision: 6.0
# On-board serial ports: 2
# On-board bi-directional parallel port
# Data cache size: 16 Kbytes
# Instruction cache size: 16 Kbytes
# Secondary unified instruction/data cache size: 1 Mbyte on Processor 0
# Main memory size: 64 Mbytes
# Vino video: unit 0, revision 0
# Integral ISDN: Basic Rate Interface unit 0, revision 1.0
# XPI FDDI controller: xpi0, firmware version 9601221233, SAS
# Integral Ethernet: ec0, version 1
# Integral SCSI controller 0: Version WD33C93B, revision D
#  Disk drive: unit 2 on SCSI controller 0
#  Disk drive: unit 1 on SCSI controller 0
# Graphics board: Indy 24-bit

# i586 ~ hinv
# Main memory size: 24 Mbytes
# 1 GenuineIntel 586 processor
# 1 16450 serial port
# 2 16550A serial ports
# 1 post-1991 82077 floppy controller
# 1 1.44M floppy drive
# 1 vga+ graphics device
# 1 keyboard
# 2 ethernet interfaces
#   eth0: 3Com 3c595 Vortex 100baseTX
#   eth2: 3c509
# 1 SCSI tape 1 SCSI cdrom 2 SCSI disks
#   QUANTUM  EMPIRE_1080S
#   HP       C3725S
#   ARCHIVE  VIPER 150  21531
#   TOSHIBA  CD-ROM XM-3501TA
# PCI bus devices:
#    SCSI storage controller: NCR 53c810 (rev 2).
#    Ethernet controller: 3Com 3C595 100bTX (rev 0).
#    VGA compatible device: S3 Inc. Vision 964-P (rev 0).
#    IDE interface: Intel 82371 Triton PIIX (rev 2).
#    ISA bridge: Intel 82371 Triton PIIX (rev 2).
#    Host bridge: Intel 82437 (rev 2).

open(FD, "dmesg|") || die "no dmesg";
while (<FD>) {
	@_ = split;
	if (/^Memory:/) {
		$_[1] =~ s|.*/||;
		$_[1] =~ s|k$||;
		$_[1] /= 1024;
		$mem = "Main memory size: $_[1] Mbytes\n";
	} elsif (/^tty/) {
		$ttys{$_[$#_]}++;
	} elsif (/^Floppy/) {
		$floppy{$_[$#_]}++;
	} elsif (/^FDC /) {
		s/.*is a //;
		chop;
		$fdc{$_}++;
	} elsif (/^scsi : detected/) {
		$scsi = $_;
	} elsif (/^eth\d.* at /) {
		s/\s*at .*//;
		push(@eth, $_);
	} 
}
open(FD, "/proc/cpuinfo");
while (<FD>) {
	@_ = split;
	if (/cpu/) {
		$cpu = $_[$#_];
	}
	if (/vendor/) {
		$cpus{"$_[$#_] $cpu"}++;
	}
}
open(FD, "/proc/ioports");
while (<FD>) {
	if (/kbd/ || /keyboard/) {
		$kbd++;
	} elsif (/vga/) {
		@_ = split;
		$graphics{$_[$#_]}++;
	}
}

print $mem if (defined $mem);
foreach $key (keys %cpus) {
	print "$cpus{$key} $key processor";
	print $cpus{$key} > 1 ? "s\n" : "\n";
}
foreach $key (keys %ttys) {
	print "$ttys{$key} $key serial port";
	print $ttys{$key} > 1 ? "s\n" : "\n";
}
foreach $key (keys %fdc) {
	print "$fdc{$key} $key floppy controller";
	print $fdc{$key} > 1 ? "s\n" : "\n";
}
foreach $key (keys %floppy) {
	print "$floppy{$key} $key floppy drive";
	print $floppy{$key} > 1 ? "s\n" : "\n";
}
foreach $key (keys %graphics) {
	print "$graphics{$key} $key graphics device";
	print $graphics{$key} > 1 ? "s\n" : "\n";
}
if (defined $kbd) {
	print "$kbd keyboard";
	print $kbd > 1 ? "s\n" : "\n";
}
if ($#eth > -1) {
	$n = $#eth + 1;
	print "$n ethernet interface";
	print $n > 1 ? "s\n" : "\n";
	foreach $eth (@eth) {
		print "  $eth";
	}
}
if (defined $scsi) {
	$scsi =~ s/.*detected //;
	$scsi =~ s/ total.//;
	print $scsi;
	open(FD, "/proc/scsi/scsi");
	$_ = <FD>;
	while (<FD>) {
		next unless /Vendor/;
		s/.*Vendor:\s*//;
		s/\s*Rev:.*//;
		s/Model:\s*//;
		print "  $_";
	}
}

open(FD, "/proc/pci");
$done = 0;
while (<FD>) {
	if (/^\s*Bus/) {
		if ($done == 0) {
			print "PCI bus devices:\n";
			$done++;
		}
		$_ = <FD>;
		print;
	}
}

Re: hardware independent hinv

[Mike Shaver]

Thus spake Larry McVoy:
> : Just forwarding since it sounds someone hopes that Linux/MIPS
> : will some day have a HW independent hinv... - Ariel
> 
> Here's my first pass at it.  It certainly isn't complete but it is a 
> start.  We could evolve Linux' /proc to fully handle this.

What about a perl (SGI::?)Hinv:: module that would get hinv data from the
appropriate source?  I've been thinking about a clean perl interface
to /proc for a while, and I assume the data's there for the taking on
the Irixen as well, if you know where to look.  (open("hinv|") is all
else fails.)

Mike

-- 
#> Mike Shaver (shaver@ingenia.com) Ingenia Communications Corporation 
#>                 Ignore the man behind the curtain.                  
#>                                                                     
#> "And then I realized that it never should have worked in the first  
#>  place.  Thus, it would not work again until rewritten." --- Anon.  

Re: hardware independent hinv

[Mike Shaver]

Thus spake Larry McVoy:
> : Just forwarding since it sounds someone hopes that Linux/MIPS
> : will some day have a HW independent hinv... - Ariel
> 
> Here's my first pass at it.  It certainly isn't complete but it is a 
> start.  We could evolve Linux' /proc to fully handle this.

What about a perl (SGI::?)Hinv:: module that would get hinv data from the
appropriate source?  I've been thinking about a clean perl interface
to /proc for a while, and I assume the data's there for the taking on
the Irixen as well, if you know where to look.  (open("hinv|") is all
else fails.)

Mike

-- 
#> Mike Shaver (shaver@ingenia.com) Ingenia Communications Corporation 
#>                 Ignore the man behind the curtain.                  
#>                                                                     
#> "And then I realized that it never should have worked in the first  
#>  place.  Thus, it would not work again until rewritten." --- Anon.  

Re: hardware independent hinv

[Miguel de Icaza]

> The solaris dynamic linker does this at run time, it collapses
> together only the functions/data which your program could ever
> reference into one contiguous chunk of pages.  

Mhm, you mean, it moves the functions and data around?  This looks
interesting.  How does the Solaris linker find this out?

On the presentation at Usenix, they used feed the profiling
information into this executable-reorganizer program and the output
was this "optimized" executable.

Actually, I just found the program, from the cord(1) man page: 

     In the example below, a program foo is run through pixie(1) which
     generates foo.pixie.  The instrumented executable is run and prof is used
     to produce a feedback file from the profiled data.  Cord is then used to
     reorder the procedures in foo, generating a new binary foo.cord.

            pixie foo
            foo.pixie
            prof -pixie -feedback foo
            cord foo foo.fb

Pretty cool.

In the paper they presented some other optimizations to dynamically
linked programs.  Let me see if I can get the paper from the Usenix
site.

Cheers,
Miguel.

Re: hardware independent hinv

[Dave Olson]

The info definitely isn't in /proc on irix.

Doesn't dmesg have the problem on linux that it has on Sun systems; that is,
it only works until enough kernel printfs have happened that the circular
buffer wraps?

Dave Olson, Silicon Graphics   Guru and busybody at large
http://reality.sgi.com/olson   olson@sgi.com

Re: hardware independent hinv

[Dave Olson]

The info definitely isn't in /proc on irix.

Doesn't dmesg have the problem on linux that it has on Sun systems; that is,
it only works until enough kernel printfs have happened that the circular
buffer wraps?

Dave Olson, Silicon Graphics   Guru and busybody at large
http://reality.sgi.com/olson   olson@sgi.com

Re: hardware independent hinv

[Martin Knoblauch]

Miguel de Icaza wrote:
> 
> 
> There was this lovely tool that showed the memory map, with the
> details on the usage.  You could click on say, Emacs, and get a map of
> where Emacs pages were, and it seemed like it could read the symbol
> table information from the process as well (it showed: "No symbols for
> this page").
> 

 That would be "gmemusage" (in a former life "bloatview", with
some really cool desktop icons. Maybe for Linux, we could replace
the pigs with a real fat penguin :-).

> I also saw some printed slides on some program that seemed to let you
> move related functions together in the binary to avoid page faults.
> Can not really tell, as they were flipping trough them really quick.
> 

 That tool is "cord". It uses feedback from prof/pixie experiments.

Martin
-- 
Check out the DevForum 97  !!!! (http://www.sgi.com/Forum97/)
  If you miss it, you'll never forgive yourself. Neither will I :-)
+---------------------------------+-----------------------------------+
|Martin Knoblauch                 | Silicon Graphics GmbH             |
|Manager Technical Marketing      | Am Hochacker 3 - Technopark       |
|Silicon Graphics Computer Systems| D-85630 Grasbrunn-Neukeferloh, FRG|
|---------------------------------| Phone: (+int) 89 46108-179 or -0  |
|http://reality.sgi.com/knobi     | Fax:   (+int) 89 46107-179        |
+---------------------------------+-----------------------------------+
|e-mail: <knobi@munich.sgi.com>   | VM: 6-333-8197 | M/S: IDE-3150    |
+---------------------------------------------------------------------+

Re: hardware independent hinv

[Raj Mathur]

>>>>> "Dave" == Dave Olson <olson@anchor.engr.sgi.com> writes:

    Dave> The info definitely isn't in /proc on irix.  Doesn't dmesg
    Dave> have the problem on linux that it has on Sun systems; that
    Dave> is, it only works until enough kernel printfs have happened
    Dave> that the circular buffer wraps?

Yes, just define a printer, (don't need to actually connect one) and
lpr a file. End Of Dmesg(tm) usable output: all you'll get now is "lp:
out of paper" messages.

-- Raju
--
       Raj Mathur / Web Technical Support / Silicon Graphics / New Delhi
         +91-11-6216324/25, 6211354/55   /    raju@sgi.com  / 7228
            http://reality.sgi.com/raju / It is the Mind that Moves
           PGP: F2 D4 4A 21 27 B0 63 FF | Not necessarily speaking
                15 97 9D AE 9D 40 BC B8 | for Silicon Graphics

Re: hardware independent hinv

[Raj Mathur]

>>>>> "Dave" == Dave Olson <olson@anchor.engr.sgi.com> writes:

    Dave> The info definitely isn't in /proc on irix.  Doesn't dmesg
    Dave> have the problem on linux that it has on Sun systems; that
    Dave> is, it only works until enough kernel printfs have happened
    Dave> that the circular buffer wraps?

Yes, just define a printer, (don't need to actually connect one) and
lpr a file. End Of Dmesg(tm) usable output: all you'll get now is "lp:
out of paper" messages.

-- Raju
--
       Raj Mathur / Web Technical Support / Silicon Graphics / New Delhi
         +91-11-6216324/25, 6211354/55   /    raju@sgi.com  / 7228
            http://reality.sgi.com/raju / It is the Mind that Moves
           PGP: F2 D4 4A 21 27 B0 63 FF | Not necessarily speaking
                15 97 9D AE 9D 40 BC B8 | for Silicon Graphics

My first project on the Indy.

[Miguel de Icaza]

Hello guys,

   I got my Indy up and running now.  My very first project would be
to work on the Linux boot loader.

   I just happily found that there are two disks on the machine, so I
will smash the second one with my boot loader tests.  

   Now, where can I find information about the boot process on the
SGI?  I want to know what does the PROM load from the disk (I bet it
loads the first sectors and jumps to them, right?), and where the code
is loaded.  

   I happilly found that a program called Insight Library comes with
the system and has a lot of information on using the PROM, which is
what I am reading now to find out any debugging facilities in there.

   Some time ago, (maybe Larry or Ariel) mentioned that it would be
possible to get me a copy of the boot loader for Irix.

Cheers,
Miguel.