Re: [Xenomai-core] Xenomai v2.2
Hannes Mayer wrote: Hi Jan! Jan Kiszka wrote: What about addr2line -e vmlinux -f c01d68b2? # addr2line -e vmlinux -f c01d68b2 xnshadow_ppd_insert shadow.c:0 Ok, will keep you posted! Tante grazie e buon fine settimana, Hannes. Please try make clean before rebuilding your 2.4 kernel with a different timer support. For me this fixed the issue (2.4 build system seems to fail catching all dependencies, thus some struct sizes don't get updated consistently). The only thing that still puzzles me is that my crash happened at a different code line. Anyway, might be due to other .config differences. This digging in 2.4 over x86 was worthwhile: Two further corner-case bugs found, though not all fixed yet. Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [BUG] x86 TSC emulation broken
Hi, I happened to switch on some CPU type that enabled the Xenomai's TSC emulation code. The result was an ugly lock-up: endless loop in the timer IRQ handler. The reason: the TSC emulation collides with the VT sound output / the PC speaker driver. Over 2.6, one can easily avoid this my switching off CONFIG_INPUT_PCSPKR. 2.4 requires to export and than manipulate kb_mksound (the pointer to the sound generating code). The latter pointer rang some bell. I once fixed a broken RTAI build due to that code. So I pulled out vulcano and actually found the related code + an extension of the original ipipe patch to export kb_mksound. I guess it would have been too complicated for Paolo to explain the reason of this export to us... Anyway, this digging revealed another potential breakage in the emulation code: RTAI takes care to read the emulated TSC at least once per 50 ms, to avoid overflows I assume. Xenomai does not. Before spending some time on a clean (in contrast to what I just read in foreign code...) fix for Xenomai, I would like to cross-check if this emulation is still considered useful. No one seems to use it, otherwise we should have received complaints much earlier. Fix it or drop it? Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Eighth Real-Time Linux Workshop 2nd CFP
I dare to forward this. Maybe someone here hasn't receive a copy yet is interested in presenting work on/with Xenomai at this event. Eighth Real-Time Linux Workshop October 12-15, 2006 Lanzhou University - SISE Tianshui South Road 222 Lanzhou, Gansu 73 P.R.China General Following the meetings of developers and users at the previous 7 successful real-time Linux workshops held in Vienna, Orlando, Milano, Boston, and Valencia, Singapore, Lille, the Real-Time Linux Workshop for 2006 will come back to Asia again, to be held at the School for Information Science and Engineering, Lanzhou University, in Lanzhou China. Embedded and real-time Linux is rapidly gaining traction in the Asia Pacific region. Embedded systems in both automation/control and entertainment moving to 32/64bit systems, opening the door for the use of full featured OS like GNU/Linux on COTS based systems. With real-time capabilities being a common demand for embedded systems the soft and hard real-time variants are an important extension to the versatile GNU/Linux GPOS. Authors are invited to submit original work dealing with general topics related to real-time Linux research, experiments and case studies, as well as issues of integration of real-time and embedded Linux. A special focus will be on industrial case studies. Topics of interest include, but are not limited to: * Modifications and variants of the GNU/Linux operating system extending its real-time capabilities, * Contributions to real-time Linux variants, drivers and extensions, * User-mode real-time concepts, implementation and experience, * Real-time Linux applications, in academia, research and industry, * Work in progress reports, covering recent developments, * Educational material on real-time Linux, * Tools for embedding Linux or real-time Linux and embedded real-time Linux applications, * RTOS core concepts, RT-safe synchronization mechanisms, * RT-safe interaction of RT and non RT components, * IPC mechanisms in RTOS, * Analysis and Benchmarking methods and results of real-time GNU/Linux variants, * Debugging techniques and tools, both for code and temporal debugging of core RTOS components, drivers and real-time applications, * Real-time related extensions to development environments. Further information: EN: http://www.realtimelinuxfoundation.org/events/rtlws-2006/ws.html CN: http://dslab.lzu.edu.cn/rtlws8/index.html Awarded papers The Programme Committee will award a best paper in the category Real- Time Systems Theory. This best paper will be invited for publication to the Real-Time Systems Journal, RTSJ. The Programme Committee will award a best paper in the category Real- Time Systems Application. This paper will be invited for publication to the Dr Dobbs Journal. Moreover, the publication of the other papers in a special issue of Dr Dobbs Journal is in discussion. Abstract submission In order register an abstract, please go to: http://www.realtimelinuxfoundation.org/rtlf/register-abstract.html Venue Lanzhou University Information Building, School of Information Science and Engineering, Laznhou University, http://www.lzu.edu.cn/. Registration In order to participate to the workshop, please register on the registration page at: http://www.realtimelinuxfoundation.org/rtlf/register-participant.html Accommodation Please refer to the Lanzhou hotel page for accomodation at http://dslab.lzu.edu.cn/rtlws8/hotels/hotels.htm Travel information For travel information and directions how to get to Lanzhou from an international airport in China please refer to: http://www.realtimelinuxfoundation.org/events/rtlws-2006/ Important dates August28: Abstract submission September 15: Notification of acceptance September 29: Final paper Pannel Participants: o Roberto Bucher - Scuola Universitaria Professionale della Svizzera Italiana, Switzerland, RTAI/ADEOS/RTAI-Lab. o Alfons Crespo Lorente - University of Valenica, Spain,Departament d'Informtica de Sistemes i Computadors, XtratuM. o Herman Haertig - Technical University Dresden, Germany,Institute for System Architecture, L4/Fiasco/L4Linux. o Nicholas Mc Guire - Lanzhou University, P.R. China, Distributed and Embedded Systems Lab, RTLinux/GPL. o Douglas Niehaus - University of Kansas, USA, Information and Telecommunication Technology Center, RT-preempt. Organization committee: * Prof. Li LIAN (Co-Chair), (SISE, Lanzhou University, CHINA) * Xiaoping ZHANG, LZU, CHINA * Jiming WANG, PKU, CHINA * Zhibing LI, ECNU, China * Prof. Nicholas MCGUIRE (Co-Chair), Real
Re: [Xenomai-core] Xenomai v2.2
Ciao Jan! Jan Kiszka wrote: [...] Please try make clean before rebuilding your 2.4 kernel with a Indeed, make clean does a wonder :-) BTW, is there any way to reconfigure the periodic timer ? Not that I wanna use it - I'm fine with the more accurate aperiodic timer, but just curious. This digging in 2.4 over x86 was worthwhile: Two further corner-case bugs found, though not all fixed yet. First, I'm sorry that I didn't consider make clean, but then this issue led to find two previously unknown bugs. From your last email to the list I guess the TSC thingie is one, what is the other one ? Anything serious ? Thanks a lot, Hannes. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Xenomai v2.2
Hannes Mayer wrote: Ciao Jan! Jan Kiszka wrote: [...] Please try make clean before rebuilding your 2.4 kernel with a Indeed, make clean does a wonder :-) Good, no further bugs hidden. :) BTW, is there any way to reconfigure the periodic timer ? Not that I wanna use it - I'm fine with the more accurate aperiodic timer, but just curious. E.g. via rt_timer_set_mode(tick_period) (native skin). If you enable the periodic mode at compile time, you can use this call from your app to tweak it during runtime. Additionally, there is the tick_arg module parameter (or the xeno_nucleus.tick_arg kernel parameter) to set the timer at startup. This digging in 2.4 over x86 was worthwhile: Two further corner-case bugs found, though not all fixed yet. First, I'm sorry that I didn't consider make clean, but then this issue led to find two previously unknown bugs. From your last email to the list I guess the TSC thingie is one, what is the other one ? Anything serious ? Not really. Try to compile the native skin as module under 2.4... Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Xenomai v2.2
On Sun, 2006-07-23 at 19:15 +0200, Jan Kiszka wrote: Hannes Mayer wrote: Hi Jan! Jan Kiszka wrote: What about addr2line -e vmlinux -f c01d68b2? # addr2line -e vmlinux -f c01d68b2 xnshadow_ppd_insert shadow.c:0 Ok, will keep you posted! Tante grazie e buon fine settimana, Hannes. Please try make clean before rebuilding your 2.4 kernel with a different timer support. For me this fixed the issue (2.4 build system seems to fail catching all dependencies, thus some struct sizes don't get updated consistently). For the record, I did run into the very same issue this afternoon while trying to reproduce this crash on 2.4.32: invalid dereference from kernel at offset #240 when starting the latency test, right after having armed the periodic timing support from a previous configuration that lacked it. A clean rebuild did fix the issue. The only thing that still puzzles me is that my crash happened at a different code line. Anyway, might be due to other .config differences. This digging in 2.4 over x86 was worthwhile: Two further corner-case bugs found, though not all fixed yet. Jan ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [BUG] x86 TSC emulation broken
On Sun, 2006-07-23 at 19:28 +0200, Jan Kiszka wrote: Hi, I happened to switch on some CPU type that enabled the Xenomai's TSC emulation code. The result was an ugly lock-up: endless loop in the timer IRQ handler. The reason: the TSC emulation collides with the VT sound output / the PC speaker driver. Over 2.6, one can easily avoid this my switching off CONFIG_INPUT_PCSPKR. 2.4 requires to export and than manipulate kb_mksound (the pointer to the sound gen* erating code). There is an issue in the Adeos 2.4 patch (1.2-05) which is not preventing the kernel from poking into the 8254 registers to determine the current time offset. The latter pointer rang some bell. I once fixed a broken RTAI build due to that code. So I pulled out vulcano and actually found the related code + an extension of the original ipipe patch to export kb_mksound. I guess it would have been too complicated for Paolo to explain the reason of this export to us... Anyway, this digging revealed another potential breakage in the emulation code: RTAI takes care to read the emulated TSC at least once per 50 ms, to avoid overflows I assume. Xenomai does not. Mm, through the host timer service, it should at least each 10ms period. Before spending some time on a clean (in contrast to what I just read in foreign code...) fix for Xenomai, I would like to cross-check if this emulation is still considered useful. No one seems to use it, otherwise we should have received complaints much earlier. Fix it or drop it? Jan ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [BUG] x86 TSC emulation broken
Philippe Gerum wrote: On Sun, 2006-07-23 at 19:28 +0200, Jan Kiszka wrote: Hi, I happened to switch on some CPU type that enabled the Xenomai's TSC emulation code. The result was an ugly lock-up: endless loop in the timer IRQ handler. The reason: the TSC emulation collides with the VT sound output / the PC speaker driver. Over 2.6, one can easily avoid this my switching off CONFIG_INPUT_PCSPKR. 2.4 requires to export and than manipulate kb_mksound (the pointer to the sound gen* erating code). There is an issue in the Adeos 2.4 patch (1.2-05) which is not preventing the kernel from poking into the 8254 registers to determine the current time offset. But the TSC emulation itself is not an Adeos service. Shouldn't it be better moved? Then I would happily leave it up to you. :) The latter pointer rang some bell. I once fixed a broken RTAI build due to that code. So I pulled out vulcano and actually found the related code + an extension of the original ipipe patch to export kb_mksound. I guess it would have been too complicated for Paolo to explain the reason of this export to us... Anyway, this digging revealed another potential breakage in the emulation code: RTAI takes care to read the emulated TSC at least once per 50 ms, to avoid overflows I assume. Xenomai does not. Mm, through the host timer service, it should at least each 10ms period. Yeah, true. I probably got blinded by the existing RTAI code. There is just the likely theoretical case that there is no host tick (LAPIC + emulated TSC? Not configurable, is it?). Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [BUG] x86 TSC emulation broken
On Sun, 2006-07-23 at 22:52 +0200, Jan Kiszka wrote: Philippe Gerum wrote: On Sun, 2006-07-23 at 19:28 +0200, Jan Kiszka wrote: Hi, I happened to switch on some CPU type that enabled the Xenomai's TSC emulation code. The result was an ugly lock-up: endless loop in the timer IRQ handler. The reason: the TSC emulation collides with the VT sound output / the PC speaker driver. Over 2.6, one can easily avoid this my switching off CONFIG_INPUT_PCSPKR. 2.4 requires to export and than manipulate kb_mksound (the pointer to the sound gen* erating code). There is an issue in the Adeos 2.4 patch (1.2-05) which is not preventing the kernel from poking into the 8254 registers to determine the current time offset. But the TSC emulation itself is not an Adeos service. Shouldn't it be better moved? Unfortunately, we can't do that. The relevant code is in arch/i386/kernel/time.c, do_slow_gettimeoffset(), you just can't abstract this from the kernel sanely. It's a recurring issue with any Adeos port over x86, and this got more complex with 2.6. Btw, it's not an emulation issue that Adeos processes that way, it's about dealing with the true owner of the PIT - as a non-virtualizable resource -, i.e. Linux, or some domain above it. When Linux does not own the PIT, it should refrain from touching it, period; and that's what this code actually ensures. This is consistent with ipipe_tune_timer(), which on some archs, is even used to tell Linux that some domain is grabbing the timer for its own use (e.g. ia64). Then I would happily leave it up to you. :) I've a fix pending for the do_slow_gettimeofset() issue in 2.4 (2.6 is fine). Adeos could export kd_mksound too, even if it's a terminally ugly way of fixing this, but I have no better approach at hand. The latter pointer rang some bell. I once fixed a broken RTAI build due to that code. So I pulled out vulcano and actually found the related code + an extension of the original ipipe patch to export kb_mksound. I guess it would have been too complicated for Paolo to explain the reason of this export to us... Anyway, this digging revealed another potential breakage in the emulation code: RTAI takes care to read the emulated TSC at least once per 50 ms, to avoid overflows I assume. Xenomai does not. Mm, through the host timer service, it should at least each 10ms period. Yeah, true. I probably got blinded by the existing RTAI code. I recall having once thoroughly debugged the non-TSC case circa fusion 0.6.4 or so, this is why I'm relatively confident that we should be able to reactivate such support without too much burden. It's confined in the HAL, so the impact on the rest of the code is minimal. There is just the likely theoretical case that there is no host tick (LAPIC + emulated TSC? Not configurable, is it?). Nope; in the LAPIC case, the hw must provide a TSC anyway. Jan -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
