Philippe Gerum wrote:
Jeroen Van den Keybus wrote:
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'...
Perfect. Thanks.
http://download.gna.org/adeos/patches/v2.6/i386/adeos-ipipe-2.6.15-i386-1.2-01.patch
--
Phili
Philippe Gerum wrote:
Jeroen Van den Keybus wrote:
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'...
Perfect. Thanks.
http://download.gna.org/adeos/patches/v2.6/i386/adeos-ipipe-2.6.15-i386-1.2-01.patch
--
Phili
Jeroen Van den Keybus wrote:
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'...
Perfect. Thanks.
Jeroen.
--
Philippe.
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
Jeroen Van den Keybus wrote:
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.c2006-02-17
16:48:21.0 +0100
@@ -185,10 +185,20 @
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
Russell Johnson wrote:
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 out with MSI-X as well, but in
that case, I have no hardware platform to test on.
You ca
> > 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 out with MSI-X as well, but in
> > that case, I have no hardware platform to test on.
> > You can chec
Jeroen Van den Keybus wrote:
I tried this patch and it doesn't solve the issue I'm facing. With and
without 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 usin
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
Jeroen Van den Keybus wrote:
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'...
Perfect. Thanks.
Jeroen.
--
Philippe.
___
Xenomai-core mailing list
Xenomai-core@gna.org
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
Jeroen Van den Keybus wrote:
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.c2006-02-17
16:48:21.0 +0100
@@ -185,10 +185,20 @
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
Russell Johnson wrote:
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 out with MSI-X as well, but in
that case, I have no hardware platform to test on.
You ca
> > 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 out with MSI-X as well, but in
> > that case, I have no hardware platform to test on.
> > You can chec
Jeroen Van den Keybus wrote:
I tried this patch and it doesn't solve the issue I'm facing. With and
without 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 usin
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
> The latest patch was incomplete; you might be luckier with
> this one. I've merged Jeroen's last observations on this issue and mine.
I tried this patch and it doesn't solve the issue I'm facing. With and
without this patch, my symptoms are the same.
I'm running a Dell 2850, dual CPU machine.
Russell Johnson wrote:
It's definitely an Adeos issue and msi.c needs fixing. What
about this patch, do
things improve with it (against 2.6.15-ipipe-1.2-00)?
I'm currently patching my setup which started with ipipe-2.6.14-i386-1.0-12.
I've been having no luck with any MSI devices in the sys
> The latest patch was incomplete; you might be luckier with
> this one. I've merged Jeroen's last observations on this issue and mine.
I tried this patch and it doesn't solve the issue I'm facing. With and
without this patch, my symptoms are the same.
I'm running a Dell 2850, dual CPU machine.
Russell Johnson wrote:
It's definitely an Adeos issue and msi.c needs fixing. What
about this patch, do
things improve with it (against 2.6.15-ipipe-1.2-00)?
I'm currently patching my setup which started with ipipe-2.6.14-i386-1.0-12.
I've been having no luck with any MSI devices in the sys
> It's definitely an Adeos issue and msi.c needs fixing. What
> about this patch, do
> things improve with it (against 2.6.15-ipipe-1.2-00)?
I'm currently patching my setup which started with ipipe-2.6.14-i386-1.0-12.
I've been having no luck with any MSI devices in the system even if they
hav
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
Jeroen Van den Keybus wrote:
It's definitely an Adeos issue and msi.c needs fixing. What about
this patch, do
things 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 ev
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
Jeroen Van den Keybus wrote:
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 th
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.
> It's definitely an Adeos issue and msi.c needs fixing. What
> about this patch, do
> things improve with it (against 2.6.15-ipipe-1.2-00)?
I'm currently patching my setup which started with ipipe-2.6.14-i386-1.0-12.
I've been having no luck with any MSI devices in the system even if they
hav
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
Jeroen Van den Keybus wrote:
It's definitely an Adeos issue and msi.c needs fixing. What about
this patch, do
things 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 ev
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
Jeroen Van den Keybus wrote:
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 th
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
Jeroen Van den Keybus wrote:
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 unmodifi
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
Jan Kiszka wrote:
Jeroen Van den Keybus wrote:
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?
Disable or enable (I guess the latter one)?
In either case, there are equival
Jeroen Van den Keybus wrote:
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?
rthal_irq_disable, sorry.
--
Philippe.
Jeroen Van den Keybus wrote:
> 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?
>>
Disable or enable (I guess the latter one)?
In either case, there are equivalent wrapp
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?
Jeroen Van den Keybus wrote:
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_ena
Jeroen Van den Keybus wrote:
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 unmodifi
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
Jan Kiszka wrote:
Jeroen Van den Keybus wrote:
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?
Disable or enable (I guess the latter one)?
In either case, there are equival
Jeroen Van den Keybus wrote:
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?
rthal_irq_disable, sorry.
--
Philippe.
Jeroen Van den Keybus wrote:
> 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?
>>
Disable or enable (I guess the latter one)?
In either case, there are equivalent wrapp
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
Jeroen Van den Keybus wrote:
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_ena
60 matches
Mail list logo
