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
On 2010-4-28, at 上午2:23, Blue Swirl wrote:
> 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.
>> 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?
>>
>> 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
