>
> Without any patch of this series:
> textdata bss dec hex filename
> 791892168 308 81665 13f01
> kernel/xenomai/skins/native/xeno_native.o
> 2666821761104 2994874fc
> kernel/xenomai/skins/rtdm/xeno_rtdm.o
> 1026611376 160224 264261 40845
> kern
>
> 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 upset
> 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
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)
{
ipipe_trace_specia
I must suspend the search for this problem for a while. The specific
hardware (computer) is unavailable to me for about a week.
Jeroen.
> 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
>
> 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 Xe
>
> 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 M
>
>
> 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.
>
>
> 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.
>
__
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 redefine
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 hasn
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) an
Ok, done. The patch works. Took me longer than expected, as I had to find out that 8 spaces don't make a TAB for 'patch'...
Jeroen.
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
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
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 o
Ok, done. The patch works. Took me longer than expected, as I had to find out that 8 spaces don't make a TAB for 'patch'...
Jeroen.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
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
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
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 o
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
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, b
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 ack_APIC_irq(
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.
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
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, b
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 mask_and_ack_level
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 ack_APIC_irq(
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.
___
Xenomai-core mailing lis
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 mask_and_ack_level
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 expec
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.
1. Turn off the card's interrupts after the first IRQ has arrived.
Result: still hangs.
Jeroen.
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 t
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?
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 comp
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 expec
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
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
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 t
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
https://mail.gna.org/listinfo/xenomai-cor
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 comp
Revision 466 contains the mutex-info fix, but that is post -rc2. Why notswitching to SVN head?
Philippe asked to apply the 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. Actual
> 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 was using th
> 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 ano
Revision 466 contains the mutex-info fix, but that is post -rc2. Why notswitching to SVN head?
Philippe asked to apply the 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. Actual
> 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 was using th
> 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 ano
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 for the assistance !
Jeroen.
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 for the assistance !
Jeroen.
___
Xenomai-core ma
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 migration as this debugging session proceeds. In order to do so, please confirm the following statements or indicate wher
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 migration as this debugging session proceeds. In order to do so, please confirm the following statements or indicate wher
@Jeroen: Did you verify that your setup also works fine withoutCONFIG_PREEMPT?
Verified. Your workaround works. No more dmesg logs.
@Jeroen: Did you verify that your setup also works fine withoutCONFIG_PREEMPT?
Verified. Your workaround works. No more dmesg logs.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
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.
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
https:
Hold on. Just crashed without the file access: please disregard last post.
Jeroen.
Hm.
When I remove the output() from both tasks, all seems fine.
Jeroen.
# ./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: N
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
Hm.
When I remove the output() from both tasks, all seems fine.
Jeroen.
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
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 o
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
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
# ./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: N
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
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
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
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 o
Gilles,
I cannot reproduce those messages after turning nucleus debugging on. Instead, I now either get relatively more failing mutexes or even hard lockups with the test program I sent to you. If the computer didn't crash, dmesg contains 3 Xenomai messages relating to a task being movend to se
Gilles,
I cannot reproduce those messages after turning nucleus debugging on. Instead, I now either get relatively more failing mutexes or even hard lockups with the test program I sent to you. If the computer didn't crash, dmesg contains 3 Xenomai messages relating to a task being movend to se
72 matches
Mail list logo
