RE: Interrupt handling....

RE: Interrupt handling....

[Matthew Dharm]

Okay... I think I've got a problem that isn't covered by the usual
examples.

I'm now trying to implment a second-level interrupt demuxer.  My
exception handler, when it sees a certain bit set in the CP0_CAUSE
register set, attempts to read from the second-level controller.  The
problem is, that code looks like this:

	li	t0, 0xfc000000
	lb	t1, 0xc(t0)

Which, as you can see, attempts to access address 0xfc00000c.  And
then I get:

Unable to handle kernel paging request at virtual address fc00000c,
epc == 801af2ac, ra == 80102eb8
Oops in fault.c::do_page_fault, line 206:

I'm guessing I'm in trouble here.  My instincts tell me the the only
way out of this might be to add a wired TLB entry to make certain I
can always access physical address 0xfc00000c... but I'm hoping there
is a better solution than tying up a TLB entry like that.  After all,
isn't that what ioremap is supposed to do?

Matt

--
Matthew D. Dharm                            Senior Software Designer
Momentum Computer Inc.                      1815 Aston Ave.  Suite 107
(760) 431-8663 X-115                        Carlsbad, CA 92008-7310
Momentum Works For You                      www.momenco.com

> -----Original Message-----
> From: linux-mips-bounce@linux-mips.org
> [mailto:linux-mips-bounce@linux-mips.org]On Behalf Of Jun Sun
> Sent: Thursday, August 29, 2002 1:46 PM
> To: Matthew Dharm
> Cc: Linux-MIPS
> Subject: Re: Interrupt handling....
>
>
> Matthew Dharm wrote:
> > I've taken it upon myself to re-write some interrupt
> handling code.
> > It's a mess, and it needs cleaning.
> >
>
> That is usually a right attitude to start ... :=)
>
> >
> > An interrupt handler must be registered with
> set_except_vector(0, ...)
> > which must return a numeric code in the range of
> 0..NR_IRQS -- it can
> > do this in any way it wants, including limited function calls (ie
> > there is a stack in place).
> >
>
> Interrupt is setup throught request_irq()/setup_irq().
> set_except_vector()
> for setting exception handlers, which is different from interrupts.
>
> > The irq_desc array of irq_desc_t structures is where the magic
> > happens.  The value returned by the interrupt handler is
> used as an
> > index into this array to do the dispatch a specific handler.  The
> > 'status' and 'action' fields are pretty much
> self-explanatory.  The
> > 'handler' field seems to point to a set of function
> pointers used for
> > enabling/disabling the IRQ.  But what is 'depth' for?
> Boards seem to
> > set it to either 0 or 1 commonly, but I don't see why.
>
> For nested disabling and enabling of interrupts.
>
> > I also don't
> > see how IRQ sharing is accomplished...
>
> Yes, it is there.  See do_IRQ() and a sub-routine
> handle_event() (or something
> like that)
>
>  > Is this pretty much how it all works?
>
> I have a more detailed description in my porting guide.
>
> http://linux.junsun.net/porting-howto/porting-howto.html#cha
pter-interrupt

Jun

RE: Interrupt handling....

[Dominic Sweetman]

Matthew,

> Okay... I think I've got a problem that isn't covered by the usual
> examples.

Possibly this is too simple an answer and is stuff you know quite well
already...

> Which, as you can see, attempts to access address 0xfc00000c.

But that address is in the MIPS CPU's 'kseg2' region.  Addresses there
are always translated by the TLB, and you haven't got an entry.

Registers from things like the 2nd level interrupt controller are
memory mapped I/O locations, and you need to do an uncached access to
the appropriate physical address.

Most MIPS hardware has registers mapped between 0-512Mbyte
(0-0x1fff.ffff) physical, because a MIPS CPU can do uncached accesses
to that using the 'kseg1' window, which occupies the 

  0xa000.0000-0xbfff.ffff  (CPU virtual address)
  0x0000.0000-0x1fff.ffff  (physical address).

There are macros defined for translating a physical address into a
kseg1 address (just add 0xa000.0000, really).

You could read the book ("See MIPS Run")...

-- 
Dominic Sweetman, 
MIPS Technologies (UK) - formerly Algorithmics
The Fruit Farm, Ely Road, Chittering, CAMBS CB5 9PH, ENGLAND
phone: +44 1223 706200 / fax: +44 1223 706250 / direct: +44 1223 706205
http://www.algor.co.uk

RE: Interrupt handling....

[Maciej W. Rozycki]

On Wed, 4 Sep 2002, Dominic Sweetman wrote:

> > Which, as you can see, attempts to access address 0xfc00000c.
> 
> But that address is in the MIPS CPU's 'kseg2' region.  Addresses there
> are always translated by the TLB, and you haven't got an entry.
> 
> Registers from things like the 2nd level interrupt controller are
> memory mapped I/O locations, and you need to do an uncached access to
> the appropriate physical address.

 As I understand 0xfc00000c is the physical address.  Thus you cannot
reach it via KSEG0/1 (although you may use XKPHYS to get there in the
64-bit mode).  Still ioremap() already handles the case mapping the area
requested in the KSEG2 space, so it should work just fine. 

> Most MIPS hardware has registers mapped between 0-512Mbyte
> (0-0x1fff.ffff) physical, because a MIPS CPU can do uncached accesses
> to that using the 'kseg1' window, which occupies the 
> 
>   0xa000.0000-0xbfff.ffff  (CPU virtual address)
>   0x0000.0000-0x1fff.ffff  (physical address).

 As I understand this is an exception.  Possibly the system supports more
than 512MB of RAM and the designers wanted to avoid holes. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: Interrupt handling....

[Matthew Dharm]

On Wed, Sep 04, 2002 at 02:58:26PM +0200, Maciej W. Rozycki wrote:
> On Wed, 4 Sep 2002, Dominic Sweetman wrote:
> 
> > > Which, as you can see, attempts to access address 0xfc00000c.
> > 
> > But that address is in the MIPS CPU's 'kseg2' region.  Addresses there
> > are always translated by the TLB, and you haven't got an entry.
> > 
> > Registers from things like the 2nd level interrupt controller are
> > memory mapped I/O locations, and you need to do an uncached access to
> > the appropriate physical address.
> 
>  As I understand 0xfc00000c is the physical address.  Thus you cannot
> reach it via KSEG0/1 (although you may use XKPHYS to get there in the
> 64-bit mode).  Still ioremap() already handles the case mapping the area
> requested in the KSEG2 space, so it should work just fine. 

This is the case.  The board itself has up to 1G of SDRAM.  Most of the
boards we sell have a minimum of 512MB.  So our I/O (PCI, external devices,
etc.) all have physical addresses in the high-end of the address space.

64-bit mode would be great... and we plan to go there eventually.  But, for
now, 32-bit is where we are.

> > Most MIPS hardware has registers mapped between 0-512Mbyte
> > (0-0x1fff.ffff) physical, because a MIPS CPU can do uncached accesses
> > to that using the 'kseg1' window, which occupies the 
> > 
> >   0xa000.0000-0xbfff.ffff  (CPU virtual address)
> >   0x0000.0000-0x1fff.ffff  (physical address).
> 
>  As I understand this is an exception.  Possibly the system supports more
> than 512MB of RAM and the designers wanted to avoid holes. 

This is exactly the case.  Our organization focuses on high-end computing
platforms.  512MB is becoming a minimum amount of memory for us.

Matt

-- 
Matthew Dharm                              Work: mdharm@momenco.com
Senior Software Designer, Momentum Computer

Re: Interrupt handling....

[Dominic Sweetman]

Matthew Dharm (mdharm@momenco.com) writes:

> >  As I understand 0xfc00000c is the physical address.  Thus you cannot
> > reach it via KSEG0/1 (although you may use XKPHYS to get there in the
> > 64-bit mode).  Still ioremap() already handles the case mapping the area
> > requested in the KSEG2 space, so it should work just fine. 
> 
> This is the case.  The board itself has up to 1G of SDRAM.  Most of the
> boards we sell have a minimum of 512MB.  So our I/O (PCI, external devices,
> etc.) all have physical addresses in the high-end of the address space.

Well, next time, get your board designers to think before they map...

It's generally better to map some DRAM low (for boot ROMs and other
stupid programs you don't want to make big-address aware), then remap
the whole DRAM to some very high address for Linux.  Much better than
forcing you to use the TLB (or XKPHYS, if you've a 64-bit CPU) to get
at I/O.

> 64-bit mode would be great...

Bear in mind that there *isn't a 64-bit mode*.  Privileged code (which
is everything except Linux applications) can always run 64-bit
instructions; all addresses are 64-bits really, it's just the
sign-extension of the registers which makes you think you've got
32-bit pointers.  Usually a 64-bit CPU can access XKPHYS any time
it can access I/O registers.

-- 
Dominic Sweetman, 
MIPS Technologies (UK) - formerly Algorithmics
The Fruit Farm, Ely Road, Chittering, CAMBS CB5 9PH, ENGLAND
phone: +44 1223 706200 / fax: +44 1223 706250 / direct: +44 1223 706205
http://www.algor.co.uk

Re: Interrupt handling....

[Maciej W. Rozycki]

On Wed, 4 Sep 2002, Dominic Sweetman wrote:

> Well, next time, get your board designers to think before they map...
> 
> It's generally better to map some DRAM low (for boot ROMs and other
> stupid programs you don't want to make big-address aware), then remap
> the whole DRAM to some very high address for Linux.  Much better than
> forcing you to use the TLB (or XKPHYS, if you've a 64-bit CPU) to get
> at I/O.

 Hmm, what's the deal?  Other processors always use MMU to access iomem...

> Bear in mind that there *isn't a 64-bit mode*.  Privileged code (which
> is everything except Linux applications) can always run 64-bit
> instructions; all addresses are 64-bits really, it's just the
> sign-extension of the registers which makes you think you've got
> 32-bit pointers.  Usually a 64-bit CPU can access XKPHYS any time
> it can access I/O registers.

 Well, it's mostly a programming convention.  Without going into details,
arch/mips is the 32-bit mode and arch/mips64 is the 64-bit one.  The usual
approximation is the state of cp0.kx, even though 64-bit operations do
indeed work when ~cp0.kx.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: Interrupt handling....

[Matthew Dharm]

On Wed, Sep 04, 2002 at 10:53:55AM +0100, Dominic Sweetman wrote:
> 
> Matthew,
> 
> > Okay... I think I've got a problem that isn't covered by the usual
> > examples.
> 
> Possibly this is too simple an answer and is stuff you know quite well
> already...

Yeah, it is. See my response to Maciej's posting....

> > Which, as you can see, attempts to access address 0xfc00000c.
> 
> But that address is in the MIPS CPU's 'kseg2' region.  Addresses there
> are always translated by the TLB, and you haven't got an entry.

It's also the physical address.

And this is the heart of the problem.  I set up an ioremap, so I thought
that the TLB exception handler would fix this for me.  It looks like that
code won't do anything if the exception was generated from an interrupt...
Or am I reading it wrong?  I'm not an expert on the TLB code...

> You could read the book ("See MIPS Run")...

I read it quite some time ago.  My copy got very dog-eared before I had the
majority of the information committed to memory.  Nice book, BTW.

Matt

-- 
Matthew Dharm                              Work: mdharm@momenco.com
Senior Software Designer, Momentum Computer

Re: Interrupt handling....

[Maciej W. Rozycki]

On Wed, 4 Sep 2002, Matthew Dharm wrote:

> And this is the heart of the problem.  I set up an ioremap, so I thought
> that the TLB exception handler would fix this for me.  It looks like that
> code won't do anything if the exception was generated from an interrupt...
> Or am I reading it wrong?  I'm not an expert on the TLB code...

 The kernel memory is unswappable so a PTE is always available.  If the
TLB refill handler cannot fetch it for some reason, then there is a bug
somewhere.  It might be helpful if you narrowed it down a bit -- refills
work correctly for modules, including interrupt handlers, and they reside
in KSEG2. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

RE: Interrupt handling....

[Matthew Dharm]

Okay... What type of information do you need?

Matt

--
Matthew D. Dharm                            Senior Software Designer
Momentum Computer Inc.                      1815 Aston Ave.  Suite 107
(760) 431-8663 X-115                        Carlsbad, CA 92008-7310
Momentum Works For You                      www.momenco.com

> -----Original Message-----
> From: Maciej W. Rozycki [mailto:macro@ds2.pg.gda.pl]
> Sent: Wednesday, September 04, 2002 10:03 AM
> To: Matthew Dharm
> Cc: Dominic Sweetman; Jun Sun; Linux-MIPS
> Subject: Re: Interrupt handling....
>
>
> On Wed, 4 Sep 2002, Matthew Dharm wrote:
>
> > And this is the heart of the problem.  I set up an
> ioremap, so I thought
> > that the TLB exception handler would fix this for me.  It
> looks like that
> > code won't do anything if the exception was generated
> from an interrupt...
> > Or am I reading it wrong?  I'm not an expert on the TLB code...
>
>  The kernel memory is unswappable so a PTE is always
> available.  If the
> TLB refill handler cannot fetch it for some reason, then
> there is a bug
> somewhere.  It might be helpful if you narrowed it down a
> bit -- refills
> work correctly for modules, including interrupt handlers,
> and they reside
> in KSEG2.
>
> --
> +  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
> +--------------------------------------------------------------+
> +        e-mail: macro@ds2.pg.gda.pl, PGP key available        +
>

RE: Interrupt handling....

[Maciej W. Rozycki]

On Wed, 4 Sep 2002, Matthew Dharm wrote:

> Okay... What type of information do you need?

 Well, first check if a PTE is indeed installed by ioremap() in the table. 
If so, the what happens at the access time -- what exceptions, what are
the contents of the related registers, what does exist in the TLB, etc.
You don't need to go to the IRQ handler at first -- it might be easier to
get such things if you deliberately access the location from elsewhere,
e.g. from the setup code right after ioremap().

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

RE: Interrupt handling....

[Jon Burgess]

>    li   t0, 0xfc000000
>    lb   t1, 0xc(t0)
>
>After all,
>isn't that what ioremap is supposed to do?

I think the problem is that you need to use the pointer which ioremap() returns
to access the region you requested. It looks like you've assumed that ioremap()
will map it 1:1 which I don't think is the case.

i.e.

struct hw_regs *foo;

foo = (struct hw_regs *)ioremap(0xfc000000, <Size>);

foo->command = hw_reset;
...


     Jon

Interrupt handling

[Sanil K]

Hi all,

This may be a generic problem as far as a driver is concerned.

We need to handle an interrupt and inform the user space on the event and
pass the data correspodning to the event.

The event can be informed through SIGNAL and the signal handler can be
invoked in the user space. Then again for data, we need to have the
"copy_to_user" mechanism .

Is there any other effective mechanism(s) to handle the interrupt. I mean
we need to convey the event and or data to the user space(prefer -
asynchronously).

Please share your views.

Sanil.

Re: Interrupt handling

[Richard B. Johnson]

On Thu, 16 Oct 2003, Sanil K wrote:

> Hi all,
>
> This may be a generic problem as far as a driver is concerned.
>
> We need to handle an interrupt and inform the user space on the event and
> pass the data correspodning to the event.
>
> The event can be informed through SIGNAL and the signal handler can be
> invoked in the user space. Then again for data, we need to have the
> "copy_to_user" mechanism .
>

poll() / select() are the usual methods. User code sleeps in
select() or poll() and an interrupt occurs (before/after, doesn't
matter). Driver  code gets the data into a interrupt-safe buffer
then executes wake_up_interruptible() from its ISR. This will cause
the caller, sleeping in poll() to wake up as soon as the
ISR is complete.

The user then, checking poll status and flags, knows that
data are available, the user calls read() to get the data.

It is possible for a user-space program to memory-map
an interrupt-safe (locked in place) data area and have
the ISR write its data to this area. However, one still
needs some kind of synchronization to know when the
data have been received and are complete.

The memory-map idea has security problems, though.
If the area ever gets unmapped (the user exits), a
fatal error could occur in kernel mode within the
ISR. In general, it's always best to allocate an
interrupt-safe buffer within the driver (module),
that is guaranteed to persist as long as the driver
is installed. This ultimately means that a copy
operation is necessary.

Memory-to-memory copy is real fast now days. The
copy_to_user() is just memcpy() with a trap mechanism
that can save the kernel from a user-induced seg-fault.
The actual trap is hardware-induced in ix86 machines
and therefore adds no overhead to the normal copy operation.

> Is there any other effective mechanism(s) to handle the interrupt. I mean
> we need to convey the event and or data to the user space(prefer -
> asynchronously).
>
> Please share your views.
>
> Sanil.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.22 on an i686 machine (797.90 BogoMips).
            Note 96.31% of all statistics are fiction.

Re: Interrupt handling

[Maciej Zenczykowski]

On Thu, 16 Oct 2003, Richard B. Johnson wrote:

> The memory-map idea has security problems, though.
> If the area ever gets unmapped (the user exits), a
> fatal error could occur in kernel mode within the
> ISR. In general, it's always best to allocate an
> interrupt-safe buffer within the driver (module),
> that is guaranteed to persist as long as the driver
> is installed. This ultimately means that a copy
> operation is necessary.
> 
> Memory-to-memory copy is real fast now days. The
> copy_to_user() is just memcpy() with a trap mechanism
> that can save the kernel from a user-induced seg-fault.
> The actual trap is hardware-induced in ix86 machines
> and therefore adds no overhead to the normal copy operation.

Is there any reason why we couldn't via kernel routine let user space 
access read-only certain pages of kernel memory?  I.e. having the 
userspace function call the driver to map into it's (user) address space a 
read-only mapping of the drivers (kernel) private r/w area?
If I'm not mistaken this is doable on x86 hardware isn't it?

Cheers,
MaZe.

Re: Interrupt handling

[Richard B. Johnson]

On Thu, 16 Oct 2003, Maciej Zenczykowski wrote:

> On Thu, 16 Oct 2003, Richard B. Johnson wrote:
>
> > The memory-map idea has security problems, though.
> > If the area ever gets unmapped (the user exits), a
> > fatal error could occur in kernel mode within the
> > ISR. In general, it's always best to allocate an
> > interrupt-safe buffer within the driver (module),
> > that is guaranteed to persist as long as the driver
> > is installed. This ultimately means that a copy
> > operation is necessary.
> >
> > Memory-to-memory copy is real fast now days. The
> > copy_to_user() is just memcpy() with a trap mechanism
> > that can save the kernel from a user-induced seg-fault.
> > The actual trap is hardware-induced in ix86 machines
> > and therefore adds no overhead to the normal copy operation.
>
> Is there any reason why we couldn't via kernel routine let user space
> access read-only certain pages of kernel memory?  I.e. having the
> userspace function call the driver to map into it's (user) address space a
> read-only mapping of the drivers (kernel) private r/w area?
> If I'm not mistaken this is doable on x86 hardware isn't it?
>
> Cheers,
> MaZe.
>
No reason. From user-space, using mmap, you can read the screen-memory
at 0xb8000, for instance, ........
-d b8000
000B8000  63 09 64 09 72 09 6F 09-6D 09 20 07 20 07 20 07   c.d.r.o.m. . . .
000B8010  20 07 20 07 20 07 20 07-20 07 20 07 20 07 20 07    . . . . . . . .
[SNIPPED]

You can look access many kernel areas that way. The probem is:

(1) When are new data available, and how much.
(2) How do you keep it from being overwritten by the next interrupt
    before it's been read.

These, and other, problems are why there are 'standard' ways of doing
things.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.22 on an i686 machine (797.90 BogoMips).
            Note 96.31% of all statistics are fiction.

Re: Interrupt handling

[George Anzinger]

Sanil K wrote:
> Hi all,
> 
> This may be a generic problem as far as a driver is concerned.
> 
> We need to handle an interrupt and inform the user space on the event and
> pass the data correspodning to the event.
> 
> The event can be informed through SIGNAL and the signal handler can be
> invoked in the user space. Then again for data, we need to have the
> "copy_to_user" mechanism .
> 
> Is there any other effective mechanism(s) to handle the interrupt. I mean
> we need to convey the event and or data to the user space(prefer -
> asynchronously).
> 
IF the amount of data is small, say a word or two or less, you can use the 
siginfo and a realtime signal.  This will get the data at the same time as the 
signal.  If you prefer to avoid the overhead of the signal, you can do 
sigwaitinfo() which avoids the floating point save/restore, but does require the 
task to wait (i.e. is not asynchronous).




-- 
George Anzinger   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml

Re: Interrupt handling

[Tom Zanussi]

[-- Attachment #1: Type: text/plain, Size: 2298 bytes --]

Sanil K wrote:
> Hi all,
> 
> This may be a generic problem as far as a driver is concerned.
> 
> We need to handle an interrupt and inform the user space on the event and
> pass the data correspodning to the event.
> 
> The event can be informed through SIGNAL and the signal handler can be
> invoked in the user space. Then again for data, we need to have the
> "copy_to_user" mechanism .
> 
> Is there any other effective mechanism(s) to handle the interrupt. I mean
> we need to convey the event and or data to the user space(prefer -
> asynchronously).
> 
> Please share your views.
> 

Hi.

You could use relayfs to do this; it was designed with this type of 
thing in mind - basically you use it to create a kernel buffer that you 
can write into from your module and then access the data using a file in 
the relayfs file system.  You can use read() or mmap() to access the 
data, depending on your needs.

If you just need to do this for debugging purposes, then the following 
patch to the relayfs version I posted on this list a couple of weeks ago 
might be of use, or you can use it as an example and do something 
similar in your own code.  Here's a link to the relayfs posting this 
patch needs to be applied to:

http://marc.theaimsgroup.com/?l=linux-kernel&m=106556134715271&w=2

Apply the attached patch on top of that, and then use klog() or 
klog_raw() to write to the buffer and from user space read() from 
/mnt/relay/klog, or similar depending on where you mounted relayfs.

If you expect to generate a lot of data, then it might be better to use 
mmap() to get at it.  For an example of this, you can look at the most 
recent version of the Linux Trace Toolkit I posted to the ltt and 
ltt-dev mailing lists around the same time.

Hope this helps,

Tom

Note:  this patch is based on a patch kindly contributed by Hubertus 
Franke, but I've added and changed things - in any case all 
responsibility for any problems with this code are mine alone.  Please 
send all comments/questions to me.  Thanks.


> Sanil.
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 



[-- Attachment #2: klog1.patch --]
[-- Type: text/plain, Size: 7993 bytes --]

diff -urpN -X dontdiff linux-2.6.0-test6.prev/fs/Kconfig linux-2.6.0-test6.cur/fs/Kconfig
--- linux-2.6.0-test6.prev/fs/Kconfig	Thu Oct 16 11:13:53 2003
+++ linux-2.6.0-test6.cur/fs/Kconfig	Thu Oct 16 11:17:20 2003
@@ -899,8 +899,8 @@ config RELAYFS_FS
 	  an efficient mechanism for tools and facilities to relay large
 	  amounts of data from kernel space to user space.  It's not useful
 	  on its own, and should only be enabled if other facilities that
-	  need it are enabled, such as for example dynamic printk or the
-	  Linux Trace Toolkit.
+	  need it are enabled, such as for example klog or the Linux Trace
+	  Toolkit.
 
 	  See <file:Documentation/filesystems/relayfs.txt> for further
 	  information.
@@ -911,6 +911,36 @@ config RELAYFS_FS
 	  module, say M here and read <file:Documentation/modules.txt>.
 
 	  If unsure, say N.
+
+config KLOG_CHANNEL
+	bool "Enable klog debugging support"
+	depends on RELAYFS_FS
+	help
+	  If you say Y to this, a relayfs channel named klog will be created
+	  in the root of the relayfs file system.  You can write to the klog
+	  channel using klog() or klog_raw() from within the kernel or
+	  kernel modules, and read from the klog channel by mounting relayfs
+	  and using read(2) to read from it (or using cat).  If you're not  
+	  sure, say N.
+
+config KLOG_CHANNEL_AUTOENABLE
+	bool "Enable klog logging on startup"
+	depends on KLOG_CHANNEL
+	default y
+	help
+	  If you say Y to this, the klog channel will be automatically enabled
+	  on startup.  Otherwise, to turn klog logging on, you need use
+	  sysctl (kernel.klog_enabled).  This option is used in cases where
+	  you don't actually want the channel to be written to until it's
+	  enabled.  If you're not sure, say Y.
+
+config KLOG_CHANNEL_SHIFT
+	depends on KLOG_CHANNEL
+	int "klog debugging channel size (16 => 64KB, 22 => 4MB)"
+	range 16 22
+	default 21
+	help
+	  Select klog debugging channel size as a power of 2.
 
 endmenu
 
diff -urpN -X dontdiff linux-2.6.0-test6.prev/fs/relayfs/Makefile linux-2.6.0-test6.cur/fs/relayfs/Makefile
--- linux-2.6.0-test6.prev/fs/relayfs/Makefile	Thu Oct 16 11:13:53 2003
+++ linux-2.6.0-test6.cur/fs/relayfs/Makefile	Thu Oct 16 11:17:20 2003
@@ -3,5 +3,6 @@
 #
 
 obj-$(CONFIG_RELAYFS_FS) += relayfs.o
+obj-$(CONFIG_KLOG_CHANNEL) += klog.o
 
 relayfs-objs := relay.o relay_lockless.o relay_locking.o inode.o
diff -urpN -X dontdiff linux-2.6.0-test6.prev/fs/relayfs/inode.c linux-2.6.0-test6.cur/fs/relayfs/inode.c
--- linux-2.6.0-test6.prev/fs/relayfs/inode.c	Thu Oct 16 11:13:53 2003
+++ linux-2.6.0-test6.cur/fs/relayfs/inode.c	Thu Oct 16 11:17:20 2003
@@ -551,10 +551,17 @@ static struct file_system_type relayfs_f
 	.kill_sb	= kill_litter_super,
 };
 
+extern int create_klog_channel(void);
+
 static int __init 
 init_relayfs_fs(void)
 {
-	return register_filesystem(&relayfs_fs_type);
+	int err = register_filesystem(&relayfs_fs_type);
+#ifdef CONFIG_KLOG_CHANNEL
+	if (!err)
+		create_klog_channel();
+#endif
+	return err;
 }
 
 static void __exit 
diff -urpN -X dontdiff linux-2.6.0-test6.prev/fs/relayfs/klog.c linux-2.6.0-test6.cur/fs/relayfs/klog.c
--- linux-2.6.0-test6.prev/fs/relayfs/klog.c	Wed Dec 31 18:00:00 1969
+++ linux-2.6.0-test6.cur/fs/relayfs/klog.c	Thu Oct 16 11:52:47 2003
@@ -0,0 +1,116 @@
+/*
+ * KLOG		Generic Logging facility built upon the relayfs infrastructure
+ *
+ * Authors:	Hubertus Franke  (frankeh@us.ibm.com)
+ *		Tom Zanussi  (zanussi@us.ibm.com)
+ *
+ *		Please direct all questions/comments to zanussi@us.ibm.com
+ *
+ *		Copyright (C) 2003, IBM Corp
+ *
+ *		This program is free software; you can redistribute it and/or
+ *		modify it under the terms of the GNU General Public License
+ *		as published by the Free Software Foundation; either version
+ *		2 of the License, or (at your option) any later version.
+ */
+
+#include <linux/kernel.h>
+#include <linux/smp_lock.h>
+#include <linux/console.h>
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/config.h>
+#include <linux/delay.h>
+#include <linux/smp.h>
+#include <linux/relayfs_fs.h>
+#include <linux/klog.h>
+
+#ifdef KLOG_CHANNEL_AUTOENABLE
+int klog_enabled = 1;
+#else
+int klog_enabled = 0;
+#endif
+EXPORT_SYMBOL(klog_enabled);
+
+int klog_channel = -1;
+
+static char buf[NR_CPUS][KLOG_BUF_SIZE];
+
+/**
+ *	klog - write a formatted string into the klog channel
+ *	@fmt: format string
+ *
+ *	Returns number of bytes written, negative number on failure.
+ */
+int klog(const char *fmt, ...)
+{
+	va_list args;
+	int len, err;
+	char *cbuf;
+	unsigned long flags;
+	
+	if (!klog_enabled || klog_channel < 0) 
+		return 0;
+
+	local_irq_save(flags);
+	cbuf = buf[smp_processor_id()];
+
+	va_start(args, fmt);
+	len = vsnprintf(cbuf, KLOG_BUF_SIZE, fmt, args);
+	va_end(args);
+	
+	err = relay_write(klog_channel, cbuf, len, -1);
+	local_irq_restore(flags);
+
+	return err;
+}
+
+/**
+ *	klog_raw - directly write into the klog channel
+ *	@buf: buffer containing data to write
+ *	@len: # bytes to write
+ *
+ *	Returns number of bytes written, negative number on failure.
+ */
+int klog_raw(const char *buf,int len)
+{
+	int err = 0;
+	
+	if (klog_enabled && klog_channel >= 0)
+		err = relay_write(klog_channel, buf, len, -1);
+
+	return err;
+}
+
+/* internal - creates channel file /mnt/relay/klog */
+int create_klog_channel(void)
+{
+	u32 bufsize, nbufs;
+
+	u32 channel_flags = RELAY_DELIVERY_PACKET | RELAY_USAGE_GLOBAL;
+	channel_flags |= RELAY_SCHEME_ANY | RELAY_TIMESTAMP_ANY;
+	
+	bufsize = 1 << (CONFIG_KLOG_CHANNEL_SHIFT - 2); /* size of sub-buffers */
+	nbufs = 4;
+
+	klog_channel = relay_open("klog",
+				  bufsize,
+				  nbufs,
+				  channel_flags,
+				  NULL,
+				  0,
+				  0,
+				  0,
+				  0,
+				  0);
+
+	if (klog_channel < 0)
+		printk("klog channel creation failed, errcode: %d\n", klog_channel);
+	else
+		printk("klog channel created (%u bytes)\n", 1 << CONFIG_KLOG_CHANNEL_SHIFT);
+
+	return klog_channel;
+}
+
+EXPORT_SYMBOL(klog);
+EXPORT_SYMBOL(klog_raw);
diff -urpN -X dontdiff linux-2.6.0-test6.prev/include/linux/klog.h linux-2.6.0-test6.cur/include/linux/klog.h
--- linux-2.6.0-test6.prev/include/linux/klog.h	Wed Dec 31 18:00:00 1969
+++ linux-2.6.0-test6.cur/include/linux/klog.h	Thu Oct 16 11:41:01 2003
@@ -0,0 +1,29 @@
+/*
+ * KLOG		Generic Logging facility built upon the relayfs infrastructure
+ *
+ * Authors:	Hubertus Frankeh  (frankeh@us.ibm.com)
+ *		Tom Zanussi  (zanussi@us.ibm.com)
+ *
+ *		Please direct all questions/comments to zanussi@us.ibm.com
+ *
+ *		Copyright (C) 2003, IBM Corp
+ *
+ *
+ *		This program is free software; you can redistribute it and/or
+ *		modify it under the terms of the GNU General Public License
+ *		as published by the Free Software Foundation; either version
+ *		2 of the License, or (at your option) any later version.
+ */
+
+#ifndef _LINUX_KLOG_H
+#define _LINUX_KLOG_H
+
+extern int klog_channel;
+
+#define KLOG_BUF_SIZE (512)     /* maximum size of formatting buffer for klog
+				 * beyond which truncation will take place */
+
+int klog(const char *fmt, ...);
+int klog_raw(const char *buf,int len); 
+
+#endif	/* _LINUX_KLOG_H */
diff -urpN -X dontdiff linux-2.6.0-test6.prev/kernel/sysctl.c linux-2.6.0-test6.cur/kernel/sysctl.c
--- linux-2.6.0-test6.prev/kernel/sysctl.c	Sat Sep 27 19:50:09 2003
+++ linux-2.6.0-test6.cur/kernel/sysctl.c	Thu Oct 16 11:17:20 2003
@@ -93,6 +93,7 @@ extern int pwrsw_enabled;
 extern int unaligned_enabled;
 #endif
 
+extern int klog_enabled;
 #ifdef CONFIG_ARCH_S390
 #ifdef CONFIG_MATHEMU
 extern int sysctl_ieee_emulation_warnings;
@@ -577,6 +578,14 @@ static ctl_table kern_table[] = {
 		.ctl_name	= KERN_PANIC_ON_OOPS,
 		.procname	= "panic_on_oops",
 		.data		= &panic_on_oops,
+		.maxlen		= sizeof(int),
+		.mode		= 0644,
+		.proc_handler	= &proc_dointvec,
+	},
+	{
+		.ctl_name	= 100, // just make up a number
+		.procname	= "klog_enabled",
+		.data		= &klog_enabled,
 		.maxlen		= sizeof(int),
 		.mode		= 0644,
 		.proc_handler	= &proc_dointvec,

Interrupt handling

[Mulyadi Santosa]

Hi... :)

On Tue, Feb 15, 2011 at 16:08, Darshan Ghumare
<darshan.ghumare@gmail.com> wrote:
> Sir,
> On x86 UP (Single CPU), Can lower priority (say) IRQ5 preempt higher one
> (say) IRQ4 (Currently, CPU is executing interrupt handler of IRQ4)?

In Linux kernel, I never heard such irq prioritizing. Linux kernel
does general preemption such that any code path could preempt other
code path as long as preemption is allowed at that point and/or
interrupt is enabled (which one affect the situation depends on type
of code path).

But, vaguely I read that Windows kernel does that.... that's why in
certain BSOD you read message prefixed with "IRQL xxx xxx xxxx". That
means lower interrupt handler somehow preempt higher one and that's
not allowed.

It comes from my raw observation so things might be wrong somewhere...

-- 
regards,

Mulyadi Santosa
Freelance Linux trainer and consultant

blog: the-hydra.blogspot.com
training: mulyaditraining.blogspot.com

Interrupt handling

[Darshan Ghumare]

Sir,

On Tue, Feb 15, 2011 at 4:16 PM, Mulyadi Santosa
<mulyadi.santosa@gmail.com>wrote:

> Hi... :)
>
> On Tue, Feb 15, 2011 at 16:08, Darshan Ghumare
> <darshan.ghumare@gmail.com> wrote:
> > Sir,
> > On x86 UP (Single CPU), Can lower priority (say) IRQ5 preempt higher one
> > (say) IRQ4 (Currently, CPU is executing interrupt handler of IRQ4)?
>
> In Linux kernel, I never heard such irq prioritizing. Linux kernel
> does general preemption such that any code path could preempt other
> code path as long as preemption is allowed at that point and/or
> interrupt is enabled (which one affect the situation depends on type
> of code path).
>

IMHO, When the Processor is executing interrupt handler of IRQ4 then
Processor is the one which pushes SS, SP, EFLAGS, CS  & EIP  on stack (in
this case this will all corresponds to interrupt handler of IRQ4) & loads CS
& EIP corresponding to IRQ5.
So, how come its depends on OS (kernel)? Please correct me if I am wrong.


> But, vaguely I read that Windows kernel does that.... that's why in
> certain BSOD you read message prefixed with "IRQL xxx xxx xxxx". That
> means lower interrupt handler somehow preempt higher one and that's
> not allowed.
>
> It comes from my raw observation so things might be wrong somewhere...
>
> --
> regards,
>
> Mulyadi Santosa
> Freelance Linux trainer and consultant
>
> blog: the-hydra.blogspot.com
> training: mulyaditraining.blogspot.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110215/bfab265f/attachment.html 

Interrupt handling

[Darshan Ghumare]

Sir,

On Tue, Feb 15, 2011 at 4:16 PM, Mulyadi Santosa
<mulyadi.santosa@gmail.com>wrote:

> Hi... :)
>
> On Tue, Feb 15, 2011 at 16:08, Darshan Ghumare
> <darshan.ghumare@gmail.com> wrote:
> > Sir,
> > On x86 UP (Single CPU), Can lower priority (say) IRQ5 preempt higher one
> > (say) IRQ4 (Currently, CPU is executing interrupt handler of IRQ4)?
>
> In Linux kernel, I never heard such irq prioritizing. Linux kernel
> does general preemption such that any code path could preempt other
> code path as long as preemption is allowed at that point and/or
> interrupt is enabled (which one affect the situation depends on type
> of code path).
>

IMHO, When the Processor is executing interrupt handler of IRQ4 then
Processor is the one which pushes SS, SP, EFLAGS, CS  & EIP  on stack (in
this case this will all corresponds to interrupt handler of IRQ4) & loads CS
& EIP corresponding to IRQ5.
So, how come its depends on OS (kernel)? Please correct me if I am wrong.


> But, vaguely I read that Windows kernel does that.... that's why in
> certain BSOD you read message prefixed with "IRQL xxx xxx xxxx". That
> means lower interrupt handler somehow preempt higher one and that's
> not allowed.
>
> It comes from my raw observation so things might be wrong somewhere...
>
> --
> regards,
>
> Mulyadi Santosa
> Freelance Linux trainer and consultant
>
> blog: the-hydra.blogspot.com
> training: mulyaditraining.blogspot.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110216/6028ce9d/attachment.html 

Interrupt handling

[Darshan Ghumare]

---------- Forwarded message ----------
From: Darshan Ghumare <darshan.ghumare@gmail.com>
Date: Wed, Feb 16, 2011 at 10:14 AM
Subject: Re: Interrupt handling
To: Mulyadi Santosa <mulyadi.santosa@gmail.com>



Sir,

>
> On Tue, Feb 15, 2011 at 4:16 PM, Mulyadi Santosa <
> mulyadi.santosa at gmail.com> wrote:
>
>> Hi... :)
>>
>> On Tue, Feb 15, 2011 at 16:08, Darshan Ghumare
>> <darshan.ghumare@gmail.com> wrote:
>> > Sir,
>> > On x86 UP (Single CPU), Can lower priority (say) IRQ5 preempt higher one
>> > (say) IRQ4 (Currently, CPU is executing interrupt handler of IRQ4)?
>>
>> In Linux kernel, I never heard such irq prioritizing. Linux kernel
>> does general preemption such that any code path could preempt other
>> code path as long as preemption is allowed at that point and/or
>> interrupt is enabled (which one affect the situation depends on type
>> of code path).
>>
>
> IMHO, When the Processor is executing interrupt handler of IRQ4 then
> Processor is the one which pushes SS, SP, EFLAGS, CS  & EIP  on stack (in
> this case this will all corresponds to interrupt handler of IRQ4) & loads CS
> & EIP corresponding to IRQ5.
> So, how come its depends on OS (kernel)? Please correct me if I am wrong.
>
>
>> But, vaguely I read that Windows kernel does that.... that's why in
>> certain BSOD you read message prefixed with "IRQL xxx xxx xxxx". That
>> means lower interrupt handler somehow preempt higher one and that's
>> not allowed.
>>
>> It comes from my raw observation so things might be wrong somewhere...
>>
>> --
>> regards,
>>
>> Mulyadi Santosa
>> Freelance Linux trainer and consultant
>>
>> blog: the-hydra.blogspot.com
>> training: mulyaditraining.blogspot.com
>>
>



-- 
Darshan?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110216/9e8390ca/attachment.html 

Interrupt handling

[Mulyadi Santosa]

Hi :)

On Tue, Feb 15, 2011 at 19:20, Darshan Ghumare
<darshan.ghumare@gmail.com> wrote:
> IMHO, When the Processor is executing interrupt handler of IRQ4 then
> Processor is the one which pushes SS, SP, EFLAGS, CS ?& EIP ?on stack (in
> this case this will all corresponds to interrupt handler of IRQ4) & loads CS
> & EIP corresponding to IRQ5.
> So, how come its depends on OS (kernel)? Please correct me if I am wrong.

OK, to make it clear, I was talking about bottom half prioritizing
.... the upper half is reacting whenever interrupt is coming (and it
is not currently masked/disabled) AFAIK. Bottom half is the part where
OS could do prioritizing if it indeed does so.

The only "prioritizing" (if you take it as prioritizing) in interrupt
is when it is fall into NMI (Non Maskable Interrupt). AFAIK, they
could just kick others in queue, just like real time task kick regular
process :) Uhm, maybe watchdog timer does same kind of interrupt
too...

Guys, CMIIW here...

-- 
regards,

Mulyadi Santosa
Freelance Linux trainer and consultant

blog: the-hydra.blogspot.com
training: mulyaditraining.blogspot.com

Interrupt handling

[Bruce Rowen]

When the interrupt line is asserted by the hardware device (could be  
a  peripheral, whatever) the interrupt controller decides how to pass  
this signal onto the processor. Some controllers will prioritize the  
interrupt based on the interrupt line number. For example, assume line  
#3 has interrupted. If line #4 then interrupts and #4 has higher  
priority, the service routine for interrupt line #3 will itself be  
interrupted. If a lower priority interrupt (say #2) occurs, then #3  
will continue until completion at which point #2 will be serviced.
Note that this hardware prioritization is highly dependent on hardware  
and hardware setup. It could be such that an incoming interrupt with a  
lower priority than a currently servicing interrupt is simply ignored.

Mulyadi is correct in that once this hardware interrupt has been  
acknowledged at the controller and the (usually very short) interrupt  
service routine has been run, the prioritization of the rest of the  
interrupt handler is left to the Kernel. Typically in most systems the  
NMI has the highest priority and of course given its name, can never  
be ignored (masked).

-Bruce

On Feb 16, 2011, at 1:54 AM, Mulyadi Santosa wrote:

> Hi :)
>
> On Tue, Feb 15, 2011 at 19:20, Darshan Ghumare
> <darshan.ghumare@gmail.com> wrote:
>> IMHO, When the Processor is executing interrupt handler of IRQ4 then
>> Processor is the one which pushes SS, SP, EFLAGS, CS  & EIP  on  
>> stack (in
>> this case this will all corresponds to interrupt handler of IRQ4) &  
>> loads CS
>> & EIP corresponding to IRQ5.
>> So, how come its depends on OS (kernel)? Please correct me if I am  
>> wrong.
>
> OK, to make it clear, I was talking about bottom half prioritizing
> .... the upper half is reacting whenever interrupt is coming (and it
> is not currently masked/disabled) AFAIK. Bottom half is the part where
> OS could do prioritizing if it indeed does so.
>
> The only "prioritizing" (if you take it as prioritizing) in interrupt
> is when it is fall into NMI (Non Maskable Interrupt). AFAIK, they
> could just kick others in queue, just like real time task kick regular
> process :) Uhm, maybe watchdog timer does same kind of interrupt
> too...
>
> Guys, CMIIW here...
>
> -- 
> regards,
>
> Mulyadi Santosa
> Freelance Linux trainer and consultant
>
> blog: the-hydra.blogspot.com
> training: mulyaditraining.blogspot.com
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Interrupt handling

[Darshan Ghumare]

Sir,

Thank you very much for the explanation.

On Wed, Feb 16, 2011 at 8:20 PM, Bruce Rowen <browen@aoc.nrao.edu> wrote:

> When the interrupt line is asserted by the hardware device (could be
> a  peripheral, whatever) the interrupt controller decides how to pass
> this signal onto the processor. Some controllers will prioritize the
> interrupt based on the interrupt line number. For example, assume line
> #3 has interrupted. If line #4 then interrupts and #4 has higher
> priority, the service routine for interrupt line #3 will itself be
> interrupted. If a lower priority interrupt (say #2) occurs, then #3
> will continue until completion at which point #2 will be serviced.
> Note that this hardware prioritization is highly dependent on hardware
> and hardware setup. It could be such that an incoming interrupt with a
> lower priority than a currently servicing interrupt is simply ignored.
>

If that is the case,
1) What happens in the case of x86?
2) Can we configure hardware (say, I/O APIC) so that alway higher priority
interrupt's handler runs first?


> Mulyadi is correct in that once this hardware interrupt has been
> acknowledged at the controller and the (usually very short) interrupt
> service routine has been run, the prioritization of the rest of the
> interrupt handler is left to the Kernel. Typically in most systems the
> NMI has the highest priority and of course given its name, can never
> be ignored (masked).
>
> -Bruce
>
> On Feb 16, 2011, at 1:54 AM, Mulyadi Santosa wrote:
>
> > Hi :)
> >
> > On Tue, Feb 15, 2011 at 19:20, Darshan Ghumare
> > <darshan.ghumare@gmail.com> wrote:
> >> IMHO, When the Processor is executing interrupt handler of IRQ4 then
> >> Processor is the one which pushes SS, SP, EFLAGS, CS  & EIP  on
> >> stack (in
> >> this case this will all corresponds to interrupt handler of IRQ4) &
> >> loads CS
> >> & EIP corresponding to IRQ5.
> >> So, how come its depends on OS (kernel)? Please correct me if I am
> >> wrong.
> >
> > OK, to make it clear, I was talking about bottom half prioritizing
> > .... the upper half is reacting whenever interrupt is coming (and it
> > is not currently masked/disabled) AFAIK. Bottom half is the part where
> > OS could do prioritizing if it indeed does so.
> >
> > The only "prioritizing" (if you take it as prioritizing) in interrupt
> > is when it is fall into NMI (Non Maskable Interrupt). AFAIK, they
> > could just kick others in queue, just like real time task kick regular
> > process :) Uhm, maybe watchdog timer does same kind of interrupt
> > too...
> >
> > Guys, CMIIW here...
> >
> > --
> > regards,
> >
> > Mulyadi Santosa
> > Freelance Linux trainer and consultant
> >
> > blog: the-hydra.blogspot.com
> > training: mulyaditraining.blogspot.com
> >
> > _______________________________________________
> > Kernelnewbies mailing list
> > Kernelnewbies at kernelnewbies.org
> > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110217/91f9fd24/attachment.html 

Interrupt handling

[Bruce Rowen]

On Feb 16, 2011, at 9:49 PM, Darshan Ghumare wrote:

> Sir,
>
> Thank you very much for the explanation.
>
> On Wed, Feb 16, 2011 at 8:20 PM, Bruce Rowen <browen@aoc.nrao.edu>  
> wrote:
> When the interrupt line is asserted by the hardware device (could be
> a  peripheral, whatever) the interrupt controller decides how to pass
> this signal onto the processor. Some controllers will prioritize the
> interrupt based on the interrupt line number. For example, assume line
> #3 has interrupted. If line #4 then interrupts and #4 has higher
> priority, the service routine for interrupt line #3 will itself be
> interrupted. If a lower priority interrupt (say #2) occurs, then #3
> will continue until completion at which point #2 will be serviced.
> Note that this hardware prioritization is highly dependent on hardware
> and hardware setup. It could be such that an incoming interrupt with a
> lower priority than a currently servicing interrupt is simply ignored.
>
> If that is the case,
> 1) What happens in the case of x86?

Depends on the interrupt controller. Common systems have interrupt  
controllers embedded into 'glue' chips such as a 'Southbridge' or  
'Northbridge'.
To find the exact device and functionality you will need to consult  
the hardware manuals for your system.

> 2) Can we configure hardware (say, I/O APIC) so that alway higher  
> priority interrupt's handler runs first?

My experience with small form-factor (pc104) X86 is that much of the  
setup/assignments of priority is done in the BIOS. I found it to be  
complex to change the assignments after the kernel is running so your  
best chance is to use the features of your BIOS.

Remember that the ISR typically exists as only a handful of lines of  
code. Its job is to determine that its hardware was the one  
interrupting (for when hardware shares interrupt lines), do whatever  
hardware changes are required (clear interrupt flags, acknowledge DMA,  
etc.), and then tell the kernel to schedule the rest of the handler  
(tasklet/bottom half, etc.).
A truly prioritized interrupt would allow the higher level interrupt  
to preempt the running of a lower levels ISR and tasklet. A lower  
level interrupt would be held off until the higher level interrupts  
ISR has completed, but it then could preempt the running of the higher  
level interrupts tasklet.
Once all interrupts are scheduled to run as tasklets, it is the order  
they are queued that determines their run order (last in, first run).

For example, scheduling the tasklet for a higher level interrupt with  
tasklet_hi_schedule() will allow it to run before those scheduled with  
tasklet_schedule().

Thus there are two places to control interrupt servicing priorities.  
The hardware level which allows preemption during the microseconds  
long hardware ISR code, and the software (tasklet) level that has  
priorities assigned by scheduling methods and scheduling order.

-Bruce





-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110217/39c6b579/attachment.html