Alexander Leidinger

After the call for public testing we got some reports about LORs and a panic. This happened after an extensive parallel compiling session of linux stuff on a SMP system for several hours. Roman redid some of the locking and the fixes are in the tree. Intermediate patches already showed promising results. We’re waiting for the test of the committed solution now.

Yesterday we also got reports about segfaults with linux Java 5 and 6. This is under investigation (any debugging help would be appreciated, Java is a large beast).

I also noticed that we don’t have the results of a LTP run of a native Linux system in the wiki. It would be very nice to have this, as it would allow us to see broken test cases (Roman thinks the openat tests are flawed) or at least we see where it doesn’t matter much that we don’t PASS.

Apart from Konstantin (envy24* driver author) I also got a p4 account for Yuriy (emu10kx driver author). Let’s cross fingers for a lot of collaboration in //depot/projects/soundsystem/ now…

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.

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.

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.

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).

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:

Hi,

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 () 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 ). 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.

Bye,
Alexander.

I got time yesterday to test acroread with the patch from Intron/Kostik and … Yeah! I was not able to crash acroread in the 2.6.16 emulation! Great! Request for widespread testing soon?!?

Now we just have to determine if we have to care about the locking (I don’t know if kib@ already asked jhb@ about it) and the race condition. In case the userland exhibits very very bad programming and is using the FD before open() returns successfully, the program could read data. This can only happen if the program has the right permission to this data (the open is supposed to fail in this case not because of access restrictions, but because of e.g., the wrong file type).

Ariffs changes two months ago to reduce the latency in the soundsystem also prepared the way for multichannel support and Yuriy added multichannel recording to the emu10kx driver (there are some bugs ATM and it is only a proof of concept to play around with it until we get real multichannel support in the generic sound code). Ryan tries to get some time (let’s cross fingers!) to convert a driver (probably the emu10kx driver) to use the new mixer infrastructure before he has to concentrate on his studies again.

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

DragonFly synced with a not so current version of our soundsystem. I had a little discussion with them and pointed out some recent improvements and some drivers they missed to sync. They don’t have the man power to participate in large improvements, but I hope for some small benefits like bugfixes or additional PCI IDs. I also pointed out the wiki page, maybe we can get some additional sentences (we are lacking content there, feel free to help out with a sentence or more!) there from them. It doesn’t make sense to split the effort, so I offered to share the page with DFly.