SGI Octane & SMP, stuck in calibrate_delay(), help?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



So I've been messing around with getting the SGI Octane to boot Linux again,
using some old patches I was sent several years ago, but forgot about
(credit goes to Tanzy for creating them).  A *lot* of devices are really
slow, however.  I suspect problems with the way I've got the IRQ handling
set up at the moment.  I.e., hdparm -t on MD-RAID SCSI reports 9MB/sec if
you boot with init=/bin/bash, or ~4.5MB/sec if I boot it normally.  It is
running an old Gentoo userland from ~2009, however, and there may be
something screwy w/ a modern (3.14.3) kernel against such an old userland.

Right now, though, I am trying to get SMP working (again).  I've gotten
IPI's setup via a percpu mailbox, but bringing up the second CPU is proving
to be very problematic.  It's hanging up in calibrate_delay(), when called
from arch/mips/kernel/smp.c::start_secondary().

Currently:
 - ip30_prepare_cpus: Acquires IPI IRQ for CPU0, unmasks STATUSF_IP4 (IPI).
 - ip30_boot_secondary: Sets sp/gp on CPU1 and boots it up. [1]
 - ip30_init_secondary: Unmasks STATUSF_IP{2,3,4,5,6,7} on CPU1 [2]
 - ip30_smp_finish: Acquires IPI IRQ for CPU1, enables local interrupts.

Notes:
1. I have discovered that if a printk() or pr_*() function is NOT placed
immediately at the end of the function, CPU1 is never launched.  This
appears to kickstart the CPU so that it probes itself and reports data to
dmesg.  Has anyone else seen this on other SMP platforms?

2. From reading other MIPS SMP implementations, all I need to do in
mp_ops->init_secondary is to set the interrupt mask bits in the CAUSE
register.  But this is where the machine hangs in calibrate_delay().  I
tried adding local_irq_enable() immediately after, which I know isn't
correct (that belongs in smp_finish), and that gets it to tick a few times,
but then it stops again.

This system uses the CONFIG_CEVT_R4K and CONFIG_CSRC_R4K for the CPU timers,
but it looks like cevt-r4k.c is rigged to only install one CPU timer -- any
other calls by other CPUs returns out of the r4k_clockevent_init function
early.  Older IP30 code included timer broadcasting bits, too, but these
were using IRQs that were hardwired to other functions in HEART (the system
ASIC/interrupt controller), so I dropped that approach.  I also don't think
they were compatible w/ the clockevent code added in ~2.6.24.

So, I am out of ideas.  Anyone got other ideas to try?

Thanks!,

-- 
Joshua Kinard
Gentoo/MIPS
kumba@xxxxxxxxxx
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic


[Index of Archives]     [Linux MIPS Home]     [LKML Archive]     [Linux ARM Kernel]     [Linux ARM]     [Linux]     [Git]     [Yosemite News]     [Linux SCSI]     [Linux Hams]

  Powered by Linux