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
--
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
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 check whether
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
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
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
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:
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.
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
have
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
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.
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
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
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
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
have
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.
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
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
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
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
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
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
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
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 wrappers in
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.
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
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
27 matches
Mail list logo
