On Thu, Dec 03, 2009 at 07:30:38PM +0100, Tobias Schneider wrote: > 2. The more interesting question: as written in "Writing an alsa driver" > callbacks are basically not atomic, but I am getting BUG: scheduling > while atomic: amixer/0x00000001/430 Call Trace: .[..] in "put" > callback?? So what is meant with "basically not atomic"?? What is > allowed and what is not allowed, am I able to get hardware interrupts in > this context? That message basically means that you called a scheduling function while you have preemption switched off. One common pitfall is to let the CPU reschedule from an interrupt handler or while holding a spinlock. The basic problem is that if you hold a spinlock and let the CPU do something else, some other execution path (on the same CPU) could also try to access the same lock which then deadlocks your system. It all boils down to: from interrupt handlers or while you hold a spinlock, you must never call any function that will sleep (and thereby reschedule). Some functions such like kmalloc have a flag that you can pass depending on whether you want it to allow to sleep (GFP_KERNEL) or not (GFP_ATOMIC). If you necessarily _have_ to sleep from atomic context, you must postpone your work using a work_struct or something similar. You should post your code so people can have a look. HTH, Daniel _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
