Hello Lukasz, 2009/2/23 Lukasz Majewski <majess1982@xxxxxxxxx>: > Hello, > > Thank you for this extremely fast response. :-) No thanks :-) > Now some explanation about uClibc. I know that this C library lacks of many > features (for instance NTPL support for ARM). Unfortunately, for ARM > architecture, there is nice utility -> buildroot for building toolchain and > root filesystems. I'm not using x86 as target architecture, so cross > compiling toolchain without errors is success as it is :-). > I've tried pxtdist tool from pengutronix.de , but I cannot build proper > toolchain without errors for my Atmel's ARM9 device (ARMv5tej arch to be > precise). Or saying it in another way -> I gave up after spending some time > and moved back toward working uClibc. I've build some toolchains, but during > build I've encountered some errors and despite of that it, built If you have problems building compiler toolchains, there are other ways to do it. You can use a precompiled (and tested) toolchain, for example: * http://www.codesourcery.com/sgpp/lite/arm. * http://www.denx.de/wiki/DULG/ELDK * .... The advantage of such a precompiled toolchain, is that it saves you a lot of build time, and you can focus on the things that matter for your application. > arm-linux-gcc which worked, I wasn't sure if glibc is not cracked in some > way. > > On my first post I haven't mention that I was checking rusage struct for > minor and major page faults. > In my program I checked it twice: first before calling mlockall() - on the > beginning of the program and after munlockall() when program ends either > when delay occurs or in normal termination. In both cases I've got the same > number of minor and major page faults. So it looks that no page fault > appears. Strange, normally mlockall generates a lot of pagefaults by just calling it, so there should be a difference before and directly after calling mlockall. > I've checked, and it turns out that uClibc 0.9.30 is not supporting PI > (priority inversion) and futexes. This may cause my bug ,since I'm heavily > using read/write on /dev/ files (read/write to 4 differen files). There's a > lot of space for priority inversion in my code :-/. I was writing this code > with holly faith that "in some way" priority inversion is avoided. I > assumed, that access to some device (resource in this case) has some > mechanism to inheritance the priority. That depends on the driver behind it. In kernel there is always PI support on mutexes. PI mutexes should be enabled for mutexes in your own code. Do not forget to look at the priority of softirq-s/irq-threads related to your RT-threads. if, for example, you have a thread running at prio 60, softirqs and irq-threads running at 50, and your RT thread is running at 70, and it has some dependency to the prio 50 irqs, then you could have an inversion problem here as well. The prio 60 task could prevent the softirqs and irq-threads from running, leaving the prio 70 task waiting for a very long time. > Is looks,that the only solution for me is to build toolchain with glibc at > least 2.6 and gcc 4.+ with full support of Priority Inheritance, futexses > and "clock_" set of functions. As I mentioned it's a bit tricky for ARM > (especialy with proper ABI and software floating point support > (msoft-float)). But it looks as the only feasible solution. As mentioned above, you could use a precompiled toolchain. It would at least safe you time to get it working, and if you still want to compile one yourself, you can always do it later... Kind Regards, Remy -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
