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

["M. Koehrer" <mathias_koehrer@domain.hid>]

[-- 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 --]