Re: [Xenomai-core] x86_64 - Initial results.
Paul wrote: Hi Philippe On Saturday 24 February 2007 17:17, Philippe Gerum wrote: Ok, the latter looks clearly pathological. The trace should tell us more. Rather the CONFIG_IPIPE_TRACE feature, with the IRQs off tracking option set Had to recompile without SMP (see attached config), so used the -03 ipipe patch with xenomai r2248. Started the latency test, and then fired up X (no WM) - At which point the latency went in to a zombie state with a massive hike in value. ipipe/trace/max, latency log, and dmesg outputs all attached. Please grab trace/frozen instead, enable verbose mode, and increase back_trace_points so that the reported latency is fully covered. See http://www.xenomai.org/index.php/I-pipe:Tracer for further instructions. Thanks, Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Re: RT-Socket-CAN versioning
Wolfgang Grandegger wrote: Hi Jan, Jan Kiszka wrote: Wolfgang Grandegger wrote: Hi Jan, currently the RT-Socket-CAN drivers maintains it's own version or release number. As RT-Socket-CAN is part of Xenomai, I do not see the need for it (and so far I did not update it). What is the intended use of driver_version in struct rtdm_device? Actually, I was thinking about this too yesterday. The idea of the separate versioning for RTDM drivers is to signal the users if something in the driver really changed. It's fairly obvious what to do with it for out-of-tree drivers, but for in-tree it might be worth considering the policy. The current model, maintained more or less properly for the existing drivers, is to increment independently of Xenomai according to major or minor changes. One may ease this burden for the driver developer by simply filling in Xenomai's version here. That would just let the revisions increase on every Xenomai release, even if the driver remained untouched. The tag would still have a meaning for out-of-tree drivers, but for in-tree it would be fairly meaningless. Well, whatever is commonly preferred, it should then be applied consistently on all RTDM drivers in Xenomai. What are the opinions on this list (I will comment afterwards)? OK, no other opinions so far. Then let's keep the current versioning I guess everyone's busy with more serious issues. scheme. I'm going to boost the RT-Socket-CAN version number to 0.90.0 with the next commit and to 1.0.0 for the next official release (2.4.x?). Ack. That's preferred from my side as well. Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Kernel lockup with lapic on old AMD Athlon
Hello, here is the boot log of an hangup of 2.6.20 with I-pipe 1.7-02 and Xenomai todays trunk. I already reported this hangup a while ago but now I get an oops. At that time Gilles said that lapic on old Athlons might be buggy. Does the attached boot log confirm this assumption? 2.6.20-rt8 is working, BTW. Thanks. Wolfgang. Linux version 2.6.20-ipipe ([EMAIL PROTECTED]) (gcc version 4.0.2 20051125 (Red Hat 4.0.2-8)) #1 PREEMPT Sun Feb 25 10:21:36 CET 2007 BIOS-provided physical RAM map: sanitize start sanitize end copy_e820_map() start: size: 0009fc00 end: 0009fc00 type: 1 copy_e820_map() type is E820_RAM copy_e820_map() start: 0009fc00 size: 0400 end: 000a type: 2 copy_e820_map() start: 000f size: 0001 end: 0010 type: 2 copy_e820_map() start: 0010 size: 1fef end: 1fff type: 1 copy_e820_map() type is E820_RAM copy_e820_map() start: 1fff size: 3000 end: 1fff3000 type: 4 copy_e820_map() start: 1fff3000 size: d000 end: 2000 type: 3 copy_e820_map() start: size: 0001 end: 0001 type: 2 BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 1fff (usable) BIOS-e820: 1fff - 1fff3000 (ACPI NVS) BIOS-e820: 1fff3000 - 2000 (ACPI data) BIOS-e820: - 0001 (reserved) 0MB HIGHMEM available. 511MB LOWMEM available. Zone PFN ranges: DMA 0 - 4096 Normal 4096 - 131056 HighMem131056 - 131056 early_node_map[1] active PFN ranges 0:0 - 131056 DMI 2.2 present. ACPI: PM-Timer IO Port: 0x4008 Allocating PCI resources starting at 3000 (gap: 2000:dfff) Detected 1099.576 MHz processor. Built 1 zonelists. Total pages: 130033 Kernel command line: ro root=LABEL=/ rhgb console=tty0 console=ttyS1,19200 lapicLocal APIC disabled by BIOS -- reenabling. Found and enabled local APIC! Enabling fast FPU save and restore... done. Initializing CPU#0 CPU 0 irqstacks, hard=c0434000 soft=c0435000 PID hash table entries: 2048 (order: 11, 8192 bytes) I-pipe 1.7-02: pipeline enabled. Console: colour VGA+ 80x25 Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Memory: 514108k/524224k available (2165k kernel code, 9552k reserved, 872k data, 216k init, 0k highmem) virtual kernel memory layout: fixmap : 0xfff9c000 - 0xf000 ( 396 kB) pkmap : 0xff80 - 0xffc0 (4096 kB) vmalloc : 0xe080 - 0xff7fe000 ( 495 MB) lowmem : 0xc000 - 0xdfff ( 511 MB) .init : 0xc03f9000 - 0xc042f000 ( 216 kB) .data : 0xc031d467 - 0xc03f75d0 ( 872 kB) .text : 0xc010 - 0xc031d467 (2165 kB) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 2199.58 BogoMIPS (lpj=1099790) Security Framework v1.0.0 initialized SELinux: Initializing. SELinux: Starting in permissive mode selinux_register_security: Registering secondary module capability Capability LSM initialized as secondary Mount-cache hash table entries: 512 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 256K (64 bytes/line) Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: AMD Athlon(tm) Processor stepping 02 Checking 'hlt' instruction... OK. ACPI: Core revision 20060707 ACPI: setting ELCR to 0800 (from 0e20) NET: Registered protocol family 16 ACPI: bus type pci registered PCI: PCI BIOS revision 2.10 entry at 0xfb250, last bus=1 PCI: Using configuration type 1 Setting up standard PCI resources ACPI: Interpreter enabled ACPI: Using PIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (:00) ACPI: Assume root bridge [\_SB_.PCI0] bus is 0 Disabling VIA memory write queue (PCI ID 0305, rev 03): [55] 89 1f - 09 PCI quirk: region 6000-607f claimed by vt82c686 HW-mon PCI quirk: region 5000-500f claimed by vt82c686 SMB ACPI: PCI Interrupt Link [LNKA] (IRQs 1 3 4 5 6 7 10 11 12 14 15) *9 ACPI: PCI Interrupt Link [LNKB] (IRQs 1 3 4 *5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 1 3 4 5 6 7 *10 11 12 14 15) ACPI: PCI Interrupt Link [LNKD] (IRQs 1 3 4 5 6 7 10 *11 12 14 15) Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI init pnp: PnP ACPI: found 12 devices usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb PCI: Using ACPI for IRQ routing PCI: If a device doesn't work, try pci=routeirq. If it helps, post a report PCI: Bridge: :00:01.0 IO window: 9000-9fff MEM window:
Re: [Xenomai-core] Re: [Adeos-main] Re: Heads up: Xenomai port over x86_64 has started
On Sun, 2007-02-25 at 00:18 +, Paul wrote: On Sunday 25 February 2007 00:15, Paul wrote: Hi Philippe On Saturday 24 February 2007 22:46, Philippe Gerum wrote: Added to the fact that I've just fixed the CONFIG_SMP +CONFIG_PREEMPT issue [1], what remains to get a fully functional preliminary x86_64 port is to solve the CONFIG_SMP+CONFIG_IPIPE_TRACE, and we should be done. If CONFIG_PREEMPT is not enabled, the kernel compile fails with: arch/x86_64/kernel/built-in.o: In function `__ipipe_preempt_schedule_irq': arch/x86_64/kernel/ipipe.c:471: undefined reference to `preempt_schedule_irq' make[1]: *** [.tmp_vmlinux1] Error 1 make[1]: Leaving directory `/var/tmp/linux-2.6.19.3' make: *** [debian/stamp-build-kernel] Error 2 The attached patch addresses the problem.. Scrub that - It exposes another problem in thunk.S which I missed... Thanks. 1.0-04 should fix both issues. Regards, Paul. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Kernel lockup with lapic on old AMD Athlon
Wolfgang Grandegger wrote: Hello, here is the boot log of an hangup of 2.6.20 with I-pipe 1.7-02 and Xenomai todays trunk. I already reported this hangup a while ago but now I get an oops. At that time Gilles said that lapic on old Athlons might be buggy. Does the attached boot log confirm this assumption? 2.6.20-rt8 is working, BTW. What I had observed with an old Athlon were some random lockups. I was trying to setup a samba print server at the time, and the lockup always occured when some windows machine was trying to use the shared printer through network. I think the IO-APIC was also enabled. Then, at some later time, I read somewhere on the internet that the IO-APIC or LAPIC could be buggy on some Athlons, so I understood what had happened to me. So, I did not investigate this issue any further. -- Gilles Chanteperdrix. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Kernel lockup with lapic on old AMD Athlon
Gilles Chanteperdrix wrote: Wolfgang Grandegger wrote: Hello, here is the boot log of an hangup of 2.6.20 with I-pipe 1.7-02 and Xenomai todays trunk. I already reported this hangup a while ago but now I get an oops. At that time Gilles said that lapic on old Athlons might be buggy. Does the attached boot log confirm this assumption? 2.6.20-rt8 is working, BTW. What I had observed with an old Athlon were some random lockups. I was trying to setup a samba print server at the time, and the lockup always occured when some windows machine was trying to use the shared printer through network. I think the IO-APIC was also enabled. Then, at some later time, I read somewhere on the internet that the IO-APIC or LAPIC could be buggy on some Athlons, so I understood what had happened to me. So, I did not investigate this issue any further. I didn't either, especially because it works with lapic disabled in the kernel config. I just thought that this oops might be useful to somebody. Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Enhanced RTDM device closure
Jan Kiszka wrote: Hi, a few changes of the RTDM layer were committed to trunk recently. They make handling of RTDM file descriptors more handy: o rt_dev_close/POSIX-close now polls as long as the underlying device reports -EAGAIN. No more looping inside the application is required. This applies to the usual non-RT invocation of close, the corner case close from RT context can still return EAGAIN. o Automatic cleanup of open file descriptors has been implemented. This is not yet the perfect design (*), but a straightforward approach to ease the cleanup after application crashes or other unexpected terminations. o Report file descriptor owner via /proc: # cat /proc/xenomai/rtdm/open_fildes Index Locked Device Owner [PID] 0 0 rttest0 latency [973] 1 0 rtser0 cross-link [981] 2 0 rtser1 cross-link [981] 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] x86_64 - Initial results.
Paul wrote: On Sunday 25 February 2007 10:02, Jan Kiszka wrote: Rather the CONFIG_IPIPE_TRACE feature, with the IRQs off tracking option set Please grab trace/frozen instead, enable verbose mode, and increase back_trace_points so that the reported latency is fully covered. See OK - Recompiled with the 1.04 patch for UP with the ipipe trace support. After cutting Xorg's configs to a minimum (vesa driver, no Glx/dri support), latency runs OK and reports some pretty horrible numbers when X starts (no WM). Enabling the tracer, and starting/stopping X, the system either locks up or latency goes in to a zombie state. The attached trace logs provide little information - Also included dmesg and kernel config. One more try please: we also need CONFIG_IPIPE_TRACE_MCOUNT. 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] x86_64 - Initial results.
Paul wrote: On Sunday 25 February 2007 10:02, Jan Kiszka wrote: Rather the CONFIG_IPIPE_TRACE feature, with the IRQs off tracking option set Please grab trace/frozen instead, enable verbose mode, and increase back_trace_points so that the reported latency is fully covered. See OK - Recompiled with the 1.04 patch for UP with the ipipe trace support. After cutting Xorg's configs to a minimum (vesa driver, no Glx/dri support), If you want to disable X acceleration, you should add : Option NoAccel in the Device section of your X configuration file. latency runs OK and reports some pretty horrible numbers when X starts (no WM). Enabling the tracer, and starting/stopping X, the system either locks up or latency goes in to a zombie state. The attached trace logs provide little information - Also included dmesg and kernel config. -- Gilles Chanteperdrix. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Rép. : Re: [Xenomai-core] rtdm, rtc and printk driver.
Nicolas BLANCHARD [EMAIL PROTECTED] 23/02/07 15:55 Jan Kiszka [EMAIL PROTECTED] 23.02 14:47 Nicolas BLANCHARD wrote: Hello, I've write a little rtdm driver to r/w RealTimeClock on rtc146818 chipset. /me not having done much with rtc (hmm, a lot of years back on PCs, I think): can this chip be found in normal PC hardware? Or is it only on specific embedded boards? (Means: can I actually play with your driver? :) ) Motorola 146818 circuit is a 6800 peripheral CMOS device, it's often used with processors 6800 and 8085. I think it's used on a lot of x86 board. First nice work Nicolas ! (he is my coworker) Time usage for us is really important in our field activity, and more important without too much drift. And this real-time driver let us to have direct access to the RTC values instead of the Linux system one that generally drift a lot per day...(it was already the same problem under RTLinux) And without a secondary mode switch... Nowadays, you will generally not find directly a 146818 chip or compatible (like the Dallas ones). Many CPUs (for example the SIS Vortex86 we use on our embedded cards) have integrated in themself, on a single chip, many antique PC peripherals like this RTC compatible 146818, a 8254 system timer, the dual 8259 interrupt controller. Also sometimes the serials 16550 UART are included !!! So yes, for sure on many computers you will be able to use it ! I also use this driver to write kernel message from user-space (printk). In attachment you can find an archive with the driver and an example of use (just code). to compil, you must change kernel sources directory (KERNELSOURCEDIR flag). It Based on code of Jan Kiszka found in http://www.captain.at/ I hope it could be interesting. All feedback are welcome. You will get it. Thanks for sharing your code! It seems normal to us to share some possible usefull stuff like this one, keeping the free software spirit! ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: Rép. : Re: [Xenomai-core] rtdm, rtc and printk driver.
Marc LE DOUARAIN wrote: Nicolas BLANCHARD [EMAIL PROTECTED] 23/02/07 15:55 Jan Kiszka [EMAIL PROTECTED] 23.02 14:47 Nicolas BLANCHARD wrote: Hello, I've write a little rtdm driver to r/w RealTimeClock on rtc146818 chipset. /me not having done much with rtc (hmm, a lot of years back on PCs, I think): can this chip be found in normal PC hardware? Or is it only on specific embedded boards? (Means: can I actually play with your driver? :) ) Motorola 146818 circuit is a 6800 peripheral CMOS device, it's often used with processors 6800 and 8085. I think it's used on a lot of x86 board. First nice work Nicolas ! (he is my coworker) Time usage for us is really important in our field activity, and more important without too much drift. And this real-time driver let us to have direct access to the RTC values instead of the Linux system one that generally drift a lot per day...(it was already the same problem under RTLinux) And without a secondary mode switch... So you need such an interface for time-stamping, or also for scheduling events based on a RTC-provided date? I had a short look at the driver, and it seems that there exist ideas to register an interrupt on the RTC (it's currently freed but never acquired). The long-term question for me is if there is a need to synchronise the system clock (or some skin timebase in future Xenomai versions) on an external sources like the RTC here. Not that I'm desperately locking for work, it's just good to know user requirements whenever further design decisions [on the time subsystem] have to be made. Nowadays, you will generally not find directly a 146818 chip or compatible (like the Dallas ones). Many CPUs (for example the SIS Vortex86 we use on our embedded cards) have integrated in themself, on a single chip, many antique PC peripherals like this RTC compatible 146818, a 8254 system timer, the dual 8259 interrupt controller. Also sometimes the serials 16550 UART are included !!! So yes, for sure on many computers you will be able to use it ! OK, thanks. I also use this driver to write kernel message from user-space (printk). In attachment you can find an archive with the driver and an example of use (just code). to compil, you must change kernel sources directory (KERNELSOURCEDIR flag). It Based on code of Jan Kiszka found in http://www.captain.at/ I hope it could be interesting. All feedback are welcome. You will get it. Thanks for sharing your code! It seems normal to us to share some possible usefull stuff like this one, keeping the free software spirit! Then you shall benefit from this: :) You may have a locking problem. Calling CMOS_READ/WRITE is not safe from Xenomai context (I wish we had that domain violation debugging feature already - classic scenario here). There is a locking mechanism embedded which is based on the assumption that it can protect itself from preemption via local_irq_save - an assumption that is not true from the Xenomai perspective. If there are no further RTC users in your running system, you should just do direct hardware access and your own locking around it. But CMOS_READ [1], e.g., is used in quite a few places in the kernel, one would have to check under which conditions to really play safe. Jan [1] http://lxr.free-electrons.com/ident?i=CMOS_READ signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] x86_64 - Initial results.
On Sunday 25 February 2007 16:03, Jan Kiszka wrote: The attached trace logs provide little information - Also included dmesg One more try please: we also need CONFIG_IPIPE_TRACE_MCOUNT. With both CONFIG_IPIPE_TRACE_MCOUNT and CONFIG_IPIPE_TRACE_VMALLOC enabled, the system auto-reboots as soon as the kernel starts to uncompress. Disabling the latter restores normal service. On Sunday 25 February 2007 16:09, Gilles Chanteperdrix wrote: Option NoAccel Results are still the same - Latency goes to pot and hangs as soon as X starts up. Quite likely the offending trace isn't getting logged.. Regards, Paul. [0.00] Linux version 2.6.19.3-xenomai ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #7 Sun Feb 25 17:58:53 GMT 2007 [0.00] Command line: root=/dev/sda2 ro splash=silent vga=788 [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 0009fc00 (usable) [0.00] BIOS-e820: 0009fc00 - 000a (reserved) [0.00] BIOS-e820: 000e4000 - 0010 (reserved) [0.00] BIOS-e820: 0010 - 1ffb (usable) [0.00] BIOS-e820: 1ffb - 1ffc (ACPI data) [0.00] BIOS-e820: 1ffc - 1fff (ACPI NVS) [0.00] BIOS-e820: 1fff - 2000 (reserved) [0.00] BIOS-e820: ff78 - 0001 (reserved) [0.00] Entering add_active_range(0, 0, 159) 0 entries of 256 used [0.00] Entering add_active_range(0, 256, 130992) 1 entries of 256 used [0.00] end_pfn_map = 1048576 [0.00] DMI 2.3 present. [0.00] ACPI: RSDP (v000 ACPIAM) @ 0x000fa810 [0.00] ACPI: RSDT (v001 A M I OEMRSDT 0x01000723 MSFT 0x0097) @ 0x1ffb [0.00] ACPI: FADT (v001 A M I OEMFACP 0x01000723 MSFT 0x0097) @ 0x1ffb0200 [0.00] ACPI: MADT (v001 A M I OEMAPIC 0x01000723 MSFT 0x0097) @ 0x1ffb0390 [0.00] ACPI: OEMB (v001 A M I OEMBIOS 0x01000723 MSFT 0x0097) @ 0x1ffc0040 [0.00] ACPI: DSDT (v001 A0277 A0277001 0x0001 MSFT 0x010d) @ 0x [0.00] Entering add_active_range(0, 0, 159) 0 entries of 256 used [0.00] Entering add_active_range(0, 256, 130992) 1 entries of 256 used [0.00] Zone PFN ranges: [0.00] DMA 0 - 4096 [0.00] DMA324096 - 1048576 [0.00] Normal1048576 - 1048576 [0.00] early_node_map[2] active PFN ranges [0.00] 0:0 - 159 [0.00] 0: 256 - 130992 [0.00] On node 0 totalpages: 130895 [0.00] DMA zone: 56 pages used for memmap [0.00] DMA zone: 1700 pages reserved [0.00] DMA zone: 2243 pages, LIFO batch:0 [0.00] DMA32 zone: 1734 pages used for memmap [0.00] DMA32 zone: 125162 pages, LIFO batch:31 [0.00] Normal zone: 0 pages used for memmap [0.00] ACPI: PM-Timer IO Port: 0x808 [0.00] ACPI: Local APIC address 0xfee0 [0.00] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) [0.00] Processor #0 (Bootup-CPU) [0.00] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) [0.00] Processor #1 [0.00] WARNING: NR_CPUS limit of 1 reached. Processor ignored. [0.00] ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) [0.00] IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23 [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [0.00] ACPI: IRQ0 used by override. [0.00] ACPI: IRQ2 used by override. [0.00] ACPI: IRQ9 used by override. [0.00] Setting APIC routing to flat [0.00] Using ACPI (MADT) for SMP configuration information [0.00] Nosave address range: 0009f000 - 000a [0.00] Nosave address range: 000a - 000e4000 [0.00] Nosave address range: 000e4000 - 0010 [0.00] Allocating PCI resources starting at 3000 (gap: 2000:df78) [0.00] Built 1 zonelists. Total pages: 127405 [0.00] Kernel command line: root=/dev/sda2 ro splash=silent vga=788 [0.00] Initializing CPU#0 [0.00] PID hash table entries: 2048 (order: 11, 16384 bytes) [ 28.777403] time.c: Using 3.579545 MHz WALL PM GTOD PIT/TSC timer. [ 28.777410] time.c: Detected 2403.177 MHz processor. [ 28.777485] I-pipe 1.0-04: pipeline enabled. [ 28.777553] Console: colour dummy device 80x25 [ 28.778250] Dentry cache hash table entries: 65536 (order: 7, 524288 bytes) [ 28.778657] Inode-cache hash table entries: 32768 (order: 6, 262144 bytes) [ 28.778737] Checking aperture... [ 28.778745] CPU 0: aperture @ f000 size 64 MB [ 28.786774] Memory: 502760k/523968k available
Re: [Xenomai-core] x86_64 - Initial results.
Paul wrote:
On Sunday 25 February 2007 16:03, Jan Kiszka wrote:
The attached trace logs provide little information - Also included dmesg
One more try please: we also need CONFIG_IPIPE_TRACE_MCOUNT.
With both CONFIG_IPIPE_TRACE_MCOUNT and CONFIG_IPIPE_TRACE_VMALLOC enabled,
the system auto-reboots as soon as the kernel starts to uncompress. Disabling
the latter restores normal service.
Are we still tracing too early during boot? Probably worth a qemu/gdb
session.
On Sunday 25 February 2007 16:09, Gilles Chanteperdrix wrote:
Option NoAccel
Results are still the same - Latency goes to pot and hangs as soon as X
starts
up. Quite likely the offending trace isn't getting logged..
...
I-pipe frozen back-tracing service on 2.6.19.3-xenomai/ipipe-1.0-04
Freeze: 434598593698 cycles, Trace Points: 30 (+100)
Calibrated minimum trace-point overhead: 0.037 us
+- Hard IRQs ('|': locked)
|+ unused
||+--- unused
|||+-- Xenomai
+- Linux ('*': domain stalled, '+': current, '#': current+stalled)
|+-- Delay flag ('+': 1 us, '!': 10
us)
||+- NMI noise ('N')
|||
TypeUser Val. TimeDelay Function (Parent)
:| +*func-244+ 6.981 __ipipe_handle_irq+0x21
(common_interrupt+0x78)
:| +*func-238+ 6.956 __ipipe_ack_apic+0x9
(__ipipe_handle_irq+0x87)
:| +*func-231+ 7.615 __ipipe_dispatch_wired+0xc
(__ipipe_handle_irq+0x91)
:| #*func-223+ 6.951 xnintr_clock_handler+0x9
(__ipipe_dispatch_wired+0x94)
:| #*func-216+ 7.210 xnintr_irq_handler+0x21
(xnintr_clock_handler+0x1b)
Given these *huge* latencies for that simple functions, we are may face
some CPU frequency screw (though scaling is switched off?). Something
must disturb the tsc-ns conversion. Maybe this is actually no latency
real issue...
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] x86_64 - Initial results.
On Sun, 2007-02-25 at 18:42 +, Paul wrote: Results are still the same - Latency goes to pot and hangs as soon as X starts up. Quite likely the offending trace isn't getting logged.. Just for the purpose of digging the issue further, does this particular problem persist when MTRRs are switched off from the kernel config? -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Kernel lockup with lapic on old AMD Athlon
On Sun, 2007-02-25 at 16:09 +0100, Wolfgang Grandegger wrote:
Gilles Chanteperdrix wrote:
Wolfgang Grandegger wrote:
Hello,
here is the boot log of an hangup of 2.6.20 with I-pipe 1.7-02 and
Xenomai todays trunk. I already reported this hangup a while ago but now
I get an oops. At that time Gilles said that lapic on old Athlons might
be buggy. Does the attached boot log confirm this assumption? 2.6.20-rt8
is working, BTW.
What I had observed with an old Athlon were some random lockups. I was
trying to setup a samba print server at the time, and the lockup always
occured when some windows machine was trying to use the shared printer
through network. I think the IO-APIC was also enabled. Then, at some
later time, I read somewhere on the internet that the IO-APIC or LAPIC
could be buggy on some Athlons, so I understood what had happened to
me. So, I did not investigate this issue any further.
I didn't either, especially because it works with lapic disabled in the
kernel config. I just thought that this oops might be useful to somebody.
Does the following help?
--- ksrc/arch/i386/hal.c(revision 2256)
+++ ksrc/arch/i386/hal.c(working copy)
@@ -119,23 +119,26 @@
}
}
-#if LINUX_VERSION_CODE KERNEL_VERSION(2,6,19)
-irqreturn_t rthal_broadcast_to_local_timers(int irq,
-void *dev_id, struct pt_regs *regs)
-#else /* = 2.6.19 */
-irqreturn_t rthal_broadcast_to_local_timers(int irq,
-void *dev_id)
-#endif
+#if LINUX_VERSION_CODE KERNEL_VERSION(2,5,0)
+#include asm/smpboot.h
+static inline void send_IPI_all(int vector)
{
-unsigned long flags;
+ unsigned long flags;
-rthal_local_irq_save_hw(flags);
-apic_wait_icr_idle();
-apic_write_around(APIC_ICR,
- APIC_DM_FIXED | APIC_DEST_ALLINC | LOCAL_TIMER_VECTOR);
-rthal_local_irq_restore_hw(flags);
+ rthal_local_irq_save_hw(flags);
+ apic_wait_icr_idle();
+ apic_write_around(APIC_ICR,
+ APIC_DM_FIXED | APIC_DEST_ALLINC | INT_DEST_ADDR_MODE
| LOCAL_TIMER_VECTOR);
+ rthal_local_irq_restore_hw(flags);
+}
+#else
+#include mach_ipi.h
+#endif
-return IRQ_HANDLED;
+DECLARE_LINUX_IRQ_HANDLER(rthal_broadcast_to_local_timers, irq, dev_id)
+{
+ send_IPI_all(LOCAL_TIMER_VECTOR);
+ return IRQ_HANDLED;
}
unsigned long rthal_timer_calibrate(void)
Index: include/asm-i386/wrappers.h
===
--- include/asm-i386/wrappers.h (revision 2256)
+++ include/asm-i386/wrappers.h (working copy)
@@ -131,12 +131,19 @@
void *dev_id,
struct pt_regs *regs);
+#define DECLARE_LINUX_IRQ_HANDLER(fn, irq, dev_id) \
+ irqreturn_t fn(int irq, void *dev_id, struct pt_regs *regs)
+
#define rthal_irq_chip_end(irq)rthal_irq_chip_enable(irq)
#else /* = 2.6.19 */
#define rthal_irq_chip_enable(irq) ({
rthal_irq_descp(irq)-chip-enable(irq); 0; })
#define rthal_irq_chip_disable(irq) ({
rthal_irq_descp(irq)-chip-disable(irq); 0; })
#define rthal_irq_chip_end(irq) ({ rthal_irq_descp(irq)-ipipe_end(irq,
rthal_irq_descp(irq)); 0; })
typedef irq_handler_t rthal_irq_host_handler_t;
+
+#define DECLARE_LINUX_IRQ_HANDLER(fn, irq, dev_id) \
+ irqreturn_t fn(int irq, void *dev_id)
+
#endif
#endif /* _XENO_ASM_I386_WRAPPERS_H */
--
Philippe.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] x86_64 - Initial results.
Hi Philippe
On Sunday 25 February 2007 22:00, Philippe Gerum wrote:
Results are still the same - Latency goes to pot and hangs as soon as X
starts up. Quite likely the offending trace isn't getting logged..
Just for the purpose of digging the issue further, does this particular
problem persist when MTRRs are switched off from the kernel config?
I'd just finished compiling yet another kernel with CONFIG_MTRR disabled and
was about to run another test..
Logs attached - Even with ipipe-trace enabled, latencies are acceptable when
firing up X/KDE..
Regards, Paul.
I-pipe frozen back-tracing service on 2.6.19.3-xenomai/ipipe-1.0-04
Freeze: 970774923862 cycles, Trace Points: 30 (+100)
Calibrated minimum trace-point overhead: 0.037 us
+- Hard IRQs ('|': locked)
|+ unused
||+--- unused
|||+-- Xenomai
+- Linux ('*': domain stalled, '+': current, '#': current+stalled)
|+-- Delay flag ('+': 1 us, '!': 10 us)
||+- NMI noise ('N')
|||
TypeUser Val. TimeDelay Function (Parent)
:| # func -30.067 xnpod_schedule+0x16
(xnintr_irq_handler+0x116)
:| # [ 3008] Xorg-1-30.231 xnpod_schedule+0xa8
(xnintr_irq_handler+0x116)
:| # func -20.343 __switch_to+0x16 (xnpod_schedule+0x80b)
:| # [ 2716] samplin 99-20.134 xnpod_schedule+0x848
(xnpod_suspend_thread+0x154)
:| # func -20.065 __ipipe_restore_pipeline_head+0x16
(xnpod_wait_thread_period+0x11e)
:| + end 0x8000-20.163 __ipipe_restore_pipeline_head+0xb1
(xnpod_wait_thread_period+0x11e)
:| + begin 0x8001-20.073 __ipipe_dispatch_event+0xe9
(__ipipe_syscall_root+0x8d)
:| + end 0x8001-20.088 __ipipe_dispatch_event+0x191
(__ipipe_syscall_root+0x8d)
:| + begin 0x8000-20.326 __ipipe_syscall_root+0x14b
(__ipipe_syscall_root_thunk+0x35)
: + func -10.076 __ipipe_syscall_root+0xc
(__ipipe_syscall_root_thunk+0x35)
: + func -10.071 __ipipe_dispatch_event+0x16
(__ipipe_syscall_root+0x8d)
:| + begin 0x8001-10.048 __ipipe_dispatch_event+0x37
(__ipipe_syscall_root+0x8d)
:| + end 0x8001-10.070 __ipipe_dispatch_event+0xb6
(__ipipe_syscall_root+0x8d)
: + func -10.098 hisyscall_event+0x21
(__ipipe_dispatch_event+0xc7)
: + func -10.077 __rt_timer_tsc2ns+0xe [xeno_native]
(hisyscall_event+0x1bb)
: + func -10.144 rt_timer_tsc2ns+0x9 [xeno_native]
(__rt_timer_tsc2ns+0x2c [xeno_native])
:| + begin 0x8001-10.072 __ipipe_dispatch_event+0xe9
(__ipipe_syscall_root+0x8d)
:| + end 0x8001-10.078 __ipipe_dispatch_event+0x191
(__ipipe_syscall_root+0x8d)
:| + begin 0x8000 00.139 __ipipe_syscall_root+0x14b
(__ipipe_syscall_root_thunk+0x35)
: + func 00.063 __ipipe_syscall_root+0xc
(__ipipe_syscall_root_thunk+0x35)
: + func 00.064 __ipipe_dispatch_event+0x16
(__ipipe_syscall_root+0x8d)
:| + begin 0x8001 00.056 __ipipe_dispatch_event+0x37
(__ipipe_syscall_root+0x8d)
:| + end 0x8001 00.061 __ipipe_dispatch_event+0xb6
(__ipipe_syscall_root+0x8d)
: + func 00.151 hisyscall_event+0x21
(__ipipe_dispatch_event+0xc7)
: + func 00.059 xnshadow_sys_trace+0x16
(hisyscall_event+0x1bb)
: + func 00.127 ipipe_trace_frozen_reset+0xa
(xnshadow_sys_trace+0x8a)
: + func 00.051 __ipipe_global_path_lock+0xa
(ipipe_trace_frozen_reset+0x14)
:| + begin 0x8001 00.120 __ipipe_global_path_lock+0x1c
(ipipe_trace_frozen_reset+0x14)
:| + end 0x8001 00.066 __ipipe_global_path_unlock+0x62
(ipipe_trace_frozen_reset+0x61)
+ freeze 0x543e 00.084 xnshadow_sys_trace+0x94
(hisyscall_event+0x1bb)
| + begin 0x8001 00.062 __ipipe_dispatch_event+0xe9
(__ipipe_syscall_root+0x8d)
| + end 0x8001 00.083 __ipipe_dispatch_event+0x191
(__ipipe_syscall_root+0x8d)
| + begin 0x8000 00.131 __ipipe_syscall_root+0x14b
(__ipipe_syscall_root_thunk+0x35)
+ func 00.066 __ipipe_syscall_root+0xc
(__ipipe_syscall_root_thunk+0x35)
+ func 00.064 __ipipe_dispatch_event+0x16
(__ipipe_syscall_root+0x8d)
| + begin 0x8001 00.057 __ipipe_dispatch_event+0x37
(__ipipe_syscall_root+0x8d)
| + end 0x8001 00.071 __ipipe_dispatch_event+0xb6
(__ipipe_syscall_root+0x8d)
+ func 00.083 hisyscall_event+0x21
(__ipipe_dispatch_event+0xc7)
+ func 00.048
