What are the possible causes of "BUG: scheduling while atomic?"

There is another process that continually creates files that need to be processed by this code. This code constantly scans the filesystem for new files that need processing, comparing the contents of the filesystem against the sqlite database that contains the processing results - one record for each file. This process works in nice -n 19

order not to interfere with the creation of new files by another process. This all works fine for a lot of files (> 1k), but then blows up with BUG: scheduling while atomic

. According to this

"Scheduling while atomic" indicates that you tried to sleep somewhere that you shouldn't

But the only dream in the code looks like this:

void doFiles(void) {
    for (...) { // for each file in the file-system
        ... // check database - do processing if needed
    }
    sleep(1);
}
int main(int argc, char *argv[], char *envp[]) {
    while (true) doFiles();
    return -1;
}

      

The code will hit this dream after it checks every file in the filesystem against the database. The process must be repeated as new files will be added from time to time. There is no multithreading in this code. Are there other possible reasons for "BUG: scheduling while atomic" besides unlocal sleep?

Edit: Additional error output:

note: mirlin[1083] exited with preempt_count 1
BUG: scheduling while atomic: mirlin/1083/0x40000002
Modules linked in: g_cdc_ms musb_hdrc nop_usb_xceiv irqk edmak dm365mmap cmemk
Backtrace: 
[<c002a5a0>] (dump_backtrace+0x0/0x110) from [<c028e56c>] (dump_stack+0x18/0x1c)
 r6:c1099460 r5:c04ea000 r4:00000000 r3:20000013
[<c028e554>] (dump_stack+0x0/0x1c) from [<c00337b8>] (__schedule_bug+0x58/0x64)
[<c0033760>] (__schedule_bug+0x0/0x64) from [<c028e864>] (schedule+0x84/0x378)
 r4:c10992c0 r3:00000000
[<c028e7e0>] (schedule+0x0/0x378) from [<c0033a80>] (__cond_resched+0x28/0x38)
[<c0033a58>] (__cond_resched+0x0/0x38) from [<c028ec6c>] (_cond_resched+0x34/0x44)
 r4:00013000 r3:00000001
[<c028ec38>] (_cond_resched+0x0/0x44) from [<c0082f64>] (unmap_vmas+0x570/0x620)
[<c00829f4>] (unmap_vmas+0x0/0x620) from [<c0085c10>] (exit_mmap+0xc0/0x1ec)
[<c0085b50>] (exit_mmap+0x0/0x1ec) from [<c0037610>] (mmput+0x40/0xfc)
 r9:00000001 r8:80000005 r6:c04ea000 r5:00000000 r4:c0427300
[<c00375d0>] (mmput+0x0/0xfc) from [<c003b5e4>] (exit_mm+0x150/0x158)
 r5:c10992c0 r4:c0427300
[<c003b494>] (exit_mm+0x0/0x158) from [<c003cd44>] (do_exit+0x198/0x67c)
 r7:c03120d1 r6:c10992c0 r5:0000000b r4:c10992c0
...

      

+3


source to share


2 answers


This error was caused by a bad build. A clean build on its own didn't help. A new check and build was required to resolve this issue.



-1


source


As others have said, you can sleep () at any time in your user code.

Looks like a driver problem on your platform. The driver cannot actually call sleep () or schedule (), but often it calls a kernel function call, which in turn will call one of them.



It is also similar to using memory mapped I / O on an embedded TI ARM processor.

+2


source







All Articles