Nested interrupts in IA64 linux?

Nested interrupts in IA64 linux?

[ameya.mitragotri]

Hi,
A couple of queries on interrupts in IA64.

kernel Version: linux 2.6.2
Platform: Itanium-2 (2 CPU) 

1) Intel's manual  (Intel Itanium Architecture: Software Developers
Manual : Volume II) Chapter 3.4.3 (page 2:417) says that nested
interrupts are not supported. But the linux kernel source code 
(ia64_handle_irq) has some comment regarding handling nested 
interrupts. It's a little confusing here. Can anyone throw
some light on this? 

Does Linux support nested interrupts on IA64?

We tried to check our assumption (that it doesn't) by putting a 
mdelay in an interrupt context and found that no other interrupts are
received before the current one is over.

2) We tried to ack the current interrupt. The interrupt we were working
on was level triggered (USB keyboard). 
We did this:
a. Called ->end() of the interrupt descriptor. This will send an EOI to
the IOSAPIC. b. Called ia64_eoi() which sends eoi to the processor. c.
These steps should enable the next interrupts(??). d. We polled on ivr
to get the next interrupts in a loop as done in ia64_handle_irq
function). But this loop never returns a valid interrupt and continues
indefinitely.

The question is: 
are ->end() and ia64_eoi() (along with local_irq_enable()) sufficient to

ack an interrupt and accept the next one?

We are trying to do this because we want to dump (using LKCD) in a
keyboard 
interrupt context. This dump performs write on the SCSI device(Fusion
MPT), 
but we never seem to receive a SCSI interrupt indicating write
completion. 

This works perfectly fine if it is not from an interrupt context. Any
pointers will be really helpful.

Thanks and regards,
Ameya

Re: Nested interrupts in IA64 linux?

[David Mosberger]

>>>>> On Sat, 14 Feb 2004 12:10:27 +0530, ameya.mitragotri@wipro.com said:

  Ameya> Does Linux support nested interrupts on IA64?

Yes.

  Ameya> We are trying to do this because we want to dump (using LKCD)
  Ameya> in a keyboard interrupt context. This dump performs write on
  Ameya> the SCSI device(Fusion MPT), but we never seem to receive a
  Ameya> SCSI interrupt indicating write completion.

Interrupts are divided into priority classes (16 vectors per class).
An interrupt at a vector that maps to a lower-or-equal class cannot
interrupt a pending interrupt.  The exact irq mapping will depend on
your machine (and may depend on the kernel), but here is an example
for a zx2000:

$ cat /proc/interrupts
           CPU0
 28:        132          LSAPIC  cpe_poll
 29:          0          LSAPIC  cmc_poll
 31:          0          LSAPIC  cmc_hndlr
 48:          0  IO-SAPIC-level  acpi
 49:      15566   IO-SAPIC-edge  serial
 60:         30  IO-SAPIC-level  sym53c8xx
 61:     445042  IO-SAPIC-level  sym53c8xx
 62:      76142  IO-SAPIC-level  ohci_hcd
 63:     170072  IO-SAPIC-level  ohci_hcd
 64:          0  IO-SAPIC-level  ehci_hcd
 65:         19  IO-SAPIC-level  ide1
 66:    2985681  IO-SAPIC-level  eth0
 67:          0  IO-SAPIC-level  FM801
232:          0          LSAPIC  mca_rdzv
238:          0          LSAPIC  perfmon
239:  121556726          LSAPIC  timer
240:          0          LSAPIC  mca_wkup
NMI:          0
ERR:          0

In this case, the SCSI controllers (sym53c8xx) are at vectors 60 and
61, which maps to priority class 3.  The USB vectors (62-64) map to
either priority class 3 or 4, so it's not surprising that you don't
get any SCSI interrupts while handing a (USB) keyboard interrupt.

If you want to force SCSI interrupts to come through, you'd have to
lower the task-priority-register (TPR).  You can see in
ia64_handle_irq() how this is done.  Of course, do this at our own
risk!

	--david

RE: Nested interrupts in IA64 linux?

[Luck, Tony]

Ameya,

Perhaps your confusion about whether nested interrupts
are supported comes from the definition of the PSR.i
bit?  When PSR.i is set to zero, then all interrupts of
all priorities are blocked.  The cpu does clear PSR.i
when an interrupt occurs ... so that the OS handler
can do whatever it needs to do so save enough processor
state to allow the interrupt handler to execute.

Linux restores PSR.i from the saved value relatively
soon after beginning execution of Linux handler code.
This re-enables interrupts (at the processor level).

-Tony

> -----Original Message-----
> From: David Mosberger [mailto:davidm@napali.hpl.hp.com]
> Sent: Saturday, February 14, 2004 12:04 AM
> To: ameya.mitragotri@wipro.com
> Cc: linux-ia64@vger.kernel.org; davidm@napali.hpl.hp.com; 
> kaos@sgi.com;
> Luck, Tony
> Subject: Re: Nested interrupts in IA64 linux?
> 
> 
> >>>>> On Sat, 14 Feb 2004 12:10:27 +0530, 
> ameya.mitragotri@wipro.com said:
> 
>   Ameya> Does Linux support nested interrupts on IA64?
> 
> Yes.
> 
>   Ameya> We are trying to do this because we want to dump (using LKCD)
>   Ameya> in a keyboard interrupt context. This dump performs write on
>   Ameya> the SCSI device(Fusion MPT), but we never seem to receive a
>   Ameya> SCSI interrupt indicating write completion.
> 
> Interrupts are divided into priority classes (16 vectors per class).
> An interrupt at a vector that maps to a lower-or-equal class cannot
> interrupt a pending interrupt.  The exact irq mapping will depend on
> your machine (and may depend on the kernel), but here is an example
> for a zx2000:
> 
> $ cat /proc/interrupts
>            CPU0
>  28:        132          LSAPIC  cpe_poll
>  29:          0          LSAPIC  cmc_poll
>  31:          0          LSAPIC  cmc_hndlr
>  48:          0  IO-SAPIC-level  acpi
>  49:      15566   IO-SAPIC-edge  serial
>  60:         30  IO-SAPIC-level  sym53c8xx
>  61:     445042  IO-SAPIC-level  sym53c8xx
>  62:      76142  IO-SAPIC-level  ohci_hcd
>  63:     170072  IO-SAPIC-level  ohci_hcd
>  64:          0  IO-SAPIC-level  ehci_hcd
>  65:         19  IO-SAPIC-level  ide1
>  66:    2985681  IO-SAPIC-level  eth0
>  67:          0  IO-SAPIC-level  FM801
> 232:          0          LSAPIC  mca_rdzv
> 238:          0          LSAPIC  perfmon
> 239:  121556726          LSAPIC  timer
> 240:          0          LSAPIC  mca_wkup
> NMI:          0
> ERR:          0
> 
> In this case, the SCSI controllers (sym53c8xx) are at vectors 60 and
> 61, which maps to priority class 3.  The USB vectors (62-64) map to
> either priority class 3 or 4, so it's not surprising that you don't
> get any SCSI interrupts while handing a (USB) keyboard interrupt.
> 
> If you want to force SCSI interrupts to come through, you'd have to
> lower the task-priority-register (TPR).  You can see in
> ia64_handle_irq() how this is done.  Of course, do this at our own
> risk!
> 
> 	--david
>