2010/6/22 陈宇飞 <cyfde...@gmail.com>: > > On 2010-6-22, at 下午1:46, Artyom Tarasenko wrote: > >> 2010/4/28 陈宇飞 <cyfde...@gmail.com>: >>> I've tested the latest git HEAD version. But still has the problem. >>> >>> Investigating Linux kernel execution shows that the function which will >>> clear the interrupt is not executed. >>> >>> Here's the relevant kernel code. >>> >>> maybe_smp4m_msg: >>> GET_PROCESSOR4M_ID(o3) >>> set sun4m_interrupts, %l5 >>> ld [%l5], %o5 >>> sethi %hi(0x40000000), %o2 >>> sll %o3, 12, %o3 >>> ld [%o5 + %o3], %o1 >>> andcc %o1, %o2, %g0 >>> be,a smp4m_ticker /* Jump to smp4m_ticker, which will clear >>> interrupt */ >>> cmp %l7, 14 /* Comparing the interrupt level*/ >>> st %o2, [%o5 + 0x4] >>> WRITE_PAUSE >>> ld [%o5], %g0 >>> WRITE_PAUSE >>> or %l0, PSR_PIL, %l4 >>> wr %l4, 0x0, %psr >>> WRITE_PAUSE >>> wr %l4, PSR_ET, %psr >>> WRITE_PAUSE >>> call smp_reschedule_irq >>> nop >>> >>> RESTORE_ALL >>> >> >> actually what would be interesting to look at is the code of >> smp4m_ticker - the routine which should clear the irq. >> >>>> On 4/27/10, 陈宇飞 <cyfde...@gmail.com> wrote: >>>>> Actually this has been test before. >>>>> >>>>> http://lists.gnu.org/archive/html/qemu-devel/2006-08/msg00512.html >>>> >>>> That was before I added SMP support to OpenBIOS. >>>> >>>>> I've tested Debian 3.1 (with Linux 2.4.27.3) and Debian 4.0 (with >>>>> Linux 2.6.18.6), on both qemu 0.10.6 and 0.12.3, emulating machine is >>>>> set to SS-20. >>>>> >>>>> 1. non-smp kernel successfully boots with both -smp 1 or -smp 2. >>>>> 2. smp kernel can only boot with -smp 1. (The 2.6 kernel is cross >>>>> compiled by gcc 4.2.4 since no binary package is available) >>>>> >>>>> Some investigation with qemu's debug message and Linux kernel dump >>>>> (the 2.6 kernel) shows that >>>>> >>>>> 1. When the boot cpu tries to start cpu 1, cpu 1 calls >>>>> local_irq_enable. After that, cpu 1 get's lot's of level 14 interrupt. >> >> Is 'cpu 1' the first or the second cpu? > > 'cpu 1' is the second cpu. > >> >>>>> 2. Printing out the executed TBs' pc values shows that kernel >>>>> interrupt handler is executed. >>>>> 3. Qemu's do_interrupt debug message shows that cpu 1 always get level >>>>> 14 interrupt at the same pc, which is the nop instruction just after >>>>> the "mov %g1, %psr" instruction. >>>>> >>>>> I guess that the interrupt is not cleared even after the execution of >>>>> the interrupt handler. I've found debian installation report which >>>>> boots smp linux kernel, so I thinks this problem is caused by qemu? >> >> Can you please try the patch http://patchwork.ozlabs.org/patch/56338/ ? >> Does it improve the situation? > > I've tested this patch, but still have the same problem.
Can you try enabling debug in hw/slavio_timer.c and hw/slavio_intctl.c and look whether the second cpu tries to write any register there between the interrupts? >>>>> I'm tring to fix this problem but I'm not familiar with sparc >>>>> architecture, is there any clue? >>>> >>>> This sounds awfully familiar to the problems Solaris had with >>>> interrupts. Does the problem still exist with git HEAD version of >>>> QEMU? > -- > Best regards, > Chen Yufei > > -- Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/
