Pro­gress in the linux 2.6.x com­pat­ib­il­ity

Since my call for test­ing the ex­ten­ded linuxu­lat­or in FreeBSD-cur­rent we got not much neg­at­ive re­sponses. Ping doesn’t work on the linux side (fixed in p4), or­din­ary net­work con­nec­tions (e.g. down­load­ing some stuff) works fine. There seems to be a dead­lock on SMP sys­tems when com­pil­ing a lot of stuff in par­al­lel (e.g. us­ing emerge in a gentoo–ch­root with MAKEFLAGS=-j4), this is be­ing un­der in­vest­ig­a­tion by Ro­man. Com­pil­ing stuff seri­ally on an UP sys­tem works just fine so far.

I’m won­der­ing if the lack of re­sponses means that everything is run­ning just fine, or that nobody is giv­ing it a try. So far the daily use of linux pro­grams (acror­ead, linux-​firefox, …) with 2.6.16 com­pat­ib­il­ity seems to just work fine on UP and SMP sys­tems and cur­rently I don’t see a reas­on to not switch the de­fault in i386 in a week.

Jung-​uk Kim is work­ing on the linux-​TLS on amd64 part. ATM he is chas­ing bugs. It looks we can get fea­ture par­ity between i386/​linux and amd64/​linux32 soon.

In­tron did send in a patch for the linux-​aio stuff. Now I just need to get time to have a look at it.

Up­com­ming sound stuff

Ry­an got per­mis­sion to ex­tend the work he did in the SoC as part of a class at uni­ver­sity. He wants to push down the new mix­er stuff to the driver level now. He does it in the emu10kx driver (be­cause he has such a card) and maybe in an­oth­er driver. This will al­low to use a lot more of the fea­tures a card of­fers. Yur­iy (au­thor of the emu10kx driver) has some work in the driver sched­uled too, so I offered him a p4 ac­count so that they can col­lab­or­ate. As of this writ­ting it is up to the p4 ad­mins to grant an ac­count.

And while I’m at it: Kon­stantin (env24* driver au­thor) got his p4 ac­count already. He tries to get some time to com­mit his work in pro­gress there.

Status of the Real­Play­er stuff

Shaun had some un­re­lated soft­ware prob­lems so he wasn’t able to do the pa­per­work re­ques­ted by Real. Those prob­lems seem to be fixed and he ex­pects to get some time to do the pa­per­work “soon”. Real is look­ing for­ward to this as the FreeBSD build is much bet­ter now.

A way to en­cour­age hard­ware com­pan­ies to sup­port *BSD

In multimedia@ we have a dis­cus­sion about the envy24* chips. One ques­tion is how to con­vince com­pan­ies to provide some tech­nic­al in­form­a­tion or at least free hard­ware samples. As part of the an­swer I poin­ted to http://​www​.bsdstats​.org/ which may be able to provide some num­bers (e.g. envy24* chips without a match­ing driver) which may help in ne­go­ti­at­ing some stuff with a com­pany. Un­for­tu­nately not many envy24 chips show up there. Part of the prob­lem may be that not enough people run the bsdstats port (and en­able peri­od­ic re­port­ing of at least the devices).

So do you have any un­sup­por­ted hard­ware (not only lim­ited to sound­cards) or some hard­ware which is still up-​to-​date but lacks some fea­tures in the driver (this is at least the case for all re­cent sound­cards like envy24* or HDA based ones)? Fine, run bsdstats and en­able the peri­od­ic re­port­ing. Maybe we are able to get enough num­bers to show to com­pan­ies so that they think it would be fin­an­cially be­ne­fi­cial to sup­port us in some way (free hard­ware, docs, tech­nic­al hints, whatever).

Oh… while we are at it, the ALSA people ad­ded sup­port for some envy24 based cards based upon the re­verse en­gin­eer­ing ef­fort which was needed to write our driver as it is now. So if you are work­ing for a com­pany and read­ing this: if you sup­port us, you get the Linux stuff for free too. 🙂 And as an ad­di­tion­al bo­nus, you can show a work­ing driver without any bad leg­al strings (e.g. GPL in­fec­tion) to OEMs. So go and cal­cu­late how much sales you can do with em­bed­ded stuff and come back to us with some tech­nic­al hints and/​or free hard­ware (it costs some few bucks for you to provide this: not much if it fails but a large amount of re­turn if it works out).

Linuxu­lat­or in -cur­rent ready for test­ing the 2.6.16 emu­la­tion

Today I com­mit­ted two patches which fix the last two pan­ics we know about in the 2.6.16 emu­la­tion. Now we need test­ers. Here’s the text of the mail I did send to current@ a few mo­ments ago:


today I com­mit­ted the last fixes for the showstop­per prob­lems (pan­ics) in the linux 2.6.16 emu­la­tion. I in­tend to switch the de­fault ver­sion to 2.6.16 on i386 “soon” (see be­low), so please help test­ing it.

More re­cent linux dis­tri­bu­tions (e.g. FC5) re­quire a 2.6 ker­nel and don’t work with 2.4.2 any­more. And be­cause FC4 is “abandon-​ware” (no se­cur­ity fixes from fe­dor­alegacy any­more), get­ting 2.6.16 emu­la­tion up an run­ning is very im­port­ant.

If you use a linux pro­gram, please add compat.linux.osrelease=2.6.16 to /etc/sysctl.conf (my desktop is run­ning with 2.6.16 emu­la­tion since some days already). After the next boot (or after run­ning “sy­sctl compat.linux.osrelease=2.6.16”, please make sure no linux pro­gram is run­ning already) any linux pro­gram will start with a linux ker­nel ver­sion of 2.6.16 in­stead of 2.4.2. The de­fault linux base port (FC4) will then use dif­fer­ent code paths (e.g. with­in glibc). In case you want to switch back to the 2.4.2 emu­la­tion without a re­boot, please make sure no linux pro­gram is run­ning any­more.

So far we fixed all known/​repeatable prob­lems with acror­ead, real­play­er, skype and linux fire­fox. If you en­counter strange be­ha­vi­or with any linux pro­gram, please tell us (emulation@​freebsd.​org) which pro­gram you used, how to re­peat the prob­lem, what the prob­lem is, and if it only is vis­ible with 2.6.16 or with 2.4.2 too. You should also watch out for mes­sages in the dmesg (un­im­ple­men­ted sys­tem calls or oth­er stuff, this is used to de­term­ine the pri­or­ity of miss­ing sy­scalls). Please also have a look at http://​wiki​.FreeBSD​.org/​l​i​n​u​x​-​k​e​r​nel, I in­tend to doc­u­ment the known prob­lems there. If you find your prob­lem there, please tell us about it if you are will­ing to test fixes.

We are spe­cially in­ter­ested in re­ports (good or bad) on SMP sys­tems. Please beat the hell out of the linuxu­lat­or!

On amd64 sys­tems we have not the same func­tion­al­ity as on i386, miss­ing are fu­texes and TLS. In P4 we already have the fu­tex part covered, but the TLS part is still miss­ing (any­one with a clue about the ker­nel side of TLS on amd64 is wel­come to give a hint or two to jkim@ and rdivacky@). So if you get a mes­sage about miss­ing fu­texes or TLS on amd64: we know about it (test­ers for the fu­tex stuff are wel­come, but first you need to use a pro­gram which uses fu­texes and com­plains).

As long as we get prob­lem re­ports with 2.6.16 I will not switch the de­fault to 2.6.16. If we don’t get a re­port at all, I will switch the de­fault on i386 to 2.6.16 in two weeks. If we get some prob­lem re­ports, we will push back the switch a little bit de­pend­ing on the sever­ity of the prob­lem.


Fix for the showstop­per bug in the linuxu­lat­or

I got time yes­ter­day to test acror­ead with the patch from In­tron/​Kostik and … Yeah! I was not able to crash acror­ead in the 2.6.16 emu­la­tion! Great! Re­quest for wide­spread test­ing soon?!?

Now we just have to de­term­ine if we have to care about the lock­ing (I don’t know if kib@ already asked jhb@ about it) and the race con­di­tion. In case the user­land ex­hib­its very very bad pro­gram­ming and is us­ing the FD be­fore open() re­turns suc­cess­fully, the pro­gram could read data. This can only hap­pen if the pro­gram has the right per­mis­sion to this data (the open is sup­posed to fail in this case not be­cause of ac­cess re­stric­tions, but be­cause of e.g., the wrong file type).

I fore­see nice im­prove­ments in the sound­sys­tem

Ar­iffs changes two months ago to re­duce the latency in the sound­sys­tem also pre­pared the way for mul­tichan­nel sup­port and Yur­iy ad­ded mul­tichan­nel re­cord­ing to the emu10kx driver (there are some bugs ATM and it is only a proof of concept to play around with it un­til we get real mul­tichan­nel sup­port in the gen­er­ic sound code). Ry­an tries to get some time (let’s cross fin­gers!) to con­vert a driver (prob­ably the emu10kx driver) to use the new mix­er in­fra­struc­ture be­fore he has to con­cen­trate on his stud­ies again.

This looks like we could get some very nice stuff this year.