Re: [Xenomai-core] [PATCH] Adeos for Linux 2.6.19 PowerPC kernels.

[Philippe Gerum <rpm@xenomai.org>]

On Mon, 2007-05-14 at 13:12 +0200, Benjamin Zores wrote:
> Philippe Gerum wrote:
> > FWIW, I've almost finished an I-pipe port over 2.6.21 also using the
> > arch/powerpc tree. It relies on the genirq layer which makes things way
> > more comfortable, and which does not require to redefine particular ack
> > routines but rather keep the original irqchip handlers.
> >   
> That's pretty cool !
> Well, using the genirq layer is definitely the way to go but, as stated, 
> my patch was a port based adeos-1.5 which was kinda old.
> > This should get better when the I-pipe/powerpc development is merged
> > into the main git repo here, which should happen in a reasonable future:
> > http://www.denx.de/cgi-bin/gitweb.cgi?p=ipipe-2.6.git;a=summary
> >   
> Well, I'm waiting for that too.
> Most of embedded devels still relies on ppc arch instead of powerpc
> and I hope this situation will change soon.
> 
> > Note: you are mixing my [and Karim's words] from the orginal Abstract
> > with your words from the new Disclaimer, making the "we" clauses rather
> > confusing. It should be more of a README.alcatel-lucent file than a
> > README.adeos one.
> >   
> I can do so.
> 
> > I had a look at this patch, and I see two issues, one of which can't be
> > solved easily unless you make your code use the genirq layer (see
> > x86-1.7 series and beyond), the other one is simple to fix.
> >   
> I know.
> That's why I said my patch is working but the implementation isn't as 
> nice as I'd like it to be.
> 
> > Calling mask_ack in __ipipe_ack works for edge/level IRQs, but would not
> > be applicable to transparent controllers only requiring the software to
> > send eoi, or per-cpu IRQ flows involving mask+eoi for instance.
> > Basically, this code works because it assumes that all IRQs are somehow
> > managed in level mode thus preventing the interrupt flood, but this may
> > not be always the case. Working with the vanilla genirq layer solves
> > this.
> >   
> I however won't have more time allowed
> to update the patch to use genirq layer.
> 
> > The other issue is an old bug of mine for this port, specifically we
> > need to call irq_enter()/irq_exit() for virtual interrupts too;
> > otherwise, softirqs triggered by virtual ones might be delayed until the
> > next hw interrupt comes in. Something like this would do:
> > [...]
> >   
> Is this patch tested ?

Yes, in my patchset though. Your IRQ handler may still require a valid
cookie value, typically a pointer to some register frame
(__ipipe_tick_regs + cpuid); you could try to replace the NULL value
passed to virq handlers from my patch by the same value passed to root
domain handlers.

> It seems not to work, segfaulting kernel.
> 
> [...]
> I-pipe 1.5-01: pipeline enabled.
> Unable to handle kernel paging request for data at address 0x00000084

> Faulting instruction address: 0xc001c874
> 

If the suggestion above does not work, I guess that objdump on the
kernel image is your friend then, at least to locate the offending
routine.

Oops: Kernel access of bad area, sig: 11 [#1]
> [...]
> 
> 
> I can update the patch but I won't be able to switch to genirq layer.
> So it's up to you to decide whether this patch gets commited or just lay 
> down on mailing lists archives.
> 
> Hoping to see your 2.6.21 patch soon ;-)
> 
> Ben
-- 
Philippe.