2010-02-21 14:28:22     BUG: scheduling while atomic, introduced somewhere between svn8318 and svn8332

Document created by Aaronwu Employee on Aug 20, 2013
Version 1Show Document
  • View in full screen mode

2010-02-21 14:28:22     BUG: scheduling while atomic, introduced somewhere between svn8318 and svn8332

George Yohng (AUSTRIA)

Message: 86283   

 

Hello,

 

I have updated ucLinux blackfin kernel to the latest SVN, and now I have such bug.

 

It does not depend on any modules, and a stack trace does not seem to be meaningful. In fact - the reproduced stack trace below was made out of running lsusb without any USB support modules loaded. This also happens with other programs, such as cat, ls, etc - as long as they have to wait a bit longer - there is a chance that BUG scheduling while atomic will happen.

 

This started to happen after I updated to svn8332, and this was not happening with svn8318. So I think the problem was introduced somewhere inbetween, but I'm not very familiar with the code to point exactly where the problem might be.

 

Stack trace always looks the same, independently which program has crashed it. Also the value '0x04000001' is constant. Process name and PID can be anything at all - depending on which process is running.

 

 

 

Feb 21 20:49:50 blackfin user.err kernel: BUG: scheduling while atomic: lsusb/253/0x04000001

Feb 21 20:49:50 blackfin user.notice kernel: Hardware Trace:

Feb 21 20:49:50 blackfin user.notice kernel:    0 Target : <0x00005070> { _dump_stack + 0x0 }

Feb 21 20:49:50 blackfin user.notice kernel:      Source : <0x0000e106> { ___schedule_bug + 0x5a } JUMP.L

Feb 21 20:49:50 blackfin user.notice kernel:    1 Target : <0x0000e100> { ___schedule_bug + 0x54 }

Feb 21 20:49:50 blackfin user.notice kernel:      Source : <0x0000e0f2> { ___schedule_bug + 0x46 } IF !CC JUMP

Feb 21 20:49:50 blackfin user.notice kernel:    2 Target : <0x0000e0e6> { ___schedule_bug + 0x3a }

Feb 21 20:49:50 blackfin user.notice kernel:      Source : <0x00029cbc> { _print_modules + 0x0 } RTS

Feb 21 20:49:50 blackfin user.notice kernel:    3 Target : <0x00029cbc> { _print_modules + 0x0 }

Feb 21 20:49:50 blackfin user.notice kernel:      Source : <0x0000e0e2> { ___schedule_bug + 0x36 } CALL pcrel

Feb 21 20:49:50 blackfin user.notice kernel:    4 Target : <0x0000e0e2> { ___schedule_bug + 0x36 }

Feb 21 20:49:50 blackfin user.notice kernel:    6 Target : <0x000112c4> { _vprintk + 0x134 }

Feb 21 20:49:50 blackfin user.notice kernel:      Source : <0xffa00b74> { __common_int_entry + 0xcc } RTI

Feb 21 20:49:50 blackfin user.notice kernel:    7 Target : <0xffa00b12> { __common_int_entry + 0x6a }

Feb 21 20:49:50 blackfin user.notice kernel:      Source : <0xffa0095c> { _return_from_int + 0x58 } RTS

Feb 21 20:49:50 blackfin user.notice kernel:    8 Target : <0xffa0095c> { _return_from_int + 0x58 }

Feb 21 20:49:50 blackfin user.notice kernel:      Source : <0xffa00932> { _return_from_int + 0x2e } IF !CC JUMP

Feb 21 20:49:50 blackfin user.notice kernel:    9 Target : <0xffa00904> { _return_from_int + 0x0 }

Feb 21 20:49:50 blackfin user.notice kernel:      Source : <0xffa00b0e> { __common_int_entry + 0x66 } CALL pcrel

Feb 21 20:49:50 blackfin user.notice kernel:   10 Target : <0xffa00b0c> { __common_int_entry + 0x64 }

Feb 21 20:49:50 blackfin user.notice kernel:      Source : <0xffa00286> { _asm_do_IRQ + 0x3e } RTS

Feb 21 20:49:50 blackfin user.notice kernel:   11 Target : <0xffa0027e> { _asm_do_IRQ + 0x36 }

Feb 21 20:49:50 blackfin user.notice kernel:      Source : <0x00014b26> { __local_bh_enable + 0x3a } RTS

Feb 21 20:49:50 blackfin user.notice kernel:   12 Target : <0x00014aec> { __local_bh_enable + 0x0 }

Feb 21 20:49:50 blackfin user.notice kernel:      Source : <0x00014e0a> { ___do_softirq + 0xb2 } JUMP.L

Feb 21 20:49:50 blackfin user.notice kernel:   13 Target : <0x00014e02> { ___do_softirq + 0xaa }

Feb 21 20:49:50 blackfin user.notice kernel:      Source : <0x00014df6> { ___do_softirq + 0x9e } IF !CC JUMP

Feb 21 20:49:50 blackfin user.notice kernel:   14 Target : <0x00014de2> { ___do_softirq + 0x8a }

 

 

 

 

Thanks,

George.

QuoteReplyEditDelete

 

 

2010-02-22 04:33:56     Re: BUG: scheduling while atomic, introduced somewhere between svn8318 and svn8332

Yi Li (CHINA)

Message: 86314   

 

George,

 

What Blackfin part are you using?

 

How to reprodce? Simple run "lsusb"?

 

-YI

QuoteReplyEditDelete

 

 

2010-02-22 10:54:22     Re: BUG: scheduling while atomic, introduced somewhere between svn8318 and svn8332

George Yohng (AUSTRIA)

Message: 86320   

 

I am using BF525 rev0.2

 

In my case, running lsusb reproduces it for sure. But it happens on running other things too.

 

USB support is not compiled into kernel. Kernel config is attached.

 

config

QuoteReplyEditDelete

 

 

2010-02-22 10:56:30     Re: BUG: scheduling while atomic, introduced somewhere between svn8318 and svn8332

George Yohng (AUSTRIA)

Message: 86321   

 

It appears that forum has problems with attachment file names starting with a dot. Now trying to attach as txt.

 

config.txt

QuoteReplyEditDelete

 

 

2010-02-22 15:37:36     Re: BUG: scheduling while atomic, introduced somewhere between svn8318 and svn8332

Mike Frysinger (UNITED STATES)

Message: 86349   

 

files starting with a dot get automatically fixed so there is no need to double post things

QuoteReplyEditDelete

 

 

2010-02-22 23:39:32     Re: BUG: scheduling while atomic, introduced somewhere between svn8318 and svn8332

Sonic Zhang (CHINA)

Message: 86353   

 

This looks the same issue described in bug   blackfin.uclinux.org/gf/tracker/5924

QuoteReplyEditDelete

 

 

2010-02-23 01:24:15     Re: BUG: scheduling while atomic, introduced somewhere between svn8318 and svn8332

Barry Song (CHINA)

Message: 86354   

 

It is due to my new access_ok check-in. There is a lock to access VMA list, but some atomic contexts call this function. Then I revert this check-in at first.

 

Read the document:

access_ok

Name

access_ok --  Checks if a user space pointer is valid

Synopsis

 

access_ok ( type, addr, size);

Arguments

 

type

 

    Type of access: VERIFY_READ or VERIFY_WRITE. Note that VERIFY_WRITE is a superset of VERIFY_READ - if it is safe to write to a block, it is always safe to read from it.

addr

 

    User space pointer to start of block to check

size

 

    Size of block to check

 

Context

 

User context only. This function may sleep.

 

 

 

"This function may sleep. " It is legal. But some atomic codes still call it.

QuoteReplyEditDelete

Attachments

Outcomes