蜗窝科技

@hjl：如果自加操作是原子的，那么不会出现你说的问题啊。

@looper，第二个问题就比较直接： runtime PM resume的时候（__pm_runtime_resume），会关中断（spin_lock_irqsave），但是，在resume的过程中，调到devfreq_simple_ondemand_handler-->devfreq_monitor_resume了，而在devfreq_monitor_resume中，有mutex_lock的调用。就出现上面的警告了。你查一下为什么会有这个流程。 PS：mali是ARM的GPU，看情况，问题都出在相关的代码中，你可以检查一下代码。

@wowo：具体原因不知道。应该是Android的一种叫做Monkey测试出来的。 中间没有insomd,rmmod。 而mail是什么东西，我也不清楚。估计是上层的什么应用吧。 在稳定性测试中还有类似的情况： BUG: sleeping function called from invalid context at /space/builder/repo/sprdroid6.0mr1_prime_k318_dev/kernel/kernel/locking/mutex.c:97 in_atomic(): 0, irqs_disabled(): 128, pid: 3909, name: mali-renderer [01-01 08:56:28.356] <0>[ 2881.732806] c0 Call trace: [01-01 08:56:28.356] <4>[ 2881.735432] c0 [<ffffffc00008b480>] dump_backtrace+0x0/0x164 [01-01 08:56:28.356] <4>[ 2881.735441] c0 [<ffffffc00008b600>] show_stack+0x1c/0x28 [01-01 08:56:28.356] <4>[ 2881.735453] c0 [<ffffffc0009d121c>] dump_stack+0x74/0xb8 [01-01 08:56:28.356] <4>[ 2881.735464] c0 [<ffffffc0000e33d4>] __might_sleep+0x158/0x1a0 [01-01 08:56:28.356] <4>[ 2881.735473] c0 [<ffffffc0009d9d48>] mutex_lock+0x28/0x50 [01-01 08:56:28.356] <4>[ 2881.735483] c0 [<ffffffc000740c58>] devfreq_monitor_resume+0x20/0xb0 [01-01 08:56:28.356] <4>[ 2881.735494] c0 [<ffffffc000742548>] devfreq_simple_ondemand_handler+0x80/0xc4 [01-01 08:56:28.356] <4>[ 2881.735502] c0 [<ffffffc000740998>] devfreq_resume_device+0x34/0x5c [01-01 08:56:28.356] <4>[ 2881.735521] c0 [<ffffffbffc014df0>] kbase_release_device+0x78/0x3b90 [mali_kbase] [01-01 08:56:28.356] <4>[ 2881.735532] c0 [<ffffffc0004acdc4>] pm_generic_runtime_resume+0x38/0x58 [01-01 08:56:28.356] <4>[ 2881.735541] c0 [<ffffffc0004aec70>] __rpm_callback+0x70/0x9c [01-01 08:56:28.356] <4>[ 2881.735550] c0 [<ffffffc0004aeccc>] rpm_callback+0x30/0xa0 [01-01 08:56:28.356] <4>[ 2881.735558] c0 [<ffffffc0004afff4>] rpm_resume+0x424/0x5f0 [01-01 08:56:28.356] <4>[ 2881.735566] c0 [<ffffffc0004b0224>] __pm_runtime_resume+0x64/0xa0 [01-01 08:56:28.356] <4>[ 2881.735582] c0 [<ffffffbffc01ea20>] kbase_platform_fake_register+0x18c/0xef8 [mali_kbase] [01-01 08:56:28.356] <4>[ 2881.735597] c0 [<ffffffbffc02868c>] kbase_pm_clock_on+0x9c/0x1ac [mali_kbase] [01-01 08:56:28.356] <4>[ 2881.735612] c0 [<ffffffbffc026dd4>] kbase_pm_do_poweron+0x24/0x3c [mali_kbase] [01-01 08:56:28.356] <4>[ 2881.735627] c0 [<ffffffbffc0295f0>] kbase_pm_update_active+0xa0/0x18c [mali_kbase] [01-01 08:56:28.356] <4>[ 2881.735642] c0 [<ffffffbffc027128>] kbase_hwaccess_pm_gpu_active+0x1c/0x2c [mali_kbase] [01-01 08:56:28.376] <4>[ 2881.735656] c0 [<ffffffbffc00d860>] kbase_pm_context_active_handle_suspend+0xbc/0xc4 [mali_kbase] [01-01 08:56:28.376] <4>[ 2881.735670] c0 [<ffffffbffc00b300>] kbase_js_sched+0x148/0x86c [mali_kbase] [01-01 08:56:28.376] <4>[ 2881.735682] c0 [<ffffffbffc0074e8>] kbase_jd_submit+0x318/0x3b4 [mali_kbase] [01-01 08:56:28.376] <4>[ 2881.735696] c0 [<ffffffbffc017318>] kbase_release_device+0x25a0/0x3b90 [mali_kbase] [01-01 08:56:28.376] <4>[ 2881.735708] c0 [<ffffffc000246d20>] compat_SyS_ioctl+0xbc/0x1688 都是进入了sleep中。

@wolf：你用的是什么系统呢？待机和休眠机制又是怎样的呢？

@looper：每次都有这句话吗？ [01-02 07:45:29.883] <3>[ 8.510170] c0 Preemption disabled at:[<ffffffc0009cc934>] printk+0x7c/0x8c 和printk有关？ mali是变成模块的？ 再做rmmod、insmod测试？ printk可能会输出到屏幕上？

@wowo：这个问题是测试组在kernel log中发现的， 而且整个流程也是kernel 原生的代码。我用的kernel是3.18的。of_devfreq_cooling_register_power中确实有分配内存： devm_kzalloc(dev, sizeof(*dfc), GFP_KERNEL); 使用GFP_KERNEL这个标志分配内存是可以睡眠的，但是irqs_disabled(): 0， 而preempt_count_equals(preempt_offset)=0说明是有抢占或者中断被禁止了。 关键我没有头绪， 不知从何入手。 求指点。谢谢

@looper：你的driver的probe函数是怎么写的？是不是有关中断、关抢占之类的？ 另外可以试试在___might_sleep中加打印，查一下具体的原因。 if ((preempt_count_equals(preempt_offset) && !irqs_disabled() && !is_idle_task(current)) || system_state != SYSTEM_RUNNING || oops_in_progress) return; if (time_before(jiffies, prev_jiffy + HZ) && prev_jiffy) return; prev_jiffy = jiffies;

问一下，怎么用命令行禁止系统进入待机，休眠呢?

@wowo：回复晚了，下面是call trace [01-02 07:45:29.883] <3>[ 8.510125] c0 BUG: sleeping function called from invalid context at /space/builder/repo/sprdroid6.0_trunk_k318_dev/kernel/mm/slub.c:1240 [01-02 07:45:29.883] <3>[ 8.510150] c0 in_atomic(): 0, irqs_disabled(): 0, pid: 1, name: init [01-02 07:45:29.883] <3>[ 8.510170] c0 Preemption disabled at:[<ffffffc0009cc934>] printk+0x7c/0x8c [01-02 07:45:29.883] <4>[ 8.510218] c0 [01-02 07:45:29.883] <4>[ 8.510242] c0 CPU: 0 PID: 1 Comm: init Tainted: G W O 3.18.12+ #1 [01-02 07:45:29.883] <4>[ 8.510263] c0 Hardware name [01-02 07:45:29.884] <0>[ 8.510282] c0 Call trace: [01-02 07:45:29.884] <38>[ 8.510987] c4 logd.auditd: policy loaded [01-02 07:45:29.884] <4>[ 8.512944] c0 [<ffffffc00008b480>] dump_backtrace+0x0/0x164 [01-02 07:45:29.884] <4>[ 8.512958] c0 [<ffffffc00008b600>] show_stack+0x1c/0x28 [01-02 07:45:29.884] <4>[ 8.512972] c0 [<ffffffc0009cd570>] dump_stack+0x74/0xb8 [01-02 07:45:29.885] <4>[ 8.512988] c0 [<ffffffc0000e3414>] __might_sleep+0x198/0x1a0 [01-02 07:45:29.885] <4>[ 8.513003] c0 [<ffffffc0001e2e68>] __kmalloc_track_caller+0x220/0x2ac [01-02 07:45:29.885] <4>[ 8.513017] c0 [<ffffffc0004a8fe0>] devm_kmalloc+0x38/0x84 [01-02 07:45:29.885] <4>[ 8.513032] c0 [<ffffffc000666954>] of_devfreq_cooling_register_power+0xfc/0x314 [01-02 07:45:29.885] <4>[ 8.513060] c0 [<ffffffbffc02b27c>] kbase_devfreq_init+0x268/0x2dc [mali_kbase] [01-02 07:45:29.885] <4>[ 8.513092] c0 [<ffffffbffc018658>] kbase_release_device+0x38e0/0x3c2c [mali_kbase] [01-02 07:45:29.885] <4>[ 8.513106] c0 [<ffffffc0004a7610>] platform_drv_probe+0x50/0xcc [01-02 07:45:29.885] <4>[ 8.513120] c0 [<ffffffc0004a52c4>] driver_probe_device+0xb4/0x3c8 [01-02 07:45:29.885] <4>[ 8.513132] c0 [<ffffffc0004a56dc>] __driver_attach+0xa8/0xb0 [01-02 07:45:29.885] <4>[ 8.513145] c0 [<ffffffc0004a3150>] bus_for_each_dev+0x68/0xac [01-02 07:45:29.885] <4>[ 8.513158] c0 [<ffffffc0004a4c90>] driver_attach+0x28/0x34 [01-02 07:45:29.885] <4>[ 8.513170] c0 [<ffffffc0004a4894>] bus_add_driver+0x16c/0x248 [01-02 07:45:29.885] <4>[ 8.513183] c0 [<ffffffc0004a6074>] driver_register+0x6c/0x138 [01-02 07:45:29.885] <4>[ 8.513196] c0 [<ffffffc0004a7528>] __platform_driver_register+0x74/0x84 [01-02 07:45:29.885] <4>[ 8.513222] c0 [<ffffffbffc04b01c>] init_module+0x1c/0x28 [mali_kbase] [01-02 07:45:29.885] <4>[ 8.513235] c0 [<ffffffc000082acc>] do_one_initcall+0xcc/0x1e8 [01-02 07:45:29.885] <4>[ 8.513248] c0 [<ffffffc00013b1cc>] load_module+0x1728/0x1e08 [01-02 07:45:29.886] <4>[ 8.513259] c0 [<ffffffc00013b998>] SyS_init_module+0xec/0x148 [01-02 07:45:29.887] <6>[ 8.513381] c0 mali 60000000.gpu: Dynamic power table: 850 MHz @ 800 mV: 124 = 124 mW [01-02 07:45:29.887] <6>[ 8.513396] c0 mali 60000000.gpu: Dynamic power table: 768 MHz @ 800 mV: 112 = 112 mW 楼主，在稳定性测试中经常会发现类似问题，不知道如何解决，还请帮忙看看。谢谢。

@hello-world：昨晚的疑问是 在单核系统下，两个线程共同访问同个变量，利用原子操作进行自加。当线程1 获得这个变量内存的访问权，这时被线程2抢占，线程2也获取这个内存的访问权，进行多次累加，当线程2再次获得访问权时，这时被线程1抢占，线程1继续之间的自加动作，并且将累加的值写回内存。 上面就是场景，这种情况会导致累加结果回退，请问如何避免这种情况？？？