From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4DA6FABA.7020407@domain.hid> Date: Thu, 14 Apr 2011 15:46:34 +0200 From: Jesper Christensen MIME-Version: 1.0 References: <4DA6F0DD.1080403@domain.hid> <1302787886.2083.27.camel@domain.hid> In-Reply-To: <1302787886.2083.27.camel@domain.hid> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-core] kernel threads crash - possible race condition? List-Id: Xenomai life and development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Philippe Gerum Cc: "xenomai@xenomai.org" Actually i have been running with CONFIG_XENO_HW_UNLOCKED_SWITCH the whole time and i also raised the stack size from 4k to 8k. I do however think there could be some fishyness in entry_32.S. In "transfer_to_handler" SPRN_SPRG3 is used to check for stack overflow (at least in my kernel 2.6.29.6), but i must admit i haven't seen any of that in the kernel log. /Jesper On 2011-04-14 15:31, Philippe Gerum wrote: > On Thu, 2011-04-14 at 15:04 +0200, Jesper Christensen wrote: > >> I wrote about some problems concerning stack corruption when running >> xenomai on ppc. I have found out that if i disable hardware interrupts >> while running "rthal_thread_switch" the problem seems to dissapear >> somewhat. I saw a crash yesterday after running for 3 hours, and i'm >> currently running a test (has been running for 3 hours). Usually it >> would fail after 30-40 minutes. My question is: could there be a problem >> if we receive an interrupt between updating the stack pointer and the >> sprg3 register with the new thread pointer? >> >> > Normally, there should not be any issue (famous last words), since we > would run Xenomai-only code over the preempted context, and we don't > depend on SPRG3 to fetch the current phys address. In fact, at this > stage we simply don't care about the linux context, only referring to > the current Xenomai thread, which is obtained differently. > > Try switching off CONFIG_XENO_HW_UNLOCKED_SWITCH, in the "machine" > config area, if this ends up being rock-solid, then this would be a hint > that something may be fishy in this area. Raising your k-thread stack > sizes in a separate test may be interesting to check too, if not already > done. > > > >> /Jesper >> >> >> >> _______________________________________________ >> Xenomai-core mailing list >> Xenomai-core@domain.hid >> https://mail.gna.org/listinfo/xenomai-core >> >