Dual Athlon MP 1900+ on MSI K7D Master-L

Dual Athlon MP 1900+ on MSI K7D Master-L

[Dieter Nützel]

Specs:

dual "MP unlocked" Athlon XP 1900+ (4th bridge of L5 is closed)
MSI K7D Master-L (MS-6501 v1.0), AMD 760 MPX
2 x 512 MB DDR-SDRAM 266, CL2, unregistered, no ECC

Linux SMP 2.4.19-rc1-jam2 + Page Coloring

PCI devices found:
  Bus  0, device   0, function  0:
    Host bridge: Advanced Micro Devices [AMD] AMD-760 MP [IGD4-2P] System 
Controller (rev 17).
      Master Capable.  Latency=32.
      Prefetchable 32 bit memory at 0xe8000000 [0xebffffff].
      Prefetchable 32 bit memory at 0xee100000 [0xee100fff].
      I/O at 0xc400 [0xc403].
  Bus  0, device   1, function  0:
    PCI bridge: Advanced Micro Devices [AMD] AMD-760 MP [IGD4-2P] AGP Bridge 
(rev 0).
      Master Capable.  Latency=32.  Min Gnt=14.
  Bus  0, device   7, function  0:
    ISA bridge: Advanced Micro Devices [AMD] AMD-768 [Opus] ISA (rev 5).
  Bus  0, device   7, function  1:
    IDE interface: Advanced Micro Devices [AMD] AMD-768 [Opus] IDE (rev 4).
      Master Capable.  Latency=32.
      I/O at 0xc000 [0xc00f].
  Bus  0, device   7, function  3:
    Bridge: Advanced Micro Devices [AMD] AMD-768 [Opus] ACPI (rev 3).
      Master Capable.  Latency=32.
  Bus  0, device  16, function  0:
    PCI bridge: Advanced Micro Devices [AMD] AMD-768 [Opus] PCI (rev 5).
      Master Capable.  Latency=32.  Min Gnt=6.
  Bus  1, device   5, function  0:
    VGA compatible controller: 3Dfx Interactive, Inc. Voodoo 4 / Voodoo 5 (rev 
1).
      IRQ 17.
      Non-prefetchable 32 bit memory at 0xe0000000 [0xe3ffffff].
      Prefetchable 32 bit memory at 0xd8000000 [0xdfffffff].
      I/O at 0xb000 [0xb0ff].
  Bus  2, device   0, function  0:
    USB Controller: Advanced Micro Devices [AMD] AMD-768 [Opus] USB (rev 7).
      IRQ 19.
      Master Capable.  Latency=32.  Max Lat=80.
      Non-prefetchable 32 bit memory at 0xed122000 [0xed122fff].
  Bus  2, device   4, function  0:
    Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 8).
      IRQ 16.
      Master Capable.  Latency=32.  Min Gnt=2.Max Lat=20.
      I/O at 0x9000 [0x901f].
  Bus  2, device   4, function  1:
    Input device controller: Creative Labs SB Live! MIDI/Game Port (rev 8).
      Master Capable.  Latency=32.
      I/O at 0x9400 [0x9407].
  Bus  2, device   5, function  0:
    Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 4).
      IRQ 17.
      Master Capable.  Latency=32.  Min Gnt=8.Max Lat=56.
      Prefetchable 32 bit memory at 0xee000000 [0xee000fff].
      I/O at 0x9800 [0x981f].
      Non-prefetchable 32 bit memory at 0xed000000 [0xed0fffff].
  Bus  2, device   6, function  0:
    SCSI storage controller: Adaptec AHA-2940U/UW/D / AIC-7881U (rev 1).
      IRQ 18.
      Master Capable.  Latency=32.  Min Gnt=8.Max Lat=8.
      I/O at 0x9c00 [0x9cff].
      Non-prefetchable 32 bit memory at 0xed120000 [0xed120fff].
  Bus  2, device   9, function  0:
    Ethernet controller: Intel Corp. 82559ER (rev 9).
      IRQ 17.
      Master Capable.  Latency=32.  Min Gnt=8.Max Lat=56.
      Non-prefetchable 32 bit memory at 0xed121000 [0xed121fff].
      I/O at 0xa000 [0xa03f].
      Non-prefetchable 32 bit memory at 0xed100000 [0xed11ffff].

/home/nuetzel> sensors
eeprom-i2c-0-50
Adapter: SMBus AMD768 adapter at 06e0
Algorithm: Non-I2C SMBus adapter
Memory type:            SDRAM DIMM SPD
SDRAM Size (MB):        invalid
12 1 2 144

eeprom-i2c-0-51
Adapter: SMBus AMD768 adapter at 06e0
Algorithm: Non-I2C SMBus adapter

w83627hf-isa-0290
Adapter: ISA adapter
Algorithm: ISA algorithm
VCore 1:   +1.71 V  (min =  +4.08 V, max =  +4.08 V)
VCore 2:   +2.48 V  (min =  +4.08 V, max =  +4.08 V)
+3.3V:     +3.36 V  (min =  +3.13 V, max =  +3.45 V)
+5V:       +4.94 V  (min =  +4.72 V, max =  +5.24 V)
+12V:     +12.08 V  (min = +10.79 V, max = +13.19 V)
-12V:     -12.70 V  (min = -13.21 V, max = -10.90 V)
-5V:       -5.10 V  (min =  -5.26 V, max =  -4.76 V)
V5SB:      +5.38 V  (min =  +4.72 V, max =  +5.24 V)
VBat:      +3.42 V  (min =  +2.40 V, max =  +3.60 V)
U160:        0 RPM  (min = 3000 RPM, div = 2)
CPU 0:    4500 RPM  (min = 3000 RPM, div = 2)
CPU 1:    4272 RPM  (min = 3000 RPM, div = 2)
System:   +33.0°C   (limit = +60°C, hysteresis = +127°C) sensor = thermistor
CPU 1:    +41.5°C   (limit = +60°C, hysteresis = +50°C) sensor = 3904 
transistor
CPU 0:    +43.0°C   (limit = +60°C, hysteresis = +50°C) sensor = 3904 
transistor
vid:      +18.50 V
alarms:   Chassis intrusion detection
beep_enable:
          Sound alarm disabled

During compilation of the glibc.
Do you need more info?

Alan, were should I put the "-j2/-j3" make flag for the kernel compilation?
/usr/src/linux/Documentation/smp.txt is way outdated ;-(

Is there a place (maybe in /usr/lib/rpmrc; SuSE/RedHat) to get both CPUs 
running during RPM packages compilation?

Thanks,
	Dieter
-- 
Dieter Nützel
Graduate Student, Computer Science

University of Hamburg
Department of Computer Science
@home: Dieter.Nuetzel@hamburg.de

Re: Dual Athlon MP 1900+ on MSI K7D Master-L

[Kelledin]

On Thursday 18 July 2002 08:31 pm, Dieter Nützel wrote:
> Alan, were should I put the "-j2/-j3" make flag for the kernel
> compilation? /usr/src/linux/Documentation/smp.txt is way
> outdated ;-(
>
> Is there a place (maybe in /usr/lib/rpmrc; SuSE/RedHat) to get
> both CPUs running during RPM packages compilation?

Alan may have a different answer for you, but in my experience, 
you can just specify the -j<whatever> flag when you run make 
(and also set the MAKE variable to "make -j<whatever>".  The 
speed benefit really kicks in when making bzImage or modules.

In general, I find it best to set the number of jobs to the 
number of CPUs _plus 1_--i.e. for single CPU, use make -j2, and 
for dual CPUs, use make -j3.  Going for that "plus 1" makes most 
builds just a smidgen faster.  For me, on my dual PPro box, the 
process would be something like:

make menuconfig
make -j3 MAKE="make -j3" dep clean bzImage modules

Doing just a bare "make -j" (using just "-j" where you'd normally 
use "-j<whatever>") is never good, even if you actually do have 
tons and tons of mem+swap.  Besides sucking up memory like 
there's no tomorrow, it hammers the system with context switches 
and forces the build to spend way too much of its time stuck in 
the process scheduler.  This makes a nice brutal stress-test for 
a system, but it slows your build to a crawl.

AFAIK, the only way to get RPM packages to use "make 
-j<whatever>" is to edit their spec files manually, have the 
%build scriptlet look in /proc/cpuinfo to discover the number of 
CPUs, and then have the scriptlet explicitly call make with 
appropriate -j parameters.  You might want to do this both in 
the %build and %install scriptlets, since environment variable 
settings in the %build scriptlet don't necessarily carry over 
into %install.

Beware, also, that many build scripts will not work properly with 
"make -j<whatever>".  A parallel build as a whole may work, or 
it may not.  Some source packages may fail loudly and die.  A 
few may appear to complete successfully, yet silently fail to 
install some file or another.  It's fairly common for source 
trees not to be 100% "parallel-build safe", and the kernel is no 
exception.

You could possibly complain to developers about this, but most 
developers have higher priorities than catering to people with 
multiple CPUs. ;)  So using "make -j<whatever>" should always be 
considered "experimental."

--
Kelledin
"If a server crashes in a server farm and no one pings it, does 
it still cost four figures to fix?"

Re: Dual Athlon MP 1900+ on MSI K7D Master-L

[William Park]

On Thu, Jul 18, 2002 at 09:14:30PM -0500, Kelledin wrote:
> On Thursday 18 July 2002 08:31 pm, Dieter N?tzel wrote:
> > Alan, were should I put the "-j2/-j3" make flag for the kernel
> > compilation? /usr/src/linux/Documentation/smp.txt is way
> > outdated ;-(
...
> In general, I find it best to set the number of jobs to the 
> number of CPUs _plus 1_--i.e. for single CPU, use make -j2, and 
> for dual CPUs, use make -j3.  Going for that "plus 1" makes most 
> builds just a smidgen faster.  For me, on my dual PPro box, the 
> process would be something like:
> 
> make menuconfig
> make -j3 MAKE="make -j3" dep clean bzImage modules

I usually have better luck if I use only one target per 'make':
    make menuconfig
    make -j3 dep
    make clean
    make -j3 bzlilo
    make -j3 modules
    make -j3 modules_install
Especially, 'modules' and 'modules_install' must be done separately.

-- 
William Park, Open Geometry Consulting, <opengeometry@yahoo.ca>
8-CPU Cluster, Hosting, NAS, Linux, LaTeX, python, vim, mutt, tin

Re: Dual Athlon MP 1900+ on MSI K7D Master-L

[Bill Davidsen]

On Thu, 18 Jul 2002, Kelledin wrote:
> Alan may have a different answer for you, but in my experience, 
> you can just specify the -j<whatever> flag when you run make 
> (and also set the MAKE variable to "make -j<whatever>".  The 
> speed benefit really kicks in when making bzImage or modules.
> 
> In general, I find it best to set the number of jobs to the 
> number of CPUs _plus 1_--i.e. for single CPU, use make -j2, and 
> for dual CPUs, use make -j3.  Going for that "plus 1" makes most 
> builds just a smidgen faster.  For me, on my dual PPro box, the 
> process would be something like:
> 
> make menuconfig
> make -j3 MAKE="make -j3" dep clean bzImage modules

These do different things...

If you put -j3 on the command line as an option to the primary make, it
can (will) run that many processes and do things out of order. If you use
MAKE='make -j3' it only takes effect after a new make process is started.
So you can put all the things on one command line and they will be run to
completion sequentially. I find this helpful to avoid mixing bzImage and
modules, one may get an error and the other will keep on going, scrolling
the error off the screen.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.