Getting PID while in interrupt handler: How?

Getting PID while in interrupt handler: How?

Post by 91F97 » Tue, 07 Apr 1992 06:13:00



Hi.  I'm using ULTRIX.  I have an interrupt handler and multiple children.
An unknown child is generating an interrupt.  Under ULTRIX, the SELECT
statement means something else.
I've grepped all the ".h" files for "pid" and only got 8 hits.  None of these
hits were applicable.
So....
   Does anyone out there know how to find the PID of the child task that
   generated the interrupt while in the interrupt handler?  The handler is
   in the parent.
Thanks...
---
Stephen McLeod
The Eterna Student
 
 
 

Getting PID while in interrupt handler: How?

Post by Jonathan I. Kame » Tue, 07 Apr 1992 07:20:16


   Hi.  I'm using ULTRIX.  I have an interrupt handler and multiple children.

What kind of "interrupts" does the handler handle?  In the kernel, the
term "interrupt handler" has a *relatively* well-understood meaning,
but it is not at all clear what you are referring to in this case.  Do
you mean a signal handler?  If so, for what signal?  If not, then do
you mean an input handler of some sort, driven by a select loop?

   An unknown child is generating an interrupt.

How?  What kind of "interrupt?"  (See above.)

   Under ULTRIX, the SELECT
   statement means something else.

Why do you say that?  I've used select() just fine under Ultrix.  How
does this relate to your problem?

      Does anyone out there know how to find the PID of the child task that
      generated the interrupt while in the interrupt handler?  The handler is
      in the parent.

If you ask a meaningful question, we might be able to answer it.

--

MIT Information Systems/Athena              Moderator, news.answers
    (Send correspondence related to the news.answers newsgroup
        {and ONLY correspondence related to the newsgroup}


 
 
 

Getting PID while in interrupt handler: How?

Post by 91F97 » Tue, 07 Apr 1992 12:11:00




>   Hi.  I'm using ULTRIX.  I have an interrupt handler and multiple children.

>What kind of "interrupts" does the handler handle?  In the kernel, the
>term "interrupt handler" has a *relatively* well-understood meaning,
>but it is not at all clear what you are referring to in this case.  Do
>you mean a signal handler?  If so, for what signal?  If not, then do
>you mean an input handler of some sort, driven by a select loop?

>   An unknown child is generating an interrupt.

>How?  What kind of "interrupt?"  (See above.)

>   Under ULTRIX, the SELECT
>   statement means something else.

>Why do you say that?  I've used select() just fine under Ultrix.  How
>does this relate to your problem?

>      Does anyone out there know how to find the PID of the child task that
>      generated the interrupt while in the interrupt handler?  The handler is
>      in the parent.

>If you ask a meaningful question, we might be able to answer it.

Okay... :)

  I have several child tasks that are generating "SIGUSR1" signals.  
I have one handler in the parent task that is handling these signals.
Is there any way to find out the PID of the child that sent the signal
to which the child is now responding?

I was told on some systems that Select could find this informations but I
am on ULTRIX and I was told that on ULTRIX the Select statement is used
for i/o and cannot be used to find the PID.

I grep'd the header files for "pid" and they only revealed 8 references to
"pid" and none of the references were helpful.

Is this sufficiently clear?  Do you need more information?
---
Stephen McLeod
The Eternal Student

 
 
 

Getting PID while in interrupt handler: How?

Post by Jonathan I. Kame » Tue, 07 Apr 1992 23:39:38


     I have several child tasks that are generating "SIGUSR1" signals.  
   I have one handler in the parent task that is handling these signals.
   Is there any way to find out the PID of the child that sent the signal
   to which the child is now responding?

No.  A signal does not piggyback any information, such as the process
that sent it; all you get when you get a signal is the signal.

The exception to this is SIGCHLD, since you can do a wait() when you
get a SIGCHLD in order to determine what child died, but SIGCHLD is
special in any case.

If you need to know what child generated your interrupt, then you're
going to have to use some other interrupt mechanism besides signals.
For example, you could open a pipe in the parent before forking the
children, and have the children write their PID's into the pipe when
they are sending a SIGUSR1 now.  The parent can enable asynchronous
I/O on the pipe, and install a SIGIO signal handler which will be
activated when there is input on it, and then read the PID's from the
pipe in order to determine what child is asking for attention.

   I was told on some systems that Select could find this informations but I
   am on ULTRIX and I was told that on ULTRIX the Select statement is used
   for i/o and cannot be used to find the PID.

I don't know of any UNIX systems where select() does anything besides
I/O.

--

MIT Information Systems/Athena              Moderator, news.answers
    (Send correspondence related to the news.answers newsgroup
        {and ONLY correspondence related to the newsgroup}

 
 
 

1. driver: interrupt handler not getting called

Into the last leg of my driver saga, I hope.

I think i've got everything set up for basic operation.  DMA allocated,
all that stuff.
My attach routine calls

        ddi_add_intr(dip, 0, NULL, 0, hpt_handle_intr, (caddr_t) softstate);

and my strategy func sets the device registers. I do a read of the status
regs immediately after supposedly starting a transfer.
It shows as "busy", and the error flag is clear...

So why does my interrupt routine never get called?

I have a cmn_err() as the first thing in hpt_handle_intr, but I never
see a message, and the dd to my device hangs.

Any ideas, folks?

--
[Trim the no-bots from my address to reply to me by email!]
[ Do NOT email-CC me on posts. Pick one or the other.]

The word of the day is mispergitude

2. aterm doesnt' refresh

3. Getting children's PID with parent's pid?

4. UserFs: Any folks to help developing ideas for it?

5. Handlers, Handlers, Handlers

6. Module aliases

7. Ethernet interrupts getting processed as timer interrupts

8. SUN multicast problem

9. Problems with interrupt handler

10. interrupt handler

11. aiee, killing interrupt handler

12. aiee, killed interrupt handler - kernel panic

13. Serializing data & device access across file ops and interrupt handler