From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <5046C2DA.7080200@ebus.com> Date: Tue, 04 Sep 2012 20:11:22 -0700 From: Doug Brunner MIME-Version: 1.0 References: <50405C4F.5030301@ebus.com> <50406A3D.4080801@xenomai.org> <5043F063.2020302@ebus.com> <50444008.4000109@xenomai.org> <5045AD78.3090904@ebus.com> <5045B732.8040104@xenomai.org> In-Reply-To: <5045B732.8040104@xenomai.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai] Upgrading to Xenomai 2.6.1 List-Id: Discussions about the Xenomai project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gilles Chanteperdrix Cc: xenomai@xenomai.org On 09/04/2012 01:09 AM, Gilles Chanteperdrix wrote: > On 09/04/2012 09:27 AM, Doug Brunner wrote: >> On 09/02/2012 10:28 PM, Gilles Chanteperdrix wrote: >>> On 09/03/2012 01:48 AM, Doug Brunner wrote: >>> >>>> On 08/31/2012 12:39 AM, Gilles Chanteperdrix wrote: >>>>> On 08/31/2012 08:40 AM, Doug Brunner wrote: >>>>> >>>>>> I've been having a very hard time with the upgrade from Xenomai 2.6.0 to >>>>>> 2.6.1--hoping someone might have a suggestion for me. My thinking was >>>>>> that, to get the most possible bug fixes, I should also upgrade to the >>>>>> latest kernel for which there is a stable I-pipe patch, which appears to >>>>>> be 3.2.21 from examining the list of available patches distributed with >>>>>> Xenomai. >>>>>> >>>>>> Unfortunately, 3.2.21 (even unmodified, using a vanilla Debian kernel >>>>>> config, set for 586 cpu type) will not boot on my target platform >>>>>> (Winsystems PPM-LX800-G, which has a Geode LX800 CPU). It immediately >>>>>> resets after "Loading initial ramdisk", without even any early printk >>>>>> output. I have no idea what could be causing that :( >>>>> Ok. I have just booted my geode with 3.4, both with 586 cpu type without >>>>> tsc and with geode cpu type with tsc. The kernel boots and the latency >>>>> test starts. So, I guess you selected a kernel configuration option we >>>>> do not support (such as CONFIG_KGDB). >>>>> >>>>> You can download the configuration which works for me here: >>>>> http://xenomai.org/~gch/config-geode >>>>> >>>> Argh...the problem was apparently that I'd left SMP support selected. >>>> Thanks for your config! It's a nice bare-bones kernel and boots my Geode >>>> as well so I'm using it as a new starting point. >>>> I saw an email from you on 8/3 referring to a regression connected to >>>> irq_hold that was fixed in your git. Should I get an I-pipe patch from >>>> there, or from git.denx.de/ipipe.git instead of using the one >>>> distributed with 2.6.1? >>> Probably not, that is a fix for IO-APIC interrupt controller, the geode >>> does not have an IO-APIC. Making a few tests with geode without tsc I >>> found out something obvious: "statistics collection" should be disabled >>> as it causes the tsc read function to be called often, and each read of >>> the emulated tsc costs 4us. >> If I understand you correctly you are recommending I use 3.2.21 with the >> ipipe patch supplied with Xeno 2.6.1 (changing ipipe_root_domain_p to >> ipipe_root_p in arch/x86/lib/mmx_32.c). >> >> Unfortunately it seems neither that 3.2.21 nor the already ipipe-enabled >> 3.4.6 from git.denx.de/ipipe.git >> (29e656a9501663366287a893d5f6d62bff9f40f6) works with my target >> Winsystems PPM-LX800-G. Whether I use the config you posted at >> http://xenomai.org/~gch/config-geode or mine (derived from yours, just >> drops some ethernet devices I don't use and adds the Geode framebuffer >> and IPv6), the system experiences ATA faults such as the following >> immediately upon trying to boot: >> >> ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen >> ata1.00: failed command: READ DMA >> ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 in >> res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) >> ata1.00: status: { DRDY } >> >> Finally, after several of these with long delays in between, it panics >> because it can't find the root filesystem on the ATA device it's trying >> to access (CF card via the CS5536 controller). >> >> The same config minus the ipipe stuff, fed to an unpatched kernel tree, >> produces a binary that will boot the system with no error messages; this >> is true for both 3.2.21 and 3.4.6. Any idea what could be doing this, or >> what else I can do to debug? I've attached my configs for reference, >> except the 3.4.6 ipipe which I forgot to save. > The cs5536 SATA driver does not work for me either, even without I-pipe, > whereas the legacy IDE driver (option CONFIG_BLK_DEV_CS5536) works, > could you test whether it works for you? > For me the CS5536 PATA driver (not SATA as you have) works fine without I-pipe, but with I-pipe I get the fault described above. The legacy IDE driver does work with I-pipe, at least on 3.2.21. I will be running the Xenomai test suite against that build tomorrow.