蜗窝科技

我想问一下，BLE时分过程是怎么时分的？比如两个从设备与主设备通信，同时还有主设备可以作为别的设备的从设备，整个过程怎么理解？望解答

您好linuxer,我有个疑问：在local_irq_disable中最终是对cpsr寄存器的I位置位，那么这个local是怎样体现出来的呢？是不是在一个多核cpu中其中每一核都有一个独立的cpsr寄存器

楼主，请问为什么softirq在同一个CPU上要串行化处理呢？为什么不可以像中断那样：低优先级的softirq可以被高优先级的softirq抢占并先执行呢？是防止功能错误还是性能考虑呢？

@linuxer：@linuxer： 谢谢你的解答，我现在明白了，所以kernel的地址（image地址 - TEXT_OFFSET）一定是放在物理地址的首地址处，才能将正确的物理地址位置放到x24中

@linuxer：谢谢linuxer回复；再麻烦下，还有个疑问，求详细解答下 1. 那个timer中断是怎么发起的呢？由谁 什么时候触发的，和上面的日志线程有关吗 不知道是不是这样：按文章的介绍，应该是硬件发起一个hard irq（这里可能是磁盘驱动），然后raise timer softirq？ timer超时是内核不断去检查么？ 2. 明白，但如果中断上下文有访问共享资源，也是要类似线程，加锁吧？ ------- 不过在linux的世界不是这么玩的。中断上下文是非常轻的，其实不算是线程。 -------

@tczb：你的场景我猜是这样的：文件系统的日志线程愉快的运行，但是被一次timer的中断无情的插入了，因为blk的一个timer到期了，因此转到那个timer的handler中执行，在这个timer handler执行过程中，出现了严重的问题，导致kernel panic了。 你的场景包括一个内核线程和timer的中断上下文（hw irq和soft irq context），没有两个线程，当然，如果你认为中断上下文也是一种“线程”，那么就两个线程好了，哈哈，不过在linux的世界不是这么玩的。中断上下文是非常轻的，其实不算是线程。

你好，有一个相关的问题请教： 我在用一块ARM（CortexA7）板子，板子上用两个CPU分别运行T-Kernel和Linux，Linux内核加载地址在内存后半部（高地址），但是现在想访问内核加载地址以前的内存（地址小于内核加载地址）。本以为SPARSEMEM可以解决这个问题，但是内核加载地址以前的内存仍被忽略。。。请问可有什么解决办法。。。 下面是启动时输出的log： OF: fdt:Ignoring memory block 0x60000000 - 0x6a000000

@raceant：需要定义内存物理地址的起始位置吗？一般情况下，kernel image被copy到（内存首地址＋TEXT_OFFSET）这样的一个位置上去，因此，在没有打开MMU的时候，代码中实际上是有技巧可以获取自己执行在哪一个地址上的。 adrp x24, __PHYS_OFFSET x24中即保存了内存的物理地址。 编译器在编译这一条指令的时候，把该指令所在的虚拟地址和__PHYS_OFFSET的offset保存在了指令的imm域。当实际运行的时候，x24被赋值为当前PC值＋offset，也就是内存的物理地址了。BTW，上面说的实际上是需要对齐到page size的。

文章写得很好,现在看起来也收获很大 @linuxer, 也麻烦请教几个问题(和中断相关)，感谢： 我遇到一个kenerl panic，oops如下，有几个疑惑： 1. Call trace里面分2部分，以Exception stack为分界，上面的中断处理和下面的kthread，在内核中是2个线程分别在处理吗？ 2. 中断处理do_softirq，应该是个TIMERIRQ，回调函数是blk_mq_rq_timer，这个软中断是由内核(时钟计时)自动启动线程来调用的吗？用户态不可控？ 3. 如果1成立，这2个线程应该存在竞争关系？处理不当，可能会有race condition问题 Call trace: [<ffffffc000350690>] blk_mq_tag_to_rq+0x34/0xc4 [<ffffffc0003552d8>] bt_for_each+0x78/0x114 [<ffffffc0003553e8>] blk_mq_tag_busy_iter+0x74/0x84 [<ffffffc000351254>] blk_mq_rq_timer+0x68/0x138 [<ffffffc0001014e0>] call_timer_fn.isra.29+0x2c/0x9c [<ffffffc000101788>] run_timer_softirq+0x238/0x2d8 [<ffffffc0000a6ec0>] __do_softirq+0x110/0x25c [<ffffffc0000a72c8>] irq_exit+0x90/0xc0 [<ffffffc0000f17f8>] __handle_domain_irq+0x9c/0x10c [<ffffffc00008250c>] gic_handle_irq+0x50/0xb4 Exception stack(0xffffffc07b24f840 to 0xffffffc07b24f970) f840: 7c20d500 ffffffc0 00000000 00000080 7b24f9b0 ffffffc0 00350b80 ffffffc0 f860: 80000145 00000000 ffffffff 00000000 7b24fa50 ffffffc0 0000001b 00000000 f880: 00302200 00000000 00000000 00000000 7c9aa000 ffffffc0 00000038 00000000 f8a0: 00000000 01000000 00000000 00000000 5d004d80 ffffffc0 00000000 00000000 f8c0: 60db1478 ffffffc0 00000000 00000000 7d66d068 ffffffc0 60db1000 ffffffc0 f8e0: 74733b60 ffffffc0 60da5f08 ffffffc0 60d1a208 ffffffc0 38000000 0000185c f900: 001fbfdc ffffffc0 5b06a72c 00000072 3f800000 00000000 7c20d500 ffffffc0 f920: 00000011 00000000 7ffe2e00 ffffffc0 7dbff880 ffffffc0 7c9b1000 ffffffc0 f940: 7b24fae0 ffffffc0 5d004cc0 ffffffc0 0091b000 ffffffc0 00000009 00000000 f960: 7d642200 ffffffc0 7b24f9b0 ffffffc0 [<ffffffc000085f80>] el1_irq+0x80/0xf4 [<ffffffc000352ac4>] blk_mq_map_request+0xbc/0x1d4 [<ffffffc000353fc8>] blk_sq_make_request+0x80/0x29c [<ffffffc000344608>] generic_make_request+0xd8/0x154 [<ffffffc000344728>] submit_bio+0xa4/0x1c0 [<ffffffc0001e9108>] _submit_bh+0x158/0x240 [<ffffffc0001e9214>] submit_bh+0x24/0x2c [<ffffffc00029cbe4>] jbd2_journal_commit_transaction+0x9ac/0x1998 [<ffffffc0002a246c>] kjournald2+0xd8/0x2ac [<ffffffc0000c5d4c>] kthread+0xe8/0x104 Code: f9403000 f8765813 f9401a74 f9401e77 (f9406a95) ---[ end trace 75da3e8cdd880aeb ]--- Kernel panic - not syncing: Fatal exception in interrupt

@zecho：cpu0 和 cpu1是在node0里， message queue是在cache和bus之间，所以cpu0对a的值可以更新到cpu0和cpu1的共享cache里，所以cpu1可以看到， 但 cpu0的message queue是满了，所以invalidate的消息发不到cpu2. 所以这里的核心问题是message queue是在cache下面（图中)，而不是cache上面