I have been using a Linux operaing system on a small ARM processor board. All of my software runs in user-space. I have had a big challenge creating software interrupts on a periodic bases. I've used the sigaction() and setitimer() functions to setup this periodic timer interupt. This gives me only one periodic interrupt that occurs ever 30ms. Is there a better way to do this? Could I get these interupts to occur more often, perhaps every 100us?
@kernelkernel: I just see it linked in as a module (604401.090805] Modules linked in: cdc_acm). I think that's part of USB OTG subsystem used to make USB behave as an Ethernet. I could be wrong those as I haven't looked at that part of the kernel in a few months.
@timd: The memory management uint (MMU) is used to create a translation of physical to virtual addresses. The MMU enables a consistent memory interface across all CPU architectures that run Linux. But, the use of an MMU and it's page tables consumes memory. So, uCLinux is a way to give a Linux look and feel to processors with well less than 1 MB of RAM. It's not quite Linux, but from a user's API perspective, it's pretty close.
@kernelkernel I see you're using USB OTG. The most known source for this bug is tring to sleep in a completion handler. So, if you try to sleep in a bottom_half (e.g., tasklet) you'll also see this error. Look at your ISR to see if you're using a schedule_tasklet call. If so, look in the tasklet to make sure it's not trying to sleep (wait_event, etc.) Also, look at your kernel timers for similar logic.
@timd: uCLinux runs with an MMU on smaller processors like the CortexM3/M4. It is based on the Linux source tree, but operates in a fundamentally different way than full-up Linux. I'd use the full-up version first and then experiment with uCLinux if you have a specific need to run on an MMU-less processor.
Mike: Thank You for that info. This error is occuring when I am trying to play a audio. There is a new chunk of code added . I have to debug it. I will post to the mailing list after I reach to certain point from the ftrace hint you have given
@kernelkernel: BTW, most of the time I've see that error were related to the driver calling schedule() while the application was supposed to have exclusive access. E.g., USB interface calling schedule in a wait_event_interruptible() call.
@kernelkernel The trace should be captured on the target. Is this bug repeatable? If so, use the tracing_on and tracing_off features in the kernel API to capture the function graph associated with the failure. Capture that info to a trace file and look at it on the host. Then, if it's a repeatible bug and not related to proprietary code, submit the bug and the trace to the Linux Kernel Mailing List for the maintainers to examine.
@kernelkernel The "scheduling while atomic" bug is a significant problem in your system if you're seeing it. I'd use ftrace to capture the trace around that and look to see where your system is going south.
@jamesdeutch The stated goal of LTTng is to get it into mainline sometime by year end. But, because ftrace and oprofile are aready there, Linus may not be keep on adding yet another profiler to the kernel. If the argument for LTTng is compelling, then it will likely get in. If it's just another "me too" then it may never get into the kernel.
@timd Yes, it is the same source tree. Obvisously the interfaces are slightly different for the ARM because of the difference in CPU features. So, there may be features that exist on ARM that don't on x86 and vice versa
@INVITATION: I am accepting input from those interested in participating on an Embedded Study group. Please, write about your interest to email@example.com. The level should start with basics but opent to any one interested in learning or helping to learn. No agenda in place yet.
Re mainline question: a few years ago, I would have answered affirmatively wrt being comfortable "doing the integration" work. But now, not unless it's integrated with whatever kernel source mgmt infrastructure I'm using (eg Debian's).
Depends on the ease of integration (which usually means lots of documentation is needed) - I don't mind surgery on the kernel at all, but I don't like spending hours upon hours just trying to get a tool to work so that I can start on solving my problems
Varies for me. Often, commandline is faster to move around with. But GUIs that provide some sort of "value-added" output (like the tool in the slides) can be useful for first-line exploration (also nice is if they implement IO via separate thread or process mechanisms...).
If the tool is not in the mainline kernel, it needs to be better enough to make it work the effort to build a new kernel. Plus, if the tool is not in the mainline kernel, it makes kernel upgrades a pain.
I almost always require that my tools are fully functional via the CLI, but the option of viewing the information occasionally in a GUI so that I can use my eyes+brain as a pattern recognition device is useful.
@INVITATION: I am accepting input from those interested in participating on an Embedded Study group. Please, write about your interest to firstname.lastname@example.org. The level should be beginner but opent to any one interested to learn or help to learn. No agenda in place yet.
I experienced latency problem with my own uart based micro network -- on a linux with no low latency switched on we experienced problems with the micro-network which needed hard response times from the nodes.
only used our own debug functions (way back) in Windows CE. Have used Performance Validator (SoftwareVerify.com) more recently for timing information but not completely into kernel; was one layer above.
Focus on Fundamentals consists of 45-minute on-line classes that cover a host of technologies. You learn without leaving the comfort of your desk. All classes are taught by subject-matter experts and all are archived. So if you can't attend live, attend at your convenience.