Re: lost interrupt on Blade 100/150 with "newer" OBP

[Eduardo Horvath <eeh%NetBSD.org@localhost>]

On Tue, 19 Aug 2008, doomwarrior wrote:

> > Rather than look at the differences in code bases it might be easier to just
> > debug the problem.
> >   
> The last time I try to build a kdbg kernel for sparc64 doesn't work for me.
> The serial port wasn't buildable with kdbg or simply don't work (can't
> remember in detail). I asked on the list and got reply it is not working.
> So If you have some newer information about this, please go ahead...

You don't want kgdb for this anyway since you need to poke around in 
device registers.  You want to either use DDB or OpenBoot.

> > What you can do is do something to trigger the interrupt at the IDE driver,
> > then examine the interrupt diagnostic registers to see which interrupt is in
> > the pending state.  This will tell you what the mondo for that interrupt
> > really is.  Then by comparing that to the results of OF_mapintr() you can
> > probably find and fix the bug.
> >   
> as I already try to explain, in OF_mapintr and all functions which are called
> by mapintr are the same - based on OpenBSD 3.3. So this can't be the problem.
> Maybe there are side effects. But this isn't so trivial. (at least for me)

So you verified that the output of OF_mapintr() corresponds to the 
interrupt that has been posted by the IDE controller?

> But never the less I found some code, wich is strange to me. I missing some
> va_ends in OF_interpret function of Sparcs openfirmware.c. I compared the
> function to openbsd at it looks different. There are several va_ends.
> I don't have a specification for openfirmware interface, but I think it is odd
> to do a va_start without completing the call with va_end. For me it is like
> malloc/new <-> free/delete. At least a comment should be added, if it is
> really ok.

va_end should be a noop on sparc V9.  And I don't think OF_interpret() is 
ever actually called.  But I suppose you can fix this if you want.

Eduardo