Level 2 cache activation code?

[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