ICS ex­per­i­ence on the Samasung Galaxy Tab 10.1

As told be­fore, I have the ICS as provided by Sam­sung (to it is not the stock ICS, it is the Samsung-​version of ICS)  on the Galaxy Tab 10.1. Now that it is nearly two months of us­ing it, I want to share a little bit of my ex­per­i­ence.

Ba­sic­ally it just works. If you know ICS already, you more or less know how it is on the Galaxy Tab 10.1.

The cal­en­dar app is dif­fer­ent, it is the Sam­sung app, not the nat­ive ICS one. I have a prob­lem to sync it with the exchange-​connector as it is in Horde 4, but I did not take the time to in­vest­ig­ate the is­sue. My Nex­us S con­nects just fine, so it must be some modi­fic­a­tion by Sam­sung which is caus­ing the is­sue.

Some­times the tab­let hangs, and I have to shut­down by press­ing the power but­ton for some seconds. This only hap­pens when con­nec­ted via WLAN. When I start the tab­let again, it will hang again if I am not fast enough to enter the PIN of the SIM, un­lock the screen and to de­ac­tiv­ate the WLAN. But even then it will hang after the de­ac­tiv­a­tion of the WLAN. After re­boot­ing the second time (with WLAN already de­ac­tiv­ated), everything works again.

The email app is also stut­ter­ing some­times. This hap­pens when I open a folder with a lot of emails and the email app is try­ing to de­term­ine if there are at­tach­ments or not. Either the app is not multi-​threaded, or it is not well done.

Apart from that it just works.

Email app from An­droid 3.1 in An­droid 3.2?

As pre­vi­ously re­por­ted, I tried the up­date to An­droid 3.2 on my Tab and was not happy about the new EMail app. At the week­end I had a little bit of time, so I tried to get the Email.apk from An­droid 3.1 in­to An­droid 3.2.

Long story short, I failed.

Ti­tani­um­Backup PRO was restor­ing or hours (the op­tion to mi­grate from a dif­fer­ent ROM ver­sion was en­abled) un­til I killed the app, and it did not get any­where (I just emailed their sup­port if I did some­thing com­pletely stu­pid, or of this is a bug in TB). And a copy by hand in­to /​system/​apps did not work (app fails to start).

Ideas wel­come.

Linuxu­lat­or D-​Trace probes com­mit­ted to cur­rent

A while ago I com­mit­ted the linuxu­lat­or D-​Trace probes I talked about earli­er. I waited a little bit for this an­nounce­ment to make sure I have not broken any­thing. Nobody com­plained so far, so I as­sume noth­ing ob­vi­ously bad crept in.

The >500 probes I com­mit­ted do not cov­er the en­tire linuxu­lat­or, but are a good start. Adding new ones is straight for­ward, if someone is in­ter­ested in a ju­ni­or–ker­nel-hack­er task, this would be one. Just ask me (or ask on emu­la­tion@), and I can guide you through it.

Sam­sung HMX-​H200 cam­cord­er

My wife de­cided that we need a cam­cord­er. As I am a good hus­band, I do not com­plain (she pays 😀 ).

There was an of­fer in a su­per mar­ket nearby. Not as low as you can find in the in­ter­net, but if there is a prob­lem, it is much more easy to com­plain. For some­thing like this, I/​we prefer this and am-​are OK to spend a little bit more money for this con­veni­ence.

This cam­cord­er is re­cord­ing to SDHC cards. Such cards have a speed rat­ing, and you need to take some min–speed one, to be able to re­cord videos with a cam­cord­er. Un­for­tu­nately Sam­sung does not list the speed rat­ing some­where. I searched on the Sam­sung site in the spe­cific­a­tions and in the FAQ. Noth­ing. After a little bit of googling I at least found a re­view where the re­cord­ing time for spe­cif­ic card-​sizes where lis­ted.

So I took the card-​size in MB, di­vided it by the re­cord­ing time in seconds, and got the data trans­fer rate per second for the spe­cified res­ol­u­tions. The 1080i res­ol­u­tion has the highest trans­fer rate and as such it is the most in­ter­est­ing one to de­cide what kind of card one needs.

The highest trans­fer rate seems to be less than 2.2 MB/​s, so a class 4 SDHC card should be enough.

Peri­od­ic scrub­bing of ZFS pools

I no­ticed that we do not have some auto­mat­ic way of scrub­bing a ZFS pool peri­od­ic­ally. A quick poll on fs@ re­vealed, that there is in­terest in some­thing like this. So I took a little bit of time to write a peri­od­ic daily script which checks if the last scrub is X days ago and scrubs a pool ac­cord­ingly. The script has op­tions to scrub all pools, or just a spe­cif­ic sub­set. It also al­lows to spe­cify a time–in­ter­val between scrubs for each pool with dif­fer­ent levels of fall-​back (if no pool-​specific in­ter­val is set, the de­fault in­ter­val is used, which is set to 30 days if no oth­er de­fault in­ter­val is spe­cified).

The dis­cus­sion about this is hap­pen­ing over at fs@, so go there and have a look for the CFT (with a link to the WIP of the script) and the dis­cus­sion if you are in­ter­ested.

So far there are some minor de­tails to sort out (and a little bit of doc­u­ment­a­tion to write) be­fore I can com­mit it… prob­ably next week.

Mono build prob­lems on FreeBSD-​current

I try to build mono on FreeBSD-cur­rent (it is a de­pend­ency of some GNOME pro­gram). Un­for­tu­nately this does not work cor­rectly.

What I see are hangs of the build. If I stop the build when it hangs and re­start it, it will con­tin­ue and suc­ceed to pro­cess the build steps a little bit fur­ther, but then it hangs again.

If I ktrace the hanging pro­cess, I see that there is a call to wait re­turn­ing with the er­ror mes­sage that the child does not ex­ist. Then there is a call to nanosleep.

It looks to me like this pro­cess missed some SIGCLD (or is wait­ing for some­thing which did not ex­ist at all), and a loop is wait­ing for a child to exit. This loop prob­ably has no prop­er con­di­tion for the fact that there is no such child (any­more). As such it will stay forever in this loop.

So I grepped a litte bit around in mono and found the fol­low­ing code in <mono-src-dir>/mcs/class/Mono.Posix/Mono.Unix/UnixProcess.cs:

pub­lic void Wait­F­orExit ()
{
    int status;
    int r;
    do {
        r = Nat­ive.Sy­scall.wait­pid (pid, out status, (Native.WaitOptions) 0);
    } while (UnixMarshal.ShouldRetrySyscall ®);
    UnixMarshal.ThrowExceptionForLastErrorIf ®;
}

This does look a little bit as it could be re­lated to the prob­lem I see, but ShouldRetrySy­scall only re­turns true if the er­rno is EINTR. So this looks cor­rect. 🙁

I looked a little bit more at this file and it looks like either I do not un­der­stand the se­mant­ic of this lan­guage, or Get­Pro­cessStatus does re­turn the re­turn­value of the wait­pid call in­stead of the status (which is not what it shall re­turn to my un­der­stand­ing). If I am cor­rect, it can not really de­tect the status of a pro­cess. It would be very bad if such a fun­da­ment­al thing went un­noticed in mono…  which does not put a good light on the unit-​tests (if any) or the gen­er­al test­ing of mono. For this reas­on I hope I am wrong.

I did not stop there, as this part does not look like it is the prob­lem. I found the fol­low­ing in mono/io-layer/processes.c:

stat­ic gboolean waitfor_​pid (gpoint­er test, gpoint­er user_​data)
{
…
    do {
        ret = wait­pid (process->id, &status, WNOHANG);
    } while (er­rno == EINTR);

    if (ret <= 0) {
        /​* Pro­cess not ready for wait */​
#if­def DEBUG
        g_​message (“%s: Pro­cess %d not ready for wait­ing for: %s”,
                   _​_​func_​_​, process->id, g_​strerror (er­rno));
#en­dif

        re­turn (FALSE);
    }

#if­def DEBUG
    g_​message (“%s: Pro­cess %d fin­ished”, _​_​func_​_​, ret);
#en­dif

    process->waited = TRUE; … } 

And here we have the prob­lem, I think. I changed the (ret <= 0) to  (ret == 0 || (ret < 0 && er­rno != ECHILD)). This will not really give the cor­rect status, but at least it should not block any­more and I should be able to see the dif­fer­ence dur­ing the build.

And now after test­ing, I see a dif­fer­ence, but the prob­lem is still there. The wait with ECHILD is gone in the loop, but there is still some loop with a sem­a­phore op­er­a­tion:

62960 mono     CALL  clock_gettime(0xd,0xbf9feef8)
62960 mono     RET   clock_​gettime 0
62960 mono     CALL  semop(0x20c0000,0xbf9feef6,0x1)
62960 mono     RET   se­mop 0
62960 mono     CALL  semop(0x20c0000,0xbf9feef6,0x1)
62960 mono     RET   se­mop 0
62960 mono     CALL  semop(0x20c0000,0xbf9feef6,0x1)
62960 mono     RET   se­mop 0
62960 mono     CALL  semop(0x20c0000,0xbf9feef6,0x1)
62960 mono     RET   se­mop 0
62960 mono     CALL  nanosleep(0xbf9fef84,0)
62960 mono     RET   nanosleep 0
62960 mono     CALL  clock_gettime(0xd,0xbf9feef8)
62960 mono     RET   clock_​gettime 0
62960 mono     CALL  semop(0x20c0000,0xbf9feef6,0x1)
62960 mono     RET   se­mop 0
62960 mono     CALL  semop(0x20c0000,0xbf9feef6,0x1)
62960 mono     RET   se­mop 0
62960 mono     CALL  semop(0x20c0000,0xbf9feef6,0x1)
62960 mono     RET   se­mop 0
62960 mono     CALL  semop(0x20c0000,0xbf9feef6,0x1)
62960 mono     RET   se­mop 0
62960 mono     CALL  nanosleep(0xbf9fef84,0)

OK, there is more go­ing on. I think someone with more know­ledge about mono should have a look at this (do not only look at this se­mop thing, but also look why it loses a child).