Since my call for testing the extended linuxulator in FreeBSD–current we got not much negative responses. Ping doesn’t work on the linux side (fixed in p4), ordinary network connections (e.g. downloading some stuff) works fine. There seems to be a deadlock on SMP systems when compiling a lot of stuff in parallel (e.g. using emerge in a gentoo–chroot with MAKEFLAGS=-j4), this is being under investigation by Roman. Compiling stuff serially on an UP system works just fine so far.
I’m wondering if the lack of responses means that everything is running just fine, or that nobody is giving it a try. So far the daily use of linux programs (acroread, linux-firefox, …) with 2.6.16 compatibility seems to just work fine on UP and SMP systems and currently I don’t see a reason to not switch the default in i386 in a week.
Jung-uk Kim is working on the linux-TLS on amd64 part. ATM he is chasing bugs. It looks we can get feature parity between i386/linux and amd64/linux32 soon.
Intron did send in a patch for the linux-aio stuff. Now I just need to get time to have a look at it.
, linux aio
, linux programs
, linux side
, negative responses
, network connections
, smp systems
Ryan got permission to extend the work he did in the SoC as part of a class at university. He wants to push down the new mixer stuff to the driver level now. He does it in the emu10kx driver (because he has such a card) and maybe in another driver. This will allow to use a lot more of the features a card offers. Yuriy (author of the emu10kx driver) has some work in the driver scheduled too, so I offered him a p4 account so that they can collaborate. As of this writting it is up to the p4 admins to grant an account.
And while I’m at it: Konstantin (env24* driver author) got his p4 account already. He tries to get some time to commit his work in progress there.
, driver level
, new stuff
, work in progress
Shaun had some unrelated software problems so he wasn’t able to do the paperwork requested by Real. Those problems seem to be fixed and he expects to get some time to do the paperwork “soon”. Real is looking forward to this as the FreeBSD build is much better now.
, software problems
In multimedia@ we have a discussion about the envy24* chips. One question is how to convince companies to provide some technical information or at least free hardware samples. As part of the answer I pointed to http://www.bsdstats.org/ which may be able to provide some numbers (e.g. envy24* chips without a matching driver) which may help in negotiating some stuff with a company. Unfortunately not many envy24 chips show up there. Part of the problem may be that not enough people run the bsdstats port (and enable periodic reporting of at least the devices).
So do you have any unsupported hardware (not only limited to soundcards) or some hardware which is still up-to-date but lacks some features in the driver (this is at least the case for all recent soundcards like envy24* or HDA based ones)? Fine, run bsdstats and enable the periodic reporting. Maybe we are able to get enough numbers to show to companies so that they think it would be financially beneficial to support us in some way (free hardware, docs, technical hints, whatever).
Oh… while we are at it, the ALSA people added support for some envy24 based cards based upon the reverse engineering effort which was needed to write our driver as it is now. So if you are working for a company and reading this: if you support us, you get the Linux stuff for free too. And as an additional bonus, you can show a working driver without any bad legal strings (e.g. GPL infection) to OEMs. So go and calculate how much sales you can do with embedded stuff and come back to us with some technical hints and/or free hardware (it costs some few bucks for you to provide this: not much if it fails but a large amount of return if it works out).
, free hardware
, hardware companies
, hardware docs
, hardware samples
, reverse engineering
, technical information
, unsupported hardware
Today I committed two patches which fix the last two panics we know about in the 2.6.16 emulation. Now we need testers. Here’s the text of the mail I did send to current@ a few moments ago:
Tags: code paths
today I committed the last fixes for the showstopper problems (panics) in the linux 2.6.16 emulation. I intend to switch the default version to 2.6.16 on i386 “soon” (see below), so please help testing it.
More recent linux distributions (e.g. FC5) require a 2.6 kernel and don’t work with 2.4.2 anymore. And because FC4 is “abandon-ware” (no security fixes from fedoralegacy anymore), getting 2.6.16 emulation up an running is very important.
If you use a linux program, please add compat.linux.osrelease=2.6.16 to /etc/sysctl.conf (my desktop is running with 2.6.16 emulation since some days already). After the next boot (or after running “sysctl compat.linux.osrelease=2.6.16″, please make sure no linux program is running already) any linux program will start with a linux kernel version of 2.6.16 instead of 2.4.2. The default linux base port (FC4) will then use different code paths (e.g. within glibc). In case you want to switch back to the 2.4.2 emulation without a reboot, please make sure no linux program is running anymore.
So far we fixed all known/repeatable problems with acroread, realplayer, skype and linux firefox. If you encounter strange behavior with any linux program, please tell us (firstname.lastname@example.org) which program you used, how to repeat the problem, what the problem is, and if it only is visible with 2.6.16 or with 2.4.2 too. You should also watch out for messages in the dmesg (unimplemented system calls or other stuff, this is used to determine the priority of missing syscalls). Please also have a look at http://wiki.FreeBSD.org/linux-kernel, I intend to document the known problems there. If you find your problem there, please tell us about it if you are willing to test fixes.
We are specially interested in reports (good or bad) on SMP systems. Please beat the hell out of the linuxulator!
On amd64 systems we have not the same functionality as on i386, missing are futexes and TLS. In P4 we already have the futex part covered, but the TLS part is still missing (anyone with a clue about the kernel side of TLS on amd64 is welcome to give a hint or two to jkim@ and rdivacky@). So if you get a message about missing futexes or TLS on amd64: we know about it (testers for the futex stuff are welcome, but first you need to use a program which uses futexes and complains).
As long as we get problem reports with 2.6.16 I will not switch the default to 2.6.16. If we don’t get a report at all, I will switch the default on i386 to 2.6.16 in two weeks. If we get some problem reports, we will push back the switch a little bit depending on the severity of the problem.
, default version
, linux distributions
, linux kernel version
, linux program
, repeatable problems
, strange behavior