[Xenomai] xenomai in vmware smp crash

Gentlemen, Hello! It's been many years since I've been on the list. I still dabble in Xenomai when jobs come up. I wish I had more need to use it so I can contribute. I've missed my friendly back and forth emails with Gilles on geopolitical issues. I was asked by a client to patch an

Re: [Xenomai] xenomai in vmware smp crash

I should mention that this is 3.2.31 and it's using the ipipe 3.2.21-x86-1 patch. ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] xenomai in vmware smp crash

Disregard my email. I did search before posting, but found nothing. I did another search after posting for ipipe.c:592 and found it. This patch solved my problem: http://www.mail-archive.com/xenomai@xenomai.org/msg01010.html Thanks, Steven -Original Message- From: Steven Seeger

Re: [Xenomai] powerpc 440 userspace latency test does nothing

More info on this. timer_gettime() on latency's timerfd returns 0 seconds and 1 nanosecond, indicating the timer has not expired. No matter how much time I sleep before this the result is the same. The output of cat /proc/xenomai/timer/coreclk: SCLINUX: / # cat /proc/xenomai/timer/coreclk

[Xenomai] powerpc 440 userspace latency test does nothing

Hey guys. I am running a virtex5 ml507 board from Xilinx configured to use the internal powerpc 440 processor in the FPGA. I compiled a 3.18.20 kernel and patched it and build xenomai 3.0.1. I am able to run latency -t 1 and latency -t 2 When I try to run just latency, however, I get no

Re: [Xenomai] powerpc 440 userspace latency test does nothing

Just to add more info, the issue is that the read() call from the timerfd never returns. I've never seen this occur before. Steven On Saturday, December 05, 2015 03:02:38 Steven Seeger wrote: > Hey guys. > > I am running a virtex5 ml507 board from Xilinx configured to use the &

Re: [Xenomai] powerpc 440 userspace latency test does nothing

Me again. The issue appears to be that there's a discrepancy between the value returned by clock_gettime(CLOCK_MONOTONIC... and the cobalt kernel's internal notion of time. Changing latency to start with a 100 nanosecond relative time (which adds some constant latency to the expected result

[Xenomai] userspace absolute timer value

Since my last post I seem to have solved the issues with my ppc44x board hard locking up. I've relayed this info to Philippe and hopefully he will confirm that I'm correct and that I should make a patch. However in the process, I've stopped seeing the latency -t1 and latency -t2 work correctly.

Re: [Xenomai] userspace absolute timer value

On Wednesday, December 23, 2015 19:43:41 Gilles Chanteperdrix wrote: > If I understand correctly, your problem is that struct timespec > tv_sec member has 32 bits. Well, I am afraid there is not much we > can do about that (I heard mainline has a plan to switch to a new > timespec with a 64 bits

Re: [Xenomai] userspace absolute timer value

All, The issue that I had with userspace absolute time to start a timer (what latency test does) was due to a quirk on my board where the powerpc timebase was coming up as 0xdXXX which was causing the 32-bit userland to lose precision when getting the monotonic clock value. The

Re: [Xenomai] Gilles Chanteperdrix, 1975-2016

Words cannot adequately describe the loss of Gilles for our hard realtime Linux community. I have communicated with him for years, and always had the utmost respect for him.He took the time to troubleshoot a strange FPU issue on the Geode with me back in early 2007. We spent weeks going back

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

Philippe, as we have previously discussed I am willing to take over the PPC i- pipe maintenance on my personal time if it will help. My only issue is right now the only PPC board I have in my posseession is an 8548-based board. I might be able to borrow some 405 and 440-based boards from work if

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

> Hi Steven, > > I have remote access to many ppc boards and could help here. This said > 85xx, 40x and 44x already cover much of the ppc32 scope running Xenomai > - maybe adding mpc52xx would be good, I have one here. I don't see much > traction these days for Xenomai over ppc64, so I'm not even

Re: [Xenomai] New year, new roles

boards for relatively low cost. If there's anything I can do for you guys let me know. Steven Seeger Software Engineer Embedded Flight Systems, Inc. 304-550-8800 (cell) On Monday, December 18, 2017 8:48:08 AM EST Jan Kiszka wrote: > On 2017-12-17 20:16, Philippe Gerum wrote: > > Sixteen ye

Re: [Xenomai] New year, new roles

Sorry I should say that "a team at Johnson Space Center" not the whole center itself. :) Steven ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai

[Xenomai] ppc32 users

Is anyone actively using xenomai on ppc32? I'm going to be doing the 4.14 migration of the IPIPE to ppc32 and was hoping for some volunteers to help test. Steven ___ Xenomai mailing list Xenomai@xenomai.org

Re: [Xenomai] Reg:Xenomaui support for Powerpc p1022

On Monday, June 11, 2018 7:10:10 AM EDT Sureshvs wrote: > Hi > > > I am using freescale P1022 PowerPC based processor board.xenomai support is > available for p1022 ? In your website, suported architectures for > powerpc1022 is not mentioned. > > Kindly share the details. Hi Suresh. I'm

Re: [Xenomai] Reg:Xenomaui support for Powerpc p1022

On Tuesday, June 12, 2018 9:34:21 AM EDT Alexander Voytov wrote: > What about P2020 and xenomai? Did anyone ported xenomai on fsl p2020? > Alex You're asking the wrong questions. p1020 and p2020 are e500 processors, and the e500 family is supported in xenomai. I have an 8548 board (also e500)

Re: [Xenomai] Introducing Dovetail

On Tuesday, June 5, 2018 6:48:23 AM EDT Philippe Gerum wrote: > This is a heads-up about an ongoing work I hinted at last year [1] > codenamed "Dovetail", which has just reached a significant milestone. In > short, an overhauled implementation of the interrupt pipeline is now > capable of

Re: [Xenomai] Unrecoverable FP Unavailable Exception 801

Hello all. I've created what Philippe thinks is a good patch for this issue as well as looked at other cases of clobbered bits in the MSR as it relates to vsx, spe, and altivec. I have checked in a patch on our interim 4.14 IPIPE work which is not yet public. It looks trivial to backport this

Re: [Xenomai] Xenomai community meeting 02.02.18

On Tuesday, January 9, 2018 6:22:02 AM EST Henning Schild wrote: > Hi, > > we have already talked about the "elephant in the room" and in that > thread we also talked about a face-to-face meeting of current and > future maintainers, contributers and users. > > We have now agreed on a time and

Re: [Xenomai] Unrecoverable FP Unavailable Exception 801

On Wednesday, April 4, 2018 8:57:31 AM EDT Sagi Maimon wrote: > HI, > I did it only from Linux side. > I can try doing it from xenomai side too. > Please explain how would it help to investigate the problem? > If the problem does not occur in a regular linux thread, but only occurs in a

Re: [Xenomai] Unrecoverable FP Unavailable Exception 801

On Wednesday, April 4, 2018 11:42:08 AM EDT Sagi Maimon wrote: > Thanks for your reply. > You are right, but unfortunately in my ssytem it happens on the Linux side: > The Linux kernel code that fixes the alignment during align exception (600) > works most of the time, but sometimes during the

Re: [Xenomai] Unrecoverable FP Unavailable Exception 801

On Monday, April 2, 2018 10:54:54 AM EDT Sagi Maimon wrote: > Hi all, > I am working with: Powerpc e300 SOC. > I am using: xenomai-2.6.4 version > > I am experiencing this exception on my Linux : > Unrecoverable FP Unavailable Exception 801 at c0003858 > Oops:

Re: [Xenomai] Unrecoverable FP Unavailable Exception 801

On Tuesday, April 3, 2018 2:31:38 PM EDT Lennart Sorensen wrote: > On Tue, Apr 03, 2018 at 09:57:52AM -0400, Steven Seeger wrote: > > I'm a little curious about the fact that the address this occurred at is > > 0xc0003858, which suggests it's kernel code. As Philippe asked, w

Re: [Xenomai] Unrecoverable FP Unavailable Exception 801

On Wednesday, April 25, 2018 12:49:53 PM EDT Philippe Gerum wrote: > The fix makes a lot of sense, thanks. This bug slipped under the radar > for years likely because enabling the ppc fpu in kernel context mainly > happens when fixing up alignment issues, which rt apps tend to avoid in > the first

Re: [Xenomai] Does RTNET supports TCP?

On Saturday, October 6, 2018 4:07:49 AM EDT Sebastian Smolorz wrote: > Do you mean kernel/drivers/net/doc/README.drvporting? Yes, this was it. Thanks. Steven ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] Does RTNET supports TCP?

On Thursday, October 4, 2018 9:02:46 PM EDT Pham, Phong wrote: > Hi, > > I noticed starting Xenomai 3.0.1 until now (3.0.7), there is net/ in > .../kernel/drivers/ and in ../kernel/drivers/net/stack/ipv4/Kconfig > > # source "drivers/xenomai/net/stack/ipv4/tcp/Kconfig" I don't know why this is

Re: [Xenomai] Does RTNET supports TCP?

On Monday, October 8, 2018 2:49:55 PM EDT Sebastian Smolorz wrote: > > Hm ... then why don't you fetch your files in non-realtime context? This > would be much easier I suppose. Yes I agree. Based on what Phong has said, it would make more sense to fetch the files in a non-realtime context and

Re: [PATCH] cobalt/kernel: Simplify mayday processing

On Monday, November 5, 2018 7:20:33 AM EST Jan Kiszka wrote: > > I would appreciate if you could test ARM64 and PowerPC for me. Until we > have QEMU test images for both, it's still tricky for me to do that. I have something I've got to get done before I can do anything else, but once that's

xenomai in space

List, Early Saturday morning a Space/X dragon rocket launched with STP-H6 on board. I wrote some drivers and was on the software architecture board for the software on the CIB, communications interface bus on that system. There are several (9 if I recall) science experiments that all

Re: I-pipe / Dovetail news

On Thursday, May 2, 2019 12:46:37 PM EDT Philippe Gerum wrote: > At the end of this process, a Dovetail-based Cobalt core should be > available for the ARM, ARM64 and x86_64 architectures. The port is made > in a way that enables the Cobalt core to interface with either the > I-pipe or Dovetail at

__ipipe_root_sync

Why was __ipipe_root_sync moved out of kernel/ipipe/core.c? I see it now in arch/arm/kernel/ipipe.c. It is the same exact code I had in the PPC branch in kernel/ipipe/core.c. I can move it to the arch-specific code, but was wondering why. Steven

release spam

Everyone, Sorry for the release spam. I accidentally pushed all tags to the tag server instead of just the one I was working on. Guess I will buy donuts if I ever make it out to one of the meetings. :) Steven

Re: __ipipe_root_sync

On Friday, April 26, 2019 2:11:30 PM EDT Philippe Gerum wrote: > > However, __ipipe_root_sync() is 100% redundant with sync_root_irqs(), > which we need in the generic pipelined syscall handling callable from C. > So the situation is a bit silly ATM. Let's rename sync_root_irqs() to >

Re: [PATCH] powerpc: ipipe: Do full exit checks after __ipipe_call_mayday

On Thursday, December 19, 2019 11:53:36 AM EST Jan Kiszka wrote: > > Ho, ho, this is an early X-mas gift. Thanks for finding this. I'm a terrible PPC maintainer so if anyone else wants to volunteer to take my place ;) > Looking at DoSyscall in entry_32.S, it seems we lack such a careful >

Re: [PATCH] powerpc: ipipe: Do full exit checks after __ipipe_call_mayday

On Thursday, December 19, 2019 12:14:27 PM EST Jan Kiszka wrote: > > Check ipipe-arm/ipipe/master:arch/arm/kernel/entry-common.S for the call > to ipipe_call_mayday. I suspect that pattern transfers nicely. > > Jan Will do. Can you point me to a smokey test that will prove the implemention is

Re: [PATCH] powerpc: ipipe: Do full exit checks after __ipipe_call_mayday

On Thursday, December 19, 2019 11:53:36 AM EST Jan Kiszka wrote: > > Ho, ho, this is an early X-mas gift. Jan, I got "gdb ok" when I removed the block I had in the entry_32.S I sent you around the recheck/do_user_signal path. I was pretty sure I didn't need the intret there. Do you remember

Re: [PATCH] powerpc: ipipe: Do full exit checks after __ipipe_call_mayday

Jan, I took a look at entry-common.S and entry_32.S and I think we have the correct check. The flow is a little different, but it seems to work as far as I can tell. This was originally Philippe's code. Maybe he can take a quick look. ;) Steven

Re: [PATCH] powerpc: ipipe: Do full exit checks after __ipipe_call_mayday

Tried running with your patch, Jan. I made sure the files I sent you I had worked on were the same I had sent you. I wound up with a crash in do_user_signal during the smokey gdb test. # LD_LIBRARY_PATH=/usr/xenomai/lib /usr/xenomai/bin/smokey --run=gdb [ 10.650031] Unable to handle kernel

Re: initial porting of IPIPE x86_64 patches onto Linux stable 5.4.52

On Tuesday, August 25, 2020 9:25:00 AM EDT Lennart Sorensen wrote: > A 5020 is an e5500, which is nothing like an e500. The e500 is PowerpC > SPE, while the e5500 (and the e300, e500mc and e6500) are "real" PowerPC > instead with a somewhat different instruction set. Sorry e500 was a typo in

Re: initial porting of IPIPE x86_64 patches onto Linux stable 5.4.52

> On Mon, Aug 24, 2020 at 2:09 AM Jan Kiszka wrote: > > Greg, with this baseline available, porting ARM/ARM64 to 5.4 should > > become possible. Thought I would wait until we have basic confidence on > > x86 into the generic pieces. Steven, same for powerpc. I'm definitely interested in doing

Re: Dovetail <-> PREEMPT_RT hybridization

On Thursday, July 23, 2020 12:23:53 PM EDT Philippe Gerum wrote: > Two misunderstandings it seems: > > - this work is all about evolving Dovetail, not Xenomai. If such work does > bring the upsides I'm expecting, then I would surely switch EVL to it. In > parallel, you would still have the

Re: Dovetail <-> PREEMPT_RT hybridization

On Tuesday, July 21, 2020 1:18:21 PM EDT Philippe Gerum wrote: > > - identifying and quantifying the longest interrupt-free sections in the > target preempt-rt kernel under meaningful stress load, with the irqoff > tracer. I wrote down some information [1] about the stress workloads which >