免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
最近访问板块 发新帖
查看: 2710 | 回复: 1
打印 上一主题 下一主题

[驱动] 软irq问题 [复制链接]

论坛徽章:
0
跳转到指定楼层
1 [收藏(0)] [报告]
发表于 2016-01-09 14:33 |只看该作者 |倒序浏览
我做的是一个hdmi识别的内核驱动,平台是arm 4核的,具体的型号我也不清楚,

主流程是用timer来调用每10ms调用一次,

另外还有一个线程,在主流程里启动,

他们都会调用一个hdmirx_phy_clk_rate_monitor的函数,这个函数用mutex来保护临界区

从错误信息看,这个timer是通过软irq来调度的,

那么可以用mutex来保护临界区吗?是不是mutex的问题造成了系统崩溃?

[  658.875867@0] BUG: scheduling while atomic: swapper/0/0/0x00000102
[  658.876402@0] Modules linked in: dwc3 r840_fe(O) mali_kbase(O)
[  658.882190@0] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G           O 3.14.29-g5755ca5-dirty #116
[  658.890834@0] Call trace:
[  658.893331@0] [<ffffffc001088ea4>] dump_backtrace+0x0/0x144
[  658.898849@0] [<ffffffc001089004>] show_stack+0x1c/0x28
[  658.904011@0] [<ffffffc001a2343c>] dump_stack+0x74/0xb8
[  658.909292@0] [<ffffffc0010c90fc>] __schedule_bug+0x58/0x6c
[  658.914706@0] [<ffffffc001a28e48>] __schedule+0x648/0x748
[  658.920067@0] [<ffffffc001a28f74>] schedule+0x2c/0x80
[  658.925138@0] [<ffffffc001a293fc>] schedule_preempt_disabled+0x18/0x2c
[  658.931537@0] [<ffffffc001a2af1c>] __mutex_lock_slowpath+0x13c/0x244
[  658.937830@0] [<ffffffc001a2b074>] mutex_lock+0x50/0x70
[  658.943083@0] [<ffffffc0016faa64>] hdmirx_phy_clk_rate_monitor+0x28/0x128
[  658.949735@0] [<ffffffc0016f4c44>] hdmirx_hw_monitor+0x84/0x11a0
[  658.955672@0] [<ffffffc0016f8a24>] hdmirx_timer_handler+0x18/0x40
[  658.961804@0] [<ffffffc0010a77dc>] call_timer_fn+0x3c/0x148
[  658.967243@0] [<ffffffc0010a80e8>] run_timer_softirq+0x1ac/0x284
[  658.973183@0] [<ffffffc00109ef7c>] __do_softirq+0x138/0x2e0
[  658.978796@0] [<ffffffc00109f3b8>] irq_exit+0x94/0xc8
[  658.983703@0] [<ffffffc0010848b0>] handle_IRQ+0x54/0xd0
[  658.988890@0] [<ffffffc001081418>] gic_handle_irq+0x44/0x88
[  658.994480@0] Exception stack(0xffffffc001ed3dd0 to 0xffffffc001ed3ef0)
[  659.000966@0] 3dc0:                                     01ed0000 ffffffc0 01ed0000 ffffffc0
[  659.009330@0] 3de0: 01ed3f10 ffffffc0 01085458 ffffffc0 010f1e68 ffffffc0 00000000 00000000
[  659.017530@0] 3e00: 33fa4cbc ffffffc0 00000000 01000000 00000020 00000000 01fded00 ffffffc0
[  659.025896@0] 3e20: 25c17d03 00000002 00000000 00000000 00000018 00000000 01ed3d30 ffffffc0
[  659.034076@0] 3e40: 00000400 00000000 000003ff 00000000 f52b7cf0 00000000 f52b7ce0 00000000
[  659.042449@0] 3e60: f70b0beb 00000000 00000000 00000000 0110e4ec ffffffc0 00000000 00000000
[  659.050650@0] 3e80: 00000000 00000000 01ed0000 ffffffc0 01ed0000 ffffffc0 02065898 ffffffc0
[  659.059011@0] 3ea0: 01a32000 ffffffc0 01fca000 ffffffc0 01fc9875 ffffffc0 01c7c308 ffffffc0
[  659.067209@0] 3ec0: 00000001 00000000 01080468 ffffffc0 00000000 00000040 01ed3f10 ffffffc0
[  659.075557@0] 3ee0: 01085454 ffffffc0 01ed3f10 ffffffc0
[  659.080661@0] [<ffffffc001083da8>] el1_irq+0x68/0xd8
[  659.085569@0] [<ffffffc0010f1e64>] cpu_startup_entry+0x1d8/0x224
[  659.091613@0] [<ffffffc001a1d0fc>] rest_init+0x84/0x90
[  659.096623@0] [<ffffffc001dba7c0>] start_kernel+0x33c/0x354
[  659.102120@0] bad: scheduling from the idle thread!
[  659.106966@0] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G        W  O 3.14.29-g5755ca5-dirty #116
[  659.115569@0] Call trace:
[  659.118095@0] [<ffffffc001088ea4>] dump_backtrace+0x0/0x144
[  659.123601@0] [<ffffffc001089004>] show_stack+0x1c/0x28
[  659.128870@0] [<ffffffc001a2343c>] dump_stack+0x74/0xb8
[  659.133950@0] [<ffffffc0010d23b0>] dequeue_task_idle+0x2c/0x44
[  659.139743@0] [<ffffffc0010ca09c>] dequeue_task+0x74/0xa0
[  659.145160@0] [<ffffffc0010cba00>] deactivate_task+0x48/0x58
[  659.150696@0] [<ffffffc001a28c34>] __schedule+0x434/0x748
[  659.156044@0] [<ffffffc001a28f74>] schedule+0x2c/0x80
[  659.161119@0] [<ffffffc001a293fc>] schedule_preempt_disabled+0x18/0x2c
[  659.167516@0] [<ffffffc001a2af1c>] __mutex_lock_slowpath+0x13c/0x244
[  659.173798@0] [<ffffffc001a2b074>] mutex_lock+0x50/0x70
[  659.179068@0] [<ffffffc0016faa64>] hdmirx_phy_clk_rate_monitor+0x28/0x128
[  659.185699@0] [<ffffffc0016f4c44>] hdmirx_hw_monitor+0x84/0x11a0
[  659.191747@0] [<ffffffc0016f8a24>] hdmirx_timer_handler+0x18/0x40
[  659.197701@0] [<ffffffc0010a77dc>] call_timer_fn+0x3c/0x148
[  659.203208@0] [<ffffffc0010a80e8>] run_timer_softirq+0x1ac/0x284
[  659.209254@0] [<ffffffc00109ef7c>] __do_softirq+0x138/0x2e0
[  659.214680@0] [<ffffffc00109f3b8>] irq_exit+0x94/0xc8
[  659.219696@0] [<ffffffc0010848b0>] handle_IRQ+0x54/0xd0
[  659.224938@0] [<ffffffc001081418>] gic_handle_irq+0x44/0x88
[  659.230390@0] Exception stack(0xffffffc001ed3dd0 to 0xffffffc001ed3ef0)
[  659.236945@0] 3dc0:                                     01ed0000 ffffffc0 01ed0000 ffffffc0
[  659.245300@0] 3de0: 01ed3f10 ffffffc0 01085458 ffffffc0 010f1e68 ffffffc0 00000000 00000000
[  659.253510@0] 3e00: 33fa4cbc ffffffc0 00000000 01000000 00000020 00000000 01fded00 ffffffc0
[  659.261868@0] 3e20: 25c17d03 00000002 00000000 00000000 00000018 00000000 01ed3d30 ffffffc0
[  659.270069@0] 3e40: 00000400 00000000 000003ff 00000000 f52b7cf0 00000000 f52b7ce0 00000000
[  659.278430@0] 3e60: f70b0beb 00000000 00000000 00000000 0110e4ec ffffffc0 00000000 00000000
[  659.286629@0] 3e80: 00000000 00000000 01ed0000 ffffffc0 01ed0000 ffffffc0 02065898 ffffffc0
[  659.294979@0] 3ea0: 01a32000 ffffffc0 01fca000 ffffffc0 01fc9875 ffffffc0 01c7c308 ffffffc0
[  659.303189@0] 3ec0: 00000001 00000000 01080468 ffffffc0 00000000 00000040 01ed3f10 ffffffc0
[  659.311545@0] 3ee0: 01085454 ffffffc0 01ed3f10 ffffffc0
[  659.316640@0] [<ffffffc001083da8>] el1_irq+0x68/0xd8
[  659.321545@0] [<ffffffc0010f1e64>] cpu_startup_entry+0x1d8/0x224
[  659.327592@0] [<ffffffc001a1d0fc>] rest_init+0x84/0x90
[  659.332593@0] [<ffffffc001dba7c0>] start_kernel+0x33c/0x354
[  659.338129@0] Bad mode in Synchronous Abort handler detected, code 0x86000006
[  659.345170@0] CPU: 0 PID: 4415 Comm: mali-mem-purge Tainted: G        W  O 3.14.29-g5755ca5-dirty #116
[  659.345783@1] best EQ ch0=4, ch1=4,ch2=4
[  659.358279@0] task: ffffffc012cd0000 ti: ffffffc007604000 task.ti: ffffffc007604000
[  659.365869@0] PC is at 0x0
[  659.368543@0] LR is at enqueue_task+0x54/0x7c

论坛徽章:
0
2 [报告]
发表于 2016-02-22 15:15 |只看该作者
内核定时器是通过软中断实现的,也就是说定时器的执行函数的运行上下文是软中断上下文,软中断上下文中也是不允许睡眠的.而mutex是用于加锁可能睡眠的临界区的.
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP