* Re: [Xenomai-help] kernel 2.6.32.11 with xenomai 2.5.3 fails to boot on ubuntu lucid system
2010-08-17 10:27 ` Philippe Gerum
@ 2010-08-17 13:51 ` Hemal C.Bavishi
2010-08-17 15:24 ` Stefan Kisdaroczi
2010-08-17 17:01 ` [Xenomai-help] kernel 2.6.32.11 with xenomai 2.5.3 fails to boot on ubuntu lucid system Philippe Gerum
` (2 subsequent siblings)
3 siblings, 1 reply; 54+ messages in thread
From: Hemal C.Bavishi @ 2010-08-17 13:51 UTC (permalink / raw)
To: Philippe Gerum, Theo Veenker; +Cc: Xenomai help
When I tried to compile it with the latest version of kernel with xenomai 2.5.4, I am getting following errors in Xenomai (disable CONFIG_SMP, enable CONFIG_X86_UP_APIC and
CONFIG_X86_UP_IOAPIC (*).)
kernel/xenomai/arch/generic/hal.c:47:29: error: asm/xenomai/hal.h: No such file or directory
kernel/xenomai/arch/generic/hal.c:77: error: ‘RTHAL_NR_CPUS’ undeclared here (not in a function)
kernel/xenomai/arch/generic/hal.c:79: error: ‘RTHAL_NR_APCS’ undeclared here (not in a function)
kernel/xenomai/arch/generic/hal.c:89: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘rthal_apc_lock’
kernel/xenomai/arch/generic/hal.c:93: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘rthal_domain’
kernel/xenomai/arch/generic/hal.c:97: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘rthal_trap_handler’
kernel/xenomai/arch/generic/hal.c:99: error: ‘RTHAL_NR_FAULTS’ undeclared here (not in a function)
kernel/xenomai/arch/generic/hal.c: In function ‘rthal_critical_enter’:
kernel/xenomai/arch/generic/hal.c:105: error: implicit declaration of function ‘rthal_grab_superlock’
kernel/xenomai/arch/generic/hal.c: In function ‘rthal_critical_exit’:
kernel/xenomai/arch/generic/hal.c:118: error: implicit declaration of function ‘rthal_release_superlock’
kernel/xenomai/arch/generic/hal.c: At top level:
kernel/xenomai/arch/generic/hal.c:169: error: expected declaration specifiers or ‘...’ before ‘rthal_irq_handler_t’
kernel/xenomai/arch/generic/hal.c:170: error: expected declaration specifiers or ‘...’ before ‘rthal_irq_ackfn_t’
kernel/xenomai/arch/generic/hal.c: In function ‘rthal_irq_request’:
kernel/xenomai/arch/generic/hal.c:172: error: ‘handler’ undeclared (first use in this function)
kernel/xenomai/arch/generic/hal.c:172: error: (Each undeclared identifier is reported only once
kernel/xenomai/arch/generic/hal.c:172: error: for each function it appears in.)
kernel/xenomai/arch/generic/hal.c:175: error: implicit declaration of function ‘rthal_virtualize_irq’
kernel/xenomai/arch/generic/hal.c:175: error: ‘rthal_domain’ undeclared (first use in this function)
kernel/xenomai/arch/generic/hal.c:179: error: ‘ackfn’ undeclared (first use in this function)
kernel/xenomai/arch/generic/hal.c:180: error: ‘IPIPE_HANDLE_MASK’ undeclared (first use in this function)
kernel/xenomai/arch/generic/hal.c:180: error: ‘IPIPE_WIRED_MASK’ undeclared (first use in this function)
kernel/xenomai/arch/generic/hal.c:181: error: ‘IPIPE_EXCLUSIVE_MASK’ undeclared (first use in this function)
kernel/xenomai/arch/generic/hal.c: In function ‘rthal_irq_release’:
kernel/xenomai/arch/generic/hal.c:215: error: ‘rthal_domain’ undeclared (first use in this function)
kernel/xenomai/arch/generic/hal.c:216: error: ‘IPIPE_PASS_MASK’ undeclared (first use in this function)
kernel/xenomai/arch/generic/hal.c: At top level:
kernel/xenomai/arch/generic/hal.c:390: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘rthal_trap_catch’
kernel/xenomai/arch/generic/hal.c: In function ‘rthal_apc_handler’:
kernel/xenomai/arch/generic/hal.c:400: error: implicit declaration of function ‘rthal_spin_lock’
kernel/xenomai/arch/generic/hal.c:400: error: ‘rthal_apc_lock’ undeclared (first use in this function)
kernel/xenomai/arch/generic/hal.c:402: error: implicit declaration of function ‘rthal_processor_id’
kernel/xenomai/arch/generic/hal.c:413: error: implicit declaration of function ‘ffnz’
kernel/xenomai/arch/generic/hal.c:418: error: implicit declaration of function ‘rthal_spin_unlock’
kernel/xenomai/arch/generic/hal.c: In function ‘rthal_apc_alloc’:
kernel/xenomai/arch/generic/hal.c:526: error: implicit declaration of function ‘rthal_spin_lock_irqsave’
kernel/xenomai/arch/generic/hal.c:526: error: ‘rthal_apc_lock’ undeclared (first use in this function)
kernel/xenomai/arch/generic/hal.c:537: error: implicit declaration of function ‘rthal_spin_unlock_irqrestore’
kernel/xenomai/arch/generic/hal.c: In function ‘rthal_apc_schedule’:
kernel/xenomai/arch/generic/hal.c:608: error: implicit declaration of function ‘rthal_local_irq_save’
kernel/xenomai/arch/generic/hal.c:611: error: implicit declaration of function ‘rthal_schedule_irq_root’
kernel/xenomai/arch/generic/hal.c:613: error: implicit declaration of function ‘rthal_local_irq_restore’
kernel/xenomai/arch/generic/hal.c: In function ‘hal_read_proc’:
kernel/xenomai/arch/generic/hal.c:628: error: ‘IPIPE_MAJOR_NUMBER’ undeclared (first use in this function)
kernel/xenomai/arch/generic/hal.c:629: error: ‘IPIPE_MINOR_NUMBER’ undeclared (first use in this function)
kernel/xenomai/arch/generic/hal.c:630: error: ‘IPIPE_PATCH_NUMBER’ undeclared (first use in this function)
kernel/xenomai/arch/generic/hal.c: In function ‘faults_read_proc’:
kernel/xenomai/arch/generic/hal.c:658: error: ‘rthal_fault_labels’ undeclared (first use in this function)
kernel/xenomai/arch/generic/hal.c: In function ‘rthal_add_proc_leaf’:
kernel/xenomai/arch/generic/hal.c:744: error: implicit declaration of function ‘wrap_proc_dir_entry_owner’
kernel/xenomai/arch/generic/hal.c: In function ‘rthal_proc_register’:
kernel/xenomai/arch/generic/hal.c:786: error: implicit declaration of function ‘rthal_nmi_proc_register’
kernel/xenomai/arch/generic/hal.c: In function ‘rthal_proc_unregister’:
kernel/xenomai/arch/generic/hal.c:793: error: implicit declaration of function ‘rthal_nmi_proc_unregister’
kernel/xenomai/arch/generic/hal.c: In function ‘rthal_init’:
kernel/xenomai/arch/generic/hal.c:806: error: implicit declaration of function ‘rthal_arch_init’
kernel/xenomai/arch/generic/hal.c:832: error: invalid use of undefined type ‘struct rthal_calibration_data’
kernel/xenomai/arch/generic/hal.c:833: error: invalid use of undefined type ‘struct rthal_calibration_data’
kernel/xenomai/arch/generic/hal.c:834: error: invalid use of undefined type ‘struct rthal_calibration_data’
kernel/xenomai/arch/generic/hal.c:840: error: implicit declaration of function ‘rthal_alloc_virq’
kernel/xenomai/arch/generic/hal.c:848: error: ‘rthal_current_domain’ undeclared (first use in this function)
kernel/xenomai/arch/generic/hal.c:851: error: ‘IPIPE_HANDLE_MASK’ undeclared (first use in this function)
kernel/xenomai/arch/generic/hal.c:874: error: implicit declaration of function ‘rthal_register_domain’
kernel/xenomai/arch/generic/hal.c:874: error: ‘rthal_domain’ undeclared (first use in this function)
kernel/xenomai/arch/generic/hal.c:876: error: ‘RTHAL_DOMAIN_ID’ undeclared (first use in this function)
kernel/xenomai/arch/generic/hal.c:877: error: ‘RTHAL_XENO_PRIO’ undeclared (first use in this function)
kernel/xenomai/arch/generic/hal.c:877: error: ‘rthal_domain_entry’ undeclared (first use in this function)
kernel/xenomai/arch/generic/hal.c:915: error: implicit declaration of function ‘rthal_free_virq’
kernel/xenomai/arch/generic/hal.c:918: error: implicit declaration of function ‘rthal_arch_cleanup’
kernel/xenomai/arch/generic/hal.c: In function ‘rthal_exit’:
kernel/xenomai/arch/generic/hal.c:931: error: ‘rthal_current_domain’ undeclared (first use in this function)
kernel/xenomai/arch/generic/hal.c:945: error: implicit declaration of function ‘rthal_unregister_domain’
kernel/xenomai/arch/generic/hal.c:945: error: ‘rthal_domain’ undeclared (first use in this function)
kernel/xenomai/arch/generic/hal.c: At top level:
kernel/xenomai/arch/generic/hal.c:1107: error: ‘rthal_irq_enable’ undeclared here (not in a function)
kernel/xenomai/arch/generic/hal.c:1107: warning: type defaults to ‘int’ in declaration of ‘rthal_irq_enable’
kernel/xenomai/arch/generic/hal.c:1108: error: ‘rthal_irq_disable’ undeclared here (not in a function)
kernel/xenomai/arch/generic/hal.c:1108: warning: type defaults to ‘int’ in declaration of ‘rthal_irq_disable’
kernel/xenomai/arch/generic/hal.c:1109: error: ‘rthal_irq_end’ undeclared here (not in a function)
kernel/xenomai/arch/generic/hal.c:1109: warning: type defaults to ‘int’ in declaration of ‘rthal_irq_end’
kernel/xenomai/arch/generic/hal.c:1110: error: ‘rthal_irq_host_request’ undeclared here (not in a function)
kernel/xenomai/arch/generic/hal.c:1110: warning: type defaults to ‘int’ in declaration of ‘rthal_irq_host_request’
kernel/xenomai/arch/generic/hal.c:1111: error: ‘rthal_irq_host_release’ undeclared here (not in a function)
kernel/xenomai/arch/generic/hal.c:1111: warning: type defaults to ‘int’ in declaration of ‘rthal_irq_host_release’
kernel/xenomai/arch/generic/hal.c:1113: error: ‘rthal_trap_catch’ undeclared here (not in a function)
kernel/xenomai/arch/generic/hal.c:1113: warning: type defaults to ‘int’ in declaration of ‘rthal_trap_catch’
kernel/xenomai/arch/generic/hal.c:1114: error: ‘rthal_timer_request’ undeclared here (not in a function)
kernel/xenomai/arch/generic/hal.c:1114: warning: type defaults to ‘int’ in declaration of ‘rthal_timer_request’
kernel/xenomai/arch/generic/hal.c:1115: error: ‘rthal_timer_release’ undeclared here (not in a function)
kernel/xenomai/arch/generic/hal.c:1115: warning: type defaults to ‘int’ in declaration of ‘rthal_timer_release’
kernel/xenomai/arch/generic/hal.c:1116: error: ‘rthal_timer_calibrate’ undeclared here (not in a function)
kernel/xenomai/arch/generic/hal.c:1116: warning: type defaults to ‘int’ in declaration of ‘rthal_timer_calibrate’
kernel/xenomai/arch/generic/hal.c:1124: error: ‘rthal_domain’ undeclared here (not in a function)
kernel/xenomai/arch/generic/hal.c:1124: warning: type defaults to ‘int’ in declaration of ‘rthal_domain’
kernel/xenomai/arch/generic/hal.c:1135: error: ‘kill_proc_info’ undeclared here (not in a function)
kernel/xenomai/arch/generic/hal.c:1135: warning: type defaults to ‘int’ in declaration of ‘kill_proc_info’
make[6]: *** [kernel/xenomai/arch/generic/hal.o] Error 1
make[5]: *** [kernel/xenomai/arch/generic] Error 2
make[4]: *** [kernel/xenomai/arch] Error 2
make[3]: *** [kernel/xenomai] Error 2
make[2]: *** [kernel] Error 2
make[2]: *** Waiting for unfinished jobs....
CC mm/mincore.o
CC mm/mlock.o
CC mm/mmap.o
CC mm/mprotect.o
CC mm/mremap.o
CC mm/msync.o
CC mm/rmap.o
CC mm/vmalloc.o
CC mm/pagewalk.o
CC mm/init-mm.o
CC mm/bounce.o
CC mm/page_io.o
CC mm/swap_state.o
CC mm/swapfile.o
CC mm/thrash.o
CC mm/dmapool.o
CC mm/hugetlb.o
CC mm/mmu_notifier.o
CC mm/ksm.o
CC mm/slub.o
CC mm/percpu_up.o
CC mm/memcontrol.o
CC mm/page_cgroup.o
CC mm/memory-failure.o
LD mm/built-in.o
make[2]: Leaving directory `/root/linux-2.6.34.2'
make[1]: *** [debian/stamp/build/kernel] Error 2
make[1]: Leaving directory `/root/linux-2.6.34.2'
make: *** [debian/stamp/do-build-arch] Error 2
root@domain.hid# cd latency
________________________________________
From: xenomai-help-bounces@domain.hid [xenomai-help-bounces@domain.hid] On Behalf Of Philippe Gerum [rpm@xenomai.org]
Sent: Tuesday, August 17, 2010 3:57 PM
To: Theo Veenker
Cc: Xenomai help
Subject: Re: [Xenomai-help] kernel 2.6.32.11 with xenomai 2.5.3 fails to boot on ubuntu lucid system
On Mon, 2010-08-16 at 21:14 +0200, Theo Veenker wrote:
> On 08/16/2010 04:26 PM, Theo Veenker wrote:
> > Gilles Chanteperdrix wrote:
> >> Theo Veenker wrote:
> >>> Hi,
> >>>
> >>> I want to upgrade all our PC's from Ubuntu hardy to lucid and in the
> >>> process
> >>> I'm also going from kernel 2.6.29.5 with Xenomai 2.4.8 to kernel
> >>> 2.6.32.11
> >>> with Xenomai 2.5.3.
> >>>
> >>> I first built and tested the 2.6.32.11 kernel with 2.5.3 on my hardy
> >>> system
> >>> and all went fine. But the problem is it just doesn't run on the
> >>> lucid distro.
> >>
> >> This, I do not understand, the kernel does not need any support from the
> >> distribution for booting, how can the same kernel boot with one
> >> distribution, and not with the other? When you say the "same kernel", do
> >> you mean the exact same zImage or bzImage, or do you mean the kernel
> >> with the same configuration, but with a different compiler, or only the
> >> version is identical?
> >>
> >
> > It is a complete mystery to me either. I compiled my kernel into a deb
> > package
> > and installed the very same deb package on three machines:
> > MSI p45 neo3 with Hardy on it -> works OK
> > MSI p45 neo3 with Ludid on it -> nothing (works fine with regular kernel)
> > MSI 945P with Lucid on it: -> nothing (works fine with regular kernel)
> >
> > I'll try the suggestions posted and keep you informed.
>
> OK. Connected a terminal to catch early kernel messages. Still no output
> unfortunately (with the regular kernel I do get output on the terminal,
> so the connection works).
>
> Meanwhile also built and tested kernel 2.6.32.15 + xenomai 2.5.4. Still nothing.
> I'm clueless. I'm running Xenomai for years on dozens of systems and I've
> never run into problems like this. I think I'll have to sit down and take a
> close look at what I'm doing. I've always built my kernels using make-kpkg,
> maybe that somehow introduces a problem here. I'll try without it.
>
> (unfortunately/luckily I have to work from home for a few days so I can't
> get to the test system until later this week)
I failed to reproduce the issue yet, but it very much looks like an
I-pipe bug. Could you try the following config variants when time
allows:
- on 2.6.32.11 or .15, disable CONFIG_SMP, enable CONFIG_X86_UP_APIC
only (*).
- on 2.6.32.11 or .15, disable CONFIG_SMP, enable CONFIG_X86_UP_APIC and
CONFIG_X86_UP_IOAPIC (*).
- on 2.6.32.7, use your normal CONFIG_SMP config, with this patch in:
http://download.gna.org/adeos/patches/v2.6/x86/older/adeos-ipipe-2.6.32.7-x86-2.5-01.patch
(*) you need to switch off CONFIG_SMP first, to see those knobs appear
in the "processor type and features" menu.
The fact that you did see the panic blinking signal at least once tends
to point the finger at some access fault the kernel tries to recover
without success, rather than a sudden freeze. It must happen early
enough during the boot process, for the console not to be available yet
for reporting what the kernel whines about.
We don't know yet if that bug is either the consequence of some
interrupt delivery, and/or induced by code only involved in SMP. Those
test configs may help in discovering this.
TIA,
--
Philippe.
_______________________________________________
Xenomai-help mailing list
Xenomai-help@domain.hid
https://mail.gna.org/listinfo/xenomai-help
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: [Xenomai-help] kernel 2.6.32.11 with xenomai 2.5.3 fails to boot on ubuntu lucid system
2010-08-17 13:51 ` Hemal C.Bavishi
@ 2010-08-17 15:24 ` Stefan Kisdaroczi
2010-08-18 7:09 ` Gilles Chanteperdrix
2010-08-18 18:45 ` [Xenomai-help] kernel 2.6.32.11 with xenomai 2.5.3 fails to boot on ubuntu lucid system [PATCH] Stefan Kisdaroczi
0 siblings, 2 replies; 54+ messages in thread
From: Stefan Kisdaroczi @ 2010-08-17 15:24 UTC (permalink / raw)
To: xenomai
[-- Attachment #1: Type: text/plain, Size: 640 bytes --]
On 17.08.2010 15:51, Hemal C.Bavishi wrote:
> When I tried to compile it with the latest version of kernel with xenomai 2.5.4, I am getting following errors in Xenomai (disable CONFIG_SMP, enable CONFIG_X86_UP_APIC and
> CONFIG_X86_UP_IOAPIC (*).)
>
Just tested, got the same build error with 2.6.34.
If I patch 2.6.34 with prepare-kernel [1] it compiles,
if I use the debian packaged patch generated with prepare-patch [2] it
fails.
I guess a fix is needed in prepare-patch for 2.6.34, but no time to look
closer now.
Stefan
[1] xenomai-2.5.4/scripts/prepare-kernel.sh
[2] xenomai-2.5.4/debian/prepare-patch.sh
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Xenomai-help] kernel 2.6.32.11 with xenomai 2.5.3 fails to boot on ubuntu lucid system
2010-08-17 15:24 ` Stefan Kisdaroczi
@ 2010-08-18 7:09 ` Gilles Chanteperdrix
2010-08-18 9:03 ` Paul
2010-08-18 18:45 ` [Xenomai-help] kernel 2.6.32.11 with xenomai 2.5.3 fails to boot on ubuntu lucid system [PATCH] Stefan Kisdaroczi
1 sibling, 1 reply; 54+ messages in thread
From: Gilles Chanteperdrix @ 2010-08-18 7:09 UTC (permalink / raw)
To: Stefan Kisdaroczi; +Cc: xenomai
Stefan Kisdaroczi wrote:
> On 17.08.2010 15:51, Hemal C.Bavishi wrote:
>> When I tried to compile it with the latest version of kernel with xenomai 2.5.4, I am getting following errors in Xenomai (disable CONFIG_SMP, enable CONFIG_X86_UP_APIC and
>> CONFIG_X86_UP_IOAPIC (*).)
>>
>
> Just tested, got the same build error with 2.6.34.
> If I patch 2.6.34 with prepare-kernel [1] it compiles,
> if I use the debian packaged patch generated with prepare-patch [2] it
> fails.
>
> I guess a fix is needed in prepare-patch for 2.6.34, but no time to look
> closer now.
>
> Stefan
>
> [1] xenomai-2.5.4/scripts/prepare-kernel.sh
> [2] xenomai-2.5.4/debian/prepare-patch.sh
prepare-kernel.sh has a "--outpatch" option, which seems to be able to
generate patches, so, would not it be possible to modify prepare-patch
to simply call prepare-kernel.sh with the --outpatch option?
This way, we will not have to duplicate into prepare-patch.sh the
modifications we make to prepare-kernel.sh.
--
Gilles.
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Xenomai-help] kernel 2.6.32.11 with xenomai 2.5.3 fails to boot on ubuntu lucid system
2010-08-18 7:09 ` Gilles Chanteperdrix
@ 2010-08-18 9:03 ` Paul
2010-08-18 9:06 ` Gilles Chanteperdrix
0 siblings, 1 reply; 54+ messages in thread
From: Paul @ 2010-08-18 9:03 UTC (permalink / raw)
To: xenomai
On Wednesday 18 August 2010, Gilles Chanteperdrix wrote:
> Stefan Kisdaroczi wrote:
> > On 17.08.2010 15:51, Hemal C.Bavishi wrote:
> >> When I tried to compile it with the latest version of kernel with
> >> xenomai 2.5.4, I am getting following errors in Xenomai (disable
> >> CONFIG_SMP, enable CONFIG_X86_UP_APIC and CONFIG_X86_UP_IOAPIC
> >> (*).)
> >
> > Just tested, got the same build error with 2.6.34.
> > If I patch 2.6.34 with prepare-kernel [1] it compiles,
> > if I use the debian packaged patch generated with prepare-patch [2]
> > it fails.
> >
> > I guess a fix is needed in prepare-patch for 2.6.34, but no time to
> > look closer now.
> >
> > Stefan
> >
> > [1] xenomai-2.5.4/scripts/prepare-kernel.sh
> > [2] xenomai-2.5.4/debian/prepare-patch.sh
>
> prepare-kernel.sh has a "--outpatch" option, which seems to be able
> to generate patches, so, would not it be possible to modify
> prepare-patch to simply call prepare-kernel.sh with the --outpatch
> option?
>
> This way, we will not have to duplicate into prepare-patch.sh the
> modifications we make to prepare-kernel.sh.
The debian/prepare-patch.sh does not require a kernel source tree and
generates patches for multiple kernels & arches - It is a fudge, but it
works for the most part and does not impose dependencies of multiple
kernel source trees on package build systems.
Regards, Paul.
Regards, Paul.
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Xenomai-help] kernel 2.6.32.11 with xenomai 2.5.3 fails to boot on ubuntu lucid system
2010-08-18 9:03 ` Paul
@ 2010-08-18 9:06 ` Gilles Chanteperdrix
2010-08-19 15:21 ` Stefan Kisdaroczi
0 siblings, 1 reply; 54+ messages in thread
From: Gilles Chanteperdrix @ 2010-08-18 9:06 UTC (permalink / raw)
To: Paul; +Cc: xenomai
Paul wrote:
> On Wednesday 18 August 2010, Gilles Chanteperdrix wrote:
>> Stefan Kisdaroczi wrote:
>>> On 17.08.2010 15:51, Hemal C.Bavishi wrote:
>>>> When I tried to compile it with the latest version of kernel with
>>>> xenomai 2.5.4, I am getting following errors in Xenomai (disable
>>>> CONFIG_SMP, enable CONFIG_X86_UP_APIC and CONFIG_X86_UP_IOAPIC
>>>> (*).)
>>> Just tested, got the same build error with 2.6.34.
>>> If I patch 2.6.34 with prepare-kernel [1] it compiles,
>>> if I use the debian packaged patch generated with prepare-patch [2]
>>> it fails.
>>>
>>> I guess a fix is needed in prepare-patch for 2.6.34, but no time to
>>> look closer now.
>>>
>>> Stefan
>>>
>>> [1] xenomai-2.5.4/scripts/prepare-kernel.sh
>>> [2] xenomai-2.5.4/debian/prepare-patch.sh
>> prepare-kernel.sh has a "--outpatch" option, which seems to be able
>> to generate patches, so, would not it be possible to modify
>> prepare-patch to simply call prepare-kernel.sh with the --outpatch
>> option?
>>
>> This way, we will not have to duplicate into prepare-patch.sh the
>> modifications we make to prepare-kernel.sh.
>
> The debian/prepare-patch.sh does not require a kernel source tree and
> generates patches for multiple kernels & arches - It is a fudge, but it
> works for the most part and does not impose dependencies of multiple
> kernel source trees on package build systems.
Ok. Understood. The thing is that prepare-patch.sh is broken, so now may
be a good occasion to merge its functionality in prepare-kernel.sh, so
that we do not duplicate the code in these two really non-trivial scripts.
--
Gilles.
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Xenomai-help] kernel 2.6.32.11 with xenomai 2.5.3 fails to boot on ubuntu lucid system
2010-08-18 9:06 ` Gilles Chanteperdrix
@ 2010-08-19 15:21 ` Stefan Kisdaroczi
2010-08-19 15:28 ` Gilles Chanteperdrix
0 siblings, 1 reply; 54+ messages in thread
From: Stefan Kisdaroczi @ 2010-08-19 15:21 UTC (permalink / raw)
To: gilles.chanteperdrix; +Cc: xenomai
[-- Attachment #1: Type: text/plain, Size: 2398 bytes --]
On 18.08.2010 11:06, Gilles Chanteperdrix wrote:
> Paul wrote:
>
>> On Wednesday 18 August 2010, Gilles Chanteperdrix wrote:
>>
>>> Stefan Kisdaroczi wrote:
>>>
>>>> On 17.08.2010 15:51, Hemal C.Bavishi wrote:
>>>>
>>>>> When I tried to compile it with the latest version of kernel with
>>>>> xenomai 2.5.4, I am getting following errors in Xenomai (disable
>>>>> CONFIG_SMP, enable CONFIG_X86_UP_APIC and CONFIG_X86_UP_IOAPIC
>>>>> (*).)
>>>>>
>>>> Just tested, got the same build error with 2.6.34.
>>>> If I patch 2.6.34 with prepare-kernel [1] it compiles,
>>>> if I use the debian packaged patch generated with prepare-patch [2]
>>>> it fails.
>>>>
>>>> I guess a fix is needed in prepare-patch for 2.6.34, but no time to
>>>> look closer now.
>>>>
>>>> Stefan
>>>>
>>>> [1] xenomai-2.5.4/scripts/prepare-kernel.sh
>>>> [2] xenomai-2.5.4/debian/prepare-patch.sh
>>>>
>>> prepare-kernel.sh has a "--outpatch" option, which seems to be able
>>> to generate patches, so, would not it be possible to modify
>>> prepare-patch to simply call prepare-kernel.sh with the --outpatch
>>> option?
>>>
>>> This way, we will not have to duplicate into prepare-patch.sh the
>>> modifications we make to prepare-kernel.sh.
>>>
>> The debian/prepare-patch.sh does not require a kernel source tree and
>> generates patches for multiple kernels & arches - It is a fudge, but it
>> works for the most part and does not impose dependencies of multiple
>> kernel source trees on package build systems.
>>
> Ok. Understood. The thing is that prepare-patch.sh is broken, so now may
> be a good occasion to merge its functionality in prepare-kernel.sh, so
> that we do not duplicate the code in these two really non-trivial scripts.
>
Hi Gilles,
There is another copy. The debian/ directory from the xenomai tree is
not used for debian packages at debian.org. The Debian Maintainer Roland
Stigge has his own debian/ directory.
I submitted a bugreport including the patch for this bug to debian [1].
If we move the prepare-patch.sh out of the debian/ dir (suggested by
Roland), that would not be necessary.
I suggest to move debian/prepare-patch.sh to
scripts/prepare-debian-patch.sh.
I'll create a patch if you agree.
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=593585
Stefan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Xenomai-help] kernel 2.6.32.11 with xenomai 2.5.3 fails to boot on ubuntu lucid system
2010-08-19 15:21 ` Stefan Kisdaroczi
@ 2010-08-19 15:28 ` Gilles Chanteperdrix
2010-08-19 17:13 ` Stefan Kisdaroczi
0 siblings, 1 reply; 54+ messages in thread
From: Gilles Chanteperdrix @ 2010-08-19 15:28 UTC (permalink / raw)
To: Stefan Kisdaroczi; +Cc: xenomai
Stefan Kisdaroczi wrote:
> On 18.08.2010 11:06, Gilles Chanteperdrix wrote:
>> Paul wrote:
>>
>>> On Wednesday 18 August 2010, Gilles Chanteperdrix wrote:
>>>
>>>> Stefan Kisdaroczi wrote:
>>>>
>>>>> On 17.08.2010 15:51, Hemal C.Bavishi wrote:
>>>>>
>>>>>> When I tried to compile it with the latest version of kernel with
>>>>>> xenomai 2.5.4, I am getting following errors in Xenomai (disable
>>>>>> CONFIG_SMP, enable CONFIG_X86_UP_APIC and CONFIG_X86_UP_IOAPIC
>>>>>> (*).)
>>>>>>
>>>>> Just tested, got the same build error with 2.6.34.
>>>>> If I patch 2.6.34 with prepare-kernel [1] it compiles,
>>>>> if I use the debian packaged patch generated with prepare-patch [2]
>>>>> it fails.
>>>>>
>>>>> I guess a fix is needed in prepare-patch for 2.6.34, but no time to
>>>>> look closer now.
>>>>>
>>>>> Stefan
>>>>>
>>>>> [1] xenomai-2.5.4/scripts/prepare-kernel.sh
>>>>> [2] xenomai-2.5.4/debian/prepare-patch.sh
>>>>>
>>>> prepare-kernel.sh has a "--outpatch" option, which seems to be able
>>>> to generate patches, so, would not it be possible to modify
>>>> prepare-patch to simply call prepare-kernel.sh with the --outpatch
>>>> option?
>>>>
>>>> This way, we will not have to duplicate into prepare-patch.sh the
>>>> modifications we make to prepare-kernel.sh.
>>>>
>>> The debian/prepare-patch.sh does not require a kernel source tree and
>>> generates patches for multiple kernels & arches - It is a fudge, but it
>>> works for the most part and does not impose dependencies of multiple
>>> kernel source trees on package build systems.
>>>
>> Ok. Understood. The thing is that prepare-patch.sh is broken, so now may
>> be a good occasion to merge its functionality in prepare-kernel.sh, so
>> that we do not duplicate the code in these two really non-trivial scripts.
>>
>
> Hi Gilles,
>
> There is another copy. The debian/ directory from the xenomai tree is
> not used for debian packages at debian.org. The Debian Maintainer Roland
> Stigge has his own debian/ directory.
Yes, I know that. And this makes me wonder how Roland generated the
patches for 2.5.4, since his script is identical to ours.
> I submitted a bugreport including the patch for this bug to debian [1].
> If we move the prepare-patch.sh out of the debian/ dir (suggested by
> Roland), that would not be necessary.
>
> I suggest to move debian/prepare-patch.sh to
> scripts/prepare-debian-patch.sh.
> I'll create a patch if you agree.
I do not understand how changing the script location or name remove the
duplication between this script and prepare-kernel.sh. We fixed the
issue with the location of ipipe.h in prepare-kernel.sh ages ago, so, as
far as I understand, the bug comes from this duplication.
I really think the good idea is to implement the functionality of
prepare-patch.sh (i.e. being able to generate a patch without the kernel
sources) into prepare-kernel.sh --outpatch command, and simply make
prepare-patch.sh call prepare-kernel, this would end all the duplication
between the two scripts.
--
Gilles.
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Xenomai-help] kernel 2.6.32.11 with xenomai 2.5.3 fails to boot on ubuntu lucid system
2010-08-19 15:28 ` Gilles Chanteperdrix
@ 2010-08-19 17:13 ` Stefan Kisdaroczi
2010-08-19 18:49 ` Gilles Chanteperdrix
0 siblings, 1 reply; 54+ messages in thread
From: Stefan Kisdaroczi @ 2010-08-19 17:13 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
[-- Attachment #1: Type: text/plain, Size: 4997 bytes --]
On 19.08.2010 17:28, Gilles Chanteperdrix wrote:
> Stefan Kisdaroczi wrote:
>
>> On 18.08.2010 11:06, Gilles Chanteperdrix wrote:
>>
>>> Paul wrote:
>>>
>>>
>>>> On Wednesday 18 August 2010, Gilles Chanteperdrix wrote:
>>>>
>>>>
>>>>> Stefan Kisdaroczi wrote:
>>>>>
>>>>>
>>>>>> On 17.08.2010 15:51, Hemal C.Bavishi wrote:
>>>>>>
>>>>>>
>>>>>>> When I tried to compile it with the latest version of kernel with
>>>>>>> xenomai 2.5.4, I am getting following errors in Xenomai (disable
>>>>>>> CONFIG_SMP, enable CONFIG_X86_UP_APIC and CONFIG_X86_UP_IOAPIC
>>>>>>> (*).)
>>>>>>>
>>>>>>>
>>>>>> Just tested, got the same build error with 2.6.34.
>>>>>> If I patch 2.6.34 with prepare-kernel [1] it compiles,
>>>>>> if I use the debian packaged patch generated with prepare-patch [2]
>>>>>> it fails.
>>>>>>
>>>>>> I guess a fix is needed in prepare-patch for 2.6.34, but no time to
>>>>>> look closer now.
>>>>>>
>>>>>> Stefan
>>>>>>
>>>>>> [1] xenomai-2.5.4/scripts/prepare-kernel.sh
>>>>>> [2] xenomai-2.5.4/debian/prepare-patch.sh
>>>>>>
>>>>>>
>>>>> prepare-kernel.sh has a "--outpatch" option, which seems to be able
>>>>> to generate patches, so, would not it be possible to modify
>>>>> prepare-patch to simply call prepare-kernel.sh with the --outpatch
>>>>> option?
>>>>>
>>>>> This way, we will not have to duplicate into prepare-patch.sh the
>>>>> modifications we make to prepare-kernel.sh.
>>>>>
>>>>>
>>>> The debian/prepare-patch.sh does not require a kernel source tree and
>>>> generates patches for multiple kernels & arches - It is a fudge, but it
>>>> works for the most part and does not impose dependencies of multiple
>>>> kernel source trees on package build systems.
>>>>
>>>>
>>> Ok. Understood. The thing is that prepare-patch.sh is broken, so now may
>>> be a good occasion to merge its functionality in prepare-kernel.sh, so
>>> that we do not duplicate the code in these two really non-trivial scripts.
>>>
>>>
>> Hi Gilles,
>>
>> There is another copy. The debian/ directory from the xenomai tree is
>> not used for debian packages at debian.org. The Debian Maintainer Roland
>> Stigge has his own debian/ directory.
>>
> Yes, I know that. And this makes me wonder how Roland generated the
> patches for 2.5.4, since his script is identical to ours.
>
The patch generating worked without obvious problems and the patches
apply cleanly. But the patched kernels are failing to build if
CONFIG_XENOMAI is set on kernels 2.6.33+. As debian squeeze will ship
with a 2.6.32 kernel he probably just tested 2.6.32 and this worked.
There is also a chance that he didn't test to build a xenomai patched
kernel at all, as the important thing was to have 2.5.4 uploaded before
the squeeze-freeze and that no release-critical bugs are filed until the
package migration from unstable to testing. You released 2.5.4 the 2.8.,
he uploaded 4.8., freeze was 6.8. and the package migrated to testing
the 15.8. He already has a upload permission from the
debian-release-team for a bugfix-upload of xenomai. He really is doing a
very good job. Yes, I remember the discussion you had last winter about
2.4.x, but for debian the most important is to have the latest possible
upstream version uploaded just before freeze, and he succeeded.
For a bad maintaining example look at Ubuntu. I filed a bugreport the
22.3.2010:
https://bugs.launchpad.net/ubuntu/+source/xenomai/+bug/544284
No response, no upload, nothing, still xenomai 2.4.8... And Ubuntu is
debian unstable based, so they only have to sync.
This is probably the reason for all those 'building packages for Ubuntu
10.04'-questions on this list. If Ubuntu would ship a newer version the
beginners could directly introduce themselves with the 'Why do i get
negative latency values?'-question :-)
>> If we move the prepare-patch.sh out of the debian/ dir (suggested by
>> Roland), that would not be necessary.
>>
>> I suggest to move debian/prepare-patch.sh to
>> scripts/prepare-debian-patch.sh.
>> I'll create a patch if you agree.
>>
> I do not understand how changing the script location or name remove the
> duplication between this script and prepare-kernel.sh. We fixed the
> issue with the location of ipipe.h in prepare-kernel.sh ages ago, so, as
> far as I understand, the bug comes from this duplication.
>
> I really think the good idea is to implement the functionality of
> prepare-patch.sh (i.e. being able to generate a patch without the kernel
> sources) into prepare-kernel.sh --outpatch command, and simply make
> prepare-patch.sh call prepare-kernel, this would end all the duplication
> between the two scripts.
>
ok, as you said above it's 'non-trivial' but on the other side we are
not in a hurry.
Stefan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Xenomai-help] kernel 2.6.32.11 with xenomai 2.5.3 fails to boot on ubuntu lucid system
2010-08-19 17:13 ` Stefan Kisdaroczi
@ 2010-08-19 18:49 ` Gilles Chanteperdrix
2010-08-20 16:43 ` Stefan Kisdaroczi
0 siblings, 1 reply; 54+ messages in thread
From: Gilles Chanteperdrix @ 2010-08-19 18:49 UTC (permalink / raw)
To: Stefan Kisdaroczi; +Cc: xenomai
Stefan Kisdaroczi wrote:
> On 19.08.2010 17:28, Gilles Chanteperdrix wrote:
>> Yes, I know that. And this makes me wonder how Roland generated the
>> patches for 2.5.4, since his script is identical to ours.
>>
>
> The patch generating worked without obvious problems and the patches
> apply cleanly. But the patched kernels are failing to build if
> CONFIG_XENOMAI is set on kernels 2.6.33+. As debian squeeze will ship
> with a 2.6.32 kernel he probably just tested 2.6.32 and this worked.
>
> There is also a chance that he didn't test to build a xenomai patched
> kernel at all, as the important thing was to have 2.5.4 uploaded before
> the squeeze-freeze and that no release-critical bugs are filed until the
> package migration from unstable to testing. You released 2.5.4 the 2.8.,
> he uploaded 4.8., freeze was 6.8. and the package migrated to testing
> the 15.8. He already has a upload permission from the
> debian-release-team for a bugfix-upload of xenomai. He really is doing a
> very good job. Yes, I remember the discussion you had last winter about
> 2.4.x, but for debian the most important is to have the latest possible
> upstream version uploaded just before freeze, and he succeeded.
Oh boy, this was a genuine question, I was not attempting any critics of
any kind... I was impressed that 2.5.4 made it to squeeze.
>
> For a bad maintaining example look at Ubuntu. I filed a bugreport the
> 22.3.2010:
> https://bugs.launchpad.net/ubuntu/+source/xenomai/+bug/544284
> No response, no upload, nothing, still xenomai 2.4.8... And Ubuntu is
> debian unstable based, so they only have to sync.
> This is probably the reason for all those 'building packages for Ubuntu
> 10.04'-questions on this list. If Ubuntu would ship a newer version the
> beginners could directly introduce themselves with the 'Why do i get
> negative latency values?'-question :-)
No comment. I had to use Ubuntu for some time, and did not like it.
>
>>> If we move the prepare-patch.sh out of the debian/ dir (suggested by
>>> Roland), that would not be necessary.
>>>
>>> I suggest to move debian/prepare-patch.sh to
>>> scripts/prepare-debian-patch.sh.
>>> I'll create a patch if you agree.
>>>
>> I do not understand how changing the script location or name remove the
>> duplication between this script and prepare-kernel.sh. We fixed the
>> issue with the location of ipipe.h in prepare-kernel.sh ages ago, so, as
>> far as I understand, the bug comes from this duplication.
>>
>> I really think the good idea is to implement the functionality of
>> prepare-patch.sh (i.e. being able to generate a patch without the kernel
>> sources) into prepare-kernel.sh --outpatch command, and simply make
>> prepare-patch.sh call prepare-kernel, this would end all the duplication
>> between the two scripts.
>>
>
> ok, as you said above it's 'non-trivial' but on the other side we are
> not in a hurry.
Ok. I will try and have a look at modifying prepare-kernel.sh, probably
this week-end. When done, I will let someone else (probably you ?)
modify prepare-patch.sh. In the meantime, I will merge the patch you
sent which fixes prepare-patch.sh, and the other one which moves
prepare-patch.sh.
--
Gilles.
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Xenomai-help] kernel 2.6.32.11 with xenomai 2.5.3 fails to boot on ubuntu lucid system
2010-08-19 18:49 ` Gilles Chanteperdrix
@ 2010-08-20 16:43 ` Stefan Kisdaroczi
0 siblings, 0 replies; 54+ messages in thread
From: Stefan Kisdaroczi @ 2010-08-20 16:43 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
[-- Attachment #1.1: Type: text/plain, Size: 577 bytes --]
On 19.08.2010 20:49, Gilles Chanteperdrix wrote:
> Stefan Kisdaroczi wrote:
>
> [...]
>> ok, as you said above it's 'non-trivial' but on the other side we are
>> not in a hurry.
>>
> Ok. I will try and have a look at modifying prepare-kernel.sh, probably
> this week-end. When done, I will let someone else (probably you ?)
>
Thank you.
> modify prepare-patch.sh. In the meantime, I will merge the patch you
> sent which fixes prepare-patch.sh, and the other one which moves
> prepare-patch.sh.
>
I sent only one, attached both now.
Stefan
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: 0001-debian-fix-asm-include-directory-linking-in-prepare-.patch --]
[-- Type: text/x-patch; name="0001-debian-fix-asm-include-directory-linking-in-prepare-.patch", Size: 930 bytes --]
From 80e14710c85f35e9e62657c5b89ea5c271b977e4 Mon Sep 17 00:00:00 2001
From: Stefan Kisdaroczi <kisda@domain.hid>
Date: Wed, 18 Aug 2010 20:24:15 +0200
Subject: [PATCH 1/2] debian: fix asm include directory linking in prepare-patch.sh
---
debian/prepare-patch.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/debian/prepare-patch.sh b/debian/prepare-patch.sh
index 296638d..6ca734b 100755
--- a/debian/prepare-patch.sh
+++ b/debian/prepare-patch.sh
@@ -112,7 +112,7 @@ for linux_arch in $supported_arch ; do
esac
patch_link r m ksrc/arch/$base_arch arch/$linux_arch/xenomai
- patch_link r n include/asm-$base_arch include/asm-$linux_arch/xenomai
+ patch_link r n include/asm-$base_arch arch/$linux_arch/include/asm/xenomai
p="+drivers-\$(CONFIG_XENOMAI) += arch/$linux_arch/xenomai/"
echo $p | patch_append arch/$linux_arch/Makefile
--
1.7.1
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.3: 0002-debian-move-debian-prepare-patch.sh-to-scripts.patch --]
[-- Type: text/x-patch; name="0002-debian-move-debian-prepare-patch.sh-to-scripts.patch", Size: 14341 bytes --]
From 1ebcd79e2b1dce0c52c7ad327245774ca053091b Mon Sep 17 00:00:00 2001
From: Stefan Kisdaroczi <kisda@domain.hid>
Date: Fri, 20 Aug 2010 18:19:32 +0200
Subject: [PATCH 2/2] debian: move debian/prepare-patch.sh to scripts/
---
debian/prepare-patch.sh | 201 ----------------------------------------------
debian/rules | 2 +-
scripts/prepare-patch.sh | 201 ++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 202 insertions(+), 202 deletions(-)
delete mode 100755 debian/prepare-patch.sh
create mode 100755 scripts/prepare-patch.sh
diff --git a/debian/prepare-patch.sh b/debian/prepare-patch.sh
deleted file mode 100755
index 6ca734b..0000000
--- a/debian/prepare-patch.sh
+++ /dev/null
@@ -1,201 +0,0 @@
-#! /bin/bash
-
-#----------------------------------------------------------------------
-# Description: Hacked down & butchered scripts/prepare-kernel.sh..
-# Script to copy assorted sources to a temp directory and
-# generate a kernel patch without the need of a virgin
-# linux source tree.
-#----------------------------------------------------------------------
-
-set -e
-
-unset CDPATH
-
-patch_file=xenomai_all.patch
-
-supported_arch="$*"
-
-patch_append() {
- file="$1"
-
-# echo "diff -u1wbr orig/$file new/$file" >> $patch_file
- echo "--- linux/$file 1970-01-01 01:00:00.000000000 +0100" >> $patch_file
- echo "+++ linux-patched/$file 2007-03-06 17:55:58.000000000 +0000" >> $patch_file
- echo "@@ -500,0 +500,2 @@" >> $patch_file
- echo "+" >> $patch_file
- cat >> $patch_file
-}
-
-patch_link() {
- recursive="$1" # "r" or "n"
- link_makefiles="$2" # "m" or "n"
- target_dir="$3"
- link_dir="$4"
-
- (
- recursive_opt=""
- directorytype_opt=""
- if test x$recursive = xr; then
- recursive_opts="-mindepth 1"
- directorytype_opt="-type d -o"
- else
- recursive_opt="-maxdepth 1"
- fi
- link_makefiles_opt=""
- if test x$link_makefiles = xm; then
- link_makefiles_opt="-name Makefile -o"
- fi
-
- cd $xenomai_root/$target_dir &&
- find . $recursive_opt \( $link_makefiles_opt -name Kconfig -o -name '*.[chS]' \) |
- while read f; do
- f=`echo $f | cut -d/ -f2-`
- d=`dirname $f`
- if test ! -d $temp_tree/$link_dir/$d ; then
- mkdir -p $temp_tree/$link_dir/$d
- fi
- cp $xenomai_root/$target_dir/$f $temp_tree/$link_dir/$f
- done
- )
-
-}
-
-generate_patch() {
- (
- cd "$temp_tree"
- find . -name demos -o -name snippets -exec rm -fR {} \+ &&
- find . -type f |
- while read f ; do
- diff -Naurd "$linux_tree/$f" "$f" |
- sed -e "s,^--- ${linux_tree}/\.\(/.*\)$,--- linux\1," \
- -e "s,^+++ \.\(/.*\)$,+++ linux-patched\1,"
- done
- )
-}
-
-diff_addons() {
- lines=`cat $xenomai_root/scripts/Kconfig.frag | wc -l`
-
- echo "--- linux/init/Kconfig 1970-01-01 01:00:00.000000000 +0100" >> $patch_file
- echo "+++ linux-patched/init/Kconfig 2007-03-06 17:55:58.000000000 +0000" >> $patch_file
- echo "@@ -1400,0 +1400,$lines @@" >> $patch_file
- sed -e "s,@LINUX_ARCH@,$linux_arch,g" $xenomai_root/scripts/Kconfig.frag | sed 's/^/+/' >> $patch_file
- echo " " >> $patch_file
-}
-
-xenomai_root=`dirname $0`/..
-xenomai_root=`cd $xenomai_root && pwd`
-
-rm -fR $xenomai_root/tmp
-rm -f $patch_file
-
-mkdir -p $xenomai_root/tmp/linux
-mkdir -p $xenomai_root/tmp/linux.new
-linux_tree="$xenomai_root/tmp/linux"
-temp_tree="$xenomai_root/tmp/linux.new"
-
-
-for linux_arch in $supported_arch ; do
- case $linux_arch in
- i386)
- base_arch=x86
- ;;
- x86_64)
- base_arch=x86
- ;;
- x86)
- base_arch=x86
- ;;
- *)
- base_arch=$linux_arch
- ;;
- esac
-
- patch_link r m ksrc/arch/$base_arch arch/$linux_arch/xenomai
- patch_link r n include/asm-$base_arch arch/$linux_arch/include/asm/xenomai
-
- p="+drivers-\$(CONFIG_XENOMAI) += arch/$linux_arch/xenomai/"
- echo $p | patch_append arch/$linux_arch/Makefile
- diff_addons
-done
-
-p="+obj-\$(CONFIG_XENOMAI) += xenomai/"
-echo $p | patch_append drivers/Makefile
-
-p="+obj-\$(CONFIG_XENOMAI) += xenomai/"
-echo $p | patch_append kernel/Makefile
-
-# Create local directories then symlink to the source files from
-# there, so that we don't pollute the Xenomai source tree with
-# compilation files.
-patch_link n m ksrc/ kernel/xenomai
-patch_link n m ksrc/arch kernel/xenomai/arch
-patch_link r m ksrc/arch/generic kernel/xenomai/arch/generic
-patch_link n m ksrc/nucleus kernel/xenomai/nucleus
-patch_link r m ksrc/skins kernel/xenomai/skins
-patch_link r m ksrc/drivers drivers/xenomai
-patch_link r n include/asm-generic include/asm-generic/xenomai
-patch_link n n include include/xenomai
-cd $xenomai_root
-for d in include/* ; do
- if test -d $d -a -z "`echo $d | grep '^include/asm-'`"; then
- destdir=`echo $d | sed -e 's,^\(include\)\(/.*\)$,\1/xenomai\2,'`
- patch_link r n $d $destdir
- fi
-done
-
-generate_patch >> $patch_file
-
-cd $xenomai_root
-
-#echo "Patch-name: Xenomai realtime kernel patches" > $xenomai_root/debian/linux-patch-xenomai.kpatches
-#echo "Patch-id: xenomai" >> $xenomai_root/debian/linux-patch-xenomai.kpatches
-#echo "Architecture: all" >> $xenomai_root/debian/linux-patch-xenomai.kpatches
-
-find $xenomai_root/ksrc/ -name "adeos-ipipe-2.6.*-$supported_arch-*.patch" |
-while read f ; do
-
- file=`basename $f`
- arch=`echo $file | cut -d- -f4`
- kver=`echo $file | cut -d- -f3`
-
- case $arch in
- arm)
- march=arm
- ;;
- i386)
- march=i386
- ;;
- ppc|ppc64|powerpc)
- march=powerpc
- ;;
- x86_64)
- march=amd64
- ;;
- x86)
- march=i386
- ;;
- esac
-
- # Only one patch per arch/kver - Having a common plus kver/arch patch
- # would require two linux-patch-foo packages.. When dh-kpatches Ver.1.0
- # gets to testing, this can be looked at again..
- echo "" >> $xenomai_root/debian/linux-patch-xenomai.kpatches
- echo "Patch-file: $file" >> $xenomai_root/debian/linux-patch-xenomai.kpatches
- echo "Kernel-version: $kver" >> $xenomai_root/debian/linux-patch-xenomai.kpatches
- echo "Architecture: $march" >> $xenomai_root/debian/linux-patch-xenomai.kpatches
-
- if [ "$arch" = "x86" ] ; then
- echo "" >> $xenomai_root/debian/linux-patch-xenomai.kpatches
- echo "Patch-file: $file" >> $xenomai_root/debian/linux-patch-xenomai.kpatches
- echo "Kernel-version: $kver" >> $xenomai_root/debian/linux-patch-xenomai.kpatches
- echo "Architecture: amd64" >> $xenomai_root/debian/linux-patch-xenomai.kpatches
- fi
-
- cp $f $xenomai_root/$file
- cat $xenomai_root/$patch_file >> $xenomai_root/$file
-
-done
-
-exit 0
-
diff --git a/debian/rules b/debian/rules
index e39977d..788b031 100755
--- a/debian/rules
+++ b/debian/rules
@@ -63,7 +63,7 @@ patch-stamp:
dh_testdir
cp debian/linux-patch-xenomai.kpatches.in debian/linux-patch-xenomai.kpatches
for i in arm i386 powerpc x86_64 x86 ; do \
- bash $(CURDIR)/debian/prepare-patch.sh $$i ; \
+ bash $(CURDIR)/scripts/prepare-patch.sh $$i ; \
done
touch patch-stamp
diff --git a/scripts/prepare-patch.sh b/scripts/prepare-patch.sh
new file mode 100755
index 0000000..6ca734b
--- /dev/null
+++ b/scripts/prepare-patch.sh
@@ -0,0 +1,201 @@
+#! /bin/bash
+
+#----------------------------------------------------------------------
+# Description: Hacked down & butchered scripts/prepare-kernel.sh..
+# Script to copy assorted sources to a temp directory and
+# generate a kernel patch without the need of a virgin
+# linux source tree.
+#----------------------------------------------------------------------
+
+set -e
+
+unset CDPATH
+
+patch_file=xenomai_all.patch
+
+supported_arch="$*"
+
+patch_append() {
+ file="$1"
+
+# echo "diff -u1wbr orig/$file new/$file" >> $patch_file
+ echo "--- linux/$file 1970-01-01 01:00:00.000000000 +0100" >> $patch_file
+ echo "+++ linux-patched/$file 2007-03-06 17:55:58.000000000 +0000" >> $patch_file
+ echo "@@ -500,0 +500,2 @@" >> $patch_file
+ echo "+" >> $patch_file
+ cat >> $patch_file
+}
+
+patch_link() {
+ recursive="$1" # "r" or "n"
+ link_makefiles="$2" # "m" or "n"
+ target_dir="$3"
+ link_dir="$4"
+
+ (
+ recursive_opt=""
+ directorytype_opt=""
+ if test x$recursive = xr; then
+ recursive_opts="-mindepth 1"
+ directorytype_opt="-type d -o"
+ else
+ recursive_opt="-maxdepth 1"
+ fi
+ link_makefiles_opt=""
+ if test x$link_makefiles = xm; then
+ link_makefiles_opt="-name Makefile -o"
+ fi
+
+ cd $xenomai_root/$target_dir &&
+ find . $recursive_opt \( $link_makefiles_opt -name Kconfig -o -name '*.[chS]' \) |
+ while read f; do
+ f=`echo $f | cut -d/ -f2-`
+ d=`dirname $f`
+ if test ! -d $temp_tree/$link_dir/$d ; then
+ mkdir -p $temp_tree/$link_dir/$d
+ fi
+ cp $xenomai_root/$target_dir/$f $temp_tree/$link_dir/$f
+ done
+ )
+
+}
+
+generate_patch() {
+ (
+ cd "$temp_tree"
+ find . -name demos -o -name snippets -exec rm -fR {} \+ &&
+ find . -type f |
+ while read f ; do
+ diff -Naurd "$linux_tree/$f" "$f" |
+ sed -e "s,^--- ${linux_tree}/\.\(/.*\)$,--- linux\1," \
+ -e "s,^+++ \.\(/.*\)$,+++ linux-patched\1,"
+ done
+ )
+}
+
+diff_addons() {
+ lines=`cat $xenomai_root/scripts/Kconfig.frag | wc -l`
+
+ echo "--- linux/init/Kconfig 1970-01-01 01:00:00.000000000 +0100" >> $patch_file
+ echo "+++ linux-patched/init/Kconfig 2007-03-06 17:55:58.000000000 +0000" >> $patch_file
+ echo "@@ -1400,0 +1400,$lines @@" >> $patch_file
+ sed -e "s,@LINUX_ARCH@,$linux_arch,g" $xenomai_root/scripts/Kconfig.frag | sed 's/^/+/' >> $patch_file
+ echo " " >> $patch_file
+}
+
+xenomai_root=`dirname $0`/..
+xenomai_root=`cd $xenomai_root && pwd`
+
+rm -fR $xenomai_root/tmp
+rm -f $patch_file
+
+mkdir -p $xenomai_root/tmp/linux
+mkdir -p $xenomai_root/tmp/linux.new
+linux_tree="$xenomai_root/tmp/linux"
+temp_tree="$xenomai_root/tmp/linux.new"
+
+
+for linux_arch in $supported_arch ; do
+ case $linux_arch in
+ i386)
+ base_arch=x86
+ ;;
+ x86_64)
+ base_arch=x86
+ ;;
+ x86)
+ base_arch=x86
+ ;;
+ *)
+ base_arch=$linux_arch
+ ;;
+ esac
+
+ patch_link r m ksrc/arch/$base_arch arch/$linux_arch/xenomai
+ patch_link r n include/asm-$base_arch arch/$linux_arch/include/asm/xenomai
+
+ p="+drivers-\$(CONFIG_XENOMAI) += arch/$linux_arch/xenomai/"
+ echo $p | patch_append arch/$linux_arch/Makefile
+ diff_addons
+done
+
+p="+obj-\$(CONFIG_XENOMAI) += xenomai/"
+echo $p | patch_append drivers/Makefile
+
+p="+obj-\$(CONFIG_XENOMAI) += xenomai/"
+echo $p | patch_append kernel/Makefile
+
+# Create local directories then symlink to the source files from
+# there, so that we don't pollute the Xenomai source tree with
+# compilation files.
+patch_link n m ksrc/ kernel/xenomai
+patch_link n m ksrc/arch kernel/xenomai/arch
+patch_link r m ksrc/arch/generic kernel/xenomai/arch/generic
+patch_link n m ksrc/nucleus kernel/xenomai/nucleus
+patch_link r m ksrc/skins kernel/xenomai/skins
+patch_link r m ksrc/drivers drivers/xenomai
+patch_link r n include/asm-generic include/asm-generic/xenomai
+patch_link n n include include/xenomai
+cd $xenomai_root
+for d in include/* ; do
+ if test -d $d -a -z "`echo $d | grep '^include/asm-'`"; then
+ destdir=`echo $d | sed -e 's,^\(include\)\(/.*\)$,\1/xenomai\2,'`
+ patch_link r n $d $destdir
+ fi
+done
+
+generate_patch >> $patch_file
+
+cd $xenomai_root
+
+#echo "Patch-name: Xenomai realtime kernel patches" > $xenomai_root/debian/linux-patch-xenomai.kpatches
+#echo "Patch-id: xenomai" >> $xenomai_root/debian/linux-patch-xenomai.kpatches
+#echo "Architecture: all" >> $xenomai_root/debian/linux-patch-xenomai.kpatches
+
+find $xenomai_root/ksrc/ -name "adeos-ipipe-2.6.*-$supported_arch-*.patch" |
+while read f ; do
+
+ file=`basename $f`
+ arch=`echo $file | cut -d- -f4`
+ kver=`echo $file | cut -d- -f3`
+
+ case $arch in
+ arm)
+ march=arm
+ ;;
+ i386)
+ march=i386
+ ;;
+ ppc|ppc64|powerpc)
+ march=powerpc
+ ;;
+ x86_64)
+ march=amd64
+ ;;
+ x86)
+ march=i386
+ ;;
+ esac
+
+ # Only one patch per arch/kver - Having a common plus kver/arch patch
+ # would require two linux-patch-foo packages.. When dh-kpatches Ver.1.0
+ # gets to testing, this can be looked at again..
+ echo "" >> $xenomai_root/debian/linux-patch-xenomai.kpatches
+ echo "Patch-file: $file" >> $xenomai_root/debian/linux-patch-xenomai.kpatches
+ echo "Kernel-version: $kver" >> $xenomai_root/debian/linux-patch-xenomai.kpatches
+ echo "Architecture: $march" >> $xenomai_root/debian/linux-patch-xenomai.kpatches
+
+ if [ "$arch" = "x86" ] ; then
+ echo "" >> $xenomai_root/debian/linux-patch-xenomai.kpatches
+ echo "Patch-file: $file" >> $xenomai_root/debian/linux-patch-xenomai.kpatches
+ echo "Kernel-version: $kver" >> $xenomai_root/debian/linux-patch-xenomai.kpatches
+ echo "Architecture: amd64" >> $xenomai_root/debian/linux-patch-xenomai.kpatches
+ fi
+
+ cp $f $xenomai_root/$file
+ cat $xenomai_root/$patch_file >> $xenomai_root/$file
+
+done
+
+exit 0
+
--
1.7.1
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply related [flat|nested] 54+ messages in thread
* Re: [Xenomai-help] kernel 2.6.32.11 with xenomai 2.5.3 fails to boot on ubuntu lucid system [PATCH]
2010-08-17 15:24 ` Stefan Kisdaroczi
2010-08-18 7:09 ` Gilles Chanteperdrix
@ 2010-08-18 18:45 ` Stefan Kisdaroczi
2010-08-18 18:58 ` Stefan Kisdaroczi
2010-08-18 21:08 ` Paul
1 sibling, 2 replies; 54+ messages in thread
From: Stefan Kisdaroczi @ 2010-08-18 18:45 UTC (permalink / raw)
To: xenomai
[-- Attachment #1.1: Type: text/plain, Size: 917 bytes --]
On 17.08.2010 17:24, Stefan Kisdaroczi wrote:
> On 17.08.2010 15:51, Hemal C.Bavishi wrote:
>
>> When I tried to compile it with the latest version of kernel with xenomai 2.5.4, I am getting following errors in Xenomai (disable CONFIG_SMP, enable CONFIG_X86_UP_APIC and
>> CONFIG_X86_UP_IOAPIC (*).)
>>
>>
> Just tested, got the same build error with 2.6.34.
> If I patch 2.6.34 with prepare-kernel [1] it compiles,
> if I use the debian packaged patch generated with prepare-patch [2] it
> fails.
>
> I guess a fix is needed in prepare-patch for 2.6.34, but no time to look
> closer now.
>
patch for prepare-patch.sh attached.
prepare-kernel.sh try's to find ipipe.h and uses the old or new tree
structure. Is it ok to change this unconditionally in prepare-patch.sh?
All adeos-patches in xenomai-2.5.git have ipipe.h in
arch/$linux_arch/include/asm/, so i think yes.
Stefan
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: 0001-debian-fix-asm-include-directory-linking-in-prepare-.patch --]
[-- Type: text/x-patch; name="0001-debian-fix-asm-include-directory-linking-in-prepare-.patch", Size: 926 bytes --]
From 8e792591e8c42a4c38d16514e02622f3398c9f22 Mon Sep 17 00:00:00 2001
From: Stefan Kisdaroczi <kisda@domain.hid>
Date: Wed, 18 Aug 2010 20:24:15 +0200
Subject: [PATCH] debian: fix asm include directory linking in prepare-patch.sh
---
debian/prepare-patch.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/debian/prepare-patch.sh b/debian/prepare-patch.sh
index 296638d..6ca734b 100755
--- a/debian/prepare-patch.sh
+++ b/debian/prepare-patch.sh
@@ -112,7 +112,7 @@ for linux_arch in $supported_arch ; do
esac
patch_link r m ksrc/arch/$base_arch arch/$linux_arch/xenomai
- patch_link r n include/asm-$base_arch include/asm-$linux_arch/xenomai
+ patch_link r n include/asm-$base_arch arch/$linux_arch/include/asm/xenomai
p="+drivers-\$(CONFIG_XENOMAI) += arch/$linux_arch/xenomai/"
echo $p | patch_append arch/$linux_arch/Makefile
--
1.7.1
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply related [flat|nested] 54+ messages in thread* Re: [Xenomai-help] kernel 2.6.32.11 with xenomai 2.5.3 fails to boot on ubuntu lucid system [PATCH]
2010-08-18 18:45 ` [Xenomai-help] kernel 2.6.32.11 with xenomai 2.5.3 fails to boot on ubuntu lucid system [PATCH] Stefan Kisdaroczi
@ 2010-08-18 18:58 ` Stefan Kisdaroczi
2010-08-18 21:08 ` Paul
1 sibling, 0 replies; 54+ messages in thread
From: Stefan Kisdaroczi @ 2010-08-18 18:58 UTC (permalink / raw)
To: xenomai
[-- Attachment #1: Type: text/plain, Size: 1419 bytes --]
On 18.08.2010 20:45, Stefan Kisdaroczi wrote:
> On 17.08.2010 17:24, Stefan Kisdaroczi wrote:
>
>> On 17.08.2010 15:51, Hemal C.Bavishi wrote:
>>
>>
>>> When I tried to compile it with the latest version of kernel with xenomai 2.5.4, I am getting following errors in Xenomai (disable CONFIG_SMP, enable CONFIG_X86_UP_APIC and
>>> CONFIG_X86_UP_IOAPIC (*).)
>>>
>>>
>>>
>> Just tested, got the same build error with 2.6.34.
>> If I patch 2.6.34 with prepare-kernel [1] it compiles,
>> if I use the debian packaged patch generated with prepare-patch [2] it
>> fails.
>>
>> I guess a fix is needed in prepare-patch for 2.6.34, but no time to look
>> closer now.
>>
>>
> patch for prepare-patch.sh attached.
> prepare-kernel.sh try's to find ipipe.h and uses the old or new tree
> structure. Is it ok to change this unconditionally in prepare-patch.sh?
> All adeos-patches in xenomai-2.5.git have ipipe.h in
> arch/$linux_arch/include/asm/, so i think yes.
>
>
prepare-patch.sh worked with the wrong path until this commit for linux
2.6.33:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=c95fa08a3e17c3f2983c4cbf409f5c9ae47b7dec
> Stefan
>
>
>
>
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Xenomai-help] kernel 2.6.32.11 with xenomai 2.5.3 fails to boot on ubuntu lucid system [PATCH]
2010-08-18 18:45 ` [Xenomai-help] kernel 2.6.32.11 with xenomai 2.5.3 fails to boot on ubuntu lucid system [PATCH] Stefan Kisdaroczi
2010-08-18 18:58 ` Stefan Kisdaroczi
@ 2010-08-18 21:08 ` Paul
1 sibling, 0 replies; 54+ messages in thread
From: Paul @ 2010-08-18 21:08 UTC (permalink / raw)
To: xenomai
On Wednesday 18 August 2010, Stefan Kisdaroczi wrote:
> On 17.08.2010 17:24, Stefan Kisdaroczi wrote:
> > On 17.08.2010 15:51, Hemal C.Bavishi wrote:
> >> When I tried to compile it with the latest version of kernel with
> >> xenomai 2.5.4, I am getting following errors in Xenomai (disable
> >> CONFIG_SMP, enable CONFIG_X86_UP_APIC and CONFIG_X86_UP_IOAPIC
> >> (*).)
> >
> > Just tested, got the same build error with 2.6.34.
> > If I patch 2.6.34 with prepare-kernel [1] it compiles,
> > if I use the debian packaged patch generated with prepare-patch [2]
> > it fails.
> >
> > I guess a fix is needed in prepare-patch for 2.6.34, but no time to
> > look closer now.
>
> patch for prepare-patch.sh attached.
> prepare-kernel.sh try's to find ipipe.h and uses the old or new tree
> structure. Is it ok to change this unconditionally in
> prepare-patch.sh? All adeos-patches in xenomai-2.5.git have ipipe.h
> in
> arch/$linux_arch/include/asm/, so i think yes.
As long as no one tries to include a patch for anything prior to 2.6.28
(I think that is when everything moved to arch/*/include/asm) - There
is only one ipipe patch in head currently for 2.6.25-ppc, but I doubt
if anyone would be using it on a Debian build.
For that one case, I don't think it worth adding any additional
complexity to generate a patch with a limited life span.
Regards, Paul.
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Xenomai-help] kernel 2.6.32.11 with xenomai 2.5.3 fails to boot on ubuntu lucid system
2010-08-17 10:27 ` Philippe Gerum
2010-08-17 13:51 ` Hemal C.Bavishi
@ 2010-08-17 17:01 ` Philippe Gerum
2010-08-17 17:43 ` Stefan Kisdaroczi
2010-08-20 12:31 ` Theo Veenker
3 siblings, 0 replies; 54+ messages in thread
From: Philippe Gerum @ 2010-08-17 17:01 UTC (permalink / raw)
To: Theo Veenker; +Cc: Xenomai help
On Tue, 2010-08-17 at 12:27 +0200, Philippe Gerum wrote:
> On Mon, 2010-08-16 at 21:14 +0200, Theo Veenker wrote:
> > On 08/16/2010 04:26 PM, Theo Veenker wrote:
> > > Gilles Chanteperdrix wrote:
> > >> Theo Veenker wrote:
> > >>> Hi,
> > >>>
> > >>> I want to upgrade all our PC's from Ubuntu hardy to lucid and in the
> > >>> process
> > >>> I'm also going from kernel 2.6.29.5 with Xenomai 2.4.8 to kernel
> > >>> 2.6.32.11
> > >>> with Xenomai 2.5.3.
> > >>>
> > >>> I first built and tested the 2.6.32.11 kernel with 2.5.3 on my hardy
> > >>> system
> > >>> and all went fine. But the problem is it just doesn't run on the
> > >>> lucid distro.
> > >>
> > >> This, I do not understand, the kernel does not need any support from the
> > >> distribution for booting, how can the same kernel boot with one
> > >> distribution, and not with the other? When you say the "same kernel", do
> > >> you mean the exact same zImage or bzImage, or do you mean the kernel
> > >> with the same configuration, but with a different compiler, or only the
> > >> version is identical?
> > >>
> > >
> > > It is a complete mystery to me either. I compiled my kernel into a deb
> > > package
> > > and installed the very same deb package on three machines:
> > > MSI p45 neo3 with Hardy on it -> works OK
> > > MSI p45 neo3 with Ludid on it -> nothing (works fine with regular kernel)
> > > MSI 945P with Lucid on it: -> nothing (works fine with regular kernel)
> > >
> > > I'll try the suggestions posted and keep you informed.
> >
> > OK. Connected a terminal to catch early kernel messages. Still no output
> > unfortunately (with the regular kernel I do get output on the terminal,
> > so the connection works).
> >
> > Meanwhile also built and tested kernel 2.6.32.15 + xenomai 2.5.4. Still nothing.
> > I'm clueless. I'm running Xenomai for years on dozens of systems and I've
> > never run into problems like this. I think I'll have to sit down and take a
> > close look at what I'm doing. I've always built my kernels using make-kpkg,
> > maybe that somehow introduces a problem here. I'll try without it.
> >
> > (unfortunately/luckily I have to work from home for a few days so I can't
> > get to the test system until later this week)
>
> I failed to reproduce the issue yet, but it very much looks like an
> I-pipe bug. Could you try the following config variants when time
> allows:
>
> - on 2.6.32.11 or .15, disable CONFIG_SMP, enable CONFIG_X86_UP_APIC
> only (*).
> - on 2.6.32.11 or .15, disable CONFIG_SMP, enable CONFIG_X86_UP_APIC and
> CONFIG_X86_UP_IOAPIC (*).
> - on 2.6.32.7, use your normal CONFIG_SMP config, with this patch in:
> http://download.gna.org/adeos/patches/v2.6/x86/older/adeos-ipipe-2.6.32.7-x86-2.5-01.patch
>
> (*) you need to switch off CONFIG_SMP first, to see those knobs appear
> in the "processor type and features" menu.
I forgot another important switch: make sure to disable CONFIG_XENOMAI
completely in your kernel config, only keeping CONFIG_IPIPE, or at least
to compile out all skins. When the first skin is started, our real-time
timer starts ticking, and we don't want the relevant code in the way
while chasing the original issue.
>
> The fact that you did see the panic blinking signal at least once tends
> to point the finger at some access fault the kernel tries to recover
> without success, rather than a sudden freeze. It must happen early
> enough during the boot process, for the console not to be available yet
> for reporting what the kernel whines about.
>
> We don't know yet if that bug is either the consequence of some
> interrupt delivery, and/or induced by code only involved in SMP. Those
> test configs may help in discovering this.
>
> TIA,
>
--
Philippe.
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Xenomai-help] kernel 2.6.32.11 with xenomai 2.5.3 fails to boot on ubuntu lucid system
2010-08-17 10:27 ` Philippe Gerum
2010-08-17 13:51 ` Hemal C.Bavishi
2010-08-17 17:01 ` [Xenomai-help] kernel 2.6.32.11 with xenomai 2.5.3 fails to boot on ubuntu lucid system Philippe Gerum
@ 2010-08-17 17:43 ` Stefan Kisdaroczi
2010-08-17 18:06 ` Jan Kiszka
2010-08-18 8:27 ` Philippe Gerum
2010-08-20 12:31 ` Theo Veenker
3 siblings, 2 replies; 54+ messages in thread
From: Stefan Kisdaroczi @ 2010-08-17 17:43 UTC (permalink / raw)
To: xenomai
[-- Attachment #1: Type: text/plain, Size: 3834 bytes --]
On 17.08.2010 12:27, Philippe Gerum wrote:
> On Mon, 2010-08-16 at 21:14 +0200, Theo Veenker wrote:
>
>> On 08/16/2010 04:26 PM, Theo Veenker wrote:
>>
>>> Gilles Chanteperdrix wrote:
>>>
>>>> Theo Veenker wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I want to upgrade all our PC's from Ubuntu hardy to lucid and in the
>>>>> process
>>>>> I'm also going from kernel 2.6.29.5 with Xenomai 2.4.8 to kernel
>>>>> 2.6.32.11
>>>>> with Xenomai 2.5.3.
>>>>>
>>>>> I first built and tested the 2.6.32.11 kernel with 2.5.3 on my hardy
>>>>> system
>>>>> and all went fine. But the problem is it just doesn't run on the
>>>>> lucid distro.
>>>>>
>>>> This, I do not understand, the kernel does not need any support from the
>>>> distribution for booting, how can the same kernel boot with one
>>>> distribution, and not with the other? When you say the "same kernel", do
>>>> you mean the exact same zImage or bzImage, or do you mean the kernel
>>>> with the same configuration, but with a different compiler, or only the
>>>> version is identical?
>>>>
>>>>
>>> It is a complete mystery to me either. I compiled my kernel into a deb
>>> package
>>> and installed the very same deb package on three machines:
>>> MSI p45 neo3 with Hardy on it -> works OK
>>> MSI p45 neo3 with Ludid on it -> nothing (works fine with regular kernel)
>>> MSI 945P with Lucid on it: -> nothing (works fine with regular kernel)
>>>
>>> I'll try the suggestions posted and keep you informed.
>>>
>> OK. Connected a terminal to catch early kernel messages. Still no output
>> unfortunately (with the regular kernel I do get output on the terminal,
>> so the connection works).
>>
>> Meanwhile also built and tested kernel 2.6.32.15 + xenomai 2.5.4. Still nothing.
>> I'm clueless. I'm running Xenomai for years on dozens of systems and I've
>> never run into problems like this. I think I'll have to sit down and take a
>> close look at what I'm doing. I've always built my kernels using make-kpkg,
>> maybe that somehow introduces a problem here. I'll try without it.
>>
>> (unfortunately/luckily I have to work from home for a few days so I can't
>> get to the test system until later this week)
>>
> I failed to reproduce the issue yet, but it very much looks like an
> I-pipe bug. Could you try the following config variants when time
> allows:
>
I installed the kernel (2.6.32.15 2.5.4 x86 32bit) which is working on
my laptop in a kvm machine.
In the virtual machine the kernel never starts and hangs.
I attached gdb to kvm and according to the cpu registers and system.map
it hangs in 'doublefault_fn'. As I'm not really familiar with gdb i'm
thankful if someone has a hint how to proceed. Thanks
Stefan
> - on 2.6.32.11 or .15, disable CONFIG_SMP, enable CONFIG_X86_UP_APIC
> only (*).
> - on 2.6.32.11 or .15, disable CONFIG_SMP, enable CONFIG_X86_UP_APIC and
> CONFIG_X86_UP_IOAPIC (*).
> - on 2.6.32.7, use your normal CONFIG_SMP config, with this patch in:
> http://download.gna.org/adeos/patches/v2.6/x86/older/adeos-ipipe-2.6.32.7-x86-2.5-01.patch
>
> (*) you need to switch off CONFIG_SMP first, to see those knobs appear
> in the "processor type and features" menu.
>
> The fact that you did see the panic blinking signal at least once tends
> to point the finger at some access fault the kernel tries to recover
> without success, rather than a sudden freeze. It must happen early
> enough during the boot process, for the console not to be available yet
> for reporting what the kernel whines about.
>
> We don't know yet if that bug is either the consequence of some
> interrupt delivery, and/or induced by code only involved in SMP. Those
> test configs may help in discovering this.
>
> TIA,
>
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Xenomai-help] kernel 2.6.32.11 with xenomai 2.5.3 fails to boot on ubuntu lucid system
2010-08-17 17:43 ` Stefan Kisdaroczi
@ 2010-08-17 18:06 ` Jan Kiszka
2010-08-18 12:38 ` Stefan Kisdaroczi
2010-08-18 8:27 ` Philippe Gerum
1 sibling, 1 reply; 54+ messages in thread
From: Jan Kiszka @ 2010-08-17 18:06 UTC (permalink / raw)
To: Stefan Kisdaroczi; +Cc: xenomai
Stefan Kisdaroczi wrote:
> I installed the kernel (2.6.32.15 2.5.4 x86 32bit) which is working on
> my laptop in a kvm machine.
> In the virtual machine the kernel never starts and hangs.
To make sure you are not facing a KVM issue (though they are much rarer
theses days - given you are using a recent KVM version...), please
cross-check if the guest behaves identically when booting without KVM
support (-no-kvm when using qemu-kvm).
> I attached gdb to kvm and according to the cpu registers and system.map
> it hangs in 'doublefault_fn'. As I'm not really familiar with gdb i'm
> thankful if someone has a hint how to proceed. Thanks
Build the kernel with CONFIG_DEBUG_INFO, start "gdb
/linux/src/path/vmlinux", then type "bt" at the gdb prompt when the
guest hangs. This should dump a symbolic backtrace - though likely not
beyond the exception entry. In that case, you could help us by examining
the origin of the exception (parameters to the exception handler, it
specifically receives a full register state).
Also note that there are graphical debuggers, e.g. ddd, that can help
working with gdb without knowing all its commands by heart.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Xenomai-help] kernel 2.6.32.11 with xenomai 2.5.3 fails to boot on ubuntu lucid system
2010-08-17 18:06 ` Jan Kiszka
@ 2010-08-18 12:38 ` Stefan Kisdaroczi
0 siblings, 0 replies; 54+ messages in thread
From: Stefan Kisdaroczi @ 2010-08-18 12:38 UTC (permalink / raw)
To: Jan Kiszka; +Cc: xenomai
[-- Attachment #1: Type: text/plain, Size: 1430 bytes --]
On 17.08.2010 20:06, Jan Kiszka wrote:
> Stefan Kisdaroczi wrote:
>
>> I installed the kernel (2.6.32.15 2.5.4 x86 32bit) which is working on
>> my laptop in a kvm machine.
>> In the virtual machine the kernel never starts and hangs.
>>
> To make sure you are not facing a KVM issue (though they are much rarer
> theses days - given you are using a recent KVM version...), please
> cross-check if the guest behaves identically when booting without KVM
> support (-no-kvm when using qemu-kvm).
>
Hi Jan,
thanks for the hints.
With versions 0.12.4 setting breakpoints with gdb didn't work, with
0.12.5 they work.
Stefan
>> I attached gdb to kvm and according to the cpu registers and system.map
>> it hangs in 'doublefault_fn'. As I'm not really familiar with gdb i'm
>> thankful if someone has a hint how to proceed. Thanks
>>
> Build the kernel with CONFIG_DEBUG_INFO, start "gdb
> /linux/src/path/vmlinux", then type "bt" at the gdb prompt when the
> guest hangs. This should dump a symbolic backtrace - though likely not
> beyond the exception entry. In that case, you could help us by examining
> the origin of the exception (parameters to the exception handler, it
> specifically receives a full register state).
>
> Also note that there are graphical debuggers, e.g. ddd, that can help
> working with gdb without knowing all its commands by heart.
>
> Jan
>
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Xenomai-help] kernel 2.6.32.11 with xenomai 2.5.3 fails to boot on ubuntu lucid system
2010-08-17 17:43 ` Stefan Kisdaroczi
2010-08-17 18:06 ` Jan Kiszka
@ 2010-08-18 8:27 ` Philippe Gerum
2010-08-18 12:11 ` Stefan Kisdaroczi
2010-08-18 23:21 ` Gilles Chanteperdrix
1 sibling, 2 replies; 54+ messages in thread
From: Philippe Gerum @ 2010-08-18 8:27 UTC (permalink / raw)
To: Stefan Kisdaroczi; +Cc: xenomai, Jan Kiszka
On Tue, 2010-08-17 at 19:43 +0200, Stefan Kisdaroczi wrote:
> On 17.08.2010 12:27, Philippe Gerum wrote:
> > On Mon, 2010-08-16 at 21:14 +0200, Theo Veenker wrote:
> >
> >> On 08/16/2010 04:26 PM, Theo Veenker wrote:
> >>
> >>> Gilles Chanteperdrix wrote:
> >>>
> >>>> Theo Veenker wrote:
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> I want to upgrade all our PC's from Ubuntu hardy to lucid and in the
> >>>>> process
> >>>>> I'm also going from kernel 2.6.29.5 with Xenomai 2.4.8 to kernel
> >>>>> 2.6.32.11
> >>>>> with Xenomai 2.5.3.
> >>>>>
> >>>>> I first built and tested the 2.6.32.11 kernel with 2.5.3 on my hardy
> >>>>> system
> >>>>> and all went fine. But the problem is it just doesn't run on the
> >>>>> lucid distro.
> >>>>>
> >>>> This, I do not understand, the kernel does not need any support from the
> >>>> distribution for booting, how can the same kernel boot with one
> >>>> distribution, and not with the other? When you say the "same kernel", do
> >>>> you mean the exact same zImage or bzImage, or do you mean the kernel
> >>>> with the same configuration, but with a different compiler, or only the
> >>>> version is identical?
> >>>>
> >>>>
> >>> It is a complete mystery to me either. I compiled my kernel into a deb
> >>> package
> >>> and installed the very same deb package on three machines:
> >>> MSI p45 neo3 with Hardy on it -> works OK
> >>> MSI p45 neo3 with Ludid on it -> nothing (works fine with regular kernel)
> >>> MSI 945P with Lucid on it: -> nothing (works fine with regular kernel)
> >>>
> >>> I'll try the suggestions posted and keep you informed.
> >>>
> >> OK. Connected a terminal to catch early kernel messages. Still no output
> >> unfortunately (with the regular kernel I do get output on the terminal,
> >> so the connection works).
> >>
> >> Meanwhile also built and tested kernel 2.6.32.15 + xenomai 2.5.4. Still nothing.
> >> I'm clueless. I'm running Xenomai for years on dozens of systems and I've
> >> never run into problems like this. I think I'll have to sit down and take a
> >> close look at what I'm doing. I've always built my kernels using make-kpkg,
> >> maybe that somehow introduces a problem here. I'll try without it.
> >>
> >> (unfortunately/luckily I have to work from home for a few days so I can't
> >> get to the test system until later this week)
> >>
> > I failed to reproduce the issue yet, but it very much looks like an
> > I-pipe bug. Could you try the following config variants when time
> > allows:
> >
>
> I installed the kernel (2.6.32.15 2.5.4 x86 32bit) which is working on
> my laptop in a kvm machine.
> In the virtual machine the kernel never starts and hangs.
> I attached gdb to kvm and according to the cpu registers and system.map
> it hangs in 'doublefault_fn'. As I'm not really familiar with gdb i'm
> thankful if someone has a hint how to proceed. Thanks
If you could ask for a backtrace ("bt" command) in gdb once attached to
the hanged kernel, and post the output there, that would be great.
Meanwhile, I tried to reproduce the issue in kvm with no luck so far.
Aside of timing issues making the boot over kvm quite shaky and most of
the time impossible with the APIC enabled, using a legacy 8254 mode
boots but never hangs. Pure emulation with -no-kvm or enabling kvm on
the host does not make a difference. I've been trying with a 32bit guest
over a 64bit host, and both host and guest in 32bit mode to no avail so
far (QEMU PC emulator version 0.12.3 (qemu-kvm-0.12.3)).
I had a bit more luck on real hw though; a m65 Dell workstation (core2
duo) seems to be kind enough to break during early boot. The failure
ratio is variable, but 1 crash over 3-5 boots is common; sometimes it
even crashes several times in a row. The bad news is that no rs232 is
available from this machine, and the crash happens way to early to count
on any usb<->serial converter to get any debug output; so this is going
to take some time to nail down the bug on this hw. I don't expect
netconsole to help me in any way either, for the same reason. Here are
some more information I could get though:
- CONFIG_SMP, CONFIG_*_APIC/IO_APIC do not make any difference. I still
have a kernel crashing against the wall in plain, basic uniprocessor
mode (i.e. 8254 legacy IRQ and timing).
- The very same kernel image does not break when booted via tftp here.
It really seems to need a boot of the kernel image from the hard drive
to get the issue. However, having the rootfs over NFS or on the hdd does
not seem to make any difference. This could be the sign of a mishandled
early access fault, which would be confirmed by your trace showing that
the double fault handler is called.
- CONFIG_IPIPE introduces the issue alone; no need for CONFIG_XENOMAI.
Since you are lucky enough to reproduce the bug over kvm, could you
confirm my findings on your setup? i.e. that CONFIG_SMP, CONFIG_*APIC*
and CONFIG_XENOMAI are not involved in this?
PS: At this point, I think this bug only occurs in 32bit mode, but this
has to be verified.
TIA,
--
Philippe.
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: [Xenomai-help] kernel 2.6.32.11 with xenomai 2.5.3 fails to boot on ubuntu lucid system
2010-08-18 8:27 ` Philippe Gerum
@ 2010-08-18 12:11 ` Stefan Kisdaroczi
2010-08-18 13:54 ` Stefan Kisdaroczi
` (2 more replies)
2010-08-18 23:21 ` Gilles Chanteperdrix
1 sibling, 3 replies; 54+ messages in thread
From: Stefan Kisdaroczi @ 2010-08-18 12:11 UTC (permalink / raw)
To: Philippe Gerum; +Cc: xenomai
[-- Attachment #1: Type: text/plain, Size: 6542 bytes --]
On 18.08.2010 10:27, Philippe Gerum wrote:
> On Tue, 2010-08-17 at 19:43 +0200, Stefan Kisdaroczi wrote:
>
>> On 17.08.2010 12:27, Philippe Gerum wrote:
>>
>>> On Mon, 2010-08-16 at 21:14 +0200, Theo Veenker wrote:
>>>
>>>
>>>> On 08/16/2010 04:26 PM, Theo Veenker wrote:
>>>>
>>>>
>>>>> Gilles Chanteperdrix wrote:
>>>>>
>>>>>
>>>>>> Theo Veenker wrote:
>>>>>>
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I want to upgrade all our PC's from Ubuntu hardy to lucid and in the
>>>>>>> process
>>>>>>> I'm also going from kernel 2.6.29.5 with Xenomai 2.4.8 to kernel
>>>>>>> 2.6.32.11
>>>>>>> with Xenomai 2.5.3.
>>>>>>>
>>>>>>> I first built and tested the 2.6.32.11 kernel with 2.5.3 on my hardy
>>>>>>> system
>>>>>>> and all went fine. But the problem is it just doesn't run on the
>>>>>>> lucid distro.
>>>>>>>
>>>>>>>
>>>>>> This, I do not understand, the kernel does not need any support from the
>>>>>> distribution for booting, how can the same kernel boot with one
>>>>>> distribution, and not with the other? When you say the "same kernel", do
>>>>>> you mean the exact same zImage or bzImage, or do you mean the kernel
>>>>>> with the same configuration, but with a different compiler, or only the
>>>>>> version is identical?
>>>>>>
>>>>>>
>>>>>>
>>>>> It is a complete mystery to me either. I compiled my kernel into a deb
>>>>> package
>>>>> and installed the very same deb package on three machines:
>>>>> MSI p45 neo3 with Hardy on it -> works OK
>>>>> MSI p45 neo3 with Ludid on it -> nothing (works fine with regular kernel)
>>>>> MSI 945P with Lucid on it: -> nothing (works fine with regular kernel)
>>>>>
>>>>> I'll try the suggestions posted and keep you informed.
>>>>>
>>>>>
>>>> OK. Connected a terminal to catch early kernel messages. Still no output
>>>> unfortunately (with the regular kernel I do get output on the terminal,
>>>> so the connection works).
>>>>
>>>> Meanwhile also built and tested kernel 2.6.32.15 + xenomai 2.5.4. Still nothing.
>>>> I'm clueless. I'm running Xenomai for years on dozens of systems and I've
>>>> never run into problems like this. I think I'll have to sit down and take a
>>>> close look at what I'm doing. I've always built my kernels using make-kpkg,
>>>> maybe that somehow introduces a problem here. I'll try without it.
>>>>
>>>> (unfortunately/luckily I have to work from home for a few days so I can't
>>>> get to the test system until later this week)
>>>>
>>>>
>>> I failed to reproduce the issue yet, but it very much looks like an
>>> I-pipe bug. Could you try the following config variants when time
>>> allows:
>>>
>>>
>> I installed the kernel (2.6.32.15 2.5.4 x86 32bit) which is working on
>> my laptop in a kvm machine.
>> In the virtual machine the kernel never starts and hangs.
>> I attached gdb to kvm and according to the cpu registers and system.map
>> it hangs in 'doublefault_fn'. As I'm not really familiar with gdb i'm
>> thankful if someone has a hint how to proceed. Thanks
>>
> If you could ask for a backtrace ("bt" command) in gdb once attached to
> the hanged kernel, and post the output there, that would be great.
>
hi philippe, hope this helps:
(gdb) bt
#0 doublefault_fn () at arch/x86/kernel/doublefault_32.c:47
#1 0x00000000 in ?? ()
I set two breakpoints:
1) do_test_wp_bit()
2) zap_low_mappings()
The second breakpoint is never reached, the fault seems to happen in
do_test_wp_bit().
arch/x86/mm/init_32.c : mem_init() -> test_wp_bit() -> do_test_wp_bit()
Breakpoint 1, do_test_wp_bit () at arch/x86/mm/init_32.c:981
981 __asm__ __volatile__(
(gdb) info registers
eax 0xffdff000 -2101248
ecx 0x7fc 2044
edx 0x13e8025 20873253
ebx 0xff7fe000 -8396800
esp 0xc1345fc0 0xc1345fc0
ebp 0x3830 0x3830
esi 0x160 352
edi 0x48d 1165
eip 0xc101a308 0xc101a308 <do_test_wp_bit>
eflags 0x2 [ ]
cs 0x60 96
ss 0x68 104
ds 0x7b 123
es 0x7b 123
fs 0xd8 216
gs 0x0 0
> Meanwhile, I tried to reproduce the issue in kvm with no luck so far.
> Aside of timing issues making the boot over kvm quite shaky and most of
> the time impossible with the APIC enabled, using a legacy 8254 mode
> boots but never hangs. Pure emulation with -no-kvm or enabling kvm on
> the host does not make a difference. I've been trying with a 32bit guest
> over a 64bit host, and both host and guest in 32bit mode to no avail so
> far (QEMU PC emulator version 0.12.3 (qemu-kvm-0.12.3)).
>
> I had a bit more luck on real hw though; a m65 Dell workstation (core2
> duo) seems to be kind enough to break during early boot. The failure
> ratio is variable, but 1 crash over 3-5 boots is common; sometimes it
> even crashes several times in a row. The bad news is that no rs232 is
> available from this machine, and the crash happens way to early to count
> on any usb<->serial converter to get any debug output; so this is going
> to take some time to nail down the bug on this hw. I don't expect
> netconsole to help me in any way either, for the same reason. Here are
> some more information I could get though:
>
> - CONFIG_SMP, CONFIG_*_APIC/IO_APIC do not make any difference. I still
> have a kernel crashing against the wall in plain, basic uniprocessor
> mode (i.e. 8254 legacy IRQ and timing).
>
> - The very same kernel image does not break when booted via tftp here.
> It really seems to need a boot of the kernel image from the hard drive
> to get the issue. However, having the rootfs over NFS or on the hdd does
> not seem to make any difference. This could be the sign of a mishandled
> early access fault, which would be confirmed by your trace showing that
> the double fault handler is called.
>
> - CONFIG_IPIPE introduces the issue alone; no need for CONFIG_XENOMAI.
>
> Since you are lucky enough to reproduce the bug over kvm, could you
> confirm my findings on your setup? i.e. that CONFIG_SMP, CONFIG_*APIC*
> and CONFIG_XENOMAI are not involved in this?
>
> PS: At this point, I think this bug only occurs in 32bit mode, but this
> has to be verified.
>
> TIA,
>
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: [Xenomai-help] kernel 2.6.32.11 with xenomai 2.5.3 fails to boot on ubuntu lucid system
2010-08-18 12:11 ` Stefan Kisdaroczi
@ 2010-08-18 13:54 ` Stefan Kisdaroczi
2010-08-22 17:42 ` Philippe Gerum
2010-08-18 14:53 ` Philippe Gerum
2010-08-18 18:09 ` Philippe Gerum
2 siblings, 1 reply; 54+ messages in thread
From: Stefan Kisdaroczi @ 2010-08-18 13:54 UTC (permalink / raw)
To: xenomai
[-- Attachment #1: Type: text/plain, Size: 1019 bytes --]
On 18.08.2010 14:11, Stefan Kisdaroczi wrote:
> [...]
> hi philippe, hope this helps:
>
>
> (gdb) bt
> #0 doublefault_fn () at arch/x86/kernel/doublefault_32.c:47
> #1 0x00000000 in ?? ()
>
> I set two breakpoints:
> 1) do_test_wp_bit()
> 2) zap_low_mappings()
>
> The second breakpoint is never reached, the fault seems to happen in
> do_test_wp_bit().
> arch/x86/mm/init_32.c : mem_init() -> test_wp_bit() -> do_test_wp_bit()
>
If I got it right, do_test_wp_bit() should fault, and then
ipipe_handle_exception gets called.
At this point, ipipe_init_early() was called, but ipipe_init() not.
So, I currently guess the bug is somewhere in ipipe_handle_exception().
Looking at ipipe-2.6.git I see the following commits which could be related:
x86: Fix root domain state restoring on exception return, 22.01.2010,
Jan, a2bc69bd3bd2e6a8f39d8407c647d7dfd2821bc0
x86/ipipe: Fix up regs unconditionally on exceptions, 12.04.2010, Jan,
ed2e37c05c897a46ea895a0dfbf08086057e2bcf
Stefan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Xenomai-help] kernel 2.6.32.11 with xenomai 2.5.3 fails to boot on ubuntu lucid system
2010-08-18 13:54 ` Stefan Kisdaroczi
@ 2010-08-22 17:42 ` Philippe Gerum
2010-08-23 11:59 ` Stefan Kisdaroczi
0 siblings, 1 reply; 54+ messages in thread
From: Philippe Gerum @ 2010-08-22 17:42 UTC (permalink / raw)
To: Stefan Kisdaroczi; +Cc: xenomai
On Wed, 2010-08-18 at 15:54 +0200, Stefan Kisdaroczi wrote:
> On 18.08.2010 14:11, Stefan Kisdaroczi wrote:
> > [...]
> > hi philippe, hope this helps:
> >
> >
> > (gdb) bt
> > #0 doublefault_fn () at arch/x86/kernel/doublefault_32.c:47
> > #1 0x00000000 in ?? ()
> >
> > I set two breakpoints:
> > 1) do_test_wp_bit()
> > 2) zap_low_mappings()
> >
> > The second breakpoint is never reached, the fault seems to happen in
> > do_test_wp_bit().
> > arch/x86/mm/init_32.c : mem_init() -> test_wp_bit() -> do_test_wp_bit()
> >
>
> If I got it right, do_test_wp_bit() should fault, and then
> ipipe_handle_exception gets called.
> At this point, ipipe_init_early() was called, but ipipe_init() not.
> So, I currently guess the bug is somewhere in ipipe_handle_exception().
As mentioned below, you were right:
http://git.denx.de/?p=ipipe-2.6.git;a=commit;h=d7ed9ab34a265d6486504d20ee794548ce6011d3
Your assumption that the bootloader was involved in this bug was correct
as well. This is the reason why I could not reproduce the issue over
kvm, I was bypassing the installed bootloader, passing -kernel to qemu
to directly load an external image, so no IRQ pending on entry to the
kernel, ever...
Thanks for your help.
--
Philippe.
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Xenomai-help] kernel 2.6.32.11 with xenomai 2.5.3 fails to boot on ubuntu lucid system
2010-08-22 17:42 ` Philippe Gerum
@ 2010-08-23 11:59 ` Stefan Kisdaroczi
0 siblings, 0 replies; 54+ messages in thread
From: Stefan Kisdaroczi @ 2010-08-23 11:59 UTC (permalink / raw)
To: Philippe Gerum; +Cc: xenomai
[-- Attachment #1: Type: text/plain, Size: 1483 bytes --]
On 22.08.2010 19:42, Philippe Gerum wrote:
> On Wed, 2010-08-18 at 15:54 +0200, Stefan Kisdaroczi wrote:
>
>> On 18.08.2010 14:11, Stefan Kisdaroczi wrote:
>>
>>> [...]
>>> hi philippe, hope this helps:
>>>
>>>
>>> (gdb) bt
>>> #0 doublefault_fn () at arch/x86/kernel/doublefault_32.c:47
>>> #1 0x00000000 in ?? ()
>>>
>>> I set two breakpoints:
>>> 1) do_test_wp_bit()
>>> 2) zap_low_mappings()
>>>
>>> The second breakpoint is never reached, the fault seems to happen in
>>> do_test_wp_bit().
>>> arch/x86/mm/init_32.c : mem_init() -> test_wp_bit() -> do_test_wp_bit()
>>>
>>>
>> If I got it right, do_test_wp_bit() should fault, and then
>> ipipe_handle_exception gets called.
>> At this point, ipipe_init_early() was called, but ipipe_init() not.
>> So, I currently guess the bug is somewhere in ipipe_handle_exception().
>>
> As mentioned below, you were right:
> http://git.denx.de/?p=ipipe-2.6.git;a=commit;h=d7ed9ab34a265d6486504d20ee794548ce6011d3
>
> Your assumption that the bootloader was involved in this bug was correct
> as well. This is the reason why I could not reproduce the issue over
> kvm, I was bypassing the installed bootloader, passing -kernel to qemu
> to directly load an external image, so no IRQ pending on entry to the
> kernel, ever...
>
> Thanks for your help.
>
>
Tested with 2.6.32.20 and debian squeeze, boots fine, laptop and virtual
machine.
Thanks Philippe.
Stefan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Xenomai-help] kernel 2.6.32.11 with xenomai 2.5.3 fails to boot on ubuntu lucid system
2010-08-18 12:11 ` Stefan Kisdaroczi
2010-08-18 13:54 ` Stefan Kisdaroczi
@ 2010-08-18 14:53 ` Philippe Gerum
2010-08-18 18:09 ` Philippe Gerum
2 siblings, 0 replies; 54+ messages in thread
From: Philippe Gerum @ 2010-08-18 14:53 UTC (permalink / raw)
To: Stefan Kisdaroczi; +Cc: xenomai
On Wed, 2010-08-18 at 14:11 +0200, Stefan Kisdaroczi wrote:
> On 18.08.2010 10:27, Philippe Gerum wrote:
> > On Tue, 2010-08-17 at 19:43 +0200, Stefan Kisdaroczi wrote:
> >
> >> On 17.08.2010 12:27, Philippe Gerum wrote:
> >>
> >>> On Mon, 2010-08-16 at 21:14 +0200, Theo Veenker wrote:
> >>>
> >>>
> >>>> On 08/16/2010 04:26 PM, Theo Veenker wrote:
> >>>>
> >>>>
> >>>>> Gilles Chanteperdrix wrote:
> >>>>>
> >>>>>
> >>>>>> Theo Veenker wrote:
> >>>>>>
> >>>>>>
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> I want to upgrade all our PC's from Ubuntu hardy to lucid and in the
> >>>>>>> process
> >>>>>>> I'm also going from kernel 2.6.29.5 with Xenomai 2.4.8 to kernel
> >>>>>>> 2.6.32.11
> >>>>>>> with Xenomai 2.5.3.
> >>>>>>>
> >>>>>>> I first built and tested the 2.6.32.11 kernel with 2.5.3 on my hardy
> >>>>>>> system
> >>>>>>> and all went fine. But the problem is it just doesn't run on the
> >>>>>>> lucid distro.
> >>>>>>>
> >>>>>>>
> >>>>>> This, I do not understand, the kernel does not need any support from the
> >>>>>> distribution for booting, how can the same kernel boot with one
> >>>>>> distribution, and not with the other? When you say the "same kernel", do
> >>>>>> you mean the exact same zImage or bzImage, or do you mean the kernel
> >>>>>> with the same configuration, but with a different compiler, or only the
> >>>>>> version is identical?
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>> It is a complete mystery to me either. I compiled my kernel into a deb
> >>>>> package
> >>>>> and installed the very same deb package on three machines:
> >>>>> MSI p45 neo3 with Hardy on it -> works OK
> >>>>> MSI p45 neo3 with Ludid on it -> nothing (works fine with regular kernel)
> >>>>> MSI 945P with Lucid on it: -> nothing (works fine with regular kernel)
> >>>>>
> >>>>> I'll try the suggestions posted and keep you informed.
> >>>>>
> >>>>>
> >>>> OK. Connected a terminal to catch early kernel messages. Still no output
> >>>> unfortunately (with the regular kernel I do get output on the terminal,
> >>>> so the connection works).
> >>>>
> >>>> Meanwhile also built and tested kernel 2.6.32.15 + xenomai 2.5.4. Still nothing.
> >>>> I'm clueless. I'm running Xenomai for years on dozens of systems and I've
> >>>> never run into problems like this. I think I'll have to sit down and take a
> >>>> close look at what I'm doing. I've always built my kernels using make-kpkg,
> >>>> maybe that somehow introduces a problem here. I'll try without it.
> >>>>
> >>>> (unfortunately/luckily I have to work from home for a few days so I can't
> >>>> get to the test system until later this week)
> >>>>
> >>>>
> >>> I failed to reproduce the issue yet, but it very much looks like an
> >>> I-pipe bug. Could you try the following config variants when time
> >>> allows:
> >>>
> >>>
> >> I installed the kernel (2.6.32.15 2.5.4 x86 32bit) which is working on
> >> my laptop in a kvm machine.
> >> In the virtual machine the kernel never starts and hangs.
> >> I attached gdb to kvm and according to the cpu registers and system.map
> >> it hangs in 'doublefault_fn'. As I'm not really familiar with gdb i'm
> >> thankful if someone has a hint how to proceed. Thanks
> >>
> > If you could ask for a backtrace ("bt" command) in gdb once attached to
> > the hanged kernel, and post the output there, that would be great.
> >
>
> hi philippe, hope this helps:
Yes, it does a lot. Actually, I thought I fixed it months ago:
http://git.denx.de/?p=ipipe-2.6.git;a=commit;h=a250e984a76fd327a0d8cfada5290b27e99f1e4d
As a matter of fact, I did not. Oh well, ...
>
> (gdb) bt
> #0 doublefault_fn () at arch/x86/kernel/doublefault_32.c:47
> #1 0x00000000 in ?? ()
>
> I set two breakpoints:
> 1) do_test_wp_bit()
> 2) zap_low_mappings()
>
> The second breakpoint is never reached, the fault seems to happen in
> do_test_wp_bit().
> arch/x86/mm/init_32.c : mem_init() -> test_wp_bit() -> do_test_wp_bit()
>
> Breakpoint 1, do_test_wp_bit () at arch/x86/mm/init_32.c:981
> 981 __asm__ __volatile__(
> (gdb) info registers
> eax 0xffdff000 -2101248
> ecx 0x7fc 2044
> edx 0x13e8025 20873253
> ebx 0xff7fe000 -8396800
> esp 0xc1345fc0 0xc1345fc0
> ebp 0x3830 0x3830
> esi 0x160 352
> edi 0x48d 1165
> eip 0xc101a308 0xc101a308 <do_test_wp_bit>
> eflags 0x2 [ ]
> cs 0x60 96
> ss 0x68 104
> ds 0x7b 123
> es 0x7b 123
> fs 0xd8 216
> gs 0x0 0
>
> > Meanwhile, I tried to reproduce the issue in kvm with no luck so far.
> > Aside of timing issues making the boot over kvm quite shaky and most of
> > the time impossible with the APIC enabled, using a legacy 8254 mode
> > boots but never hangs. Pure emulation with -no-kvm or enabling kvm on
> > the host does not make a difference. I've been trying with a 32bit guest
> > over a 64bit host, and both host and guest in 32bit mode to no avail so
> > far (QEMU PC emulator version 0.12.3 (qemu-kvm-0.12.3)).
> >
> > I had a bit more luck on real hw though; a m65 Dell workstation (core2
> > duo) seems to be kind enough to break during early boot. The failure
> > ratio is variable, but 1 crash over 3-5 boots is common; sometimes it
> > even crashes several times in a row. The bad news is that no rs232 is
> > available from this machine, and the crash happens way to early to count
> > on any usb<->serial converter to get any debug output; so this is going
> > to take some time to nail down the bug on this hw. I don't expect
> > netconsole to help me in any way either, for the same reason. Here are
> > some more information I could get though:
> >
> > - CONFIG_SMP, CONFIG_*_APIC/IO_APIC do not make any difference. I still
> > have a kernel crashing against the wall in plain, basic uniprocessor
> > mode (i.e. 8254 legacy IRQ and timing).
> >
> > - The very same kernel image does not break when booted via tftp here.
> > It really seems to need a boot of the kernel image from the hard drive
> > to get the issue. However, having the rootfs over NFS or on the hdd does
> > not seem to make any difference. This could be the sign of a mishandled
> > early access fault, which would be confirmed by your trace showing that
> > the double fault handler is called.
> >
> > - CONFIG_IPIPE introduces the issue alone; no need for CONFIG_XENOMAI.
> >
> > Since you are lucky enough to reproduce the bug over kvm, could you
> > confirm my findings on your setup? i.e. that CONFIG_SMP, CONFIG_*APIC*
> > and CONFIG_XENOMAI are not involved in this?
> >
> > PS: At this point, I think this bug only occurs in 32bit mode, but this
> > has to be verified.
> >
> > TIA,
> >
> >
>
>
--
Philippe.
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: [Xenomai-help] kernel 2.6.32.11 with xenomai 2.5.3 fails to boot on ubuntu lucid system
2010-08-18 12:11 ` Stefan Kisdaroczi
2010-08-18 13:54 ` Stefan Kisdaroczi
2010-08-18 14:53 ` Philippe Gerum
@ 2010-08-18 18:09 ` Philippe Gerum
2 siblings, 0 replies; 54+ messages in thread
From: Philippe Gerum @ 2010-08-18 18:09 UTC (permalink / raw)
To: Stefan Kisdaroczi; +Cc: xenomai
On Wed, 2010-08-18 at 14:11 +0200, Stefan Kisdaroczi wrote:
> On 18.08.2010 10:27, Philippe Gerum wrote:
> > On Tue, 2010-08-17 at 19:43 +0200, Stefan Kisdaroczi wrote:
> >
> >> On 17.08.2010 12:27, Philippe Gerum wrote:
> >>
> >>> On Mon, 2010-08-16 at 21:14 +0200, Theo Veenker wrote:
> >>>
> >>>
> >>>> On 08/16/2010 04:26 PM, Theo Veenker wrote:
> >>>>
> >>>>
> >>>>> Gilles Chanteperdrix wrote:
> >>>>>
> >>>>>
> >>>>>> Theo Veenker wrote:
> >>>>>>
> >>>>>>
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> I want to upgrade all our PC's from Ubuntu hardy to lucid and in the
> >>>>>>> process
> >>>>>>> I'm also going from kernel 2.6.29.5 with Xenomai 2.4.8 to kernel
> >>>>>>> 2.6.32.11
> >>>>>>> with Xenomai 2.5.3.
> >>>>>>>
> >>>>>>> I first built and tested the 2.6.32.11 kernel with 2.5.3 on my hardy
> >>>>>>> system
> >>>>>>> and all went fine. But the problem is it just doesn't run on the
> >>>>>>> lucid distro.
> >>>>>>>
> >>>>>>>
> >>>>>> This, I do not understand, the kernel does not need any support from the
> >>>>>> distribution for booting, how can the same kernel boot with one
> >>>>>> distribution, and not with the other? When you say the "same kernel", do
> >>>>>> you mean the exact same zImage or bzImage, or do you mean the kernel
> >>>>>> with the same configuration, but with a different compiler, or only the
> >>>>>> version is identical?
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>> It is a complete mystery to me either. I compiled my kernel into a deb
> >>>>> package
> >>>>> and installed the very same deb package on three machines:
> >>>>> MSI p45 neo3 with Hardy on it -> works OK
> >>>>> MSI p45 neo3 with Ludid on it -> nothing (works fine with regular kernel)
> >>>>> MSI 945P with Lucid on it: -> nothing (works fine with regular kernel)
> >>>>>
> >>>>> I'll try the suggestions posted and keep you informed.
> >>>>>
> >>>>>
> >>>> OK. Connected a terminal to catch early kernel messages. Still no output
> >>>> unfortunately (with the regular kernel I do get output on the terminal,
> >>>> so the connection works).
> >>>>
> >>>> Meanwhile also built and tested kernel 2.6.32.15 + xenomai 2.5.4. Still nothing.
> >>>> I'm clueless. I'm running Xenomai for years on dozens of systems and I've
> >>>> never run into problems like this. I think I'll have to sit down and take a
> >>>> close look at what I'm doing. I've always built my kernels using make-kpkg,
> >>>> maybe that somehow introduces a problem here. I'll try without it.
> >>>>
> >>>> (unfortunately/luckily I have to work from home for a few days so I can't
> >>>> get to the test system until later this week)
> >>>>
> >>>>
> >>> I failed to reproduce the issue yet, but it very much looks like an
> >>> I-pipe bug. Could you try the following config variants when time
> >>> allows:
> >>>
> >>>
> >> I installed the kernel (2.6.32.15 2.5.4 x86 32bit) which is working on
> >> my laptop in a kvm machine.
> >> In the virtual machine the kernel never starts and hangs.
> >> I attached gdb to kvm and according to the cpu registers and system.map
> >> it hangs in 'doublefault_fn'. As I'm not really familiar with gdb i'm
> >> thankful if someone has a hint how to proceed. Thanks
> >>
> > If you could ask for a backtrace ("bt" command) in gdb once attached to
> > the hanged kernel, and post the output there, that would be great.
> >
>
> hi philippe, hope this helps:
>
> (gdb) bt
> #0 doublefault_fn () at arch/x86/kernel/doublefault_32.c:47
> #1 0x00000000 in ?? ()
>
> I set two breakpoints:
> 1) do_test_wp_bit()
> 2) zap_low_mappings()
>
> The second breakpoint is never reached, the fault seems to happen in
> do_test_wp_bit().
> arch/x86/mm/init_32.c : mem_init() -> test_wp_bit() -> do_test_wp_bit()
>
> Breakpoint 1, do_test_wp_bit () at arch/x86/mm/init_32.c:981
> 981 __asm__ __volatile__(
> (gdb) info registers
> eax 0xffdff000 -2101248
> ecx 0x7fc 2044
> edx 0x13e8025 20873253
> ebx 0xff7fe000 -8396800
> esp 0xc1345fc0 0xc1345fc0
> ebp 0x3830 0x3830
> esi 0x160 352
> edi 0x48d 1165
> eip 0xc101a308 0xc101a308 <do_test_wp_bit>
> eflags 0x2 [ ]
> cs 0x60 96
> ss 0x68 104
> ds 0x7b 123
> es 0x7b 123
> fs 0xd8 216
> gs 0x0 0
>
I confirm that disabling the WP test does work around the issue for me
on real hw as well. So, either something is re-enabling interrupts over
the fault handler, which would be weird in this context since the kernel
did not install its own IRQ handlers yet, or something is accessing
uninit pipeline stuff over the fault handling path like you mentioned.
--
Philippe.
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Xenomai-help] kernel 2.6.32.11 with xenomai 2.5.3 fails to boot on ubuntu lucid system
2010-08-18 8:27 ` Philippe Gerum
2010-08-18 12:11 ` Stefan Kisdaroczi
@ 2010-08-18 23:21 ` Gilles Chanteperdrix
2010-08-18 23:25 ` Gilles Chanteperdrix
2010-08-19 5:18 ` Philippe Gerum
1 sibling, 2 replies; 54+ messages in thread
From: Gilles Chanteperdrix @ 2010-08-18 23:21 UTC (permalink / raw)
To: Philippe Gerum; +Cc: xenomai, Jan Kiszka
Philippe Gerum wrote:
> - The very same kernel image does not break when booted via tftp here.
> It really seems to need a boot of the kernel image from the hard drive
> to get the issue. However, having the rootfs over NFS or on the hdd does
> not seem to make any difference. This could be the sign of a mishandled
> early access fault, which would be confirmed by your trace showing that
> the double fault handler is called.
Probably the sign that how the NIC is configured causes the interrupt or
not when re-enabling hardware interrupt: when network booting, the
bootloader or BIOS PXE loader leaves the NIC correctly disabled so that
no interupt can be generated.
--
Gilles.
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Xenomai-help] kernel 2.6.32.11 with xenomai 2.5.3 fails to boot on ubuntu lucid system
2010-08-18 23:21 ` Gilles Chanteperdrix
@ 2010-08-18 23:25 ` Gilles Chanteperdrix
2010-08-19 5:18 ` Philippe Gerum
1 sibling, 0 replies; 54+ messages in thread
From: Gilles Chanteperdrix @ 2010-08-18 23:25 UTC (permalink / raw)
To: Philippe Gerum; +Cc: xenomai, Jan Kiszka
Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
>> - The very same kernel image does not break when booted via tftp here.
>> It really seems to need a boot of the kernel image from the hard drive
>> to get the issue. However, having the rootfs over NFS or on the hdd does
>> not seem to make any difference. This could be the sign of a mishandled
>> early access fault, which would be confirmed by your trace showing that
>> the double fault handler is called.
>
> Probably the sign that how the NIC is configured causes the interrupt or
> not when re-enabling hardware interrupt: when network booting, the
> bootloader or BIOS PXE loader leaves the NIC correctly disabled so that
> no interupt can be generated.
The point being that to cause the bug reliably on KVM, you can try and
put early in the kernel boot some hardware initialization code which
causes a NIC interrupt or any other interrupt to be generated.
--
Gilles.
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Xenomai-help] kernel 2.6.32.11 with xenomai 2.5.3 fails to boot on ubuntu lucid system
2010-08-18 23:21 ` Gilles Chanteperdrix
2010-08-18 23:25 ` Gilles Chanteperdrix
@ 2010-08-19 5:18 ` Philippe Gerum
1 sibling, 0 replies; 54+ messages in thread
From: Philippe Gerum @ 2010-08-19 5:18 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai, Jan Kiszka
On Thu, 2010-08-19 at 01:21 +0200, Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
> > - The very same kernel image does not break when booted via tftp here.
> > It really seems to need a boot of the kernel image from the hard drive
> > to get the issue. However, having the rootfs over NFS or on the hdd does
> > not seem to make any difference. This could be the sign of a mishandled
> > early access fault, which would be confirmed by your trace showing that
> > the double fault handler is called.
>
> Probably the sign that how the NIC is configured causes the interrupt or
> not when re-enabling hardware interrupt: when network booting, the
> bootloader or BIOS PXE loader leaves the NIC correctly disabled so that
> no interupt can be generated.
>
Actually, the issue is that some device is raising an IRQ before the
kernel enters mem_init and raises a fault to test the write protect
feature. At this point, the kernel did disable interrupts at CPU level
(we do have an early local_irq_disable_hw() hanging around in
start_kernel() to ensure that anyway). However, it might happen that the
fault virtualization code introduced by the pipeline spuriously
re-enables them, causing havoc.
At this stage of the init process (i.e. when checking whether the CPU
honors the wp bit), we just can't take any interrupt yet, since the
pipeline did not fully initialize, and the kernel did not even install
its own handlers or configured the PIC.
--
Philippe.
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Xenomai-help] kernel 2.6.32.11 with xenomai 2.5.3 fails to boot on ubuntu lucid system
2010-08-17 10:27 ` Philippe Gerum
` (2 preceding siblings ...)
2010-08-17 17:43 ` Stefan Kisdaroczi
@ 2010-08-20 12:31 ` Theo Veenker
2010-08-20 12:34 ` Gilles Chanteperdrix
` (2 more replies)
3 siblings, 3 replies; 54+ messages in thread
From: Theo Veenker @ 2010-08-20 12:31 UTC (permalink / raw)
To: Philippe Gerum; +Cc: Xenomai help
Philippe Gerum wrote:
> On Mon, 2010-08-16 at 21:14 +0200, Theo Veenker wrote:
>> On 08/16/2010 04:26 PM, Theo Veenker wrote:
>>> Gilles Chanteperdrix wrote:
>>>> Theo Veenker wrote:
>>>>> Hi,
>>>>>
>>>>> I want to upgrade all our PC's from Ubuntu hardy to lucid and in the
>>>>> process
>>>>> I'm also going from kernel 2.6.29.5 with Xenomai 2.4.8 to kernel
>>>>> 2.6.32.11
>>>>> with Xenomai 2.5.3.
>>>>>
>>>>> I first built and tested the 2.6.32.11 kernel with 2.5.3 on my hardy
>>>>> system
>>>>> and all went fine. But the problem is it just doesn't run on the
>>>>> lucid distro.
>>>> This, I do not understand, the kernel does not need any support from the
>>>> distribution for booting, how can the same kernel boot with one
>>>> distribution, and not with the other? When you say the "same kernel", do
>>>> you mean the exact same zImage or bzImage, or do you mean the kernel
>>>> with the same configuration, but with a different compiler, or only the
>>>> version is identical?
>>>>
>>> It is a complete mystery to me either. I compiled my kernel into a deb
>>> package
>>> and installed the very same deb package on three machines:
>>> MSI p45 neo3 with Hardy on it -> works OK
>>> MSI p45 neo3 with Ludid on it -> nothing (works fine with regular kernel)
>>> MSI 945P with Lucid on it: -> nothing (works fine with regular kernel)
>>>
>>> I'll try the suggestions posted and keep you informed.
>> OK. Connected a terminal to catch early kernel messages. Still no output
>> unfortunately (with the regular kernel I do get output on the terminal,
>> so the connection works).
>>
>> Meanwhile also built and tested kernel 2.6.32.15 + xenomai 2.5.4. Still nothing.
>> I'm clueless. I'm running Xenomai for years on dozens of systems and I've
>> never run into problems like this. I think I'll have to sit down and take a
>> close look at what I'm doing. I've always built my kernels using make-kpkg,
>> maybe that somehow introduces a problem here. I'll try without it.
>>
>> (unfortunately/luckily I have to work from home for a few days so I can't
>> get to the test system until later this week)
>
> I failed to reproduce the issue yet, but it very much looks like an
> I-pipe bug. Could you try the following config variants when time
> allows:
>
> - on 2.6.32.11 or .15, disable CONFIG_SMP, enable CONFIG_X86_UP_APIC
> only (*).
> - on 2.6.32.11 or .15, disable CONFIG_SMP, enable CONFIG_X86_UP_APIC and
> CONFIG_X86_UP_IOAPIC (*).
> - on 2.6.32.7, use your normal CONFIG_SMP config, with this patch in:
> http://download.gna.org/adeos/patches/v2.6/x86/older/adeos-ipipe-2.6.32.7-x86-2.5-01.patch
>
> (*) you need to switch off CONFIG_SMP first, to see those knobs appear
> in the "processor type and features" menu.
>
> The fact that you did see the panic blinking signal at least once tends
> to point the finger at some access fault the kernel tries to recover
> without success, rather than a sudden freeze. It must happen early
> enough during the boot process, for the console not to be available yet
> for reporting what the kernel whines about.
>
> We don't know yet if that bug is either the consequence of some
> interrupt delivery, and/or induced by code only involved in SMP. Those
> test configs may help in discovering this.
>
> TIA,
>
Here are my results. I've built 5 kernels:
K1: 2.6.32.15 (without the adeos patch applied)
K2: 2.6.32.15 + 2.5.4
K3: 2.6.32.15 + 2.5.4 CONFIG_SMP off, CONFIG_X86_UP_API on, CONFIG_XENOMAI off, CONFIG_IPIPE on
K4: 2.6.32.15 + 2.5.4 as (3) with CONFIG_X86_UP_IOAPIC on
K5: 2.6.32.7 with adeos-ipipe-2.6.32.7-x86-2.5-01.patch
I now tested these kernels on four systems:
A1: MSI 945P with Ubuntu 8.04
A2: MSI 945P with Ubuntu 10.04
B1: MSI p45 neo3 with Ubuntu 8.04
B2: MSI p45 neo3 with Ubuntu 10.04
A1 and A2 are identical systems from the same batch and B1 and B2 also.
What worked:
A1 A2 B1 B2
----------------------------------------------------------------
K1 Y Y Y Y
K2 Y N/Y Y N
K3 Y N/Y Y N
K4 Y N/Y Y N
K5 Y N/Y Y N
The No/Yes cases means on this system sometimes the kernel would boot
(same as others have reported before). In the No cases I got no ouput
on the attached console.
Stange as it may be I still do see a strong correlation between the OS
version and whether an adeos patched kernel works or not.
Regards,
Theo
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: [Xenomai-help] kernel 2.6.32.11 with xenomai 2.5.3 fails to boot on ubuntu lucid system
2010-08-20 12:31 ` Theo Veenker
@ 2010-08-20 12:34 ` Gilles Chanteperdrix
2010-08-20 13:34 ` Theo Veenker
2010-08-20 13:01 ` Philippe Gerum
2010-08-21 9:32 ` Daniele Nicolodi
2 siblings, 1 reply; 54+ messages in thread
From: Gilles Chanteperdrix @ 2010-08-20 12:34 UTC (permalink / raw)
To: Theo Veenker; +Cc: Xenomai help
Theo Veenker wrote:
> Philippe Gerum wrote:
>> On Mon, 2010-08-16 at 21:14 +0200, Theo Veenker wrote:
>>> On 08/16/2010 04:26 PM, Theo Veenker wrote:
>>>> Gilles Chanteperdrix wrote:
>>>>> Theo Veenker wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I want to upgrade all our PC's from Ubuntu hardy to lucid and in the
>>>>>> process
>>>>>> I'm also going from kernel 2.6.29.5 with Xenomai 2.4.8 to kernel
>>>>>> 2.6.32.11
>>>>>> with Xenomai 2.5.3.
>>>>>>
>>>>>> I first built and tested the 2.6.32.11 kernel with 2.5.3 on my hardy
>>>>>> system
>>>>>> and all went fine. But the problem is it just doesn't run on the
>>>>>> lucid distro.
>>>>> This, I do not understand, the kernel does not need any support from the
>>>>> distribution for booting, how can the same kernel boot with one
>>>>> distribution, and not with the other? When you say the "same kernel", do
>>>>> you mean the exact same zImage or bzImage, or do you mean the kernel
>>>>> with the same configuration, but with a different compiler, or only the
>>>>> version is identical?
>>>>>
>>>> It is a complete mystery to me either. I compiled my kernel into a deb
>>>> package
>>>> and installed the very same deb package on three machines:
>>>> MSI p45 neo3 with Hardy on it -> works OK
>>>> MSI p45 neo3 with Ludid on it -> nothing (works fine with regular kernel)
>>>> MSI 945P with Lucid on it: -> nothing (works fine with regular kernel)
>>>>
>>>> I'll try the suggestions posted and keep you informed.
>>> OK. Connected a terminal to catch early kernel messages. Still no output
>>> unfortunately (with the regular kernel I do get output on the terminal,
>>> so the connection works).
>>>
>>> Meanwhile also built and tested kernel 2.6.32.15 + xenomai 2.5.4. Still nothing.
>>> I'm clueless. I'm running Xenomai for years on dozens of systems and I've
>>> never run into problems like this. I think I'll have to sit down and take a
>>> close look at what I'm doing. I've always built my kernels using make-kpkg,
>>> maybe that somehow introduces a problem here. I'll try without it.
>>>
>>> (unfortunately/luckily I have to work from home for a few days so I can't
>>> get to the test system until later this week)
>> I failed to reproduce the issue yet, but it very much looks like an
>> I-pipe bug. Could you try the following config variants when time
>> allows:
>>
>> - on 2.6.32.11 or .15, disable CONFIG_SMP, enable CONFIG_X86_UP_APIC
>> only (*).
>> - on 2.6.32.11 or .15, disable CONFIG_SMP, enable CONFIG_X86_UP_APIC and
>> CONFIG_X86_UP_IOAPIC (*).
>> - on 2.6.32.7, use your normal CONFIG_SMP config, with this patch in:
>> http://download.gna.org/adeos/patches/v2.6/x86/older/adeos-ipipe-2.6.32.7-x86-2.5-01.patch
>>
>> (*) you need to switch off CONFIG_SMP first, to see those knobs appear
>> in the "processor type and features" menu.
>>
>> The fact that you did see the panic blinking signal at least once tends
>> to point the finger at some access fault the kernel tries to recover
>> without success, rather than a sudden freeze. It must happen early
>> enough during the boot process, for the console not to be available yet
>> for reporting what the kernel whines about.
>>
>> We don't know yet if that bug is either the consequence of some
>> interrupt delivery, and/or induced by code only involved in SMP. Those
>> test configs may help in discovering this.
>>
>> TIA,
>>
>
> Here are my results. I've built 5 kernels:
> K1: 2.6.32.15 (without the adeos patch applied)
> K2: 2.6.32.15 + 2.5.4
> K3: 2.6.32.15 + 2.5.4 CONFIG_SMP off, CONFIG_X86_UP_API on, CONFIG_XENOMAI off, CONFIG_IPIPE on
> K4: 2.6.32.15 + 2.5.4 as (3) with CONFIG_X86_UP_IOAPIC on
> K5: 2.6.32.7 with adeos-ipipe-2.6.32.7-x86-2.5-01.patch
>
> I now tested these kernels on four systems:
> A1: MSI 945P with Ubuntu 8.04
> A2: MSI 945P with Ubuntu 10.04
> B1: MSI p45 neo3 with Ubuntu 8.04
> B2: MSI p45 neo3 with Ubuntu 10.04
>
> A1 and A2 are identical systems from the same batch and B1 and B2 also.
>
> What worked:
> A1 A2 B1 B2
> ----------------------------------------------------------------
> K1 Y Y Y Y
> K2 Y N/Y Y N
> K3 Y N/Y Y N
> K4 Y N/Y Y N
> K5 Y N/Y Y N
What are the versions of grub you are using with A1, A2, B1, B2?
--
Gilles.
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Xenomai-help] kernel 2.6.32.11 with xenomai 2.5.3 fails to boot on ubuntu lucid system
2010-08-20 12:34 ` Gilles Chanteperdrix
@ 2010-08-20 13:34 ` Theo Veenker
0 siblings, 0 replies; 54+ messages in thread
From: Theo Veenker @ 2010-08-20 13:34 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: Xenomai help
Gilles Chanteperdrix wrote:
> Theo Veenker wrote:
>> Philippe Gerum wrote:
>>> On Mon, 2010-08-16 at 21:14 +0200, Theo Veenker wrote:
>>>> On 08/16/2010 04:26 PM, Theo Veenker wrote:
>>>>> Gilles Chanteperdrix wrote:
>>>>>> Theo Veenker wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I want to upgrade all our PC's from Ubuntu hardy to lucid and in the
>>>>>>> process
>>>>>>> I'm also going from kernel 2.6.29.5 with Xenomai 2.4.8 to kernel
>>>>>>> 2.6.32.11
>>>>>>> with Xenomai 2.5.3.
>>>>>>>
>>>>>>> I first built and tested the 2.6.32.11 kernel with 2.5.3 on my hardy
>>>>>>> system
>>>>>>> and all went fine. But the problem is it just doesn't run on the
>>>>>>> lucid distro.
>>>>>> This, I do not understand, the kernel does not need any support from the
>>>>>> distribution for booting, how can the same kernel boot with one
>>>>>> distribution, and not with the other? When you say the "same kernel", do
>>>>>> you mean the exact same zImage or bzImage, or do you mean the kernel
>>>>>> with the same configuration, but with a different compiler, or only the
>>>>>> version is identical?
>>>>>>
>>>>> It is a complete mystery to me either. I compiled my kernel into a deb
>>>>> package
>>>>> and installed the very same deb package on three machines:
>>>>> MSI p45 neo3 with Hardy on it -> works OK
>>>>> MSI p45 neo3 with Ludid on it -> nothing (works fine with regular kernel)
>>>>> MSI 945P with Lucid on it: -> nothing (works fine with regular kernel)
>>>>>
>>>>> I'll try the suggestions posted and keep you informed.
>>>> OK. Connected a terminal to catch early kernel messages. Still no output
>>>> unfortunately (with the regular kernel I do get output on the terminal,
>>>> so the connection works).
>>>>
>>>> Meanwhile also built and tested kernel 2.6.32.15 + xenomai 2.5.4. Still nothing.
>>>> I'm clueless. I'm running Xenomai for years on dozens of systems and I've
>>>> never run into problems like this. I think I'll have to sit down and take a
>>>> close look at what I'm doing. I've always built my kernels using make-kpkg,
>>>> maybe that somehow introduces a problem here. I'll try without it.
>>>>
>>>> (unfortunately/luckily I have to work from home for a few days so I can't
>>>> get to the test system until later this week)
>>> I failed to reproduce the issue yet, but it very much looks like an
>>> I-pipe bug. Could you try the following config variants when time
>>> allows:
>>>
>>> - on 2.6.32.11 or .15, disable CONFIG_SMP, enable CONFIG_X86_UP_APIC
>>> only (*).
>>> - on 2.6.32.11 or .15, disable CONFIG_SMP, enable CONFIG_X86_UP_APIC and
>>> CONFIG_X86_UP_IOAPIC (*).
>>> - on 2.6.32.7, use your normal CONFIG_SMP config, with this patch in:
>>> http://download.gna.org/adeos/patches/v2.6/x86/older/adeos-ipipe-2.6.32.7-x86-2.5-01.patch
>>>
>>> (*) you need to switch off CONFIG_SMP first, to see those knobs appear
>>> in the "processor type and features" menu.
>>>
>>> The fact that you did see the panic blinking signal at least once tends
>>> to point the finger at some access fault the kernel tries to recover
>>> without success, rather than a sudden freeze. It must happen early
>>> enough during the boot process, for the console not to be available yet
>>> for reporting what the kernel whines about.
>>>
>>> We don't know yet if that bug is either the consequence of some
>>> interrupt delivery, and/or induced by code only involved in SMP. Those
>>> test configs may help in discovering this.
>>>
>>> TIA,
>>>
>> Here are my results. I've built 5 kernels:
>> K1: 2.6.32.15 (without the adeos patch applied)
>> K2: 2.6.32.15 + 2.5.4
>> K3: 2.6.32.15 + 2.5.4 CONFIG_SMP off, CONFIG_X86_UP_API on, CONFIG_XENOMAI off, CONFIG_IPIPE on
>> K4: 2.6.32.15 + 2.5.4 as (3) with CONFIG_X86_UP_IOAPIC on
>> K5: 2.6.32.7 with adeos-ipipe-2.6.32.7-x86-2.5-01.patch
>>
>> I now tested these kernels on four systems:
>> A1: MSI 945P with Ubuntu 8.04
>> A2: MSI 945P with Ubuntu 10.04
>> B1: MSI p45 neo3 with Ubuntu 8.04
>> B2: MSI p45 neo3 with Ubuntu 10.04
>>
>> A1 and A2 are identical systems from the same batch and B1 and B2 also.
>>
>> What worked:
>> A1 A2 B1 B2
>> ----------------------------------------------------------------
>> K1 Y Y Y Y
>> K2 Y N/Y Y N
>> K3 Y N/Y Y N
>> K4 Y N/Y Y N
>> K5 Y N/Y Y N
>
> What are the versions of grub you are using with A1, A2, B1, B2?
>
This is 0.97 for A1 and B1 and 1.98 for A2 and B2.
Theo
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Xenomai-help] kernel 2.6.32.11 with xenomai 2.5.3 fails to boot on ubuntu lucid system
2010-08-20 12:31 ` Theo Veenker
2010-08-20 12:34 ` Gilles Chanteperdrix
@ 2010-08-20 13:01 ` Philippe Gerum
2010-08-22 17:36 ` Philippe Gerum
2010-08-21 9:32 ` Daniele Nicolodi
2 siblings, 1 reply; 54+ messages in thread
From: Philippe Gerum @ 2010-08-20 13:01 UTC (permalink / raw)
To: Theo Veenker; +Cc: Xenomai help
On Fri, 2010-08-20 at 14:31 +0200, Theo Veenker wrote:
> Philippe Gerum wrote:
> > On Mon, 2010-08-16 at 21:14 +0200, Theo Veenker wrote:
> >> On 08/16/2010 04:26 PM, Theo Veenker wrote:
> >>> Gilles Chanteperdrix wrote:
> >>>> Theo Veenker wrote:
> >>>>> Hi,
> >>>>>
> >>>>> I want to upgrade all our PC's from Ubuntu hardy to lucid and in the
> >>>>> process
> >>>>> I'm also going from kernel 2.6.29.5 with Xenomai 2.4.8 to kernel
> >>>>> 2.6.32.11
> >>>>> with Xenomai 2.5.3.
> >>>>>
> >>>>> I first built and tested the 2.6.32.11 kernel with 2.5.3 on my hardy
> >>>>> system
> >>>>> and all went fine. But the problem is it just doesn't run on the
> >>>>> lucid distro.
> >>>> This, I do not understand, the kernel does not need any support from the
> >>>> distribution for booting, how can the same kernel boot with one
> >>>> distribution, and not with the other? When you say the "same kernel", do
> >>>> you mean the exact same zImage or bzImage, or do you mean the kernel
> >>>> with the same configuration, but with a different compiler, or only the
> >>>> version is identical?
> >>>>
> >>> It is a complete mystery to me either. I compiled my kernel into a deb
> >>> package
> >>> and installed the very same deb package on three machines:
> >>> MSI p45 neo3 with Hardy on it -> works OK
> >>> MSI p45 neo3 with Ludid on it -> nothing (works fine with regular kernel)
> >>> MSI 945P with Lucid on it: -> nothing (works fine with regular kernel)
> >>>
> >>> I'll try the suggestions posted and keep you informed.
> >> OK. Connected a terminal to catch early kernel messages. Still no output
> >> unfortunately (with the regular kernel I do get output on the terminal,
> >> so the connection works).
> >>
> >> Meanwhile also built and tested kernel 2.6.32.15 + xenomai 2.5.4. Still nothing.
> >> I'm clueless. I'm running Xenomai for years on dozens of systems and I've
> >> never run into problems like this. I think I'll have to sit down and take a
> >> close look at what I'm doing. I've always built my kernels using make-kpkg,
> >> maybe that somehow introduces a problem here. I'll try without it.
> >>
> >> (unfortunately/luckily I have to work from home for a few days so I can't
> >> get to the test system until later this week)
> >
> > I failed to reproduce the issue yet, but it very much looks like an
> > I-pipe bug. Could you try the following config variants when time
> > allows:
> >
> > - on 2.6.32.11 or .15, disable CONFIG_SMP, enable CONFIG_X86_UP_APIC
> > only (*).
> > - on 2.6.32.11 or .15, disable CONFIG_SMP, enable CONFIG_X86_UP_APIC and
> > CONFIG_X86_UP_IOAPIC (*).
> > - on 2.6.32.7, use your normal CONFIG_SMP config, with this patch in:
> > http://download.gna.org/adeos/patches/v2.6/x86/older/adeos-ipipe-2.6.32.7-x86-2.5-01.patch
> >
> > (*) you need to switch off CONFIG_SMP first, to see those knobs appear
> > in the "processor type and features" menu.
> >
> > The fact that you did see the panic blinking signal at least once tends
> > to point the finger at some access fault the kernel tries to recover
> > without success, rather than a sudden freeze. It must happen early
> > enough during the boot process, for the console not to be available yet
> > for reporting what the kernel whines about.
> >
> > We don't know yet if that bug is either the consequence of some
> > interrupt delivery, and/or induced by code only involved in SMP. Those
> > test configs may help in discovering this.
> >
> > TIA,
> >
>
> Here are my results. I've built 5 kernels:
> K1: 2.6.32.15 (without the adeos patch applied)
> K2: 2.6.32.15 + 2.5.4
> K3: 2.6.32.15 + 2.5.4 CONFIG_SMP off, CONFIG_X86_UP_API on, CONFIG_XENOMAI off, CONFIG_IPIPE on
> K4: 2.6.32.15 + 2.5.4 as (3) with CONFIG_X86_UP_IOAPIC on
> K5: 2.6.32.7 with adeos-ipipe-2.6.32.7-x86-2.5-01.patch
>
> I now tested these kernels on four systems:
> A1: MSI 945P with Ubuntu 8.04
> A2: MSI 945P with Ubuntu 10.04
> B1: MSI p45 neo3 with Ubuntu 8.04
> B2: MSI p45 neo3 with Ubuntu 10.04
>
> A1 and A2 are identical systems from the same batch and B1 and B2 also.
>
> What worked:
> A1 A2 B1 B2
> ----------------------------------------------------------------
> K1 Y Y Y Y
> K2 Y N/Y Y N
> K3 Y N/Y Y N
> K4 Y N/Y Y N
> K5 Y N/Y Y N
>
> The No/Yes cases means on this system sometimes the kernel would boot
> (same as others have reported before). In the No cases I got no ouput
> on the attached console.
>
> Stange as it may be I still do see a strong correlation between the OS
> version and whether an adeos patched kernel works or not.
I should be able to confirm reasonably soon that the bug depends on
having an interrupt pending or not before the kernel entry point is
reached. This may depend on whether the bootloader clears the PIC and
when before jumping to the kernel start address. It will also depend on
the behavior of some device involved in the boot sequence, such as the
disk controller, for pending that IRQ or not.
If this assumption turns to be correct, please make sure to send me your
congrats for having authored the silly piece of code I have right in
front of me now, that randomly turns boot screens into black holes since
2003 or so.
>
> Regards,
> Theo
--
Philippe.
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Xenomai-help] kernel 2.6.32.11 with xenomai 2.5.3 fails to boot on ubuntu lucid system
2010-08-20 13:01 ` Philippe Gerum
@ 2010-08-22 17:36 ` Philippe Gerum
2010-08-23 7:15 ` Theo Veenker
0 siblings, 1 reply; 54+ messages in thread
From: Philippe Gerum @ 2010-08-22 17:36 UTC (permalink / raw)
To: Theo Veenker; +Cc: Xenomai help
On Fri, 2010-08-20 at 15:01 +0200, Philippe Gerum wrote:
> On Fri, 2010-08-20 at 14:31 +0200, Theo Veenker wrote:
> > Philippe Gerum wrote:
> > > On Mon, 2010-08-16 at 21:14 +0200, Theo Veenker wrote:
> > >> On 08/16/2010 04:26 PM, Theo Veenker wrote:
> > >>> Gilles Chanteperdrix wrote:
> > >>>> Theo Veenker wrote:
> > >>>>> Hi,
> > >>>>>
> > >>>>> I want to upgrade all our PC's from Ubuntu hardy to lucid and in the
> > >>>>> process
> > >>>>> I'm also going from kernel 2.6.29.5 with Xenomai 2.4.8 to kernel
> > >>>>> 2.6.32.11
> > >>>>> with Xenomai 2.5.3.
> > >>>>>
> > >>>>> I first built and tested the 2.6.32.11 kernel with 2.5.3 on my hardy
> > >>>>> system
> > >>>>> and all went fine. But the problem is it just doesn't run on the
> > >>>>> lucid distro.
> > >>>> This, I do not understand, the kernel does not need any support from the
> > >>>> distribution for booting, how can the same kernel boot with one
> > >>>> distribution, and not with the other? When you say the "same kernel", do
> > >>>> you mean the exact same zImage or bzImage, or do you mean the kernel
> > >>>> with the same configuration, but with a different compiler, or only the
> > >>>> version is identical?
> > >>>>
> > >>> It is a complete mystery to me either. I compiled my kernel into a deb
> > >>> package
> > >>> and installed the very same deb package on three machines:
> > >>> MSI p45 neo3 with Hardy on it -> works OK
> > >>> MSI p45 neo3 with Ludid on it -> nothing (works fine with regular kernel)
> > >>> MSI 945P with Lucid on it: -> nothing (works fine with regular kernel)
> > >>>
> > >>> I'll try the suggestions posted and keep you informed.
> > >> OK. Connected a terminal to catch early kernel messages. Still no output
> > >> unfortunately (with the regular kernel I do get output on the terminal,
> > >> so the connection works).
> > >>
> > >> Meanwhile also built and tested kernel 2.6.32.15 + xenomai 2.5.4. Still nothing.
> > >> I'm clueless. I'm running Xenomai for years on dozens of systems and I've
> > >> never run into problems like this. I think I'll have to sit down and take a
> > >> close look at what I'm doing. I've always built my kernels using make-kpkg,
> > >> maybe that somehow introduces a problem here. I'll try without it.
> > >>
> > >> (unfortunately/luckily I have to work from home for a few days so I can't
> > >> get to the test system until later this week)
> > >
> > > I failed to reproduce the issue yet, but it very much looks like an
> > > I-pipe bug. Could you try the following config variants when time
> > > allows:
> > >
> > > - on 2.6.32.11 or .15, disable CONFIG_SMP, enable CONFIG_X86_UP_APIC
> > > only (*).
> > > - on 2.6.32.11 or .15, disable CONFIG_SMP, enable CONFIG_X86_UP_APIC and
> > > CONFIG_X86_UP_IOAPIC (*).
> > > - on 2.6.32.7, use your normal CONFIG_SMP config, with this patch in:
> > > http://download.gna.org/adeos/patches/v2.6/x86/older/adeos-ipipe-2.6.32.7-x86-2.5-01.patch
> > >
> > > (*) you need to switch off CONFIG_SMP first, to see those knobs appear
> > > in the "processor type and features" menu.
> > >
> > > The fact that you did see the panic blinking signal at least once tends
> > > to point the finger at some access fault the kernel tries to recover
> > > without success, rather than a sudden freeze. It must happen early
> > > enough during the boot process, for the console not to be available yet
> > > for reporting what the kernel whines about.
> > >
> > > We don't know yet if that bug is either the consequence of some
> > > interrupt delivery, and/or induced by code only involved in SMP. Those
> > > test configs may help in discovering this.
> > >
> > > TIA,
> > >
> >
> > Here are my results. I've built 5 kernels:
> > K1: 2.6.32.15 (without the adeos patch applied)
> > K2: 2.6.32.15 + 2.5.4
> > K3: 2.6.32.15 + 2.5.4 CONFIG_SMP off, CONFIG_X86_UP_API on, CONFIG_XENOMAI off, CONFIG_IPIPE on
> > K4: 2.6.32.15 + 2.5.4 as (3) with CONFIG_X86_UP_IOAPIC on
> > K5: 2.6.32.7 with adeos-ipipe-2.6.32.7-x86-2.5-01.patch
> >
> > I now tested these kernels on four systems:
> > A1: MSI 945P with Ubuntu 8.04
> > A2: MSI 945P with Ubuntu 10.04
> > B1: MSI p45 neo3 with Ubuntu 8.04
> > B2: MSI p45 neo3 with Ubuntu 10.04
> >
> > A1 and A2 are identical systems from the same batch and B1 and B2 also.
> >
> > What worked:
> > A1 A2 B1 B2
> > ----------------------------------------------------------------
> > K1 Y Y Y Y
> > K2 Y N/Y Y N
> > K3 Y N/Y Y N
> > K4 Y N/Y Y N
> > K5 Y N/Y Y N
> >
> > The No/Yes cases means on this system sometimes the kernel would boot
> > (same as others have reported before). In the No cases I got no ouput
> > on the attached console.
> >
> > Stange as it may be I still do see a strong correlation between the OS
> > version and whether an adeos patched kernel works or not.
>
> I should be able to confirm reasonably soon that the bug depends on
> having an interrupt pending or not before the kernel entry point is
> reached. This may depend on whether the bootloader clears the PIC and
> when before jumping to the kernel start address. It will also depend on
> the behavior of some device involved in the boot sequence, such as the
> disk controller, for pending that IRQ or not.
>
> If this assumption turns to be correct, please make sure to send me your
> congrats for having authored the silly piece of code I have right in
> front of me now, that randomly turns boot screens into black holes since
> 2003 or so.
This took longer than expected since there were multiple holes to plug
for this issue, but here is the patch that makes my box always boot
properly again with 2.6.32 kernels :
http://git.denx.de/?p=ipipe-2.6.git;a=commit;h=d7ed9ab34a265d6486504d20ee794548ce6011d3
The fix is included in these patches, which are on their way to xenomai
mainline:
http://download.gna.org/adeos/patches/v2.6/x86/older/adeos-ipipe-2.6.32.15-x86-2.7-02.patch
http://download.gna.org/adeos/patches/v2.6/x86/older/adeos-ipipe-2.6.32.20-x86-2.7-02.patch
http://download.gna.org/adeos/patches/v2.6/x86/adeos-ipipe-2.6.34.5-x86-2.7-03.patch
HTH,
--
Philippe.
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Xenomai-help] kernel 2.6.32.11 with xenomai 2.5.3 fails to boot on ubuntu lucid system
2010-08-22 17:36 ` Philippe Gerum
@ 2010-08-23 7:15 ` Theo Veenker
0 siblings, 0 replies; 54+ messages in thread
From: Theo Veenker @ 2010-08-23 7:15 UTC (permalink / raw)
To: Philippe Gerum; +Cc: Xenomai help
Philippe Gerum wrote:
> On Fri, 2010-08-20 at 15:01 +0200, Philippe Gerum wrote:
>> On Fri, 2010-08-20 at 14:31 +0200, Theo Veenker wrote:
>>> Philippe Gerum wrote:
>>>> On Mon, 2010-08-16 at 21:14 +0200, Theo Veenker wrote:
>>>>> On 08/16/2010 04:26 PM, Theo Veenker wrote:
>>>>>> Gilles Chanteperdrix wrote:
>>>>>>> Theo Veenker wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I want to upgrade all our PC's from Ubuntu hardy to lucid and in the
>>>>>>>> process
>>>>>>>> I'm also going from kernel 2.6.29.5 with Xenomai 2.4.8 to kernel
>>>>>>>> 2.6.32.11
>>>>>>>> with Xenomai 2.5.3.
>>>>>>>>
>>>>>>>> I first built and tested the 2.6.32.11 kernel with 2.5.3 on my hardy
>>>>>>>> system
>>>>>>>> and all went fine. But the problem is it just doesn't run on the
>>>>>>>> lucid distro.
>>>>>>> This, I do not understand, the kernel does not need any support from the
>>>>>>> distribution for booting, how can the same kernel boot with one
>>>>>>> distribution, and not with the other? When you say the "same kernel", do
>>>>>>> you mean the exact same zImage or bzImage, or do you mean the kernel
>>>>>>> with the same configuration, but with a different compiler, or only the
>>>>>>> version is identical?
>>>>>>>
>>>>>> It is a complete mystery to me either. I compiled my kernel into a deb
>>>>>> package
>>>>>> and installed the very same deb package on three machines:
>>>>>> MSI p45 neo3 with Hardy on it -> works OK
>>>>>> MSI p45 neo3 with Ludid on it -> nothing (works fine with regular kernel)
>>>>>> MSI 945P with Lucid on it: -> nothing (works fine with regular kernel)
>>>>>>
>>>>>> I'll try the suggestions posted and keep you informed.
>>>>> OK. Connected a terminal to catch early kernel messages. Still no output
>>>>> unfortunately (with the regular kernel I do get output on the terminal,
>>>>> so the connection works).
>>>>>
>>>>> Meanwhile also built and tested kernel 2.6.32.15 + xenomai 2.5.4. Still nothing.
>>>>> I'm clueless. I'm running Xenomai for years on dozens of systems and I've
>>>>> never run into problems like this. I think I'll have to sit down and take a
>>>>> close look at what I'm doing. I've always built my kernels using make-kpkg,
>>>>> maybe that somehow introduces a problem here. I'll try without it.
>>>>>
>>>>> (unfortunately/luckily I have to work from home for a few days so I can't
>>>>> get to the test system until later this week)
>>>> I failed to reproduce the issue yet, but it very much looks like an
>>>> I-pipe bug. Could you try the following config variants when time
>>>> allows:
>>>>
>>>> - on 2.6.32.11 or .15, disable CONFIG_SMP, enable CONFIG_X86_UP_APIC
>>>> only (*).
>>>> - on 2.6.32.11 or .15, disable CONFIG_SMP, enable CONFIG_X86_UP_APIC and
>>>> CONFIG_X86_UP_IOAPIC (*).
>>>> - on 2.6.32.7, use your normal CONFIG_SMP config, with this patch in:
>>>> http://download.gna.org/adeos/patches/v2.6/x86/older/adeos-ipipe-2.6.32.7-x86-2.5-01.patch
>>>>
>>>> (*) you need to switch off CONFIG_SMP first, to see those knobs appear
>>>> in the "processor type and features" menu.
>>>>
>>>> The fact that you did see the panic blinking signal at least once tends
>>>> to point the finger at some access fault the kernel tries to recover
>>>> without success, rather than a sudden freeze. It must happen early
>>>> enough during the boot process, for the console not to be available yet
>>>> for reporting what the kernel whines about.
>>>>
>>>> We don't know yet if that bug is either the consequence of some
>>>> interrupt delivery, and/or induced by code only involved in SMP. Those
>>>> test configs may help in discovering this.
>>>>
>>>> TIA,
>>>>
>>> Here are my results. I've built 5 kernels:
>>> K1: 2.6.32.15 (without the adeos patch applied)
>>> K2: 2.6.32.15 + 2.5.4
>>> K3: 2.6.32.15 + 2.5.4 CONFIG_SMP off, CONFIG_X86_UP_API on, CONFIG_XENOMAI off, CONFIG_IPIPE on
>>> K4: 2.6.32.15 + 2.5.4 as (3) with CONFIG_X86_UP_IOAPIC on
>>> K5: 2.6.32.7 with adeos-ipipe-2.6.32.7-x86-2.5-01.patch
>>>
>>> I now tested these kernels on four systems:
>>> A1: MSI 945P with Ubuntu 8.04
>>> A2: MSI 945P with Ubuntu 10.04
>>> B1: MSI p45 neo3 with Ubuntu 8.04
>>> B2: MSI p45 neo3 with Ubuntu 10.04
>>>
>>> A1 and A2 are identical systems from the same batch and B1 and B2 also.
>>>
>>> What worked:
>>> A1 A2 B1 B2
>>> ----------------------------------------------------------------
>>> K1 Y Y Y Y
>>> K2 Y N/Y Y N
>>> K3 Y N/Y Y N
>>> K4 Y N/Y Y N
>>> K5 Y N/Y Y N
>>>
>>> The No/Yes cases means on this system sometimes the kernel would boot
>>> (same as others have reported before). In the No cases I got no ouput
>>> on the attached console.
>>>
>>> Stange as it may be I still do see a strong correlation between the OS
>>> version and whether an adeos patched kernel works or not.
>> I should be able to confirm reasonably soon that the bug depends on
>> having an interrupt pending or not before the kernel entry point is
>> reached. This may depend on whether the bootloader clears the PIC and
>> when before jumping to the kernel start address. It will also depend on
>> the behavior of some device involved in the boot sequence, such as the
>> disk controller, for pending that IRQ or not.
>>
>> If this assumption turns to be correct, please make sure to send me your
>> congrats for having authored the silly piece of code I have right in
>> front of me now, that randomly turns boot screens into black holes since
>> 2003 or so.
>
> This took longer than expected since there were multiple holes to plug
> for this issue, but here is the patch that makes my box always boot
> properly again with 2.6.32 kernels :
>
> http://git.denx.de/?p=ipipe-2.6.git;a=commit;h=d7ed9ab34a265d6486504d20ee794548ce6011d3
>
> The fix is included in these patches, which are on their way to xenomai
> mainline:
>
> http://download.gna.org/adeos/patches/v2.6/x86/older/adeos-ipipe-2.6.32.15-x86-2.7-02.patch
> http://download.gna.org/adeos/patches/v2.6/x86/older/adeos-ipipe-2.6.32.20-x86-2.7-02.patch
> http://download.gna.org/adeos/patches/v2.6/x86/adeos-ipipe-2.6.34.5-x86-2.7-03.patch
Yeehaa, it works! Just tested with 2.6.32.15 and the machines with Ubuntu 10.04
(the ones using grub2) now boot fine.
Philippe, I bow my head in gratitude. Many thanks everbody.
Theo
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [Xenomai-help] kernel 2.6.32.11 with xenomai 2.5.3 fails to boot on ubuntu lucid system
2010-08-20 12:31 ` Theo Veenker
2010-08-20 12:34 ` Gilles Chanteperdrix
2010-08-20 13:01 ` Philippe Gerum
@ 2010-08-21 9:32 ` Daniele Nicolodi
2 siblings, 0 replies; 54+ messages in thread
From: Daniele Nicolodi @ 2010-08-21 9:32 UTC (permalink / raw)
To: xenomai
On 20/08/10 14:31, Theo Veenker wrote:
> Here are my results. I've built 5 kernels:
> K1: 2.6.32.15 (without the adeos patch applied)
> K2: 2.6.32.15 + 2.5.4
> K3: 2.6.32.15 + 2.5.4 CONFIG_SMP off, CONFIG_X86_UP_API on, CONFIG_XENOMAI off, CONFIG_IPIPE on
> K4: 2.6.32.15 + 2.5.4 as (3) with CONFIG_X86_UP_IOAPIC on
> K5: 2.6.32.7 with adeos-ipipe-2.6.32.7-x86-2.5-01.patch
>
> I now tested these kernels on four systems:
> A1: MSI 945P with Ubuntu 8.04
> A2: MSI 945P with Ubuntu 10.04
> B1: MSI p45 neo3 with Ubuntu 8.04
> B2: MSI p45 neo3 with Ubuntu 10.04
>
> A1 and A2 are identical systems from the same batch and B1 and B2 also.
>
> What worked:
> A1 A2 B1 B2
> ----------------------------------------------------------------
> K1 Y Y Y Y
> K2 Y N/Y Y N
> K3 Y N/Y Y N
> K4 Y N/Y Y N
> K5 Y N/Y Y N
>
> The No/Yes cases means on this system sometimes the kernel would boot
> (same as others have reported before). In the No cases I got no ouput
> on the attached console.
Hello. I would like to add my system to the statistics. I have an x86
single core host where the latest xenomai kernel I'm able to run is
2.6.30 with adeos patch 2.4.something (sorry, I do not have access to
this machine right now). Using adeos patch version 2.6 produces the same
problem as reported by Theo: no output after the boot loader.
I'm also using the latest grub provided by debian, version 1.92 I think.
I'll try with a different grub version when I'll be back to work.
Cheers,
--
Daniele
^ permalink raw reply [flat|nested] 54+ messages in thread