During the last weeks I identified 64 patches for ZFS which are in 8-stable but not in 7-stable. For 56 of them I had a deeper look and most of them are commited now to 7-stable. The ones of those 56 which I did not commit are not applicable to 7-stable (infrastructure differences between 8 and 7).
Unfortunately this did not solve the stability problems I have on a 7-stable system.
I also committed a diff reduction (between 8-stable and 7-stable) patch which also fixed some not so harmless mismerges (mem-leak and initializing the same mutex twice at different places). No idea yet if it helps in my case.
I also want to merge the new arc reclaim logic from head to 8-stable and 7-stable. Maybe I can do this tomorrow.
Currently I run a test with a kernel where the shared locks for ZFS are switched to exclusive locks.
Due to the problems with a 7-stable machine, I had a look at some unmerged fixes for ZFS (58 changes not merged).
I backported some of those changes from 8-stable to 7-stable, I have this running on one 7-stable machine. I would like to get some more feedback for it (even an
The 7-stable system on which I have stability problems after an update from 7.1 to 7.2/7-stable is now semi-stable.
The watchdog reboots after one minute of no reaction (currently it is able to run 3
This WE I was told that FreeNAS seems to want to move from FreeBSD to Linux (since then it seems there could be a linux and a FreeBSD version). One of the reasons seems to be a missing sensors framework.
As I was committing a port of the OpenBSD sensors framework (produced as part of the Google Summer of Code 2007) to FreeBSD and had to remove it afterwards because one committer complained very loudly, I was asked what the status of this is.
The short status is: Nobody is doing something about it.
Before I explain the long status, I give
Yesterday I committed the v4l support into the linuxulator (in 9-current). Part of this was the import of the v4l header from linux. We have the permission to use it, it is not licensed via GPL. This means we can use it in FreeBSD native drivers, and they are even allowed to be compiled into GENERIC (but I doubt we have a driver which could provide the v4l interface in GENERIC).
The code I committed is
I committed my patch for tools/kerneldoc/subsys. Except for not generating the PDF part, this is now the same config which I use to generate the online version. While writing the commit log I noticed that I did more changes than I thought
I managed to get some time to setup an automated generation of the doxygen docs for kernel subsystems of FreeBSD on my webserver.
Every night/morning (German timezone) the sources will be updated, and the docs get regenerated (this takes some time). Currently this depends upon some patches to the makefile and doxygen config files in tools/kerneldoc/subsys. Everything is generated directly in the place where the webserver will look for to deliver the pages, so if you browse this in the middle of the generation, the content may not be consistent (yet).
Please be nice to the webserver and do not mirror this. You can generate this yourself very easy. Assuming you have the FreeBSD source on a local hard disk, you just need to download the patch from http://www.Leidinger.net/FreeBSD/current-patches/ (if you do not find dox.diff, update your FreeBSD sources and everything will be OK), apply the patch, cd into tools/kerneldoc/subsys and run