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 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 or not MSI is actually being used by doing '/sbin/lspci -v' and look for the Capability: Message Signalled Interrupt. When the driver is running in MSI mode, it should read 'Enable+' instead of 'Enable-'.
Finally, verify how interrupts are dispatched. Have a look at /proc/interrupts for this (cat /proc/interrupts').
I'm running a Dell 2850, dual CPU machine.
As it's a Dell, I assume there's two Intel Penium CPU's inside. Are you running with SMP enabled ?
When I build a kernel without
Adeos then things are fine. When I build with Adeos and MSI enabled the
following occurs:
1) If BIOS has USB disabled then the system will hang without even a
num-lock respose (i.e. tapping the num-lock key doesn't toggle the light).
The hang occurs just about the time the E1000 driver would load and enable
an MSI interrupt.
2) If BIOS has USB enabled then the system will run much longer but may hang
during heavy interrupt load on the E1000 driver.
Are you using the e1000 driver in NAPI mode ? It is recommended to do this, especially on the preemptible kernel, as it may significantly reduce the interrupt volume. In that case, I think it is doubtful if using MSI would give you any benefit at all over normal, shared IRQs.
My assumption based on past experience is that no num-lock response means an
infinite interrupt loop.
The local (internal) CPU APIC hasn't been informed that the interrupt has been dealt with and it will therefore allow no other interrupts anymore to arrive in the CPU (including your keyboard's). In fact, your CPU is idle.
[The original 8259 was designed to detect the IRET instruction bit pattern on the databus and use that as an acknowledge signal. Upon arrival of the second 8259 in the PC/AT, this could no longer be done. I don't know if the APIC could do it today (it seems possible, theoretically). ]
for the most part. There is one scenario where the system will still hang
doing disk and network accesses under a moderate load of I/O.
Hm. That may indicate another issue.
Both of these tests are just to get a stable kernel before I really start
using Adeos. So Adeos is in its default configuration and I haven't loaded
Xenomai modules when these hangs occur.
I'm currently running the 2.6.14.4 kernel with the 2.6.14-1.0-12 patch of
adeos and then I included your msi.c patch from the previous e-mail. If you
have any further hints or suggestions I'll try them. Meanwhile I'm trying
different versions of various drivers (e1000 and scsi) as well as updating
the patch level of the kernel itself.
Try upgrading the kernel. The kernel usually comes with updated drivers as well. Currently I'm running 2.6.16-rc2, which I had to patch manually for Adeos (about 3 'hunks' from the 2.6.15-i386-1.2-00 patch didn't apply properly). By using 2.6.16-rc2, I got much better Intel (especially i865 graphics) chipset support than 2.6.15. Note, however, that I did the bug fixing in this thread on a plain 2.6.15, though (and the msi.c code is nearly identical).
I would recommend upgrading to 2.6.15 with the latest Adeos patch and try to get a stable system before enabling MSI.
_______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
