Re: [perfmon2] panic on mips when using sampling
Status: Beta
Brought to you by:
seranian
From: Philip M. <mu...@cs...> - 2007-12-02 19:21:00
|
Hi Vince, The particular code base you have has only been verified on an SB1, although versions of it work on my MIPS5K and the SiCortex node chip, all MIPS64 variants. My advice here would be boot uniprocessor here, without CONFIG_SMP and see if you get any further along. printk might be a bit more friendly then. One thing I ran into was that request_irq was not SMP safe in our version of Linux/MIPS (2.6.15). It was only good for per-node interrupts. The symptom was that the interrupt enable mask register did not get properly updated. This has probably been fixed in the code base, but it's also something to look out for. Phil On Dec 2, 2007, at 12:37 AM, Vince Weaver wrote: > >> Vince, this flush code exists also in the code that writes to the >> sample buffer, except that happens inside of an interrupt handler, >> which, if that went south, would cause a hard lock. Just an idea. > > has sampling ever been tested on MIPS? If it is known to work > normally, > the problem might be with the interrupt handling of this particular > hardware. > > I've spent a lot of time adding printk()s to the code, tracing what is > happening. The last thing I can get to log is the sys_pfm_start() > completing properly... some program output happens, and then a hard > lock. > It's quite possible this is when the first overflow interrupt would > happen. I've tried putting printk's in the interrupt handler (is that > allowed?) but do not get any output on ther serial console. I've also > tried replacing the interrupt handler with an empty one, but things > still > lock. > > This happens even when the cache-flushing code is disabled, so I don't > think it's necessarily cache-flushing related. > > I'll check with the people who are doing the port to this hardware > (SGI > IP30) to see if there are any known problems with interrupts. > > Vince > |