Hi, Aurelien, After some days debugging, we found the root cause: If we revert the commit 21b40200cfe961 (aio: use flush_dcache_page()), everything is OK. This commit add two flush_dcache_page() in irq disabled context, but in MIPS, flush_dcache_page() is implemented via call_function IPI. Unfortunately, call_function IPI shouldn't be called in irq disabled context, otherwise there will be deadlock. I don't know how to solve this problem, since commit 21b40200 shouldn't be reverted (Loongson can revert it because of hardware-maintained cache, but other MIPS need this). May be the original author (Kent Overstreet) have good ideas? Huacai On Sat, Jul 26, 2014 at 10:51 PM, Aurelien Jarno <aurelien@xxxxxxxxxxx> wrote: > On Sat, Jul 26, 2014 at 02:05:28PM +0800, 陈华才 wrote: >> Hi, >> >> I'm debugging, please wait for some time. > > Great, thanks! Does it means you have been able to reproduce the issue? > If not I can provide you a copy of the chroot I used to reproduce the > issue. > > I also tried with the kernel from > http://dev.lemote.com/cgit/linux-official.git/ but unfortunately > I haven't been able to get it working correctly with > PREEMPT_VOLUNTARY=yes. I have tried with the kernel from the master > branch and after merging the v3.15.6 tag. In one of the case I got the > following backtrace on the serial console: > > | [ 75.128906] irq 17, desc: ffffffff80c911e0, depth: 1, count: 0, unhandled: 0 > | [ 75.136718] ->handle_irq(): ffffffff80289a18, handle_bad_irq+0x0/0x2d0 > | [ 75.144531] ->irq_data.chip(): ffffffff80cbe210, 0xffffffff80cbe210 > | [ 75.144531] ->action(): (null) > | [ 75.144531] IRQ_NOPROBE set > | [ 75.144531] unexpected IRQ # 17 > > Aurelien > > -- > Aurelien Jarno GPG: 4096R/1DDD8C9B > aurelien@xxxxxxxxxxx http://www.aurel32.net >
