Monthly Archive for May, 2007
As people might have noticed, it's been awfully quiet here. That is mostly because I've been so damn busy with my new project: FreeBSD/xen. I assume people will know what Xen is, if not, wikipedia is your friend :-) Quite some time ago, Kip Macy has been working on the port, but eventually started working on other things. I'm trying to continue his work, and currently, most of it will be in the Perforce branch. Mind that the current focus is the domU support (ie. using FreeBSD as a guest OS), but dom0 (using FreeBSD as the host OS) is of course also TODO :-) So, how far are we? Quite far ... I managed to get the original port working on Xen 3.1. However, this port was quite old (it was based on a CURRENT tree of 9 months old), so current work is in getting it working on today's CURRENT. Currently, it boots again, and the Xen-specific device drivers work as well! However, the process map (pmap) stuff has been quite extensively changed; and I believe FreeBSD (ab)uses paging table entries in order to build a freelist (which it does by not marking the pages in question valid, so they can't be accessed unless it has actually mapped them. As it maps the pages to virtual addresses, Xen seems to choke and abort on this... I've contacted Alan Cox, the FreeBSD VM guru, to see if this analysis is correct; if so, I think a patch to Xen may be in order. Currently, mapping all pages to NULL 'fixes' the problem, but triggers out-of-memory messages later on (which makes perfect sense). I'm glad, though, that I managed to get interrupts fully working again today. Xenbus works again, and it can even find my virtual harddisk and mount it! However, once the true process-running takes place, it crashes due to the incomplete pmap stuff. Either way, I'll update my blog with the progress as it's being made. The goal is to have this work ready for inclusion in 7-RELEASE; this will take a lot of work but I'll do my best to get it ready in time!
During the last couple of weeks I have converted two more drivers (vge(4) and axe(4)) to support ALTQ(4). Additionaly, Max Laier has converted aue(4).
Although ALTQ has been a part of FreeBSD for almost 3 years now, there are still lots of drivers that do not support it yet. “Why is that?” you may ask. Actually the driver modifications necessary are minimal, so no problem there. What is missing are people with the hardware to test the changes to make sure that
- they actually work
- they do not break driver operation without ALTQ
Testing ALTQ patches does not take a lot of time, the procedure is outlined at http://people.freebsd.org/~mlaier/ALTQ_driver . The following is a (non-exhaustive) list of drivers that have not yet been converted to support ALTQ. If you own any hardware that is supported by one of these drivers, please consider contacting me for a patch to test, or to donate said hardware if you can spare it.
- arl(4) (probably obsolete)
- cdce(4)
- cnw(4) (probably obsolete)
- cue(4)
- cue(4)
- cs(4) (probably obsolete)
- cxgb(4)
- ex(4) (probably obsolete)
- fe(4) (probably obsolete)
- gem(4)
- ie(4) (probably obsolete)
- ixgb(4)
- kue(4)
- lge(4)
- pcn(4)
- nge(4)
- rue(4)
- sn(4)
- snc(4)
- ti(4)
- tl(4)
- tx(4)
- txp(4)
- wb(4)
- xe(4)
Without much ado, our resident gcc expert Alexander Kabaev imported GCC 4.2.0 (2007-05-14, SVN level 124707) into development branch of FreeBSD. This means that FreeBSD 7.0 will ship with a modern C compiler again, and that a lot of ports will not compile on it (unless fixed, of course).
In related news, X.Org 7.2 import to the ports tree should happen in next 24 hours.
Ariff Abdullah, our malaysian committer, has brought the driver for High Definition Audio (HDA) chips to FreeBSD 6-STABLE. Yay!
Half a year ago, when he first added that driver to CURRENT, he vower never to MFC it. Never say never, I guess.
It’s ports tree freeze time and Novel has yet to announce it but Mono 1.2.4 is in the BSD# CVS repo ready and waiting. If you’re interested in Mono on FreeBSD please use and test it to make sure the update goes smoothly and there are no surprises. You can see the BSD# homepage and instructions for using mono-merge to use the ports in the BSD# repo.
Today I decided to set up some syslog logging of my router.
I enabled syslog logging on the router and pointed it in direction of the syslogd box.
I could see that the syslog packets got to the interface of the syslogd box, but nothing in the logs.
First removed -s from syslogd_flags in /etc/rc.conf, then added -a syslog_src_ip/bitmask to syslogd_flags.
Still nothing in the logs.
Then added -dv to the flags, and found that i got:
rejected in rule 0 due to port mismatch
Well after some searching i found that one could add :* to the -a ip:bitmask line.
Did so and messages got into syslogd, but they did not end up in the right log file.
‘+hostname’ to the rescue, added it at the end of /etc/syslog.conf, still nothing in the right logfile.
Then noticed that the logfile specified in the +hostname block was assigned to the last !program block.
I figured that the right order of /etc/syslog.conf should be:
1) General logging.
2) +hostname block(s).
3) !program block(s).
If not in this order it will not work.
