Hi Now, i continue appliyng my patch to compile KERNEL+RT+AUFS.
I was try to use the rt_mutex_set_owner() wihtout success. I do not remember what the problem was. Now i'm running 4.4.38-rt49 Kernel wiht RT and AUFS Linux x64-v3 4.4.38-rt49 #1 SMP PREEMPT RT Mon Dec 19 10:28:46 CET 2016 x86_64 GNU/Linux I use the kernel to run a DEBIAN based live system. If you want test my kernel i can share-it on google drive. Sorry for my english. 2017-01-16 16:57 GMT+01:00 Demmel Nikolaus (BOSP/PAR) <nikolaus.dem...@de.bosch.com>: > Hi J. R. Okajima, > > thank you for your prompt response. > > I'm assuming from your response that in general you expect AUFS to work with > PREEMPT_RT, or is this not the case? > > "Demmel Nikolaus (BOSP/PAR)": >> > we are using AUFS for our root filesystem with an tmpfs overlay and >> > recentl= >> > y wanted to switch to a kernel with PREEMPT_RT patch. Unfortunately, it >> > see= >> > ms that mounting aufs seems to hang about 40% of the time during boot >> > (ther= >> > e is no specific kernel or log message). When it comes up, it seems to >> > work= >> > correctly. > >> Do you mean that mounting aufs took very long time and your system runs >> flawlessly after that? >> Interesting... > >> My first suggestion to see what is going on is "strace -T -f mount -t aufs >> ..." >> which will give us a hint. > >> Sometimes people sets aufs FHSM feature incorrectly. That >> setting/configuration should match in kernel-space and user-space. If it >> doesn't match, it will take a long time in mounting aufs unexpectedly. >> When FHSM is enabled both in kernel and user-space, then it will take a >> long time too. But it is an expected behaviour. > > What I actually mean is that in about 40% of the time when booting into a > kernel with the RT patch, the boot hangs at > > mount -t aufs -o "dirs=/rw=rw:/ro=ro" aufs $ROOT_MOUNT > > in our init script and does not appear to return at all. The other 60% it > works as expected without delay. > > Then exact same configuration just without PREEMPT_RT patch appears to work > 100% of the time. > > Does your answer still apply? Should we try the strace? > >> > In order to get AUFS to compile, we needed to apply the following >> > additiona= >> > l patch: >> > https://github.com/beagleboard/linux/pull/108/commits/ad740435f28e= >> > 3ffb5d73a419086b0b6fd3bc7240 > >> Hmm, this patch reminds me a post from Daniel Vidal in May 2013 (the >> patch looks different from what I suggested, though). Refer to >> http://www.mail-archive.com/aufs-users@lists.sourceforge.net/msg04210.html >> and its thread. > > Hm... interesting. To me (being unfamiliar with the innards of both > PREEMPT_RT and AUFS) this > looks like potential for a locking issue. The patch / discussion you linked > seems to suggest that > the owner should be set assigned to lock.owner, which is not done in the > patch we are using. Mind that > the patch I linked is also just something I stumbled across while googling > the initial compile error. > In particular the commit message doesn't sound too confident that the change > is actually the correct > fix and not just a way to make it compile. > > Do you suggest that we should try to change it to the patch you linked? > >> Next time when you post, tell me the version of patches you are using >> and the URL where I can get all of thme. > > Sorry, here are the versions, I hope this helps (I'm copying this from a > yocto build config and I'm not sure in what format it would be most useful > for you. I'm not even sure what would be the best tool to use to get from the > list of repos with kernel source and patches a compiled kernel without using > yocto). > > https://www.kernel.org/pub/linux/kernel/v4.x/linux-4.1.30.tar.xz > http://git.linuxfoundation.org/?p=ltsi-kernel.git;a=commit;h=079621627b2d96cf0d85a0413ce5670056a70751w > https://github.com/sfjro/aufs4-standalone.git > https://www.kernel.org/pub/linux/kernel/projects/rt/4.1/older/patches-4.1.30-rt34.tar.xz > > Best, > Nikolaus > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot
