On 9/4/2011 16:31, Mouse wrote:
How do I find the current interrupt list on an IPX that the OS knows about? I'm trying to figure out what interrupts are being used by the two serial ports and their priority versus other system interrupts.Is this a one-off debugging-info sort of thing, or is this something you want to be able to do programmatically and reliably? In the former case, isn't that information embedded in the boot-time autoconfig messages? In the latter, I suspect you're not going to find such an interface; that strikes me as the kind of information userland normally shouldn't be caring about, so you probably will have to add a custom interface for it. (If you care to say, why _do_ you care?)
It is just a one-off. Never noticed it in the boot messages but I see them there (ipl and softpri).
I'm still going back and forth with the people on the ntpd list. One person asked about the interrupt priority and whether the port was sharing interrupts or blocking the port. I've narrowed the problem of using the GPS and PPS reference clocks together. Currently, if I use the GPS and PPS reference clocks together, the PPS part never works at all. If I remove the GPS reference clock, PPS works fine.
So I did some testing by using gpsd as my stand-in for the GPS reference clock. I configured ntpd to listen to the shared memory provided by gpsd.
It all boils down to this: If and only if the kernel PPS code is activated by ntpd FIRST, before anything tries to open the serial port to actually read data, I am then able to start up gpsd (and by extension the GPS reference clock) and have both GPS and PPS working simultaneously.
However, if the serial port is captured by gpsd (and by extension the GPS reference clock) FIRST, before the kernel PPS is activated, kernel PPS fails and I get no PPS ticks.
The way ntpd's code is written, it doesn't activate the kernel PPS code until the other clocks have stabilized including a GPS clock if it's there. The GPS clock opens along with all the other clocks right away so it grabs the serial port immediately.
This process appears to work on other platforms since the same code has been in use for a while with no difficulties for other systems. It just isn't quite working here.