[Xenomai-help] Xenomai and MSI enabled crashes kernel

[Xenomai-help] Xenomai and MSI enabled crashes kernel

[M. Koehrer]

[-- Attachment #1.1: Type: text/plain, Size: 4339 bytes --]

Hi everybody,

I am using kernel 2.6.20.4 and Xenomai 2.3.1 on a SMP enabled dual core Pentium 4.
Everything works fine when I do not enable the CONFIG_PCI_MSI (Messages signaled interrupts) for
PCI Express.
As I am always short with interrupts I want to use MSI for the PCIe base
I/O devices like Ethernet.

When I run the same kernel without any Xenomai patch, it works really fine.
My onboard PCIe e1000 network adapter will be loaded fine and gets the (cool) interrupt number 219!
Perfect!

When I use the Adeos patch from Xenomai 2.3.1 on this kernel the modprobe of the e1000 driver
leads to a kernel crash.
At this stage no real time application is running.
Using a serial console, I was able to log the kernel dump.
Here it is:

BUG: unable to handle
 kernel NULL pointer dereference at virtual address 00000000
 printing eip:
*pde = 00000000
Oops: 0000 [#1]
SMP
Modules linked in: e1000
CPU:    0
EIP:    0060:[<00000000>]    Not tainted VLI
EFLAGS: 00010086   (2.6.20.4 #7)
EIP is at _stext+0x3feffc70/0x14
eax: c0112244   ebx: 00000006   ecx: c011434d   edx: c168c000
esi: 00000006   edi: 00000046   ebp: ffffffff   esp: c168de20
ds: 007b   es: 007b   ss: 0068
Process ifconfig (pid: 1231, ti=c168c000 task=c1692a90 task.ti=c168c000)
Stack: c03e5680 000000db 00000000 c03d9100 c010ef83 00006d80 00000001 00000060
       e099a210 00000286 ffffff24 df77b5c8 00000000 0000000f 00000001 c0103439
       df77b5c8 e099a0ff e09c0000 00000000 0000000f 00000001 80080740 dfd2007b
Call Trace:
 [<c010ef83>] __ipipe_handle_irq+0x1b9/0x20b
 [<e099a210>] e1000_set_multi+0x111/0x189 [e1000]
 [<c0103439>] common_interrupt+0x21/0x38
 [<e099a0ff>] e1000_set_multi+0x0/0x189 [e1000]
 [<e099a210>] e1000_set_multi+0x111/0x189 [e1000]
 [<c02dcf81>] __dev_mc_upload+0x1d/0x1e
 [<c02dd0a1>] dev_mc_upload+0x24/0x37
 [<c02db5ac>] dev_open+0x44/0x62
 [<c02da079>] dev_change_flags+0x47/0xe4
 [<c030d192>] devinet_ioctl+0x252/0x56f
 [<c02db18a>] dev_ifsioc+0x113/0x38d
 [<c02d15a4>] sock_ioctl+0x0/0x1ad
 [<c02d1732>] sock_ioctl+0x18e/0x1ad
 [<c02d15a4>] sock_ioctl+0x0/0x1ad
 [<c015e18f>] do_ioctl+0x1f/0x62
 [<c015e416>] vfs_ioctl+0x244/0x256
 [<c015e45b>] sys_ioctl+0x33/0x4c
 [<c01029f3>] sysenter_past_esp+0x6c/0x70
 =======================
Code:  Bad EIP value.
EIP: [<00000000>] _stext+0x3feffc70/0x14 SS:ESP 0068:c168de20
 <0>Kernel panic - not syncing: Fatal exception in interrupt
 BUG: at arch/i386/kernel/smp.c:565 smp_call_function()
 [<c010b903>] smp_call_function+0x66/0x10a
 [<c0118e12>] printk+0x62/0xd5
 [<c010b9c2>] smp_send_stop+0x1b/0x2b
 [<c01183ad>] panic+0x4d/0xe4
 [<c0103f71>] die+0x1f2/0x226
 [<c011167c>] do_page_fault+0x447/0x517
 [<c010f61d>] __ipipe_handle_exception+0xce/0x158
 [<c010bb1e>] smp_call_function_interrupt+0x31/0x4c
 [<c033336d>] error_code+0x81/0x90
 [<c011434d>] try_to_wake_up+0x33c/0x346
 [<c0112244>] __activate_task+0x1c/0x29
 [<c010ef83>] __ipipe_handle_irq+0x1b9/0x20b
 [<e099a210>] e1000_set_multi+0x111/0x189 [e1000]
 [<c0103439>] common_interrupt+0x21/0x38
 [<e099a0ff>] e1000_set_multi+0x0/0x189 [e1000]
 [<e099a210>] e1000_set_multi+0x111/0x189 [e1000]
 [<c02dcf81>] __dev_mc_upload+0x1d/0x1e
 [<c02dd0a1>] dev_mc_upload+0x24/0x37
 [<c02db5ac>] dev_open+0x44/0x62
 [<c02da079>] dev_change_flags+0x47/0xe4
 [<c030d192>] devinet_ioctl+0x252/0x56f
 [<c02db18a>] dev_ifsioc+0x113/0x38d
 [<c02d15a4>] sock_ioctl+0x0/0x1ad
 [<c02d1732>] sock_ioctl+0x18e/0x1ad
 [<c02d15a4>] sock_ioctl+0x0/0x1ad
 [<c015e18f>] do_ioctl+0x1f/0x62
 [<c015e416>] vfs_ioctl+0x244/0x256
 [<c015e45b>] sys_ioctl+0x33/0x4c
 [<c01029f3>] sysenter_past_esp+0x6c/0x70
 =======================

I have attached my kernel config to this mail.
Any idea on this? Is there anybody out there that has MSI running succesfully with the Xenomai adeos patch?

Thanks for any feedback on that issue!

Regards

Mathias


-- 
Mathias Koehrer
mathias_koehrer@domain.hid


50€ AMAZON-Einkaufsgutschein bei Bestellung von Arcor-DSL:
Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren
ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT JETZT bei Arcor: günstig
und schnell mit DSL - das All-Inclusive-Paket für clevere Doppel-Sparer,
nur  39,85 €  inkl. DSL- und ISDN-Grundgebühr!
http://www.arcor.de/rd/emf-dsl-2

[-- Attachment #2: config.gz --]
[-- Type: application/octetstream, Size: 8598 bytes --]

Re: [Xenomai-help] Xenomai and MSI enabled crashes kernel

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 4452 bytes --]

M. Koehrer wrote:
> Hi everybody,
> 
> I am using kernel 2.6.20.4 and Xenomai 2.3.1 on a SMP enabled dual core Pentium 4.
> Everything works fine when I do not enable the CONFIG_PCI_MSI (Messages signaled interrupts) for
> PCI Express.
> As I am always short with interrupts I want to use MSI for the PCIe base
> I/O devices like Ethernet.
> 
> When I run the same kernel without any Xenomai patch, it works really fine.
> My onboard PCIe e1000 network adapter will be loaded fine and gets the (cool) interrupt number 219!
> Perfect!
> 
> When I use the Adeos patch from Xenomai 2.3.1 on this kernel the modprobe of the e1000 driver
> leads to a kernel crash.
> At this stage no real time application is running.
> Using a serial console, I was able to log the kernel dump.
> Here it is:
> 
> BUG: unable to handle
>  kernel NULL pointer dereference at virtual address 00000000
>  printing eip:
> *pde = 00000000
> Oops: 0000 [#1]
> SMP
> Modules linked in: e1000
> CPU:    0
> EIP:    0060:[<00000000>]    Not tainted VLI
> EFLAGS: 00010086   (2.6.20.4 #7)
> EIP is at _stext+0x3feffc70/0x14
> eax: c0112244   ebx: 00000006   ecx: c011434d   edx: c168c000
> esi: 00000006   edi: 00000046   ebp: ffffffff   esp: c168de20
> ds: 007b   es: 007b   ss: 0068
> Process ifconfig (pid: 1231, ti=c168c000 task=c1692a90 task.ti=c168c000)
> Stack: c03e5680 000000db 00000000 c03d9100 c010ef83 00006d80 00000001 00000060
>        e099a210 00000286 ffffff24 df77b5c8 00000000 0000000f 00000001 c0103439
>        df77b5c8 e099a0ff e09c0000 00000000 0000000f 00000001 80080740 dfd2007b
> Call Trace:
>  [<c010ef83>] __ipipe_handle_irq+0x1b9/0x20b
>  [<e099a210>] e1000_set_multi+0x111/0x189 [e1000]
>  [<c0103439>] common_interrupt+0x21/0x38
>  [<e099a0ff>] e1000_set_multi+0x0/0x189 [e1000]
>  [<e099a210>] e1000_set_multi+0x111/0x189 [e1000]
>  [<c02dcf81>] __dev_mc_upload+0x1d/0x1e
>  [<c02dd0a1>] dev_mc_upload+0x24/0x37
>  [<c02db5ac>] dev_open+0x44/0x62
>  [<c02da079>] dev_change_flags+0x47/0xe4
>  [<c030d192>] devinet_ioctl+0x252/0x56f
>  [<c02db18a>] dev_ifsioc+0x113/0x38d
>  [<c02d15a4>] sock_ioctl+0x0/0x1ad
>  [<c02d1732>] sock_ioctl+0x18e/0x1ad
>  [<c02d15a4>] sock_ioctl+0x0/0x1ad
>  [<c015e18f>] do_ioctl+0x1f/0x62
>  [<c015e416>] vfs_ioctl+0x244/0x256
>  [<c015e45b>] sys_ioctl+0x33/0x4c
>  [<c01029f3>] sysenter_past_esp+0x6c/0x70
>  =======================
> Code:  Bad EIP value.
> EIP: [<00000000>] _stext+0x3feffc70/0x14 SS:ESP 0068:c168de20
>  <0>Kernel panic - not syncing: Fatal exception in interrupt
>  BUG: at arch/i386/kernel/smp.c:565 smp_call_function()
>  [<c010b903>] smp_call_function+0x66/0x10a
>  [<c0118e12>] printk+0x62/0xd5
>  [<c010b9c2>] smp_send_stop+0x1b/0x2b
>  [<c01183ad>] panic+0x4d/0xe4
>  [<c0103f71>] die+0x1f2/0x226
>  [<c011167c>] do_page_fault+0x447/0x517
>  [<c010f61d>] __ipipe_handle_exception+0xce/0x158
>  [<c010bb1e>] smp_call_function_interrupt+0x31/0x4c
>  [<c033336d>] error_code+0x81/0x90
>  [<c011434d>] try_to_wake_up+0x33c/0x346
>  [<c0112244>] __activate_task+0x1c/0x29
>  [<c010ef83>] __ipipe_handle_irq+0x1b9/0x20b
>  [<e099a210>] e1000_set_multi+0x111/0x189 [e1000]
>  [<c0103439>] common_interrupt+0x21/0x38
>  [<e099a0ff>] e1000_set_multi+0x0/0x189 [e1000]
>  [<e099a210>] e1000_set_multi+0x111/0x189 [e1000]
>  [<c02dcf81>] __dev_mc_upload+0x1d/0x1e
>  [<c02dd0a1>] dev_mc_upload+0x24/0x37
>  [<c02db5ac>] dev_open+0x44/0x62
>  [<c02da079>] dev_change_flags+0x47/0xe4
>  [<c030d192>] devinet_ioctl+0x252/0x56f
>  [<c02db18a>] dev_ifsioc+0x113/0x38d
>  [<c02d15a4>] sock_ioctl+0x0/0x1ad
>  [<c02d1732>] sock_ioctl+0x18e/0x1ad
>  [<c02d15a4>] sock_ioctl+0x0/0x1ad
>  [<c015e18f>] do_ioctl+0x1f/0x62
>  [<c015e416>] vfs_ioctl+0x244/0x256
>  [<c015e45b>] sys_ioctl+0x33/0x4c
>  [<c01029f3>] sysenter_past_esp+0x6c/0x70
>  =======================
> 
> I have attached my kernel config to this mail.
> Any idea on this? Is there anybody out there that has MSI running succesfully with the Xenomai adeos patch?

Hmm, from a glance at the 2.6.20 ipipe patch I would say that MSI is
currently unsupported. No related patch hunk makes it look suspicious to
me -- or is this supposed to work automagically, Philippe?

In the meantime, could you post me your vmlinux privately? When time
allows, I would like to disassemble __ipipe_handle_irq and maybe more.
Please also attach your .config.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] Xenomai and MSI enabled crashes kernel

[Philippe Gerum]

On Fri, 2007-04-27 at 13:48 +0200, Jan Kiszka wrote:

> > 
> > I have attached my kernel config to this mail.
> > Any idea on this? Is there anybody out there that has MSI running succesfully with the Xenomai adeos patch?
> 
> Hmm, from a glance at the 2.6.20 ipipe patch I would say that MSI is
> currently unsupported. No related patch hunk makes it look suspicious to
> me -- or is this supposed to work automagically, Philippe?

Since genirq, MSI interrupts have their irq_chip descriptor managed by
the IO-APIC support. What remains to be tested is the masking/unmasking
code, which is still implemented by the msi driver; unfortunately I have
no PCI-Express hw at hand anymore, so I can't test CONFIG_PCI_MSI
properly.

At first sight, the issue Mathias raised looks like an out-of-bound
array reference indexed on an unexpectedly large IRQ value; this would
be quite a dumb bug, but the only way to check that is with proper hw.

-- 
Philippe.

Re: [Xenomai-help] Xenomai and MSI enabled crashes kernel

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1118 bytes --]

Philippe Gerum wrote:
> On Fri, 2007-04-27 at 13:48 +0200, Jan Kiszka wrote:
> 
>>> I have attached my kernel config to this mail.
>>> Any idea on this? Is there anybody out there that has MSI running succesfully with the Xenomai adeos patch?
>> Hmm, from a glance at the 2.6.20 ipipe patch I would say that MSI is
>> currently unsupported. No related patch hunk makes it look suspicious to
>> me -- or is this supposed to work automagically, Philippe?
> 
> Since genirq, MSI interrupts have their irq_chip descriptor managed by
> the IO-APIC support. What remains to be tested is the masking/unmasking
> code, which is still implemented by the msi driver; unfortunately I have
> no PCI-Express hw at hand anymore, so I can't test CONFIG_PCI_MSI
> properly.
> 
> At first sight, the issue Mathias raised looks like an out-of-bound
> array reference indexed on an unexpectedly large IRQ value; this would
> be quite a dumb bug, but the only way to check that is with proper hw.
> 

... or instrumentation patches for Mathias' target, in case he has the
time to do some short-cycle tests.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] Xenomai and MSI enabled crashes kernel

[M. Koehrer]

Hi all,

sure, I can provide support in testing (as this is reproducable at my PC).

Mathias

> Philippe Gerum wrote:
> > On Fri, 2007-04-27 at 13:48 +0200, Jan Kiszka wrote:
> > 
> >>> I have attached my kernel config to this mail.
> >>> Any idea on this? Is there anybody out there that has MSI running
> succesfully with the Xenomai adeos patch?
> >> Hmm, from a glance at the 2.6.20 ipipe patch I would say that MSI is
> >> currently unsupported. No related patch hunk makes it look suspicious to
> >> me -- or is this supposed to work automagically, Philippe?
> > 
> > Since genirq, MSI interrupts have their irq_chip descriptor managed by
> > the IO-APIC support. What remains to be tested is the masking/unmasking
> > code, which is still implemented by the msi driver; unfortunately I have
> > no PCI-Express hw at hand anymore, so I can't test CONFIG_PCI_MSI
> > properly.
> > 
> > At first sight, the issue Mathias raised looks like an out-of-bound
> > array reference indexed on an unexpectedly large IRQ value; this would
> > be quite a dumb bug, but the only way to check that is with proper hw.
> > 
> 
> ... or instrumentation patches for Mathias' target, in case he has the
> time to do some short-cycle tests.
> 
> Jan
> 
> 

-- 
Mathias Koehrer
mathias_koehrer@domain.hid


50€ AMAZON-Einkaufsgutschein bei Bestellung von Arcor-DSL:
Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren
ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT JETZT bei Arcor: günstig
und schnell mit DSL - das All-Inclusive-Paket für clevere Doppel-Sparer,
nur  39,85 €  inkl. DSL- und ISDN-Grundgebühr!
http://www.arcor.de/rd/emf-dsl-2

Re: [Xenomai-help] Xenomai and MSI enabled crashes kernel

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 577 bytes --]

M. Koehrer wrote:
> Hi all,
> 
> sure, I can provide support in testing (as this is reproducable at my PC).

Then please start like this:

--- linux-2.6.20.orig/arch/i386/kernel/ipipe.c
+++ linux-2.6.20/arch/i386/kernel/ipipe.c
@@ -777,6 +777,7 @@ int __ipipe_handle_irq(struct pt_regs re
     m_ack = 0;
    } else
     m_ack = 1;
+printk("%d %d %d\n", regs.orig_eax, irq, IPIPE_NR_IRQS);

    ipipe_load_cpuid();


TIA,
Jan


PS: Thanks for the vmlinux. The oops must be somewhere in
__ipipe_walk_pipeline - likely due to a inconsistent irq number.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] Xenomai and MSI enabled crashes kernel

[M. Koehrer]

Hi Jan, 

here is the result - I have logged with a serial console (as my kernel freezes).
There are many printk messages...

I hope that helps a little bit

Regards

Mathias
++++++++++++++++++++++++++ START ++++++++++++++++++++++++
INIT: version 2.86 booting
Setting parameters of disc: (none).
Setting the system clock..
Mounting proc filesystem
mount: proc already mounted
Cleaning up ifupdown....
Loading kernel modules...done.
Loading device-mapper support.
Checking file systems...fsck 1.40-WIP (14-Nov-2006)
done.
Setting kernel variables...done.
Checking /etc/fstab.
Mounting local filesystems...done.
Activating swapfile swap...done.
Setting up networking....
Configuring network interfaces...BUG: unable to handle kernel NULL pointer dereference-208 207 256
 printing eip:
*pde = 00000000
Oops: 0000 [#1]
-208 207 256
-208 207 256
-1 0 256
SMP -208 207 256
-208 207 256
-1 0 256

Modules linked in:-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
 e1000-208 207 256
-208 207 256
-1 0 256

CPU:    0
EIP:    0060:[<00000000>]    Not tainted VLI
EFLAGS: 00010286   (2.6.20.4 #15)
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
EIP is at _stext+0x3feffc70/0x14
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
eax: c0112268   ebx: 00000006   ecx: c0114371   edx: df042000
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
esi: c0118e36   edi: c03847cd   ebp: ffffffff   esp: df043e10
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
ds: 007b   es: 007b   ss: 0068
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
Process ifconfig (pid: 1241, ti=df042000 task=c1693a90 task.ti=df042000)-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256

Stack: -1 0 256
-208 207 256
-208 207 256
c03e5680 -1 0 256
-208 207 256
-208 207 256
000000db -1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
00000000 -1 0 256
-208 207 256
-208 207 256
c03d9100 -1 0 256
-208 207 256
-208 207 256
c010efa5 -1 0 256
-208 207 256
-208 207 256
c03847cd -1 0 256
-208 207 256
-208 207 256
ffffff24 -1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
000000db -1 0 256
-208 207 256
-208 207 256

       -1 0 256
-208 207 256
-208 207 256
00000100 -1 0 256
-208 207 256
-208 207 256
00006d80 -1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
00000001 -1 0 256
-208 207 256
-208 207 256
00000060 -1 0 256
-208 207 256
-208 207 256
e099a210 -1 0 256
-208 207 256
-208 207 256
00000286 -1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
ffffff24 -1 0 256
-208 207 256
-208 207 256
df70b5c8 -1 0 256
-208 207 256
-208 207 256

       -1 0 256
-208 207 256
-208 207 256
00000000 -1 0 256
-208 207 256
-208 207 256
0000000f -1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
00000001 -1 0 256
-208 207 256
-208 207 256
c0103439 -1 0 256
-208 207 256
-208 207 256
df70b5c8 -1 0 256
-208 207 256
-208 207 256
e099a0ff -1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
e09c0000 -1 0 256
-208 207 256
-208 207 256
00000000 -1 0 256
-208 207 256
-208 207 256

Call Trace:
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
 [<c010efa5>] -1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
__ipipe_handle_irq+0x1db/0x22d
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
 [<e099a210>] -1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
e1000_set_multi+0x111/0x189 [e1000]
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
 [<c0103439>] -1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
common_interrupt+0x21/0x38
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
 [<e099a0ff>] -1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
e1000_set_multi+0x0/0x189 [e1000]
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
 [<e099a210>] -1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
e1000_set_multi+0x111/0x189 [e1000]
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
 [<c02dcfa1>] -1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
__dev_mc_upload+0x1d/0x1e
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
 [<c02dd0c1>] -1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
dev_mc_upload+0x24/0x37
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
 [<c02db5cc>] -1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
dev_open+0x44/0x62
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
 [<c02da099>] -1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
dev_change_flags+0x47/0xe4
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
 [<c030d1b2>] -1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
devinet_ioctl+0x252/0x56f
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
 [<c02db1aa>] -1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
dev_ifsioc+0x113/0x38d
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
 [<c02d15c4>] -1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
sock_ioctl+0x0/0x1ad
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
 [<c02d1752>] -1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
sock_ioctl+0x18e/0x1ad
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
 [<c02d15c4>] -1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
sock_ioctl+0x0/0x1ad
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
 [<c015e1b3>] -1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
do_ioctl+0x1f/0x62
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
 [<c015e43a>] -1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
vfs_ioctl+0x244/0x256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
 [<c015e47f>] -1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
sys_ioctl+0x33/0x4c
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
 [<c01029f3>] -1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
sysenter_past_esp+0x6c/0x70
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
 =======================
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
Code: -1 0 256
-208 207 256
-208 207 256
 Bad EIP value.-208 207 256

EIP: [<00000000>] _stext+0x3feffc70/0x14-208 207 256
 SS:ESP 0068:df043e10
-208 207 256
 -208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-1 0 256
-208 207 256
-208 207 256
Kernel panic - not syncing: Fatal exception in interrupt
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
 -1 0 256
-208 207 256
-208 207 256
-220 219 256
-1 0 256
-208 207 256
-208 207 256

++++++++++++++++++++++++++++++++ END +++++++++++++++++++++++++++++


----- Original Nachricht ----
Von:     Jan Kiszka <jan.kiszka@domain.hid>
An:      "M. Koehrer" <mathias_koehrer@domain.hid>
Datum:   27.04.2007 15:47
Betreff: Re: [Xenomai-help] Xenomai and MSI enabled crashes kernel

> M. Koehrer wrote:
> > Hi all,
> > 
> > sure, I can provide support in testing (as this is reproducable at my
> PC).
> 
> Then please start like this:
> 
> --- linux-2.6.20.orig/arch/i386/kernel/ipipe.c
> +++ linux-2.6.20/arch/i386/kernel/ipipe.c
> @@ -777,6 +777,7 @@ int __ipipe_handle_irq(struct pt_regs re
>      m_ack = 0;
>     } else
>      m_ack = 1;
> +printk("%d %d %d\n", regs.orig_eax, irq, IPIPE_NR_IRQS);
> 
>     ipipe_load_cpuid();
> 
> 
> TIA,
> Jan
> 
> 
> PS: Thanks for the vmlinux. The oops must be somewhere in
> __ipipe_walk_pipeline - likely due to a inconsistent irq number.
> 
> 

-- 
Mathias Koehrer
mathias_koehrer@domain.hid


50€ AMAZON-Einkaufsgutschein bei Bestellung von Arcor-DSL:
Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren
ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT JETZT bei Arcor: günstig
und schnell mit DSL - das All-Inclusive-Paket für clevere Doppel-Sparer,
nur  39,85 €  inkl. DSL- und ISDN-Grundgebühr!
http://www.arcor.de/rd/emf-dsl-2

Re: [Xenomai-help] Xenomai and MSI enabled crashes kernel

[Philippe Gerum]

On Fri, 2007-04-27 at 16:08 +0200, M. Koehrer wrote:
> Hi Jan, 
> 
> here is the result - I have logged with a serial console (as my kernel freezes).
> There are many printk messages...
> 

--- arch/i386/kernel/ipipe.c~	2007-02-26 10:31:39.000000000 +0100
+++ arch/i386/kernel/ipipe.c	2007-04-27 16:19:06.000000000 +0200
@@ -167,6 +167,7 @@
 static int __ipipe_ack_irq(unsigned irq)
 {
 	irq_desc_t *desc = irq_desc + irq;
+	BUG_ON(!desc->ipipe_ack);
 	desc->ipipe_ack(irq, desc);
 	return 1;
 }

-- 
Philippe.

Re: [Xenomai-help] Xenomai and MSI enabled crashes kernel

[M. Koehrer]

Hello Philippe,

here it is: (I have no idea what BUGON does...)

Mathias

++++++++++++++++++++++++++++++++++++++++++++++ START +++++++++++++++++++++++++++
Performing network-prepareConfiguring network interfaces...BUG: unable to handle kernel NULL pointer dereference-1 0 256
 printing eip:
*pde = 00000000
Oops: 0000 [#1]
-1 0 256
-208 207 256
-208 207 256
SMP -1 0 256
-208 207 256
-208 207 256

Modules linked in:-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
 e1000-1 0 256
-208 207 256
-208 207 256

CPU:    0
EIP:    0060:[<00000000>]    Not tainted VLI
EFLAGS: 00010286   (2.6.20.4 #16)
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
EIP is at _stext+0x3feffc70/0x14
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
eax: c0112274   ebx: 00000006   ecx: c011437d   edx: df04a000
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
esi: c0118e42   edi: c03847e6   ebp: ffffffff   esp: df04be10
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
ds: 007b   es: 007b   ss: 0068
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
Process ifconfig (pid: 1241, ti=df04a000 task=dfc2b560 task.ti=df04a000)-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256

Stack: -1 0 256
-208 207 256
-208 207 256
c03e5680 -1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
000000db -1 0 256
-208 207 256
-208 207 256
00000000 -1 0 256
-208 207 256
-208 207 256
c03d9100 -1 0 256
-208 207 256
-208 207 256
c010efb3 -1 0 256
-208 207 256
-208 207 256
c03847e6 -1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
ffffff24 -1 0 256
-208 207 256
-208 207 256
000000db -1 0 256
-208 207 256
-208 207 256

       -1 0 256
-208 207 256
-208 207 256
00000100 -1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
00006d80 -1 0 256
-208 207 256
-208 207 256
00000001 -1 0 256
-208 207 256
-208 207 256
00000060 -1 0 256
-208 207 256
-208 207 256
e099a210 -1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
00000286 -1 0 256
-208 207 256
-208 207 256
ffffff24 -1 0 256
-208 207 256
-208 207 256
df70c5c8 -1 0 256
-208 207 256
-208 207 256

       -1 0 256
-208 207 256
-208 207 256
00000000 -1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
0000000f -1 0 256
-208 207 256
-208 207 256
00000001 -1 0 256
-208 207 256
-208 207 256
c0103439 -1 0 256
-208 207 256
-208 207 256
df70c5c8 -1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
e099a0ff -1 0 256
-208 207 256
-208 207 256
e09c0000 -1 0 256
-208 207 256
-208 207 256
00000000 -1 0 256
-208 207 256
-208 207 256

Call Trace:
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
 [<c010efb3>] -1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
__ipipe_handle_irq+0x1db/0x22d
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
 [<e099a210>] -1 0 256
-208 207 256
-208 207 256
e1000_set_multi+0x111/0x189 [e1000]
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
 [<c0103439>] -1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
common_interrupt+0x21/0x38
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
 [<e099a0ff>] -1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
e1000_set_multi+0x0/0x189 [e1000]
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
 [<e099a210>] -1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
e1000_set_multi+0x111/0x189 [e1000]
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
 [<c02dcfb1>] -1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
__dev_mc_upload+0x1d/0x1e
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
 [<c02dd0d1>] -1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
dev_mc_upload+0x24/0x37
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
 [<c02db5dc>] -1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
dev_open+0x44/0x62
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
 [<c02da0a9>] -1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
dev_change_flags+0x47/0xe4
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
 [<c030d1c2>] -1 0 256
-208 207 256
-208 207 256
devinet_ioctl+0x252/0x56f
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
 [<c02db1ba>] -1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
dev_ifsioc+0x113/0x38d
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
 [<c02d15d4>] -1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
sock_ioctl+0x0/0x1ad
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
 [<c02d1762>] -1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
sock_ioctl+0x18e/0x1ad
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
 [<c02d15d4>] -1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
sock_ioctl+0x0/0x1ad
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
 [<c015e1bf>] -1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
do_ioctl+0x1f/0x62
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
 [<c015e446>] -1 0 256
-208 207 256
-208 207 256
vfs_ioctl+0x244/0x256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
 [<c015e48b>] -208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
sys_ioctl+0x33/0x4c
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
 [<c01029f3>] -1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
sysenter_past_esp+0x6c/0x70
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
 =======================
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
Code: -208 207 256
-208 207 256
 Bad EIP value.-208 207 256

EIP: [<00000000>] _stext+0x3feffc70/0x14-208 207 256
 SS:ESP 0068:df04be10
-208 207 256
 -208 207 256
-1 0 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
Kernel panic - not syncing: Fatal exception in interrupt
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256
 -208 207 256
-208 207 256
-220 219 256
-1 0 256
-208 207 256
-208 207 256
-1 0 256

++++++++++++++++++++++++++++++++++++++++++++++ END +++++++++++++++++++++++++++
 


> On Fri, 2007-04-27 at 16:08 +0200, M. Koehrer wrote:
> > Hi Jan, 
> > 
> > here is the result - I have logged with a serial console (as my kernel
> freezes).
> > There are many printk messages...
> > 
> 
> --- arch/i386/kernel/ipipe.c~	2007-02-26 10:31:39.000000000 +0100
> +++ arch/i386/kernel/ipipe.c	2007-04-27 16:19:06.000000000 +0200
> @@ -167,6 +167,7 @@
>  static int __ipipe_ack_irq(unsigned irq)
>  {
>  	irq_desc_t *desc = irq_desc + irq;
> +	BUG_ON(!desc->ipipe_ack);
>  	desc->ipipe_ack(irq, desc);
>  	return 1;
>  }
> 
> -- 
> Philippe.
> 
> 
> 

-- 
Mathias Koehrer
mathias_koehrer@domain.hid


50€ AMAZON-Einkaufsgutschein bei Bestellung von Arcor-DSL:
Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren
ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT JETZT bei Arcor: günstig
und schnell mit DSL - das All-Inclusive-Paket für clevere Doppel-Sparer,
nur  39,85 €  inkl. DSL- und ISDN-Grundgebühr!
http://www.arcor.de/rd/emf-dsl-2

Re: [Xenomai-help] Xenomai and MSI enabled crashes kernel

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 730 bytes --]

M. Koehrer wrote:
> Hi Jan, 
> 
> here is the result - I have logged with a serial console (as my kernel freezes).
> There are many printk messages...
> 
> I hope that helps a little bit

Not yet (was a silly patch, please revert first). Another try

--- linux-2.6.20.orig/include/asm-i386/ipipe.h
+++ linux-2.6.20/include/asm-i386/ipipe.h
@@ -262,6 +262,9 @@ static inline unsigned long __ipipe_ffnz
 do { \
 	local_irq_enable_nohead(ipd);				 \
 	if (ipd == ipipe_root_domain) {				 \
+if (!ipd->irqs[irq].handler) { \
+	ipipe_set_printk_sync(ipd); printk("irq=%d\n", irq); BUG(); \
+}; \
 		if (likely(!ipipe_virtual_irq_p(irq))) {	 \
 			__ipipe_call_root_xirq_handler(ipd,irq); \
 		} else {					 \



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] Xenomai and MSI enabled crashes kernel

[Philippe Gerum]

On Fri, 2007-04-27 at 16:28 +0200, M. Koehrer wrote:
> Hello Philippe,
> 
> here it is: (I have no idea what BUGON does...)

This triggers a kernel panic whenever the assertion is true.
The bug we are chasing is typical of an indirect function call using an
unexpectedly null pointer. There are a few callbacks in the interrupt
grabbing code, I'm trying to locate the one that jumps out of the
window.

> 
> Mathias
> 
> ++++++++++++++++++++++++++++++++++++++++++++++ START +++++++++++++++++++++++++++
> Performing network-prepareConfiguring network interfaces...BUG: unable to handle kernel NULL pointer dereference-1 0 256
>  printing eip:
> *pde = 00000000
> Oops: 0000 [#1]
> -1 0 256
> -208 207 256
> -208 207 256
> SMP -1 0 256
> -208 207 256
> -208 207 256
> 
> Modules linked in:-1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
>  e1000-1 0 256
> -208 207 256
> -208 207 256
> 
> CPU:    0
> EIP:    0060:[<00000000>]    Not tainted VLI
> EFLAGS: 00010286   (2.6.20.4 #16)
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> EIP is at _stext+0x3feffc70/0x14
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> eax: c0112274   ebx: 00000006   ecx: c011437d   edx: df04a000
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> esi: c0118e42   edi: c03847e6   ebp: ffffffff   esp: df04be10
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> ds: 007b   es: 007b   ss: 0068
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> Process ifconfig (pid: 1241, ti=df04a000 task=dfc2b560 task.ti=df04a000)-1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> 
> Stack: -1 0 256
> -208 207 256
> -208 207 256
> c03e5680 -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> 000000db -1 0 256
> -208 207 256
> -208 207 256
> 00000000 -1 0 256
> -208 207 256
> -208 207 256
> c03d9100 -1 0 256
> -208 207 256
> -208 207 256
> c010efb3 -1 0 256
> -208 207 256
> -208 207 256
> c03847e6 -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> ffffff24 -1 0 256
> -208 207 256
> -208 207 256
> 000000db -1 0 256
> -208 207 256
> -208 207 256
> 
>        -1 0 256
> -208 207 256
> -208 207 256
> 00000100 -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> 00006d80 -1 0 256
> -208 207 256
> -208 207 256
> 00000001 -1 0 256
> -208 207 256
> -208 207 256
> 00000060 -1 0 256
> -208 207 256
> -208 207 256
> e099a210 -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> 00000286 -1 0 256
> -208 207 256
> -208 207 256
> ffffff24 -1 0 256
> -208 207 256
> -208 207 256
> df70c5c8 -1 0 256
> -208 207 256
> -208 207 256
> 
>        -1 0 256
> -208 207 256
> -208 207 256
> 00000000 -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> 0000000f -1 0 256
> -208 207 256
> -208 207 256
> 00000001 -1 0 256
> -208 207 256
> -208 207 256
> c0103439 -1 0 256
> -208 207 256
> -208 207 256
> df70c5c8 -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> e099a0ff -1 0 256
> -208 207 256
> -208 207 256
> e09c0000 -1 0 256
> -208 207 256
> -208 207 256
> 00000000 -1 0 256
> -208 207 256
> -208 207 256
> 
> Call Trace:
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
>  [<c010efb3>] -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> __ipipe_handle_irq+0x1db/0x22d
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
>  [<e099a210>] -1 0 256
> -208 207 256
> -208 207 256
> e1000_set_multi+0x111/0x189 [e1000]
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
>  [<c0103439>] -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> common_interrupt+0x21/0x38
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
>  [<e099a0ff>] -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> e1000_set_multi+0x0/0x189 [e1000]
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
>  [<e099a210>] -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> e1000_set_multi+0x111/0x189 [e1000]
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
>  [<c02dcfb1>] -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> __dev_mc_upload+0x1d/0x1e
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
>  [<c02dd0d1>] -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> dev_mc_upload+0x24/0x37
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
>  [<c02db5dc>] -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> dev_open+0x44/0x62
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
>  [<c02da0a9>] -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> dev_change_flags+0x47/0xe4
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
>  [<c030d1c2>] -1 0 256
> -208 207 256
> -208 207 256
> devinet_ioctl+0x252/0x56f
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
>  [<c02db1ba>] -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> dev_ifsioc+0x113/0x38d
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
>  [<c02d15d4>] -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> sock_ioctl+0x0/0x1ad
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
>  [<c02d1762>] -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> sock_ioctl+0x18e/0x1ad
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
>  [<c02d15d4>] -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> sock_ioctl+0x0/0x1ad
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
>  [<c015e1bf>] -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> do_ioctl+0x1f/0x62
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
>  [<c015e446>] -1 0 256
> -208 207 256
> -208 207 256
> vfs_ioctl+0x244/0x256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
>  [<c015e48b>] -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> sys_ioctl+0x33/0x4c
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
>  [<c01029f3>] -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> sysenter_past_esp+0x6c/0x70
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
>  =======================
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> Code: -208 207 256
> -208 207 256
>  Bad EIP value.-208 207 256
> 
> EIP: [<00000000>] _stext+0x3feffc70/0x14-208 207 256
>  SS:ESP 0068:df04be10
> -208 207 256
>  -208 207 256
> -1 0 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> Kernel panic - not syncing: Fatal exception in interrupt
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
>  -208 207 256
> -208 207 256
> -220 219 256
> -1 0 256
> -208 207 256
> -208 207 256
> -1 0 256
> 
> ++++++++++++++++++++++++++++++++++++++++++++++ END +++++++++++++++++++++++++++
>  
> 
> 
> > On Fri, 2007-04-27 at 16:08 +0200, M. Koehrer wrote:
> > > Hi Jan, 
> > > 
> > > here is the result - I have logged with a serial console (as my kernel
> > freezes).
> > > There are many printk messages...
> > > 
> > 
> > --- arch/i386/kernel/ipipe.c~	2007-02-26 10:31:39.000000000 +0100
> > +++ arch/i386/kernel/ipipe.c	2007-04-27 16:19:06.000000000 +0200
> > @@ -167,6 +167,7 @@
> >  static int __ipipe_ack_irq(unsigned irq)
> >  {
> >  	irq_desc_t *desc = irq_desc + irq;
> > +	BUG_ON(!desc->ipipe_ack);
> >  	desc->ipipe_ack(irq, desc);
> >  	return 1;
> >  }
> > 
> > -- 
> > Philippe.
> > 
> > 
> > 
> 
-- 
Philippe.

Re: [Xenomai-help] Xenomai and MSI enabled crashes kernel

[M. Koehrer]

Hi Jan,

here is the next result:

Regards

Mathias
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Performing network-prepareConfiguring network interfaces...BUG: unable to handle kernel paging request at virtual address 5112039a
 printing eip:
*pde = 00000000
Oops: 0002 [#1]
SMP 
Modules linked in: e1000
CPU:    0
EIP:    0060:[<c03e5680>]    Not tainted VLI
EFLAGS: 00010092   (2.6.20.4 #17)
EIP is at 0xc03e5680
eax: c0112254   ebx: 00000006   ecx: c011435d   edx: dfa42000
esi: 00000046   edi: ffffffff   ebp: 00000000   esp: dfa43e24
ds: 007b   es: 007b   ss: 0068
Process ifconfig (pid: 1241, ti=dfa42000 task=dfc80030 task.ti=dfa42000)
Stack: 000000db 00000000 c03d9100 c010ef91 00006d80 00000001 00000060 e099a1ed 
       00000286 ffffff24 df6fe5c8 00000000 0000000f 00000002 c0103439 df6fe5c8 
       e099a0ff e09c0000 00000000 0000000f 00000002 80080740 dfdd007b df6f007b 
Call Trace:
 [<c010ef91>] __ipipe_handle_irq+0x1b9/0x20b
 [<e099a1ed>] e1000_set_multi+0xee/0x189 [e1000]
 [<c0103439>] common_interrupt+0x21/0x38
 [<e099a0ff>] e1000_set_multi+0x0/0x189 [e1000]
 [<e099a1ed>] e1000_set_multi+0xee/0x189 [e1000]
 [<c02dcf91>] __dev_mc_upload+0x1d/0x1e
 [<c02dd0b1>] dev_mc_upload+0x24/0x37
 [<c02db5bc>] dev_open+0x44/0x62
 [<c02da089>] dev_change_flags+0x47/0xe4
 [<c030d1a2>] devinet_ioctl+0x252/0x56f
 [<c02db19a>] dev_ifsioc+0x113/0x38d
 [<c02d15b4>] sock_ioctl+0x0/0x1ad
 [<c02d1742>] sock_ioctl+0x18e/0x1ad
 [<c02d15b4>] sock_ioctl+0x0/0x1ad
 [<c015e1a7>] do_ioctl+0x1f/0x62
 [<c015e42e>] vfs_ioctl+0x244/0x256
 [<c015e473>] sys_ioctl+0x33/0x4c
 [<c01029f3>] sysenter_past_esp+0x6c/0x70
 =======================
Code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <00> 91 3d c0 00 91 3d c0 00 00 00 00 00 00 00 00 00 00 00 00 00 
EIP: [<c03e5680>] 0xc03e5680 SS:ESP 0068:dfa43e24
 <0>Kernel panic - not syncing: Fatal exception in interrupt
 BUG: at arch/i386/kernel/smp.c:565 smp_call_function()
 [<c010b903>] smp_call_function+0x66/0x10a
 [<c0118e22>] printk+0x62/0xd5
 [<c010b9c2>] smp_send_stop+0x1b/0x2b
 [<c01183bd>] panic+0x4d/0xe4
 [<c0103f71>] die+0x1f2/0x226
 [<c011168c>] do_page_fault+0x447/0x517
 [<c013fb96>] __alloc_pages+0x52/0x286
 [<c010f62b>] __ipipe_handle_exception+0xce/0x158
 [<c01521cb>] kmem_cache_alloc+0x5d/0x67
 [<c010bb1e>] smp_call_function_interrupt+0x31/0x4c
 [<c033337d>] error_code+0x81/0x90
 [<c011435d>] try_to_wake_up+0x33c/0x346
 [<c0112254>] __activate_task+0x1c/0x29
 [<c010ef91>] __ipipe_handle_irq+0x1b9/0x20b
 [<e099a1ed>] e1000_set_multi+0xee/0x189 [e1000]
 [<c0103439>] common_interrupt+0x21/0x38
 [<e099a0ff>] e1000_set_multi+0x0/0x189 [e1000]
 [<e099a1ed>] e1000_set_multi+0xee/0x189 [e1000]
 [<c02dcf91>] __dev_mc_upload+0x1d/0x1e
 [<c02dd0b1>] dev_mc_upload+0x24/0x37
 [<c02db5bc>] dev_open+0x44/0x62
 [<c02da089>] dev_change_flags+0x47/0xe4
 [<c030d1a2>] devinet_ioctl+0x252/0x56f
 [<c02db19a>] dev_ifsioc+0x113/0x38d
 [<c02d15b4>] sock_ioctl+0x0/0x1ad
 [<c02d1742>] sock_ioctl+0x18e/0x1ad
 [<c02d15b4>] sock_ioctl+0x0/0x1ad
 [<c015e1a7>] do_ioctl+0x1f/0x62
 [<c015e42e>] vfs_ioctl+0x244/0x256
 [<c015e473>] sys_ioctl+0x33/0x4c
 [<c01029f3>] sysenter_past_esp+0x6c/0x70
 =======================






----- Original Nachricht ----
Von:     Jan Kiszka <jan.kiszka@domain.hid>
An:      "M. Koehrer" <mathias_koehrer@domain.hid>
Datum:   27.04.2007 16:31
Betreff: Re: [Xenomai-help] Xenomai and MSI enabled crashes kernel

> M. Koehrer wrote:
> > Hi Jan, 
> > 
> > here is the result - I have logged with a serial console (as my kernel
> freezes).
> > There are many printk messages...
> > 
> > I hope that helps a little bit
> 
> Not yet (was a silly patch, please revert first). Another try
> 
> --- linux-2.6.20.orig/include/asm-i386/ipipe.h
> +++ linux-2.6.20/include/asm-i386/ipipe.h
> @@ -262,6 +262,9 @@ static inline unsigned long __ipipe_ffnz
>  do { \
>  	local_irq_enable_nohead(ipd);				 \
>  	if (ipd == ipipe_root_domain) {				 \
> +if (!ipd->irqs[irq].handler) { \
> +	ipipe_set_printk_sync(ipd); printk("irq=%d\n", irq); BUG(); \
> +}; \
>  		if (likely(!ipipe_virtual_irq_p(irq))) {	 \
>  			__ipipe_call_root_xirq_handler(ipd,irq); \
>  		} else {					 \
> 
> 
> 

-- 
Mathias Koehrer
mathias_koehrer@domain.hid


50€ AMAZON-Einkaufsgutschein bei Bestellung von Arcor-DSL:
Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren
ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT JETZT bei Arcor: günstig
und schnell mit DSL - das All-Inclusive-Paket für clevere Doppel-Sparer,
nur  39,85 €  inkl. DSL- und ISDN-Grundgebühr!
http://www.arcor.de/rd/emf-dsl-2

Re: [Xenomai-help] Xenomai and MSI enabled crashes kernel

[Philippe Gerum]

On Fri, 2007-04-27 at 16:28 +0200, M. Koehrer wrote:
> Hello Philippe,
> 
> here it is: (I have no idea what BUGON does...)
> 

This patch will print out the irq/vector mappings. I'm interested in
reading this output.

--- arch/i386/kernel/io_apic.c~	2007-02-26 10:31:39.000000000 +0100
+++ arch/i386/kernel/io_apic.c	2007-04-27 16:51:51.000000000 +0200
@@ -1259,6 +1259,7 @@
 	current_vector = vector;
 	current_offset = offset;
 	irq_vector[irq] = vector;
+	printk("IRQ %d vectored at #%2x\n", irq, vector);
 
 	return vector;
 }

-- 
Philippe.

Re: [Xenomai-help] Xenomai and MSI enabled crashes kernel

[Philippe Gerum]

On Fri, 2007-04-27 at 16:56 +0200, Philippe Gerum wrote:
> On Fri, 2007-04-27 at 16:28 +0200, M. Koehrer wrote:
> > Hello Philippe,
> > 
> > here it is: (I have no idea what BUGON does...)
> > 
> 
> This patch will print out the irq/vector mappings. I'm interested in
> reading this output.
> 
> --- arch/i386/kernel/io_apic.c~	2007-02-26 10:31:39.000000000 +0100
> +++ arch/i386/kernel/io_apic.c	2007-04-27 16:51:51.000000000 +0200
> @@ -1259,6 +1259,7 @@
>  	current_vector = vector;
>  	current_offset = offset;
>  	irq_vector[irq] = vector;
> +	printk("IRQ %d vectored at #%2x\n", irq, vector);

Please s/%2x/%.2x

>  
>  	return vector;
>  }
> 
-- 
Philippe.

Re: [Xenomai-help] Xenomai and MSI enabled crashes kernel

[M. Koehrer]

Hi Philippe,

here is the next result (I have switched off the "quiet" kernel parameter to get everything).

Regards

Mathias
++++++++++++++++++++++++++++++++++++++++++++++++++

Linux version 2.6.20.4 (root@domain.hid) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #18 SMP Fri Apr 27 16:58:38 GMT-2 2007
BIOS-provided physical RAM map:
sanitize start
sanitize end
copy_e820_map() start: 0000000000000000 size: 000000000009e000 end: 000000000009e000 type: 1
copy_e820_map() type is E820_RAM
copy_e820_map() start: 000000000009e000 size: 0000000000002000 end: 00000000000a0000 type: 2
copy_e820_map() start: 00000000000ca000 size: 0000000000002000 end: 00000000000cc000 type: 2
copy_e820_map() start: 00000000000e4000 size: 000000000001c000 end: 0000000000100000 type: 2
copy_e820_map() start: 0000000000100000 size: 000000001fde0000 end: 000000001fee0000 type: 1
copy_e820_map() type is E820_RAM
copy_e820_map() start: 000000001fee0000 size: 0000000000009000 end: 000000001fee9000 type: 3
copy_e820_map() start: 000000001fee9000 size: 0000000000017000 end: 000000001ff00000 type: 4
copy_e820_map() start: 000000001ff00000 size: 0000000000100000 end: 0000000020000000 type: 2
copy_e820_map() start: 00000000fec00000 size: 0000000000010000 end: 00000000fec10000 type: 2
copy_e820_map() start: 00000000fee00000 size: 0000000000001000 end: 00000000fee01000 type: 2
copy_e820_map() start: 00000000ff000000 size: 0000000001000000 end: 0000000100000000 type: 2
 BIOS-e820: 0000000000000000 - 000000000009e000 (usable)
 BIOS-e820: 000000000009e000 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000ca000 - 00000000000cc000 (reserved)
 BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000001fee0000 (usable)
 BIOS-e820: 000000001fee0000 - 000000001fee9000 (ACPI data)
 BIOS-e820: 000000001fee9000 - 000000001ff00000 (ACPI NVS)
 BIOS-e820: 000000001ff00000 - 0000000020000000 (reserved)
 BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
 BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
 BIOS-e820: 00000000ff000000 - 0000000100000000 (reserved)
510MB LOWMEM available.
found SMP MP-table at 000f5f40
Zone PFN ranges:
  DMA             0 ->     4096
  Normal       4096 ->   130784
early_node_map[1] active PFN ranges
    0:        0 ->   130784
DMI present.
ACPI: PM-Timer IO Port: 0x1008
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 15:6 APIC version 20
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
Processor #1 15:6 APIC version 20
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23
ACPI: IOAPIC (id[0x03] address[0xfec10000] gsi_base[24])
IOAPIC[1]: apic_id 3, version 32, address 0xfec10000, GSI 24-47
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
Enabling APIC mode:  Flat.  Using 2 I/O APICs
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at 30000000 (gap: 20000000:dec00000)
Detected 3192.197 MHz processor.
Built 1 zonelists.  Total pages: 129763
Kernel command line: root=/dev/sda5 vga=ext isolcpus=1,3,7 console=ttyS0,115200n8
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
PID hash table entries: 2048 (order: 11, 8192 bytes)
I-pipe 1.7-03: pipeline enabled.
Console: colour VGA+ 80x50
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 513860k/523136k available (2256k kernel code, 8696k reserved, 893k data, 224k init, 0k highmem)
virtual kernel memory layout:
    fixmap  : 0xfffb7000 - 0xfffff000   ( 288 kB)
    vmalloc : 0xe0800000 - 0xfffb5000   ( 503 MB)
    lowmem  : 0xc0000000 - 0xdfee0000   ( 510 MB)
      .init : 0xc041a000 - 0xc0452000   ( 224 kB)
      .data : 0xc03341f1 - 0xc041360c   ( 893 kB)
      .text : 0xc0100000 - 0xc03341f1   (2256 kB)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 6389.64 BogoMIPS (lpj=12779283)
Mount-cache hash table entries: 512
monitor/mwait feature present.
using mwait in idle threads.
CPU: Trace cache: 12K uops, L1 D cache: 16K
CPU: L2 cache: 2048K
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU0: Intel P4/Xeon Extended MCE MSRs (24) available
Compat vDSO mapped to ffffe000.
Checking 'hlt' instruction... OK.
Freeing SMP alternatives: 15k freed
ACPI: Core revision 20060707
CPU0: Intel(R) Pentium(R) D CPU 3.20GHz stepping 02
Booting processor 1/1 eip 2000
Initializing CPU#1
Calibrating delay using timer specific routine.. 6384.56 BogoMIPS (lpj=12769139)
monitor/mwait feature present.
CPU: Trace cache: 12K uops, L1 D cache: 16K
CPU: L2 cache: 2048K
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 1
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#1.
CPU1: Intel P4/Xeon Extended MCE MSRs (24) available
CPU1: Thermal monitoring enabled
CPU1: Intel(R) Pentium(R) D CPU 3.20GHz stepping 02
Total of 2 processors activated (12774.21 BogoMIPS).
ENABLING IO-APIC IRQs
IRQ 1 vectored at #39
IRQ 3 vectored at #41
IRQ 4 vectored at #49
IRQ 5 vectored at #51
IRQ 6 vectored at #59
IRQ 7 vectored at #61
IRQ 8 vectored at #69
IRQ 9 vectored at #71
IRQ 10 vectored at #79
IRQ 11 vectored at #81
IRQ 12 vectored at #89
IRQ 13 vectored at #91
IRQ 14 vectored at #99
IRQ 15 vectored at #a1
..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
checking TSC synchronization across 2 CPUs: passed.
Brought up 2 CPUs
migration_cost=0
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: BIOS Bug: MCFG area at f0000000 is not E820-reserved
PCI: Not using MMCONFIG.
PCI: PCI BIOS revision 2.10 entry at 0xfd877, last bus=10
PCI: Using configuration type 1
Setting up standard PCI resources
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI quirk: region 1000-107f claimed by ICH6 ACPI/GPIO/TCO
PCI quirk: region 1180-11bf claimed by ICH6 GPIO
0000:00:1f.1: trying to change BAR0 from 0000 to 01F0
0000:00:1f.1: trying to change BAR1 from 0000 to 03F4
0000:00:1f.1: trying to change BAR2 from 0000 to 0170
0000:00:1f.1: trying to change BAR3 from 0000 to 0374
PCI: PXH quirk detected, disabling MSI for SHPC device
PCI: Firmware left 0000:0a:06.0 e100 interrupts enabled, disabling
PCI: Transparent bridge - 0000:00:1e.0
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 *10 11 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 10 *11 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 10 11 14 15) *5
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 *10 11 14 15)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 10 *11 14 15)
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 10 11 14 15) *12
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
pnp: PnP ACPI: found 12 devices
SCSI subsystem initialized
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
PCI: Bridge: 0000:01:00.0
  IO window: disabled.
  MEM window: e0100000-e1ffffff
  PREFETCH window: e8000000-efffffff
PCI: Bridge: 0000:00:01.0
  IO window: disabled.
  MEM window: e0100000-e1ffffff
  PREFETCH window: e8000000-efffffff
PCI: Bridge: 0000:03:00.0
  IO window: disabled.
  MEM window: disabled.
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:1c.0
  IO window: disabled.
  MEM window: e2000000-e20fffff
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:1c.4
  IO window: 4000-4fff
  MEM window: e2100000-e21fffff
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:1c.5
  IO window: 5000-5fff
  MEM window: e2200000-e22fffff
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:1e.0
  IO window: 6000-6fff
  MEM window: e2300000-e3ffffff
  PREFETCH window: 30000000-300fffff
IRQ 16 vectored at #a9
ACPI: PCI Interrupt 0000:00:01.0[A] -> GSI 16 (level, low) -> IRQ 16
IRQ 17 vectored at #b1
ACPI: PCI Interrupt 0000:00:1c.0[A] -> GSI 17 (level, low) -> IRQ 17
ACPI: PCI Interrupt 0000:00:1c.4[A] -> GSI 17 (level, low) -> IRQ 17
ACPI: PCI Interrupt 0000:00:1c.5[B] -> GSI 16 (level, low) -> IRQ 16
NET: Registered protocol family 2
IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
TCP established hash table entries: 16384 (order: 5, 131072 bytes)
TCP bind hash table entries: 8192 (order: 4, 65536 bytes)
TCP: Hash tables configured (established 16384 bind 8192)
TCP reno registered
checking if image is initramfs...it isn't (no cpio magic); looks like an initrd
Freeing initrd memory: 348k freed
Simple Boot Flag at 0x37 set to 0x1
Machine check exception polling timer started.
audit: initializing netlink socket (disabled)
audit(1177686146.976:1): initialized
Installing knfsd (copyright (C) 1996 okir@domain.hid).
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
assign_interrupt_mode Found MSI capability
IRQ 223 vectored at #b9
assign_interrupt_mode Found MSI capability
IRQ 222 vectored at #c1
assign_interrupt_mode Found MSI capability
IRQ 221 vectored at #c9
assign_interrupt_mode Found MSI capability
IRQ 220 vectored at #d1
input: Power Button (FF) as /class/input/input0
ACPI: Power Button (FF) [PWRF]
input: Power Button (CM) as /class/input/input1
ACPI: Power Button (CM) [PWRB]
lp: driver loaded but no devices found
Linux agpgart interface v0.101 (c) Dave Jones
[drm] Initialized drm 1.1.0 20060810
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
00:09: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
00:0a: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
IRQ 18 vectored at #d9
ACPI: PCI Interrupt 0000:05:00.3[C] -> GSI 18 (level, low) -> IRQ 18
0000:05:00.3: ttyS2 at I/O 0x4020 (irq = 18) is a 16550A
parport: PnPBIOS parport detected.
parport0: PC-style at 0x378 (0x778), irq 7 [PCSPP(,...)]
lp0: using parport0 (interrupt-driven).
floppy0: no floppy controllers found
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ICH7: IDE controller at PCI slot 0000:00:1f.1
ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 18
ICH7: chipset revision 1
ICH7: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0x3020-0x3027, BIOS settings: hda:DMA, hdb:pio
hda: HL-DT-STDVD-ROM GDR8164B, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: ATAPI 52X DVD-ROM drive, 256kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
ata_piix 0000:00:1f.2: MAP [ P0 P2 P1 P3 ]
IRQ 19 vectored at #e1
ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 19 (level, low) -> IRQ 19
ata1: SATA max UDMA/133 cmd 0x3068 ctl 0x305E bmdma 0x3030 irq 19
ata2: SATA max UDMA/133 cmd 0x3060 ctl 0x305A bmdma 0x3038 irq 19
scsi0 : ata_piix
ata1.00: ATA-7, max UDMA/133, 160836480 sectors: LBA48 NCQ (depth 0/32)
ata1.00: ata1: dev 0 multi count 16
ata1.00: configured for UDMA/133
scsi1 : ata_piix
ATA: abnormal status 0x7F on port 0x3067
scsi 0:0:0:0: Direct-Access     ATA      Hitachi HDS72168 P21O PQ: 0 ANSI: 5
SCSI device sda: 160836480 512-byte hdwr sectors (82348 MB)
sda: Write Protect is off
SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA
SCSI device sda: 160836480 512-byte hdwr sectors (82348 MB)
sda: Write Protect is off
SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA
 sda: sda1 sda2 < sda5 sda6 sda7 >
sd 0:0:0:0: Attached scsi disk sda
sd 0:0:0:0: Attached scsi generic sg0 type 0
PNP: PS/2 Controller [PNP0303:KBC0,PNP0f13:MSE0] at 0x60,0x64 irq 1,12
serio: i8042 KBD port at 0x60,0x64 irq 1
mice: PS/2 mouse device common for all mice
input: AT Translated Set 2 keyboard as /class/input/input2
input: PC Speaker as /class/input/input3
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
Starting balanced_irq
Using IPI Shortcut mode
RAMDISK: Compressed image found at block 0
Time: tsc clocksource has been installed.
VFS: Mounted root (minix filesystem).
Requested Root Partition: sda5. OK
ReiserFS: sda5: found reiserfs format "3.6" with standard journal
ReiserFS: sda5: using ordered data mode
ReiserFS: sda5: journal params: device sda5, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: sda5: checking transaction log (sda5)
ReiserFS: sda5: Using r5 hash to sort names
VFS: Mounted root (reiserfs filesystem) readonly.
Trying to move old root to /initrd ... /initrd does not exist. Ignored.
Unmounting old root
Trying to free ramdisk memory ... okay
Freeing unused kernel memory: 224k freed
INIT: version 2.86 booting
Setting parameters of disc: (none).
Setting the system clock..
Mounting proc filesystem
mount: proc already mounted
Cleaning up ifupdown....
Loading kernel modules...done.
Loading device-mapper support.
Checking file systems...fsck 1.40-WIP (14-Nov-2006)
done.
Setting kernel variables...done.
Checking /etc/fstab.
Mounting local filesystems...ReiserFS: sda1: found reiserfs format "3.6" with standard journal
ReiserFS: sda1: using ordered data mode
ReiserFS: sda1: journal params: device sda1, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: sda1: checking transaction log (sda1)
ReiserFS: sda1: Using r5 hash to sort names
done.
Activating swapfile swap...done.
Configuring network interfaces...Intel(R) PRO/1000 Network Driver - version 7.3.15-k2
Copyright (c) 1999-2006 Intel Corporation.
ACPI: PCI Interrupt 0000:05:00.0[A] -> GSI 16 (level, low) -> IRQ 16
e1000: 0000:05:00.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1) 00:30:48:5a:f9:0a
e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
IRQ 219 vectored at #e9
BUG: unable to handle kernel paging request at virtual address 511203b2
 printing eip:
c03e5680
*pde = 00000000
Oops: 0002 [#1]
SMP 
Modules linked in: e1000
CPU:    0
EIP:    0060:[<c03e5680>]    Not tainted VLI
EFLAGS: 00010092   (2.6.20.4 #18)
EIP is at 0xc03e5680
eax: c011226c   ebx: 00000006   ecx: c0114375   edx: dfc1a000
esi: 00000046   edi: ffffffff   ebp: 00000000   esp: dfc1be24
ds: 007b   es: 007b   ss: 0068
Process ifconfig (pid: 1241, ti=dfc1a000 task=dfcb3030 task.ti=dfc1a000)
Stack: 000000db 00000000 c03d9100 c010efa9 00006d80 00000001 00000060 e099a210 
       00000286 ffffff24 df7015c8 00000000 0000000f 00000001 c0103439 df7015c8 
       e099a0ff e09c0000 00000000 0000000f 00000001 80080740 c14a007b df70007b 
Call Trace:
 [<c010efa9>] __ipipe_handle_irq+0x1b9/0x20b
 [<e099a210>] e1000_set_multi+0x111/0x189 [e1000]
 [<c0103439>] common_interrupt+0x21/0x38
 [<e099a0ff>] e1000_set_multi+0x0/0x189 [e1000]
 [<e099a210>] e1000_set_multi+0x111/0x189 [e1000]
 [<c02dcfb1>] __dev_mc_upload+0x1d/0x1e
 [<c02dd0d1>] dev_mc_upload+0x24/0x37
 [<c02db5dc>] dev_open+0x44/0x62
 [<c02da0a9>] dev_change_flags+0x47/0xe4
 [<c030d1c2>] devinet_ioctl+0x252/0x56f
 [<c02db1ba>] dev_ifsioc+0x113/0x38d
 [<c02d15d4>] sock_ioctl+0x0/0x1ad
 [<c02d1762>] sock_ioctl+0x18e/0x1ad
 [<c02d15d4>] sock_ioctl+0x0/0x1ad
 [<c015e1bf>] do_ioctl+0x1f/0x62
 [<c015e446>] vfs_ioctl+0x244/0x256
 [<c015e48b>] sys_ioctl+0x33/0x4c
 [<c01029f3>] sysenter_past_esp+0x6c/0x70
 =======================
Code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <00> 91 3d c0 00 91 3d c0 00 00 00 00 00 00 00 00 00 00 00 00 00 
EIP: [<c03e5680>] 0xc03e5680 SS:ESP 0068:dfc1be24
 <0>Kernel panic - not syncing: Fatal exception in interrupt
 BUG: at arch/i386/kernel/smp.c:565 smp_call_function()
 [<c010b903>] smp_call_function+0x66/0x10a
 [<c0118e3a>] printk+0x62/0xd5
 [<c010b9c2>] smp_send_stop+0x1b/0x2b
 [<c01183d5>] panic+0x4d/0xe4
 [<c0103f71>] die+0x1f2/0x226
 [<c01116a4>] do_page_fault+0x447/0x517
 [<c013fbae>] __alloc_pages+0x52/0x286
 [<c010f643>] __ipipe_handle_exception+0xce/0x158
 [<c01521e3>] kmem_cache_alloc+0x5d/0x67
 [<c010bb1e>] smp_call_function_interrupt+0x31/0x4c
 [<c033339d>] error_code+0x81/0x90
 [<c0114375>] try_to_wake_up+0x33c/0x346
 [<c011226c>] __activate_task+0x1c/0x29
 [<c010efa9>] __ipipe_handle_irq+0x1b9/0x20b
 [<e099a210>] e1000_set_multi+0x111/0x189 [e1000]
 [<c0103439>] common_interrupt+0x21/0x38
 [<e099a0ff>] e1000_set_multi+0x0/0x189 [e1000]
 [<e099a210>] e1000_set_multi+0x111/0x189 [e1000]
 [<c02dcfb1>] __dev_mc_upload+0x1d/0x1e
 [<c02dd0d1>] dev_mc_upload+0x24/0x37
 [<c02db5dc>] dev_open+0x44/0x62
 [<c02da0a9>] dev_change_flags+0x47/0xe4
 [<c030d1c2>] devinet_ioctl+0x252/0x56f
 [<c02db1ba>] dev_ifsioc+0x113/0x38d
 [<c02d15d4>] sock_ioctl+0x0/0x1ad
 [<c02d1762>] sock_ioctl+0x18e/0x1ad
 [<c02d15d4>] sock_ioctl+0x0/0x1ad
 [<c015e1bf>] do_ioctl+0x1f/0x62
 [<c015e446>] vfs_ioctl+0x244/0x256
 [<c015e48b>] sys_ioctl+0x33/0x4c
 [<c01029f3>] sysenter_past_esp+0x6c/0x70
 =======================




----- Original Nachricht ----
Von:     Philippe Gerum <rpm@xenomai.org>
An:      "M. Koehrer" <mathias_koehrer@domain.hid>
Datum:   27.04.2007 17:05
Betreff: Re: Re: [Xenomai-help] Xenomai and MSI enabled crashes kernel

> On Fri, 2007-04-27 at 16:56 +0200, Philippe Gerum wrote:
> > On Fri, 2007-04-27 at 16:28 +0200, M. Koehrer wrote:
> > > Hello Philippe,
> > > 
> > > here it is: (I have no idea what BUGON does...)
> > > 
> > 
> > This patch will print out the irq/vector mappings. I'm interested in
> > reading this output.
> > 
> > --- arch/i386/kernel/io_apic.c~	2007-02-26 10:31:39.000000000 +0100
> > +++ arch/i386/kernel/io_apic.c	2007-04-27 16:51:51.000000000 +0200
> > @@ -1259,6 +1259,7 @@
> >  	current_vector = vector;
> >  	current_offset = offset;
> >  	irq_vector[irq] = vector;
> > +	printk("IRQ %d vectored at #%2x\n", irq, vector);
> 
> Please s/%2x/%.2x
> 
> >  
> >  	return vector;
> >  }
> > 
> -- 
> Philippe.
> 
> 
> 

-- 
Mathias Koehrer
mathias_koehrer@domain.hid


50€ AMAZON-Einkaufsgutschein bei Bestellung von Arcor-DSL:
Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren
ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT JETZT bei Arcor: günstig
und schnell mit DSL - das All-Inclusive-Paket für clevere Doppel-Sparer,
nur  39,85 €  inkl. DSL- und ISDN-Grundgebühr!
http://www.arcor.de/rd/emf-dsl-2

Re: [Xenomai-help] Xenomai and MSI enabled crashes kernel

[Philippe Gerum]

On Fri, 2007-04-27 at 17:10 +0200, M. Koehrer wrote:
> Hi Philippe,
> 
> here is the next result (I have switched off the "quiet" kernel parameter to get everything).
> 

Thanks, I will look at this output asap. On your side, please run
$ objdump -d vmlinux > foo

then search for the kernel routine embodying the text address 0xc03e5680
in the dump file (leftmost column). I'd be interested to see the
disassembly of the entire routine.

> IRQ 219 vectored at #e9
> BUG: unable to handle kernel paging request at virtual address 511203b2
>  printing eip:
> c03e5680
> *pde = 00000000
> Oops: 0002 [#1]
> SMP 
> Modules linked in: e1000
> CPU:    0
> EIP:    0060:[<c03e5680>]    Not tainted VLI
> EFLAGS: 00010092   (2.6.20.4 #18)
> EIP is at 0xc03e5680
> eax: c011226c   ebx: 00000006   ecx: c0114375   edx: dfc1a000
> esi: 00000046   edi: ffffffff   ebp: 00000000   esp: dfc1be24
> ds: 007b   es: 007b   ss: 0068
> Process ifconfig (pid: 1241, ti=dfc1a000 task=dfcb3030 task.ti=dfc1a000)
> Stack: 000000db 00000000 c03d9100 c010efa9 00006d80 00000001 00000060 e099a210 
>        00000286 ffffff24 df7015c8 00000000 0000000f 00000001 c0103439 df7015c8 
>        e099a0ff e09c0000 00000000 0000000f 00000001 80080740 c14a007b df70007b 
> Call Trace:
>  [<c010efa9>] __ipipe_handle_irq+0x1b9/0x20b
>  [<e099a210>] e1000_set_multi+0x111/0x189 [e1000]
>  [<c0103439>] common_interrupt+0x21/0x38
>  [<e099a0ff>] e1000_set_multi+0x0/0x189 [e1000]
>  [<e099a210>] e1000_set_multi+0x111/0x189 [e1000]
>  [<c02dcfb1>] __dev_mc_upload+0x1d/0x1e
>  [<c02dd0d1>] dev_mc_upload+0x24/0x37
>  [<c02db5dc>] dev_open+0x44/0x62
>  [<c02da0a9>] dev_change_flags+0x47/0xe4
>  [<c030d1c2>] devinet_ioctl+0x252/0x56f
>  [<c02db1ba>] dev_ifsioc+0x113/0x38d
>  [<c02d15d4>] sock_ioctl+0x0/0x1ad
>  [<c02d1762>] sock_ioctl+0x18e/0x1ad
>  [<c02d15d4>] sock_ioctl+0x0/0x1ad
>  [<c015e1bf>] do_ioctl+0x1f/0x62
>  [<c015e446>] vfs_ioctl+0x244/0x256
>  [<c015e48b>] sys_ioctl+0x33/0x4c
>  [<c01029f3>] sysenter_past_esp+0x6c/0x70
>  =======================
> Code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <00> 91 3d c0 00 91 3d c0 00 00 00 00 00 00 00 00 00 00 00 00 00 
> EIP: [<c03e5680>] 0xc03e5680 SS:ESP 0068:dfc1be24
>  <0>Kernel panic - not syncing: Fatal exception in interrupt
>  BUG: at arch/i386/kernel/smp.c:565 smp_call_function()
>  [<c010b903>] smp_call_function+0x66/0x10a
>  [<c0118e3a>] printk+0x62/0xd5
>  [<c010b9c2>] smp_send_stop+0x1b/0x2b
>  [<c01183d5>] panic+0x4d/0xe4
>  [<c0103f71>] die+0x1f2/0x226
>  [<c01116a4>] do_page_fault+0x447/0x517
>  [<c013fbae>] __alloc_pages+0x52/0x286
>  [<c010f643>] __ipipe_handle_exception+0xce/0x158
>  [<c01521e3>] kmem_cache_alloc+0x5d/0x67
>  [<c010bb1e>] smp_call_function_interrupt+0x31/0x4c
>  [<c033339d>] error_code+0x81/0x90
>  [<c0114375>] try_to_wake_up+0x33c/0x346
>  [<c011226c>] __activate_task+0x1c/0x29
>  [<c010efa9>] __ipipe_handle_irq+0x1b9/0x20b
>  [<e099a210>] e1000_set_multi+0x111/0x189 [e1000]
>  [<c0103439>] common_interrupt+0x21/0x38
>  [<e099a0ff>] e1000_set_multi+0x0/0x189 [e1000]
>  [<e099a210>] e1000_set_multi+0x111/0x189 [e1000]
>  [<c02dcfb1>] __dev_mc_upload+0x1d/0x1e
>  [<c02dd0d1>] dev_mc_upload+0x24/0x37
>  [<c02db5dc>] dev_open+0x44/0x62
>  [<c02da0a9>] dev_change_flags+0x47/0xe4
>  [<c030d1c2>] devinet_ioctl+0x252/0x56f
>  [<c02db1ba>] dev_ifsioc+0x113/0x38d
>  [<c02d15d4>] sock_ioctl+0x0/0x1ad
>  [<c02d1762>] sock_ioctl+0x18e/0x1ad
>  [<c02d15d4>] sock_ioctl+0x0/0x1ad
>  [<c015e1bf>] do_ioctl+0x1f/0x62
>  [<c015e446>] vfs_ioctl+0x244/0x256
>  [<c015e48b>] sys_ioctl+0x33/0x4c
>  [<c01029f3>] sysenter_past_esp+0x6c/0x70
>  =======================
> 
> 
> 
> 
> ----- Original Nachricht ----
> Von:     Philippe Gerum <rpm@xenomai.org>
> An:      "M. Koehrer" <mathias_koehrer@domain.hid>
> Datum:   27.04.2007 17:05
> Betreff: Re: Re: [Xenomai-help] Xenomai and MSI enabled crashes kernel
> 
> > On Fri, 2007-04-27 at 16:56 +0200, Philippe Gerum wrote:
> > > On Fri, 2007-04-27 at 16:28 +0200, M. Koehrer wrote:
> > > > Hello Philippe,
> > > > 
> > > > here it is: (I have no idea what BUGON does...)
> > > > 
> > > 
> > > This patch will print out the irq/vector mappings. I'm interested in
> > > reading this output.
> > > 
> > > --- arch/i386/kernel/io_apic.c~	2007-02-26 10:31:39.000000000 +0100
> > > +++ arch/i386/kernel/io_apic.c	2007-04-27 16:51:51.000000000 +0200
> > > @@ -1259,6 +1259,7 @@
> > >  	current_vector = vector;
> > >  	current_offset = offset;
> > >  	irq_vector[irq] = vector;
> > > +	printk("IRQ %d vectored at #%2x\n", irq, vector);
> > 
> > Please s/%2x/%.2x
> > 
> > >  
> > >  	return vector;
> > >  }
> > > 
> > -- 
> > Philippe.
> > 
> > 
> > 
> 
-- 
Philippe.

Re: [Xenomai-help] Xenomai and MSI enabled crashes kernel

[M. Koehrer]

Hi Philippe,

I have extracted that part. However this very address is not available.
I have placed a couple of lines before and after that address.

Regards

Mathias
PS: I will continue on Monday with the tests....



c0333593 <__kprobes_text_end>:
c0333593:	6a 00                	push   $0x0
c0333595:	0f a1                	pop    %fs
c0333597:	e9 ba e6 dc ff       	jmp    c0101c56 <__switch_to+0x11a>
c033359c:	ba f2 ff ff ff       	mov    $0xfffffff2,%edx
c03335a1:	e9 a6 e7 dc ff       	jmp    c0101d4c <setup_sigcontext+0x14>
c03335a6:	ba f2 ff ff ff       	mov    $0xfffffff2,%edx
c03335ab:	e9 a7 e7 dc ff       	jmp    c0101d57 <setup_sigcontext+0x1f>
c03335b0:	ba f2 ff ff ff       	mov    $0xfffffff2,%edx
c03335b5:	e9 a9 e7 dc ff       	jmp    c0101d63 <setup_sigcontext+0x2b>
c03335ba:	bd f2 ff ff ff       	mov    $0xfffffff2,%ebp
c03335bf:	e9 ab e7 dc ff       	jmp    c0101d6f <setup_sigcontext+0x37>
c03335c4:	ba f2 ff ff ff       	mov    $0xfffffff2,%edx
c03335c9:	e9 a9 e7 dc ff       	jmp    c0101d77 <setup_sigcontext+0x3f>
c03335ce:	ba f2 ff ff ff       	mov    $0xfffffff2,%edx
c03335d3:	e9 ab e7 dc ff       	jmp    c0101d83 <setup_sigcontext+0x4b>
c03335d8:	ba f2 ff ff ff       	mov    $0xfffffff2,%edx
c03335dd:	e9 ad e7 dc ff       	jmp    c0101d8f <setup_sigcontext+0x57>
c03335e2:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c03335e7:	e9 af e7 dc ff       	jmp    c0101d9b <setup_sigcontext+0x63>
c03335ec:	ba f2 ff ff ff       	mov    $0xfffffff2,%edx
c03335f1:	e9 b0 e7 dc ff       	jmp    c0101da6 <setup_sigcontext+0x6e>
c03335f6:	ba f2 ff ff ff       	mov    $0xfffffff2,%edx
c03335fb:	e9 b2 e7 dc ff       	jmp    c0101db2 <setup_sigcontext+0x7a>
c0333600:	ba f2 ff ff ff       	mov    $0xfffffff2,%edx
c0333605:	e9 b4 e7 dc ff       	jmp    c0101dbe <setup_sigcontext+0x86>
c033360a:	ba f2 ff ff ff       	mov    $0xfffffff2,%edx
c033360f:	e9 b6 e7 dc ff       	jmp    c0101dca <setup_sigcontext+0x92>
c0333614:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c0333619:	e9 c5 e7 dc ff       	jmp    c0101de3 <setup_sigcontext+0xab>
c033361e:	ba f2 ff ff ff       	mov    $0xfffffff2,%edx
c0333623:	e9 ce e7 dc ff       	jmp    c0101df6 <setup_sigcontext+0xbe>
c0333628:	ba f2 ff ff ff       	mov    $0xfffffff2,%edx
c033362d:	e9 d0 e7 dc ff       	jmp    c0101e02 <setup_sigcontext+0xca>
c0333632:	ba f2 ff ff ff       	mov    $0xfffffff2,%edx
c0333637:	e9 d2 e7 dc ff       	jmp    c0101e0e <setup_sigcontext+0xd6>
c033363c:	ba f2 ff ff ff       	mov    $0xfffffff2,%edx
c0333641:	e9 d4 e7 dc ff       	jmp    c0101e1a <setup_sigcontext+0xe2>
c0333646:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c033364b:	e9 d6 e7 dc ff       	jmp    c0101e26 <setup_sigcontext+0xee>
c0333650:	ba f2 ff ff ff       	mov    $0xfffffff2,%edx
c0333655:	e9 d8 e7 dc ff       	jmp    c0101e32 <setup_sigcontext+0xfa>
c033365a:	bf f2 ff ff ff       	mov    $0xfffffff2,%edi
c033365f:	e9 e9 e7 dc ff       	jmp    c0101e4d <setup_sigcontext+0x115>
c0333664:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c0333669:	e9 36 e8 dc ff       	jmp    c0101ea4 <setup_sigcontext+0x16c>
c033366e:	ba f2 ff ff ff       	mov    $0xfffffff2,%edx
c0333673:	e9 3d e8 dc ff       	jmp    c0101eb5 <setup_sigcontext+0x17d>
c0333678:	be f2 ff ff ff       	mov    $0xfffffff2,%esi
c033367d:	66 31 c9             	xor    %cx,%cx
c0333680:	e9 70 e8 dc ff       	jmp    c0101ef5 <restore_sigcontext+0x22>
c0333685:	b9 f2 ff ff ff       	mov    $0xfffffff2,%ecx
c033368a:	66 31 db             	xor    %bx,%bx
c033368d:	e9 6f e8 dc ff       	jmp    c0101f01 <restore_sigcontext+0x2e>
c0333692:	6a 00                	push   $0x0
c0333694:	0f a1                	pop    %fs
c0333696:	e9 6c e8 dc ff       	jmp    c0101f07 <restore_sigcontext+0x34>
c033369b:	bb f2 ff ff ff       	mov    $0xfffffff2,%ebx
c03336a0:	66 31 c9             	xor    %cx,%cx
c03336a3:	e9 65 e8 dc ff       	jmp    c0101f0d <restore_sigcontext+0x3a>
c03336a8:	be f2 ff ff ff       	mov    $0xfffffff2,%esi
c03336ad:	66 31 c9             	xor    %cx,%cx
c03336b0:	e9 64 e8 dc ff       	jmp    c0101f19 <restore_sigcontext+0x46>
c03336b5:	bb f2 ff ff ff       	mov    $0xfffffff2,%ebx
c03336ba:	31 c9                	xor    %ecx,%ecx
c03336bc:	e9 65 e8 dc ff       	jmp    c0101f26 <restore_sigcontext+0x53>
c03336c1:	bb f2 ff ff ff       	mov    $0xfffffff2,%ebx
c03336c6:	31 c9                	xor    %ecx,%ecx
c03336c8:	e9 63 e8 dc ff       	jmp    c0101f30 <restore_sigcontext+0x5d>
c03336cd:	bb f2 ff ff ff       	mov    $0xfffffff2,%ebx
c03336d2:	31 c9                	xor    %ecx,%ecx
c03336d4:	e9 61 e8 dc ff       	jmp    c0101f3a <restore_sigcontext+0x67>
c03336d9:	bb f2 ff ff ff       	mov    $0xfffffff2,%ebx
c03336de:	31 c9                	xor    %ecx,%ecx
c03336e0:	e9 5f e8 dc ff       	jmp    c0101f44 <restore_sigcontext+0x71>
c03336e5:	bb f2 ff ff ff       	mov    $0xfffffff2,%ebx
c03336ea:	31 c9                	xor    %ecx,%ecx
c03336ec:	e9 5d e8 dc ff       	jmp    c0101f4e <restore_sigcontext+0x7b>
c03336f1:	bb f2 ff ff ff       	mov    $0xfffffff2,%ebx
c03336f6:	31 c9                	xor    %ecx,%ecx
c03336f8:	e9 5a e8 dc ff       	jmp    c0101f57 <restore_sigcontext+0x84>
c03336fd:	bb f2 ff ff ff       	mov    $0xfffffff2,%ebx
c0333702:	31 c9                	xor    %ecx,%ecx
c0333704:	e9 58 e8 dc ff       	jmp    c0101f61 <restore_sigcontext+0x8e>
c0333709:	bb f2 ff ff ff       	mov    $0xfffffff2,%ebx
c033370e:	31 c9                	xor    %ecx,%ecx
c0333710:	e9 56 e8 dc ff       	jmp    c0101f6b <restore_sigcontext+0x98>
c0333715:	bb f2 ff ff ff       	mov    $0xfffffff2,%ebx
c033371a:	66 31 c9             	xor    %cx,%cx
c033371d:	e9 54 e8 dc ff       	jmp    c0101f76 <restore_sigcontext+0xa3>
c0333722:	bb f2 ff ff ff       	mov    $0xfffffff2,%ebx
c0333727:	66 31 c9             	xor    %cx,%cx
c033372a:	e9 58 e8 dc ff       	jmp    c0101f87 <restore_sigcontext+0xb4>
c033372f:	b9 f2 ff ff ff       	mov    $0xfffffff2,%ecx
c0333734:	31 db                	xor    %ebx,%ebx
c0333736:	e9 5c e8 dc ff       	jmp    c0101f97 <restore_sigcontext+0xc4>
c033373b:	ba f2 ff ff ff       	mov    $0xfffffff2,%edx
c0333740:	31 c9                	xor    %ecx,%ecx
c0333742:	e9 70 e8 dc ff       	jmp    c0101fb7 <restore_sigcontext+0xe4>
c0333747:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c033374c:	31 d2                	xor    %edx,%edx
c033374e:	e9 d1 e8 dc ff       	jmp    c0102024 <restore_sigcontext+0x151>
c0333753:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c0333758:	31 d2                	xor    %edx,%edx
c033375a:	e9 07 e9 dc ff       	jmp    c0102066 <sys_sigaction+0x31>
c033375f:	b9 f2 ff ff ff       	mov    $0xfffffff2,%ecx
c0333764:	31 c0                	xor    %eax,%eax
c0333766:	e9 0c e9 dc ff       	jmp    c0102077 <sys_sigaction+0x42>
c033376b:	ba f2 ff ff ff       	mov    $0xfffffff2,%edx
c0333770:	31 c0                	xor    %eax,%eax
c0333772:	e9 11 e9 dc ff       	jmp    c0102088 <sys_sigaction+0x53>
c0333777:	b9 f2 ff ff ff       	mov    $0xfffffff2,%ecx
c033377c:	31 c0                	xor    %eax,%eax
c033377e:	e9 0c e9 dc ff       	jmp    c010208f <sys_sigaction+0x5a>
c0333783:	ba f2 ff ff ff       	mov    $0xfffffff2,%edx
c0333788:	e9 52 e9 dc ff       	jmp    c01020df <sys_sigaction+0xaa>
c033378d:	bb f2 ff ff ff       	mov    $0xfffffff2,%ebx
c0333792:	e9 55 e9 dc ff       	jmp    c01020ec <sys_sigaction+0xb7>
c0333797:	ba f2 ff ff ff       	mov    $0xfffffff2,%edx
c033379c:	e9 58 e9 dc ff       	jmp    c01020f9 <sys_sigaction+0xc4>
c03337a1:	bb f2 ff ff ff       	mov    $0xfffffff2,%ebx
c03337a6:	e9 57 e9 dc ff       	jmp    c0102102 <sys_sigaction+0xcd>
c03337ab:	be f2 ff ff ff       	mov    $0xfffffff2,%esi
c03337b0:	e9 20 eb dc ff       	jmp    c01022d5 <do_notify_resume+0x1c4>
c03337b5:	ba f2 ff ff ff       	mov    $0xfffffff2,%edx
c03337ba:	e9 1e eb dc ff       	jmp    c01022dd <do_notify_resume+0x1cc>
c03337bf:	bb f2 ff ff ff       	mov    $0xfffffff2,%ebx
c03337c4:	e9 1f eb dc ff       	jmp    c01022e8 <do_notify_resume+0x1d7>
c03337c9:	b9 f2 ff ff ff       	mov    $0xfffffff2,%ecx
c03337ce:	e9 36 eb dc ff       	jmp    c0102309 <do_notify_resume+0x1f8>
c03337d3:	be f2 ff ff ff       	mov    $0xfffffff2,%esi
c03337d8:	e9 3c eb dc ff       	jmp    c0102319 <do_notify_resume+0x208>
c03337dd:	ba f2 ff ff ff       	mov    $0xfffffff2,%edx
c03337e2:	e9 44 eb dc ff       	jmp    c010232b <do_notify_resume+0x21a>
c03337e7:	ba f2 ff ff ff       	mov    $0xfffffff2,%edx
c03337ec:	e9 63 eb dc ff       	jmp    c0102354 <do_notify_resume+0x243>
c03337f1:	bb f2 ff ff ff       	mov    $0xfffffff2,%ebx
c03337f6:	e9 71 eb dc ff       	jmp    c010236c <do_notify_resume+0x25b>
c03337fb:	b9 f2 ff ff ff       	mov    $0xfffffff2,%ecx
c0333800:	e9 c3 eb dc ff       	jmp    c01023c8 <do_notify_resume+0x2b7>
c0333805:	ba f2 ff ff ff       	mov    $0xfffffff2,%edx
c033380a:	e9 c2 eb dc ff       	jmp    c01023d1 <do_notify_resume+0x2c0>
c033380f:	ba f2 ff ff ff       	mov    $0xfffffff2,%edx
c0333814:	e9 c6 eb dc ff       	jmp    c01023df <do_notify_resume+0x2ce>
c0333819:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c033381e:	e9 c5 eb dc ff       	jmp    c01023e8 <do_notify_resume+0x2d7>
c0333823:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c0333828:	e9 88 ec dc ff       	jmp    c01024b5 <do_notify_resume+0x3a4>
c033382d:	bb 04 00 00 00       	mov    $0x4,%ebx
c0333832:	e9 b3 ec dc ff       	jmp    c01024ea <do_notify_resume+0x3d9>
c0333837:	b9 f2 ff ff ff       	mov    $0xfffffff2,%ecx
c033383c:	e9 e5 ec dc ff       	jmp    c0102526 <do_notify_resume+0x415>
c0333841:	ba f2 ff ff ff       	mov    $0xfffffff2,%edx
c0333846:	e9 e6 ec dc ff       	jmp    c0102531 <do_notify_resume+0x420>
c033384b:	ba f2 ff ff ff       	mov    $0xfffffff2,%edx
c0333850:	e9 ea ec dc ff       	jmp    c010253f <do_notify_resume+0x42e>
c0333855:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c033385a:	e9 e9 ec dc ff       	jmp    c0102548 <do_notify_resume+0x437>
c033385f:	ba f2 ff ff ff       	mov    $0xfffffff2,%edx
c0333864:	31 c0                	xor    %eax,%eax
c0333866:	e9 1e f0 dc ff       	jmp    c0102889 <sys_sigreturn+0x2d>
c033386b:	ba 04 00 00 00       	mov    $0x4,%edx
c0333870:	31 c0                	xor    %eax,%eax
c0333872:	e9 1f f0 dc ff       	jmp    c0102896 <sys_sigreturn+0x3a>
c0333877:	c7 44 24 24 00 00 00 	movl   $0x0,0x24(%esp)
c033387e:	00 
c033387f:	e9 9a f1 dc ff       	jmp    c0102a1e <sysenter_exit+0xe>
c0333884:	c7 04 24 00 00 00 00 	movl   $0x0,(%esp)
c033388b:	e9 33 f2 dc ff       	jmp    c0102ac3 <restore_nocheck_notrace+0x7>
c0333890:	c7 04 24 00 00 00 00 	movl   $0x0,(%esp)
c0333897:	e9 28 f2 dc ff       	jmp    c0102ac4 <restore_nocheck_notrace+0x8>
c033389c:	c7 04 24 00 00 00 00 	movl   $0x0,(%esp)
c03338a3:	e9 1d f2 dc ff       	jmp    c0102ac5 <restore_nocheck_notrace+0x9>

c03338a8 <iret_exc>:
c03338a8:	fb                   	sti    
c03338a9:	6a 00                	push   $0x0
c03338ab:	6a 20                	push   $0x20
c03338ad:	e9 6a fa ff ff       	jmp    c033331c <error_code>
c03338b2:	c7 04 24 00 00 00 00 	movl   $0x0,(%esp)
c03338b9:	e9 8a fb dc ff       	jmp    c0103448 <common_interrupt+0x30>
c03338be:	c7 04 24 00 00 00 00 	movl   $0x0,(%esp)
c03338c5:	e9 7f fb dc ff       	jmp    c0103449 <common_interrupt+0x31>
c03338ca:	c7 04 24 00 00 00 00 	movl   $0x0,(%esp)
c03338d1:	e9 74 fb dc ff       	jmp    c010344a <common_interrupt+0x32>
c03338d6:	c7 04 24 00 00 00 00 	movl   $0x0,(%esp)
c03338dd:	e9 a3 fb dc ff       	jmp    c0103485 <reschedule_interrupt+0x35>
c03338e2:	c7 04 24 00 00 00 00 	movl   $0x0,(%esp)
c03338e9:	e9 98 fb dc ff       	jmp    c0103486 <reschedule_interrupt+0x36>
c03338ee:	c7 04 24 00 00 00 00 	movl   $0x0,(%esp)
c03338f5:	e9 8d fb dc ff       	jmp    c0103487 <reschedule_interrupt+0x37>
c03338fa:	c7 04 24 00 00 00 00 	movl   $0x0,(%esp)
c0333901:	e9 bf fb dc ff       	jmp    c01034c5 <invalidate_interrupt+0x35>
c0333906:	c7 04 24 00 00 00 00 	movl   $0x0,(%esp)
c033390d:	e9 b4 fb dc ff       	jmp    c01034c6 <invalidate_interrupt+0x36>
c0333912:	c7 04 24 00 00 00 00 	movl   $0x0,(%esp)
c0333919:	e9 a9 fb dc ff       	jmp    c01034c7 <invalidate_interrupt+0x37>
c033391e:	c7 04 24 00 00 00 00 	movl   $0x0,(%esp)
c0333925:	e9 db fb dc ff       	jmp    c0103505 <call_function_interrupt+0x35>
c033392a:	c7 04 24 00 00 00 00 	movl   $0x0,(%esp)
c0333931:	e9 d0 fb dc ff       	jmp    c0103506 <call_function_interrupt+0x36>
c0333936:	c7 04 24 00 00 00 00 	movl   $0x0,(%esp)
c033393d:	e9 c5 fb dc ff       	jmp    c0103507 <call_function_interrupt+0x37>
c0333942:	c7 04 24 00 00 00 00 	movl   $0x0,(%esp)
c0333949:	e9 f7 fb dc ff       	jmp    c0103545 <apic_timer_interrupt+0x35>
c033394e:	c7 04 24 00 00 00 00 	movl   $0x0,(%esp)
c0333955:	e9 ec fb dc ff       	jmp    c0103546 <apic_timer_interrupt+0x36>
c033395a:	c7 04 24 00 00 00 00 	movl   $0x0,(%esp)
c0333961:	e9 e1 fb dc ff       	jmp    c0103547 <apic_timer_interrupt+0x37>
c0333966:	c7 04 24 00 00 00 00 	movl   $0x0,(%esp)
c033396d:	e9 13 fc dc ff       	jmp    c0103585 <error_interrupt+0x35>
c0333972:	c7 04 24 00 00 00 00 	movl   $0x0,(%esp)
c0333979:	e9 08 fc dc ff       	jmp    c0103586 <error_interrupt+0x36>
c033397e:	c7 04 24 00 00 00 00 	movl   $0x0,(%esp)
c0333985:	e9 fd fb dc ff       	jmp    c0103587 <error_interrupt+0x37>
c033398a:	c7 04 24 00 00 00 00 	movl   $0x0,(%esp)
c0333991:	e9 2f fc dc ff       	jmp    c01035c5 <spurious_interrupt+0x35>
c0333996:	c7 04 24 00 00 00 00 	movl   $0x0,(%esp)
c033399d:	e9 24 fc dc ff       	jmp    c01035c6 <spurious_interrupt+0x36>
c03339a2:	c7 04 24 00 00 00 00 	movl   $0x0,(%esp)
c03339a9:	e9 19 fc dc ff       	jmp    c01035c7 <spurious_interrupt+0x37>
c03339ae:	c7 04 24 00 00 00 00 	movl   $0x0,(%esp)
c03339b5:	e9 4b fc dc ff       	jmp    c0103605 <thermal_interrupt+0x35>
c03339ba:	c7 04 24 00 00 00 00 	movl   $0x0,(%esp)
c03339c1:	e9 40 fc dc ff       	jmp    c0103606 <thermal_interrupt+0x36>
c03339c6:	c7 04 24 00 00 00 00 	movl   $0x0,(%esp)
c03339cd:	e9 35 fc dc ff       	jmp    c0103607 <thermal_interrupt+0x37>
c03339d2:	c7 04 24 00 00 00 00 	movl   $0x0,(%esp)
c03339d9:	e9 56 fb ff ff       	jmp    c0333534 <nmi_espfix_stack+0x74>
c03339de:	c7 04 24 00 00 00 00 	movl   $0x0,(%esp)
c03339e5:	e9 4b fb ff ff       	jmp    c0333535 <nmi_espfix_stack+0x75>
c03339ea:	c7 04 24 00 00 00 00 	movl   $0x0,(%esp)
c03339f1:	e9 40 fb ff ff       	jmp    c0333536 <nmi_espfix_stack+0x76>
c03339f6:	ba f2 ff ff ff       	mov    $0xfffffff2,%edx
c03339fb:	30 db                	xor    %bl,%bl
c03339fd:	e9 e0 02 dd ff       	jmp    c0103ce2 <show_registers+0x204>
c0333a02:	ba f2 ff ff ff       	mov    $0xfffffff2,%edx
c0333a07:	30 db                	xor    %bl,%bl
c0333a09:	e9 15 03 dd ff       	jmp    c0103d23 <show_registers+0x245>
c0333a0e:	ba f2 ff ff ff       	mov    $0xfffffff2,%edx
c0333a13:	66 31 db             	xor    %bx,%bx
c0333a16:	e9 bb 06 dd ff       	jmp    c01040d6 <is_valid_bugaddr+0x23>
c0333a1b:	ba f2 ff ff ff       	mov    $0xfffffff2,%edx
c0333a20:	e9 39 1c dd ff       	jmp    c010565e <arch_ptrace+0x3b8>
c0333a25:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c0333a2a:	31 c9                	xor    %ecx,%ecx
c0333a2c:	e9 64 1c dd ff       	jmp    c0105695 <arch_ptrace+0x3ef>
c0333a31:	bb f2 ff ff ff       	mov    $0xfffffff2,%ebx
c0333a36:	e9 88 37 dd ff       	jmp    c01071c3 <sys_olduname+0x5c>
c0333a3b:	bb f2 ff ff ff       	mov    $0xfffffff2,%ebx
c0333a40:	e9 a7 37 dd ff       	jmp    c01071ec <sys_olduname+0x85>
c0333a45:	bb f2 ff ff ff       	mov    $0xfffffff2,%ebx
c0333a4a:	e9 c9 37 dd ff       	jmp    c0107218 <sys_olduname+0xb1>
c0333a4f:	bb f2 ff ff ff       	mov    $0xfffffff2,%ebx
c0333a54:	e9 eb 37 dd ff       	jmp    c0107244 <sys_olduname+0xdd>
c0333a59:	bf f2 ff ff ff       	mov    $0xfffffff2,%edi
c0333a5e:	e9 0b 38 dd ff       	jmp    c010726e <sys_olduname+0x107>
c0333a63:	ba f2 ff ff ff       	mov    $0xfffffff2,%edx
c0333a68:	31 c0                	xor    %eax,%eax
c0333a6a:	e9 e9 3b dd ff       	jmp    c0107658 <convert_fxsr_from_user+0x97>
c0333a6f:	ba f2 ff ff ff       	mov    $0xfffffff2,%edx
c0333a74:	31 c0                	xor    %eax,%eax
c0333a76:	e9 e7 3b dd ff       	jmp    c0107662 <convert_fxsr_from_user+0xa1>
c0333a7b:	ba f2 ff ff ff       	mov    $0xfffffff2,%edx
c0333a80:	66 31 c0             	xor    %ax,%ax
c0333a83:	e9 e6 3b dd ff       	jmp    c010766e <convert_fxsr_from_user+0xad>
c0333a88:	b9 f2 ff ff ff       	mov    $0xfffffff2,%ecx
c0333a8d:	e9 0a 3d dd ff       	jmp    c010779c <convert_fxsr_to_user+0x106>
c0333a92:	b9 f2 ff ff ff       	mov    $0xfffffff2,%ecx
c0333a97:	e9 0b 3d dd ff       	jmp    c01077a7 <convert_fxsr_to_user+0x111>
c0333a9c:	b9 f2 ff ff ff       	mov    $0xfffffff2,%ecx
c0333aa1:	e9 0e 3d dd ff       	jmp    c01077b4 <convert_fxsr_to_user+0x11e>
c0333aa6:	b9 f2 ff ff ff       	mov    $0xfffffff2,%ecx
c0333aab:	e9 b7 3f dd ff       	jmp    c0107a67 <save_i387+0x9c>
c0333ab0:	ba f2 ff ff ff       	mov    $0xfffffff2,%edx
c0333ab5:	e9 b5 3f dd ff       	jmp    c0107a6f <save_i387+0xa4>
c0333aba:	b9 f2 ff ff ff       	mov    $0xfffffff2,%ecx
c0333abf:	66 31 f6             	xor    %si,%si
c0333ac2:	e9 61 42 dd ff       	jmp    c0107d28 <romsignature+0x1c>
c0333ac7:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c0333acc:	e9 b5 6d dd ff       	jmp    c010a886 <mtrr_wrmsr+0x13>
c0333ad1:	6a 00                	push   $0x0
c0333ad3:	0f a1                	pop    %fs
c0333ad5:	e9 13 c1 dd ff       	jmp    c010fbed <save_v86_state+0x129>
c0333ada:	ba f2 ff ff ff       	mov    $0xfffffff2,%edx
c0333adf:	30 db                	xor    %bl,%bl
c0333ae1:	e9 40 d5 dd ff       	jmp    c0111026 <__is_prefetch+0x156>
c0333ae6:	ba f2 ff ff ff       	mov    $0xfffffff2,%edx
c0333aeb:	30 c9                	xor    %cl,%cl
c0333aed:	e9 a5 d5 dd ff       	jmp    c0111097 <__is_prefetch+0x1c7>
c0333af2:	bf f2 ff ff ff       	mov    $0xfffffff2,%edi
c0333af7:	e9 c8 55 de ff       	jmp    c01190c4 <do_syslog+0x131>
c0333afc:	bf f2 ff ff ff       	mov    $0xfffffff2,%edi
c0333b01:	e9 b7 56 de ff       	jmp    c01191bd <do_syslog+0x22a>
c0333b06:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c0333b0b:	30 d2                	xor    %dl,%dl
c0333b0d:	e9 fd 56 de ff       	jmp    c011920f <do_syslog+0x27c>
c0333b12:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c0333b17:	e9 fd 56 de ff       	jmp    c0119219 <do_syslog+0x286>
c0333b1c:	bd f2 ff ff ff       	mov    $0xfffffff2,%ebp
c0333b21:	e9 92 d7 de ff       	jmp    c01212b8 <copy_siginfo_to_user+0x4e>
c0333b26:	be f2 ff ff ff       	mov    $0xfffffff2,%esi
c0333b2b:	e9 90 d7 de ff       	jmp    c01212c0 <copy_siginfo_to_user+0x56>
c0333b30:	be f2 ff ff ff       	mov    $0xfffffff2,%esi
c0333b35:	e9 90 d7 de ff       	jmp    c01212ca <copy_siginfo_to_user+0x60>
c0333b3a:	ba f2 ff ff ff       	mov    $0xfffffff2,%edx
c0333b3f:	e9 dc d7 de ff       	jmp    c0121320 <copy_siginfo_to_user+0xb6>
c0333b44:	be f2 ff ff ff       	mov    $0xfffffff2,%esi
c0333b49:	e9 da d7 de ff       	jmp    c0121328 <copy_siginfo_to_user+0xbe>
c0333b4e:	ba f2 ff ff ff       	mov    $0xfffffff2,%edx
c0333b53:	e9 da d7 de ff       	jmp    c0121332 <copy_siginfo_to_user+0xc8>
c0333b58:	be f2 ff ff ff       	mov    $0xfffffff2,%esi
c0333b5d:	e9 d8 d7 de ff       	jmp    c012133a <copy_siginfo_to_user+0xd0>
c0333b62:	b9 f2 ff ff ff       	mov    $0xfffffff2,%ecx
c0333b67:	e9 d6 d7 de ff       	jmp    c0121342 <copy_siginfo_to_user+0xd8>
c0333b6c:	ba f2 ff ff ff       	mov    $0xfffffff2,%edx
c0333b71:	e9 dd d7 de ff       	jmp    c0121353 <copy_siginfo_to_user+0xe9>
c0333b76:	be f2 ff ff ff       	mov    $0xfffffff2,%esi
c0333b7b:	e9 db d7 de ff       	jmp    c012135b <copy_siginfo_to_user+0xf1>
c0333b80:	be f2 ff ff ff       	mov    $0xfffffff2,%esi
c0333b85:	e9 dd d7 de ff       	jmp    c0121367 <copy_siginfo_to_user+0xfd>
c0333b8a:	ba f2 ff ff ff       	mov    $0xfffffff2,%edx
c0333b8f:	e9 dd d7 de ff       	jmp    c0121371 <copy_siginfo_to_user+0x107>
c0333b94:	be f2 ff ff ff       	mov    $0xfffffff2,%esi
c0333b99:	e9 db d7 de ff       	jmp    c0121379 <copy_siginfo_to_user+0x10f>
c0333b9e:	ba f2 ff ff ff       	mov    $0xfffffff2,%edx
c0333ba3:	e9 db d7 de ff       	jmp    c0121383 <copy_siginfo_to_user+0x119>
c0333ba8:	ba f2 ff ff ff       	mov    $0xfffffff2,%edx
c0333bad:	e9 db d7 de ff       	jmp    c012138d <copy_siginfo_to_user+0x123>
c0333bb2:	b9 f2 ff ff ff       	mov    $0xfffffff2,%ecx
c0333bb7:	e9 d9 d7 de ff       	jmp    c0121395 <copy_siginfo_to_user+0x12b>
c0333bbc:	b9 f2 ff ff ff       	mov    $0xfffffff2,%ecx
c0333bc1:	e9 db d7 de ff       	jmp    c01213a1 <copy_siginfo_to_user+0x137>
c0333bc6:	be f2 ff ff ff       	mov    $0xfffffff2,%esi
c0333bcb:	e9 d9 d7 de ff       	jmp    c01213a9 <copy_siginfo_to_user+0x13f>
c0333bd0:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c0333bd5:	e9 d7 d7 de ff       	jmp    c01213b1 <copy_siginfo_to_user+0x147>
c0333bda:	b9 f2 ff ff ff       	mov    $0xfffffff2,%ecx
c0333bdf:	e9 db d7 de ff       	jmp    c01213bf <copy_siginfo_to_user+0x155>
c0333be4:	be f2 ff ff ff       	mov    $0xfffffff2,%esi
c0333be9:	e9 d9 d7 de ff       	jmp    c01213c7 <copy_siginfo_to_user+0x15d>
c0333bee:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c0333bf3:	31 ed                	xor    %ebp,%ebp
c0333bf5:	e9 9e e9 de ff       	jmp    c0122598 <do_sigaltstack+0x6f>
c0333bfa:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c0333bff:	31 f6                	xor    %esi,%esi
c0333c01:	e9 99 e9 de ff       	jmp    c012259f <do_sigaltstack+0x76>
c0333c06:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c0333c0b:	31 db                	xor    %ebx,%ebx
c0333c0d:	e9 94 e9 de ff       	jmp    c01225a6 <do_sigaltstack+0x7d>
c0333c12:	b8 04 00 00 00       	mov    $0x4,%eax
c0333c17:	31 c9                	xor    %ecx,%ecx
c0333c19:	e9 41 85 df ff       	jmp    c012c15f <futex_requeue+0x9b>
c0333c1e:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c0333c23:	e9 90 87 df ff       	jmp    c012c3b8 <handle_futex_death+0x52>
c0333c28:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c0333c2d:	e9 8c 8a df ff       	jmp    c012c6be <futex_lock_pi+0x164>
c0333c32:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c0333c37:	e9 ea 8a df ff       	jmp    c012c726 <futex_lock_pi+0x1cc>
c0333c3c:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c0333c41:	e9 2e 8d df ff       	jmp    c012c974 <futex_lock_pi+0x41a>
c0333c46:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c0333c4b:	e9 8a 8f df ff       	jmp    c012cbda <futex_lock_pi+0x680>
c0333c50:	b8 04 00 00 00       	mov    $0x4,%eax
c0333c55:	31 c9                	xor    %ecx,%ecx
c0333c57:	e9 be 91 df ff       	jmp    c012ce1a <do_futex+0xef>
c0333c5c:	ba f2 ff ff ff       	mov    $0xfffffff2,%edx
c0333c61:	e9 0b 96 df ff       	jmp    c012d271 <do_futex+0x546>
c0333c66:	ba f2 ff ff ff       	mov    $0xfffffff2,%edx
c0333c6b:	e9 29 96 df ff       	jmp    c012d299 <do_futex+0x56e>
c0333c70:	bb f2 ff ff ff       	mov    $0xfffffff2,%ebx
c0333c75:	e9 33 96 df ff       	jmp    c012d2ad <do_futex+0x582>
c0333c7a:	bb f2 ff ff ff       	mov    $0xfffffff2,%ebx
c0333c7f:	e9 3b 96 df ff       	jmp    c012d2bf <do_futex+0x594>
c0333c84:	bb f2 ff ff ff       	mov    $0xfffffff2,%ebx
c0333c89:	e9 41 96 df ff       	jmp    c012d2cf <do_futex+0x5a4>
c0333c8e:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c0333c93:	e9 ce 98 df ff       	jmp    c012d566 <do_futex+0x83b>
c0333c98:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c0333c9d:	e9 b7 99 df ff       	jmp    c012d659 <do_futex+0x92e>
c0333ca2:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c0333ca7:	e9 e4 9a df ff       	jmp    c012d790 <do_futex+0xa65>
c0333cac:	bb f2 ff ff ff       	mov    $0xfffffff2,%ebx
c0333cb1:	e9 86 7d e0 ff       	jmp    c013ba3c <file_read_actor+0x28>
c0333cb6:	bb f2 ff ff ff       	mov    $0xfffffff2,%ebx
c0333cbb:	e9 99 7d e0 ff       	jmp    c013ba59 <file_read_actor+0x45>
c0333cc0:	bb f2 ff ff ff       	mov    $0xfffffff2,%ebx
c0333cc5:	30 c0                	xor    %al,%al
c0333cc7:	e9 fb 90 e0 ff       	jmp    c013cdc7 <generic_file_buffered_write+0x122>
c0333ccc:	bb f2 ff ff ff       	mov    $0xfffffff2,%ebx
c0333cd1:	30 c0                	xor    %al,%al
c0333cd3:	e9 17 91 e0 ff       	jmp    c013cdef <generic_file_buffered_write+0x14a>
c0333cd8:	ba f2 ff ff ff       	mov    $0xfffffff2,%edx
c0333cdd:	30 c0                	xor    %al,%al
c0333cdf:	e9 d8 ef e1 ff       	jmp    c0152cbc <kmem_cache_create+0x90>
c0333ce4:	bb f2 ff ff ff       	mov    $0xfffffff2,%ebx
c0333ce9:	30 c0                	xor    %al,%al
c0333ceb:	e9 d5 55 e2 ff       	jmp    c01592c5 <iov_fault_in_pages_read+0x29>
c0333cf0:	bb f2 ff ff ff       	mov    $0xfffffff2,%ebx
c0333cf5:	30 c0                	xor    %al,%al
c0333cf7:	e9 e9 55 e2 ff       	jmp    c01592e5 <iov_fault_in_pages_read+0x49>
c0333cfc:	bb f2 ff ff ff       	mov    $0xfffffff2,%ebx
c0333d01:	e9 7d 62 e2 ff       	jmp    c0159f83 <pipe_read+0xe7>
c0333d06:	bb f2 ff ff ff       	mov    $0xfffffff2,%ebx
c0333d0b:	e9 99 62 e2 ff       	jmp    c0159fa9 <pipe_read+0x10d>
c0333d10:	bb f2 ff ff ff       	mov    $0xfffffff2,%ebx
c0333d15:	e9 d0 a7 e2 ff       	jmp    c015e4ea <filldir64+0x46>
c0333d1a:	be f2 ff ff ff       	mov    $0xfffffff2,%esi
c0333d1f:	e9 db a7 e2 ff       	jmp    c015e4ff <filldir64+0x5b>
c0333d24:	be f2 ff ff ff       	mov    $0xfffffff2,%esi
c0333d29:	e9 e1 a7 e2 ff       	jmp    c015e50f <filldir64+0x6b>
c0333d2e:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c0333d33:	e9 e1 a7 e2 ff       	jmp    c015e519 <filldir64+0x75>
c0333d38:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c0333d3d:	e9 e2 a7 e2 ff       	jmp    c015e524 <filldir64+0x80>
c0333d42:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c0333d47:	e9 f7 a7 e2 ff       	jmp    c015e543 <filldir64+0x9f>
c0333d4c:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c0333d51:	e9 67 a8 e2 ff       	jmp    c015e5bd <filldir+0x54>
c0333d56:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c0333d5b:	e9 67 a8 e2 ff       	jmp    c015e5c7 <filldir+0x5e>
c0333d60:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c0333d65:	e9 65 a8 e2 ff       	jmp    c015e5cf <filldir+0x66>
c0333d6a:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c0333d6f:	e9 7a a8 e2 ff       	jmp    c015e5ee <filldir+0x85>
c0333d74:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c0333d79:	e9 7c a8 e2 ff       	jmp    c015e5fa <filldir+0x91>
c0333d7e:	bf f2 ff ff ff       	mov    $0xfffffff2,%edi
c0333d83:	e9 91 a9 e2 ff       	jmp    c015e719 <sys_getdents64+0x83>
c0333d88:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c0333d8d:	e9 6f aa e2 ff       	jmp    c015e801 <fillonedir+0x78>
c0333d92:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c0333d97:	e9 70 aa e2 ff       	jmp    c015e80c <fillonedir+0x83>
c0333d9c:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c0333da1:	e9 6e aa e2 ff       	jmp    c015e814 <fillonedir+0x8b>
c0333da6:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c0333dab:	e9 81 aa e2 ff       	jmp    c015e831 <fillonedir+0xa8>
c0333db0:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c0333db5:	e9 4c ae e2 ff       	jmp    c015ec06 <do_sys_poll+0x29c>
c0333dba:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c0333dbf:	31 db                	xor    %ebx,%ebx
c0333dc1:	e9 a4 b7 e2 ff       	jmp    c015f56a <sys_pselect6+0x2c>
c0333dc6:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c0333dcb:	31 d2                	xor    %edx,%edx
c0333dcd:	e9 9f b7 e2 ff       	jmp    c015f571 <sys_pselect6+0x33>
c0333dd2:	be f2 ff ff ff       	mov    $0xfffffff2,%esi
c0333dd7:	30 c0                	xor    %al,%al
c0333dd9:	e9 65 21 e3 ff       	jmp    c0165f43 <copy_mount_options+0x92>
c0333dde:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c0333de3:	31 ff                	xor    %edi,%edi
c0333de5:	e9 04 52 e3 ff       	jmp    c0168fee <sys_io_submit+0x59>
c0333dea:	bb f2 ff ff ff       	mov    $0xfffffff2,%ebx
c0333def:	e9 2a 35 e4 ff       	jmp    c017731e <sys_epoll_wait+0x279>
c0333df4:	bb f2 ff ff ff       	mov    $0xfffffff2,%ebx
c0333df9:	e9 35 35 e4 ff       	jmp    c0177333 <sys_epoll_wait+0x28e>
c0333dfe:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c0333e03:	e9 0d 75 e4 ff       	jmp    c017b315 <load_elf_binary+0xfcc>
c0333e08:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c0333e0d:	e9 18 75 e4 ff       	jmp    c017b32a <load_elf_binary+0xfe1>
c0333e12:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c0333e17:	e9 21 75 e4 ff       	jmp    c017b33d <load_elf_binary+0xff4>
c0333e1c:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c0333e21:	e9 49 75 e4 ff       	jmp    c017b36f <load_elf_binary+0x1026>
c0333e26:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c0333e2b:	e9 75 75 e4 ff       	jmp    c017b3a5 <load_elf_binary+0x105c>
c0333e30:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c0333e35:	e9 99 75 e4 ff       	jmp    c017b3d3 <load_elf_binary+0x108a>
c0333e3a:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c0333e3f:	e9 c3 75 e4 ff       	jmp    c017b407 <load_elf_binary+0x10be>
c0333e44:	be f2 ff ff ff       	mov    $0xfffffff2,%esi
c0333e49:	30 c0                	xor    %al,%al
c0333e4b:	e9 0b f9 e5 ff       	jmp    c019375b <reiserfs_file_write+0x16df>
c0333e50:	be f2 ff ff ff       	mov    $0xfffffff2,%esi
c0333e55:	30 c0                	xor    %al,%al
c0333e57:	e9 24 f9 e5 ff       	jmp    c0193780 <reiserfs_file_write+0x1704>
c0333e5c:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c0333e61:	30 d2                	xor    %dl,%dl
c0333e63:	e9 48 84 ed ff       	jmp    c020c2b0 <__bitmap_parse+0x90>
c0333e68:	8b 5c 24 20          	mov    0x20(%esp),%ebx
c0333e6c:	c7 03 f2 ff ff ff    	movl   $0xfffffff2,(%ebx)
c0333e72:	8b 7c 24 14          	mov    0x14(%esp),%edi
c0333e76:	8b 4c 24 18          	mov    0x18(%esp),%ecx
c0333e7a:	31 c0                	xor    %eax,%eax
c0333e7c:	f3 aa                	rep stos %al,%es:(%edi)
c0333e7e:	e9 21 cb ed ff       	jmp    c02109a4 <csum_partial_copy_generic+0xf4>
c0333e83:	8b 5c 24 24          	mov    0x24(%esp),%ebx
c0333e87:	c7 03 f2 ff ff ff    	movl   $0xfffffff2,(%ebx)
c0333e8d:	e9 12 cb ed ff       	jmp    c02109a4 <csum_partial_copy_generic+0xf4>
c0333e92:	ba f2 ff ff ff       	mov    $0xfffffff2,%edx
c0333e97:	e9 33 cd ed ff       	jmp    c0210bcf <__strncpy_from_user+0x17>
c0333e9c:	8d 0c 8a             	lea    (%edx,%ecx,4),%ecx
c0333e9f:	e9 43 cd ed ff       	jmp    c0210be7 <__clear_user+0x13>
c0333ea4:	8d 0c 88             	lea    (%eax,%ecx,4),%ecx
c0333ea7:	e9 04 ce ed ff       	jmp    c0210cb0 <__copy_from_user_ll_nocache_nozero+0xc5>
c0333eac:	01 c1                	add    %eax,%ecx
c0333eae:	e9 1f ce ed ff       	jmp    c0210cd2 <__copy_from_user_ll_nocache_nozero+0xe7>
c0333eb3:	8d 0c 88             	lea    (%eax,%ecx,4),%ecx
c0333eb6:	e9 17 ce ed ff       	jmp    c0210cd2 <__copy_from_user_ll_nocache_nozero+0xe7>
c0333ebb:	8d 0c 88             	lea    (%eax,%ecx,4),%ecx
c0333ebe:	e9 c0 ce ed ff       	jmp    c0210d83 <__copy_from_user_ll_nozero+0xac>
c0333ec3:	01 c1                	add    %eax,%ecx
c0333ec5:	e9 dc ce ed ff       	jmp    c0210da6 <__copy_from_user_ll_nozero+0xcf>
c0333eca:	8d 0c 88             	lea    (%eax,%ecx,4),%ecx
c0333ecd:	e9 d4 ce ed ff       	jmp    c0210da6 <__copy_from_user_ll_nozero+0xcf>
c0333ed2:	8d 0c 88             	lea    (%eax,%ecx,4),%ecx
c0333ed5:	51                   	push   %ecx
c0333ed6:	50                   	push   %eax
c0333ed7:	31 c0                	xor    %eax,%eax
c0333ed9:	f3 aa                	rep stos %al,%es:(%edi)
c0333edb:	58                   	pop    %eax
c0333edc:	59                   	pop    %ecx
c0333edd:	e9 75 cf ed ff       	jmp    c0210e57 <__copy_from_user_ll+0xac>
c0333ee2:	01 c1                	add    %eax,%ecx
c0333ee4:	eb 03                	jmp    c0333ee9 <iret_exc+0x641>
c0333ee6:	8d 0c 88             	lea    (%eax,%ecx,4),%ecx
c0333ee9:	51                   	push   %ecx
c0333eea:	50                   	push   %eax
c0333eeb:	31 c0                	xor    %eax,%eax
c0333eed:	f3 aa                	rep stos %al,%es:(%edi)
c0333eef:	58                   	pop    %eax
c0333ef0:	59                   	pop    %ecx
c0333ef1:	e9 84 cf ed ff       	jmp    c0210e7a <__copy_from_user_ll+0xcf>
c0333ef6:	8d 0c 88             	lea    (%eax,%ecx,4),%ecx
c0333ef9:	e9 2d d0 ed ff       	jmp    c0210f2b <__copy_to_user_ll+0xac>
c0333efe:	01 c1                	add    %eax,%ecx
c0333f00:	e9 49 d0 ed ff       	jmp    c0210f4e <__copy_to_user_ll+0xcf>
c0333f05:	8d 0c 88             	lea    (%eax,%ecx,4),%ecx
c0333f08:	e9 41 d0 ed ff       	jmp    c0210f4e <__copy_to_user_ll+0xcf>
c0333f0d:	8d 0c 88             	lea    (%eax,%ecx,4),%ecx
c0333f10:	51                   	push   %ecx
c0333f11:	50                   	push   %eax
c0333f12:	31 c0                	xor    %eax,%eax
c0333f14:	f3 aa                	rep stos %al,%es:(%edi)
c0333f16:	58                   	pop    %eax
c0333f17:	59                   	pop    %ecx
c0333f18:	e9 4d d1 ed ff       	jmp    c021106a <__copy_from_user_ll_nocache+0xc5>
c0333f1d:	01 c1                	add    %eax,%ecx
c0333f1f:	eb 03                	jmp    c0333f24 <iret_exc+0x67c>
c0333f21:	8d 0c 88             	lea    (%eax,%ecx,4),%ecx
c0333f24:	51                   	push   %ecx
c0333f25:	50                   	push   %eax
c0333f26:	31 c0                	xor    %eax,%eax
c0333f28:	f3 aa                	rep stos %al,%es:(%edi)
c0333f2a:	58                   	pop    %eax
c0333f2b:	59                   	pop    %ecx
c0333f2c:	e9 5b d1 ed ff       	jmp    c021108c <__copy_from_user_ll_nocache+0xe7>
c0333f31:	ba f2 ff ff ff       	mov    $0xfffffff2,%edx
c0333f36:	e9 89 d1 ed ff       	jmp    c02110c4 <strncpy_from_user+0x33>
c0333f3b:	8d 0c 8b             	lea    (%ebx,%ecx,4),%ecx
c0333f3e:	e9 b4 d1 ed ff       	jmp    c02110f7 <clear_user+0x2d>
c0333f43:	31 c0                	xor    %eax,%eax
c0333f45:	e9 e1 d1 ed ff       	jmp    c021112b <strnlen_user+0x2f>
c0333f4a:	b0 01                	mov    $0x1,%al
c0333f4c:	e9 da d1 ed ff       	jmp    c021112b <strnlen_user+0x2f>
c0333f51:	bb f2 ff ff ff       	mov    $0xfffffff2,%ebx
c0333f56:	e9 8f 6a ee ff       	jmp    c021a9ea <proc_bus_pci_read+0xba>
c0333f5b:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c0333f60:	e9 af 6a ee ff       	jmp    c021aa14 <proc_bus_pci_read+0xe4>
c0333f65:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c0333f6a:	e9 c5 6a ee ff       	jmp    c021aa34 <proc_bus_pci_read+0x104>
c0333f6f:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c0333f74:	e9 e4 6a ee ff       	jmp    c021aa5d <proc_bus_pci_read+0x12d>
c0333f79:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c0333f7e:	e9 fc 6a ee ff       	jmp    c021aa7f <proc_bus_pci_read+0x14f>
c0333f83:	ba f2 ff ff ff       	mov    $0xfffffff2,%edx
c0333f88:	30 c9                	xor    %cl,%cl
c0333f8a:	e9 81 6b ee ff       	jmp    c021ab10 <proc_bus_pci_write+0x77>
c0333f8f:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c0333f94:	66 31 c9             	xor    %cx,%cx
c0333f97:	e9 98 6b ee ff       	jmp    c021ab34 <proc_bus_pci_write+0x9b>
c0333f9c:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c0333fa1:	31 c9                	xor    %ecx,%ecx
c0333fa3:	e9 a8 6b ee ff       	jmp    c021ab50 <proc_bus_pci_write+0xb7>
c0333fa8:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c0333fad:	66 31 c9             	xor    %cx,%cx
c0333fb0:	e9 bd 6b ee ff       	jmp    c021ab72 <proc_bus_pci_write+0xd9>
c0333fb5:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c0333fba:	30 c9                	xor    %cl,%cl
c0333fbc:	e9 cf 6b ee ff       	jmp    c021ab90 <proc_bus_pci_write+0xf7>
c0333fc1:	ba f2 ff ff ff       	mov    $0xfffffff2,%edx
c0333fc6:	30 c0                	xor    %al,%al
c0333fc8:	e9 25 76 ef ff       	jmp    c022b5f2 <acpi_os_readable+0xb>
c0333fcd:	ba f2 ff ff ff       	mov    $0xfffffff2,%edx
c0333fd2:	30 c0                	xor    %al,%al
c0333fd4:	e9 23 76 ef ff       	jmp    c022b5fc <acpi_os_readable+0x15>
c0333fd9:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c0333fde:	e9 7f 7f f1 ff       	jmp    c024bf62 <read_port+0x42>
c0333fe3:	ba f2 ff ff ff       	mov    $0xfffffff2,%edx
c0333fe8:	30 c0                	xor    %al,%al
c0333fea:	e9 e8 7f f1 ff       	jmp    c024bfd7 <write_port+0x44>
c0333fef:	ba f2 ff ff ff       	mov    $0xfffffff2,%edx
c0333ff4:	66 31 c0             	xor    %ax,%ax
c0333ff7:	e9 08 07 f2 ff       	jmp    c0254704 <vt_ioctl+0x1006>
c0333ffc:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c0334001:	66 31 c9             	xor    %cx,%cx
c0334004:	e9 06 07 f2 ff       	jmp    c025470f <vt_ioctl+0x1011>
c0334009:	ba f2 ff ff ff       	mov    $0xfffffff2,%edx
c033400e:	66 31 c0             	xor    %ax,%ax
c0334011:	e9 03 07 f2 ff       	jmp    c0254719 <vt_ioctl+0x101b>
c0334016:	ba f2 ff ff ff       	mov    $0xfffffff2,%edx
c033401b:	66 31 c0             	xor    %ax,%ax
c033401e:	e9 01 07 f2 ff       	jmp    c0254724 <vt_ioctl+0x1026>
c0334023:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c0334028:	66 31 c9             	xor    %cx,%cx
c033402b:	e9 fc 06 f2 ff       	jmp    c025472c <vt_ioctl+0x102e>
c0334030:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c0334035:	66 31 db             	xor    %bx,%bx
c0334038:	e9 f5 06 f2 ff       	jmp    c0254732 <vt_ioctl+0x1034>
c033403d:	b9 f2 ff ff ff       	mov    $0xfffffff2,%ecx
c0334042:	e9 54 15 f2 ff       	jmp    c025559b <con_get_unimap+0x9f>
c0334047:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c033404c:	e9 53 15 f2 ff       	jmp    c02555a4 <con_get_unimap+0xa8>
c0334051:	ba f2 ff ff ff       	mov    $0xfffffff2,%edx
c0334056:	e9 8d 15 f2 ff       	jmp    c02555e8 <con_get_unimap+0xec>
c033405b:	b9 f2 ff ff ff       	mov    $0xfffffff2,%ecx
c0334060:	66 31 d2             	xor    %dx,%dx
c0334063:	e9 65 1c f2 ff       	jmp    c0255ccd <con_set_unimap+0x118>
c0334068:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c033406d:	66 31 c9             	xor    %cx,%cx
c0334070:	e9 5c 1c f2 ff       	jmp    c0255cd1 <con_set_unimap+0x11c>
c0334075:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c033407a:	e9 00 1d f2 ff       	jmp    c0255d7f <con_get_trans_new+0x32>
c033407f:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c0334084:	30 d2                	xor    %dl,%dl
c0334086:	e9 30 1d f2 ff       	jmp    c0255dbb <con_set_trans_old+0x2a>
c033408b:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c0334090:	e9 9c 1d f2 ff       	jmp    c0255e31 <con_get_trans_old+0x51>
c0334095:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c033409a:	66 31 d2             	xor    %dx,%dx
c033409d:	e9 cb 1d f2 ff       	jmp    c0255e6d <con_set_trans_new+0x2b>
c03340a2:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c03340a7:	66 31 f6             	xor    %si,%si
c03340aa:	e9 8e 1f f2 ff       	jmp    c025603d <set_selection+0x48>
c03340af:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c03340b4:	66 31 c9             	xor    %cx,%cx
c03340b7:	e9 8b 1f f2 ff       	jmp    c0256047 <set_selection+0x52>
c03340bc:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c03340c1:	66 31 f6             	xor    %si,%si
c03340c4:	e9 84 1f f2 ff       	jmp    c025604d <set_selection+0x58>
c03340c9:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c03340ce:	66 31 f6             	xor    %si,%si
c03340d1:	e9 81 1f f2 ff       	jmp    c0256057 <set_selection+0x62>
c03340d6:	ba f2 ff ff ff       	mov    $0xfffffff2,%edx
c03340db:	66 31 c0             	xor    %ax,%ax
c03340de:	e9 7c 1f f2 ff       	jmp    c025605f <set_selection+0x6a>
c03340e3:	bb f2 ff ff ff       	mov    $0xfffffff2,%ebx
c03340e8:	e9 23 7c f2 ff       	jmp    c025bd10 <tioclinux+0xa3>
c03340ed:	bb f2 ff ff ff       	mov    $0xfffffff2,%ebx
c03340f2:	e9 3c 7c f2 ff       	jmp    c025bd33 <tioclinux+0xc6>
c03340f7:	bb f2 ff ff ff       	mov    $0xfffffff2,%ebx
c03340fc:	e9 6a 7c f2 ff       	jmp    c025bd6b <tioclinux+0xfe>
c0334101:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c0334106:	e9 a2 ca f5 ff       	jmp    c0290bad <scsi_ioctl+0x10a>
c033410b:	bf f2 ff ff ff       	mov    $0xfffffff2,%edi
c0334110:	e9 a1 ca f5 ff       	jmp    c0290bb6 <scsi_ioctl+0x113>
c0334115:	be f2 ff ff ff       	mov    $0xfffffff2,%esi
c033411a:	30 d2                	xor    %dl,%dl
c033411c:	e9 b2 01 f7 ff       	jmp    c02a42d3 <sg_write+0x100>
c0334121:	bf f2 ff ff ff       	mov    $0xfffffff2,%edi
c0334126:	e9 06 07 f7 ff       	jmp    c02a4831 <sg_ioctl+0x3f9>
c033412b:	bf f2 ff ff ff       	mov    $0xfffffff2,%edi
c0334130:	e9 04 07 f7 ff       	jmp    c02a4839 <sg_ioctl+0x401>
c0334135:	bf f2 ff ff ff       	mov    $0xfffffff2,%edi
c033413a:	e9 02 07 f7 ff       	jmp    c02a4841 <sg_ioctl+0x409>
c033413f:	bf f2 ff ff ff       	mov    $0xfffffff2,%edi
c0334144:	e9 00 07 f7 ff       	jmp    c02a4849 <sg_ioctl+0x411>
c0334149:	bf f2 ff ff ff       	mov    $0xfffffff2,%edi
c033414e:	e9 ff 06 f7 ff       	jmp    c02a4852 <sg_ioctl+0x41a>
c0334153:	b9 f2 ff ff ff       	mov    $0xfffffff2,%ecx
c0334158:	e9 01 07 f7 ff       	jmp    c02a485e <sg_ioctl+0x426>
c033415d:	bf f2 ff ff ff       	mov    $0xfffffff2,%edi
c0334162:	e9 00 07 f7 ff       	jmp    c02a4867 <sg_ioctl+0x42f>
c0334167:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c033416c:	e9 ff 06 f7 ff       	jmp    c02a4870 <sg_ioctl+0x438>
c0334171:	bb f2 ff ff ff       	mov    $0xfffffff2,%ebx
c0334176:	e9 fc 06 f7 ff       	jmp    c02a4877 <sg_ioctl+0x43f>
c033417b:	bb f2 ff ff ff       	mov    $0xfffffff2,%ebx
c0334180:	e9 76 07 f7 ff       	jmp    c02a48fb <sg_ioctl+0x4c3>
c0334185:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c033418a:	e9 32 09 f7 ff       	jmp    c02a4ac1 <sg_ioctl+0x689>
c033418f:	ba f2 ff ff ff       	mov    $0xfffffff2,%edx
c0334194:	31 db                	xor    %ebx,%ebx
c0334196:	e9 f8 6d 10 00       	jmp    c043af93 <pci_pcbios_init+0x31>
c033419b:	6a 00                	push   $0x0
c033419d:	07                   	pop    %es
c033419e:	e9 e7 c5 f9 ff       	jmp    c02d078a <__restore_processor_state+0x26>
c03341a3:	6a 00                	push   $0x0
c03341a5:	0f a1                	pop    %fs
c03341a7:	e9 e1 c5 f9 ff       	jmp    c02d078d <__restore_processor_state+0x29>
c03341ac:	6a 00                	push   $0x0
c03341ae:	0f a9                	pop    %gs
c03341b0:	e9 db c5 f9 ff       	jmp    c02d0790 <__restore_processor_state+0x2c>
c03341b5:	6a 00                	push   $0x0
c03341b7:	17                   	pop    %ss
c03341b8:	e9 d6 c5 f9 ff       	jmp    c02d0793 <__restore_processor_state+0x2f>
c03341bd:	ba f2 ff ff ff       	mov    $0xfffffff2,%edx
c03341c2:	e9 88 cd f9 ff       	jmp    c02d0f4f <rthal_strncpy_from_user+0x17>
c03341c7:	ba f2 ff ff ff       	mov    $0xfffffff2,%edx
c03341cc:	e9 b6 e4 f9 ff       	jmp    c02d2687 <move_addr_to_user+0x61>
c03341d1:	ba f2 ff ff ff       	mov    $0xfffffff2,%edx
c03341d6:	e9 1e e6 f9 ff       	jmp    c02d27f9 <sys_recvmsg+0x16b>
c03341db:	ba f2 ff ff ff       	mov    $0xfffffff2,%edx
c03341e0:	e9 2d e6 f9 ff       	jmp    c02d2812 <sys_recvmsg+0x184>
c03341e5:	b8 f2 ff ff ff       	mov    $0xfffffff2,%eax
c03341ea:	30 c9                	xor    %cl,%cl
c03341ec:	e9 85 cc ff ff       	jmp    c0330e76 <proc_dodebug+0x67>
Disassembly of section .init.text:

c041a000 <no_halt>:
c041a000:	c6 05 05 1c 41 c0 00 	movb   $0x0,0xc0411c05
c041a007:	b8 01 00 00 00       	mov    $0x1,%eax
c041a00c:	c3                   	ret    

c041a00d <mca_pentium>:
c041a00d:	c7 05 74 4a 45 c0 01 	movl   $0x1,0xc0454a74
c041a014:	00 00 00 
c041a017:	b8 01 00 00 00       	mov    $0x1,%eax
c041a01c:	c3                   	ret    

c041a01d <no_387>:
c041a01d:	c6 05 06 1c 41 c0 00 	movb   $0x0,0xc0411c06
c041a024:	0f 20 c0             	mov    %cr0,%eax
c041a027:	83 c8 0e             	or     $0xe,%eax
c041a02a:	0f 22 c0             	mov    %eax,%cr0
c041a02d:	b8 01 00 00 00       	mov    $0x1,%eax
c041a032:	c3                   	ret    

c041a033 <nosmp>:
c041a033:	c7 05 28 53 3d c0 00 	movl   $0x0,0xc03d5328
c041a03a:	00 00 00 
c041a03d:	b8 01 00 00 00       	mov    $0x1,%eax
c041a042:	c3                   	ret    


 


----- Original Nachricht ----
Von:     Philippe Gerum <rpm@xenomai.org>
An:      "M. Koehrer" <mathias_koehrer@domain.hid>
Datum:   27.04.2007 17:36
Betreff: Re: [Xenomai-help] Xenomai and MSI enabled crashes kernel

> On Fri, 2007-04-27 at 17:10 +0200, M. Koehrer wrote:
> > Hi Philippe,
> > 
> > here is the next result (I have switched off the "quiet" kernel parameter
> to get everything).
> > 
> 
> Thanks, I will look at this output asap. On your side, please run
> $ objdump -d vmlinux > foo
> 
> then search for the kernel routine embodying the text address 0xc03e5680
> in the dump file (leftmost column). I'd be interested to see the
> disassembly of the entire routine.
> 
> > IRQ 219 vectored at #e9
> > BUG: unable to handle kernel paging request at virtual address 511203b2
> >  printing eip:
> > c03e5680
> > *pde = 00000000
> > Oops: 0002 [#1]
> > SMP 
> > Modules linked in: e1000
> > CPU:    0
> > EIP:    0060:[<c03e5680>]    Not tainted VLI
> > EFLAGS: 00010092   (2.6.20.4 #18)
> > EIP is at 0xc03e5680
> > eax: c011226c   ebx: 00000006   ecx: c0114375   edx: dfc1a000
> > esi: 00000046   edi: ffffffff   ebp: 00000000   esp: dfc1be24
> > ds: 007b   es: 007b   ss: 0068
> > Process ifconfig (pid: 1241, ti=dfc1a000 task=dfcb3030 task.ti=dfc1a000)
> > Stack: 000000db 00000000 c03d9100 c010efa9 00006d80 00000001 00000060
> e099a210 
> >        00000286 ffffff24 df7015c8 00000000 0000000f 00000001 c0103439
> df7015c8 
> >        e099a0ff e09c0000 00000000 0000000f 00000001 80080740 c14a007b
> df70007b 
> > Call Trace:
> >  [<c010efa9>] __ipipe_handle_irq+0x1b9/0x20b
> >  [<e099a210>] e1000_set_multi+0x111/0x189 [e1000]
> >  [<c0103439>] common_interrupt+0x21/0x38
> >  [<e099a0ff>] e1000_set_multi+0x0/0x189 [e1000]
> >  [<e099a210>] e1000_set_multi+0x111/0x189 [e1000]
> >  [<c02dcfb1>] __dev_mc_upload+0x1d/0x1e
> >  [<c02dd0d1>] dev_mc_upload+0x24/0x37
> >  [<c02db5dc>] dev_open+0x44/0x62
> >  [<c02da0a9>] dev_change_flags+0x47/0xe4
> >  [<c030d1c2>] devinet_ioctl+0x252/0x56f
> >  [<c02db1ba>] dev_ifsioc+0x113/0x38d
> >  [<c02d15d4>] sock_ioctl+0x0/0x1ad
> >  [<c02d1762>] sock_ioctl+0x18e/0x1ad
> >  [<c02d15d4>] sock_ioctl+0x0/0x1ad
> >  [<c015e1bf>] do_ioctl+0x1f/0x62
> >  [<c015e446>] vfs_ioctl+0x244/0x256
> >  [<c015e48b>] sys_ioctl+0x33/0x4c
> >  [<c01029f3>] sysenter_past_esp+0x6c/0x70
> >  =======================
> > Code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <00> 91 3d c0 00
> 91 3d c0 00 00 00 00 00 00 00 00 00 00 00 00 00 
> > EIP: [<c03e5680>] 0xc03e5680 SS:ESP 0068:dfc1be24
> >  <0>Kernel panic - not syncing: Fatal exception in interrupt
> >  BUG: at arch/i386/kernel/smp.c:565 smp_call_function()
> >  [<c010b903>] smp_call_function+0x66/0x10a
> >  [<c0118e3a>] printk+0x62/0xd5
> >  [<c010b9c2>] smp_send_stop+0x1b/0x2b
> >  [<c01183d5>] panic+0x4d/0xe4
> >  [<c0103f71>] die+0x1f2/0x226
> >  [<c01116a4>] do_page_fault+0x447/0x517
> >  [<c013fbae>] __alloc_pages+0x52/0x286
> >  [<c010f643>] __ipipe_handle_exception+0xce/0x158
> >  [<c01521e3>] kmem_cache_alloc+0x5d/0x67
> >  [<c010bb1e>] smp_call_function_interrupt+0x31/0x4c
> >  [<c033339d>] error_code+0x81/0x90
> >  [<c0114375>] try_to_wake_up+0x33c/0x346
> >  [<c011226c>] __activate_task+0x1c/0x29
> >  [<c010efa9>] __ipipe_handle_irq+0x1b9/0x20b
> >  [<e099a210>] e1000_set_multi+0x111/0x189 [e1000]
> >  [<c0103439>] common_interrupt+0x21/0x38
> >  [<e099a0ff>] e1000_set_multi+0x0/0x189 [e1000]
> >  [<e099a210>] e1000_set_multi+0x111/0x189 [e1000]
> >  [<c02dcfb1>] __dev_mc_upload+0x1d/0x1e
> >  [<c02dd0d1>] dev_mc_upload+0x24/0x37
> >  [<c02db5dc>] dev_open+0x44/0x62
> >  [<c02da0a9>] dev_change_flags+0x47/0xe4
> >  [<c030d1c2>] devinet_ioctl+0x252/0x56f
> >  [<c02db1ba>] dev_ifsioc+0x113/0x38d
> >  [<c02d15d4>] sock_ioctl+0x0/0x1ad
> >  [<c02d1762>] sock_ioctl+0x18e/0x1ad
> >  [<c02d15d4>] sock_ioctl+0x0/0x1ad
> >  [<c015e1bf>] do_ioctl+0x1f/0x62
> >  [<c015e446>] vfs_ioctl+0x244/0x256
> >  [<c015e48b>] sys_ioctl+0x33/0x4c
> >  [<c01029f3>] sysenter_past_esp+0x6c/0x70
> >  =======================
> > 
> > 
> > 
> > 
> > ----- Original Nachricht ----
> > Von:     Philippe Gerum <rpm@xenomai.org>
> > An:      "M. Koehrer" <mathias_koehrer@domain.hid>
> > Datum:   27.04.2007 17:05
> > Betreff: Re: Re: [Xenomai-help] Xenomai and MSI enabled crashes kernel
> > 
> > > On Fri, 2007-04-27 at 16:56 +0200, Philippe Gerum wrote:
> > > > On Fri, 2007-04-27 at 16:28 +0200, M. Koehrer wrote:
> > > > > Hello Philippe,
> > > > > 
> > > > > here it is: (I have no idea what BUGON does...)
> > > > > 
> > > > 
> > > > This patch will print out the irq/vector mappings. I'm interested in
> > > > reading this output.
> > > > 
> > > > --- arch/i386/kernel/io_apic.c~	2007-02-26 10:31:39.000000000 +0100
> > > > +++ arch/i386/kernel/io_apic.c	2007-04-27 16:51:51.000000000 +0200
> > > > @@ -1259,6 +1259,7 @@
> > > >  	current_vector = vector;
> > > >  	current_offset = offset;
> > > >  	irq_vector[irq] = vector;
> > > > +	printk("IRQ %d vectored at #%2x\n", irq, vector);
> > > 
> > > Please s/%2x/%.2x
> > > 
> > > >  
> > > >  	return vector;
> > > >  }
> > > > 
> > > -- 
> > > Philippe.
> > > 
> > > 
> > > 
> > 
> -- 
> Philippe.
> 
> 
> 

-- 
Mathias Koehrer
mathias_koehrer@domain.hid


50€ AMAZON-Einkaufsgutschein bei Bestellung von Arcor-DSL:
Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren
ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT JETZT bei Arcor: günstig
und schnell mit DSL - das All-Inclusive-Paket für clevere Doppel-Sparer,
nur  39,85 €  inkl. DSL- und ISDN-Grundgebühr!
http://www.arcor.de/rd/emf-dsl-2

Re: [Xenomai-help] Xenomai and MSI enabled crashes kernel

[Philippe Gerum]

On Fri, 2007-04-27 at 17:10 +0200, M. Koehrer wrote:
> Hi Philippe,
> 
> here is the next result (I have switched off the "quiet" kernel parameter to get everything).
> 

There is a SMP-related bugfix regarding our IPI namespace I need to
backport from x86_64 to x86. Not sure this is what bites us here yet,
but there is no use to chase the wild goose. In any case, CONFIG_PCI_MSI
clearly worsens the situation regarding this issue.

> Regards
> 
> Mathias
> ++++++++++++++++++++++++++++++++++++++++++++++++++
> 
> Linux version 2.6.20.4 (root@domain.hid) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #18 SMP Fri Apr 27 16:58:38 GMT-2 2007
> BIOS-provided physical RAM map:
> sanitize start
> sanitize end
> copy_e820_map() start: 0000000000000000 size: 000000000009e000 end: 000000000009e000 type: 1
> copy_e820_map() type is E820_RAM
> copy_e820_map() start: 000000000009e000 size: 0000000000002000 end: 00000000000a0000 type: 2
> copy_e820_map() start: 00000000000ca000 size: 0000000000002000 end: 00000000000cc000 type: 2
> copy_e820_map() start: 00000000000e4000 size: 000000000001c000 end: 0000000000100000 type: 2
> copy_e820_map() start: 0000000000100000 size: 000000001fde0000 end: 000000001fee0000 type: 1
> copy_e820_map() type is E820_RAM
> copy_e820_map() start: 000000001fee0000 size: 0000000000009000 end: 000000001fee9000 type: 3
> copy_e820_map() start: 000000001fee9000 size: 0000000000017000 end: 000000001ff00000 type: 4
> copy_e820_map() start: 000000001ff00000 size: 0000000000100000 end: 0000000020000000 type: 2
> copy_e820_map() start: 00000000fec00000 size: 0000000000010000 end: 00000000fec10000 type: 2
> copy_e820_map() start: 00000000fee00000 size: 0000000000001000 end: 00000000fee01000 type: 2
> copy_e820_map() start: 00000000ff000000 size: 0000000001000000 end: 0000000100000000 type: 2
>  BIOS-e820: 0000000000000000 - 000000000009e000 (usable)
>  BIOS-e820: 000000000009e000 - 00000000000a0000 (reserved)
>  BIOS-e820: 00000000000ca000 - 00000000000cc000 (reserved)
>  BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved)
>  BIOS-e820: 0000000000100000 - 000000001fee0000 (usable)
>  BIOS-e820: 000000001fee0000 - 000000001fee9000 (ACPI data)
>  BIOS-e820: 000000001fee9000 - 000000001ff00000 (ACPI NVS)
>  BIOS-e820: 000000001ff00000 - 0000000020000000 (reserved)
>  BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
>  BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
>  BIOS-e820: 00000000ff000000 - 0000000100000000 (reserved)
> 510MB LOWMEM available.
> found SMP MP-table at 000f5f40
> Zone PFN ranges:
>   DMA             0 ->     4096
>   Normal       4096 ->   130784
> early_node_map[1] active PFN ranges
>     0:        0 ->   130784
> DMI present.
> ACPI: PM-Timer IO Port: 0x1008
> ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
> Processor #0 15:6 APIC version 20
> ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
> Processor #1 15:6 APIC version 20
> ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
> ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
> ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
> IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23
> ACPI: IOAPIC (id[0x03] address[0xfec10000] gsi_base[24])
> IOAPIC[1]: apic_id 3, version 32, address 0xfec10000, GSI 24-47
> ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge)
> ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
> Enabling APIC mode:  Flat.  Using 2 I/O APICs
> Using ACPI (MADT) for SMP configuration information
> Allocating PCI resources starting at 30000000 (gap: 20000000:dec00000)
> Detected 3192.197 MHz processor.
> Built 1 zonelists.  Total pages: 129763
> Kernel command line: root=/dev/sda5 vga=ext isolcpus=1,3,7 console=ttyS0,115200n8
> Enabling fast FPU save and restore... done.
> Enabling unmasked SIMD FPU exception support... done.
> Initializing CPU#0
> PID hash table entries: 2048 (order: 11, 8192 bytes)
> I-pipe 1.7-03: pipeline enabled.
> Console: colour VGA+ 80x50
> Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
> Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
> Memory: 513860k/523136k available (2256k kernel code, 8696k reserved, 893k data, 224k init, 0k highmem)
> virtual kernel memory layout:
>     fixmap  : 0xfffb7000 - 0xfffff000   ( 288 kB)
>     vmalloc : 0xe0800000 - 0xfffb5000   ( 503 MB)
>     lowmem  : 0xc0000000 - 0xdfee0000   ( 510 MB)
>       .init : 0xc041a000 - 0xc0452000   ( 224 kB)
>       .data : 0xc03341f1 - 0xc041360c   ( 893 kB)
>       .text : 0xc0100000 - 0xc03341f1   (2256 kB)
> Checking if this processor honours the WP bit even in supervisor mode... Ok.
> Calibrating delay using timer specific routine.. 6389.64 BogoMIPS (lpj=12779283)
> Mount-cache hash table entries: 512
> monitor/mwait feature present.
> using mwait in idle threads.
> CPU: Trace cache: 12K uops, L1 D cache: 16K
> CPU: L2 cache: 2048K
> CPU: Physical Processor ID: 0
> CPU: Processor Core ID: 0
> Intel machine check architecture supported.
> Intel machine check reporting enabled on CPU#0.
> CPU0: Intel P4/Xeon Extended MCE MSRs (24) available
> Compat vDSO mapped to ffffe000.
> Checking 'hlt' instruction... OK.
> Freeing SMP alternatives: 15k freed
> ACPI: Core revision 20060707
> CPU0: Intel(R) Pentium(R) D CPU 3.20GHz stepping 02
> Booting processor 1/1 eip 2000
> Initializing CPU#1
> Calibrating delay using timer specific routine.. 6384.56 BogoMIPS (lpj=12769139)
> monitor/mwait feature present.
> CPU: Trace cache: 12K uops, L1 D cache: 16K
> CPU: L2 cache: 2048K
> CPU: Physical Processor ID: 0
> CPU: Processor Core ID: 1
> Intel machine check architecture supported.
> Intel machine check reporting enabled on CPU#1.
> CPU1: Intel P4/Xeon Extended MCE MSRs (24) available
> CPU1: Thermal monitoring enabled
> CPU1: Intel(R) Pentium(R) D CPU 3.20GHz stepping 02
> Total of 2 processors activated (12774.21 BogoMIPS).
> ENABLING IO-APIC IRQs
> IRQ 1 vectored at #39
> IRQ 3 vectored at #41
> IRQ 4 vectored at #49
> IRQ 5 vectored at #51
> IRQ 6 vectored at #59
> IRQ 7 vectored at #61
> IRQ 8 vectored at #69
> IRQ 9 vectored at #71
> IRQ 10 vectored at #79
> IRQ 11 vectored at #81
> IRQ 12 vectored at #89
> IRQ 13 vectored at #91
> IRQ 14 vectored at #99
> IRQ 15 vectored at #a1
> ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
> checking TSC synchronization across 2 CPUs: passed.
> Brought up 2 CPUs
> migration_cost=0
> NET: Registered protocol family 16
> ACPI: bus type pci registered
> PCI: BIOS Bug: MCFG area at f0000000 is not E820-reserved
> PCI: Not using MMCONFIG.
> PCI: PCI BIOS revision 2.10 entry at 0xfd877, last bus=10
> PCI: Using configuration type 1
> Setting up standard PCI resources
> ACPI: Interpreter enabled
> ACPI: Using IOAPIC for interrupt routing
> ACPI: PCI Root Bridge [PCI0] (0000:00)
> PCI quirk: region 1000-107f claimed by ICH6 ACPI/GPIO/TCO
> PCI quirk: region 1180-11bf claimed by ICH6 GPIO
> 0000:00:1f.1: trying to change BAR0 from 0000 to 01F0
> 0000:00:1f.1: trying to change BAR1 from 0000 to 03F4
> 0000:00:1f.1: trying to change BAR2 from 0000 to 0170
> 0000:00:1f.1: trying to change BAR3 from 0000 to 0374
> PCI: PXH quirk detected, disabling MSI for SHPC device
> PCI: Firmware left 0000:0a:06.0 e100 interrupts enabled, disabling
> PCI: Transparent bridge - 0000:00:1e.0
> ACPI: PCI Interrupt Link [LNKA] (IRQs 3 *10 11 14 15)
> ACPI: PCI Interrupt Link [LNKB] (IRQs 3 10 *11 14 15)
> ACPI: PCI Interrupt Link [LNKC] (IRQs 3 10 11 14 15) *5
> ACPI: PCI Interrupt Link [LNKD] (IRQs 3 *10 11 14 15)
> ACPI: PCI Interrupt Link [LNKE] (IRQs 3 10 *11 14 15)
> ACPI: PCI Interrupt Link [LNKF] (IRQs 3 10 11 14 15) *0, disabled.
> ACPI: PCI Interrupt Link [LNKG] (IRQs 3 10 11 14 15) *0, disabled.
> ACPI: PCI Interrupt Link [LNKH] (IRQs 3 10 11 14 15) *12
> Linux Plug and Play Support v0.97 (c) Adam Belay
> pnp: PnP ACPI init
> pnp: PnP ACPI: found 12 devices
> SCSI subsystem initialized
> PCI: Using ACPI for IRQ routing
> PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
> PCI: Bridge: 0000:01:00.0
>   IO window: disabled.
>   MEM window: e0100000-e1ffffff
>   PREFETCH window: e8000000-efffffff
> PCI: Bridge: 0000:00:01.0
>   IO window: disabled.
>   MEM window: e0100000-e1ffffff
>   PREFETCH window: e8000000-efffffff
> PCI: Bridge: 0000:03:00.0
>   IO window: disabled.
>   MEM window: disabled.
>   PREFETCH window: disabled.
> PCI: Bridge: 0000:00:1c.0
>   IO window: disabled.
>   MEM window: e2000000-e20fffff
>   PREFETCH window: disabled.
> PCI: Bridge: 0000:00:1c.4
>   IO window: 4000-4fff
>   MEM window: e2100000-e21fffff
>   PREFETCH window: disabled.
> PCI: Bridge: 0000:00:1c.5
>   IO window: 5000-5fff
>   MEM window: e2200000-e22fffff
>   PREFETCH window: disabled.
> PCI: Bridge: 0000:00:1e.0
>   IO window: 6000-6fff
>   MEM window: e2300000-e3ffffff
>   PREFETCH window: 30000000-300fffff
> IRQ 16 vectored at #a9
> ACPI: PCI Interrupt 0000:00:01.0[A] -> GSI 16 (level, low) -> IRQ 16
> IRQ 17 vectored at #b1
> ACPI: PCI Interrupt 0000:00:1c.0[A] -> GSI 17 (level, low) -> IRQ 17
> ACPI: PCI Interrupt 0000:00:1c.4[A] -> GSI 17 (level, low) -> IRQ 17
> ACPI: PCI Interrupt 0000:00:1c.5[B] -> GSI 16 (level, low) -> IRQ 16
> NET: Registered protocol family 2
> IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
> TCP established hash table entries: 16384 (order: 5, 131072 bytes)
> TCP bind hash table entries: 8192 (order: 4, 65536 bytes)
> TCP: Hash tables configured (established 16384 bind 8192)
> TCP reno registered
> checking if image is initramfs...it isn't (no cpio magic); looks like an initrd
> Freeing initrd memory: 348k freed
> Simple Boot Flag at 0x37 set to 0x1
> Machine check exception polling timer started.
> audit: initializing netlink socket (disabled)
> audit(1177686146.976:1): initialized
> Installing knfsd (copyright (C) 1996 okir@domain.hid).
> io scheduler noop registered
> io scheduler anticipatory registered (default)
> io scheduler deadline registered
> io scheduler cfq registered
> assign_interrupt_mode Found MSI capability
> IRQ 223 vectored at #b9
> assign_interrupt_mode Found MSI capability
> IRQ 222 vectored at #c1
> assign_interrupt_mode Found MSI capability
> IRQ 221 vectored at #c9
> assign_interrupt_mode Found MSI capability
> IRQ 220 vectored at #d1
> input: Power Button (FF) as /class/input/input0
> ACPI: Power Button (FF) [PWRF]
> input: Power Button (CM) as /class/input/input1
> ACPI: Power Button (CM) [PWRB]
> lp: driver loaded but no devices found
> Linux agpgart interface v0.101 (c) Dave Jones
> [drm] Initialized drm 1.1.0 20060810
> Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
> serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
> serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
> 00:09: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
> 00:0a: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
> IRQ 18 vectored at #d9
> ACPI: PCI Interrupt 0000:05:00.3[C] -> GSI 18 (level, low) -> IRQ 18
> 0000:05:00.3: ttyS2 at I/O 0x4020 (irq = 18) is a 16550A
> parport: PnPBIOS parport detected.
> parport0: PC-style at 0x378 (0x778), irq 7 [PCSPP(,...)]
> lp0: using parport0 (interrupt-driven).
> floppy0: no floppy controllers found
> RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
> loop: loaded (max 8 devices)
> Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
> ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
> ICH7: IDE controller at PCI slot 0000:00:1f.1
> ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 18
> ICH7: chipset revision 1
> ICH7: not 100% native mode: will probe irqs later
>     ide0: BM-DMA at 0x3020-0x3027, BIOS settings: hda:DMA, hdb:pio
> hda: HL-DT-STDVD-ROM GDR8164B, ATAPI CD/DVD-ROM drive
> ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> hda: ATAPI 52X DVD-ROM drive, 256kB Cache, UDMA(33)
> Uniform CD-ROM driver Revision: 3.20
> ata_piix 0000:00:1f.2: MAP [ P0 P2 P1 P3 ]
> IRQ 19 vectored at #e1
> ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 19 (level, low) -> IRQ 19
> ata1: SATA max UDMA/133 cmd 0x3068 ctl 0x305E bmdma 0x3030 irq 19
> ata2: SATA max UDMA/133 cmd 0x3060 ctl 0x305A bmdma 0x3038 irq 19
> scsi0 : ata_piix
> ata1.00: ATA-7, max UDMA/133, 160836480 sectors: LBA48 NCQ (depth 0/32)
> ata1.00: ata1: dev 0 multi count 16
> ata1.00: configured for UDMA/133
> scsi1 : ata_piix
> ATA: abnormal status 0x7F on port 0x3067
> scsi 0:0:0:0: Direct-Access     ATA      Hitachi HDS72168 P21O PQ: 0 ANSI: 5
> SCSI device sda: 160836480 512-byte hdwr sectors (82348 MB)
> sda: Write Protect is off
> SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA
> SCSI device sda: 160836480 512-byte hdwr sectors (82348 MB)
> sda: Write Protect is off
> SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA
>  sda: sda1 sda2 < sda5 sda6 sda7 >
> sd 0:0:0:0: Attached scsi disk sda
> sd 0:0:0:0: Attached scsi generic sg0 type 0
> PNP: PS/2 Controller [PNP0303:KBC0,PNP0f13:MSE0] at 0x60,0x64 irq 1,12
> serio: i8042 KBD port at 0x60,0x64 irq 1
> mice: PS/2 mouse device common for all mice
> input: AT Translated Set 2 keyboard as /class/input/input2
> input: PC Speaker as /class/input/input3
> TCP cubic registered
> NET: Registered protocol family 1
> NET: Registered protocol family 17
> Starting balanced_irq
> Using IPI Shortcut mode
> RAMDISK: Compressed image found at block 0
> Time: tsc clocksource has been installed.
> VFS: Mounted root (minix filesystem).
> Requested Root Partition: sda5. OK
> ReiserFS: sda5: found reiserfs format "3.6" with standard journal
> ReiserFS: sda5: using ordered data mode
> ReiserFS: sda5: journal params: device sda5, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
> ReiserFS: sda5: checking transaction log (sda5)
> ReiserFS: sda5: Using r5 hash to sort names
> VFS: Mounted root (reiserfs filesystem) readonly.
> Trying to move old root to /initrd ... /initrd does not exist. Ignored.
> Unmounting old root
> Trying to free ramdisk memory ... okay
> Freeing unused kernel memory: 224k freed
> INIT: version 2.86 booting
> Setting parameters of disc: (none).
> Setting the system clock..
> Mounting proc filesystem
> mount: proc already mounted
> Cleaning up ifupdown....
> Loading kernel modules...done.
> Loading device-mapper support.
> Checking file systems...fsck 1.40-WIP (14-Nov-2006)
> done.
> Setting kernel variables...done.
> Checking /etc/fstab.
> Mounting local filesystems...ReiserFS: sda1: found reiserfs format "3.6" with standard journal
> ReiserFS: sda1: using ordered data mode
> ReiserFS: sda1: journal params: device sda1, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
> ReiserFS: sda1: checking transaction log (sda1)
> ReiserFS: sda1: Using r5 hash to sort names
> done.
> Activating swapfile swap...done.
> Configuring network interfaces...Intel(R) PRO/1000 Network Driver - version 7.3.15-k2
> Copyright (c) 1999-2006 Intel Corporation.
> ACPI: PCI Interrupt 0000:05:00.0[A] -> GSI 16 (level, low) -> IRQ 16
> e1000: 0000:05:00.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1) 00:30:48:5a:f9:0a
> e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
> IRQ 219 vectored at #e9
> BUG: unable to handle kernel paging request at virtual address 511203b2
>  printing eip:
> c03e5680
> *pde = 00000000
> Oops: 0002 [#1]
> SMP 
> Modules linked in: e1000
> CPU:    0
> EIP:    0060:[<c03e5680>]    Not tainted VLI
> EFLAGS: 00010092   (2.6.20.4 #18)
> EIP is at 0xc03e5680
> eax: c011226c   ebx: 00000006   ecx: c0114375   edx: dfc1a000
> esi: 00000046   edi: ffffffff   ebp: 00000000   esp: dfc1be24
> ds: 007b   es: 007b   ss: 0068
> Process ifconfig (pid: 1241, ti=dfc1a000 task=dfcb3030 task.ti=dfc1a000)
> Stack: 000000db 00000000 c03d9100 c010efa9 00006d80 00000001 00000060 e099a210 
>        00000286 ffffff24 df7015c8 00000000 0000000f 00000001 c0103439 df7015c8 
>        e099a0ff e09c0000 00000000 0000000f 00000001 80080740 c14a007b df70007b 
> Call Trace:
>  [<c010efa9>] __ipipe_handle_irq+0x1b9/0x20b
>  [<e099a210>] e1000_set_multi+0x111/0x189 [e1000]
>  [<c0103439>] common_interrupt+0x21/0x38
>  [<e099a0ff>] e1000_set_multi+0x0/0x189 [e1000]
>  [<e099a210>] e1000_set_multi+0x111/0x189 [e1000]
>  [<c02dcfb1>] __dev_mc_upload+0x1d/0x1e
>  [<c02dd0d1>] dev_mc_upload+0x24/0x37
>  [<c02db5dc>] dev_open+0x44/0x62
>  [<c02da0a9>] dev_change_flags+0x47/0xe4
>  [<c030d1c2>] devinet_ioctl+0x252/0x56f
>  [<c02db1ba>] dev_ifsioc+0x113/0x38d
>  [<c02d15d4>] sock_ioctl+0x0/0x1ad
>  [<c02d1762>] sock_ioctl+0x18e/0x1ad
>  [<c02d15d4>] sock_ioctl+0x0/0x1ad
>  [<c015e1bf>] do_ioctl+0x1f/0x62
>  [<c015e446>] vfs_ioctl+0x244/0x256
>  [<c015e48b>] sys_ioctl+0x33/0x4c
>  [<c01029f3>] sysenter_past_esp+0x6c/0x70
>  =======================
> Code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <00> 91 3d c0 00 91 3d c0 00 00 00 00 00 00 00 00 00 00 00 00 00 
> EIP: [<c03e5680>] 0xc03e5680 SS:ESP 0068:dfc1be24
>  <0>Kernel panic - not syncing: Fatal exception in interrupt
>  BUG: at arch/i386/kernel/smp.c:565 smp_call_function()
>  [<c010b903>] smp_call_function+0x66/0x10a
>  [<c0118e3a>] printk+0x62/0xd5
>  [<c010b9c2>] smp_send_stop+0x1b/0x2b
>  [<c01183d5>] panic+0x4d/0xe4
>  [<c0103f71>] die+0x1f2/0x226
>  [<c01116a4>] do_page_fault+0x447/0x517
>  [<c013fbae>] __alloc_pages+0x52/0x286
>  [<c010f643>] __ipipe_handle_exception+0xce/0x158
>  [<c01521e3>] kmem_cache_alloc+0x5d/0x67
>  [<c010bb1e>] smp_call_function_interrupt+0x31/0x4c
>  [<c033339d>] error_code+0x81/0x90
>  [<c0114375>] try_to_wake_up+0x33c/0x346
>  [<c011226c>] __activate_task+0x1c/0x29
>  [<c010efa9>] __ipipe_handle_irq+0x1b9/0x20b
>  [<e099a210>] e1000_set_multi+0x111/0x189 [e1000]
>  [<c0103439>] common_interrupt+0x21/0x38
>  [<e099a0ff>] e1000_set_multi+0x0/0x189 [e1000]
>  [<e099a210>] e1000_set_multi+0x111/0x189 [e1000]
>  [<c02dcfb1>] __dev_mc_upload+0x1d/0x1e
>  [<c02dd0d1>] dev_mc_upload+0x24/0x37
>  [<c02db5dc>] dev_open+0x44/0x62
>  [<c02da0a9>] dev_change_flags+0x47/0xe4
>  [<c030d1c2>] devinet_ioctl+0x252/0x56f
>  [<c02db1ba>] dev_ifsioc+0x113/0x38d
>  [<c02d15d4>] sock_ioctl+0x0/0x1ad
>  [<c02d1762>] sock_ioctl+0x18e/0x1ad
>  [<c02d15d4>] sock_ioctl+0x0/0x1ad
>  [<c015e1bf>] do_ioctl+0x1f/0x62
>  [<c015e446>] vfs_ioctl+0x244/0x256
>  [<c015e48b>] sys_ioctl+0x33/0x4c
>  [<c01029f3>] sysenter_past_esp+0x6c/0x70
>  =======================
> 
> 
> 
> 
> ----- Original Nachricht ----
> Von:     Philippe Gerum <rpm@xenomai.org>
> An:      "M. Koehrer" <mathias_koehrer@domain.hid>
> Datum:   27.04.2007 17:05
> Betreff: Re: Re: [Xenomai-help] Xenomai and MSI enabled crashes kernel
> 
> > On Fri, 2007-04-27 at 16:56 +0200, Philippe Gerum wrote:
> > > On Fri, 2007-04-27 at 16:28 +0200, M. Koehrer wrote:
> > > > Hello Philippe,
> > > > 
> > > > here it is: (I have no idea what BUGON does...)
> > > > 
> > > 
> > > This patch will print out the irq/vector mappings. I'm interested in
> > > reading this output.
> > > 
> > > --- arch/i386/kernel/io_apic.c~	2007-02-26 10:31:39.000000000 +0100
> > > +++ arch/i386/kernel/io_apic.c	2007-04-27 16:51:51.000000000 +0200
> > > @@ -1259,6 +1259,7 @@
> > >  	current_vector = vector;
> > >  	current_offset = offset;
> > >  	irq_vector[irq] = vector;
> > > +	printk("IRQ %d vectored at #%2x\n", irq, vector);
> > 
> > Please s/%2x/%.2x
> > 
> > >  
> > >  	return vector;
> > >  }
> > > 
> > -- 
> > Philippe.
> > 
> > 
> > 
> 
-- 
Philippe.

Re: [Xenomai-help] Xenomai and MSI enabled crashes kernel

[Bernhard Walle]

[-- Attachment #1: Type: text/plain, Size: 626 bytes --]

* M. Koehrer <mathias_koehrer@domain.hid> [2007-04-26 14:04]:
> 
> I am using kernel 2.6.20.4 and Xenomai 2.3.1 on a SMP enabled dual core Pentium 4.
> Everything works fine when I do not enable the CONFIG_PCI_MSI (Messages signaled interrupts) for
> PCI Express.
> As I am always short with interrupts I want to use MSI for the PCIe base
> I/O devices like Ethernet.

Didn't follow the thread, but as workaround to disable MSI in Linux
you can boot with 'pci=nomsi'.


Thanks,
   Bernhard
-- 
Mütter lieben ihre Kinder mehr, als Väter es tun, weil sie sicher sein können,
dass es ihre sind.
	-- Aristoteles

[-- Attachment #2: Type: application/pgp-signature, Size: 307 bytes --]

Re: [Xenomai-help] Xenomai and MSI enabled crashes kernel

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 3510 bytes --]

M. Koehrer wrote:
> Hi Philippe,
> 
> I have extracted that part. However this very address is not available.
> I have placed a couple of lines before and after that address.
> 
> Regards
> 
> Mathias
> PS: I will continue on Monday with the tests....
> 

If you happen to do so, please give this patch a try. It's an experiment
to include I-pipe tracer information in kernel oops reports. For this
purpose, enable CONFIG_IPIPE_TRACE_MCOUNT, CONFIG_IPIPE_TRACE_ENABLE,
and CONFIG_IPIPE_TRACE_IRQSOFF. Then trigger the oops. Maybe we get more
information about the function call history.

Thanks,
Jan

---
 arch/i386/mm/fault.c        |    5 +++++
 include/linux/ipipe_trace.h |    7 ++++++-
 kernel/ipipe/tracer.c       |    8 ++++++++
 lib/bust_spinlocks.c        |    5 +++++
 4 files changed, 24 insertions(+), 1 deletion(-)

Index: linux-2.6.20/arch/i386/mm/fault.c
===================================================================
--- linux-2.6.20.orig/arch/i386/mm/fault.c
+++ linux-2.6.20/arch/i386/mm/fault.c
@@ -23,6 +23,7 @@
 #include <linux/module.h>
 #include <linux/kprobes.h>
 #include <linux/uaccess.h>
+#include <linux/ipipe_trace.h>

 #include <asm/system.h>
 #include <asm/desc.h>
@@ -68,9 +69,13 @@ void bust_spinlocks(int yes)
 	int loglevel_save = console_loglevel;

 	if (yes) {
+		ipipe_trace_panic_freeze();
 		oops_in_progress = 1;
 		return;
 	}
+
+	ipipe_trace_panic_dump();
+
 #ifdef CONFIG_VT
 	unblank_screen();
 #endif
Index: linux-2.6.20/include/linux/ipipe_trace.h
===================================================================
--- linux-2.6.20.orig/include/linux/ipipe_trace.h
+++ linux-2.6.20/include/linux/ipipe_trace.h
@@ -39,6 +39,11 @@ int ipipe_trace_frozen_reset(void);
 void ipipe_trace_panic_freeze(void);
 void ipipe_trace_panic_dump(void);

-#endif /* CONFIG_IPIPE_TRACE */
+#else /* !CONFIG_IPIPE_TRACE */
+
+static inline void ipipe_trace_panic_freeze(void) { }
+static inline void ipipe_trace_panic_dump(void) { }
+
+#endif /* !CONFIG_IPIPE_TRACE */

 #endif	/* !__LINUX_IPIPE_H */
Index: linux-2.6.20/kernel/ipipe/tracer.c
===================================================================
--- linux-2.6.20.orig/kernel/ipipe/tracer.c
+++ linux-2.6.20/kernel/ipipe/tracer.c
@@ -565,6 +565,9 @@ void ipipe_trace_panic_freeze(void)
 	unsigned long flags;
 	int cpu_id;

+	if (!ipipe_trace_enable)
+		return;
+
 	ipipe_trace_enable = 0;
 	local_irq_save_hw_notrace(flags);

@@ -614,6 +617,9 @@ void ipipe_trace_panic_dump(void)
 	int start, pos;
 	char task_info[12];

+	if (!panic_path)
+		return;
+
 	printk("I-pipe tracer log (%d points):\n", cnt);

 	start = pos = WRAP_POINT_NO(panic_path->trace_pos-1);
@@ -667,6 +673,8 @@ void ipipe_trace_panic_dump(void)
 		}
 		pos = WRAP_POINT_NO(pos - 1);
 	}
+
+	panic_path = NULL;
 }
 EXPORT_SYMBOL(ipipe_trace_panic_dump);

Index: linux-2.6.20/lib/bust_spinlocks.c
===================================================================
--- linux-2.6.20.orig/lib/bust_spinlocks.c
+++ linux-2.6.20/lib/bust_spinlocks.c
@@ -12,14 +12,19 @@
 #include <linux/tty.h>
 #include <linux/wait.h>
 #include <linux/vt_kern.h>
+#include <linux/ipipe_trace.h>


 void bust_spinlocks(int yes)
 {
 	if (yes) {
+		ipipe_trace_panic_freeze();
 		oops_in_progress = 1;
 	} else {
 		int loglevel_save = console_loglevel;
+
+		ipipe_trace_panic_dump();
+
 #ifdef CONFIG_VT
 		unblank_screen();
 #endif


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] Xenomai and MSI enabled crashes kernel

[M. Koehrer]

Hi Jan,

enclosed is the output of this experiment.
I have removed all patches from last week before applying the new patch.

Regards

Mathias
--------------------------------------------- 
Intel(R) PRO/1000 Network Driver - version 7.3.15-k2
Copyright (c) 1999-2006 Intel Corporation.
ACPI: PCI Interrupt 0000:05:00.0[A] -> GSI 16 (level, low) -> IRQ 16
e1000: 0000:05:00.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1) 00:30:48:5a:f9:0a
e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
Kernel panic - not syncing: Aiee, killing interrupt handler!
I-pipe tracer log (30 points):
     +func                    0 ipipe_trace_panic_freeze+0x9 (bust_spinlocks+0x1b)
     +func                    0 bust_spinlocks+0xc (panic+0x17)
     +func                    0 panic+0xd (do_exit+0x78)
     +func                    0 do_exit+0xe (sys_exit_group+0x0)
     +func                   -1 do_group_exit+0xb (get_signal_to_deliver+0x388)
 |   +end     0x80000000     -1 __ipipe_unstall_root+0x56 (__ipipe_restore_root+0x18)
 |   #begin   0x80000000     -1 __ipipe_unstall_root+0x1a (__ipipe_restore_root+0x18)
     #func                   -1 __ipipe_unstall_root+0x8 (__ipipe_restore_root+0x18)
     #func                   -1 __ipipe_restore_root+0x8 (_spin_unlock_irqrestore+0x1e)
     #func                   -2 _spin_unlock_irqrestore+0x8 (complete_all+0x48)
     #func                   -2 __wake_up_common+0xe (complete_all+0x3f)
 |   #end     0x80000001     -2 __ipipe_stall_root+0x47 (_spin_lock_irqsave+0x21)
 |   +begin   0x80000001     -2 __ipipe_stall_root+0x21 (_spin_lock_irqsave+0x21)
     +func                   -3 __ipipe_stall_root+0xa (_spin_lock_irqsave+0x21)
 |   +end     0x80000001     -3 __ipipe_test_root+0x41 (_spin_lock_irqsave+0x11)
 |   +begin   0x80000001     -3 __ipipe_test_root+0x1f (_spin_lock_irqsave+0x11)
     +func                   -3 __ipipe_test_root+0xa (_spin_lock_irqsave+0x11)
     +func                   -3 _spin_lock_irqsave+0xa (complete_all+0x1a)
     +func                   -4 complete_all+0xe (do_coredump+0x587)
     +func                   -4 up_write+0x8 (do_coredump+0x1cf)
 |   +end     0x80000000     -5 __ipipe_unstall_root+0x56 (do_coredump+0x139)
 |   #begin   0x80000000     -5 __ipipe_unstall_root+0x1a (do_coredump+0x139)
     #func                   -5 __ipipe_unstall_root+0x8 (do_coredump+0x139)
     #func                   -6 zap_process+0xa (do_coredump+0x120)
 |   #end     0x80000001     -6 __ipipe_stall_root+0x47 (_spin_lock_irq+0x10)
 |   +begin   0x80000001     -6 __ipipe_stall_root+0x21 (_spin_lock_irq+0x10)
     +func                   -6 __ipipe_stall_root+0xa (_spin_lock_irq+0x10)
     +func                   -7 _spin_lock_irq+0x9 (do_coredump+0xfd)
     +func                   -7 init_waitqueue_head+0x8 (do_coredump+0xe7)
     +func                   -7 init_waitqueue_head+0x8 (do_coredump+0xd5)
 

----- Original Nachricht ----
Von:     Jan Kiszka <jan.kiszka@domain.hid>
An:      "M. Koehrer" <mathias_koehrer@domain.hid>
Datum:   30.04.2007 11:05
Betreff: Re: Aw: Re: [Xenomai-help] Xenomai and MSI enabled crashes kernel

> M. Koehrer wrote:
> > Hi Philippe,
> > 
> > I have extracted that part. However this very address is not available.
> > I have placed a couple of lines before and after that address.
> > 
> > Regards
> > 
> > Mathias
> > PS: I will continue on Monday with the tests....
> > 
> 
> If you happen to do so, please give this patch a try. It's an experiment
> to include I-pipe tracer information in kernel oops reports. For this
> purpose, enable CONFIG_IPIPE_TRACE_MCOUNT, CONFIG_IPIPE_TRACE_ENABLE,
> and CONFIG_IPIPE_TRACE_IRQSOFF. Then trigger the oops. Maybe we get more
> information about the function call history.
> 
> Thanks,
> Jan
> 


-- 
Mathias Koehrer
mathias_koehrer@domain.hid


50€ AMAZON-Einkaufsgutschein bei Bestellung von Arcor-DSL:
Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren
ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT JETZT bei Arcor: günstig
und schnell mit DSL - das All-Inclusive-Paket für clevere Doppel-Sparer,
nur  39,85 €  inkl. DSL- und ISDN-Grundgebühr!
http://www.arcor.de/rd/emf-dsl-2

Re: [Xenomai-help] Xenomai and MSI enabled crashes kernel

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 632 bytes --]

M. Koehrer wrote:
> Hi Jan,
> 
> enclosed is the output of this experiment.
> I have removed all patches from last week before applying the new patch.
> 

This BUG look now very different from your previous issue. Are you sure
you build is consistent? Maybe the not-yet-backported IPI bug over
x86_64 actually cause this heisenbug, don't know.

Well, if and only if you have nothing better to do ;), you could retry,
starting a test with a patch-free tree, then switching on the tracer and
testing again, and finally re-applying my last patch. But we may also
wait for Philippe to provide the IPI fix first.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] Xenomai and MSI enabled crashes kernel

[M. Koehrer]

Hi Jan,

I have done three experiments:
1. Using my kernel without any additional test-patches
2. Activating the trace stuff in the .config file
3. Applying your patches from today

I hope this helps...


Regards

Mathias

Here are the three relevant result files:
************************************** 1 **********************************************
Intel(R) PRO/1000 Network Driver - version 7.3.15-k2
Copyright (c) 1999-2006 Intel Corporation.
ACPI: PCI Interrupt 0000:05:00.0[A] -> GSI 16 (level, low) -> IRQ 16
e1000: 0000:05:00.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1) 00:30:48:5a:f9:0a
e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
BUG: unable to handle kernel NULL pointer dereference at virtual address 00000000
 printing eip:
00000000
*pde = 00000000
Oops: 0000 [#1]
SMP 
Modules linked in: e1000
CPU:    0
EIP:    0060:[<00000000>]    Not tainted VLI
EFLAGS: 00010086   (2.6.20.4 #3)
EIP is at _stext+0x3feffc70/0x14
eax: c0112244   ebx: 00000006   ecx: c011434d   edx: df860000
esi: 00000006   edi: 00000046   ebp: ffffffff   esp: df861e20
ds: 007b   es: 007b   ss: 0068
Process ifconfig (pid: 1242, ti=df860000 task=dfdd0030 task.ti=df860000)
Stack: c03e5680 000000db 00000000 c03d9100 c010ef83 00006d80 00000001 00000060 
       e099a210 00000286 ffffff24 df7085c8 00000000 0000000f 00000001 c0103439 
       df7085c8 e099a0ff e09c0000 00000000 0000000f 00000001 80080740 dfc7007b 
Call Trace:
 [<c010ef83>] __ipipe_handle_irq+0x1b9/0x20b
 [<e099a210>] e1000_set_multi+0x111/0x189 [e1000]
 [<c0103439>] common_interrupt+0x21/0x38
 [<e099a0ff>] e1000_set_multi+0x0/0x189 [e1000]
 [<e099a210>] e1000_set_multi+0x111/0x189 [e1000]
 [<c02dcf81>] __dev_mc_upload+0x1d/0x1e
 [<c02dd0a1>] dev_mc_upload+0x24/0x37
 [<c02db5ac>] dev_open+0x44/0x62
 [<c02da079>] dev_change_flags+0x47/0xe4
 [<c030d192>] devinet_ioctl+0x252/0x56f
 [<c02db18a>] dev_ifsioc+0x113/0x38d
 [<c02d15a4>] sock_ioctl+0x0/0x1ad
 [<c02d1732>] sock_ioctl+0x18e/0x1ad
 [<c02d15a4>] sock_ioctl+0x0/0x1ad
 [<c015e18f>] do_ioctl+0x1f/0x62
 [<c015e416>] vfs_ioctl+0x244/0x256
 [<c015e45b>] sys_ioctl+0x33/0x4c
 [<c01029f3>] sysenter_past_esp+0x6c/0x70
 =======================
Code:  Bad EIP value.
EIP: [<00000000>] _stext+0x3feffc70/0x14 SS:ESP 0068:df861e20
 <0>Kernel panic - not syncing: Fatal exception in interrupt
 BUG: at arch/i386/kernel/smp.c:565 smp_call_function()
 [<c010b903>] smp_call_function+0x66/0x10a
 [<c0118e12>] printk+0x62/0xd5
 [<c010b9c2>] smp_send_stop+0x1b/0x2b
 [<c01183ad>] panic+0x4d/0xe4
 [<c0103f71>] die+0x1f2/0x226
 [<c011167c>] do_page_fault+0x447/0x517
 [<c010f61d>] __ipipe_handle_exception+0xce/0x158
 [<c010bb1e>] smp_call_function_interrupt+0x31/0x4c
 [<c033336d>] error_code+0x81/0x90
 [<c011434d>] try_to_wake_up+0x33c/0x346
 [<c0112244>] __activate_task+0x1c/0x29
 [<c010ef83>] __ipipe_handle_irq+0x1b9/0x20b
 [<e099a210>] e1000_set_multi+0x111/0x189 [e1000]
 [<c0103439>] common_interrupt+0x21/0x38
 [<e099a0ff>] e1000_set_multi+0x0/0x189 [e1000]
 [<e099a210>] e1000_set_multi+0x111/0x189 [e1000]
 [<c02dcf81>] __dev_mc_upload+0x1d/0x1e
 [<c02dd0a1>] dev_mc_upload+0x24/0x37
 [<c02db5ac>] dev_open+0x44/0x62
 [<c02da079>] dev_change_flags+0x47/0xe4
 [<c030d192>] devinet_ioctl+0x252/0x56f
 [<c02db18a>] dev_ifsioc+0x113/0x38d
 [<c02d15a4>] sock_ioctl+0x0/0x1ad
 [<c02d1732>] sock_ioctl+0x18e/0x1ad
 [<c02d15a4>] sock_ioctl+0x0/0x1ad
 [<c015e18f>] do_ioctl+0x1f/0x62
 [<c015e416>] vfs_ioctl+0x244/0x256
 [<c015e45b>] sys_ioctl+0x33/0x4c
 [<c01029f3>] sysenter_past_esp+0x6c/0x70
 =======================


************************************** 2 **********************************************
Intel(R) PRO/1000 Network Driver - version 7.3.15-k2
Copyright (c) 1999-2006 Intel Corporation.
ACPI: PCI Interrupt 0000:05:00.0[A] -> GSI 16 (level, low) -> IRQ 16
e1000: 0000:05:00.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1) 00:30:48:5a:f9:0a
e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
BUG: scheduling while atomic: ifconfig/0x00010000/1242
 [<c0103d34>] show_trace_log_lvl+0x1f/0x34
 [<c01043b4>] show_trace+0x17/0x19
 [<c010444c>] dump_stack+0x1b/0x1d
 [<c0349ffb>] __sched_text_start+0x8b/0x8af
 [<c0102ca3>] work_resched+0x6/0x1c
 =======================
Kernel panic - not syncing: Aiee, killing interrupt handler!
  
************************************** 3 **********************************************

Intel(R) PRO/1000 Network Driver - version 7.3.15-k2
Copyright (c) 1999-2006 Intel Corporation.
ACPI: PCI Interrupt 0000:05:00.0[A] -> GSI 16 (level, low) -> IRQ 16
e1000: 0000:05:00.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1) 00:30:48:5a:f9:0a
e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
BUG: scheduling while atomic: ifconfig/0x00010000/1241
 [<c0103d34>] show_trace_log_lvl+0x1f/0x34
 [<c01043b4>] show_trace+0x17/0x19
 [<c010444c>] dump_stack+0x1b/0x1d
 [<c034a01b>] __sched_text_start+0x8b/0x8af
 [<c0102ca3>] work_resched+0x6/0x1c
 =======================
Kernel panic - not syncing: Aiee, killing interrupt handler!
I-pipe tracer log (30 points):
     +func                    0 ipipe_trace_panic_freeze+0x9 (bust_spinlocks+0x1b)
     +func                    0 bust_spinlocks+0xc (panic+0x17)
     +func                    0 panic+0xd (do_exit+0x78)
     +func                    0 do_exit+0xe (sys_exit_group+0x0)
     +func                    0 do_group_exit+0xb (get_signal_to_deliver+0x388)
 |   +end     0x80000000     -1 __ipipe_unstall_root+0x56 (__ipipe_restore_root+0x18)
 |   #begin   0x80000000     -1 __ipipe_unstall_root+0x1a (__ipipe_restore_root+0x18)
     #func                   -1 __ipipe_unstall_root+0x8 (__ipipe_restore_root+0x18)
     #func                   -1 __ipipe_restore_root+0x8 (_spin_unlock_irqrestore+0x1e)
     #func                   -2 _spin_unlock_irqrestore+0x8 (complete_all+0x48)
     #func                   -2 __wake_up_common+0xe (complete_all+0x3f)
 |   #end     0x80000001     -2 __ipipe_stall_root+0x47 (_spin_lock_irqsave+0x21)
 |   +begin   0x80000001     -2 __ipipe_stall_root+0x21 (_spin_lock_irqsave+0x21)
     +func                   -3 __ipipe_stall_root+0xa (_spin_lock_irqsave+0x21)
 |   +end     0x80000001     -3 __ipipe_test_root+0x41 (_spin_lock_irqsave+0x11)
 |   +begin   0x80000001     -3 __ipipe_test_root+0x1f (_spin_lock_irqsave+0x11)
     +func                   -3 __ipipe_test_root+0xa (_spin_lock_irqsave+0x11)
     +func                   -3 _spin_lock_irqsave+0xa (complete_all+0x1a)
     +func                   -4 complete_all+0xe (do_coredump+0x587)
     +func                   -4 up_write+0x8 (do_coredump+0x1cf)
 |   +end     0x80000000     -4 __ipipe_unstall_root+0x56 (do_coredump+0x139)
 |   #begin   0x80000000     -5 __ipipe_unstall_root+0x1a (do_coredump+0x139)
     #func                   -5 __ipipe_unstall_root+0x8 (do_coredump+0x139)
     #func                   -5 zap_process+0xa (do_coredump+0x120)
 |   #end     0x80000001     -6 __ipipe_stall_root+0x47 (_spin_lock_irq+0x10)
 |   +begin   0x80000001     -6 __ipipe_stall_root+0x21 (_spin_lock_irq+0x10)
     +func                   -6 __ipipe_stall_root+0xa (_spin_lock_irq+0x10)
     +func                   -6 _spin_lock_irq+0x9 (do_coredump+0xfd)
     +func                   -6 init_waitqueue_head+0x8 (do_coredump+0xe7)
     +func                   -7 init_waitqueue_head+0x8 (do_coredump+0xd5)
 




> M. Koehrer wrote:
> > Hi Jan,
> > 
> > enclosed is the output of this experiment.
> > I have removed all patches from last week before applying the new patch.
> > 
> 
> This BUG look now very different from your previous issue. Are you sure
> you build is consistent? Maybe the not-yet-backported IPI bug over
> x86_64 actually cause this heisenbug, don't know.
> 
> Well, if and only if you have nothing better to do ;), you could retry,
> starting a test with a patch-free tree, then switching on the tracer and
> testing again, and finally re-applying my last patch. But we may also
> wait for Philippe to provide the IPI fix first.
> 
> Jan
> 
> 

-- 
Mathias Koehrer
mathias_koehrer@domain.hid


50€ AMAZON-Einkaufsgutschein bei Bestellung von Arcor-DSL:
Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren
ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT JETZT bei Arcor: günstig
und schnell mit DSL - das All-Inclusive-Paket für clevere Doppel-Sparer,
nur  39,85 €  inkl. DSL- und ISDN-Grundgebühr!
http://www.arcor.de/rd/emf-dsl-2

Re: [Xenomai-help] Xenomai and MSI enabled crashes kernel

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 444 bytes --]

M. Koehrer wrote:
> Hi Jan,
> 
> I have done three experiments:
> 1. Using my kernel without any additional test-patches
> 2. Activating the trace stuff in the .config file
> 3. Applying your patches from today
> 
> I hope this helps...
> 

Heisenbug, as I feared. Something gets utterly corrupted, depending on
the code layout. :-/

Let's wait for Philippe's x86_64 back-port to save resources we may need
later on...

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] Xenomai and MSI enabled crashes kernel

[Philippe Gerum]

[-- Attachment #1: Type: text/plain, Size: 927 bytes --]

On Fri, 2007-04-27 at 22:39 +0200, Philippe Gerum wrote:
> On Fri, 2007-04-27 at 17:10 +0200, M. Koehrer wrote:
> > Hi Philippe,
> > 
> > here is the next result (I have switched off the "quiet" kernel parameter to get everything).
> > 
> 
> There is a SMP-related bugfix regarding our IPI namespace I need to
> backport from x86_64 to x86. Not sure this is what bites us here yet,
> but there is no use to chase the wild goose. In any case, CONFIG_PCI_MSI
> clearly worsens the situation regarding this issue.

Here we are, please apply the first patch against a stock I-pipe 1.7-03
kernel, then the second one against a vanilla Xenomai v2.3.x tree.

What the first patch does is moving the system IRQs out of the regular
interrupt namespace wrt Adeos handling, which could solve possible
conflicts whenever CONFIG_PCI_MSI is on. The second patch makes the
Xenomai tree aware of the differentiated namespaces.

-- 
Philippe.


[-- Attachment #2: adeos.patch --]
[-- Type: text/x-patch, Size: 6946 bytes --]

diff --git a/arch/i386/kernel/ipipe.c b/arch/i386/kernel/ipipe.c
index ff45e25..c83a65f 100644
--- a/arch/i386/kernel/ipipe.c
+++ b/arch/i386/kernel/ipipe.c
@@ -207,49 +207,49 @@ void __init __ipipe_enable_pipeline(void)
 	/* Map the APIC system vectors. */
 
 	ipipe_virtualize_irq(ipipe_root_domain,
-			     LOCAL_TIMER_VECTOR - FIRST_EXTERNAL_VECTOR,
+			     ipipe_apic_vector_irq(LOCAL_TIMER_VECTOR),
 			     (ipipe_irq_handler_t)&smp_apic_timer_interrupt,
 			     NULL,
 			     &__ipipe_ack_apic,
 			     IPIPE_STDROOT_MASK);
 
 	ipipe_virtualize_irq(ipipe_root_domain,
-			     SPURIOUS_APIC_VECTOR - FIRST_EXTERNAL_VECTOR,
+			     ipipe_apic_vector_irq(SPURIOUS_APIC_VECTOR),
 			     (ipipe_irq_handler_t)&smp_spurious_interrupt,
 			     NULL,
 			     &__ipipe_noack_apic,
 			     IPIPE_STDROOT_MASK);
 
 	ipipe_virtualize_irq(ipipe_root_domain,
-			     ERROR_APIC_VECTOR - FIRST_EXTERNAL_VECTOR,
+			     ipipe_apic_vector_irq(ERROR_APIC_VECTOR),
 			     (ipipe_irq_handler_t)&smp_error_interrupt,
 			     NULL,
 			     &__ipipe_ack_apic,
 			     IPIPE_STDROOT_MASK);
 
 	ipipe_virtualize_irq(ipipe_root_domain,
-			     IPIPE_SERVICE_VECTOR0 - FIRST_EXTERNAL_VECTOR,
+			     ipipe_apic_vector_irq(IPIPE_SERVICE_VECTOR0),
 			     &__ipipe_null_handler,
 			     NULL,
 			     &__ipipe_ack_apic,
 			     IPIPE_STDROOT_MASK);
 
 	ipipe_virtualize_irq(ipipe_root_domain,
-			     IPIPE_SERVICE_VECTOR1 - FIRST_EXTERNAL_VECTOR,
+			     ipipe_apic_vector_irq(IPIPE_SERVICE_VECTOR1),
 			     &__ipipe_null_handler,
 			     NULL,
 			     &__ipipe_ack_apic,
 			     IPIPE_STDROOT_MASK);
 
 	ipipe_virtualize_irq(ipipe_root_domain,
-			     IPIPE_SERVICE_VECTOR2 - FIRST_EXTERNAL_VECTOR,
+			     ipipe_apic_vector_irq(IPIPE_SERVICE_VECTOR2),
 			     &__ipipe_null_handler,
 			     NULL,
 			     &__ipipe_ack_apic,
 			     IPIPE_STDROOT_MASK);
 
 	ipipe_virtualize_irq(ipipe_root_domain,
-			     IPIPE_SERVICE_VECTOR3 - FIRST_EXTERNAL_VECTOR,
+			     ipipe_apic_vector_irq(IPIPE_SERVICE_VECTOR3),
 			     &__ipipe_null_handler,
 			     NULL,
 			     &__ipipe_ack_apic,
@@ -257,7 +257,7 @@ void __init __ipipe_enable_pipeline(void)
 
 #ifdef CONFIG_X86_MCE_P4THERMAL
 	ipipe_virtualize_irq(ipipe_root_domain,
-			     THERMAL_APIC_VECTOR - FIRST_EXTERNAL_VECTOR,
+			     ipipe_apic_vector_irq(THERMAL_APIC_VECTOR),
 			     (ipipe_irq_handler_t)&smp_thermal_interrupt,
 			     NULL,
 			     &__ipipe_ack_apic,
@@ -265,7 +265,7 @@ void __init __ipipe_enable_pipeline(void)
 #endif /* CONFIG_X86_MCE_P4THERMAL */
 
 	__ipipe_tick_irq =
-	    using_apic_timer ? LOCAL_TIMER_VECTOR - FIRST_EXTERNAL_VECTOR : 0;
+		using_apic_timer ? ipipe_apic_vector_irq(LOCAL_TIMER_VECTOR) : 0;
 
 #else	/* !CONFIG_X86_LOCAL_APIC */
 
@@ -275,21 +275,21 @@ void __init __ipipe_enable_pipeline(void)
 
 #ifdef CONFIG_SMP
 	ipipe_virtualize_irq(ipipe_root_domain,
-			     RESCHEDULE_VECTOR - FIRST_EXTERNAL_VECTOR,
+			     ipipe_apic_vector_irq(RESCHEDULE_VECTOR),
 			     (ipipe_irq_handler_t)&smp_reschedule_interrupt,
 			     NULL,
 			     &__ipipe_ack_apic,
 			     IPIPE_STDROOT_MASK);
 
 	ipipe_virtualize_irq(ipipe_root_domain,
-			     INVALIDATE_TLB_VECTOR - FIRST_EXTERNAL_VECTOR,
+			     ipipe_apic_vector_irq(INVALIDATE_TLB_VECTOR),
 			     (ipipe_irq_handler_t)&smp_invalidate_interrupt,
 			     NULL,
 			     &__ipipe_ack_apic,
 			     IPIPE_STDROOT_MASK);
 
 	ipipe_virtualize_irq(ipipe_root_domain,
-			     CALL_FUNCTION_VECTOR - FIRST_EXTERNAL_VECTOR,
+			     ipipe_apic_vector_irq(CALL_FUNCTION_VECTOR),
 			     (ipipe_irq_handler_t)&smp_call_function_interrupt,
 			     NULL,
 			     &__ipipe_ack_apic,
@@ -772,10 +772,17 @@ int __ipipe_handle_irq(struct pt_regs regs)
 	ipipe_declare_cpuid;
 	int m_ack;
 
-	if (regs.orig_eax < 0) {
+	if ((long)regs.orig_eax < 0) {
 		irq = ~irq;
+#ifdef CONFIG_X86_LOCAL_APIC
+		{
+			unsigned vector = irq + FIRST_EXTERNAL_VECTOR;
+			if (vector >= FIRST_SYSTEM_VECTOR)
+				irq = ipipe_apic_vector_irq(vector);
+		}
+#endif
 		m_ack = 0;
-	} else
+	} else /* This is a self-triggered interrupt. */
 		m_ack = 1;
 
 	ipipe_load_cpuid();
@@ -881,7 +888,7 @@ finalize_nosync:
 	 * preemptible kernels along the way out through
 	 * ret_from_intr.
 	 */
-	if (regs.orig_eax < 0)
+	if ((long)regs.orig_eax < 0)
 		__set_bit(IPIPE_STALL_FLAG, &ipipe_root_domain->cpudata[cpuid].status);
 #endif	/* CONFIG_SMP */
 
diff --git a/include/asm-i386/ipipe.h b/include/asm-i386/ipipe.h
index 43efd34..8a501a9 100644
--- a/include/asm-i386/ipipe.h
+++ b/include/asm-i386/ipipe.h
@@ -27,28 +27,35 @@
 #include <linux/threads.h>
 #include <irq_vectors.h>
 
-#define IPIPE_ARCH_STRING	"1.7-03"
+#define IPIPE_ARCH_STRING	"1.8-devel"
 #define IPIPE_MAJOR_NUMBER	1
-#define IPIPE_MINOR_NUMBER	7
-#define IPIPE_PATCH_NUMBER	3
+#define IPIPE_MINOR_NUMBER	7
+#define IPIPE_PATCH_NUMBER	99
 
 #ifdef CONFIG_X86_LOCAL_APIC
-/* We want to cover the whole IRQ space when the APIC is enabled. */
-#ifdef CONFIG_PCI_MSI
-#define IPIPE_NR_XIRQS NR_IRQS
-#else	/* CONFIG_PCI_MSI */
-#define IPIPE_NR_XIRQS   224
-#endif	/* CONFIG_PCI_MSI */
+/* We want to cover the whole IRQ space when the APIC is enabled.
+   Reserve 32 IRQs for APIC interrupts, we don't want them to mess
+   with the normally assigned interrupts.*/
+#if (NR_IRQS > 16)
+#define IPIPE_NR_XIRQS		(NR_IRQS + 32)
+#define IPIPE_FIRST_APIC_IRQ	NR_IRQS
+#else
+#define IPIPE_NR_XIRQS		256
+#define IPIPE_FIRST_APIC_IRQ	224
+#endif
+#define ipipe_apic_irq_vector(irq)  ((irq) - IPIPE_FIRST_APIC_IRQ + FIRST_SYSTEM_VECTOR)
+#define ipipe_apic_vector_irq(vec)  ((vec) - FIRST_SYSTEM_VECTOR + IPIPE_FIRST_APIC_IRQ)
+
 /* If the APIC is enabled, then we expose four service vectors in the
    APIC space which are freely available to domains. */
 #define IPIPE_SERVICE_VECTOR0	0xf5
-#define IPIPE_SERVICE_IPI0	(IPIPE_SERVICE_VECTOR0 - FIRST_EXTERNAL_VECTOR)
+#define IPIPE_SERVICE_IPI0	ipipe_apic_vector_irq(IPIPE_SERVICE_VECTOR0)
 #define IPIPE_SERVICE_VECTOR1	0xf6
-#define IPIPE_SERVICE_IPI1	(IPIPE_SERVICE_VECTOR1 - FIRST_EXTERNAL_VECTOR)
+#define IPIPE_SERVICE_IPI1	ipipe_apic_vector_irq(IPIPE_SERVICE_VECTOR1)
 #define IPIPE_SERVICE_VECTOR2	0xf7
-#define IPIPE_SERVICE_IPI2	(IPIPE_SERVICE_VECTOR2 - FIRST_EXTERNAL_VECTOR)
+#define IPIPE_SERVICE_IPI2	ipipe_apic_vector_irq(IPIPE_SERVICE_VECTOR2)
 #define IPIPE_SERVICE_VECTOR3	0xf8
-#define IPIPE_SERVICE_IPI3	(IPIPE_SERVICE_VECTOR3 - FIRST_EXTERNAL_VECTOR)
+#define IPIPE_SERVICE_IPI3	ipipe_apic_vector_irq(IPIPE_SERVICE_VECTOR3)
 #else	/* !CONFIG_X86_LOCAL_APIC */
 #define IPIPE_NR_XIRQS		NR_IRQS
 #endif	/* CONFIG_X86_LOCAL_APIC */
@@ -93,7 +100,7 @@
 #include <linux/thread_info.h>
 
 #define IPIPE_CRITICAL_VECTOR  0xf9	/* Used by ipipe_critical_enter/exit() */
-#define IPIPE_CRITICAL_IPI     (IPIPE_CRITICAL_VECTOR - FIRST_EXTERNAL_VECTOR)
+#define IPIPE_CRITICAL_IPI     ipipe_apic_vector_irq(IPIPE_CRITICAL_VECTOR)
 
 extern int (*__ipipe_logical_cpuid)(void);
 

[-- Attachment #3: xeno.patch --]
[-- Type: text/x-patch, Size: 2241 bytes --]

Index: include/asm-i386/bits/shadow.h
===================================================================
--- include/asm-i386/bits/shadow.h	(revision 2395)
+++ include/asm-i386/bits/shadow.h	(working copy)
@@ -56,9 +56,9 @@
 		switch (irq) {
 #ifdef CONFIG_SMP
 		case RTHAL_CRITICAL_IPI:
-		case INVALIDATE_TLB_VECTOR - FIRST_EXTERNAL_VECTOR:
-		case CALL_FUNCTION_VECTOR - FIRST_EXTERNAL_VECTOR:
-		case RESCHEDULE_VECTOR - FIRST_EXTERNAL_VECTOR:
+		case ipipe_apic_vector_irq(INVALIDATE_TLB_VECTOR):
+		case ipipe_apic_vector_irq(CALL_FUNCTION_VECTOR):
+		case ipipe_apic_vector_irq(RESCHEDULE_VECTOR):
 
 			/* Never lock out these ones. */
 			continue;
@@ -79,9 +79,9 @@
 		switch (irq) {
 #ifdef CONFIG_SMP
 		case RTHAL_CRITICAL_IPI:
-		case INVALIDATE_TLB_VECTOR - FIRST_EXTERNAL_VECTOR:
-		case CALL_FUNCTION_VECTOR - FIRST_EXTERNAL_VECTOR:
-		case RESCHEDULE_VECTOR - FIRST_EXTERNAL_VECTOR:
+		case ipipe_apic_vector_irq(INVALIDATE_TLB_VECTOR):
+		case ipipe_apic_vector_irq(CALL_FUNCTION_VECTOR):
+		case ipipe_apic_vector_irq(RESCHEDULE_VECTOR):
 
 			continue;
 #endif /* CONFIG_SMP */
Index: include/asm-i386/hal.h
===================================================================
--- include/asm-i386/hal.h	(revision 2395)
+++ include/asm-i386/hal.h	(working copy)
@@ -142,6 +142,11 @@
 #define RTHAL_APIC_TIMER_IPI       RTHAL_SERVICE_IPI3
 #define RTHAL_APIC_ICOUNT          ((RTHAL_TIMER_FREQ + HZ/2)/HZ)
 #define RTHAL_TIMER_IRQ 	   RTHAL_APIC_TIMER_IPI
+#ifndef ipipe_apic_vector_irq
+/* Older I-pipe versions do not differentiate the normal IRQ space
+   from the system IRQ range, which is wrong... */
+#define ipipe_apic_vector_irq(vec) (vec - FIRST_EXTERNAL_VECTOR)
+#endif
 #else  /* !CONFIG_X86_LOCAL_APIC */
 #define RTHAL_TIMER_IRQ		   RTHAL_8254_IRQ
 #endif /* CONFIG_X86_LOCAL_APIC */
Index: ksrc/arch/i386/hal.c
===================================================================
--- ksrc/arch/i386/hal.c	(revision 2395)
+++ ksrc/arch/i386/hal.c	(working copy)
@@ -165,7 +165,7 @@
 #ifdef CONFIG_SMP
 	send_IPI_all(LOCAL_TIMER_VECTOR);
 #else
-	rthal_trigger_irq(LOCAL_TIMER_VECTOR -  FIRST_EXTERNAL_VECTOR);
+	rthal_trigger_irq(ipipe_apic_vector_irq(LOCAL_TIMER_VECTOR));
 #endif
 	return IRQ_HANDLED;
 }

Re: [Xenomai-help] Xenomai and MSI enabled crashes kernel

[M. Koehrer]

Hi Philippe,

I have applied the patches as proposed.
However, the kernel still freezes.
Here is the corresponding message.

Regards

Mathias
======================================================
Intel(R) PRO/1000 Network Driver - version 7.3.15-k2
Copyright (c) 1999-2006 Intel Corporation.
ACPI: PCI Interrupt 0000:05:00.0[A] -> GSI 16 (level, low) -> IRQ 16
e1000: 0000:05:00.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1) 00:30:48:5a:f9:0a
e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
BUG: unable to handle kernel NULL pointer dereference at virtual address 00000000
 printing eip:
00000000
*pde = 00000000
Oops: 0000 [#1]
SMP
Modules linked in: e1000
CPU:    0
EIP:    0060:[<00000000>]    Not tainted VLI
EFLAGS: 00010086   (2.6.20.4 #6)
EIP is at _stext+0x3feffc70/0x14
eax: c01123d4   ebx: 00000007   ecx: c01144dd   edx: dfbd2000
esi: 00000006   edi: 00000046   ebp: ffffffff   esp: dfbd3e20
ds: 007b   es: 007b   ss: 0068
Process ifconfig (pid: 1241, ti=dfbd2000 task=c1632030 task.ti=dfbd2000)
Stack: c03e6f00 000000ec 00000000 c03d9180 c010f110 00007600 00000001 00000060
       e099a1ed 00000286 ffffff24 df7575c8 00000000 0000000f 00000001 c01035b9
       df7575c8 e099a0ff e09c0000 00000000 0000000f 00000001 80080740 dfd1007b
Call Trace:
 [<c010f110>] __ipipe_handle_irq+0x1c6/0x218
 [<e099a1ed>] e1000_set_multi+0xee/0x189 [e1000]
 [<c01035b9>] common_interrupt+0x21/0x38
 [<e099a0ff>] e1000_set_multi+0x0/0x189 [e1000]
 [<e099a1ed>] e1000_set_multi+0xee/0x189 [e1000]
 [<c02dd111>] __dev_mc_upload+0x1d/0x1e
 [<c02dd231>] dev_mc_upload+0x24/0x37
 [<c02db73c>] dev_open+0x44/0x62
 [<c02da209>] dev_change_flags+0x47/0xe4
 [<c030d322>] devinet_ioctl+0x252/0x56f
 [<c02db31a>] dev_ifsioc+0x113/0x38d
 [<c02d1734>] sock_ioctl+0x0/0x1ad
 [<c02d18c2>] sock_ioctl+0x18e/0x1ad
 [<c02d1734>] sock_ioctl+0x0/0x1ad
 [<c015e31f>] do_ioctl+0x1f/0x62
 [<c015e5a6>] vfs_ioctl+0x244/0x256
 [<c015e5eb>] sys_ioctl+0x33/0x4c
 [<c01029f3>] sysenter_past_esp+0x6c/0x70
 =======================
Code:  Bad EIP value.
EIP: [<00000000>] _stext+0x3feffc70/0x14 SS:ESP 0068:dfbd3e20
 <0>Kernel panic - not syncing: Fatal exception in interrupt
 BUG: at arch/i386/kernel/smp.c:565 smp_call_function()
 [<c010ba83>] smp_call_function+0x66/0x10a
 [<c0118fa2>] printk+0x62/0xd5
 [<c010bb42>] smp_send_stop+0x1b/0x2b
 [<c011853d>] panic+0x4d/0xe4
 [<c01040f1>] die+0x1f2/0x226
 [<c011180c>] do_page_fault+0x447/0x517
 [<c010f7aa>] __ipipe_handle_exception+0xce/0x158
 [<c010bc9e>] smp_call_function_interrupt+0x31/0x4c
 [<c03334fd>] error_code+0x81/0x90
 [<c01144dd>] try_to_wake_up+0x33c/0x346
 [<c01123d4>] __activate_task+0x1c/0x29
 [<c010f110>] __ipipe_handle_irq+0x1c6/0x218
 [<e099a1ed>] e1000_set_multi+0xee/0x189 [e1000]
 [<c01035b9>] common_interrupt+0x21/0x38
 [<e099a0ff>] e1000_set_multi+0x0/0x189 [e1000]
 [<e099a1ed>] e1000_set_multi+0xee/0x189 [e1000]
 [<c02dd111>] __dev_mc_upload+0x1d/0x1e
 [<c02dd231>] dev_mc_upload+0x24/0x37
 [<c02db73c>] dev_open+0x44/0x62
 [<c02da209>] dev_change_flags+0x47/0xe4
 [<c030d322>] devinet_ioctl+0x252/0x56f
 [<c02db31a>] dev_ifsioc+0x113/0x38d
 [<c02d1734>] sock_ioctl+0x0/0x1ad
 [<c02d18c2>] sock_ioctl+0x18e/0x1ad
 [<c02d1734>] sock_ioctl+0x0/0x1ad
 [<c015e31f>] do_ioctl+0x1f/0x62
 [<c015e5a6>] vfs_ioctl+0x244/0x256
 [<c015e5eb>] sys_ioctl+0x33/0x4c
 [<c01029f3>] sysenter_past_esp+0x6c/0x70
 =======================


> On Fri, 2007-04-27 at 22:39 +0200, Philippe Gerum wrote:
> > On Fri, 2007-04-27 at 17:10 +0200, M. Koehrer wrote:
> > > Hi Philippe,
> > > 
> > > here is the next result (I have switched off the "quiet" kernel
> parameter to get everything).
> > > 
> > 
> > There is a SMP-related bugfix regarding our IPI namespace I need to
> > backport from x86_64 to x86. Not sure this is what bites us here yet,
> > but there is no use to chase the wild goose. In any case, CONFIG_PCI_MSI
> > clearly worsens the situation regarding this issue.
> 
> Here we are, please apply the first patch against a stock I-pipe 1.7-03
> kernel, then the second one against a vanilla Xenomai v2.3.x tree.
> 
> What the first patch does is moving the system IRQs out of the regular
> interrupt namespace wrt Adeos handling, which could solve possible
> conflicts whenever CONFIG_PCI_MSI is on. The second patch makes the
> Xenomai tree aware of the differentiated namespaces.
> 
> -- 
> Philippe.
> 
> 

-- 
Mathias Koehrer
mathias_koehrer@domain.hid


50€ AMAZON-Einkaufsgutschein bei Bestellung von Arcor-DSL:
Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren
ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT JETZT bei Arcor: günstig
und schnell mit DSL - das All-Inclusive-Paket für clevere Doppel-Sparer,
nur  39,85 €  inkl. DSL- und ISDN-Grundgebühr!
http://www.arcor.de/rd/emf-dsl-2

Re: [Xenomai-help] Xenomai and MSI enabled crashes kernel

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2553 bytes --]

M. Koehrer wrote:
> Hi Philippe,
> 
> I have applied the patches as proposed.
> However, the kernel still freezes.

:(

> Here is the corresponding message.
> 

OK, here is another instrumentation, hoping that the bug will not move
again and that we can nail down what piece of memory contains nonsense.

The next step would then be to narrow down the corruption window (or to
find the reason for filling in nonsense during initialisation).

Jan


Index: linux-2.6.20/arch/i386/kernel/ipipe.c
===================================================================
--- linux-2.6.20.orig/arch/i386/kernel/ipipe.c
+++ linux-2.6.20/arch/i386/kernel/ipipe.c
@@ -782,6 +782,13 @@ int __ipipe_handle_irq(struct pt_regs re
 
 	head = __ipipe_pipeline.next;
 	next_domain = list_entry(head, struct ipipe_domain, p_link);
+	if (irq==219) {
+		ipipe_set_printk_sync(next_domain);
+		printk("%s:%d\n", __FUNCTION__, __LINE__);
+		printk("%s:%d %lx %p %p\n", __FUNCTION__, __LINE__,
+			ipipe_root.irqs[irq].control, ipipe_root.irqs[irq].acknowledge,
+			ipipe_root.irqs[irq].handler);
+	}
 	if (likely(test_bit(IPIPE_WIRED_FLAG, &next_domain->irqs[irq].control))) {
 		if (!m_ack && next_domain->irqs[irq].acknowledge != NULL)
 			next_domain->irqs[irq].acknowledge(irq);
@@ -865,6 +872,10 @@ finalize:
 	 * current domain in the pipeline.
 	 */
 
+	if (irq==219)
+		printk("%s:%d %lx %p %p\n", __FUNCTION__, __LINE__,
+			ipipe_root.irqs[irq].control, ipipe_root.irqs[irq].acknowledge,
+			ipipe_root.irqs[irq].handler);
 	__ipipe_walk_pipeline(head, cpuid);
 
 	ipipe_load_cpuid();
Index: linux-2.6.20/kernel/ipipe/core.c
===================================================================
--- linux-2.6.20.orig/kernel/ipipe/core.c
+++ linux-2.6.20/kernel/ipipe/core.c
@@ -791,6 +791,11 @@ void fastcall __ipipe_sync_stage(unsigne
 			rank = __ipipe_ffnz(submask);
 			irq = (level << IPIPE_IRQ_ISHIFT) + rank;
 
+			if (irq==219)
+				printk("%s:%d %lx %p %p\n", __FUNCTION__, __LINE__,
+					ipipe_root.irqs[irq].control,
+					ipipe_root.irqs[irq].acknowledge,
+					ipipe_root.irqs[irq].handler);
 			if (test_bit(IPIPE_LOCK_FLAG, &ipd->irqs[irq].control)) {
 				__clear_bit(rank, &cpudata->irq_pending_lo[level]);
 				continue;
@@ -807,6 +812,8 @@ void fastcall __ipipe_sync_stage(unsigne
 			if (ipd == ipipe_root_domain)
 				trace_hardirqs_off();
 
+			if (irq==219)
+				printk("%s:%d\n", __FUNCTION__, __LINE__);
 			__ipipe_run_isr(ipd, irq, cpuid);
 #ifdef CONFIG_SMP
 			{



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] Xenomai and MSI enabled crashes kernel

[M. Koehrer]

Hi Jan,

here is the result of this patch.
I patched in addition to Philippe's patches.

Regards

Mathias
---------
Intel(R) PRO/1000 Network Driver - version 7.3.15-k2
Copyright (c) 1999-2006 Intel Corporation.
ACPI: PCI Interrupt 0000:05:00.0[A] -> GSI 16 (level, low) -> IRQ 16
e1000: 0000:05:00.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1) 00:30:48:5a:f9:0a
e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
BUG: unable to handle kernel NULL pointer dereference at virtual address 00000000
 printing eip:
dfedd3ca
*pde = 00000000
Oops: 0000 [#1]
SMP
Modules linked in: e1000
CPU:    0
EIP:    0060:[<dfedd3ca>]    Not tainted VLI
EFLAGS: 00010082   (2.6.20.4 #7)
EIP is at 0xdfedd3ca
eax: c0112478   ebx: 00000001   ecx: c0114581   edx: df06c001
esi: dfedf6c0   edi: dfedc240   ebp: 00000000   esp: df06ddf8
ds: 007b   es: 007b   ss: 0068
Process ifconfig (pid: 1242, ti=df06c000 task=c16f9030 task.ti=df06c000)
Stack: 00000040 ffffffff 00000000 00000007 c03e6f00 000000ec 00000000 c03d9180
       c010f1b5 c015291a decbe080 00000680 decbe080 00000724 c02d6dfd 00007600
       00000001 00000060 e099a210 00000286 ffffff24 df7065c8 00000000 0000000f
Call Trace:
 [<c010f1b5>] __ipipe_handle_irq+0x26b/0x2bd
 [<c015291a>] __kmalloc+0x82/0x8d
 [<c02d6dfd>] __alloc_skb+0x4f/0xf8
 [<e099a210>] e1000_set_multi+0x111/0x189 [e1000]
 [<c01035b9>] common_interrupt+0x21/0x38
 [<e099a0ff>] e1000_set_multi+0x0/0x189 [e1000]
 [<e099a210>] e1000_set_multi+0x111/0x189 [e1000]
 [<c02dd211>] __dev_mc_upload+0x1d/0x1e
 [<c02dd331>] dev_mc_upload+0x24/0x37
 [<c02db83c>] dev_open+0x44/0x62
 [<c02da309>] dev_change_flags+0x47/0xe4
 [<c030d422>] devinet_ioctl+0x252/0x56f
 [<c02db41a>] dev_ifsioc+0x113/0x38d
 [<c02d1834>] sock_ioctl+0x0/0x1ad
 [<c02d19c2>] sock_ioctl+0x18e/0x1ad
 [<c02d1834>] sock_ioctl+0x0/0x1ad
 [<c015e41b>] do_ioctl+0x1f/0x62
 [<c015e6a2>] vfs_ioctl+0x244/0x256
 [<c015e6e7>] sys_ioctl+0x33/0x4c
 [<c01029f3>] sysenter_past_esp+0x6c/0x70
 =======================
Code: 00 00 00 00 00 01 00 00 00 00 90 ed df 04 03 02 01 6b ec fe ff 00 00 00 00 00 00 00 00 00 00 00 00 c0 d3 ed df c0 d3 ed df 00 42 <c9> de 00 db ed df d0 d3 ed df d0 d3 ed df 00 00 00 00 1a 00 00
EIP: [<dfedd3ca>] 0xdfedd3ca SS:ESP 0068:df06ddf8
 <0>Kernel panic - not syncing: Fatal exception in interrupt
 BUG: at arch/i386/kernel/smp.c:565 smp_call_function()
 [<c010ba83>] smp_call_function+0x66/0x10a
 [<c0119046>] printk+0x62/0xd5
 [<c010bb42>] smp_send_stop+0x1b/0x2b
 [<c01185e1>] panic+0x4d/0xe4
 [<c01040f1>] die+0x1f2/0x226
 [<c01118b0>] do_page_fault+0x447/0x517
 [<c010f84f>] __ipipe_handle_exception+0xce/0x158
 [<c03335fd>] error_code+0x81/0x90
 [<c0114581>] try_to_wake_up+0x33c/0x346
 [<c0112478>] __activate_task+0x1c/0x29
 [<c010f1b5>] __ipipe_handle_irq+0x26b/0x2bd
 [<c015291a>] __kmalloc+0x82/0x8d
 [<c02d6dfd>] __alloc_skb+0x4f/0xf8
 [<e099a210>] e1000_set_multi+0x111/0x189 [e1000]
 [<c01035b9>] common_interrupt+0x21/0x38
 [<e099a0ff>] e1000_set_multi+0x0/0x189 [e1000]
 [<e099a210>] e1000_set_multi+0x111/0x189 [e1000]
 [<c02dd211>] __dev_mc_upload+0x1d/0x1e
 [<c02dd331>] dev_mc_upload+0x24/0x37
 [<c02db83c>] dev_open+0x44/0x62
 [<c02da309>] dev_change_flags+0x47/0xe4
 [<c030d422>] devinet_ioctl+0x252/0x56f
 [<c02db41a>] dev_ifsioc+0x113/0x38d
 [<c02d1834>] sock_ioctl+0x0/0x1ad
 [<c02d19c2>] sock_ioctl+0x18e/0x1ad
 [<c02d1834>] sock_ioctl+0x0/0x1ad
 [<c015e41b>] do_ioctl+0x1f/0x62
 [<c015e6a2>] vfs_ioctl+0x244/0x256
 [<c015e6e7>] sys_ioctl+0x33/0x4c
 [<c01029f3>] sysenter_past_esp+0x6c/0x70
 =======================
 

----- Original Nachricht ----
Von:     Jan Kiszka <jan.kiszka@domain.hid>
An:      "M. Koehrer" <mathias_koehrer@domain.hid>
Datum:   02.05.2007 10:39
Betreff: Re: [Xenomai-help] Xenomai and MSI enabled crashes kernel

> M. Koehrer wrote:
> > Hi Philippe,
> > 
> > I have applied the patches as proposed.
> > However, the kernel still freezes.
> 
> :(
> 
> > Here is the corresponding message.
> > 
> 
> OK, here is another instrumentation, hoping that the bug will not move
> again and that we can nail down what piece of memory contains nonsense.
> 
> The next step would then be to narrow down the corruption window (or to
> find the reason for filling in nonsense during initialisation).
> 
> Jan
> 
> 
> Index: linux-2.6.20/arch/i386/kernel/ipipe.c
> ===================================================================
> --- linux-2.6.20.orig/arch/i386/kernel/ipipe.c
> +++ linux-2.6.20/arch/i386/kernel/ipipe.c
> @@ -782,6 +782,13 @@ int __ipipe_handle_irq(struct pt_regs re
>  
>  	head = __ipipe_pipeline.next;
>  	next_domain = list_entry(head, struct ipipe_domain, p_link);
> +	if (irq==219) {
> +		ipipe_set_printk_sync(next_domain);
> +		printk("%s:%d\n", __FUNCTION__, __LINE__);
> +		printk("%s:%d %lx %p %p\n", __FUNCTION__, __LINE__,
> +			ipipe_root.irqs[irq].control, ipipe_root.irqs[irq].acknowledge,
> +			ipipe_root.irqs[irq].handler);
> +	}
>  	if (likely(test_bit(IPIPE_WIRED_FLAG, &next_domain->irqs[irq].control)))
> {
>  		if (!m_ack && next_domain->irqs[irq].acknowledge != NULL)
>  			next_domain->irqs[irq].acknowledge(irq);
> @@ -865,6 +872,10 @@ finalize:
>  	 * current domain in the pipeline.
>  	 */
>  
> +	if (irq==219)
> +		printk("%s:%d %lx %p %p\n", __FUNCTION__, __LINE__,
> +			ipipe_root.irqs[irq].control, ipipe_root.irqs[irq].acknowledge,
> +			ipipe_root.irqs[irq].handler);
>  	__ipipe_walk_pipeline(head, cpuid);
>  
>  	ipipe_load_cpuid();
> Index: linux-2.6.20/kernel/ipipe/core.c
> ===================================================================
> --- linux-2.6.20.orig/kernel/ipipe/core.c
> +++ linux-2.6.20/kernel/ipipe/core.c
> @@ -791,6 +791,11 @@ void fastcall __ipipe_sync_stage(unsigne
>  			rank = __ipipe_ffnz(submask);
>  			irq = (level << IPIPE_IRQ_ISHIFT) + rank;
>  
> +			if (irq==219)
> +				printk("%s:%d %lx %p %p\n", __FUNCTION__, __LINE__,
> +					ipipe_root.irqs[irq].control,
> +					ipipe_root.irqs[irq].acknowledge,
> +					ipipe_root.irqs[irq].handler);
>  			if (test_bit(IPIPE_LOCK_FLAG, &ipd->irqs[irq].control)) {
>  				__clear_bit(rank, &cpudata->irq_pending_lo[level]);
>  				continue;
> @@ -807,6 +812,8 @@ void fastcall __ipipe_sync_stage(unsigne
>  			if (ipd == ipipe_root_domain)
>  				trace_hardirqs_off();
>  
> +			if (irq==219)
> +				printk("%s:%d\n", __FUNCTION__, __LINE__);
>  			__ipipe_run_isr(ipd, irq, cpuid);
>  #ifdef CONFIG_SMP
>  			{
> 
> 
> 

-- 
Mathias Koehrer
mathias_koehrer@domain.hid


50€ AMAZON-Einkaufsgutschein bei Bestellung von Arcor-DSL:
Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren
ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT JETZT bei Arcor: günstig
und schnell mit DSL - das All-Inclusive-Paket für clevere Doppel-Sparer,
nur  39,85 €  inkl. DSL- und ISDN-Grundgebühr!
http://www.arcor.de/rd/emf-dsl-2

Re: [Xenomai-help] Xenomai and MSI enabled crashes kernel

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1721 bytes --]

M. Koehrer wrote:
> Hi Jan,
> 
> here is the result of this patch.
> I patched in addition to Philippe's patches.
> 
> Regards
> 
> Mathias
> ---------
> Intel(R) PRO/1000 Network Driver - version 7.3.15-k2
> Copyright (c) 1999-2006 Intel Corporation.
> ACPI: PCI Interrupt 0000:05:00.0[A] -> GSI 16 (level, low) -> IRQ 16
> e1000: 0000:05:00.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1) 00:30:48:5a:f9:0a
> e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
> BUG: unable to handle kernel NULL pointer dereference at virtual address 00000000
>  printing eip:
> dfedd3ca
> *pde = 00000000
> Oops: 0000 [#1]
> SMP
> Modules linked in: e1000
> CPU:    0
> EIP:    0060:[<dfedd3ca>]    Not tainted VLI
> EFLAGS: 00010082   (2.6.20.4 #7)
> EIP is at 0xdfedd3ca
> eax: c0112478   ebx: 00000001   ecx: c0114581   edx: df06c001
> esi: dfedf6c0   edi: dfedc240   ebp: 00000000   esp: df06ddf8
> ds: 007b   es: 007b   ss: 0068
> Process ifconfig (pid: 1242, ti=df06c000 task=c16f9030 task.ti=df06c000)
> Stack: 00000040 ffffffff 00000000 00000007 c03e6f00 000000ec 00000000 c03d9180
>        c010f1b5 c015291a decbe080 00000680 decbe080 00000724 c02d6dfd 00007600
>        00000001 00000060 e099a210 00000286 ffffff24 df7065c8 00000000 0000000f
> Call Trace:
>  [<c010f1b5>] __ipipe_handle_irq+0x26b/0x2bd

I must have patched crap into this, but I don't see it. Could someone
have a look why there is no printk output related to #IRQ 219
(~0xffffff24, see stack content)?

BTW, Mathias, forcing your kernel into single CPU mode via kernel
command line "cpus=1" doesn't expose the issue, right? Could we face
some kind of setup race across the CPUs here?

Thanks,
Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] Xenomai and MSI enabled crashes kernel

[Philippe Gerum]

On Wed, 2007-05-02 at 11:14 +0200, M. Koehrer wrote:
> Hi Jan,
> 
> here is the result of this patch.
> I patched in addition to Philippe's patches.
> 
> Regards
> 
> Mathias
> ---------
> Intel(R) PRO/1000 Network Driver - version 7.3.15-k2
> Copyright (c) 1999-2006 Intel Corporation.
> ACPI: PCI Interrupt 0000:05:00.0[A] -> GSI 16 (level, low) -> IRQ 16
> e1000: 0000:05:00.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1) 00:30:48:5a:f9:0a
> e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
> BUG: unable to handle kernel NULL pointer dereference at virtual address 00000000
>  printing eip:
> dfedd3ca

The following options are needed to get a reliable backtrace, make sure
to have them on:

CONFIG_DEBUG_KERNEL=y
CONFIG_FRAME_POINTER=y

I also need the kernel disassembly; please send this privately to me
(output of "objdump -d vmlinux"). Make sure to attach the boot log for
this kernel as it fails, since code offsets listed in the backtrace are
going to move with the above options enabled.

Additionally, does the problem persist if you disable CONFIG_XENOMAI,
but still leave CONFIG_IPIPE on?

> *pde = 00000000
> Oops: 0000 [#1]
> SMP
> Modules linked in: e1000
> CPU:    0
> EIP:    0060:[<dfedd3ca>]    Not tainted VLI
> EFLAGS: 00010082   (2.6.20.4 #7)
> EIP is at 0xdfedd3ca
> eax: c0112478   ebx: 00000001   ecx: c0114581   edx: df06c001
> esi: dfedf6c0   edi: dfedc240   ebp: 00000000   esp: df06ddf8
> ds: 007b   es: 007b   ss: 0068
> Process ifconfig (pid: 1242, ti=df06c000 task=c16f9030 task.ti=df06c000)
> Stack: 00000040 ffffffff 00000000 00000007 c03e6f00 000000ec 00000000 c03d9180
>        c010f1b5 c015291a decbe080 00000680 decbe080 00000724 c02d6dfd 00007600
>        00000001 00000060 e099a210 00000286 ffffff24 df7065c8 00000000 0000000f
> Call Trace:
>  [<c010f1b5>] __ipipe_handle_irq+0x26b/0x2bd
>  [<c015291a>] __kmalloc+0x82/0x8d
>  [<c02d6dfd>] __alloc_skb+0x4f/0xf8
>  [<e099a210>] e1000_set_multi+0x111/0x189 [e1000]
>  [<c01035b9>] common_interrupt+0x21/0x38
>  [<e099a0ff>] e1000_set_multi+0x0/0x189 [e1000]
>  [<e099a210>] e1000_set_multi+0x111/0x189 [e1000]
>  [<c02dd211>] __dev_mc_upload+0x1d/0x1e
>  [<c02dd331>] dev_mc_upload+0x24/0x37
>  [<c02db83c>] dev_open+0x44/0x62
>  [<c02da309>] dev_change_flags+0x47/0xe4
>  [<c030d422>] devinet_ioctl+0x252/0x56f
>  [<c02db41a>] dev_ifsioc+0x113/0x38d
>  [<c02d1834>] sock_ioctl+0x0/0x1ad
>  [<c02d19c2>] sock_ioctl+0x18e/0x1ad
>  [<c02d1834>] sock_ioctl+0x0/0x1ad
>  [<c015e41b>] do_ioctl+0x1f/0x62
>  [<c015e6a2>] vfs_ioctl+0x244/0x256
>  [<c015e6e7>] sys_ioctl+0x33/0x4c
>  [<c01029f3>] sysenter_past_esp+0x6c/0x70
>  =======================
> Code: 00 00 00 00 00 01 00 00 00 00 90 ed df 04 03 02 01 6b ec fe ff 00 00 00 00 00 00 00 00 00 00 00 00 c0 d3 ed df c0 d3 ed df 00 42 <c9> de 00 db ed df d0 d3 ed df d0 d3 ed df 00 00 00 00 1a 00 00
> EIP: [<dfedd3ca>] 0xdfedd3ca SS:ESP 0068:df06ddf8
>  <0>Kernel panic - not syncing: Fatal exception in interrupt
>  BUG: at arch/i386/kernel/smp.c:565 smp_call_function()
>  [<c010ba83>] smp_call_function+0x66/0x10a
>  [<c0119046>] printk+0x62/0xd5
>  [<c010bb42>] smp_send_stop+0x1b/0x2b
>  [<c01185e1>] panic+0x4d/0xe4
>  [<c01040f1>] die+0x1f2/0x226
>  [<c01118b0>] do_page_fault+0x447/0x517
>  [<c010f84f>] __ipipe_handle_exception+0xce/0x158
>  [<c03335fd>] error_code+0x81/0x90
>  [<c0114581>] try_to_wake_up+0x33c/0x346
>  [<c0112478>] __activate_task+0x1c/0x29
>  [<c010f1b5>] __ipipe_handle_irq+0x26b/0x2bd
>  [<c015291a>] __kmalloc+0x82/0x8d
>  [<c02d6dfd>] __alloc_skb+0x4f/0xf8
>  [<e099a210>] e1000_set_multi+0x111/0x189 [e1000]
>  [<c01035b9>] common_interrupt+0x21/0x38
>  [<e099a0ff>] e1000_set_multi+0x0/0x189 [e1000]
>  [<e099a210>] e1000_set_multi+0x111/0x189 [e1000]
>  [<c02dd211>] __dev_mc_upload+0x1d/0x1e
>  [<c02dd331>] dev_mc_upload+0x24/0x37
>  [<c02db83c>] dev_open+0x44/0x62
>  [<c02da309>] dev_change_flags+0x47/0xe4
>  [<c030d422>] devinet_ioctl+0x252/0x56f
>  [<c02db41a>] dev_ifsioc+0x113/0x38d
>  [<c02d1834>] sock_ioctl+0x0/0x1ad
>  [<c02d19c2>] sock_ioctl+0x18e/0x1ad
>  [<c02d1834>] sock_ioctl+0x0/0x1ad
>  [<c015e41b>] do_ioctl+0x1f/0x62
>  [<c015e6a2>] vfs_ioctl+0x244/0x256
>  [<c015e6e7>] sys_ioctl+0x33/0x4c
>  [<c01029f3>] sysenter_past_esp+0x6c/0x70
>  =======================
>  
> 
> ----- Original Nachricht ----
> Von:     Jan Kiszka <jan.kiszka@domain.hid>
> An:      "M. Koehrer" <mathias_koehrer@domain.hid>
> Datum:   02.05.2007 10:39
> Betreff: Re: [Xenomai-help] Xenomai and MSI enabled crashes kernel
> 
> > M. Koehrer wrote:
> > > Hi Philippe,
> > > 
> > > I have applied the patches as proposed.
> > > However, the kernel still freezes.
> > 
> > :(
> > 
> > > Here is the corresponding message.
> > > 
> > 
> > OK, here is another instrumentation, hoping that the bug will not move
> > again and that we can nail down what piece of memory contains nonsense.
> > 
> > The next step would then be to narrow down the corruption window (or to
> > find the reason for filling in nonsense during initialisation).
> > 
> > Jan
> > 
> > 
> > Index: linux-2.6.20/arch/i386/kernel/ipipe.c
> > ===================================================================
> > --- linux-2.6.20.orig/arch/i386/kernel/ipipe.c
> > +++ linux-2.6.20/arch/i386/kernel/ipipe.c
> > @@ -782,6 +782,13 @@ int __ipipe_handle_irq(struct pt_regs re
> >  
> >  	head = __ipipe_pipeline.next;
> >  	next_domain = list_entry(head, struct ipipe_domain, p_link);
> > +	if (irq==219) {
> > +		ipipe_set_printk_sync(next_domain);
> > +		printk("%s:%d\n", __FUNCTION__, __LINE__);
> > +		printk("%s:%d %lx %p %p\n", __FUNCTION__, __LINE__,
> > +			ipipe_root.irqs[irq].control, ipipe_root.irqs[irq].acknowledge,
> > +			ipipe_root.irqs[irq].handler);
> > +	}
> >  	if (likely(test_bit(IPIPE_WIRED_FLAG, &next_domain->irqs[irq].control)))
> > {
> >  		if (!m_ack && next_domain->irqs[irq].acknowledge != NULL)
> >  			next_domain->irqs[irq].acknowledge(irq);
> > @@ -865,6 +872,10 @@ finalize:
> >  	 * current domain in the pipeline.
> >  	 */
> >  
> > +	if (irq==219)
> > +		printk("%s:%d %lx %p %p\n", __FUNCTION__, __LINE__,
> > +			ipipe_root.irqs[irq].control, ipipe_root.irqs[irq].acknowledge,
> > +			ipipe_root.irqs[irq].handler);
> >  	__ipipe_walk_pipeline(head, cpuid);
> >  
> >  	ipipe_load_cpuid();
> > Index: linux-2.6.20/kernel/ipipe/core.c
> > ===================================================================
> > --- linux-2.6.20.orig/kernel/ipipe/core.c
> > +++ linux-2.6.20/kernel/ipipe/core.c
> > @@ -791,6 +791,11 @@ void fastcall __ipipe_sync_stage(unsigne
> >  			rank = __ipipe_ffnz(submask);
> >  			irq = (level << IPIPE_IRQ_ISHIFT) + rank;
> >  
> > +			if (irq==219)
> > +				printk("%s:%d %lx %p %p\n", __FUNCTION__, __LINE__,
> > +					ipipe_root.irqs[irq].control,
> > +					ipipe_root.irqs[irq].acknowledge,
> > +					ipipe_root.irqs[irq].handler);
> >  			if (test_bit(IPIPE_LOCK_FLAG, &ipd->irqs[irq].control)) {
> >  				__clear_bit(rank, &cpudata->irq_pending_lo[level]);
> >  				continue;
> > @@ -807,6 +812,8 @@ void fastcall __ipipe_sync_stage(unsigne
> >  			if (ipd == ipipe_root_domain)
> >  				trace_hardirqs_off();
> >  
> > +			if (irq==219)
> > +				printk("%s:%d\n", __FUNCTION__, __LINE__);
> >  			__ipipe_run_isr(ipd, irq, cpuid);
> >  #ifdef CONFIG_SMP
> >  			{
> > 
> > 
> > 
> 
-- 
Philippe.

Re: [Xenomai-help] Xenomai and MSI enabled crashes kernel

[M. Koehrer]

Hi Jan,

I have looked closed into that issue.
For that I have added a global array that is written within  
__ipipe_handle_irq() (file arch/i386/kernel/ipipe.c):

                extern int xxx_int[];
                irq = ~irq;

                xxx_int[0] = irq;

#ifdef CONFIG_X86_LOCAL_APIC
                {
                        unsigned vector = irq + FIRST_EXTERNAL_VECTOR;
                        if (vector >= FIRST_SYSTEM_VECTOR)
                                irq = ipipe_apic_vector_irq(vector);
                }

                 xxx_int[1] = irq;


This global variable is printed out within the kernel trap.
It returns the values 0xcf and 0xe0 (207 and 224) for xxx_int[0], xxx_int[1].
And this is the really strange thing as the IRQ for the e1000 should be 219 (on a non-adeos-patched kernel).
I do not know what happens here, but it looks really strange...


Regards

Mathias
---------------------------------------
Intel(R) PRO/1000 Network Driver - version 7.3.15-k2
Copyright (c) 1999-2006 Intel Corporation.
ACPI: PCI Interrupt 0000:05:00.0[A] -> GSI 16 (level, low) -> IRQ 16
e1000: 0000:05:00.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1) 00:30:48:5a:f9:0a
e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
BUG: unable to handle kernel NULL pointer dereference at virtual address 00000000
 printing eip:
00000000
*pde = 00000000
Oops: 0000 [#1]
SMP
Modules linked in: e1000
xxx_int: cf e0 0 0
CPU:    0
EIP:    0060:[<00000000>]    Not tainted VLI
EFLAGS: 00010086   (2.6.20.4-msi2 #11)
EIP is at _stext+0x3feffc70/0x14
eax: c0112410   ebx: 00000007   ecx: c0114519   edx: df048000
esi: 00000006   edi: 00000046   ebp: ffffffff   esp: df049e20
ds: 007b   es: 007b   ss: 0068
Process ifconfig (pid: 1241, ti=df048000 task=c173e030 task.ti=df048000)
Stack: c03e6f00 000000ec 00000000 c03d9180 c010f14d 00007600 00000001 00000060
       e099a1ed 00000286 ffffff24 df75b5c8 00000000 0000000f 00000001 c01035b9
       df75b5c8 e099a0ff e09c0000 00000000 0000000f 00000001 80080740 dfc7007b
Call Trace:
 [<c010f14d>] __ipipe_handle_irq+0x1d3/0x225
 [<e099a1ed>] e1000_set_multi+0xee/0x189 [e1000]
 [<c01035b9>] common_interrupt+0x21/0x38
 [<e099a0ff>] e1000_set_multi+0x0/0x189 [e1000]
 [<e099a1ed>] e1000_set_multi+0xee/0x189 [e1000]
 [<c02dd151>] __dev_mc_upload+0x1d/0x1e
 [<c02dd271>] dev_mc_upload+0x24/0x37
 [<c02db77c>] dev_open+0x44/0x62
 [<c02da249>] dev_change_flags+0x47/0xe4
 [<c030d362>] devinet_ioctl+0x252/0x56f
 [<c02db35a>] dev_ifsioc+0x113/0x38d
 [<c02d1774>] sock_ioctl+0x0/0x1ad
 [<c02d1902>] sock_ioctl+0x18e/0x1ad
 [<c02d1774>] sock_ioctl+0x0/0x1ad
 [<c015e35b>] do_ioctl+0x1f/0x62
 [<c015e5e2>] vfs_ioctl+0x244/0x256
 [<c015e627>] sys_ioctl+0x33/0x4c
 [<c01029f3>] sysenter_past_esp+0x6c/0x70
 =======================
Code:  Bad EIP value.
EIP: [<00000000>] _stext+0x3feffc70/0x14 SS:ESP 0068:df049e20
 <0>Kernel panic - not syncing: Fatal exception in interrupt
 BUG: at arch/i386/kernel/smp.c:565 smp_call_function()
 [<c010bab3>] smp_call_function+0x66/0x10a
 [<c0118fde>] printk+0x62/0xd5
 [<c010bb72>] smp_send_stop+0x1b/0x2b
 [<c0118579>] panic+0x4d/0xe4
 [<c0104121>] die+0x1f2/0x226
 [<c0111848>] do_page_fault+0x447/0x517
 [<c010f7e7>] __ipipe_handle_exception+0xce/0x158
 [<c010bcce>] smp_call_function_interrupt+0x31/0x4c
 [<c033353d>] error_code+0x81/0x90
 [<c0114519>] try_to_wake_up+0x33c/0x346
 [<c0112410>] __activate_task+0x1c/0x29
 [<c010f14d>] __ipipe_handle_irq+0x1d3/0x225
 [<e099a1ed>] e1000_set_multi+0xee/0x189 [e1000]
 [<c01035b9>] common_interrupt+0x21/0x38
 [<e099a0ff>] e1000_set_multi+0x0/0x189 [e1000]
 [<e099a1ed>] e1000_set_multi+0xee/0x189 [e1000]
 [<c02dd151>] __dev_mc_upload+0x1d/0x1e
 [<c02dd271>] dev_mc_upload+0x24/0x37
 [<c02db77c>] dev_open+0x44/0x62
 [<c02da249>] dev_change_flags+0x47/0xe4
 [<c030d362>] devinet_ioctl+0x252/0x56f
 [<c02db35a>] dev_ifsioc+0x113/0x38d
 [<c02d1774>] sock_ioctl+0x0/0x1ad
 [<c02d1902>] sock_ioctl+0x18e/0x1ad
 [<c02d1774>] sock_ioctl+0x0/0x1ad
 [<c015e35b>] do_ioctl+0x1f/0x62
 [<c015e5e2>] vfs_ioctl+0x244/0x256
 [<c015e627>] sys_ioctl+0x33/0x4c
 [<c01029f3>] sysenter_past_esp+0x6c/0x70
 =======================






----- Original Nachricht ----
Von:     Jan Kiszka <jan.kiszka@domain.hid>
An:      "M. Koehrer" <mathias_koehrer@domain.hid>
Datum:   02.05.2007 11:39
Betreff: Re: [Xenomai-help] Xenomai and MSI enabled crashes kernel

> M. Koehrer wrote:
> > Hi Jan,
> > 
> > here is the result of this patch.
> > I patched in addition to Philippe's patches.
> > 
> > Regards
> > 
> > Mathias
> > ---------
> > Intel(R) PRO/1000 Network Driver - version 7.3.15-k2
> > Copyright (c) 1999-2006 Intel Corporation.
> > ACPI: PCI Interrupt 0000:05:00.0[A] -> GSI 16 (level, low) -> IRQ 16
> > e1000: 0000:05:00.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1)
> 00:30:48:5a:f9:0a
> > e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
> > BUG: unable to handle kernel NULL pointer dereference at virtual address
> 00000000
> >  printing eip:
> > dfedd3ca
> > *pde = 00000000
> > Oops: 0000 [#1]
> > SMP
> > Modules linked in: e1000
> > CPU:    0
> > EIP:    0060:[<dfedd3ca>]    Not tainted VLI
> > EFLAGS: 00010082   (2.6.20.4 #7)
> > EIP is at 0xdfedd3ca
> > eax: c0112478   ebx: 00000001   ecx: c0114581   edx: df06c001
> > esi: dfedf6c0   edi: dfedc240   ebp: 00000000   esp: df06ddf8
> > ds: 007b   es: 007b   ss: 0068
> > Process ifconfig (pid: 1242, ti=df06c000 task=c16f9030 task.ti=df06c000)
> > Stack: 00000040 ffffffff 00000000 00000007 c03e6f00 000000ec 00000000
> c03d9180
> >        c010f1b5 c015291a decbe080 00000680 decbe080 00000724 c02d6dfd
> 00007600
> >        00000001 00000060 e099a210 00000286 ffffff24 df7065c8 00000000
> 0000000f
> > Call Trace:
> >  [<c010f1b5>] __ipipe_handle_irq+0x26b/0x2bd
> 
> I must have patched crap into this, but I don't see it. Could someone
> have a look why there is no printk output related to #IRQ 219
> (~0xffffff24, see stack content)?
> 
> BTW, Mathias, forcing your kernel into single CPU mode via kernel
> command line "cpus=1" doesn't expose the issue, right? Could we face
> some kind of setup race across the CPUs here?
> 
> Thanks,
> Jan
> 
> 

-- 
Mathias Koehrer
mathias_koehrer@domain.hid


Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren
ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT JETZT bei Arcor: günstig
und schnell mit DSL - das All-Inclusive-Paket für clevere Doppel-Sparer,
nur  39,85 €  inkl. DSL- und ISDN-Grundgebühr!
http://www.arcor.de/rd/emf-dsl-2

Re: [Xenomai-help] Xenomai and MSI enabled crashes kernel

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1198 bytes --]

M. Koehrer wrote:
> Hi Jan,
> 
> I have looked closed into that issue.
> For that I have added a global array that is written within  
> __ipipe_handle_irq() (file arch/i386/kernel/ipipe.c):
> 
>                 extern int xxx_int[];
>                 irq = ~irq;
> 
>                 xxx_int[0] = irq;
> 
> #ifdef CONFIG_X86_LOCAL_APIC
>                 {
>                         unsigned vector = irq + FIRST_EXTERNAL_VECTOR;
>                         if (vector >= FIRST_SYSTEM_VECTOR)
>                                 irq = ipipe_apic_vector_irq(vector);
>                 }
> 
>                  xxx_int[1] = irq;
> 
> 
> This global variable is printed out within the kernel trap.
> It returns the values 0xcf and 0xe0 (207 and 224) for xxx_int[0], xxx_int[1].
> And this is the really strange thing as the IRQ for the e1000 should be 219 (on a non-adeos-patched kernel).
> I do not know what happens here, but it looks really strange...
> 

Please make xxx_irq per-cpu to exclude ugly races with the second CPU
handling IRQs in parallel. Also re-apply Philippe's vectoring
instrumentation and post the full kernel log to have a consistent picture.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] Xenomai and MSI enabled crashes kernel

[M. Koehrer]

Hi Philippe,

I enabled the two kernel configuration parameters.
However, this changes the error behaviour.
Now, the e1000 driver will  be loaded, however it will not work...
A unload and reload of the e1000 driver leads now to a kernel oops. However this looks
completely different than the original one I am chasing...
 
I will try to instrument the e1000 driver to ensure that it tries to retrieve the correct interrupt...

Regards

Mathias


----- Original Nachricht ----
Von:     Philippe Gerum <rpm@xenomai.org>
An:      "M. Koehrer" <mathias_koehrer@domain.hid>
Datum:   02.05.2007 14:42
Betreff: Re: [Xenomai-help] Xenomai and MSI enabled crashes kernel

> On Wed, 2007-05-02 at 11:14 +0200, M. Koehrer wrote:
> > Hi Jan,
> > 
> > here is the result of this patch.
> > I patched in addition to Philippe's patches.
> > 
> > Regards
> > 
> > Mathias
> > ---------
> > Intel(R) PRO/1000 Network Driver - version 7.3.15-k2
> > Copyright (c) 1999-2006 Intel Corporation.
> > ACPI: PCI Interrupt 0000:05:00.0[A] -> GSI 16 (level, low) -> IRQ 16
> > e1000: 0000:05:00.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1)
> 00:30:48:5a:f9:0a
> > e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
> > BUG: unable to handle kernel NULL pointer dereference at virtual address
> 00000000
> >  printing eip:
> > dfedd3ca
> 
> The following options are needed to get a reliable backtrace, make sure
> to have them on:
> 
> CONFIG_DEBUG_KERNEL=y
> CONFIG_FRAME_POINTER=y
> 
> I also need the kernel disassembly; please send this privately to me
> (output of "objdump -d vmlinux"). Make sure to attach the boot log for
> this kernel as it fails, since code offsets listed in the backtrace are
> going to move with the above options enabled.
> 
> Additionally, does the problem persist if you disable CONFIG_XENOMAI,
> but still leave CONFIG_IPIPE on?
> 
> > *pde = 00000000
> > Oops: 0000 [#1]
> > SMP
> > Modules linked in: e1000
> > CPU:    0
> > EIP:    0060:[<dfedd3ca>]    Not tainted VLI
> > EFLAGS: 00010082   (2.6.20.4 #7)
> > EIP is at 0xdfedd3ca
> > eax: c0112478   ebx: 00000001   ecx: c0114581   edx: df06c001
> > esi: dfedf6c0   edi: dfedc240   ebp: 00000000   esp: df06ddf8
> > ds: 007b   es: 007b   ss: 0068
> > Process ifconfig (pid: 1242, ti=df06c000 task=c16f9030 task.ti=df06c000)
> > Stack: 00000040 ffffffff 00000000 00000007 c03e6f00 000000ec 00000000
> c03d9180
> >        c010f1b5 c015291a decbe080 00000680 decbe080 00000724 c02d6dfd
> 00007600
> >        00000001 00000060 e099a210 00000286 ffffff24 df7065c8 00000000
> 0000000f
> > Call Trace:
> >  [<c010f1b5>] __ipipe_handle_irq+0x26b/0x2bd
> >  [<c015291a>] __kmalloc+0x82/0x8d
> >  [<c02d6dfd>] __alloc_skb+0x4f/0xf8
> >  [<e099a210>] e1000_set_multi+0x111/0x189 [e1000]
> >  [<c01035b9>] common_interrupt+0x21/0x38
> >  [<e099a0ff>] e1000_set_multi+0x0/0x189 [e1000]
> >  [<e099a210>] e1000_set_multi+0x111/0x189 [e1000]
> >  [<c02dd211>] __dev_mc_upload+0x1d/0x1e
> >  [<c02dd331>] dev_mc_upload+0x24/0x37
> >  [<c02db83c>] dev_open+0x44/0x62
> >  [<c02da309>] dev_change_flags+0x47/0xe4
> >  [<c030d422>] devinet_ioctl+0x252/0x56f
> >  [<c02db41a>] dev_ifsioc+0x113/0x38d
> >  [<c02d1834>] sock_ioctl+0x0/0x1ad
> >  [<c02d19c2>] sock_ioctl+0x18e/0x1ad
> >  [<c02d1834>] sock_ioctl+0x0/0x1ad
> >  [<c015e41b>] do_ioctl+0x1f/0x62
> >  [<c015e6a2>] vfs_ioctl+0x244/0x256
> >  [<c015e6e7>] sys_ioctl+0x33/0x4c
> >  [<c01029f3>] sysenter_past_esp+0x6c/0x70
> >  =======================
> > Code: 00 00 00 00 00 01 00 00 00 00 90 ed df 04 03 02 01 6b ec fe ff 00 00
> 00 00 00 00 00 00 00 00 00 00 c0 d3 ed df c0 d3 ed df 00 42 <c9> de 00 db ed
> df d0 d3 ed df d0 d3 ed df 00 00 00 00 1a 00 00
> > EIP: [<dfedd3ca>] 0xdfedd3ca SS:ESP 0068:df06ddf8
> >  <0>Kernel panic - not syncing: Fatal exception in interrupt
> >  BUG: at arch/i386/kernel/smp.c:565 smp_call_function()
> >  [<c010ba83>] smp_call_function+0x66/0x10a
> >  [<c0119046>] printk+0x62/0xd5
> >  [<c010bb42>] smp_send_stop+0x1b/0x2b
> >  [<c01185e1>] panic+0x4d/0xe4
> >  [<c01040f1>] die+0x1f2/0x226
> >  [<c01118b0>] do_page_fault+0x447/0x517
> >  [<c010f84f>] __ipipe_handle_exception+0xce/0x158
> >  [<c03335fd>] error_code+0x81/0x90
> >  [<c0114581>] try_to_wake_up+0x33c/0x346
> >  [<c0112478>] __activate_task+0x1c/0x29
> >  [<c010f1b5>] __ipipe_handle_irq+0x26b/0x2bd
> >  [<c015291a>] __kmalloc+0x82/0x8d
> >  [<c02d6dfd>] __alloc_skb+0x4f/0xf8
> >  [<e099a210>] e1000_set_multi+0x111/0x189 [e1000]
> >  [<c01035b9>] common_interrupt+0x21/0x38
> >  [<e099a0ff>] e1000_set_multi+0x0/0x189 [e1000]
> >  [<e099a210>] e1000_set_multi+0x111/0x189 [e1000]
> >  [<c02dd211>] __dev_mc_upload+0x1d/0x1e
> >  [<c02dd331>] dev_mc_upload+0x24/0x37
> >  [<c02db83c>] dev_open+0x44/0x62
> >  [<c02da309>] dev_change_flags+0x47/0xe4
> >  [<c030d422>] devinet_ioctl+0x252/0x56f
> >  [<c02db41a>] dev_ifsioc+0x113/0x38d
> >  [<c02d1834>] sock_ioctl+0x0/0x1ad
> >  [<c02d19c2>] sock_ioctl+0x18e/0x1ad
> >  [<c02d1834>] sock_ioctl+0x0/0x1ad
> >  [<c015e41b>] do_ioctl+0x1f/0x62
> >  [<c015e6a2>] vfs_ioctl+0x244/0x256
> >  [<c015e6e7>] sys_ioctl+0x33/0x4c
> >  [<c01029f3>] sysenter_past_esp+0x6c/0x70
> >  =======================
> >  
> > 
> > ----- Original Nachricht ----
> > Von:     Jan Kiszka <jan.kiszka@domain.hid>
> > An:      "M. Koehrer" <mathias_koehrer@domain.hid>
> > Datum:   02.05.2007 10:39
> > Betreff: Re: [Xenomai-help] Xenomai and MSI enabled crashes kernel
> > 
> > > M. Koehrer wrote:
> > > > Hi Philippe,
> > > > 
> > > > I have applied the patches as proposed.
> > > > However, the kernel still freezes.
> > > 
> > > :(
> > > 
> > > > Here is the corresponding message.
> > > > 
> > > 
> > > OK, here is another instrumentation, hoping that the bug will not move
> > > again and that we can nail down what piece of memory contains nonsense.
> > > 
> > > The next step would then be to narrow down the corruption window (or to
> > > find the reason for filling in nonsense during initialisation).
> > > 
> > > Jan
> > > 
> > > 
> > > Index: linux-2.6.20/arch/i386/kernel/ipipe.c
> > > ===================================================================
> > > --- linux-2.6.20.orig/arch/i386/kernel/ipipe.c
> > > +++ linux-2.6.20/arch/i386/kernel/ipipe.c
> > > @@ -782,6 +782,13 @@ int __ipipe_handle_irq(struct pt_regs re
> > >  
> > >  	head = __ipipe_pipeline.next;
> > >  	next_domain = list_entry(head, struct ipipe_domain, p_link);
> > > +	if (irq==219) {
> > > +		ipipe_set_printk_sync(next_domain);
> > > +		printk("%s:%d\n", __FUNCTION__, __LINE__);
> > > +		printk("%s:%d %lx %p %p\n", __FUNCTION__, __LINE__,
> > > +			ipipe_root.irqs[irq].control, ipipe_root.irqs[irq].acknowledge,
> > > +			ipipe_root.irqs[irq].handler);
> > > +	}
> > >  	if (likely(test_bit(IPIPE_WIRED_FLAG,
> &next_domain->irqs[irq].control)))
> > > {
> > >  		if (!m_ack && next_domain->irqs[irq].acknowledge != NULL)
> > >  			next_domain->irqs[irq].acknowledge(irq);
> > > @@ -865,6 +872,10 @@ finalize:
> > >  	 * current domain in the pipeline.
> > >  	 */
> > >  
> > > +	if (irq==219)
> > > +		printk("%s:%d %lx %p %p\n", __FUNCTION__, __LINE__,
> > > +			ipipe_root.irqs[irq].control, ipipe_root.irqs[irq].acknowledge,
> > > +			ipipe_root.irqs[irq].handler);
> > >  	__ipipe_walk_pipeline(head, cpuid);
> > >  
> > >  	ipipe_load_cpuid();
> > > Index: linux-2.6.20/kernel/ipipe/core.c
> > > ===================================================================
> > > --- linux-2.6.20.orig/kernel/ipipe/core.c
> > > +++ linux-2.6.20/kernel/ipipe/core.c
> > > @@ -791,6 +791,11 @@ void fastcall __ipipe_sync_stage(unsigne
> > >  			rank = __ipipe_ffnz(submask);
> > >  			irq = (level << IPIPE_IRQ_ISHIFT) + rank;
> > >  
> > > +			if (irq==219)
> > > +				printk("%s:%d %lx %p %p\n", __FUNCTION__, __LINE__,
> > > +					ipipe_root.irqs[irq].control,
> > > +					ipipe_root.irqs[irq].acknowledge,
> > > +					ipipe_root.irqs[irq].handler);
> > >  			if (test_bit(IPIPE_LOCK_FLAG, &ipd->irqs[irq].control)) {
> > >  				__clear_bit(rank, &cpudata->irq_pending_lo[level]);
> > >  				continue;
> > > @@ -807,6 +812,8 @@ void fastcall __ipipe_sync_stage(unsigne
> > >  			if (ipd == ipipe_root_domain)
> > >  				trace_hardirqs_off();
> > >  
> > > +			if (irq==219)
> > > +				printk("%s:%d\n", __FUNCTION__, __LINE__);
> > >  			__ipipe_run_isr(ipd, irq, cpuid);
> > >  #ifdef CONFIG_SMP
> > >  			{
> > > 
> > > 
> > > 
> > 
> -- 
> Philippe.
> 
> 
> 

-- 
Mathias Koehrer
mathias_koehrer@domain.hid


Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren
ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT JETZT bei Arcor: günstig
und schnell mit DSL - das All-Inclusive-Paket für clevere Doppel-Sparer,
nur  39,85 €  inkl. DSL- und ISDN-Grundgebühr!
http://www.arcor.de/rd/emf-dsl-2

Re: [Xenomai-help] Xenomai and MSI enabled crashes kernel

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 720 bytes --]

M. Koehrer wrote:
> Hi Philippe,
> 
> I enabled the two kernel configuration parameters.
> However, this changes the error behaviour.
> Now, the e1000 driver will  be loaded, however it will not work...
> A unload and reload of the e1000 driver leads now to a kernel oops. However this looks
> completely different than the original one I am chasing...
>  
> I will try to instrument the e1000 driver to ensure that it tries to retrieve the correct interrupt...

Let's don't change the test setup permanently unless it results in a
"better" oops. We need ONE base where we try to narrow the issue down,
not n of them.

OK, then please post the new oops, maybe it is in fact more comprehensible.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] Xenomai and MSI enabled crashes kernel

[Philippe Gerum]

On Wed, 2007-05-02 at 14:57 +0200, M. Koehrer wrote:
> Hi Jan,
> 
> I have looked closed into that issue.
> For that I have added a global array that is written within  
> __ipipe_handle_irq() (file arch/i386/kernel/ipipe.c):
> 
>                 extern int xxx_int[];
>                 irq = ~irq;
> 
>                 xxx_int[0] = irq;
> 
> #ifdef CONFIG_X86_LOCAL_APIC
>                 {
>                         unsigned vector = irq + FIRST_EXTERNAL_VECTOR;
>                         if (vector >= FIRST_SYSTEM_VECTOR)
>                                 irq = ipipe_apic_vector_irq(vector);
>                 }
> 
>                  xxx_int[1] = irq;
> 
> 
> This global variable is printed out within the kernel trap.
> It returns the values 0xcf and 0xe0 (207 and 224) for xxx_int[0], xxx_int[1].
> And this is the really strange thing as the IRQ for the e1000 should be 219 (on a non-adeos-patched kernel).
> I do not know what happens here, but it looks really strange...
> 

It's not, this is ok. Fact is that 0xcf is the LAPIC's local timer
interrupt vectored from 0xef, this has nothing to do with the e1000 IRQ.
The effect of my latest patch is to remap this value to the 224-256
range for IRQ numbers which Adeos now reserves to system interrupts on
your setup, i.e. 0xcf becomes interrupt number 224, because it is a
system interrupt.

As a sidenote, let's not draw any conclusion regarding the interrupt
number that might cause the bug for now, we just don't have any
guarantee that the boot log is not lying at us so far; e.g. the latest
IRQ trace could well be stuck into the printk() ring buffer, regardless
of ipipe_set_printk_sync() being in effect for the root domain or not.
What we'd need is a raw serial console output routine (i.e.
__ipipe_debug_serial() from other Adeos ports), but I've not implemented
this for x86, unfortunately.

The sole and only important thing to achieve right now, is to have this
bug 100% reproducible on a stabilized setup, which also provides enough
instrumentation to allow further debugging without moving targets. It's
an interrupt-related bug, no wonder it may have multiple incarnations,
so let's choose one and only one of them, we could trace.

What I need to know, is which code is laid at address
__ipipe_handle_irq+0x26b, this is why I asked for the disassembly.
Each change in the kernel code or configuration option will much likely
change this address, for that reason, what we need is:

- get back to CONFIG_DEBUG_KERNEL off, since enabling it changes the
behaviour
- boot the machine, and hopefully get back to the usual BUG() message,
- send a copy of the kernel disassembly along with the boot log.

Without that, I have no mean to help debugging anything, I'm afraid.

-- 
Philippe.

Re: [Xenomai-help] Xenomai and MSI enabled crashes kernel

[M. Koehrer]

[-- Attachment #1.1: Type: text/plain, Size: 2979 bytes --]

Hi Philippe,

I have restored the original kernel configuration and I got the crash again.
As it happens during the boot, it is reproducible.
Enclosed is the console log (including the oops), the relevant disassemble part,
the output of "nm vmlinux" and my kernel config.
If you like I can mail you privately the vmlinux aswell.
What I see from the disassembler listing
c010f10b:       e8 5e ae 02 00          call   c0139f6e <__ipipe_walk_pipeline>
c010f110:       ff 15 68 70 3d c0       call   *0xc03d7068
is that ipipe_walk_pipeline is called followed by a indirect call to 0xc03d7068.
I looked at `nm vmlinux` and found out that 0xc03d7068 is __ipipe_logical_cpuid.

I hope that helps to get closer to this bug...

Regards

Mathias


> 
> It's not, this is ok. Fact is that 0xcf is the LAPIC's local timer
> interrupt vectored from 0xef, this has nothing to do with the e1000 IRQ.
> The effect of my latest patch is to remap this value to the 224-256
> range for IRQ numbers which Adeos now reserves to system interrupts on
> your setup, i.e. 0xcf becomes interrupt number 224, because it is a
> system interrupt.
> 
> As a sidenote, let's not draw any conclusion regarding the interrupt
> number that might cause the bug for now, we just don't have any
> guarantee that the boot log is not lying at us so far; e.g. the latest
> IRQ trace could well be stuck into the printk() ring buffer, regardless
> of ipipe_set_printk_sync() being in effect for the root domain or not.
> What we'd need is a raw serial console output routine (i.e.
> __ipipe_debug_serial() from other Adeos ports), but I've not implemented
> this for x86, unfortunately.
> 
> The sole and only important thing to achieve right now, is to have this
> bug 100% reproducible on a stabilized setup, which also provides enough
> instrumentation to allow further debugging without moving targets. It's
> an interrupt-related bug, no wonder it may have multiple incarnations,
> so let's choose one and only one of them, we could trace.
> 
> What I need to know, is which code is laid at address
> __ipipe_handle_irq+0x26b, this is why I asked for the disassembly.
> Each change in the kernel code or configuration option will much likely
> change this address, for that reason, what we need is:
> 
> - get back to CONFIG_DEBUG_KERNEL off, since enabling it changes the
> behaviour
> - boot the machine, and hopefully get back to the usual BUG() message,
> - send a copy of the kernel disassembly along with the boot log.
> 
> Without that, I have no mean to help debugging anything, I'm afraid.


-- 
Mathias Koehrer
mathias_koehrer@domain.hid


Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren
ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT JETZT bei Arcor: günstig
und schnell mit DSL - das All-Inclusive-Paket für clevere Doppel-Sparer,
nur  39,85 €  inkl. DSL- und ISDN-Grundgebühr!
http://www.arcor.de/rd/emf-dsl-2

[-- Attachment #2: msi-crash-log.tar.bz2 --]
[-- Type: application/x-bzip2, Size: 209904 bytes --]

Re: [Xenomai-help] Xenomai and MSI enabled crashes kernel

[Philippe Gerum]

On Thu, 2007-05-03 at 09:06 +0200, M. Koehrer wrote:
> Hi Philippe,
> 
> I have restored the original kernel configuration and I got the crash again.
> As it happens during the boot, it is reproducible.
> Enclosed is the console log (including the oops), the relevant disassemble part,
> the output of "nm vmlinux" and my kernel config.
> If you like I can mail you privately the vmlinux aswell.
> What I see from the disassembler listing
> c010f10b:       e8 5e ae 02 00          call   c0139f6e <__ipipe_walk_pipeline>
> c010f110:       ff 15 68 70 3d c0       call   *0xc03d7068
> is that ipipe_walk_pipeline is called followed by a indirect call to 0xc03d7068.
> I looked at `nm vmlinux` and found out that 0xc03d7068 is __ipipe_logical_cpuid.
> 
> I hope that helps to get closer to this bug...
> 

Should be ok, thanks. I will have a close look at this.

-- 
Philippe.

Re: [Xenomai-help] Xenomai and MSI enabled crashes kernel

[M. Koehrer]

Hi everybody,

I have been gone one step back to analyze the issue from the situation is originally occurred.
This was the situation that I had a 2.6.20.4 kernel and Xenomai 2.3.1 (included Adeos patch).
When I  enable MSI in the kernel configuration I get the kernel message:
"spurious APIC interrupt on CPU#0, should never happen."
when trying to enable (ifconfig) the e1000 driver for an onboard PCIe network adapter.

I have now used the very same kernel without Xenomai patch, but using the same kernel config
(MSI enabled). This returns the IRQ 223 for the Ethernet adapter.
With 2.6.21 it returns IRQ 219, there seems to be a difference between 2.6.20 and 2.6.21.
Well, as I am working with 2.6.20.4, I looked deeper in that.

One interesting thing I found was in arch/i386/kernel/ipipe.c at function __ipipe_enable_pipeline
I do not understand the meaning of that code.
At the beginning of that function, there are a couple of calls to ipipe_virtualize_irq().
These MAP the APIC system vectors.
However, the second call that maps 
SPURIOUS_APIC_VECTOR - FIRST_EXTERNAL_VECTOR (with is infact 223) is mapped to
smp_spurious_interrupt (which leads to the result I see).
However, I am not sure if it is correct to use the VECTOR values here as ipipe_virtualize_irq
uses "irq" as second parameter and not  a vector. This looks like a vector vs. irq mismatch.

Within the create_irq() function, the e1000 creates irq 223 on vector 201.

When I monitor the calls to set_intr_gate() I see that the vector 32 will end up at the address
of irq_entries_start, vector 32 will end up at irq_entries_start + 8 etc.
In entry.S this will end up in writing ~(vector) unto the stack and calling common_interrupt.
This finally calls __ipipe_handle_irq.
The means that __ipipe_handle_irq will not be called with the IRQ number but with the vector!!
It could be that this is the same for the "old" IRQ vectors (<32). 
However for the MSI IRQs this seems to be not correct.
I think that this could be the root cause for the problems I see.

Any feedback on this comment is highly welcome!

Regards

Mathias



> On Thu, 2007-05-03 at 09:06 +0200, M. Koehrer wrote:
> > Hi Philippe,
> > 
> > I have restored the original kernel configuration and I got the crash
> again.
> > As it happens during the boot, it is reproducible.
> > Enclosed is the console log (including the oops), the relevant disassemble
> part,
> > the output of "nm vmlinux" and my kernel config.
> > If you like I can mail you privately the vmlinux aswell.
> > What I see from the disassembler listing
> > c010f10b:       e8 5e ae 02 00          call   c0139f6e
> <__ipipe_walk_pipeline>
> > c010f110:       ff 15 68 70 3d c0       call   *0xc03d7068
> > is that ipipe_walk_pipeline is called followed by a indirect call to
> 0xc03d7068.
> > I looked at `nm vmlinux` and found out that 0xc03d7068 is
> __ipipe_logical_cpuid.
> > 
> > I hope that helps to get closer to this bug...
> > 
> 
> Should be ok, thanks. I will have a close look at this.
> 
> -- 
> Philippe.
> 
> 
> 

-- 
Mathias Koehrer
mathias_koehrer@domain.hid


Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren
ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT JETZT bei Arcor: günstig
und schnell mit DSL - das All-Inclusive-Paket für clevere Doppel-Sparer,
nur  39,85 €  inkl. DSL- und ISDN-Grundgebühr!
http://www.arcor.de/rd/emf-dsl-2

Re: [Xenomai-help] Xenomai and MSI enabled crashes kernel

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2415 bytes --]

M. Koehrer wrote:
> Hi everybody,
> 
> I have been gone one step back to analyze the issue from the situation is originally occurred.
> This was the situation that I had a 2.6.20.4 kernel and Xenomai 2.3.1 (included Adeos patch).
> When I  enable MSI in the kernel configuration I get the kernel message:
> "spurious APIC interrupt on CPU#0, should never happen."
> when trying to enable (ifconfig) the e1000 driver for an onboard PCIe network adapter.
> 
> I have now used the very same kernel without Xenomai patch, but using the same kernel config
> (MSI enabled). This returns the IRQ 223 for the Ethernet adapter.
> With 2.6.21 it returns IRQ 219, there seems to be a difference between 2.6.20 and 2.6.21.
> Well, as I am working with 2.6.20.4, I looked deeper in that.
> 
> One interesting thing I found was in arch/i386/kernel/ipipe.c at function __ipipe_enable_pipeline
> I do not understand the meaning of that code.
> At the beginning of that function, there are a couple of calls to ipipe_virtualize_irq().
> These MAP the APIC system vectors.
> However, the second call that maps 
> SPURIOUS_APIC_VECTOR - FIRST_EXTERNAL_VECTOR (with is infact 223) is mapped to
> smp_spurious_interrupt (which leads to the result I see).
> However, I am not sure if it is correct to use the VECTOR values here as ipipe_virtualize_irq
> uses "irq" as second parameter and not  a vector. This looks like a vector vs. irq mismatch.

Isn't this the issue Philippe's last patch against ipipe and xenomai fixes?

> 
> Within the create_irq() function, the e1000 creates irq 223 on vector 201.
> 
> When I monitor the calls to set_intr_gate() I see that the vector 32 will end up at the address
> of irq_entries_start, vector 32 will end up at irq_entries_start + 8 etc.
> In entry.S this will end up in writing ~(vector) unto the stack and calling common_interrupt.
> This finally calls __ipipe_handle_irq.
> The means that __ipipe_handle_irq will not be called with the IRQ number but with the vector!!
> It could be that this is the same for the "old" IRQ vectors (<32). 
> However for the MSI IRQs this seems to be not correct.
> I think that this could be the root cause for the problems I see.

Again, please verify that you are not debugging the issue that Philippe
may have already fixed, ie. re-evaluate your (very systematic!) findings
after applying the ipipe fix.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]

Re: [Xenomai-help] Xenomai and MSI enabled crashes kernel

[M. Koehrer]

Hi Jan,

o.k., now I understand Philippes patch.
However, at one point, I am not quite sure if this is correct:
Within __ipipe_handle_irq()
the patch adds
#ifdef CONFIG_X86_LOCAL_APIC
               {
                       unsigned vector = irq + FIRST_EXTERNAL_VECTOR;
                       if (vector >= FIRST_SYSTEM_VECTOR)
                               irq = ipipe_apic_vector_irq(vector);
               }
#endif
I do not understand the if (vector >= ..) statement.
When I am at this point, the irq value is always the vector and never an irq.
Thus, I think I should call ipipe_apic_vector_irq in any case.
I will do a test on that.

Regards

Mathias



----- Original Nachricht ----
Von:     Jan Kiszka <jan.kiszka@domain.hid>
An:      "M. Koehrer" <mathias_koehrer@domain.hid>
Datum:   04.05.2007 09:59
Betreff: Re: [Xenomai-help] Xenomai and MSI enabled crashes kernel

> M. Koehrer wrote:
> > Hi everybody,
> > 
> > I have been gone one step back to analyze the issue from the situation is
> originally occurred.
> > This was the situation that I had a 2.6.20.4 kernel and Xenomai 2.3.1
> (included Adeos patch).
> > When I  enable MSI in the kernel configuration I get the kernel message:
> > "spurious APIC interrupt on CPU#0, should never happen."
> > when trying to enable (ifconfig) the e1000 driver for an onboard PCIe
> network adapter.
> > 
> > I have now used the very same kernel without Xenomai patch, but using the
> same kernel config
> > (MSI enabled). This returns the IRQ 223 for the Ethernet adapter.
> > With 2.6.21 it returns IRQ 219, there seems to be a difference between
> 2.6.20 and 2.6.21.
> > Well, as I am working with 2.6.20.4, I looked deeper in that.
> > 
> > One interesting thing I found was in arch/i386/kernel/ipipe.c at function
> __ipipe_enable_pipeline
> > I do not understand the meaning of that code.
> > At the beginning of that function, there are a couple of calls to
> ipipe_virtualize_irq().
> > These MAP the APIC system vectors.
> > However, the second call that maps 
> > SPURIOUS_APIC_VECTOR - FIRST_EXTERNAL_VECTOR (with is infact 223) is
> mapped to
> > smp_spurious_interrupt (which leads to the result I see).
> > However, I am not sure if it is correct to use the VECTOR values here as
> ipipe_virtualize_irq
> > uses "irq" as second parameter and not  a vector. This looks like a vector
> vs. irq mismatch.
> 
> Isn't this the issue Philippe's last patch against ipipe and xenomai fixes?
> 
> > 
> > Within the create_irq() function, the e1000 creates irq 223 on vector
> 201.
> > 
> > When I monitor the calls to set_intr_gate() I see that the vector 32 will
> end up at the address
> > of irq_entries_start, vector 32 will end up at irq_entries_start + 8 etc.
> > In entry.S this will end up in writing ~(vector) unto the stack and
> calling common_interrupt.
> > This finally calls __ipipe_handle_irq.
> > The means that __ipipe_handle_irq will not be called with the IRQ number
> but with the vector!!
> > It could be that this is the same for the "old" IRQ vectors (<32). 
> > However for the MSI IRQs this seems to be not correct.
> > I think that this could be the root cause for the problems I see.
> 
> Again, please verify that you are not debugging the issue that Philippe
> may have already fixed, ie. re-evaluate your (very systematic!) findings
> after applying the ipipe fix.
> 
> Jan
> 
> 

-- 
Mathias Koehrer
mathias_koehrer@domain.hid


Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren
ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT JETZT bei Arcor: günstig
und schnell mit DSL - das All-Inclusive-Paket für clevere Doppel-Sparer,
nur  39,85 €  inkl. DSL- und ISDN-Grundgebühr!
http://www.arcor.de/rd/emf-dsl-2

Re: [Xenomai-help] Xenomai and MSI enabled crashes kernel

[Philippe Gerum]

On Fri, 2007-05-04 at 10:20 +0200, M. Koehrer wrote:
> Hi Jan,
> 
> o.k., now I understand Philippes patch.
> However, at one point, I am not quite sure if this is correct:
> Within __ipipe_handle_irq()
> the patch adds
> #ifdef CONFIG_X86_LOCAL_APIC
>                {
>                        unsigned vector = irq + FIRST_EXTERNAL_VECTOR;
>                        if (vector >= FIRST_SYSTEM_VECTOR)
>                                irq = ipipe_apic_vector_irq(vector);
>                }
> #endif
> I do not understand the if (vector >= ..) statement.
> When I am at this point, the irq value is always the vector and never an irq.

No, the trampoline code in entry.S passes us an irq actually. But there
is indeed a vector:irq mapping issue with IRQ numbers greater than 206,
which still badly conflict with system IRQs (MSI causes high numbered
IRQs to be allocated). I'm working on a patch. More later.

> Thus, I think I should call ipipe_apic_vector_irq in any case.
> I will do a test on that.
> 
> Regards
> 
> Mathias
> 
> 
> 
> ----- Original Nachricht ----
> Von:     Jan Kiszka <jan.kiszka@domain.hid>
> An:      "M. Koehrer" <mathias_koehrer@domain.hid>
> Datum:   04.05.2007 09:59
> Betreff: Re: [Xenomai-help] Xenomai and MSI enabled crashes kernel
> 
> > M. Koehrer wrote:
> > > Hi everybody,
> > > 
> > > I have been gone one step back to analyze the issue from the situation is
> > originally occurred.
> > > This was the situation that I had a 2.6.20.4 kernel and Xenomai 2.3.1
> > (included Adeos patch).
> > > When I  enable MSI in the kernel configuration I get the kernel message:
> > > "spurious APIC interrupt on CPU#0, should never happen."
> > > when trying to enable (ifconfig) the e1000 driver for an onboard PCIe
> > network adapter.
> > > 
> > > I have now used the very same kernel without Xenomai patch, but using the
> > same kernel config
> > > (MSI enabled). This returns the IRQ 223 for the Ethernet adapter.
> > > With 2.6.21 it returns IRQ 219, there seems to be a difference between
> > 2.6.20 and 2.6.21.
> > > Well, as I am working with 2.6.20.4, I looked deeper in that.
> > > 
> > > One interesting thing I found was in arch/i386/kernel/ipipe.c at function
> > __ipipe_enable_pipeline
> > > I do not understand the meaning of that code.
> > > At the beginning of that function, there are a couple of calls to
> > ipipe_virtualize_irq().
> > > These MAP the APIC system vectors.
> > > However, the second call that maps 
> > > SPURIOUS_APIC_VECTOR - FIRST_EXTERNAL_VECTOR (with is infact 223) is
> > mapped to
> > > smp_spurious_interrupt (which leads to the result I see).
> > > However, I am not sure if it is correct to use the VECTOR values here as
> > ipipe_virtualize_irq
> > > uses "irq" as second parameter and not  a vector. This looks like a vector
> > vs. irq mismatch.
> > 
> > Isn't this the issue Philippe's last patch against ipipe and xenomai fixes?
> > 
> > > 
> > > Within the create_irq() function, the e1000 creates irq 223 on vector
> > 201.
> > > 
> > > When I monitor the calls to set_intr_gate() I see that the vector 32 will
> > end up at the address
> > > of irq_entries_start, vector 32 will end up at irq_entries_start + 8 etc.
> > > In entry.S this will end up in writing ~(vector) unto the stack and
> > calling common_interrupt.
> > > This finally calls __ipipe_handle_irq.
> > > The means that __ipipe_handle_irq will not be called with the IRQ number
> > but with the vector!!
> > > It could be that this is the same for the "old" IRQ vectors (<32). 
> > > However for the MSI IRQs this seems to be not correct.
> > > I think that this could be the root cause for the problems I see.
> > 
> > Again, please verify that you are not debugging the issue that Philippe
> > may have already fixed, ie. re-evaluate your (very systematic!) findings
> > after applying the ipipe fix.
> > 
> > Jan
> > 
> > 
> 
-- 
Philippe.

Re: [Xenomai-help] Xenomai and MSI enabled crashes kernel

[M. Koehrer]

Hi Philippe,

I patched the create_irq() function to start the search for unused interrupts not at
NR_IRQS -1 but from 127.
And this seems actually to work.
It looks like the right track!
That means, that actually the large IRQ numbers are conflicting with the system
interrupts.
However, I wonder why this works with a non-adeos-patched kernel...

Regards

Mathias


> 
> No, the trampoline code in entry.S passes us an irq actually. But there
> is indeed a vector:irq mapping issue with IRQ numbers greater than 206,
> which still badly conflict with system IRQs (MSI causes high numbered
> IRQs to be allocated). I'm working on a patch. More later.
> 


-- 
Mathias Koehrer
mathias_koehrer@domain.hid


Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren
ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT JETZT bei Arcor: günstig
und schnell mit DSL - das All-Inclusive-Paket für clevere Doppel-Sparer,
nur  39,85 €  inkl. DSL- und ISDN-Grundgebühr!
http://www.arcor.de/rd/emf-dsl-2

Re: [Xenomai-help] Xenomai and MSI enabled crashes kernel

[Philippe Gerum]

On Fri, 2007-05-04 at 14:46 +0200, M. Koehrer wrote:
> Hi Philippe,
> 
> I patched the create_irq() function to start the search for unused interrupts not at
> NR_IRQS -1 but from 127.
> And this seems actually to work.
> It looks like the right track!
> That means, that actually the large IRQ numbers are conflicting with the system
> interrupts.

> However, I wonder why this works with a non-adeos-patched kernel...

Because the vanilla kernel does not need to map system vectors to
interrupt numbers.

> 
> Regards
> 
> Mathias
> 
> 
> > 
> > No, the trampoline code in entry.S passes us an irq actually. But there
> > is indeed a vector:irq mapping issue with IRQ numbers greater than 206,
> > which still badly conflict with system IRQs (MSI causes high numbered
> > IRQs to be allocated). I'm working on a patch. More later.
> > 
> 
> 
-- 
Philippe.

Re: [Xenomai-help] Xenomai and MSI enabled crashes kernel

[Philippe Gerum]

On Fri, 2007-05-04 at 14:20 +0200, Philippe Gerum wrote:
> On Fri, 2007-05-04 at 10:20 +0200, M. Koehrer wrote:
> > Hi Jan,
> > 
> > o.k., now I understand Philippes patch.
> > However, at one point, I am not quite sure if this is correct:
> > Within __ipipe_handle_irq()
> > the patch adds
> > #ifdef CONFIG_X86_LOCAL_APIC
> >                {
> >                        unsigned vector = irq + FIRST_EXTERNAL_VECTOR;
> >                        if (vector >= FIRST_SYSTEM_VECTOR)
> >                                irq = ipipe_apic_vector_irq(vector);
> >                }
> > #endif
> > I do not understand the if (vector >= ..) statement.
> > When I am at this point, the irq value is always the vector and never an irq.
> 
> No, the trampoline code in entry.S passes us an irq actually. But there
> is indeed a vector:irq mapping issue with IRQ numbers greater than 206,
> which still badly conflict with system IRQs (MSI causes high numbered
> IRQs to be allocated). I'm working on a patch. More later.
> 

Does this patch improve things?

http://download.gna.org/adeos/patches/v2.6/i386/adeos-ipipe-2.6.20-i386-1.8-00.patch

-- 
Philippe.

Re: [Xenomai-help] Xenomai and MSI enabled crashes kernel

[M. Koehrer]

Hi Philippe,

thanks for the new adeos patch.
I have now done the following steps:
I used a vanilla 2.6.20.4 kernel and a non-patched Xenomai 2.3.1.
Then I applied the script scripts/prepare-kernel.sh with the 
adeos-ipipe-2.6.20-i386-1.8-00.patch to patch the kernel.

I am now able to boot my PC with this kernel and my e1000 actually 
works on IRQ223! 
That's perfect.
This is one big step into the right direction!

Now, I want to test the real time stuff.
I can modprobe xeno_native, this seems to work fine.
However, when I want to rmmod xeno_native, rmmod does not return.
dmesg shows the error
APIC error on CPU0 : 00(20)
APIC error on CPU1 : 00(40)

This error comes with out without the e1000 (MSI based) loaded at this time.

I am able to load and unload xeno_nucleus, thus this seems to be a
xeno_native issue.

Regards

Mathias
> 
> Does this patch improve things?
> 
> http://download.gna.org/adeos/patches/v2.6/i386/adeos-ipipe-2.6.20-i386-1.8-
> 00.patch
> 
> -- 
> Philippe.
> 


-- 
Mathias Koehrer
mathias_koehrer@domain.hid


Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren
ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT JETZT bei Arcor: günstig
und schnell mit DSL - das All-Inclusive-Paket für clevere Doppel-Sparer,
nur  39,85 €  inkl. DSL- und ISDN-Grundgebühr!
http://www.arcor.de/rd/emf-dsl-2

Re: [Xenomai-help] Xenomai and MSI enabled crashes kernel

[M. Koehrer]

Hi Philippe,

as mentioned in my previous mail, the new patch works fine. However, I get the error
APIC error on CPU0: 00(20)
APIC error on CPU1: 00(40)
when unloading (rmmod) xeno_native.
I have looked closed to that issue and I have found out that this happens
within the inline function xnarch_notify_halt() (file pod.h)

    for(cpu=0; cpu < nr_cpus-1; ++cpu)
        down(&xnarch_finalize_sync);

Perhaps this helps to detect the issue...

Regards

Mathias
> Does this patch improve things?
> 
> http://download.gna.org/adeos/patches/v2.6/i386/adeos-ipipe-2.6.20-i386-1.8-
> 00.patch
> 
> -- 
> Philippe.
> 
> 
> 

-- 
Mathias Koehrer
mathias_koehrer@domain.hid


Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren
ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT JETZT bei Arcor: günstig
und schnell mit DSL - das All-Inclusive-Paket für clevere Doppel-Sparer,
nur  39,85 €  inkl. DSL- und ISDN-Grundgebühr!
http://www.arcor.de/rd/emf-dsl-2

Re: [Xenomai-help] Xenomai and MSI enabled crashes kernel

[Philippe Gerum]

On Tue, 2007-05-08 at 13:53 +0200, M. Koehrer wrote:
> Hi Philippe,
> 
> as mentioned in my previous mail, the new patch works fine. However, I get the error
> APIC error on CPU0: 00(20)
> APIC error on CPU1: 00(40)
> when unloading (rmmod) xeno_native.
> I have looked closed to that issue and I have found out that this happens
> within the inline function xnarch_notify_halt() (file pod.h)
> 
>     for(cpu=0; cpu < nr_cpus-1; ++cpu)
>         down(&xnarch_finalize_sync);
> 

It's likely happening a few lines earlier, when sending IPI2 to
synchronize all CPUs during Xenomai shutdown. Ok, I will have a look
asap.

> Perhaps this helps to detect the issue...
> 
> Regards
> 
> Mathias
> > Does this patch improve things?
> > 
> > http://download.gna.org/adeos/patches/v2.6/i386/adeos-ipipe-2.6.20-i386-1.8-
> > 00.patch
> > 
> > -- 
> > Philippe.
> > 
> > 
> > 
> 
-- 
Philippe.

Re: [Xenomai-help] Xenomai and MSI enabled crashes kernel

[M. Koehrer]

Hi Philippe,

perhaps one more information regarding that issue: 
When I disable SMP, it seems to work fine (APIC and local APIC are enabled).

Regards

Mathias

> > as mentioned in my previous mail, the new patch works fine. However, I get
> the error
> > APIC error on CPU0: 00(20)
> > APIC error on CPU1: 00(40)
> > when unloading (rmmod) xeno_native.
> > I have looked closed to that issue and I have found out that this happens
> > within the inline function xnarch_notify_halt() (file pod.h)
> > 
> >     for(cpu=0; cpu < nr_cpus-1; ++cpu)
> >         down(&xnarch_finalize_sync);
> > 
> 
> It's likely happening a few lines earlier, when sending IPI2 to
> synchronize all CPUs during Xenomai shutdown. Ok, I will have a look
> asap.
> 


-- 
Mathias Koehrer
mathias_koehrer@domain.hid


Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren
ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT JETZT bei Arcor: günstig
und schnell mit DSL - das All-Inclusive-Paket für clevere Doppel-Sparer,
nur  39,85 €  inkl. DSL- und ISDN-Grundgebühr!
http://www.arcor.de/rd/emf-dsl-2

Re: [Xenomai-help] Xenomai and MSI enabled crashes kernel

[Philippe Gerum]

On Tue, 2007-05-08 at 14:38 +0200, M. Koehrer wrote:
> Hi Philippe,
> 
> perhaps one more information regarding that issue: 
> When I disable SMP, it seems to work fine (APIC and local APIC are enabled).

This sounds reasonable, since IPIs are SMP specific.

> 
> Regards
> 
> Mathias
> 
> > > as mentioned in my previous mail, the new patch works fine. However, I get
> > the error
> > > APIC error on CPU0: 00(20)
> > > APIC error on CPU1: 00(40)
> > > when unloading (rmmod) xeno_native.
> > > I have looked closed to that issue and I have found out that this happens
> > > within the inline function xnarch_notify_halt() (file pod.h)
> > > 
> > >     for(cpu=0; cpu < nr_cpus-1; ++cpu)
> > >         down(&xnarch_finalize_sync);
> > > 
> > 
> > It's likely happening a few lines earlier, when sending IPI2 to
> > synchronize all CPUs during Xenomai shutdown. Ok, I will have a look
> > asap.
> > 
> 
> 
-- 
Philippe.

Re: [Xenomai-help] Xenomai and MSI enabled crashes kernel

[Philippe Gerum]

On Tue, 2007-05-08 at 14:38 +0200, M. Koehrer wrote:
> Hi Philippe,
> 
> perhaps one more information regarding that issue: 
> When I disable SMP, it seems to work fine (APIC and local APIC are enabled).

This should improve things:

--- a/arch/i386/kernel/ipipe.c
+++ b/arch/i386/kernel/ipipe.c
@@ -373,7 +373,7 @@ int fastcall __ipipe_send_ipi (unsigned ipi, cpumask_t cpumask)
        cpu_clear(cpuid,cpumask);

        if (!cpus_empty(cpumask))
-               send_IPI_mask(cpumask,ipi + FIRST_EXTERNAL_VECTOR);
+               send_IPI_mask(cpumask,ipipe_apic_irq_vector(ipi));

        if (self)
                ipipe_trigger_irq(ipi);

-- 
Philippe.

Re: [Xenomai-help] Xenomai and MSI enabled crashes kernel

[M. Koehrer]

Hi Philippe,

that's it! Now, everything seems to run really nicely!
The great thing is, that is I have now one of my e1000 (PCIe) running 
in non real time mode and the other running with rtnet in real time!
They have IRQs 223 resp. 222.
As interrupt sharing was one of the main issues I had, this seems
to be solved now!
In which Xenomai version will the new adeos patch and the fix from today end up?
Or should I use the 2.3.1 and using the new adeos patch + the fix?

Thank you very much for the excellent support!

Regards

Mathias
> On Tue, 2007-05-08 at 14:38 +0200, M. Koehrer wrote:
> > Hi Philippe,
> > 
> > perhaps one more information regarding that issue: 
> > When I disable SMP, it seems to work fine (APIC and local APIC are
> enabled).
> 
> This should improve things:
> 
> --- a/arch/i386/kernel/ipipe.c
> +++ b/arch/i386/kernel/ipipe.c
> @@ -373,7 +373,7 @@ int fastcall __ipipe_send_ipi (unsigned ipi, cpumask_t
> cpumask)
>         cpu_clear(cpuid,cpumask);
> 
>         if (!cpus_empty(cpumask))
> -               send_IPI_mask(cpumask,ipi + FIRST_EXTERNAL_VECTOR);
> +               send_IPI_mask(cpumask,ipipe_apic_irq_vector(ipi));
> 
>         if (self)
>                 ipipe_trigger_irq(ipi);
> 
> -- 
> Philippe.
> 
> 
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
> 

-- 
Mathias Koehrer
mathias_koehrer@domain.hid


Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren
ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT JETZT bei Arcor: günstig
und schnell mit DSL - das All-Inclusive-Paket für clevere Doppel-Sparer,
nur  39,85 €  inkl. DSL- und ISDN-Grundgebühr!
http://www.arcor.de/rd/emf-dsl-2

Re: [Xenomai-help] Xenomai and MSI enabled crashes kernel

[Philippe Gerum]

On Tue, 2007-05-08 at 16:35 +0200, M. Koehrer wrote:
> Hi Philippe,
> 
> that's it! Now, everything seems to run really nicely!
> The great thing is, that is I have now one of my e1000 (PCIe) running 
> in non real time mode and the other running with rtnet in real time!
> They have IRQs 223 resp. 222.
> As interrupt sharing was one of the main issues I had, this seems
> to be solved now!
> In which Xenomai version will the new adeos patch and the fix from today end up?
> Or should I use the 2.3.1 and using the new adeos patch + the fix?

I'll roll out I-pipe/x86 1.8-01 including the latest fixes soon. This
patch will be available from the next 2.3.x maintenance release (2.3.2)
and the trunk.

> 
> Thank you very much for the excellent support!
> 
> Regards
> 
> Mathias
> > On Tue, 2007-05-08 at 14:38 +0200, M. Koehrer wrote:
> > > Hi Philippe,
> > > 
> > > perhaps one more information regarding that issue: 
> > > When I disable SMP, it seems to work fine (APIC and local APIC are
> > enabled).
> > 
> > This should improve things:
> > 
> > --- a/arch/i386/kernel/ipipe.c
> > +++ b/arch/i386/kernel/ipipe.c
> > @@ -373,7 +373,7 @@ int fastcall __ipipe_send_ipi (unsigned ipi, cpumask_t
> > cpumask)
> >         cpu_clear(cpuid,cpumask);
> > 
> >         if (!cpus_empty(cpumask))
> > -               send_IPI_mask(cpumask,ipi + FIRST_EXTERNAL_VECTOR);
> > +               send_IPI_mask(cpumask,ipipe_apic_irq_vector(ipi));
> > 
> >         if (self)
> >                 ipipe_trigger_irq(ipi);
> > 
> > -- 
> > Philippe.
> > 
> > 
> > 
> > _______________________________________________
> > Xenomai-help mailing list
> > Xenomai-help@domain.hid
> > https://mail.gna.org/listinfo/xenomai-help
> > 
> 
-- 
Philippe.