Progress in the lin­ux 2.6.x compatibility

Since my call for test­ing the extend­ed lin­ux­u­la­tor in FreeBSD-current we got not much neg­a­tive respons­es. Ping does­n’t work on the lin­ux side (fixed in p4), ordi­nary 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. using emerge in a gentoo-chroot with MAKEFLAGS=-j4), this is being under inves­ti­ga­tion by Roman. Com­pil­ing stuff seri­al­ly on an UP sys­tem works just fine so far.

I’m won­der­ing if the lack of respons­es means that every­thing is run­ning just fine, or that nobody is giv­ing it a try. So far the dai­ly use of lin­ux pro­grams (acrore­ad, linux-firefox, …) with 2.6.16 com­pat­i­bil­i­ty seems to just work fine on UP and SMP sys­tems and cur­rent­ly I don’t see a rea­son to not switch the default 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­i­ty 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.

Upcom­ming sound stuff

Ryan got per­mis­sion to extend the work he did in the SoC as part of a class at uni­ver­si­ty. He wants to push down the new mix­er stuff to the dri­ver lev­el now. He does it in the emu10kx dri­ver (because he has such a card) and maybe in anoth­er dri­ver. This will allow to use a lot more of the fea­tures a card offers. Yuriy (author of the emu10kx dri­ver) has some work in the dri­ver sched­uled too, so I offered him a p4 account so that they can col­lab­o­rate. As of this writ­ting it is up to the p4 admins to grant an account.

And while I’m at it: Kon­stan­tin (env24* dri­ver author) got his p4 account already. He tries to get some time to com­mit his work in progress there.

Sta­tus of the RealPlay­er stuff

Shaun had some unre­lat­ed soft­ware prob­lems so he was­n’t able to do the paper­work request­ed by Real. Those prob­lems seem to be fixed and he expects to get some time to do the paper­work “soon”. Real is look­ing for­ward to this as the FreeB­SD build is much bet­ter now.

A way to encour­age hard­ware com­pa­nies 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­pa­nies to pro­vide some tech­ni­cal infor­ma­tion or at least free hard­ware sam­ples. As part of the answer I point­ed to http://www.bsdstats.org/ which may be able to pro­vide some num­bers (e.g. envy24* chips with­out a match­ing dri­ver) which may help in nego­ti­at­ing some stuff with a com­pa­ny. Unfor­tu­nate­ly not many envy24 chips show up there. Part of the prob­lem may be that not enough peo­ple run the bsd­stats port (and enable peri­od­ic report­ing of at least the devices).

So do you have any unsup­port­ed hard­ware (not only lim­it­ed to sound­cards) or some hard­ware which is still up-to-date but lacks some fea­tures in the dri­ver (this is at least the case for all recent sound­cards like envy24* or HDA based ones)? Fine, run bsd­stats and enable the peri­od­ic report­ing. Maybe we are able to get enough num­bers to show to com­pa­nies so that they think it would be finan­cial­ly ben­e­fi­cial to sup­port us in some way (free hard­ware, docs, tech­ni­cal hints, whatever).

Oh… while we are at it, the ALSA peo­ple added sup­port for some envy24 based cards based upon the reverse engi­neer­ing effort which was need­ed to write our dri­ver as it is now. So if you are work­ing for a com­pa­ny and read­ing this: if you sup­port us, you get the Lin­ux stuff for free too. 🙂 And as an addi­tion­al bonus, you can show a work­ing dri­ver with­out any bad legal strings (e.g. GPL infec­tion) to OEMs. So go and cal­cu­late how much sales you can do with embed­ded stuff and come back to us with some tech­ni­cal hints and/or free hard­ware (it costs some few bucks for you to pro­vide this: not much if it fails but a large amount of return if it works out).

Lin­ux­u­la­tor in ‑cur­rent ready for test­ing the 2.6.16 emulation

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

Hi,

today I com­mit­ted the last fix­es for the show­stop­per prob­lems (pan­ics) in the lin­ux 2.6.16 emu­la­tion. I intend to switch the default ver­sion to 2.6.16 on i386 “soon” (see below), so please help test­ing it.

More recent lin­ux dis­tri­b­u­tions (e.g. FC5) require a 2.6 ker­nel and don’t work with 2.4.2 any­more. And because FC4 is “abandon-ware” (no secu­ri­ty fix­es from fedo­rale­ga­cy any­more), get­ting 2.6.16 emu­la­tion up an run­ning is very important.

If you use a lin­ux pro­gram, please add compat.linux.osrelease=2.6.16 to /etc/sysctl.conf (my desk­top is run­ning with 2.6.16 emu­la­tion since some days already). After the next boot (or after run­ning “sysctl compat.linux.osrelease=2.6.16”, please make sure no lin­ux pro­gram is run­ning already) any lin­ux pro­gram will start with a lin­ux ker­nel ver­sion of 2.6.16 instead of 2.4.2. The default lin­ux 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 with­out a reboot, please make sure no lin­ux pro­gram is run­ning anymore.

So far we fixed all known/repeatable prob­lems with acrore­ad, realplay­er, skype and lin­ux fire­fox. If you encounter strange behav­ior with any lin­ux pro­gram, please tell us (emulation@freebsd.org) which pro­gram you used, how to repeat the prob­lem, what the prob­lem is, and if it only is vis­i­ble with 2.6.16 or with 2.4.2 too. You should also watch out for mes­sages in the dmesg (unim­ple­ment­ed sys­tem calls or oth­er stuff, this is used to deter­mine the pri­or­i­ty of miss­ing syscalls). Please also have a look at http://wiki.FreeBSD.org/linux-kernel, I intend 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­cial­ly inter­est­ed in reports (good or bad) on SMP sys­tems. Please beat the hell out of the linuxulator!

On amd64 sys­tems we have not the same func­tion­al­i­ty as on i386, miss­ing are futex­es and TLS. In P4 we already have the futex part cov­ered, 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 futex­es or TLS on amd64: we know about it (testers for the futex stuff are wel­come, but first you need to use a pro­gram which uses futex­es and complains).

As long as we get prob­lem 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 prob­lem reports, we will push back the switch a lit­tle bit depend­ing on the sever­i­ty of the problem.

Bye,
Alexander.