LinuxQuestions.org
Review your favorite Linux distribution.
Home Forums Tutorials Articles Register
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Hardware > Linux - Embedded & Single-board computer
User Name
Password
Linux - Embedded & Single-board computer This forum is for the discussion of Linux on both embedded devices and single-board computers (such as the Raspberry Pi, BeagleBoard and PandaBoard). Discussions involving Arduino, plug computers and other micro-controller like devices are also welcome.

Notices


Reply
  Search this Thread
Old 09-18-2007, 04:38 PM   #1
EmbeddedSteve
LQ Newbie
 
Registered: Sep 2006
Posts: 17

Rep: Reputation: 0
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
 
  


Reply



Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Restarting an ISR in a transaction-like style rnkayab Programming 8 08-25-2006 02:00 PM
Handling of Interrupts in thread context asurya Linux - Newbie 1 04-05-2006 09:15 AM
Why Nics Canceling SSH Comm. meping Linux - Networking 1 09-28-2005 12:45 PM
Debugging ISR eshwar_ind Programming 1 06-18-2005 04:31 PM
Pentium Timer ISR obashir Programming 0 04-27-2003 04:45 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Hardware > Linux - Embedded & Single-board computer

All times are GMT -5. The time now is 04:15 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration