Canceling ISR Thread cause extra Interrupts
I have a rather strange problem with an embedded system. The host CPU is a PMPPC440. It's a PMC Module, plugs into a motherboard with all of the other "stuff". It communicates over the PCI bus to a PLX bridge chip.
The application we run is multi-threaded, including the ISR, which is it's own Thread. We're running a Linux 2.4.21 kernel for this board and we're using POSIX pThreads. We setup various threads with different priorities and run as root (using sudo and some admin magic).
The problem is: When I go to cancel the ISR thread, which is the highest priority thread in the system (from the "main" thread which is set to 50), it seems that the kernel somehow "runs" the thread and we see in our log file ~ 64 "interrupts" occurring, eventhough we have verified via a Logic Analyzer that NO PHYSICAL INTERRUPT occurs.
The 64 interrupts are key, in that in the driver, there is a 64 entry "task queue" that exists between the actual ISR handler and a tasklet. When the ISR gets the physical interrupt, it puts the status on the queue and schedules the tasklet. The tasklet then just wakes up the IOCTL that is hanging on yet another queue, which then returns to the ISR thread, passing back this status. The ISR thread will then parse this and then call registered handlers to process the appropriate interrupt.
I know, the driver is a bit "funky", it uses IOCTL's, but this was done before my time. We've already found a race condition in the kernel where need to use "wait_event_interruptible" vs. "interruptible_sleep_on" in order to stop a hang condition we encountered.
So, when we cancel the ISR thread, this task queue seems to be getting messed up (tail > head) and we run around the queue until head == tail. This is verified by matching timestamps on queue entries. Then, when we re-run the code, when we start the ISR thread (pthread_create), we again, get to run around the queue 64 times.
I need to remove this anomaly in order to implement a new feature that will properly handle interrupts.
Any suggestions are greatly appreciated!
Thanks in Advance!
Stephen
|