gmane.comp.micro-kernel.l4.devel

Using pthread on L4/Fiasco

석현철 — 2012-05-23T09:13:00

Thank you.

 

I made a stupid mistake.

 

When I added “REQUIRES_LIBS = libpthread” into Makefile, I modified three
Makefiles.

There are hello/Makefile, hello/server/Makefile, and
hello/server/src/Makefile.

 

I tested one by one.

But I found I made a mistake.

At last try, I wrote REQUIRES = libpthread instead of REQUIRES_LIBS =
libpthread on hello/server/src/Makefile.

 

After correcting my mistake, I can test pthread application.

 

Thank you! Marcus

 

Hyunchul Seok.

 

_______________________________________________
l4-hackers mailing list
l4-hackers< at >os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: Using pthread on L4/Fiasco

Marcus Haehnel — 2012-05-23T08:08:29

Hi,

Am 2012-05-23 09:01, schrieb 석현철:

The error message has nothing to do with the header, as it is an error 
in the link phase, where the symbols of the libpthread can not be 
resolved.



Yes, you need to include this line in your Makefile and for me this 
leads to the program linking correctly.
Are you sure you included it in server/src/Makefile and not somewhere 
else? Can you show us your Makefile and the Output of

make V=1

to see the compiler and linker commands invoked?




Kind regards,

Marcus



_______________________________________________
l4-hackers mailing list
l4-hackers< at >os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Using pthread on L4/Fiasco

석현철 — 2012-05-23T07:01:41

Hi. Hackers

 

I’m trying to use pthread in an application which runs on L4.

I modified “main.c” in Hello application, including “#include
<pthread.h>”.

And when I compiled L4Re, I got error messages:

 

 

main.o: In function `main':

/root/l4re-core-2011081207/src/l4/pkg/hello/server/src/main.c:39: undefined
reference to `pthread_create'

/root/l4re-core-2011081207/src/l4/pkg/hello/server/src/main.c:44: undefined
reference to `pthread_join'

make[5]: *** [hello] Error 1

 

 

I think this is because it cannot fine pthread.h header file. But I don’t
know how to fix it.

 

When I looked up previous lists, I could find one thread related to pthread
in 2011 list.

(the thread title is “Silly Pthread Issues”)

I think that it is the same problem, but the reply is only one. Said “Add
REQUIRES_LIBS = libpthread to the Makefile.”

Actually, I tried it, but I couldn’t solve the problem.

 

How can I use the pthread? Please, Help me!!

 

Thank you!

Hyunchul Seok

 

 

 

The modified code is below:

#include <stdio.h>

#include <unistd.h>

 

//#include <pthread-l4.h>

#include <pthread.h>

 

void *process_test(void *arg)

{

    int i = (int)arg;

    int j;

 

    for (;;)

    {

        for (j = 0; j < i; j++) {

            printf("  ");

        }

        printf("%d thread\n", i);

        sleep(i);

    }

}

 

int main(void)

{

    pthread_t threads[10];

    int status[10];

    int i;

 

    for (i = 0; i < 3; i++) {

        pthread_create(&threads[i], NULL, process_test, (void *)i);

        puts("New thread creation!");

    }

 

for (i = 0; i < 3; i++) {

        pthread_join(threads[i], (void **)&status[i]);

    }

 

    return 0;

}

 

_______________________________________________
l4-hackers mailing list
l4-hackers< at >os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

[l4ankh] Problems with fixed l4ankh

Timur — 2012-05-22T17:16:39

Hi!
I had fixed the l4ankh driver and after that it started to work properly. Now 
only thread is used to receive packets. In lines 158-162 we clear the rcv 
buffer: that is necessary to be done as after opening a session we start to 
receive packets that should not be served; otherwise the response time will be 
quite slow. This is not the best solution, but I do not have time to make it 
better.
Now I face the following problem: the driver in ankh (I use 8139cp) stops 
receiving packets after some time (for me it is usually 3-4 minutes). This 
situation occurs when  the interrupt handler was called and the device 
register IntrStatus already equals "zero". An interrupt doesn't work after 
that.

Re: [Announcement] Karma VMM first public release

Norman Feske — 2012-05-18T07:00:41

Hi Steffen,

thank you for the elaborate reply! The text you have just written would
fit pretty well on karma-vmm.org, doesn't it?. .-)


I am far from being proficient when it comes to Afterburner but from
what I understand so far, there seem to be quite a few similarities
between this project and the approach you have taken with Karma.
Code-wise, the Afterburner VMM (called wedge) is cleanly separated from
the Linux kernel. The fact that its code is executed in the same address
space as the Linux kernel rather than a different address space (as in
Vancouver and Karma) is just a performance optimization.

The list of interface functions provided by the wedge is illustrative:


https://github.com/l4ka/afterburner/blob/master/afterburn-wedge/ia32/vmiCalls.h

Most of those functions are concerned with low-level CPU emulation. In
the original form of Afterburner, they are invoked by little code stubs
that replace their corresponding CPU instructions by upcalls to the
wedge. (the replacement of those the critical CPU instructions with stub
codes is done via a semi-automated procedure dubbed pre-virtualization)
However, support for H/W virtualization has been added at a later stage,
which alleviates the need for instrumenting the Linux kernel. So from a
large distance, Karma reminds me of the latter variant of Afterburner.
To see more clearly how your work integrates with the (quite diverse)
virtualization landscape of the L4 world, it would be just great if you
contrast both projects in a little more technical detail.


From the insights I got with porting Vancouver to Genode (on NOVA), I
got that Vancouver is in fact not inherently coupled to NOVA. It is a
largely freestanding code base with only little glue between the VMM and
the kernel. Technically, it should feasible to port Vancouver to other
kernels with virtualization support such as Fiasco.OC.


From this statement, I looks like Vancouver facilitates the same design
but provides a superset of Karma's functionality. What is the main
advantage of Karma compared to Vancouver (apart from running on a
different kernel)? Why have you opted to create a new VMM rather than
facilitate a port of Vancouver to Fiasco.OC?


That looks promising. I am confident that those puzzle pieces will do
well together. .-)


Please do not take my statements above as offense. I am just genuinely
interested.

Cheers
Norman

Re: [Announcement] Karma VMM first public release

Steffen Liebergeld — 2012-05-16T10:29:05

Hi Norman, L4 Hackers,

let me try to clarify what Karma is by giving an very short overview on
L4Linux, Afterburner and Vancouver.

L4Linux is a port of the Linux kernel to the microkernel API. In this
setup Linux runs in its own address space as an L4 task. Its
applications also reside in L4 tasks that reside beside L4Linux. This
setup requires in depth modification to the Linux kernel, and -due to
the increased number if context switches- has an inherent performance
penalty. L4Linux runs on platforms that are not virtualizable (e.g. ARM,
x86). It uses the L4Re infrastructure to implement peripheral devices,
such as framebuffer, shared memory network interface and device discovery.

As far as I know, Afterburner also runs OS kernels on top of a
microkernel on platforms that are not virtualizable. Hereby the guest
kernel binary is modified to replace virtualization sensitive
instructions with "hypercalls". The "hypervisor" resides in the same
address space as the guest kernel, and implements an emulation for
sensitive instructions, mostly using functionality of the underlying kernel.

Vancouver is a virtual machine monitor (VMM) that runs on top of the
NOVA microkernel. NOVA provides means to do page table management for
first and second stage page tables, as well as the means to do a world
switch (switch the CPU from host to guest). Vancouver uses hardware
virtualization through the microkernel interface to implement memory and
CPU virtualization. For everything else (platform devices, peripheral
devices, 16bit code), Vancouver does emulation. Each instance of
Vancouver runs exactly one virtual machine (VM). If the attacker is able
to escape the VM and compromise the VMM, it is up to the microkernel to
ensure that the attack remains contained.

In some sense, the Karma VMM is a mixture between Vancouver and L4Linux.
Let me explain this.

Karma does CPU and memory virtualization using the interfaces of
Fiasco.OC [0]. It runs as a task on top of the microkernel, and one
instance of Karma drives exactly one VM. In contrast to Vancouver, Karma
does no emulation at all. Instead, it implements its own custom device
models to provide platform devices such as interrupt controllers. For
peripheral devices, Karma relies on the L4Re infrastructure, which is
very similar to L4Linux. In contrast to L4Linux, Karma requires hardware
CPU virtualization (e.g. Intel VT or AMD SVM), and can make use of
nested paging for hardware accelerated memory virtualization. As you
said, the modifications to Linux are much simpler than those of L4Linux,
and basically implement the drivers for Karma's device models. The Karma
VMM is tiny (about 8500 lines of code), and the modifications to Linux
comprise about 3000 lines of code.

Actually we are working on reviving a technology called nested
virtualization [1], where we run KVM inside the VM established by Karma.
That allows us to run any OS that KVM can run (e.g. Windows).

For additional information about Karma, you can have a look into my
diploma thesis, where you will also find a number of benchmarks:
http://os.inf.tu-dresden.de/papers_ps/liebergeld-diplom.pdf

I would be happy if this spawns even more questions, and I am looking
forward to answering those.

Best regards,
Steffen Liebergeld

[0] Fiasco.OC has support for Intel VT, AMD SVM and Nested Paging. For
platforms without Nested Paging, Karma implements a shadow tlb.
[1] The term nested virtualization is also used for multi-stage
virtualization on Intel VT and AMD SVM, and is implemented in current
versions of KVM. You may read about it in the paper "The Turtles
Project: Design and Implementation of Nested Virtualization" by
Ben-Yehuda et al.

On 16.05.2012 11:15, Norman Feske wrote:

Re: [Announcement] Karma VMM first public release

Norman Feske — 2012-05-16T09:15:45

Hello,

congratulations for getting Karma out of the door finally. :-)

The project looks very interesting. However, I think it would be
sensible of you to contrast your approach with existing projects, in
particular L4Linux, Afterburner, and Vancouver. This way, potential
users would gain a better understanding of the incentive behind Karma.

From what I gathered from personal conversations with you:

 * Karma has a higher performance than L4Linux.
 * The VMM runs outside of the Linux kernel similar to Afterburner.
 * The patch against the vanilla Linux kernel is much simpler and
   trivial to maintain compared to the L4Linux kernel. (similar to
   Afterburner)
 * Karma has no ambition to become a VMM with support for faithful
   virtualization. Hence, running Windows on Karma won't be possible.
 * Because Karma depends on x86 H/W-virtualization support, the
   approch cannot be used on ARM for now.

Are these assumptions valid?

Again, thanks for sharing your work with the community. I'm looking
forward to look into it.

Cheers
Norman


On 05/14/2012 11:44 AM, Matthias Lange wrote:

Re: Booting L4/Fiasco + L4Re on PC

Matthias Lange — 2012-05-16T06:56:33

Just burn the image to a CD and boot your PC from CDROM.

Matthias.

Booting L4/Fiasco + L4Re on PC

석현철 — 2012-05-16T05:59:54

Hello.

 

I’ve tried to boot L4/Fiasco on PC.

 

I followed the directions for building from both “http://os.inf.tu-dresden.
de/fiasco/build.html” and “http://os.inf.tu-dresden.de/L4Re/build.html”

And I could run L4/Fiasco on QEMU.

 

Now I hope I want to boot L4 on PC environment.

As I searched, it can be done through GRUB. (But, I am not convinced that
it is right way.)

Anyway, I’ve tried to boot L4 by using GRUB.

 

I use Ubuntu Linux for compiling L4/Fiasco and L4Re. In this, there is
GRUBv2.

 

I made the bootable ISO image.

(It is done by “make grub2iso E=hello MODULE_SEARCH_PATH={mypath}”)

 

And then, what should I do in order to boot L4 on PC?

 

How should I configure the GRUB configuration?

 

I really want to know how to boot L4 on PC. Please, help me!

 

 

Kind Regards,

Hyunchul Seok.

 

 

_______________________________________________
l4-hackers mailing list
l4-hackers< at >os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: understanding l4re

Björn Döbel — 2012-05-14T22:02:08

Hi,

On 14.05.2012 18:13, Ryan Brown wrote:

No. These docs don't describe the Fiasco.OC API (although many of the 
concepts are shared). The relevant documentation for Fiasco and the L4 
Runtime Environment is at https://os.inf.tu-dresden.de/L4Re/doc/

(yes, that's all for now - if you have any questions, please ask and 
we're glad to help). There's also a Wiki: http://wiki.tudos.org/Main_Page


As in any other system, pthread_create() returns -EAGAIN if there are 
insufficient system resources to create another thread. This may happen, 
if the lib is not able to allocate a stack or TLS area for the thread or 
in the Fiasco.OC case if there are insufficient kernel resources.


Actually, scheduling is the only policy that is implemented in the 
kernel and as far as I know most L4 variants do this, although there 
have been experiments to do it in user space. [1]


Fiasco.OC schedules threads based on their priorities. (Same priority 
leads to round-robbin scheduling.) There are separate run queues for 
every physical CPU and you have to explicitly bind a thread to a 
physical core.


Yes. There is a port of ldso in l4/pkg, most libs are built as shared 
variants as well. There's even an example for starting a version of the 
hello example with shared libraries:

* First check out L4Re as documented on the web page.
* Then go to l4/pkg and do
   $> svn up examples/
* Then build examples/misc/shared-hello
* In l4/conf/modules.list there is an example entry "hello-shared" that
   should get you set up.


These may be stubs in the C library, but there are no implementations of 
fork/exec for L4Re. (Although, this would be possible.)


This is done by an ELF loader. The default loaders are moe (for the 
first binary) and ned (the Lua-based init program). You can also write 
your own and use the functionality provided by l4/pkg/libloader.

 > I suppose I should take more of a look at moe and ned to understand this.

Indeed. ;)


When being started, an L4Re application gets an initial set of 
capabilities (== communication channels). These are the initially 
available services and one of them is the Log channel which by default 
provides stdout and stderr for your application. The default log 
implementation is provided by the kernel who has a serial console driver 
built in (debugging...).


This is the first place where this happens. Bootstrap is a bit weirdly 
placed in l4/pkg. Actually, it is the "kernel" that is initially booted 
for every L4 setup. It sets up a multiboot environment and then hands 
over control to Fiasco, which then is the real kernel to run. As the 
Fiasco codebase is separate from the L4Re code base, you'll find another 
UART driver in Fiasco as well. Yep, that's redundant.


No worries. May I ask if you have any special project in mind?

Cheers,
Bjoern


[1] J. Stoess: Towards Effective User-Controlled Scheduling for 
Microkernel-Based Systems, SIGOPS OSR, July 2007

Re: [Announcement] Karma VMM first public release

Julian Stecklina — 2012-05-14T21:20:43

On Mon, 2012-05-14 at 17:59 -0300, John van V. wrote: 

Can you elaborate on that?

Julian

Re: [Announcement] Karma VMM first public release

John van V. — 2012-05-14T20:59:58

Why not just let go of the linux and run posix w/ gcc?  And make a
windows-friendly driver conversion kit?

On Mon, May 14, 2012 at 6:44 AM, Matthias Lange
<mlange< at >sec.t-labs.tu-berlin.de> wrote:

[Announcement] Karma VMM first public release

Matthias Lange — 2012-05-14T09:44:34

We are happy to announce the first public release of the Karma Virtual
Machine Monitor [0].

Karma is a virtual machine monitor (VMM) that runs Linux in a virtual
machine on top of the Fiasco.OC [1] microkernel. Its main design
directives are speed and simplicity. Unlike KVM, VirtualBox or VMWare,
Karma does no emulation, but resorts to aggressive paravirtualization
and therefore has low complexity and shows superior performance for a
number of benchmarks.

Karma requires hardware assisted CPU virtualization. A feature that is
available on all recent x86 CPUs (SVM or VT). Optionally, it can make
use of hardware assisted memory virtualization (Nested Paging or ePT),
if available.

The Karma VMM is currently being used as a research vehicle at
Technische Universität Berlin and Technische Universität Dresden.

It main features are:
- Trustworthy isolation of virtual machines by means of the microkernel.
  VMM compromise does no harm to other virtual machines as one instance
  of Karma runs exactly one virtual machine.
- Clean, tiny code base, less than 9000 source lines of code.
- Near native (guest)-Linux performance.
- Supports:
  * SMP
  * Networking
  * Direct harddisk access via AHCI
  * RTC and Hpet support


Karma is released under the terms of the Gnu General Public License
Version 2.

[0] http://karma-vmm.org
[1] http://os.int.tu-dresden.de/fiasco
[2] http://www.isti.tu-berlin.de/security_in_telecommunications
[3] http://os.inf.tu-dresden.de

Re: IGB driver not getting Rx interrupt

Julian Stecklina — 2012-05-13T22:08:02

On Sun, 2012-05-13 at 23:53 +0200, Adam Lackorzynski wrote: 

For IGB that register would be called ICR or EICR (interrupt cause
register). Hope that helps finding it in the source.

Julian

Re: IGB driver not getting Rx interrupt

Adam Lackorzynski — 2012-05-13T21:53:21

Hi,

On Thu May 10, 2012 at 15:14:47 -0700, Shashi Sharma wrote:

Ok.


Usually a device has a device register that indicates whether an
interrupt has been asserted. So in JDB you could look up the this
register, or add some printf in the driver or so to see if its contents
change after some packet transfer should have happened.



Adam

Re: Fiasco.OC on Cortex-A9

Johan Dams — 2012-05-12T19:12:12

Hi.

Ok, got it to work in Qemu with the realview-pbx-a9 target. Still
working on the problem on i.MX6. 


Best regards,
Johan

On Fri, 2012-05-11 at 20:13 +0300, Johan Dams wrote:

Re: Fiasco.OC on Cortex-A9

Johan Dams — 2012-05-11T17:13:29

Hi.

As a follow up to my email below, I compiled Fiasco for the Realview
system and ran under QEmu. This is my output:

L4 Bootstrapper
  Build: #5 Fri May 11 19:55:05 EEST 2012, 4.5.3
  Scanning up to 256 MB RAM
  Memory size is 256MB (00000000 - 10000000)
  RAM: 0000000000000000 - 000000000fffffff: 262144kB
  Total RAM: 256MB
  mod08: 011ec000-01205544: hello
  mod07: 01198000-011eb22c: ned
  mod06: 010bd000-01197b8c: io
  mod05: 010bc000-010bc016: arm-imx6.devs
  mod04: 010bb000-010bb079: startup.conf
  mod03: 010a1000-010ba45c: l4re
  mod02: 01067000-010a062c: moe
  mod01: 0105d000-01066340: sigma0
  mod00: 01014000-0105c7b0: fiasco
  Moving 9 modules to 1100000 with offset ec000
  moving module 09 { 11ec000-1205544 } -> { 12d8000-12f1544 }
  moving module 08 { 1198000-11eb22c } -> { 1284000-12d722c }
  moving module 07 { 10bd000-1197b8c } -> { 11a9000-1283b8c }
  moving module 06 { 10bc000-10bc016 } -> { 11a8000-11a8016 }
  moving module 05 { 10bb000-10bb079 } -> { 11a7000-11a7079 }
  moving module 04 { 10a1000-10ba45c } -> { 118d000-11a645c }
  moving module 03 { 1067000-10a062c } -> { 1153000-118c62c }
  moving module 02 { 105d000-1066340 } -> { 1149000-1152340 }
  moving module 01 { 1014000-105c7b0 } -> { 1100000-11487b0 }
  Scanning fiasco
  Scanning sigma0
  Scanning moe rom/startup.conf 
  Relocated mbi to [0x100e000-0x100e139]
  Loading fiasco
  Loading sigma0
  Loading moe
  find kernel info page...
  found kernel info page at 0x2000
Regions of list regions
    [     1000,      19bf] {      9c0} Kern   fiasco
    [     2000,     58fff] {    57000} Kern   fiasco
    [    90000,     96ccb] {     6ccc} Sigma0 sigma0
    [    98000,     9e17b] {     617c} Sigma0 sigma0
    [   140000,    170aeb] {    30aec} Root   moe
    [   178000,    18eee7] {    16ee8} Root   moe
    [  1000000,   10133eb] {    133ec} Boot   bootstrap
    [  100e000,   100e236] {      237} Root   Multiboot info
    [  118d000,   12f1543] {   164544} Root   Modules Memory
  API Version: (87) experimental
  Sigma0 config    ip:000900e0 sp:01012044
  Roottask config  ip:001401c0 sp:00000000
  Starting kernel fiasco at 00001000

--> and here it stops, which appears to be the same issue I as I have on
the i.mx6.



Best regards,
Johan

On Fri, 2012-05-11 at 17:01 +0300, Johan Dams wrote:

Fiasco.OC on Cortex-A9

Johan Dams — 2012-05-11T14:01:29

Hi all,

I'm wondering if anyone has come across an issue with Fiasco.OC on
Cortex-A9 based systems. The problem is that I do not get past this
instruction (and with that I mean that the system just locks up): 

"mcr p15, 0, %[control], c1, c0 \n" // control

in src/kern/arm/bootstrap.cpp. The exact same code works fine on a
Cortex-A8 based processor. Changing cache on or off (in the control
variable) does not change anything. Also, just reading the current
content of the register and writing it back locks the system.

I have been going over compiler flags, tried different compilers
altogether (using 4.5.3-r1 right now), and looked if something odd was
going on with the generated assembly code, etc. with no results.

This code is a standard ARM instruction, and comes well before any
paging or even the actual kernel starts.

The SOC in question is a Freescale i.MX6 Quad core Cortex A9, which I
realize not many have actually used yet. However, if similar issues
presented itself on other platforms, these might give some clues. 
 

Any ideas?


Best regards,
Johan

Re: understanding l4re

Björn Döbel — 2012-05-11T14:06:57

Hi Ryan,

On 11.05.2012 03:15, Ryan Brown wrote:

Note, that not all files in uClibC are built. Instead, we only compile
a subset that is semi-magically determined by the list in
l4/pkg/uclibc/lib/uclibc/contrib_files.mk. Basically, you can
distinguish two classes of files:

a) files that don't have dependencies on the underlying system or
platform -- those are taken from the original uClibC sources in
l4/pkg/uclibc/lib/contrib

b) files that depend on system calls and other infrastructure (e.g.,
file systems) -- those either come from our own implementation
(l4/pkg/uclibc/lib/uclibc/*) or from the libc_backends package.

Anything related to making system calls falls under category b) and of
course uses Fiasco system calls.


There are a couple of backends in l4/pkg/libc_backends. For instance
l4/pkg/libc_backends/lib/sig implements POSIX signals on top of L4. You
will notice that it uses Fiasco system calls (look for functions
starting with l4_*()).

The backend idea is: every backend implements a part of POSIX
functionality that depends on the system, such as signals, virtual file
systems etc. You then link your application against those backends you
need. For instance, if you don't need POSIX signals in your app, there's
no need to link against libc_be_signal.


That's a feature! We reuse pthread's original functionality instead of
building everything from scratch.


Not exactly. pthread's mutex implementation tries spinning first and
once it finds out that the lock cannot be grabbed immediately, it goes
to sleep (see calls to suspend()). That's a pretty reasonable thing to
do, because it speeds up the non-contention case by not requiring any
system call.


suspend() is implemented using an L4-specific system call (see
l4/pkg/uclibc/lib/libpthread/src/restart.h

Cheers,
Bjoern

understanding l4re

Ryan Brown — 2012-05-11T01:15:01

Hi. I'm exploring developing software that runs on Fiasco.OC/L4re, so I'm
trying to understand how the various pieces fit together.  If I'm following
the makefiles correctly it looks like some uclibc files (like libc/inet)
are getting compiled, but they seem to be making linux system calls. I also
see the libc_backends code, and I'm not sure how this fits in. It looks
like these are mostly stubs, is it expected that you'll link the final
binary with the real implementation you want?

I also took a look at libpthreads, and I don't see much l4 specific code.
It looks like mutexes are implemented as spinlocks? Isn't there a better
way to do synchronization in fiasco?
_______________________________________________
l4-hackers mailing list
l4-hackers< at >os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

Re: IGB driver not getting Rx interrupt

Shashi Sharma — 2012-05-10T22:14:47

Hi Adam,

I am pretty sure now that Fiasco's ISR is not getting invoked. I put a
printf in the following interrupt handler in fiasco's
src/kern/ia32/dirq-ia32-ux.cpp.

----
extern "C" FIASCO_FASTCALL
void
irq_interrupt(Mword _irqobj, Mword ip)
----------

And it never gets invoked.

You suggested in your last e-mail to "check whether the card is
reporting a pending interrupt". But I dont really know how to do that.
Is there some way in JDB to do that?

Regards,
Shashi Sharma

On Mon, 2012-05-07 at 00:09 +0200, Adam Lackorzynski wrote: