Problem with PMAD-AA / DECStation 5000/200

Problem with PMAD-AA / DECStation 5000/200

[Armin F. Gnosa]

I'm owning a DECStation mentioned in the subject. It has
only one flaw: The Firmware-EPROM of the on-board PMAD-AA
Ethernet adapter has become amnesic. So is there anyone who
can read out his EPROM and send me an image so that I can
finally boot Linux from the net? The version was 5.3a

Many Thanks in advance
Armin

Problem with PMAD-AA / DECStation 5000/200

[Armin F. Gnosa]

I'm owning a DECStation mentioned in the subject. It has
only one flaw: The Firmware-EPROM of the on-board PMAD-AA
Ethernet adapter has become amnesic. So is there anyone who
can read out his EPROM and send me an image so that I can
finally boot Linux from the net? The version was 5.3a

Many Thanks in advance
Armin

Re: Problem with PMAD-AA / DECStation 5000/200

[Florian Lohoff]

On Thu, Aug 09, 2001 at 05:35:42PM +0200, Armin F. Gnosa wrote:
> I'm owning a DECStation mentioned in the subject. It has
> only one flaw: The Firmware-EPROM of the on-board PMAD-AA
> Ethernet adapter has become amnesic. So is there anyone who
> can read out his EPROM and send me an image so that I can
> finally boot Linux from the net? The version was 5.3a

If anyone can read out different proms i would happy to put them
somewhere on the net.  I guess the Dec/Compaq whoever guys who might
own the copyright dont bother after at least 10-15 years. There are
proms who are not able to boot from the net which could be solved just
by burning a new eprom.

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
     Why is it called "common sense" when nobody seems to have any?

Re: Problem with PMAD-AA / DECStation 5000/200

[Jan-Benedict Glaw]

On Thu, 2001-08-09 17:51:31 +0200, Florian Lohoff <flo@rfc822.org>
wrote in message <20010809175131.D30160@paradigm.rfc822.org>:
> On Thu, Aug 09, 2001 at 05:35:42PM +0200, Armin F. Gnosa wrote:
> > I'm owning a DECStation mentioned in the subject. It has
> > only one flaw: The Firmware-EPROM of the on-board PMAD-AA
> > Ethernet adapter has become amnesic. So is there anyone who
> > can read out his EPROM and send me an image so that I can
> > finally boot Linux from the net? The version was 5.3a
> 
> If anyone can read out different proms i would happy to put them
> somewhere on the net.  I guess the Dec/Compaq whoever guys who might
> own the copyright dont bother after at least 10-15 years. There are
> proms who are not able to boot from the net which could be solved just
> by burning a new eprom.

I volunteer to provide all PROMs I can find @home. However, someone
has to read them as I don't have an EPROM burner:-(

Btw... Is it possible to make some machines tftp boot (instead of
crappy/nonfunctional MOP booting?)

MfG, JBG

Re: Problem with PMAD-AA / DECStation 5000/200

[Martin Schulze]

Jan-Benedict Glaw wrote:
> I volunteer to provide all PROMs I can find @home. However, someone
> has to read them as I don't have an EPROM burner:-(
> 
> Btw... Is it possible to make some machines tftp boot (instead of
> crappy/nonfunctional MOP booting?)

After "updating" their prom's, that should be possible, I guess.

Regards,

	Joey

-- 
No question is too silly to ask, but, of course, some are too silly
to answer.   -- Perl book

Re: Problem with PMAD-AA / DECStation 5000/200

[Jan-Benedict Glaw]

On Thu, 2001-08-09 18:22:58 +0200, Martin Schulze <joey@finlandia.infodrom.north.de>
wrote in message <20010809182258.W27458@finlandia.infodrom.north.de>:
> Jan-Benedict Glaw wrote:
> > I volunteer to provide all PROMs I can find @home. However, someone
> > has to read them as I don't have an EPROM burner:-(
> > 
> > Btw... Is it possible to make some machines tftp boot (instead of
> > crappy/nonfunctional MOP booting?)
> 
> After "updating" their prom's, that should be possible, I guess.

I'm not that sure. Does there always exist a "clean" PROM? For
example, I'm searching for a tftp/bootp enabled PROM for a
DEC 5000/240 (or was it /200?). Does anybody have sth like this?

MfG, JBG

Problems mounting RedHat 7.0 or 7.1 from oss.sgi site

[Wayne Gowcher]

I have tried unsuccessfully to use the root
filesystems
mipselroot-rh7-20010606.tar.bz2
and H.J.Lu's RedHat 7.1 install from the sgi ftp site.

Both give me warnings immeadiately about the files
they are trying to access :

INIT: version 2.78 booting
/etc/rc.sysinit: .: /etc/sysconfig/network: not a
regular file
/etc/rc.sysinit: .: /etc/init.d/functions: not a
regular file
                        Welcome to Red Hat Linux
                Press 'I' to enter interactive
startup.

If I then boot either with 

init=/bin/bash rw 

and use 'ls' without any parameters 'ls' warns :

bash-2.04# ls
ls: .: Invalid argument

Using ls * will give a file listing if the directory
contains any files. But the file info is totally hosed
eg from /etc:

?--------x    0 0        root           17 Jul 23 
2000 host.conf
?--------x    0 0        root          161 Jan 12 
2000 hosts.allow
?--------x    0 0        root          347 Jan 12 
2000 hosts.deny
?--------x    0 0        root          754 Feb 24
11:57 info-dir
?

I am using a 2.4.2 kernel that boots successfully when
using the RedHat 5.1 distribution also found on the
SGI site.

My tools are :
egcs-mipsel-linux-1.1.2-4.i386.rpm
binutils-mipsel-linux-2.8.1-2.i386.rpm

Any ideas as to what I am doing wrong would be
appreciated

Compiler ? Glibc ? ???

Wayne



__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

Re: Problems mounting RedHat 7.0 or 7.1 from oss.sgi site

[H . J . Lu]

On Thu, Aug 09, 2001 at 05:29:37PM -0700, Wayne Gowcher wrote:
> I have tried unsuccessfully to use the root
> filesystems
> mipselroot-rh7-20010606.tar.bz2
> and H.J.Lu's RedHat 7.1 install from the sgi ftp site.
> 
> Both give me warnings immeadiately about the files
> they are trying to access :
> 

Your kernel is very old. You have to have kernel 2.4.3 or above to use
mine stuff.


H.J.

Re: Problem with PMAD-AA / DECStation 5000/200

[Armin F. Gnosa]

> If anyone can read out different proms i would happy to put them
> somewhere on the net.  I guess the Dec/Compaq whoever guys who might
> own the copyright dont bother after at least 10-15 years. There are
> proms who are not able to boot from the net which could be solved just
> by burning a new eprom.

That would certainly be an interesting institution to which I would
contribute, but for the sake if the webmaster those copyright matters 
have to be cleared before. :-)

Re: Problem with PMAD-AA / DECStation 5000/200

[Armin F. Gnosa]

> If anyone can read out different proms i would happy to put them
> somewhere on the net.  I guess the Dec/Compaq whoever guys who might
> own the copyright dont bother after at least 10-15 years. There are
> proms who are not able to boot from the net which could be solved just
> by burning a new eprom.

That would certainly be an interesting institution to which I would
contribute, but for the sake if the webmaster those copyright matters 
have to be cleared before. :-)

Re: Problem with PMAD-AA / DECStation 5000/200

[Maciej W. Rozycki]

On Thu, 9 Aug 2001, Jan-Benedict Glaw wrote:

> I'm not that sure. Does there always exist a "clean" PROM? For
> example, I'm searching for a tftp/bootp enabled PROM for a
> DEC 5000/240 (or was it /200?). Does anybody have sth like this?

 Look at 'http://www.netbsd.org/Ports/pmax/board-list.html'.  They list MB
ROMs only, though.  Note that certain options (FDDI controllers) have a
Flash ROM that is soldered to the PCB, so they can only be updated via
appropriate software. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: Problem with PMAD-AA / DECStation 5000/200

[Jan-Benedict Glaw]

On Fri, 2001-08-10 11:00:40 +0200, Maciej W. Rozycki <macro@ds2.pg.gda.pl>
wrote in message <Pine.GSO.3.96.1010810105208.2724E-100000@delta.ds2.pg.gda.pl>:
> On Thu, 9 Aug 2001, Jan-Benedict Glaw wrote:
> 
> > I'm not that sure. Does there always exist a "clean" PROM? For
> > example, I'm searching for a tftp/bootp enabled PROM for a
> > DEC 5000/240 (or was it /200?). Does anybody have sth like this?
> 
>  Look at 'http://www.netbsd.org/Ports/pmax/board-list.html'.  They list MB
> ROMs only, though.  Note that certain options (FDDI controllers) have a
> Flash ROM that is soldered to the PCB, so they can only be updated via
> appropriate software. 

Or via a soldering iron:-) I don't fear using it, but currently
I don't own an EPROM burner:-(

MfG, JBG

Re: Problem with PMAD-AA / DECStation 5000/200

[Maciej W. Rozycki]

On Thu, 9 Aug 2001, Jan-Benedict Glaw wrote:

> I volunteer to provide all PROMs I can find @home. However, someone
> has to read them as I don't have an EPROM burner:-(

 I'm not sure how exactly the ROMs are wired (they're usually 8-bit); 
hopefully in a "natural" way.  You can read most of ROMs under Linux via
mmap()ping /dev/mem -- parts of ROMs may not be directly available to the
host CPU if they contain option's CPU firmware.  The MB ROM is remapped
(byte-merged) by the chipset so that it can be read in 32-bit quantities
as parts of it get executed directly (the I/O ASIC permits switching the
byte merging off).  Option ROMs are not remapped as they always get copied
to the system RAM before execution.  Their organization can be read from
their headers as specified by the TURBOchannel firmware specification.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: Problem with PMAD-AA / DECStation 5000/200

[Florian Lohoff]

On Fri, Aug 10, 2001 at 10:54:46AM +0200, Armin F. Gnosa wrote:
> 
> That would certainly be an interesting institution to which I would
> contribute, but for the sake if the webmaster those copyright matters 
> have to be cleared before. :-)
> 

As i said - I dont think anyone cares - I dont think anyone is able
to tell who is the current copyright holder for the Decstation stuff so 
- sue me ...

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
     Why is it called "common sense" when nobody seems to have any?

Re: Problem with PMAD-AA / DECStation 5000/200

[Armin F. Gnosa]

>  I'm not sure how exactly the ROMs are wired (they're usually 8-bit);
> hopefully in a "natural" way.  You can read most of ROMs under Linux via
> mmap()ping /dev/mem -- parts of ROMs may not be directly available to the
> host CPU if they contain option's CPU firmware.  The MB ROM is remapped
> (byte-merged) by the chipset so that it can be read in 32-bit quantities
> as parts of it get executed directly (the I/O ASIC permits switching the
> byte merging off).  Option ROMs are not remapped as they always get copied
> to the system RAM before execution.  Their organization can be read from
> their headers as specified by the TURBOchannel firmware specification.

That sounds like an interesting alternative to pulling the PROM out of
its socket. Then, a program running on a DECStation 5000/200 should be
reading from 0x1F81C0000..0x1F1FFFFF, right? One question about Byte
Merging: Does it mean that I don't have to read bytewise but instead
DWORD-wise?

Regards,
Armin

Re: Problem with PMAD-AA / DECStation 5000/200

[Armin F. Gnosa]

>  I'm not sure how exactly the ROMs are wired (they're usually 8-bit);
> hopefully in a "natural" way.  You can read most of ROMs under Linux via
> mmap()ping /dev/mem -- parts of ROMs may not be directly available to the
> host CPU if they contain option's CPU firmware.  The MB ROM is remapped
> (byte-merged) by the chipset so that it can be read in 32-bit quantities
> as parts of it get executed directly (the I/O ASIC permits switching the
> byte merging off).  Option ROMs are not remapped as they always get copied
> to the system RAM before execution.  Their organization can be read from
> their headers as specified by the TURBOchannel firmware specification.

That sounds like an interesting alternative to pulling the PROM out of
its socket. Then, a program running on a DECStation 5000/200 should be
reading from 0x1F81C0000..0x1F1FFFFF, right? One question about Byte
Merging: Does it mean that I don't have to read bytewise but instead
DWORD-wise?

Regards,
Armin

Re: Problem with PMAD-AA / DECStation 5000/200

[Ralf Baechle]

On Fri, Aug 10, 2001 at 12:33:58PM +0200, Florian Lohoff wrote:

> > That would certainly be an interesting institution to which I would
> > contribute, but for the sake if the webmaster those copyright matters 
> > have to be cleared before. :-)
> > 
> 
> As i said - I dont think anyone cares - I dont think anyone is able
> to tell who is the current copyright holder for the Decstation stuff so 
> - sue me ...

No problem.  There is a company who bought all right of DEC is now making
some money by supporting those systems.

  Ralf

Re: Problem with PMAD-AA / DECStation 5000/200

[Armin F. Gnosa]

> > As i said - I dont think anyone cares - I dont think anyone is able
> > to tell who is the current copyright holder for the Decstation stuff so
> > - sue me ...
>
> No problem.  There is a company who bought all right of DEC is now making
> some money by supporting those systems.

So, at least for the worst case, I can still buy a new EPROM there...

Regards,
Armin

Re: Problem with PMAD-AA / DECStation 5000/200

[Armin F. Gnosa]

> > As i said - I dont think anyone cares - I dont think anyone is able
> > to tell who is the current copyright holder for the Decstation stuff so
> > - sue me ...
>
> No problem.  There is a company who bought all right of DEC is now making
> some money by supporting those systems.

So, at least for the worst case, I can still buy a new EPROM there...

Regards,
Armin

Re: Problem with PMAD-AA / DECStation 5000/200

[Jan-Benedict Glaw]

On Sun, 2001-08-12 22:32:19 +0200, Ralf Baechle <ralf@oss.sgi.com>
wrote in message <20010812223219.B21308@bacchus.dhis.org>:
> On Fri, Aug 10, 2001 at 12:33:58PM +0200, Florian Lohoff wrote:
> > > That would certainly be an interesting institution to which I would
> > > contribute, but for the sake if the webmaster those copyright matters 
> > > have to be cleared before. :-)
> > As i said - I dont think anyone cares - I dont think anyone is able
> > to tell who is the current copyright holder for the Decstation stuff so 
> > - sue me ...
> No problem.  There is a company who bought all right of DEC is now making
> some money by supporting those systems.

"No problem - let's sue Flo"	-or-
"No problem - noone will sue anybody"

If you've heared of that company (which will support those old
machines), maybe they're willung to work with us? They've maybe
got all legal rights to software/documentation/thousands of
kilometers of tape archives, but we're (partially) really
working with these machines. So maybe we've got some know-how
in practical terms which they maybe do not have...

MfG, JBG

-- 
Jan-Benedict Glaw . jbglaw@lug-owl.de . +49-172-7608481

Re: Problem with PMAD-AA / DECStation 5000/200

[Ralf Baechle]

On Sun, Aug 12, 2001 at 10:41:59PM +0200, Jan-Benedict Glaw wrote:

> If you've heared of that company (which will support those old
> machines), maybe they're willung to work with us? They've maybe
> got all legal rights to software/documentation/thousands of
> kilometers of tape archives, but we're (partially) really
> working with these machines. So maybe we've got some know-how
> in practical terms which they maybe do not have...

It's not exactly the name of a company I'd consider important enough to
dedicate the surface of a a slip of paper to it's name, so sorry, I
don't have it's name at hand.  Ask Compaq.

  Ralf

Re: Problem with PMAD-AA / DECStation 5000/200

[Maciej W. Rozycki]

On Fri, 10 Aug 2001, Armin F. Gnosa wrote:

> That sounds like an interesting alternative to pulling the PROM out of
> its socket. Then, a program running on a DECStation 5000/200 should be
> reading from 0x1F81C0000..0x1F1FFFFF, right? One question about Byte
> Merging: Does it mean that I don't have to read bytewise but instead
> DWORD-wise?

 The system ROM is mapped from 0x1f800000 up to 0x1f83fffff (and repeated
at 0x1fc00000) and is 256kB in size on my /240.

 Although I cannot verify it, docs state that the /200 contains the
following ROMs:

- the system ROM from 0x1fc00000 up to 0x1fc7ffff (repeated at
0x1ff80000), 256kB in size,

- the PMAD-A ROM from 0x1f9c0000 up to 0x1f9fffff, 32kB in size,

- the PMAZ-A ROM from 0x1f4c0000 up to 0x1f4fffff, 32kB in size. 

 The system ROMs are presented on the whole data bus, while the option
ROMs are only presented on 8 least significant bits.  The merging can be
switched off for I/O ASIC systems (I haven't tested the exact behaviour of
this configuration) but it seems to be hardwired for the /200.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Benchmark performance

[Wayne Gowcher]

I have been running the nbench-byte-2.1 benchmark on a
mips r4k processor with various combinations of kernel
and distribution packages. I initially started with a
2.4.2 kernel using the redhat 5.1 distribution found
on the SGI mips site. I compiled nbench native on the
target with redhat mounted via nfs. I used this as my
base.

I then ran a 2.4.6 kernel on the same mips 4k
processor, but this time with the redhat 7.0
distribution. I compiled native using the
distributions compiler. This resulted in :

a 3 % reduction in the Memory Index benchmark
a 2 % increase in the Integer Index benchmark
a 23 % reduction in the Floating Point Index benchmark


Using the same 2.4.6 kernel on the same mips 4k
processor, with the redhat 7.1 distribution (compiling
native with the distribution's compiler ) I got :

a 5.7 % reduction in the Memory Index benchmark
a 1.5 % reduction in the Integer Index benchmark
a 27 % reduction in the Floating point Index benchmark

Also as a test I ran the redhat 5.1 native compiled
nbench executable on the 2.4.6 / redhat 7.0 setup and
again saw reduced performance :

a 4.8 % reduction in the Memory Index benchmark
a 1.5 % increase in the Integer Index benchmark
a 26  % reduction in the floating point benchmark

Although I tried various compiler switches to acheive
the highest index I could on a per kernel / per
distribution basis ( they weren't always the same ).
My basic CFLAGS settings were :

CFLAGS = -s -static -Wall -O2 -fomit-frame-pointer
-funroll-all-loops -mips2 -finline-functions.


>From the above tests it seems that newer does not in
fact mean faster. I can only speculate as to why, and
so I would appreciate hearing from anyone who :

a, has suggestions on how to optimize compiler
performance.

b, may know why performance seems to degrade with a
newer kernel and with a newer distribution ? newer
compiler ?

c, any other tips for improving kernel / application
performance.

Wayne

__________________________________________________
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/

Benchmark performance

[Wayne Gowcher]

I have been running the nbench-byte-2.1 benchmark on a
mips r4k processor with various combinations of kernel
and distribution packages. I initially started with a
2.4.2 kernel using the redhat 5.1 distribution found
on the SGI mips site. I compiled nbench native on the
target with redhat mounted via nfs. I used this as my
base.

I then ran a 2.4.6 kernel on the same mips 4k
processor, but this time with the redhat 7.0
distribution. I compiled native using the
distributions compiler. This resulted in :

a 3 % reduction in the Memory Index benchmark
a 2 % increase in the Integer Index benchmark
a 23 % reduction in the Floating Point Index benchmark


Using the same 2.4.6 kernel on the same mips 4k
processor, with the redhat 7.1 distribution (compiling
native with the distribution's compiler ) I got :

a 5.7 % reduction in the Memory Index benchmark
a 1.5 % reduction in the Integer Index benchmark
a 27 % reduction in the Floating point Index benchmark

Also as a test I ran the redhat 5.1 native compiled
nbench executable on the 2.4.6 / redhat 7.0 setup and
again saw reduced performance :

a 4.8 % reduction in the Memory Index benchmark
a 1.5 % increase in the Integer Index benchmark
a 26  % reduction in the floating point benchmark

Although I tried various compiler switches to acheive
the highest index I could on a per kernel / per
distribution basis ( they weren't always the same ).
My basic CFLAGS settings were :

CFLAGS = -s -static -Wall -O2 -fomit-frame-pointer
-funroll-all-loops -mips2 -finline-functions.


From the above tests it seems that newer does not in
fact mean faster. I can only speculate as to why, and
so I would appreciate hearing from anyone who :

a, has suggestions on how to optimize compiler
performance.

b, may know why performance seems to degrade with a
newer kernel and with a newer distribution ? newer
compiler ?

c, any other tips for improving kernel / application
performance.

Wayne

__________________________________________________
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/

Re: Benchmark performance

[Ralf Baechle]

On Mon, Aug 13, 2001 at 10:34:46AM -0700, Wayne Gowcher wrote:

> I have been running the nbench-byte-2.1 benchmark on a
> mips r4k processor with various combinations of kernel
> and distribution packages. I initially started with a
> 2.4.2 kernel using the redhat 5.1 distribution found
> on the SGI mips site. I compiled nbench native on the
> target with redhat mounted via nfs. I used this as my
> base.
> 
> I then ran a 2.4.6 kernel on the same mips 4k
> processor, but this time with the redhat 7.0
> distribution. I compiled native using the
> distributions compiler. This resulted in :
> 
> a 3 % reduction in the Memory Index benchmark
> a 2 % increase in the Integer Index benchmark
> a 23 % reduction in the Floating Point Index benchmark

Small fluctuations in the range of 2 or 3 percent are usually explained
by a changing usage pattern of the caches.  Therefore rerunning a the
benchmarks is a good idea.  Especially microbenchmarks a la lmbench on
caches of low associativity like the direct mapped R4k caches are extremly
easily affected by cache usage patterns.

Did you get any kernel messages during the Floating Point Index benchmark
on the older kernel?

> a, has suggestions on how to optimize compiler
> performance.
> 
> b, may know why performance seems to degrade with a
> newer kernel and with a newer distribution ? newer
> compiler ?

Gcc 3.0 has been reported to produce slightly slower code than it's
predecessor by many people on various architecture.  I'm sad to find that
MIPS is also one of them.

As for the kernel - I don't really know; your analysis isn't fine grained
enough.  I don't run kernel benchmarks religiously on every version but
what I can say my number have in part risen dramatically.

> c, any other tips for improving kernel / application
> performance.

Successful tuning requires a detailed analysis first.

  Ralf

Re: Benchmark performance

[Wayne Gowcher]

Ralf,

Thanks for the input.

> > a 3 % reduction in the Memory Index benchmark
> > a 2 % increase in the Integer Index benchmark
> > a 23 % reduction in the Floating Point Index
> benchmark
> 
> Small fluctuations in the range of 2 or 3 percent
> are usually explained
> by a changing usage pattern of the caches. 
> Therefore rerunning a the
> benchmarks is a good idea.  Especially
> microbenchmarks a la lmbench on
> caches of low associativity like the direct mapped
> R4k caches are extremly
> easily affected by cache usage patterns.

I messed up the figures for the redhat 7.1 case They
should have been :

Memory Index   6.7 % decrease
Integer Index  2 % decrease
Floating Point 27 % decrease

And it was the progressive reduction in performance of
the Memory Index that was raising a red flag to me.
Especially the big hit in floating point performance.

> Did you get any kernel messages during the Floating
> Point Index benchmark
> on the older kernel?

No, everything ran fine.

> > newer kernel and with a newer distribution ? newer
> > compiler ?
> 
> Gcc 3.0 has been reported to produce slightly slower
> code than it's
> predecessor by many people on various architecture. 
> I'm sad to find that
> MIPS is also one of them.

OK. That's one to remember.

> As for the kernel - I don't really know; your
> analysis isn't fine grained
> enough.

I didn't do any performance tweaking with the kernel
itself as I wouldn't really know how to go about it. I
was more trying to use a base kernel and then see how
I could improve the benchmark performance by using
compile options on the benchmark program only.
Admittedly improving kernel performance is a far more
efficient way of improving the benchmark scores.

> Successful tuning requires a detailed analysis
> first.

I read an article recently in Linux Journal on
tweaking an Alpha kernel. I suppose the same general
principles can be applied to MIPS. Alternatively, do
you ( or anyone else ) know of a howto or even a
general article on how to do this ?

I downloaded the benchmark from :

http://www.tux.org/~mayer/linux/bmark.html

Wayne

__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

Re: Benchmark performance

[Atsushi Nemoto]

[-- Attachment #1: Type: Text/Plain, Size: 651 bytes --]

>>>>> On Mon, 13 Aug 2001 10:34:46 -0700 (PDT), Wayne Gowcher <wgowcher@yahoo.com> said:
wgowcher> a 23 % reduction in the Floating Point Index benchmark

Current CVS kernel uses FPU emulator unconditionally.  If one floating
point intruction causes a 'Unimplemented' exception (denormalized
result, etc.) following floating point instructions are also handle by
FPU emulator (not only the instruction which raise the exception).

I do not know this is really desired behavior, but here is a patch to
change this.  If Unimplemented exception had been occured during the
benchmark, aplying this patch may result better performance.

---
Atsushi Nemoto

[-- Attachment #2: fpu_emu.patch --]
[-- Type: Text/Plain, Size: 1769 bytes --]

diff -ur linux.sgi/arch/mips/kernel/traps.c linux/arch/mips/kernel/traps.c
--- linux.sgi/arch/mips/kernel/traps.c	Sun Aug  5 23:39:20 2001
+++ linux/arch/mips/kernel/traps.c	Thu Aug 16 12:20:23 2001
@@ -60,7 +60,7 @@
 extern asmlinkage void handle_mcheck(void);
 extern asmlinkage void handle_reserved(void);
 
-extern int fpu_emulator_cop1Handler(struct pt_regs *);
+extern int fpu_emulator_cop1Handler(struct pt_regs *, int);
 
 char watch_available = 0;
 
@@ -306,7 +306,8 @@
 		save_fp(current);
 	
 		/* Run the emulator */
-		sig = fpu_emulator_cop1Handler(regs);
+		/* Emulate only one insn if we have FPU. */
+		sig = fpu_emulator_cop1Handler(regs, 1);
 
 		/* 
 		 * We can't allow the emulated instruction to leave the
@@ -605,7 +606,7 @@
 			current->used_math = 1;
 		}
 	}
-	sig = fpu_emulator_cop1Handler(regs);
+	sig = fpu_emulator_cop1Handler(regs, 0);
 	last_task_used_math = current;
 	if (sig)
 		force_sig(sig, current);
diff -ur linux.sgi/arch/mips/math-emu/cp1emu.c linux/arch/mips/math-emu/cp1emu.c
--- linux.sgi/arch/mips/math-emu/cp1emu.c	Sun Aug  5 23:39:27 2001
+++ linux/arch/mips/math-emu/cp1emu.c	Thu Aug 16 12:21:07 2001
@@ -1662,7 +1662,7 @@
  * hit a non-fp instruction, or a backward branch.  This cuts down dramatically
  * on the per instruction exception overhead.
  */
-int fpu_emulator_cop1Handler(struct pt_regs *xcp)
+int fpu_emulator_cop1Handler(struct pt_regs *xcp, int maxcount)
 {
 	struct mips_fpu_soft_struct *ctx = &current->thread.fpu.soft;
 	unsigned long oldepc, prevepc;
@@ -1682,6 +1682,8 @@
 			sig = cop1Emulate(xcp, ctx);
 		else
 			xcp->cp0_epc += 4;	/* skip nops */
+		if (maxcount && --maxcount <= 0)
+			break;
 	} while (xcp->cp0_epc > prevepc && sig == 0);
 
 	/* SIGILL indicates a non-fpu instruction */

Re: Benchmark performance

[Carsten Langgaard]

Atsushi Nemoto wrote:

> >>>>> On Mon, 13 Aug 2001 10:34:46 -0700 (PDT), Wayne Gowcher <wgowcher@yahoo.com> said:
> wgowcher> a 23 % reduction in the Floating Point Index benchmark
>
> Current CVS kernel uses FPU emulator unconditionally.  If one floating
> point intruction causes a 'Unimplemented' exception (denormalized
> result, etc.) following floating point instructions are also handle by
> FPU emulator (not only the instruction which raise the exception).

You got a point here, no need to emulate following floating point instructions, if one got
a real FPU.
But I think the check in the FP emulator should be a check if we got a real FPU, instead of
a counter.
We already has a flag for that in mips_cpu.options.
The check could be something like:

    if (mips_cpu.options & MIPS_CPU_FPU)
        break;



>
> I do not know this is really desired behavior, but here is a patch to
> change this.  If Unimplemented exception had been occured during the
> benchmark, aplying this patch may result better performance.
>
> ---
> Atsushi Nemoto
>
>   ------------------------------------------------------------------------
>                     Name: fpu_emu.patch
>    fpu_emu.patch    Type: Plain Text (Text/Plain)
>                 Encoding: 7bit

--
_    _ ____  ___   Carsten Langgaard   Mailto:carstenl@mips.com
|\  /|||___)(___   MIPS Denmark        Direct: +45 4486 5527
| \/ |||    ____)  Lautrupvang 4B      Switch: +45 4486 5555
  TECHNOLOGIES     2750 Ballerup       Fax...: +45 4486 5556
                   Denmark             http://www.mips.com

Re: Benchmark performance

[Kevin D. Kissell]

> Current CVS kernel uses FPU emulator unconditionally.  If one floating
> point intruction causes a 'Unimplemented' exception (denormalized
> result, etc.) following floating point instructions are also handle by
> FPU emulator (not only the instruction which raise the exception).
> 
> I do not know this is really desired behavior, but here is a patch to
> change this.  If Unimplemented exception had been occured during the
> benchmark, aplying this patch may result better performance.

Not desired behavior, just an artifact.  However, I agree with Carsten
that changing the API to the emulator for this and using a counter
as you have done is not appropriate, and that the existing CPU
configuration flag is a more appriate mechanism.  It's possible
that Wayne's baseline numbers came from a pre-Algor-emulator
kernel, and that this "feature" accounts for some of his degraded
performance.  But I'd be surprised if it accounted for all of it,
unless his FP test does 10% of its calculations on denormalized
numbers or something.

            Kevin K.

Re: Benchmark performance

[Kevin D. Kissell]

> Current CVS kernel uses FPU emulator unconditionally.  If one floating
> point intruction causes a 'Unimplemented' exception (denormalized
> result, etc.) following floating point instructions are also handle by
> FPU emulator (not only the instruction which raise the exception).
> 
> I do not know this is really desired behavior, but here is a patch to
> change this.  If Unimplemented exception had been occured during the
> benchmark, aplying this patch may result better performance.

Not desired behavior, just an artifact.  However, I agree with Carsten
that changing the API to the emulator for this and using a counter
as you have done is not appropriate, and that the existing CPU
configuration flag is a more appriate mechanism.  It's possible
that Wayne's baseline numbers came from a pre-Algor-emulator
kernel, and that this "feature" accounts for some of his degraded
performance.  But I'd be surprised if it accounted for all of it,
unless his FP test does 10% of its calculations on denormalized
numbers or something.

            Kevin K.

Re: Benchmark performance

[Ralf Baechle]

On Thu, Aug 16, 2001 at 12:56:52PM +0900, Atsushi Nemoto wrote:

> >>>>> On Mon, 13 Aug 2001 10:34:46 -0700 (PDT), Wayne Gowcher <wgowcher@yahoo.com> said:
> wgowcher> a 23 % reduction in the Floating Point Index benchmark
> 
> Current CVS kernel uses FPU emulator unconditionally.  If one floating
> point intruction causes a 'Unimplemented' exception (denormalized
> result, etc.) following floating point instructions are also handle by
> FPU emulator (not only the instruction which raise the exception).
> 
> I do not know this is really desired behavior, but here is a patch to
> change this.  If Unimplemented exception had been occured during the
> benchmark, aplying this patch may result better performance.

This is a know problem with the emulator.  It may be used to keep the
emulator in kernel for a long time or even maliciously to keep the
CPU in the kernel for an unbounded time.

Here's my suggested fix:

Index: arch/mips/math-emu/cp1emu.c
===================================================================
RCS file: /home/pub/cvs/linux/arch/mips/math-emu/cp1emu.c,v
retrieving revision 1.7
diff -u -r1.7 cp1emu.c
--- arch/mips/math-emu/cp1emu.c	2001/08/02 21:55:26	1.7
+++ arch/mips/math-emu/cp1emu.c	2001/08/16 09:06:55
@@ -1672,6 +1672,9 @@
 
 	oldepc = xcp->cp0_epc;
 	do {
+		if (current->need_resched)
+			break;
+
 		prevepc = xcp->cp0_epc;
 		insn = mips_get_word(xcp, REG_TO_VA(xcp->cp0_epc), &err);
 		if (err) {

  Ralf

Re: Benchmark performance

[Ralf Baechle]

On Thu, Aug 16, 2001 at 11:11:56AM +0200, Kevin D. Kissell wrote:

> > Current CVS kernel uses FPU emulator unconditionally.  If one floating
> > point intruction causes a 'Unimplemented' exception (denormalized
> > result, etc.) following floating point instructions are also handle by
> > FPU emulator (not only the instruction which raise the exception).
> > 
> > I do not know this is really desired behavior, but here is a patch to
> > change this.  If Unimplemented exception had been occured during the
> > benchmark, aplying this patch may result better performance.
> 
> Not desired behavior, just an artifact.  However, I agree with Carsten
> that changing the API to the emulator for this and using a counter
> as you have done is not appropriate, and that the existing CPU
> configuration flag is a more appriate mechanism.  It's possible
> that Wayne's baseline numbers came from a pre-Algor-emulator
> kernel, and that this "feature" accounts for some of his degraded
> performance.  But I'd be surprised if it accounted for all of it,
> unless his FP test does 10% of its calculations on denormalized
> numbers or something.

As I don't know the exact nature of the calculations involved it may well
be that the broken behaviour of a pre-fpuemu kernel did completly break
the algorithem involved.

As for the hard-fp case I agree with you.  It would be interesting to
know if fp instructions that need emulation appear in groups.  Then it's
the (hopefully) rare case which we don't really care about.

  Ralf

Re: Benchmark performance

[Carsten Langgaard]

Ralf Baechle wrote:

> On Thu, Aug 16, 2001 at 12:56:52PM +0900, Atsushi Nemoto wrote:
>
> > >>>>> On Mon, 13 Aug 2001 10:34:46 -0700 (PDT), Wayne Gowcher <wgowcher@yahoo.com> said:
> > wgowcher> a 23 % reduction in the Floating Point Index benchmark
> >
> > Current CVS kernel uses FPU emulator unconditionally.  If one floating
> > point intruction causes a 'Unimplemented' exception (denormalized
> > result, etc.) following floating point instructions are also handle by
> > FPU emulator (not only the instruction which raise the exception).
> >
> > I do not know this is really desired behavior, but here is a patch to
> > change this.  If Unimplemented exception had been occured during the
> > benchmark, aplying this patch may result better performance.
>
> This is a know problem with the emulator.  It may be used to keep the
> emulator in kernel for a long time or even maliciously to keep the
> CPU in the kernel for an unbounded time.
>
> Here's my suggested fix:
>
> Index: arch/mips/math-emu/cp1emu.c
> ===================================================================
> RCS file: /home/pub/cvs/linux/arch/mips/math-emu/cp1emu.c,v
> retrieving revision 1.7
> diff -u -r1.7 cp1emu.c
> --- arch/mips/math-emu/cp1emu.c 2001/08/02 21:55:26     1.7
> +++ arch/mips/math-emu/cp1emu.c 2001/08/16 09:06:55
> @@ -1672,6 +1672,9 @@
>
>         oldepc = xcp->cp0_epc;
>         do {
> +               if (current->need_resched)
> +                       break;
> +
>                 prevepc = xcp->cp0_epc;
>                 insn = mips_get_word(xcp, REG_TO_VA(xcp->cp0_epc), &err);
>                 if (err) {
>
>   Ralf

What is probably needed too, but I still think we need the check for real FPU, so we only
emulate one instruction at a time, if we got a real FPU.


--
_    _ ____  ___   Carsten Langgaard   Mailto:carstenl@mips.com
|\  /|||___)(___   MIPS Denmark        Direct: +45 4486 5527
| \/ |||    ____)  Lautrupvang 4B      Switch: +45 4486 5555
  TECHNOLOGIES     2750 Ballerup       Fax...: +45 4486 5556
                   Denmark             http://www.mips.com

Re: Benchmark performance

[Ralf Baechle]

On Thu, Aug 16, 2001 at 01:07:28PM +0200, Carsten Langgaard wrote:

> What is probably needed too, but I still think we need the check for real
> FPU, so we only emulate one instruction at a time, if we got a real FPU.

I'm just about to put it into CVS.

  Ralf

Re: Benchmark performance

[Atsushi Nemoto]

[-- Attachment #1: Type: Text/Plain, Size: 849 bytes --]

>>>>> On Thu, 16 Aug 2001 11:11:56 +0200, "Kevin D. Kissell" <kevink@mips.com> said:
>> I do not know this is really desired behavior, but here is a patch
>> to change this.  If Unimplemented exception had been occured during
>> the benchmark, aplying this patch may result better performance.

kevink> Not desired behavior, just an artifact.  However, I agree with
kevink> Carsten that changing the API to the emulator for this and
kevink> using a counter as you have done is not appropriate, and that
kevink> the existing CPU configuration flag is a more appriate mechanism.

I see.  I created that patch while debugging time an another FPU
emulator's problem (as I reported in another message) on CPU with real
FPU.  Now the 'counter' method is not needed at all.

Although another fix by Ralf is ready, here is my new patch.

---
Atsushi Nemoto

[-- Attachment #2: fpu_emu.patch --]
[-- Type: Text/Plain, Size: 641 bytes --]

diff -ur linux.sgi/arch/mips/math-emu/cp1emu.c linux/arch/mips/math-emu/cp1emu.c
--- linux.sgi/arch/mips/math-emu/cp1emu.c	Sun Aug  5 23:39:27 2001
+++ linux/arch/mips/math-emu/cp1emu.c	Thu Aug 16 19:41:35 2001
@@ -48,6 +48,8 @@
 #include <asm/mipsregs.h>
 #include <asm/system.h>
 #include <asm/pgtable.h>
+#include <asm/cpu.h>
+#include <asm/bootinfo.h>
 
 #include <asm/fpu_emulator.h>
 
@@ -1682,6 +1684,8 @@
 			sig = cop1Emulate(xcp, ctx);
 		else
 			xcp->cp0_epc += 4;	/* skip nops */
+		if (mips_cpu.options & MIPS_CPU_FPU)
+			break;
 	} while (xcp->cp0_epc > prevepc && sig == 0);
 
 	/* SIGILL indicates a non-fpu instruction */

Re: Benchmark performance

[Atsushi Nemoto]

>>>>> On Thu, 16 Aug 2001 13:14:22 +0200, Ralf Baechle <ralf@oss.sgi.com> said:
ralf> I'm just about to put it into CVS.

Please apply this small patch...

--- linux.sgi/arch/mips/math-emu/cp1emu.c	Fri Aug 24 17:57:36 2001
+++ linux/arch/mips/math-emu/cp1emu.c	Fri Aug 24 17:57:48 2001
@@ -1675,7 +1675,7 @@
 	oldepc = xcp->cp0_epc;
 	do {
 		if (current->need_resched)
-			schedule;
+			schedule();
 
 		prevepc = xcp->cp0_epc;
 		insn = mips_get_word(xcp, REG_TO_VA(xcp->cp0_epc), &err);
---
Atsushi Nemoto

Re: Benchmark performance

[Ralf Baechle]

On Fri, Aug 24, 2001 at 06:06:32PM +0900, Atsushi Nemoto wrote:

> ralf> I'm just about to put it into CVS.
> 
> Please apply this small patch...

Thanks, applied.  Somtimes the effects of C semantics are surprising ...

  Ralf