Level 2 cache activation code?

[Svante Signell]

      Hello,

I have recently upgraded my dual MSI-6120 from 2xCeleron (Mendocino)
300@450MHz with 2xMSI-6905 slot 370 to slot 1 adapters to one Celeron2
1.3GHz (Tualatin) using a Slot-T adapter card. The plan is to equip the
mobo with 2xPIII or preferably 2xVIA C3 Nehemiah (when SMP capable). 

The problem is that the latest MSI BIOS (v2.0) for the mobo does not
support Coppermine/Tualatin processors. The single GNU/Linux kernels
boot without problems but _extremely_ slowly, at least with a speed
reduction by a factor 10. hdparm -tT gives around 20/2 compared with
250/25 with the Mendocino CPU(s). For example uncompressing the kernel
takes minute(s) compared to seconds. After some trials and web searching
I suspect that the problem is with the level 2 cache not activated by
the BIOS. 

I see the you have code in the linuxbios for activating caches. 

i) Does this code work for 440BX motherboards?
ii) Is it possible to extract this code and try out after the kernel has
booted (slowly), to verify my assumption?
iii) Is there some other tool available for cache activation?
iv) One interesting continuation would be to try to replace the MSI
(AMI) BIOS with linuxbios, but as a first step I think this would be a
little risky.

Any ideas?

Thanks,
Svante

[ron minnich]

      On Tue, 30 Sep 2003, Svante Signell wrote:

  i) Does this code work for 440BX motherboards?
it's processor-dependent, 440bx or not is not an issue.

  ii) Is it possible to extract this code and try out
after the kernel has
 booted (slowly), to verify my assumption?
yes, we tested it that way. You can try it. 

  iii) Is there some other tool available for cache
activation?
Not sure.

  iv) One interesting continuation would be to try to
replace the MSI
 (AMI) BIOS with linuxbios, but as a first step I think this would be a
 little risky.
well, so far, given the track record of many of these BIOSes, I'm not sure 
how risky that is ...

ron

[Svante Signell]

      Ron,

Thank you for your reply. Maybe there is hope after all.

On Wed, 2003-10-01 at 01:34, ron minnich wrote:
  On Tue, 30 Sep 2003, Svante Signell wrote:
 
  i) Does this code work for 440BX motherboards?
 
 it's processor-dependent, 440bx or not is not an issue.
Thanks for the info. To
clarify  I'll split the question into three:
i) Does LinuxBIOS work for 440BX-based mother-boards, single and dual?
Downloading the code from CVS shows support for Intel L440GX+ and a
patch for linux-2.4.13, not 440BX or kernels later than 2.4.13. Also, I
did not find anything about MSI mainboards.
ii) Does the cache activation code work for Mendocino, Coppermine,
Tualatin and newer Intel processors? Will it work for the VIA C3
Nehemiah?
iii) How much of the boot process in GNU/Linux the BIOS responsible for?
I thought that the kernel was only dependent on the BIOS for a few
functions, such as different HW initialisations: CPU, memory, disks, etc
compared to Windows 9x etc. Any pointers?

  ii) Is it
possible to extract this code and try out after the kernel has
 booted (slowly), to verify my assumption?
 
 yes, we tested it that way. You can try it.
I will try. Which files do I need in
addition to src/cpu/p6/l2_cache.c?

  iii) Is there
some other tool available for cache activation?
 
 Not sure.
 
  iv) One interesting continuation would be to try
to replace the MSI
 (AMI) BIOS with linuxbios, but as a first step I think this would be a
 little risky.
 
 well, so far, given the track record of many of these BIOSes, I'm not sure 
 how risky that is ...
With risks I meant the chance of being left with a dead
motherboard... I'm always
nervous when flashing the BIOS that something will happen, for example a sudden power
loss, regardless of where the BIOS originates from.

  ron
BTW: Why is this work called LinuxBIOS
(except maybe for historical
reasons). Will other OSes (eg GNU/Hurd) boot with LinuxBIOS now or in
the future? Maybe then something like FreeBIOS should be used instead.

Thanks,
Svante

[ron minnich]

      On Wed, 1 Oct 2003, Svante Signell wrote:

  i) Does LinuxBIOS work for 440BX-based mother-boards,
single and dual?
 Downloading the code from CVS shows support for Intel L440GX+ and a
 patch for linux-2.4.13, not 440BX or kernels later than 2.4.13. Also, I
 did not find anything about MSI mainboards.
single are tested. Dual I don't know.

  ii) Does the cache activation code work for Mendocino,
Coppermine,
 Tualatin and newer Intel processors? Will it work for the VIA C3
 Nehemiah?
It was only needed for PII. Coppermine and later -- "Just works". It is 
extremely cpu-dependent.

  iii) How much of the boot process in GNU/Linux the
BIOS responsible for?
 I thought that the kernel was only dependent on the BIOS for a few
 functions, such as different HW initialisations: CPU, memory, disks, etc
 compared to Windows 9x etc. Any pointers?
that's about right.

  I will try. Which files do I need in addition to
src/cpu/p6/l2_cache.c?
none. You have to turn that back into a main() but it should  be fine.

  With risks I meant the chance of being left with a
dead motherboard...
 I'm always nervous when flashing the BIOS that something will happen,
 for example a sudden power loss, regardless of where the BIOS originates
 from.
never do this kind of work without a spare bios part. Never.

  BTW: Why is this work called LinuxBIOS (except maybe
for historical
 reasons). Will other OSes (eg GNU/Hurd) boot with LinuxBIOS now or in
 the future? Maybe then something like FreeBIOS should be used instead.
It was called linuxbios for a simple reason: linux was going to be the 
bios. linux would be in flash, linux would boot the oses. 

Small flashes have caused changes in course in some cases, but the name 
has stuck anyway. Now that vendors have joined in, changing the name would 
be hard.

ron

[Svante Signell]

      Hi,

Sorry for taking up this thread again but now I have made a test of the
l2_cache activation code and have some further questions. 

The files put together to make things build are l2_cache.c, printk.c,
vsprintf.c, subr.c and corresponding header files from the linuxbios CVS
tree. For subr.c I had to add an include (#include <sys/io.h>) to get
outb defined for linking. The result so far is a segfault, in the
cache_enable() inline assembly routine in l2_cache.c)

0. How to test this code after a _slow_ boot outside the BIOS? Is single
user mode sufficient, i.e. init 1?
 
1. How are these printk statements supposed to work? Is the output
directed to some system logfile, like kern.log? How to define this
logfile etc. What to change if I want to log debug outputs to the
standard out and/or standard err? I don't find any output when running
the main program, neither in the system log files or on the screen. 

2. Any special compiler and linker switches needed, like -nostdinc,
-nostdlib, -nostartfiles, etc? Your build system is Python based, right,
so I cannot easily look at Makefiles in the CVS tree.

3. I found where the program halts with gdb and compiling with debug
set. One way to trace is single stepping in gdb etc. What is supposed to
happen when the DEBUG is defined in l2_cache.c?

4. You state that the L2 cache stuff is only needed for P2 CPUs, not for
P3 type CPUs, such as Coppermine or Tualatin. I'm testing with a Celeron
2 CPU (Tualatin), which is of P3 type. What if the BIOS does not
recognise the CPU and disables the L2 cache? People claim that AMI
BIOSes work this way. It the enabling code sufficient to make things
work.

5. If the slowness is not due to a disabled L2 cache (how to test this
properly btw?), can the  problems be solved by tying with the mtrr or
microcode update code? 

6. Maybe the problem is still hardware related, like the on-board
voltage regulator for the CPU is not working properly, even if there are
no indications at all from the on board sensors. However, if the
problems are software related and can be solved, do you think it is
feasible to replace the AMI BIOS with LinuxBIOS? The probability of
getting an updated BIOS from MSI supporting Coppermine and Tualatin
processors is probably zero.

Thanks,
Svante

On Wed, 2003-10-01 at 15:40, ron minnich wrote:
  On Wed, 1 Oct 2003, Svante Signell wrote:
 
  i) Does LinuxBIOS work for 440BX-based
mother-boards, single and dual?
 Downloading the code from CVS shows support for Intel L440GX+ and a
 patch for linux-2.4.13, not 440BX or kernels later than 2.4.13. Also, I
 did not find anything about MSI mainboards.
 
 single are tested. Dual I don't know.
 
  ii) Does the cache activation code work for
Mendocino, Coppermine,
 Tualatin and newer Intel processors? Will it work for the VIA C3
 Nehemiah?
 
 It was only needed for PII. Coppermine and later -- "Just works". It is 
 extremely cpu-dependent.
 
  iii) How much of the boot process in GNU/Linux
the BIOS responsible for?
 I thought that the kernel was only dependent on the BIOS for a few
 functions, such as different HW initialisations: CPU, memory, disks, etc
 compared to Windows 9x etc. Any pointers?
 
 that's about right.
 
  I will try. Which files do I need in addition to
src/cpu/p6/l2_cache.c?
 
 none. You have to turn that back into a main() but it should  be fine.
 
  With risks I meant the chance of being left with
a dead motherboard...
 I'm always nervous when flashing the BIOS that something will happen,
 for example a sudden power loss, regardless of where the BIOS originates
 from.
 
 never do this kind of work without a spare bios part. Never.
 
  BTW: Why is this work called LinuxBIOS (except
maybe for historical
 reasons). Will other OSes (eg GNU/Hurd) boot with LinuxBIOS now or in
 the future? Maybe then something like FreeBIOS should be used instead.
 
 It was called linuxbios for a simple reason: linux was going to be the 
 bios. linux would be in flash, linux would boot the oses. 
 
 Small flashes have caused changes in course in some cases, but the name 
 has stuck anyway. Now that vendors have joined in, changing the name would 
 be hard.
 
 ron

[steven james]

      Greetings,

To run that code inside linux, you need to add a call to iopl to allow
direct hardware access like:

res = iopl(3);
if(res) {
	report_error();
	exit(-1);
}

or something to that effect.
G'day,
sjames


On Thu, 6 Nov 2003, Svante Signell wrote:

  Hi,
 
 Sorry for taking up this thread again but now I have made a test of the
 l2_cache activation code and have some further questions. 
 
 The files put together to make things build are l2_cache.c, printk.c,
 vsprintf.c, subr.c and corresponding header files from the linuxbios CVS
 tree. For subr.c I had to add an include (#include <sys/io.h>) to get
 outb defined for linking. The result so far is a segfault, in the
 cache_enable() inline assembly routine in l2_cache.c)
 
 0. How to test this code after a _slow_ boot outside the BIOS? Is single
 user mode sufficient, i.e. init 1?
  
 1. How are these printk statements supposed to work? Is the output
 directed to some system logfile, like kern.log? How to define this
 logfile etc. What to change if I want to log debug outputs to the
 standard out and/or standard err? I don't find any output when running
 the main program, neither in the system log files or on the screen. 
 
 2. Any special compiler and linker switches needed, like -nostdinc,
 -nostdlib, -nostartfiles, etc? Your build system is Python based, right,
 so I cannot easily look at Makefiles in the CVS tree.
 
 3. I found where the program halts with gdb and compiling with debug
 set. One way to trace is single stepping in gdb etc. What is supposed to
 happen when the DEBUG is defined in l2_cache.c?
 
 4. You state that the L2 cache stuff is only needed for P2 CPUs, not for
 P3 type CPUs, such as Coppermine or Tualatin. I'm testing with a Celeron
 2 CPU (Tualatin), which is of P3 type. What if the BIOS does not
 recognise the CPU and disables the L2 cache? People claim that AMI
 BIOSes work this way. It the enabling code sufficient to make things
 work.
 
 5. If the slowness is not due to a disabled L2 cache (how to test this
 properly btw?), can the  problems be solved by tying with the mtrr or
 microcode update code? 
 
 6. Maybe the problem is still hardware related, like the on-board
 voltage regulator for the CPU is not working properly, even if there are
 no indications at all from the on board sensors. However, if the
 problems are software related and can be solved, do you think it is
 feasible to replace the AMI BIOS with LinuxBIOS? The probability of
 getting an updated BIOS from MSI supporting Coppermine and Tualatin
 processors is probably zero.
 
 Thanks,
 Svante
 
 On Wed, 2003-10-01 at 15:40, ron minnich wrote:
  On Wed, 1 Oct 2003, Svante Signell wrote:
 
  i) Does LinuxBIOS work for 440BX-based
mother-boards, single and dual?
 Downloading the code from CVS shows support for Intel L440GX+ and a
 patch for linux-2.4.13, not 440BX or kernels later than 2.4.13. Also, I
 did not find anything about MSI mainboards.
 
 single are tested. Dual I don't know.
 
  ii) Does the cache activation code work for
Mendocino, Coppermine,
 Tualatin and newer Intel processors? Will it work for the VIA C3
 Nehemiah?
 
 It was only needed for PII. Coppermine and later -- "Just works". It is 
 extremely cpu-dependent.
 
  iii) How much of the boot process in GNU/Linux
the BIOS responsible for?
 I thought that the kernel was only dependent on the BIOS for a few
 functions, such as different HW initialisations: CPU, memory, disks, etc
 compared to Windows 9x etc. Any pointers?
 
 that's about right.
 
  I will try. Which files do I need in addition to
src/cpu/p6/l2_cache.c?
 
 none. You have to turn that back into a main() but it should  be fine.
 
  With risks I meant the chance of being left with
a dead motherboard...
 I'm always nervous when flashing the BIOS that something will happen,
 for example a sudden power loss, regardless of where the BIOS originates
 from.
 
 never do this kind of work without a spare bios part. Never.
 
  BTW: Why is this work called LinuxBIOS (except
maybe for historical
 reasons). Will other OSes (eg GNU/Hurd) boot with LinuxBIOS now or in
 the future? Maybe then something like FreeBIOS should be used instead.
 
 It was called linuxbios for a simple reason: linux was going to be the 
 bios. linux would be in flash, linux would boot the oses. 
 
 Small flashes have caused changes in course in some cases, but the name 
 has stuck anyway. Now that vendors have joined in, changing the name would 
 be hard.
 
 ron
 _______________________________________________
 Linuxbios mailing list
 Linuxbios(a)clustermatic.org
 http://www.clustermatic.org/mailman/listinfo/linuxbios
-- 
-------------------------steven james, director of research, linux labs
... ........ ..... ....                    230 peachtree st nw ste 2701
the original linux labs                             atlanta.ga.us 30303
      -since 1995                              http://www.linuxlabs.com
                                   office 404.577.7747 fax [phone]
-----------------------------------------------------------------------

[Svante Signell]

      Steven,

Thanks for the tip, I'll try adding this in. Preliminary estimations
with lmbench-2.0 shows like the problems are probably due to the missing
L2 cache. I'm currently compiling and running running lmbench-3, but
with an efficient speed of 7MHz instead of 1300MHz, things take time...

BTW: If one is picky, shouldn't the test be like if(res == -1)? The man
page of iopl says: 
On success, zero is returned.  On error, -1 is returned,  and  errno is
set appropriately. 
But of course, all values not equal to 0 means "true", right?


On Thu, 2003-11-06 at 14:59, steven james wrote:
  Greetings,
 
 To run that code inside linux, you need to add a call to iopl to allow
 direct hardware access like:
 
 res = iopl(3);
 if(res) {
 	report_error();
 	exit(-1);
 }
 
 or something to that effect.
 G'day,
 sjames
 
 
 On Thu, 6 Nov 2003, Svante Signell wrote:
 
 > Hi,
 > 
 > Sorry for taking up this thread again but now I have made a test of the
 > l2_cache activation code and have some further questions. 
 > 
 > The files put together to make things build are l2_cache.c, printk.c,
 > vsprintf.c, subr.c and corresponding header files from the linuxbios CVS
 > tree. For subr.c I had to add an include (#include <sys/io.h>) to get
 > outb defined for linking. The result so far is a segfault, in the
 > cache_enable() inline assembly routine in l2_cache.c)
 > 
 > 0. How to test this code after a _slow_ boot outside the BIOS? Is single
 > user mode sufficient, i.e. init 1?
 >  
 > 1. How are these printk statements supposed to work? Is the output
 > directed to some system logfile, like kern.log? How to define this
 > logfile etc. What to change if I want to log debug outputs to the
 > standard out and/or standard err? I don't find any output when running
 > the main program, neither in the system log files or on the screen. 
 > 
 > 2. Any special compiler and linker switches needed, like -nostdinc,
 > -nostdlib, -nostartfiles, etc? Your build system is Python based, right,
 > so I cannot easily look at Makefiles in the CVS tree.
 > 
 > 3. I found where the program halts with gdb and compiling with debug
 > set. One way to trace is single stepping in gdb etc. What is supposed to
 > happen when the DEBUG is defined in l2_cache.c?
 > 
 > 4. You state that the L2 cache stuff is only needed for P2 CPUs, not for
 > P3 type CPUs, such as Coppermine or Tualatin. I'm testing with a Celeron
 > 2 CPU (Tualatin), which is of P3 type. What if the BIOS does not
 > recognise the CPU and disables the L2 cache? People claim that AMI
 > BIOSes work this way. It the enabling code sufficient to make things
 > work.
 > 
 > 5. If the slowness is not due to a disabled L2 cache (how to test this
 > properly btw?), can the  problems be solved by tying with the mtrr or
 > microcode update code? 
 > 
 > 6. Maybe the problem is still hardware related, like the on-board
 > voltage regulator for the CPU is not working properly, even if there are
 > no indications at all from the on board sensors. However, if the
 > problems are software related and can be solved, do you think it is
 > feasible to replace the AMI BIOS with LinuxBIOS? The probability of
 > getting an updated BIOS from MSI supporting Coppermine and Tualatin
 > processors is probably zero.
 > 
 > Thanks,
 > Svante

[steven james]

      Greetings,

Yes, anything non 0 is true. Testing that way (or if(res<0) when the
function is to return a count) generally helps to catch wierdness (in the
bad old days, some functions returned -errno or even errno on error but
always 0 on success, this catches all of those cases).

G'day,
sjames



On Fri, 7 Nov 2003, Svante Signell wrote:

  Steven,
 
 Thanks for the tip, I'll try adding this in. Preliminary estimations
 with lmbench-2.0 shows like the problems are probably due to the missing
 L2 cache. I'm currently compiling and running running lmbench-3, but
 with an efficient speed of 7MHz instead of 1300MHz, things take time...
 
 BTW: If one is picky, shouldn't the test be like if(res == -1)? The man
 page of iopl says: 
 On success, zero is returned.  On error, -1 is returned,  and  errno is
 set appropriately. 
 But of course, all values not equal to 0 means "true", right?
 
 
 On Thu, 2003-11-06 at 14:59, steven james wrote:
  Greetings,
 
 To run that code inside linux, you need to add a call to iopl to allow
 direct hardware access like:
 
 res = iopl(3);
 if(res) {
 	report_error();
 	exit(-1);
 }
 
 or something to that effect.
 G'day,
 sjames
 
 
 On Thu, 6 Nov 2003, Svante Signell wrote:
 
 > Hi,
 > 
 > Sorry for taking up this thread again but now I have made a test of the
 > l2_cache activation code and have some further questions. 
 > 
 > The files put together to make things build are l2_cache.c, printk.c,
 > vsprintf.c, subr.c and corresponding header files from the linuxbios CVS
 > tree. For subr.c I had to add an include (#include <sys/io.h>) to get
 > outb defined for linking. The result so far is a segfault, in the
 > cache_enable() inline assembly routine in l2_cache.c)
 > 
 > 0. How to test this code after a _slow_ boot outside the BIOS? Is single
 > user mode sufficient, i.e. init 1?
 >  
 > 1. How are these printk statements supposed to work? Is the output
 > directed to some system logfile, like kern.log? How to define this
 > logfile etc. What to change if I want to log debug outputs to the
 > standard out and/or standard err? I don't find any output when running
 > the main program, neither in the system log files or on the screen. 
 > 
 > 2. Any special compiler and linker switches needed, like -nostdinc,
 > -nostdlib, -nostartfiles, etc? Your build system is Python based, right,
 > so I cannot easily look at Makefiles in the CVS tree.
 > 
 > 3. I found where the program halts with gdb and compiling with debug
 > set. One way to trace is single stepping in gdb etc. What is supposed to
 > happen when the DEBUG is defined in l2_cache.c?
 > 
 > 4. You state that the L2 cache stuff is only needed for P2 CPUs, not for
 > P3 type CPUs, such as Coppermine or Tualatin. I'm testing with a Celeron
 > 2 CPU (Tualatin), which is of P3 type. What if the BIOS does not
 > recognise the CPU and disables the L2 cache? People claim that AMI
 > BIOSes work this way. It the enabling code sufficient to make things
 > work.
 > 
 > 5. If the slowness is not due to a disabled L2 cache (how to test this
 > properly btw?), can the  problems be solved by tying with the mtrr or
 > microcode update code? 
 > 
 > 6. Maybe the problem is still hardware related, like the on-board
 > voltage regulator for the CPU is not working properly, even if there are
 > no indications at all from the on board sensors. However, if the
 > problems are software related and can be solved, do you think it is
 > feasible to replace the AMI BIOS with LinuxBIOS? The probability of
 > getting an updated BIOS from MSI supporting Coppermine and Tualatin
 > processors is probably zero.
 > 
 > Thanks,
 > Svante
-- 
-------------------------steven james, director of research, linux labs
... ........ ..... ....                    230 peachtree st nw ste 2701
the original linux labs                             atlanta.ga.us 30303
      -since 1995                              http://www.linuxlabs.com
                                   office 404.577.7747 fax [phone]
-----------------------------------------------------------------------

[Svante Signell]

      I still do get a segfault when trying to activate the L2 cache, in the
cache_enable() inline assembly routine in l2_cache.c Anything else
neeeded to run this program inside GNU/Linux 

On Fri, 2003-11-07 at 15:42, steven james wrote:
  Greetings,
 
 Yes, anything non 0 is true. Testing that way (or if(res<0) when the
 function is to return a count) generally helps to catch wierdness (in the
 bad old days, some functions returned -errno or even errno on error but
 always 0 on success, this catches all of those cases).
 
 G'day,
 sjames
 
 
 On Thu, 2003-11-06 at 14:59, steven james wrote:
 > Greetings,
 > 
 > To run that code inside linux, you need to add a call to iopl to
allow
  direct
hardware access like:
 
 res = iopl(3);
 if(res) {
     report_error();
     exit(-1);
 }
 
 or something to that effect.
 G'day,
 sjames
 On Fri, 7 Nov 2003, Svante Signell wrote:
 
 > Steven,
 > 
 > Thanks for the tip, I'll try adding this in. Preliminary estimations
 > with lmbench-2.0 shows like the problems are probably due to the missing
 > L2 cache. I'm currently compiling and running running lmbench-3, but
 > with an efficient speed of 7MHz instead of 1300MHz, things take time...
 >
...
  > > > 5. If the slowness is not due to a
disabled L2 cache (how to test this
 > > > properly btw?), can the  problems be solved by tying with the mtrr or
 > > > microcode update code? 
 > > > 
 > > > 6. Maybe the problem is still hardware related, like the on-board
 > > > voltage regulator for the CPU is not working properly, even if there are
 > > > no indications at all from the on board sensors. However, if the
 > > > problems are software related and can be solved, do you think it is
 > > > feasible to replace the AMI BIOS with LinuxBIOS? The probability of
 > > > getting an updated BIOS from MSI supporting Coppermine and Tualatin
 > > > processors is probably zero.
 > > > 
 > > > Thanks,
 > > > Svante 
 >

[ron minnich]

      On Thu, 6 Nov 2003, Svante Signell wrote:

  Sorry for taking up this thread again but now I have
made a test of the
 l2_cache activation code and have some further questions.
you don't need this code any more. The last processor it mattered for is 
long dead. I am not removing it but if you are having trouble then you 
have a PII; do you?

  4. You state that the L2 cache stuff is only needed
for P2 CPUs, not for
 P3 type CPUs, such as Coppermine or Tualatin. I'm testing with a Celeron
 2 CPU (Tualatin), which is of P3 type. What if the BIOS does not
 recognise the CPU and disables the L2 cache? People claim that AMI
 BIOSes work this way. It the enabling code sufficient to make things
 work.
which BIOS?

  5. If the slowness is not due to a disabled L2 cache
(how to test this
 properly btw?), can the  problems be solved by tying with the mtrr or
 microcode update code?
use lmbench to scope out your caches.

ron

[Svante Signell]

      On Thu, 2003-11-06 at 15:11, ron minnich wrote:
  On Thu, 6 Nov 2003, Svante Signell wrote:
 
  Sorry for taking up this thread again but now I
have made a test of the
 l2_cache activation code and have some further questions.
 
 you don't need this code any more. The last processor it mattered for is 
 long dead. I am not removing it but if you are having trouble then you 
 have a PII; do you?
No, I have a Pentium 2 1.3GHz Tualatin processor that works properly on other 
440BX-based main boards such as QDI BrillianX 1 and Compaq Presario 5670. I'm 
using a slot 1 to socket 370 converter, SLOT-T from Upgradeware for this CPU.
  
BTW: What do you mean by PIIs are long dead? I think _many_ people are
still using PIIs, especially with 400BX-based main boards. What I have
done is to extend the life of my old computers and their main boards by
exchanging the PIIs with PIIIs, specifically using Celeron2, with 1.4
GHz frequency (or 1.3GHz, since 1.4GHz versions are hard to find
currently).

Intel is phasing out these Celeron2s today, but compatible CPUs with
decent performance and clock frequencies are becoming available, e.g.
the VIA C3 Nehemiah, today at 1.2GHz. Versions up to 2GHz are coming
soon. Even SMP capable processors are in this years roadmap. Now we are
talking low power and cheap solutions (and maybe even fan-less). I plan
to use SMP-able processors from VIA for my currently problematic
motherboard when available.  The first step is to make things run with
one CPU. 

The motherboard is a dual CPU MSI-6120 with built-in SCSI interfaces. It
is currently equipped with two SMP-able PII-type Celerons (Mendocino)
300MHz@468MHz. This motherboard have been working properly for four
years now and it would (in my opinion) be a big waste to throw it away.
I even consider to replace the problematic BIOS with a LinuxBIOS if the
problem is found not to be hardware related.

  4. You state
that the L2 cache stuff is only needed for P2 CPUs, not for
 P3 type CPUs, such as Coppermine or Tualatin. I'm testing with a Celeron
 2 CPU (Tualatin), which is of P3 type. What if the BIOS does not
 recognise the CPU and disables the L2 cache? People claim that AMI
 BIOSes work this way. It the enabling code sufficient to make things
 work.
 
 which BIOS?
The BIOS is from AMI with version 2.0 (a6120v20.exe) supplied by MSI.

  5. If the
slowness is not due to a disabled L2 cache (how to test this
 properly btw?), can the  problems be solved by tying with the mtrr or
 microcode update code?
 
 use lmbench to scope out your caches.
OK, I have now run lmbench on two boxes, one QDI box with a 1.4GHz
Celeron2 and the MSI-6120 with a 1.3GHz Celeron2, both with SLOT-T
adapters. How to find out where the bottleneck is, especially if the L2
cache is enabled or not? A lot of data is written on the log files. I'm
currently trying to find out what all numbers mean. One quick
observation though, the correctly working box is reported as: MHZ: 1409
MHz, 0.71 nanosec clock, while the problematic one is reported as: MHZ:
7 MHz, 142.86 nanosec clock. A factor of 200 in slowdown, welcome back
to the old 8086 clock speeds ;-)

  ron
Thanks,
Svante

[ron minnich]

      Those lm bench memory tests with the plots of memory access times will 
show you l1, l2, and memory boundaries. 

ron

[Svante Signell]

      Hi,

I have now run the lmbench3-0-a3 tests. For the correctly working 1.4
GHz Tualatin CPU the latency numbers shows jumps from 2ns to 6ns at 16k
array size and from 6ns to 120ns at 265k array size. I assume this
indicates correctly working level 1 and 2 caches. 

For the erroneous motherboard with a 1.3GHz Tualatin CPU the numbers are
around 400ns independent of array size. The only thing changig is that
the latency numbers increase to 440-460ns for large values of the
stride. My interpretation is that not even the L1 cache is working
properly. All other tests indicate a _very_ slow CPU, around 7MHz is
measured by lmbench (BTW how good is this value?)  compared to the
expected 1.3GHz. Two questions immediately arise.

1. Is this slowness reasonable if _no- caches are working properly?
2. If there is a problem with the on-chip voltage regulator and the CPU
clock speed is really 7MHz, as measured by lmbench, can the CPU operate
properly at this low speed. I thought there was a _lower_ limit as well
as an upper limit for the operating frequency?

Svante
 
On Fri, 2003-11-07 at 06:04, ron minnich wrote:
  Those lm bench memory tests with the plots of memory
access times will 
 show you l1, l2, and memory boundaries. 
 
 ron
 
 _______________________________________________
 Linuxbios mailing list
 Linuxbios(a)clustermatic.org
 http://www.clustermatic.org/mailman/listinfo/linuxbios

[Takeshi Sone]

      On Fri, Nov 14, 2003 at 08:26:55AM +0100, Svante Signell wrote:
  For the erroneous motherboard with a 1.3GHz Tualatin
CPU the numbers are
 around 400ns independent of array size. The only thing changig is that
 the latency numbers increase to 440-460ns for large values of the
 stride. My interpretation is that not even the L1 cache is working
 properly. All other tests indicate a _very_ slow CPU, around 7MHz is
 measured by lmbench (BTW how good is this value?)  compared to the
 expected 1.3GHz. Two questions immediately arise.
 
 1. Is this slowness reasonable if _no- caches are working properly?
 2. If there is a problem with the on-chip voltage regulator and the CPU
 clock speed is really 7MHz, as measured by lmbench, can the CPU operate
 properly at this low speed. I thought there was a _lower_ limit as well
 as an upper limit for the operating frequency?
What do these commands say?

    cat /proc/mtrr
    cat /proc/cpuinfo

-- 
Takeshi

[Svante Signell]

      On Fri, 2003-11-14 at 08:41, Takeshi Sone wrote:
  On Fri, Nov 14, 2003 at 08:26:55AM +0100, Svante
Signell wrote:
  For the erroneous motherboard with a 1.3GHz
Tualatin CPU the numbers are
 around 400ns independent of array size. The only thing changig is that
 the latency numbers increase to 440-460ns for large values of the
 stride. My interpretation is that not even the L1 cache is working
 properly. All other tests indicate a _very_ slow CPU, around 7MHz is
 measured by lmbench (BTW how good is this value?)  compared to the
 expected 1.3GHz. Two questions immediately arise.
 
 1. Is this slowness reasonable if _no- caches are working properly?
 2. If there is a problem with the on-chip voltage regulator and the CPU
 clock speed is really 7MHz, as measured by lmbench, can the CPU operate
 properly at this low speed. I thought there was a _lower_ limit as well
 as an upper limit for the operating frequency?
 
 What do these commands say?
 
     cat /proc/mtrr
     cat /proc/cpuinfo
Normal output: 1.4GHz Tualatin 
cat/proc/mtrr:
reg00: base=0x00000000 (   0MB), size= 256MB: write-back, count=1
reg01: base=0xe4000000 (3648MB), size=   8MB: write-combining, count=1

# Faulty system:
cat /proc/mtrr
cat: /proc/mtrr: No such file or directory

Faulty system:
$ cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 11
model name      : Intel(R) Celeron(TM) CPU                1300MHz
stepping        : 4
cpu MHz         : 1340.197
cache size      : 256 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 mmx fxsr sse
bogomips        : 2641.10

[Takeshi Sone]

      On Fri, Nov 14, 2003 at 10:46:00PM +0100, Svante Signell wrote:
  # Faulty system:
 cat /proc/mtrr
 cat: /proc/mtrr: No such file or directory
I guess the BIOS does not initialize the MTRR, and all RAM is uncached.
(MTRR is the registers that tell CPU where to cache)

-- 
Takeshi

[ron minnich]

      On Sun, 16 Nov 2003, Takeshi Sone wrote:

  On Fri, Nov 14, 2003 at 10:46:00PM +0100, Svante
Signell wrote:
  # Faulty system:
 cat /proc/mtrr
 cat: /proc/mtrr: No such file or directory
 
 I guess the BIOS does not initialize the MTRR, and all RAM is uncached.
 (MTRR is the registers that tell CPU where to cache)

no, even if bios does not set mtrr, those registers exist, and are 
readable. Something weird is going on here!

ron
is going on here.

[Svante Signell]

      I did boot another kernel and for that kernel there was one entry for
mtrr, so this seems to work. However, now I have tried executing both
the mtrr and cache activation code, and when coming to any inline
assembly code the program exits with a segfault :( All commented out
calls have been tried one after the other by single-stepping with gdb. 

Below is the main progam I used:

#include <mem.h>
main()
{
  struct mem_range mem;
  int res = iopl(3);
  if(res) {error();exit(-1);}
  //  cache_enable();
  //  p6_configure_l2_cache();
  cache_on(mem);
}
 
On Sat, 2003-11-15 at 20:54, ron minnich wrote:
  On Sun, 16 Nov 2003, Takeshi Sone wrote:
 
  On Fri, Nov 14, 2003 at 10:46:00PM +0100, Svante
Signell wrote:
  # Faulty system:
 cat /proc/mtrr
 cat: /proc/mtrr: No such file or directory
 
 I guess the BIOS does not initialize the MTRR, and all RAM is uncached.
 (MTRR is the registers that tell CPU where to cache)
 
 
 no, even if bios does not set mtrr, those registers exist, and are 
 readable. Something weird is going on here!
 
 ron
 is going on here. 
 
 _______________________________________________
 Linuxbios mailing list
 Linuxbios(a)clustermatic.org
 http://www.clustermatic.org/mailman/listinfo/linuxbios

[Svante Signell]

      Do I need to use gcc-2.95.x instead of gcc-3.3.2 to make the inline
assembly run OK? Or is there something about 16bit mode versus 32bit
mode?

On Sun, 2003-11-16 at 11:14, Svante Signell wrote:
  I did boot another kernel and for that kernel there
was one entry for
 mtrr, so this seems to work. However, now I have tried executing both
 the mtrr and cache activation code, and when coming to any inline
 assembly code the program exits with a segfault :( All commented out
 calls have been tried one after the other by single-stepping with gdb. 
 
 Below is the main progam I used:
 
 #include <mem.h>
 main()
 {
   struct mem_range mem;
   int res = iopl(3);
   if(res) {error();exit(-1);}
   //  cache_enable();
   //  p6_configure_l2_cache();
   cache_on(mem);
 }
  
 On Sat, 2003-11-15 at 20:54, ron minnich wrote:
 > On Sun, 16 Nov 2003, Takeshi Sone wrote:
 > 
 > > On Fri, Nov 14, 2003 at 10:46:00PM +0100, Svante Signell wrote:
 > > > # Faulty system:
 > > > cat /proc/mtrr
 > > > cat: /proc/mtrr: No such file or directory
 > > 
 > > I guess the BIOS does not initialize the MTRR, and all RAM is uncached.
 > > (MTRR is the registers that tell CPU where to cache)
 > 
 > 
 > no, even if bios does not set mtrr, those registers exist, and are 
 > readable. Something weird is going on here!
 > 
 > ron

[Takeshi Sone]

      On Tue, Nov 25, 2003 at 08:34:22PM +0100, Svante Signell wrote:
  Do I need to use gcc-2.95.x instead of gcc-3.3.2 to
make the inline
 assembly run OK? Or is there something about 16bit mode versus 32bit
 mode?
I bet it's not the compiler problem.
I guess it's a kernel-mode vs. user-mode problem.
I'm not very sure but some instructions like cache manupilation
need to be run in kernel-mode, even if IOPL=3.
If such instructions executed in user-mode, it results in segfault.
So you have to run your cache activation code in the kernel, either
put that code in the kernel itself or to make a kernel module to do it.

However, I don't know what exact code you need to enable the cache,
given that MTRR is working..

  On Sun, 2003-11-16 at 11:14, Svante Signell wrote:
 > I did boot another kernel and for that kernel there was one entry for
 > mtrr, so this seems to work. However, now I have tried executing both
 > the mtrr and cache activation code, and when coming to any inline
 > assembly code the program exits with a segfault :( All commented out
 > calls have been tried one after the other by single-stepping with gdb. 
 > 
 > Below is the main progam I used:
 > 
 > #include <mem.h>
 > main()
 > {
 >   struct mem_range mem;
 >   int res = iopl(3);
 >   if(res) {error();exit(-1);}
 >   //  cache_enable();
 >   //  p6_configure_l2_cache();
 >   cache_on(mem);
 > }
 >  
 > On Sat, 2003-11-15 at 20:54, ron minnich wrote:
 > > On Sun, 16 Nov 2003, Takeshi Sone wrote:
 > > 
 > > > On Fri, Nov 14, 2003 at 10:46:00PM +0100, Svante Signell wrote:
 > > > > # Faulty system:
 > > > > cat /proc/mtrr
 > > > > cat: /proc/mtrr: No such file or directory
 > > > 
 > > > I guess the BIOS does not initialize the MTRR, and all RAM is uncached.
 > > > (MTRR is the registers that tell CPU where to cache)
-- 
Takeshi

[ron minnich]

      what I did to test this code was to build a kernel module for my linux, 
with this code inside, and insmod the kernel module.

ron

[Svante Signell]

      Ron and Takeshi,

Thanks for the tip. I'll try that next. Any pointers how to create a
kernel module? So far I have only been writing code for user space.

On Tue, 2003-11-25 at 22:06, ron minnich wrote:
  what I did to test this code was to build a kernel
module for my linux, 
 with this code inside, and insmod the kernel module.
 
 ron
 
 _______________________________________________
 Linuxbios mailing list
 Linuxbios(a)clustermatic.org
 http://www.clustermatic.org/mailman/listinfo/linuxbios

[Svante Signell]

      I have now made a small kernel module based on l2_cache.c giving the
following output:

Nov 30 17:46:56 cl-dual kernel: Configuring L2 cache...CPU signature of
6b0 so no L2 cache configuration
Nov 30 17:46:56 cl-dual kernel: Enable Cache
Nov 30 17:46:56 cl-dual kernel: done.
Nov 30 17:46:56 cl-dual kernel:  cache_on  installed

No speed-up seen. Extremely slow as before. Any hints? mtrr is OK, I
believe. Is it the microcode??

The processor is an 1.3GHz Celeron Tualatin, with CPUID: 6b0. According
to the code in l2_cache.c newer CPUs than Coppermine (680) does not need
the L2 setup code. Is this the case?
if (signature < 0x630 || signature >= 0x680) {
  printk_debug("CPU signature of %x so no L2 cache configuration\n",
signature);
  goto done;

I few questions:
1. Does a kernel module have to be a standalone object without linking
stage?
2. How to add libraries to link with, if unresolved externals show up.
3. How to create a kernel module consisting of more than one object
file. Now I include the needed source files into the main one.
4. The cflags used are:
CFLAGS = -D__KERNEL__ -DMODULE -I ./include -I$/usr/src/linux/include -I
/usr/src/kernel-headers-2.4.22-1 -O2 -Wall -g
5. My module code looks like:
cat cache_on.c

#include <linux/module.h>
#include <linux/kernel.h>
(#include source files and other header files)

#define PFX " cache_on "

int init_module(void)
{
 p6_configure_l2_cache();
 printk(KERN_INFO PFX " installed \n");
 return 0;
}

void cleanup_module(void)
{
 printk(KERN_INFO PFX " removed\n");
}

On Tue, 2003-11-25 at 22:56, Svante Signell wrote:
  Ron and Takeshi,
 
 Thanks for the tip. I'll try that next. Any pointers how to create a
 kernel module? So far I have only been writing code for user space.
 
 On Tue, 2003-11-25 at 22:06, ron minnich wrote:
  what I did to test this code was to build a
kernel module for my linux, 
 with this code inside, and insmod the kernel module.
 
 ron
 
 _______________________________________________
 Linuxbios mailing list
 Linuxbios(a)clustermatic.org
 http://www.clustermatic.org/mailman/listinfo/linuxbios
_______________________________________________
 Linuxbios mailing list
 Linuxbios(a)clustermatic.org
 http://www.clustermatic.org/mailman/listinfo/linuxbios

[Denis Dowling]

      Hi Svante,

----- Original Message ----- 
From: "Svante Signell" <svante.signell(a)telia.com>
To: "ron minnich" <rminnich(a)lanl.gov>
Cc: "Takeshi Sone" <ts1(a)tsn.or.jp>jp>; <linuxbios(a)clustermatic.org>
Sent: Monday, December 01, 2003 10:14 AM
Subject: Re: Level 2 cache activation code?


 
 I have now made a small kernel module based on l2_cache.c giving the
 following output:

 Nov 30 17:46:56 cl-dual kernel: Configuring L2 cache...CPU signature of
 6b0 so no L2 cache configuration
 Nov 30 17:46:56 cl-dual kernel: Enable Cache
 Nov 30 17:46:56 cl-dual kernel: done.
 Nov 30 17:46:56 cl-dual kernel:  cache_on  installed

 No speed-up seen. Extremely slow as before. Any hints? mtrr is OK, I
 believe. Is it the microcode??

 The processor is an 1.3GHz Celeron Tualatin, with CPUID: 6b0. According
 to the code in l2_cache.c newer CPUs than Coppermine (680) does not need
 the L2 setup code. Is this the case?
This was based on the assumption that all CPU from the coppermine forward
had the cache integrated onto the CPU die. Is this the case with your CPU.
Is it just a single large CPU on the slot1 pcb or does there look to be
cache chips mounted on the board as well?

  if (signature < 0x630 || signature >= 0x680) {
   printk_debug("CPU signature of %x so no L2 cache configuration\n",
 signature);
   goto done;
You could always just drop this test and see what happens later. If the CPU
does have external cache chips then this code might just work in
initiallising the cache.
 
 I few questions:
 1. Does a kernel module have to be a standalone object without linking
 stage?
Yes just an object file compiled with the correct module flags.

  2. How to add libraries to link with, if unresolved
externals show up.
They should not. It is possible to add libraries but generally it is simpler
to keep all of the module code in the one file. Modules can reference other
modules if required. The depmod program will then load all required modules.

  3. How to create a kernel module consisting of more
than one object
 file. Now I include the needed source files into the main one.
Generally this is the easiest way to test this.

  4. The cflags used are:
 CFLAGS = -D__KERNEL__ -DMODULE -I ./include -I$/usr/src/linux/include -I
 /usr/src/kernel-headers-2.4.22-1 -O2 -Wall -g
Have a look at a normal kernel compile and compare these arguments against
what is used for the other modules.

  5. My module code looks like:
 cat cache_on.c

 #include <linux/module.h>
 #include <linux/kernel.h>
 (#include source files and other header files)

 #define PFX " cache_on "

 int init_module(void)
 {
  p6_configure_l2_cache();
  printk(KERN_INFO PFX " installed \n");
  return 0;
 }

 void cleanup_module(void)
 {
  printk(KERN_INFO PFX " removed\n");
 }
Looks fine. Turn on as much debugging in the l2_cache code as possible and
post to me and I will decode. Need to be able to see all of the printk_debug
messages.

Regards,
Denis

[Svante Signell]

      On Mon, 2003-12-01 at 00:47, Denis Dowling wrote:
  Hi Svante,
 
 ----- Original Message ----- 
 From: "Svante Signell" <svante.signell(a)telia.com>
 To: "ron minnich" <rminnich(a)lanl.gov>
 Cc: "Takeshi Sone" <ts1(a)tsn.or.jp>jp>; <linuxbios(a)clustermatic.org>
 Sent: Monday, December 01, 2003 10:14 AM
 Subject: Re: Level 2 cache activation code?
 
 The processor is an 1.3GHz Celeron Tualatin, with CPUID: 6b0. According
 to the code in l2_cache.c newer CPUs than Coppermine (680) does not need
 the L2 setup code. Is this the case?
 
 This was based on the assumption that all CPU from the coppermine forward
 had the cache integrated onto the CPU die. Is this the case with your CPU.
 Is it just a single large CPU on the slot1 pcb or does there look to be
 cache chips mounted on the board as well?
The CPU is placed on a socket 370 to slot
1 adapter (SLOT-T) from Upgradeware. 
No, there are no external cache chips on the MOBO. BTW, the MOBO is a dual CPU 82443BX 
board (MSI-6120). It runs perfectly well with dual Celerons (Mendocino). Also, the CPU 
placed on the SLOT-T adapter works perfectly well with other (single CPU) boards.

  if (signature
< 0x630 || signature >= 0x680) {
   printk_debug("CPU signature of %x so no L2 cache configuration\n",
 signature);
   goto done;
 
 You could always just drop this test and see what happens later. If the CPU
 does have external cache chips then this code might just work in
 initiallising the cache.
I have disabled the test and it seems the cache activation
seem to work,
see below. The slowness remains however :-( 

Dec  4 14:39:56 cl-dual kernel: Configuring L2 cache...Disable Cache
Dec  4 14:39:56 cl-dual kernel: rdmsr(0x17) = 0, 84320000
Dec  4 14:39:56 cl-dual kernel: L2 Cache latency is 1
Dec  4 14:39:56 cl-dual kernel: Sending 0 to set_l2_register4
Dec  4 14:39:56 cl-dual kernel: L2 ECC Checking is enabled
Dec  4 14:39:56 cl-dual kernel: L2 Physical Address Range is 512M
Dec  4 14:39:56 cl-dual kernel: Maximum cache mask is 2000
Dec  4 14:39:56 cl-dual kernel: L2 Cache Mask is 0
Dec  4 14:39:56 cl-dual kernel: read_l2(2) = 0
Dec  4 14:39:56 cl-dual kernel: write_l2(2) = 0
Dec  4 14:39:56 cl-dual kernel: Enable Cache
Dec  4 14:39:56 cl-dual kernel: L2 Cache size is 256K
Dec  4 14:39:56 cl-dual kernel: L2 Cache lines initialized
Dec  4 14:39:56 cl-dual kernel: Disable Cache
Dec  4 14:39:56 cl-dual kernel: Enable Cache
Dec  4 14:39:56 cl-dual kernel: done.
Dec  4 14:39:56 cl-dual kernel:  cache_on  installed

  Looks fine. Turn on as much debugging in the l2_cache
code as possible and
 post to me and I will decode. Need to be able to see all of the printk_debug
 messages.
 
 Regards,
 Denis
What is wrong here:
Not caches
Not mtrr
microcode??
anything else??
HW fault, i.e. the VRM does not work as expected, even though lm-sensors
are reporting correct voltages.
The BIOS is not supporting Coppermine and later CPUs. AMI BIOS V2.0 from
(MSI)

Soon giving up...

[Takeshi Sone]

      On Mon, Dec 01, 2003 at 12:14:14AM +0100, Svante Signell wrote:
  No speed-up seen. Extremely slow as before. Any hints?
mtrr is OK, I
 believe. Is it the microcode??
You could try the microcode driver of Linux or code from LinuxBIOS.

  3. How to create a kernel module consisting of more
than one object
 file. Now I include the needed source files into the main one.
ld -o module.o -r obj1.o obj2.o

-- 
Takeshi

[ron minnich]

      On Fri, 14 Nov 2003, Svante Signell wrote:

  I have now run the lmbench3-0-a3 tests. For the
correctly working 1.4
 GHz Tualatin CPU the latency numbers shows jumps from 2ns to 6ns at 16k
 array size and from 6ns to 120ns at 265k array size. I assume this
 indicates correctly working level 1 and 2 caches.
yes.

  For the erroneous motherboard with a 1.3GHz Tualatin
CPU the numbers are
 around 400ns independent of array size. The only thing changig is that
 the latency numbers increase to 440-460ns for large values of the
 stride. My interpretation is that not even the L1 cache is working
 properly. All other tests indicate a _very_ slow CPU, around 7MHz is
 measured by lmbench (BTW how good is this value?)  compared to the
 expected 1.3GHz. Two questions immediately arise.
weird. I have no idea what's going on here. Something is really wrong.

ron

      ron minnich wrote:
  On Fri, 14 Nov 2003, Svante Signell wrote:
 
 
 I have now run the lmbench3-0-a3 tests. For the
correctly working 1.4
GHz Tualatin CPU the latency numbers shows jumps from 2ns to 6ns at 16k
array size and from 6ns to 120ns at 265k array size. I assume this
indicates correctly working level 1 and 2 caches.
 
 
 yes.
 
 
 For the erroneous motherboard with a 1.3GHz
Tualatin CPU the numbers are
around 400ns independent of array size. The only thing changig is that
the latency numbers increase to 440-460ns for large values of the
stride. My interpretation is that not even the L1 cache is working
properly. All other tests indicate a _very_ slow CPU, around 7MHz is
measured by lmbench (BTW how good is this value?)  compared to the
expected 1.3GHz. Two questions immediately arise.
 
 
 weird. I have no idea what's going on here. Something is really wrong.
I don't think I can comment with much precision here, but...

My early experience with disabled cache is that the system gets REALLY 
slow.  PIII's (I  think) will read a full cache line for every word it 
needs.  That means that if you have a 32 byte cache line and read the 
entire line one 32 bit word at a time (8 accesses) the PIII will read 
that entire cache line 8 times, one for each word access.  This may 
apply only to code fetches.

It gets really rediculous when this is happening while executing code 
over the ISA bus (from ROM).

Cheers!
Ty

-- 
Tyson D Sawyer                             iRobot Corporation
Senior Systems Engineer                    Military Systems Division
tsawyer(a)irobot.com                         Robots for the Real World
603-654-3400 ext 206                       http://www.irobot.com