Re: [Xenomai-core] Scheduling while atomic

2006-01-18 Thread Jeroen Van den Keybus
When testing, also check the dmesg logs please. When nucleus debugging is off, you get only a kernel warning 'scheduling while atomic'. - Could you replace MAXLONG on line 119 with TM_INFINITE and rerun the sem test (to avoid printf'ing) You can terminate with Ctrl+C. - Could you try to run with

Re: [Xenomai-core] Scheduling while atomic

2006-01-18 Thread Jeroen Van den Keybus
# ./sem 1.0e5Running for 2.15 seconds.L119: Operation not permitted. Could be a dirty cleanup. Sorry for that. ...ipipe_supend_domain...default_idle...cpu_idle...start_kernel...unknown_bootoptionKernel panic start_kernel ? Unknown_bootoption ? The plot is thickening. # ./mutex 1.0e5ALERT: No

[Xenomai-core] Scheduling while atomic

2006-01-18 Thread Jeroen Van den Keybus
Hm. When I remove the output() from both tasks, all seems fine. Jeroen. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core

Re: [Xenomai-core] Scheduling while atomic

2006-01-18 Thread Jeroen Van den Keybus
Hold on. Just crashed without the file access: please disregard last post. Jeroen. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core

Re: [Xenomai-core] Scheduling while atomic

2006-01-19 Thread Jeroen Van den Keybus
Turned off: o nucleus debugging o ipipe stats o ipipe tracing o ishield The problem persists. Also tried three tasks, with same result. With one task, there is no problem. Jeroen. ___ Xenomai-core mailing list Xenomai-core@gna.org

Re: [Xenomai-core] [BUG] racy xnshadow_harden under CONFIG_PREEMPT

2006-01-23 Thread Jeroen Van den Keybus
Hello, I'm currently not at a level to participate in your discussion. Although I'm willing to supply you with stresstests, I would nevertheless like to learn more from task migrationas this debugging session proceeds. In order to do so, please confirm the following statements or indicate where

Re: [Xenomai-core] [BUG] racy xnshadow_harden under CONFIG_PREEMPT

2006-01-31 Thread Jeroen Van den Keybus
And now, Ladies and Gentlemen, with the patches attached. I've installed both patches and the problem seems to have disappeared. I'll try it on another machine tomorrow, too. Meanwhile: thanks very much forthe assistance ! Jeroen. ___ Xenomai-core

Re: [Xenomai-core] [PATCH] Shared irqs v.6

2006-02-01 Thread Jeroen Van den Keybus
I mean that the support of shared interrupts for ISA boards (edge-triggered stuff) is a kind of emulation to overcome the shortcommings of the initial design on the hardware level. The hardware was just not supposed to support shared interrupt channels. So, let's keep it a bit aside from

Re: [Xenomai-core] [BUG] racy xnshadow_harden under CONFIG_PREEMPT

2006-02-01 Thread Jeroen Van den Keybus
I've installed both patches and the problem seems to have disappeared. I'll try it on another machine tomorrow, too. Meanwhile: thanks very much for the assistance ! While testing more thoroughly, my triggers for zero mutex values after acquiring the lock are going off again.I wasusing the SVN

Re: [Xenomai-core] [BUG] racy xnshadow_harden under CONFIG_PREEMPT

2006-02-01 Thread Jeroen Van den Keybus
Revision 466 contains the mutex-info fix, but that is post -rc2. Why notswitching to SVN head? Philippe asked to applythe patch against Xenomai 2.1-rc2. Can I safely patch it against the SVN tree ? After that,what will 'svn up' do to the patched tree ? Remember I'm quite new to Linux. Actually,

[Xenomai-core] Handling PCI MSI interrupts

2006-02-14 Thread Jeroen Van den Keybus
I'm having problems using MSI interrupts in Xenomai. When using normal PCI interrupts, my PCI card + RTDM driver work flawlessly. However, I noticed the following while trying to enable MSI (by having Linux do all the administrative register-fill-ins using pci_enable_msi()): 1. The kernel is

Re: [Xenomai-core] Handling PCI MSI interrupts

2006-02-14 Thread Jeroen Van den Keybus
One moment. I'm trying to locate rthal_disable_irq()... Does calling rthal_disable_irq() instead of returning RTDM_IRQ_ENABLE, but rather 0, prevents the freeze? ___ Xenomai-core mailing list Xenomai-core@gna.org

Re: [Xenomai-core] Handling PCI MSI interrupts

2006-02-14 Thread Jeroen Van den Keybus
In the meantime, I've located the rthal_irq_disable() and used it instead of the RTDM return value (which is now 0). The machine still hangs. More importantly, I noticed that the second (after the first) interrupt gets lost (as is to be expected when the interrupt remains disabled). This causes

Re: [Xenomai-core] Handling PCI MSI interrupts

2006-02-14 Thread Jeroen Van den Keybus
1. Turn off the card's interrupts after the first IRQ has arrived. Result: still hangs. Jeroen. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core

Re: [Xenomai-core] Handling PCI MSI interrupts

2006-02-14 Thread Jeroen Van den Keybus
2. Keep my program alive for a few secs using task_sleep() or so to see if cleanup code is going awry. Alas, hangs directly after going to sleep(). Strangely, console output always arrives to the screen unhurt... Jeroen. ___ Xenomai-core mailing list

Re: [Xenomai-core] Handling PCI MSI interrupts

2006-02-14 Thread Jeroen Van den Keybus
I've got some bad news. I've rewritten (parts of) my driver to operate in native Linux (i.e. no RTDM, no Xenomai). When I run this in a Xenomai-augmented kernel (with Adeos, evidently), the machine hangs. However, when the same code is run in the same but unmodified kernel, the code works as

Re: [Xenomai-core] Handling PCI MSI interrupts

2006-02-15 Thread Jeroen Van den Keybus
In a search for the problem, I encountered some code which may be at the root of the problem. In file arch/i386/kernel/io_apic.cI see that a function mask_and_ack_level_ioapic_vector() is being defined, whereas the original 2.6.15 code did not ever issue any IO_APIC calls (both

Re: [Xenomai-core] Handling PCI MSI interrupts

2006-02-15 Thread Jeroen Van den Keybus
It's definitely an Adeos issue and msi.c needs fixing. What about this patch, dothings improve with it (against 2.6.15-ipipe-1.2-00)? I going to try the patch later on. I have currently a ´fully instrumented´ kernel against which this patch would not ever work... I´m keeping that kernel for now,

[Xenomai-core] PRNG not seeded on AMD K7

2006-03-12 Thread Jeroen Van den Keybus
When I try to open an ssh connection to or from a PC running Xenomai, I get a'PRNG not seeded' error. However, it only occurs when an RT application is running (such as 'latency'). The computer on which this occurs is an AMD K7-650. I've tested on a Pentium III 500 as well (nearly same .config)

Re: [Xenomai-core] [BUG] racy xnshadow_harden under CONFIG_PREEMPT

2006-02-01 Thread Jeroen Van den Keybus
I've installed both patches and the problem seems to have disappeared. I'll try it on another machine tomorrow, too. Meanwhile: thanks very much for the assistance ! While testing more thoroughly, my triggers for zero mutex values after acquiring the lock are going off again.I wasusing the SVN

Re: [Xenomai-core] [BUG] racy xnshadow_harden under CONFIG_PREEMPT

2006-02-01 Thread Jeroen Van den Keybus
Revision 466 contains the mutex-info fix, but that is post -rc2. Why notswitching to SVN head? Philippe asked to applythe patch against Xenomai 2.1-rc2. Can I safely patch it against the SVN tree ? After that,what will 'svn up' do to the patched tree ? Remember I'm quite new to Linux. Actually,

[Xenomai-core] Handling PCI MSI interrupts

2006-02-14 Thread Jeroen Van den Keybus
I'm having problems using MSI interrupts in Xenomai. When using normal PCI interrupts, my PCI card + RTDM driver work flawlessly. However, I noticed the following while trying to enable MSI (by having Linux do all the administrative register-fill-ins using pci_enable_msi()): 1. The kernel is

Re: [Xenomai-core] Handling PCI MSI interrupts

2006-02-14 Thread Jeroen Van den Keybus
One moment. I'm trying to locate rthal_disable_irq()... Does calling rthal_disable_irq() instead of returning RTDM_IRQ_ENABLE, but rather 0, prevents the freeze?

Re: [Xenomai-core] Handling PCI MSI interrupts

2006-02-14 Thread Jeroen Van den Keybus
In the meantime, I've located the rthal_irq_disable() and used it instead of the RTDM return value (which is now 0). The machine still hangs. More importantly, I noticed that the second (after the first) interrupt gets lost (as is to be expected when the interrupt remains disabled). This causes

Re: [Xenomai-core] Handling PCI MSI interrupts

2006-02-14 Thread Jeroen Van den Keybus
2. Keep my program alive for a few secs using task_sleep() or so to see if cleanup code is going awry. Alas, hangs directly after going to sleep(). Strangely, console output always arrives to the screen unhurt... Jeroen.

Re: [Xenomai-core] Handling PCI MSI interrupts

2006-02-14 Thread Jeroen Van den Keybus
I've got some bad news. I've rewritten (parts of) my driver to operate in native Linux (i.e. no RTDM, no Xenomai). When I run this in a Xenomai-augmented kernel (with Adeos, evidently), the machine hangs. However, when the same code is run in the same but unmodified kernel, the code works as

Re: [Xenomai-core] Handling PCI MSI interrupts

2006-02-15 Thread Jeroen Van den Keybus
At second sight, the patches are ok. I´ve boiled the problem down to a lack of EOI. If I do __ack_APIC_irq() by hand after the desc-handler-end() has run, the system no longer freezes. I'm finding out why that is. Jeroen.

Re: [Xenomai-core] Handling PCI MSI interrupts

2006-02-15 Thread Jeroen Van den Keybus
Ok. I´ve found it. The MSI interrupt type uses its end() handler to acknowledge the interrupt using ack_APIC_irq() (drivers/pci/msi.c). Xenomai uses the ack() handler to expedite the acknowledgement of an IRQ. In case of MSI, ack() is a NOP. The main problem is that Xenomai redefines

Re: [Xenomai-core] Handling PCI MSI interrupts

2006-02-15 Thread Jeroen Van den Keybus
I´m also investigating why MSI also doesn´t work under RTDM. It´s merely a coincidence that the above bug (MSI interrupts from Linux devices getting blocked) emerged and produced exactly the same behaviour (system hanging). It turns out not to be coincidential. rtdm_irq_request() (through passing

Re: [Xenomai-core] Handling PCI MSI interrupts

2006-02-17 Thread Jeroen Van den Keybus
I tried this patch and it doesn't solve the issue I'm facing. With andwithout this patch, my symptoms are the same. I tested (and intended) the patch for MSI (w/o maskbits), not MSI-X. What e1000 chip are you using exactly? Easiest way to tell is by using '/sbin/lspci'. I may be able to help you

Re: [Xenomai-core] Handling PCI MSI interrupts

2006-02-17 Thread Jeroen Van den Keybus
Could you post the patch you are successfully using to boot your box? TIA, --- linux-2.6.15/drivers/pci/msi.c 2006-01-03 04:21:10.0 +0100 +++ linux-2.6.15-ipipe/drivers/pci/msi.c 2006-02-17 16:48:21.0 +0100 @@ -185,10 +185,20 @@ spin_unlock_irqrestore(msi_lock, flags); } +#if

Re: [Xenomai-core] Handling PCI MSI interrupts

2006-02-17 Thread Jeroen Van den Keybus
Ok; unless my brain is completely toast, the last patch I recently posted does thesame, but extends the support to the MSI and MSI-X with masking bit cases. Correct. Could you test in on your box with a vanilla 2.6.15 when time allows? If it works, then I will roll out a new Adeos/x86 patch

Re: [Xenomai-core] [PATCH] Shared irqs v.6

2006-02-01 Thread Jeroen Van den Keybus
I mean that the support of shared interrupts for ISA boards (edge-triggered stuff) is a kind of emulation to overcome the shortcommings of the initial design on the hardware level. The hardware was just not supposed to support shared interrupt channels. So, let's keep it a bit aside from

[Xenomai-core] Scheduling while atomic

2006-01-18 Thread Jeroen Van den Keybus
Gilles, I cannot reproduce those messages after turning nucleus debugging on. Instead, I now either get relatively more failing mutexes oreven hard lockups with the test program I sent to you. If thecomputer didn't crash, dmesg contains 3 Xenomai messages relating to a task being movend to

[Xenomai-core] Scheduling while atomic

2006-01-18 Thread Jeroen Van den Keybus
Hello, Apparently, the code I shared with Gilles never made it to this forum. Anyway, the issue I'm having here is really a problem and it might be useful if some of you could try it out or comment on it. I might be making a silly programming error here, but the result is invariably erroneous

Re: [Xenomai-core] Scheduling while atomic

2006-01-18 Thread Jeroen Van den Keybus
Interesting, when writing to 2 different files, I get the same crashes. Will test with only one task/fd. In fact, my last crash report did contain a difference with yours: ROOT task was at priority 0 main was at 1 task0 was at 30 timeout 3.7ms task1 was at 29 timeout 4.9 ms Does this mean

Re: [Xenomai-core] Scheduling while atomic

2006-01-18 Thread Jeroen Van den Keybus
Hm. When I remove the output() from both tasks, all seems fine. Jeroen.

Re: [Xenomai-core] Scheduling while atomic

2006-01-18 Thread Jeroen Van den Keybus
When testing, also check the dmesg logs please. When nucleus debugging is off, you get only a kernel warning 'scheduling while atomic'. - Could you replace MAXLONG on line 119 with TM_INFINITE and rerun the sem test (to avoid printf'ing) You can terminate with Ctrl+C. - Could you try to run with

[Xenomai-core] Re: [BUG] racy xnshadow_harden under CONFIG_PREEMPT

2006-01-21 Thread Jeroen Van den Keybus
@Jeroen: Did you verify that your setup also works fine withoutCONFIG_PREEMPT? Verified. Your workaround works. No more dmesg logs.

Re: [Xenomai-core] [BUG] racy xnshadow_harden under CONFIG_PREEMPT

2006-01-23 Thread Jeroen Van den Keybus
Hello, I'm currently not at a level to participate in your discussion. Although I'm willing to supply you with stresstests, I would nevertheless like to learn more from task migrationas this debugging session proceeds. In order to do so, please confirm the following statements or indicate where

Re: [Xenomai-core] [BUG] racy xnshadow_harden under CONFIG_PREEMPT

2006-01-31 Thread Jeroen Van den Keybus
And now, Ladies and Gentlemen, with the patches attached. I've installed both patches and the problem seems to have disappeared. I'll try it on another machine tomorrow, too. Meanwhile: thanks very much forthe assistance ! Jeroen.

[Xenomai-core] I-pipe fasteoi interrupt handling issue

2007-10-24 Thread Jeroen Van den Keybus
On my Linux 2.6.23 with latest I-pipe patch (1.10-10), interrupts are dispatched twice if they are of the fasteoi type. I have the impression that the I-pipe does the eoi() acknowledgement (in kernel/irq/chip.c: __ipipe_ack_fasteoi_irq) without first masking off the IRQ. As the interrupt line

Re: [Xenomai-core] Registering MSI interrupt with Xenomai fails

2007-11-02 Thread Jeroen Van den Keybus
Now looking into xnintr_attach(). In xnintr_attach(), the crash occurs in xnarch_set_irq_affinity(). If the call is removed, the driver works as expected (gaining another 3 usec of latency). Now investigating ipipe_set_irq_affinity. Jeroen. Jeroen.

[Xenomai-core] Registering MSI interrupt with Xenomai fails

2007-11-02 Thread Jeroen Van den Keybus
We have a driver that operates on a PCIe card. The card has IRQ17. If we use it like that (IO-APIC-fasteoi), interrupt registration using rtdm_irq_request works correctly. (We also use rtdm_irq_enable afterwards, but it seems that the request already enables the interrupt.) However, if we

Re: [Xenomai-core] Registering MSI interrupt with Xenomai fails

2007-11-03 Thread Jeroen Van den Keybus
arch_setup_msi_irq() creates an IRQ on-the-fly from the current descriptor which is being converted to an MSI interrupt using pci_msi_enable(). From that point, the I-pipe might have an obsolete view of the interrupt map. I suspect an I-pipe issue here. I think the I-pipe is alright. It

Re: [Xenomai-core] Registering MSI interrupt with Xenomai fails

2007-11-03 Thread Jeroen Van den Keybus
The I-pipe virtualizes all IOAPIC and ISA interrupts upon startup. Then, any code calling pci_msi_enable() would end up allocating a new MSI interrupt vector. I see. So in fact, at least for the Linux domain, which indeed registers all interrupts upon initialization, every newly created MSI

Re: [Xenomai-core] Registering MSI interrupt with Xenomai fails

2007-11-05 Thread Jeroen Van den Keybus
Could there be any reason why e.g. a pci_config_read_dword() call would fail in Xenomai context (because when still in the module probe code, I can perform the call correctly - in both cases I checked the dev-bus-ops-read/write pointers and they are identical) ? Today I moved the Xenomai

[Xenomai-core] Long execution time inside __ipipe_unstall_iret_root()

2007-11-12 Thread Jeroen Van den Keybus
I have a setup which apparently suffers from long interrupt-disabled sections during heavy load (make -j16 of a kernel). I have instrumented the __ipipe_unstall_iret_root() function with the tracer as follows: asmlinkage void __ipipe_unstall_iret_root(struct pt_regs regs) {

Re: [Xenomai-core] Long execution time inside __ipipe_unstall_iret_root()

2007-11-12 Thread Jeroen Van den Keybus
So, unless the IRQ below should have been raised much earlier, there is no issue here. The point is: I actually do have interrupts (not the IPI that is visible here) that are being withheld (on average 80 us late) during this period. On this particular setup, I have seen numbers exceeding 300

Re: [Xenomai-core] Long execution time inside __ipipe_unstall_iret_root()

2007-11-12 Thread Jeroen Van den Keybus
Ouch, this shouldn't be allowed in user space! WBINVD is a privileged instruction. Do we leak privileges to user land??? Please check if your execution mode (privilege ring) is correct there. No, I rather meant a kernel-mode program that was controlled from the user space. Sorry for