Interrupts

Interrupts

[Nishant Nagalia]

Hello,

I am trying to modify linux scheduler for my project.

I want to schedule interrupts whenever I want,means I want to queue
an interrupt when it comes and execute it when my scheduler will want it
to. I should be able to queue it before it executes any function/ISR
inside kernel and then schedule it when required.

I am not able to find proper documentation of how exactly I can do this. I
would really appreciate if anyone can help me in this regards.

Nishant.

Re: Interrupts

[Zwane Mwaikambo]

On Sun, 14 Mar 2004, Nishant Nagalia wrote:

> Hello,
>
> I am trying to modify linux scheduler for my project.
>
> I want to schedule interrupts whenever I want,means I want to queue
> an interrupt when it comes and execute it when my scheduler will want it
> to. I should be able to queue it before it executes any function/ISR
> inside kernel and then schedule it when required.
>
> I am not able to find proper documentation of how exactly I can do this. I
> would really appreciate if anyone can help me in this regards.

There isn't any documentation stating how to do that because Linux doesn't
use that interrupt handling model. Perhaps you should be looking at the
FreeBSD 5 interrupt thread code instead.

Interrupts

[Guy Zana]

[-- Attachment #1.1: Type: text/plain, Size: 124 bytes --]

IO-APICs -> Any ideas of how can I check whether a signal is asserted
(level) for a real PCI device?
 
Thanks,
Guy.
 

[-- Attachment #1.2: Type: text/html, Size: 629 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: interrupts

[Luis R. Rodriguez]

On Fri, Sep 17, 2010 at 07:10:42AM -0700, Chuck Crisler wrote:
> Luis, our gizmo uses an IR interface that is poorly implemented but needs timely interrupts. It works well unless an AR9170 is plugged in. The hardware guy has put a scope on the board and claims that the interrupts are not being passed to the device. Where in the kernel or AR driver would I start looking for this problem?
> 
> I got my problems with the 9170 fixed. Now roaming looks rock solid, though it is slow (~6 seconds, mainly for the scan). The problem was in the wpa_supplicant.
> 
> Thank you,
> Chuck Crisler
> VGo Communications

Chuck, you're better off using the mailign lists, I don't work on ar9170,
Christian does though.

  Luis

Re: interrupts

[Christian Lamparter]

On Friday 17 September 2010 18:42:23 Luis R. Rodriguez wrote:
> On Fri, Sep 17, 2010 at 07:10:42AM -0700, Chuck Crisler wrote:
> > Luis, our gizmo uses an IR interface that is poorly implemented but needs
> > timely interrupts. It works well unless an AR9170 is plugged in. The
> > hardware guy has put a scope on the board and claims that the interrupts
> > are not being passed to the device. Where in the kernel or AR driver would
> > I start looking for this problem?
> > 
ar9170usb (and otus) are processing (unaggregate rx-stream, alloc an skb for
each mpdu/frame in the stream, memcpy the data into each skb, push the finished
skb to the network stack) all incoming frames in the urb callback routine,
which has to run with IRQs disabled.

This "could" explain why you are getting such a bad irq-latency.

ath9k_htc and carl9170 do things differently. Both have
tasklets(related to bottom-halves if you aren't familiar
with the term) which take care of the rx stream processing
and the latency should be better. (don't have a scope
to test that claim but I can't see why it should be worse)

> > I got my problems with the 9170 fixed. Now roaming looks
> > rock solid, though it is slow (~6 seconds, mainly for the scan).
> >
> > The problem was in the wpa_supplicant.
Hmm, I'm curious: what was the problem in wpa_supplicant?

Best regards,
	Chr

Interrupts

[Russell Johnson]

The app that I am currently working with has an interrupt scheme as follows:
device on the PCIe bus sends an interrupt to the CPU, our linux driver then
has an MSI interrupt handler (will be replaced by the EVL oob interrupt
handler), the handler then calls eventfd_signal() to alert the userspace app
that an interrupt happened. On the userspace side, there is a thread that
implements an epoll that is monitoring the eventfd for an event. The issue
is that eventfd and epoll are both Linux OS items, so I am not sure if
sticking with this kind of method is the best option. Is there a more
generally excepted method when developing with EVL to have an EVL kernel
driver notify a userspace EVL thread that there was an interrupt?

 

Thanks,

 

Russell

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6759 bytes
Desc: not available
URL: <http://xenomai.org/pipermail/xenomai/attachments/20220617/2dbd8004/attachment.bin>

Re: Interrupts

[Philippe Gerum]

Russell Johnson via Xenomai <xenomai@xenomai.org> writes:

> The app that I am currently working with has an interrupt scheme as follows:
> device on the PCIe bus sends an interrupt to the CPU, our linux driver then
> has an MSI interrupt handler (will be replaced by the EVL oob interrupt
> handler), the handler then calls eventfd_signal() to alert the userspace app
> that an interrupt happened. On the userspace side, there is a thread that
> implements an epoll that is monitoring the eventfd for an event. The issue
> is that eventfd and epoll are both Linux OS items, so I am not sure if
> sticking with this kind of method is the best option. Is there a more
> generally excepted method when developing with EVL to have an EVL kernel
> driver notify a userspace EVL thread that there was an interrupt?
>

The recommended way with EVL is to follow the common patterns used for
developing regular linux drivers, except that the EVL kernel API must be
used instead of the regular/in-band kernel API for anything which wants
to synchronize threads over the oob stage.

Typically, you could share an EVL semaphore [1] or an event flag group
[2] between the interrupt handler and the oob_ioctl() or oob_read()
call, which would block the user-space task until the matching event
happens. To monitor complex events, you could use an EVL wait queue
instead of a semaphore or a flag.

If you need to monitor multiple event sources in userland, you can use
the EVL poll API [4] with the file descriptors you would otherwise pass
to the oob_{ioctl, read, write}() calls.

[1] https://evlproject.org/core/user-api/semaphore/
[2] https://evlproject.org/core/user-api/flags/
[3] https://evlproject.org/core/kernel-api/wait/
[4] https://evlproject.org/core/user-api/poll/

-- 
Philippe.

RE: Interrupts

[Russell Johnson]

[-- Attachment #1.1: Type: text/plain, Size: 1440 bytes --]

> The recommended way with EVL is to follow the common patterns used for
> developing regular linux drivers, except that the EVL kernel API must be
> used instead of the regular/in-band kernel API for anything which wants
> to synchronize threads over the oob stage.
> 
> Typically, you could share an EVL semaphore [1] or an event flag group
> [2] between the interrupt handler and the oob_ioctl() or oob_read()
> call, which would block the user-space task until the matching event
> happens. To monitor complex events, you could use an EVL wait queue
> instead of a semaphore or a flag.
> 
> If you need to monitor multiple event sources in userland, you can use
> the EVL poll API [4] with the file descriptors you would otherwise pass
> to the oob_{ioctl, read, write}() calls.
> 
> [1] https://evlproject.org/core/user-api/semaphore/
> [2] https://evlproject.org/core/user-api/flags/
> [3] https://evlproject.org/core/kernel-api/wait/
> [4] https://evlproject.org/core/user-api/poll/
> 
> -- 
> Philippe.
 
If I create an EVL semaphore or event flag group on the userspace side
(using the libevl API), how would I go about passing a reference to that
down to the kernel driver (through ioctl)? Wouldn't the kernel driver need
to know what a "struct evl_sem" or a "struct evl_flags" is? But those are
defined in the libevl usersapce API and the kernel does not have access to
those headers from what I can see.
 
Thanks,
 
Russell

 


[-- Attachment #1.2: Type: text/html, Size: 5161 bytes --]

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 6759 bytes --]

Re: Interrupts

[Philippe Gerum]

Russell Johnson <russell.johnson@kratosdefense.com> writes:

> [[S/MIME Signed Part:Undecided]]
>> The recommended way with EVL is to follow the common patterns used for
>
>> developing regular linux drivers, except that the EVL kernel API must be
>
>> used instead of the regular/in-band kernel API for anything which wants
>
>> to synchronize threads over the oob stage.
>
>>
>
>  
>
>> Typically, you could share an EVL semaphore [1] or an event flag group
>
>> [2] between the interrupt handler and the oob_ioctl() or oob_read()
>
>> call, which would block the user-space task until the matching event
>
>> happens. To monitor complex events, you could use an EVL wait queue
>
>> instead of a semaphore or a flag.
>
>>
>
>  
>
>> If you need to monitor multiple event sources in userland, you can use
>
>> the EVL poll API [4] with the file descriptors you would otherwise pass
>
>> to the oob_{ioctl, read, write}() calls.
>
>>
>
>  
>
>> [1] https://evlproject.org/core/user-api/semaphore/
>
>> [2] https://evlproject.org/core/user-api/flags/
>
>> [3] https://evlproject.org/core/kernel-api/wait/
>
>> [4] https://evlproject.org/core/user-api/poll/
>
>>
>
>  
>
>> -- 
>
>> Philippe.
>
>  
>
> If I create an EVL semaphore or event flag group on the userspace side (using the libevl API), how would I go about passing a reference to that down to the kernel driver (through ioctl)? Wouldn’t the kernel driver need to know what a “struct evl_sem” or a “struct evl_flags” is? But those are defined in the libevl usersapce API and the kernel does not have access to those headers from what I can see.
>
>  
>

You could export the file structure of a userland object to a kernel
driver, but this is not the recommended way, especially since this would
require to deal with the lifetime of those objects using the internal
EVL API in kernel space.

The proper way for an application is to create a kernel semaphore/flag,
post it from kernel space (e.g. from an interrupt handler), pend on it
from an oob_ioctl/oob_read handler typically.

The sequence would be as follows:

1. the user task issues oob_ioctl(fd, IOC_WAIT_FOO) or oob_read(fd),
which invokes the corresponding oob_ioctl and/or oob_read handlers in
the kernel driver.

2. Those handlers call e.g. evl_down() on the kernel sem, which the
interrupt handler can post using evl_up() at some point in order to
signal the event. Conversely, the user task would wait for such event,
sleeping in kernel context until it occurs.

-- 
Philippe.