> 在 2007-09-04二的 12:03 +0200，Kevin D. Kissell写道：
> > The 4KEc is a MIPS32 Release 2 processor, for which the implementation
> > of the Cause.TI bit (bit 30) is required. You may have a defective board
> > or a bad FPGA bitfile. Please work with your support contacts at MIPS
> > to verify that this is not the case. It may also be that there's something
> > more
> > subtle going on in the interrupt processing, such that the Cause.TI bit is
> > being
> > cleared before it can be sampled by the code you've changed. But while the
> > patch below presumably solves the symptoms of your problem, I really
> > don't think that a kernel hack based on detecting CoreFPA3 is an appropriate
> > solution. I work every day with Malta/CoreFPGA3 bitfiles and have not
> > seen Cause.TI fail to function in any of the Release 2 core bitfiles I've
> > used.
>
> My board's core is Release 1 core. So Cause.TI bit always is zero. Maybe
> I need update this patch to reflect this, i.e add #ifdef to distinguish
> Release 1 and Release 2. Thanks.
In that case, your core is a 4Kc and not a 4KEc. The "r2" value in the
code you're looking at should therefore be zero. I don't have the rest
of the kernel tree you're using in front of me, but I can't help but suspect
that either cpu_has_mips_r2 has a broken definition, or that handle_iperf_irq()
isn't correctly setting its return value if the r2 argument is zero. There
should in principle be no need to add more #ifdefs than there already are
in the code in question.
Regards,
Kevin K.
|