2007-04-22 10:24:23

CPU not supported

There we have it: my CPU is not currently listed. The thing attempts to look up a CPU with vendor ID 0, bus clock BUS166, idhi = 3111 and idlo = 1555. However, it seems that not a single BUS166 CPU is defined. So I wonder how FreeBSD does it?

Looking at the FreeBSD dmesg it appears that FreeBSD has found some way to retrieve the data from ACPI? Because the frequencies go down to 250MHz, and none of the frequency lists does even contain an entry for 250MHz.

Maybe I'll need to debug which entry FreeBSD chooses?

Posted by Tonnerre Lombard | Permanent link | File under: programming

2007-04-22 02:29:47

est: a small breakthrough!

Finally, a breakthrough!

machdep.est.frequency.available = 2000 1000

There are a couple of problems still with the current state of affairs though:

  1. cpu_feature2 detection is only available in NetBSD current, not in 4.0_BETA2, so it is quite hard to deduce whether or not to enable est.
  2. Currently, no infrastructure exists for calling CPU specific probing functions. i386 does it extensively, and for each CPU that actually defines this function, which is passed through multiple layers of structs. amd64 deduces that it already knows almost anything about the CPU, and doesn't probe much specific stuff. This makes the probing function small, but it also makes it uneasy to call detection functions such as p3_get_bus_clock().
  3. est appears to be missing quite a bunch of frequencies. In my case, it shows 2000 and 1000, but not 1800, 1600, etc. until 200.

This will still be a work.

Posted by Tonnerre Lombard | Permanent link | File under: programming

2007-04-22 02:00:46

Problems with NetBSD/amd64 and est

It seems that there is quite a number of issues involved with implementing Speed Stepping on NetBSD/amd64, at least in version 4.0_BETA2.

At first I got a relatively easy set of steps that have to be performed in order to implement it:

  • Move p[34]_get_bus_clock() from i386/i386/identcpu.c into x86/x86/intel_busclock.c (I used a single function merging p3 and p4).
  • Move i386/i386/est.c into x86/x86.
  • Update amd64/amd64/identcpu.c to run est_init().
  • Update some required files like x86/conf/files.x86, etc.
  • Update {amd64,i386}/conf/files.{amd64,i386}.

The first major one is the fact that support for cpu_features2 has been added only in NetBSD-current. However, threading in NetBSD-current is completely different than in 4.0_BETA2, which means that all packages have to be recompiled unless you want to have segmentation faults (bad system call) all over.

A temporary circumvention of this was to assume generally that speed stepping is supported (i.e. comment out the cpuid checks) if it is implied by the config.

However, it seems that simply calling est_init() as suggested in step 3 is not sufficient. There is still a requirement to call the *_get_bus_clock functions prior to calling est_init because est_init will assume that the system bus clock is unknown (Which is somewhat true). Thus, my current job seems to be to find out what is usually calling the cpu_info functions.

Posted by Tonnerre Lombard | Permanent link | File under: programming

2007-04-21 00:09:23

Throw away your PHP!

For a long time, it has been said that blogs, wikis and CMS systems are the domains of PHP and nothing else. However, it seems that other languages are discovering this area and are doing just fine, or, even better.

For example, Bricolage also seems to feature a blog mode. It is a Perl based CMS, and as such, performs exceptionally well. It seems that running it on a server requires much less ressources (which means that much more people are capable of accessing it in parallel) than a comparable PHP solution.

Yes, Compiled PHP can improve this situation somewhat, but compiled PHP still seems to be somewhat slower than uncompiled Perl (which is largely due to the fact that the Perl interpreter precompiles all of its code on load, so there's not much of a difference). On the other side, pre-compiling Perl is also possible, and reduces the load speed somewhat. This is only remarkable when running Perl as a CGI or something comparable, because this will require Perl modules to be loaded every time the script is called. The solution to this problem is, for example, mod_perl.

A good solution for Wikis appears to be MoinMoin. It is capable of exporting the pages to HTML once they're written, so it can be used to produce static content which can be loaded at full speed because it does not need to be regenerated all the time. This is a significant advantage over, for example, Mediawiki, which needs to go though the code required in generating a page every time it is being accessed. This slows down the server significantly.

For minimalists, there is a similarly efficient solution for blogs: Bash Blogger. It is a complete blogging engine, including RSS support, navigation links, and a Google search plugin. It should be easy though to replace it and make it link to the BSD projects search engine or other search engines instead.

One of the major problems with Bash Blogger is that it is, as the name suggests, Bash only. However, the author announces that the upcoming 0.3.6 release will also run on saner shells such as ksh. This would make it a full-featured alternative blogging engine for (POSIX-conform) nerds.

Posted by Tonnerre Lombard | Permanent link | File under: general

2007-04-21 00:07:40

C workshop at Hackers Awake

I did a little C workshop at the Hackers Awake. It covers the basics of C and programming in itself as well as process execution.

The slides and example source code can be found in the reviews category.

Posted by Tonnerre Lombard | Permanent link | File under: programming