L4Linux stop at "Calibrating delay loop ..."
Hi，l4hackers I compiled the l4re-snapshot-2014092821 with the default modules.list, and everything seems goes well. However, L4Linux would stop at "Calibrating delay loop ...", because the value of jiffies did not change. Timer thread has not generate soft interrupt? If I entered jdb via ESC at this time, and quit via "g", then l4linux can run again. It makes me confused so much. Any help or suggestion will be very welcome. The log is showing below: L4 Bootstrapper Build: #12 2016年 09月 19日 星期一 18:58:15 CST, 4.8.3 20140320 (prerelease) Scanning up to 2048 MB RAM, starting at offset 32MB Memory size is 2048MB (00000000 - 7fffffff) RAM: 0000000000000000 - 000000007fffffff: 2097152kB Total RAM: 2048MB Scanning fiasco Scanning sigma0 Scanning moe Moving up to 10 modules behind 1100000 moving module 02 { 1968000-19a163f } -> { 1a58000-1a9163f } [235072] moving module 01 { 195e000-196738b } -> { 1a4e000-1a5738b } [37772] moving module 00 { 18f8000-195d9db } -> { 19e8000-1a4d9db } [416220] moving module 09 { 15f8000-18f7fff } -> { 16e8000-19e7fff } [3145728] moving module 08 { 11d6000-15f7497 } -> { 12c6000-16e7497 } [4330648] moving module 07 { 11d5000-11d50bc } -> { 12c5000-12c50bc } [189] moving module 06 { 107e000-11d446f } -> { 116e000-12c446f } [1401968] moving module 05 { 107d000-107d19b } -> { 116d000-116d19b } [412] moving module 04 { 102a000-107cc1f } -> { 111a000-116cc1f } [338976] moving module 03 { 1010000-1029473 } -> { 1100000-1119473 } [103540] Loading fiasco Loading sigma0 Loading moe find kernel info page... found kernel info page at 0x2000 Regions of list 'regions' [ 1000, 1aff] { b00} Kern fiasco [ 2000, 72fff] { 71000} Kern fiasco [ 73000, 7315f] { 160} Root mbi_rt [ 90000, 96edf] { 6ee0} Sigma0 sigma0 [ 98000, 9e177] { 6178} Sigma0 sigma0 [ 140000, 171d8f] { 31d90} Root moe [ 178000, 1934ab] { 1b4ac} Root moe [ 1000000, 100f58b] { f58c} Boot bootstrap [ 1100000, 19e7fff] { 8e8000} Root Module API Version: (87) experimental Sigma0 config ip:00090100 sp:00000000 Roottask config ip:00140260 sp:00000000 Starting kernel fiasco at 000012e0 Hello from Startup::stage2 Per_cpu_data_alloc: (orig: 0xf0061720-0xf00620e8) Number of IRQs available at this GIC: 128 FPU0: Arch: Unkn(2), Part: VFPv3(30), r: 5, v: 7, i: 41, t: hard, p: dbl/sngl ARM generic timer: freq=1000000 interval=1000 cnt=-262144 SERIAL ESC: allocated IRQ 89 for serial uart Not using serial hack in slow timer handler. Welcome to Fiasco.OC (arm)! L4/Fiasco.OC arm microkernel (C) 1998-2013 TU Dresden Rev: 8fd26ca-dirty compiled with gcc 4.8.3 for [] Build: #3 Mon Sep 19 18:55:38 CST 2016 Per_cpu_data_alloc: (orig: 0xf0061720-0xf00620e8) Allocate 2504 bytes (2KB) for CPU[4] local storage (offset=118a8e0, 0xf11ec000-0xf11ec9c8) cpu1: powered-up Per_cpu_data_alloc: (orig: 0xf0061720-0xf00620e8) cpu2: powered-up Allocate 2504 bytes (2KB) for CPU[1] local storage (offset=118c8e0, 0xf11ee000-0xf11ee9c8) cpu3: powered-up FPU1: Arch: Unkn(2), Part: VFPv3(30), r: 5, v: 7, i: 41, t: hard, p: dbl/sngl Calibrating timer loop... Per_cpu_data_alloc: (orig: 0xf0061720-0xf00620e8) done. Allocate 2504 bytes (2KB) for CPU[2] local storage (offset=118f8e0, 0xf11f1000-0xf11f19c8) Cache config: ON MDB: use page size: 30 FPU2: Arch: Unkn(2), Part: VFPv3(30), r: 5, v: 7, i: 41, t: hard, p: dbl/sngl ID_PFR[01]: 00001131 00011011Per_cpu_data_alloc: (orig: 0xf0061720-0xf00620e8) MDB: use page size: 21 Allocate 2504 bytes (2KB) for CPU[3] local storage (offset=11968e0, 0xf11f8000-0xf11f89c8) ID_[DA]FR0: 02010555 00000000 Cache config: ON MDB: use page size: 12 FPU3: Arch: Unkn(2), Part: VFPv3(30), r: 5, v: 7, i: 41, t: hard, p: dbl/sngl ID_PFR[01]: 00001131 00011011SID_MMFR[04]: 10101105 40000000 01240000 02102211 Cache config: ON ID_[DA]FR0: 02010555 00000000 ID_PFR[01]: 00001131 00011011ID_MMFR[04]: 10101105 40000000 01240000 02102211 ICPU[2]: goes to idle loop ID_[DA]FR0: 02010555 00000000 GID_MMFR[04]: 10101105 40000000 01240000 02102211 CPU[1]: goes to idle loop CPU[3]: goes to idle loop MA0: Hello! KIP @ 2000 allocated 4KB for maintenance structures SIGMA0: Dump of all resource maps RAM:------------------------ [0:0;fff] [4:73000;73fff] [0:74000;8ffff] [0:97000;97fff] [0:9f000;13ffff] [4:140000;171fff] [0:172000;177fff] [4:178000;193fff] [0:194000;10fffff] [4:1100000;19e7fff] [0:19e8000;3effffff] [0:40000000;7fffffff] IOMEM:---------------------- [0:80000000;ffffffff] MOE: Hello world MOE: found 2070816 KByte free memory MOE: found RAM from 73000 to 80000000 MOE: allocated 2047 KByte for the page array @0x194000 MOE: virtual user address space [0-bfffffff] MOE: rom name space cap -> [C:501000] BOOTFS: [1100000-1119474] [C:503000] l4re BOOTFS: [111a000-116cc20] [C:504000] ned BOOTFS: [116d000-116d19c] [C:505000] l4lx.cfg BOOTFS: [116e000-12c4470] [C:506000] io BOOTFS: [12c5000-12c50bd] [C:507000] arm-rv.io BOOTFS: [12c6000-16e7498] [C:508000] vmlinuz.arm BOOTFS: [16e8000-19e8000] [C:509000] ramdisk-arm.rd MOE: cmdline: moe rom/l4lx.cfg MOE: Starting: rom/ned rom/l4lx.cfg MOE: loading 'rom/ned' Ned says: Hi World! Ned: loading file: 'rom/l4lx.cfg' l4linux | libio: Warning: Query of 'vbus' failed! l4linux | PH 0 (t: 1) offs=00008000 vaddr=02000000 vend=024c8dd4 l4linux | phys= 02000000 ephys=024c8dd4 l4linux | f_sz= 00404594 memsz=004c8dd4 flgs=rwx l4linux | PH 1 (t: 4) offs=003b44e0 vaddr=023ac4e0 vend=023ac504 l4linux | phys= 023ac4e0 ephys=023ac504 l4linux | f_sz= 00000024 memsz=00000024 flgs=r-x l4linux | PH 2 (t: 1685382481) offs=00000000 vaddr=00000000 vend=00000000 l4linux | phys= 00000000 ephys=00000000 l4linux | f_sz= 00000000 memsz=00000000 flgs=rwx l4linux | Starting binary at 0x2000360, argc=8 argv=0xafff4f84 *argv=0xb1007ff0 argv0=rom/vmlinuz.arm l4linux | External resolver is at 0xa8000788 l4linux | ======> L4Linux starting... <======== l4linux | Linux version 3.16.0-l4 (li94575@li94575-Lenovo) (gcc version 4.8.3 20140320 (prerelease) (Sourcery CodeBench Lite 2014.05-29) ) #3 SMP Mon Sep 19 18:57:16 CST 2016 l4linux | Binary name: rom/vmlinuz.arm l4linux | This is an AEABI build. l4linux | Linux kernel command line (7 args): mem=64M l4x_cpus=4 l4x_cpus_map=0,1,2,3 console=ttyLv0 l4x_rd=rom/ramdisk-arm.rd root=1:0 ramdisk_size=4000 l4linux | CPU mapping (l:p)[4]: 0:0, 1:1, 2:2, 3:3 l4linux | Image: 020000a0 - 02600000 [6143 KiB]. l4linux | Areas: Text: 020000a0 - 023d6000 [3927kB] (a bit longer) l4linux | Data: 023d6000 - 023ff520 [165kB] l4linux | Initdata: 023ad000 - 023d57c0 [161kB] l4linux | BSS: 02404594 - 024c8dd4 [786kB] l4linux | Device scan: l4linux | Device scan done. l4linux | l4lx_thread_create: Created thread 413 (cpu0) (u:b3000e00, v:b3000c00, sp:023d7fa4) l4linux | main thread will be 413 l4linux | l4x_register_pointer_section: addr = 02000000 size = 5017600 l4linux | section-with-init: Virt: 0x2000000 to 0x24c8dd3 [4899 KiB] l4linux | section-with-init: Phys: 0x0042b000 to 0x008f3dd3, [4899 KiB] l4linux | Main thread running, waiting... l4linux | L4x: Memory size: 64MB l4linux | L4x: Setting superpages for main memory l4linux | L4x: Adjusted memory start: 02000000 l4linux | Main memory: Virt: 0x2600000 to 0x65fffff [65536 KiB] l4linux | Main memory: Phys: 0x01a00000 to 0x059fffff, [65536 KiB] l4linux | l4x: vmalloc area: 06600000 - 0e600000 l4linux | l4x_register_pointer_section: addr = 02000000 size = 5017600 l4linux | text: Virt: 0x2000000 to 0x24c8dd3 [4899 KiB] l4linux | text: Phys: 0x0042b000 to 0x008f3dd3, [4899 KiB] l4linux | Loading: rom/ramdisk-arm.rd l4linux | INITRD: Size of RAMdisk is 3072KiB l4linux | RAMdisk from 00002000 to 00302000 [3072KiB] l4linux | l4lx_thread_create: Created thread 419 (timer0) (u:b3000a00, v:00000000, sp:0245dfa0) Booting Linux on physical CPU 0x0 Linux version 3.16.0-l4 (li94575@li94575-Lenovo) (gcc version 4.8.3 20140320 (prerelease) (Sourcery CodeBench Lite 2014.05-29) ) #3 SMP Mon Sep 19 18:57:16 CST 2016 CPU: Fiasco [410fc075] revision 5 (ARMv7), cr=00000000 CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache Machine: L4 Ignoring unrecognised tag 0x00000000 Forcing write-allocate cache policy for SMP Forcing shared mappings for SMP Memory policy: Data cache writealloc INITRD: 00002000 - 00302000 PERCPU: Embedded 5 pages/cpu @06509000 s6080 r0 d14400 u32768 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 17716 Kernel command line: mem=64M l4x_cpus=4 l4x_cpus_map=0,1,2,3 console=ttyLv0 l4x_rd=rom/ramdisk-arm.rd root=1:0 ramdisk_size=4000 PID hash table entries: 512 (order: -1, 2048 bytes) Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) Memory: 64728K/71680K available (3157K kernel code, 165K rwdata, 604K rodata, 161K init, 786K bss, 6952K reserved) Virtual kernel memory layout: vector : 0xbffff000 - 0xc0000000 ( 4 kB) fixmap : 0xffc00000 - 0xffe00000 (2048 kB) vmalloc : 0x06600000 - 0x0e600000 ( 128 MB) lowmem : 0x00000000 - 0x06600000 ( 102 MB) .text : Virtual kernel memory layout: vector : 0xbffff000 - 0xc0000000 ( 4 kB) fixmap : 0xffc00000 - 0xffe00000 (2048 kB) vmalloc : 0x06600000 - 0x0e600000 ( 128 MB) loHierarchical RCU implementation. NR_IRQS:220 l4timer: Using IRQ210 sched_clock: 64 bits at 1000kHz, resolution 1000ns, wraps every 2147483648000ns Console: colour dummy device 80x30 console [ttyLv0] enabled Calibrating delay loop...
Hi, On Mon Sep 19, 2016 at 22:55:52 +0800, li94575 wrote:
I compiled the l4re-snapshot-2014092821 with the default modules.list, and everything seems goes well. However, L4Linux would stop at "Calibrating delay loop ...", because the value of jiffies did not change. Timer thread has not generate soft interrupt? If I entered jdb via ESC at this time, and quit via "g", then l4linux can run again. It makes me confused so much. Any help or suggestion will be very welcome.
This behavior typically indicates that there's an issue with Fiasco's timer interrupt or with the user-level one in L4Linux. For a start you could add e.g. a printk(".\n") in timer_thread in arch/l4/kernel/timer.c to see if it really does something. Does 'hello' work? Although it's a bit of work you could also compare the code of your snapshot and a recent one if there's any significant change (i.e. fix) that might be relevant. Check arch/l4/kernel/timer.c and src/kern/arm/timer-arm-generic.cpp and src/kern/arm/generic_timer.cpp in the Fiasco kernel. Adam -- Adam adam@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/
Hi, adam
On Mon Sep 19, 2016 at 22:55:52 +0800, li94575 wrote:
I compiled the l4re-snapshot-2014092821 with the default modules.list, and everything seems goes well. However, L4Linux would stop at "Calibrating delay loop ...", because the value of jiffies did not change. Timer thread has not generate soft interrupt? If I entered jdb via ESC at this time, and quit via "g", then l4linux can run again. It makes me confused so much. Any help or suggestion will be very welcome.
This behavior typically indicates that there's an issue with Fiasco's timer interrupt or with the user-level one in L4Linux. For a start you could add e.g. a printk(".\n") in timer_thread in arch/l4/kernel/timer.c to see if it really does something. Does 'hello' work? Although it's a bit of work you could also compare the code of your snapshot and a recent one if there's any significant change (i.e. fix) that might be relevant. Check arch/l4/kernel/timer.c and src/kern/arm/timer-arm-generic.cpp and src/kern/arm/generic_timer.cpp in the Fiasco kernel.'Hello' can work well, which prints "Hello World!" circularly. I add printk(".\n") in timer_thread inarch/l4/kernel/timer.c, and found timer_thread stop at l4_ipc_reply_and_wait(u, t, &l, to) afterinitializing the variable ‘increment’. However, if I use LOG_printf() for printing, the phenomenon is different, that timer_thread trigers a soft interrupt once. I have checked src/kern/arm/timer-arm-generic.cpp and src/kern/arm/generic_timer.cpp in the Fiasco kernel, there is less likely to be a problem with them.
Hi We had a similar problem working with Fiasco.OC and GendodeOS on ODROID-X2 (Exynos4412) platform. In this case after the review of GenodeOS and Fiasco.OC, we identified a small problem in the TrustZone implementation, where interrupts remain disabled. Perhaps this is not the same problem but it can help. https://github.com/ssumpf/foc/issues/13 Best regards On 09/22/2016 10:32 AM, li94575 wrote:
Hi, adam
On Mon Sep 19, 2016 at 22:55:52 +0800, li94575 wrote:
I compiled the l4re-snapshot-2014092821 with the default modules.list, and everything seems goes well. However, L4Linux would stop at "Calibrating delay loop ...", because the value of jiffies did not change. Timer thread has not generate soft interrupt? If I entered jdb via ESC at this time, and quit via "g", then l4linux can run again. It makes me confused so much. Any help or suggestion will be very welcome.
This behavior typically indicates that there's an issue with Fiasco's timer interrupt or with the user-level one in L4Linux. For a start you could add e.g. a printk(".\n") in timer_thread in arch/l4/kernel/timer.c to see if it really does something. Does 'hello' work? Although it's a bit of work you could also compare the code of your snapshot and a recent one if there's any significant change (i.e. fix) that might be relevant. Check arch/l4/kernel/timer.c and src/kern/arm/timer-arm-generic.cpp and src/kern/arm/generic_timer.cpp in the Fiasco kernel. 'Hello' can work well, which prints "Hello World!" circularly. I add printk(".\n") in timer_thread in arch/l4/kernel/timer.c, and found timer_thread stop at l4_ipc_reply_and_wait(u, t, &l, to) after initializing the variable ‘increment’. However, if I use LOG_printf() for printing, the phenomenon is different, that timer_thread trigers a soft interrupt once. I have checked src/kern/arm/timer-arm-generic.cpp and src/kern/arm/generic_timer.cpp in the Fiasco kernel, there is less likely to be a problem with them.
_______________________________________________ l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
-- MsC. Reinier Millo Sánchez Centro de Estudios de Informática Universidad Central "Marta Abreu" de Las Villas Carretera a Camajuaní Km 5 1/2 Santa Clara, Villa Clara, Cuba CP 54830 "antes de discutir ... respira; antes de hablar ... escucha; antes de escribir ... piensa; antes de herir ... siente; antes de rendirte ... intenta; antes de morir ... vive"
On Thu Sep 22, 2016 at 22:32:28 +0800, li94575 wrote:
Hi, adam
On Mon Sep 19, 2016 at 22:55:52 +0800, li94575 wrote:
I compiled the l4re-snapshot-2014092821 with the default modules.list, and everything seems goes well. However, L4Linux would stop at "Calibrating delay loop ...", because the value of jiffies did not change. Timer thread has not generate soft interrupt? If I entered jdb via ESC at this time, and quit via "g", then l4linux can run again. It makes me confused so much. Any help or suggestion will be very welcome.
This behavior typically indicates that there's an issue with Fiasco's timer interrupt or with the user-level one in L4Linux. For a start you could add e.g. a printk(".\n") in timer_thread in arch/l4/kernel/timer.c to see if it really does something. Does 'hello' work? Although it's a bit of work you could also compare the code of your snapshot and a recent one if there's any significant change (i.e. fix) that might be relevant. Check arch/l4/kernel/timer.c and src/kern/arm/timer-arm-generic.cpp and src/kern/arm/generic_timer.cpp in the Fiasco kernel.
'Hello' can work well, which prints "Hello World!" circularly. I add printk(".\n") in timer_thread in arch/l4/kernel/timer.c, and found timer_thread stop at l4_ipc_reply_and_wait(u, t, &l, to) afterinitializing the variable ¡®increment¡¯.
printk and any other Linux functionaliy cannot be used in this function because the timer_thread isn't run in a Linux context. It's run in an L4 thread next to Linux. (Sorry for my mistake of writing printk above, I actually really meant to write LOG_printf.)
However, if I use LOG_printf() for printing, the phenomenon is different, that timer_thread trigers a soft interrupt once. I have checked src/kern/arm/timer-arm-generic.cpp and src/kern/arm/generic_timer.cpp in the Fiasco kernel, there is less likely to be a problem with them.
So there's still a problem somewhere. Do you think you could try with a more recent L4Re version? I remember vaguely that I might have already seen this behavior but this would be long ago. Adam -- Adam adam@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/
At 2016-09-23 05:31:52, "Adam Lackorzynski" <adam@os.inf.tu-dresden.de> wrote:
On Thu Sep 22, 2016 at 22:32:28 +0800, li94575 wrote:
Hi, adam
On Mon Sep 19, 2016 at 22:55:52 +0800, li94575 wrote:
I compiled the l4re-snapshot-2014092821 with the default modules.list, and everything seems goes well. However, L4Linux would stop at "Calibrating delay loop ...", because the value of jiffies did not change. Timer thread has not generate soft interrupt? If I entered jdb via ESC at this time, and quit via "g", then l4linux can run again. It makes me confused so much. Any help or suggestion will be very welcome.
This behavior typically indicates that there's an issue with Fiasco's timer interrupt or with the user-level one in L4Linux. For a start you could add e.g. a printk(".\n") in timer_thread in arch/l4/kernel/timer.c to see if it really does something. Does 'hello' work? Although it's a bit of work you could also compare the code of your snapshot and a recent one if there's any significant change (i.e. fix) that might be relevant. Check arch/l4/kernel/timer.c and src/kern/arm/timer-arm-generic.cpp and src/kern/arm/generic_timer.cpp in the Fiasco kernel.
'Hello' can work well, which prints "Hello World!" circularly. I add printk(".\n") in timer_thread in arch/l4/kernel/timer.c, and found timer_thread stop at l4_ipc_reply_and_wait(u, t, &l, to) afterinitializing the variable ¡®increment¡¯.
printk and any other Linux functionaliy cannot be used in this function because the timer_thread isn't run in a Linux context. It's run in an L4 thread next to Linux. (Sorry for my mistake of writing printk above, I actually really meant to write LOG_printf.)
However, if I use LOG_printf() for printing, the phenomenon is different, that timer_thread trigers a soft interrupt once. I have checked src/kern/arm/timer-arm-generic.cpp and src/kern/arm/generic_timer.cpp in the Fiasco kernel, there is less likely to be a problem with them.
So there's still a problem somewhere. Do you think you could try with a more recent L4Re version? I remember vaguely that I might have already seen this behavior but this would be long ago.
I have to admit that there may be a problem with the configuration of the generic timer, but I donot know where the problem. Before this, the generic timer can run well with fiasco.oc-r56+genode+l4linux3.9, I do not make any changes and move the bsp codefor this newer fiasco version.I replace generic timer with Aptimer, then l4linux can run well. So, If I want to assign anAptimer for each CPU, is there any ready-made case for reference?
On Fri Sep 30, 2016 at 22:06:47 +0800, li94575 wrote:
At 2016-09-23 05:31:52, "Adam Lackorzynski" <adam@os.inf.tu-dresden.de> wrote:
On Thu Sep 22, 2016 at 22:32:28 +0800, li94575 wrote:
Hi, adam
On Mon Sep 19, 2016 at 22:55:52 +0800, li94575 wrote:
I compiled the l4re-snapshot-2014092821 with the default modules.list, and everything seems goes well. However, L4Linux would stop at "Calibrating delay loop ...", because the value of jiffies did not change. Timer thread has not generate soft interrupt? If I entered jdb via ESC at this time, and quit via "g", then l4linux can run again. It makes me confused so much. Any help or suggestion will be very welcome.
This behavior typically indicates that there's an issue with Fiasco's timer interrupt or with the user-level one in L4Linux. For a start you could add e.g. a printk(".\n") in timer_thread in arch/l4/kernel/timer.c to see if it really does something. Does 'hello' work? Although it's a bit of work you could also compare the code of your snapshot and a recent one if there's any significant change (i.e. fix) that might be relevant. Check arch/l4/kernel/timer.c and src/kern/arm/timer-arm-generic.cpp and src/kern/arm/generic_timer.cpp in the Fiasco kernel.
'Hello' can work well, which prints "Hello World!" circularly. I add printk(".\n") in timer_thread in arch/l4/kernel/timer.c, and found timer_thread stop at l4_ipc_reply_and_wait(u, t, &l, to) afterinitializing the variable ¡®increment¡¯.
printk and any other Linux functionaliy cannot be used in this function because the timer_thread isn't run in a Linux context. It's run in an L4 thread next to Linux. (Sorry for my mistake of writing printk above, I actually really meant to write LOG_printf.)
However, if I use LOG_printf() for printing, the phenomenon is different, that timer_thread trigers a soft interrupt once. I have checked src/kern/arm/timer-arm-generic.cpp and src/kern/arm/generic_timer.cpp in the Fiasco kernel, there is less likely to be a problem with them.
So there's still a problem somewhere. Do you think you could try with a more recent L4Re version? I remember vaguely that I might have already seen this behavior but this would be long ago.
I have to admit that there may be a problem with the configuration of the generic timer, but I donot know where the problem. Before this, the generic timer can run well with fiasco.oc-r56+genode+l4linux3.9, I do not make any changes and move the bsp codefor this newer fiasco version.I replace generic timer with Aptimer, then l4linux can run well. So, If I want to assign anAptimer for each CPU, is there any ready-made case for reference?
Do you have others timers for each CPU? Maybe better (as easier), use one timer and distribute the timer tick to other CPUs: There's a timer_tick-broadcast and it is used in 3 BSPs. Does this help? Adam -- Adam adam@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/
At 2016-10-04 05:48:21, "Adam Lackorzynski" <adam@os.inf.tu-dresden.de> wrote:
On Fri Sep 30, 2016 at 22:06:47 +0800, li94575 wrote:
At 2016-09-23 05:31:52, "Adam Lackorzynski" <adam@os.inf.tu-dresden.de> wrote:
On Thu Sep 22, 2016 at 22:32:28 +0800, li94575 wrote:
Hi, adam
On Mon Sep 19, 2016 at 22:55:52 +0800, li94575 wrote:
I compiled the l4re-snapshot-2014092821 with the default modules.list, and everything seems goes well. However, L4Linux would stop at "Calibrating delay loop ...", because the value of jiffies did not change. Timer thread has not generate soft interrupt? If I entered jdb via ESC at this time, and quit via "g", then l4linux can run again. It makes me confused so much. Any help or suggestion will be very welcome.
This behavior typically indicates that there's an issue with Fiasco's timer interrupt or with the user-level one in L4Linux. For a start you could add e.g. a printk(".\n") in timer_thread in arch/l4/kernel/timer.c to see if it really does something. Does 'hello' work? Although it's a bit of work you could also compare the code of your snapshot and a recent one if there's any significant change (i.e. fix) that might be relevant. Check arch/l4/kernel/timer.c and src/kern/arm/timer-arm-generic.cpp and src/kern/arm/generic_timer.cpp in the Fiasco kernel.
'Hello' can work well, which prints "Hello World!" circularly. I add printk(".\n") in timer_thread in arch/l4/kernel/timer.c, and found timer_thread stop at l4_ipc_reply_and_wait(u, t, &l, to) afterinitializing the variable ¡®increment¡¯.
printk and any other Linux functionaliy cannot be used in this function because the timer_thread isn't run in a Linux context. It's run in an L4 thread next to Linux. (Sorry for my mistake of writing printk above, I actually really meant to write LOG_printf.)
However, if I use LOG_printf() for printing, the phenomenon is different, that timer_thread trigers a soft interrupt once. I have checked src/kern/arm/timer-arm-generic.cpp and src/kern/arm/generic_timer.cpp in the Fiasco kernel, there is less likely to be a problem with them.
So there's still a problem somewhere. Do you think you could try with a more recent L4Re version? I remember vaguely that I might have already seen this behavior but this would be long ago.
I have to admit that there may be a problem with the configuration of the generic timer, but I donot know where the problem. Before this, the generic timer can run well with fiasco.oc-r56+genode+l4linux3.9, I do not make any changes and move the bsp codefor this newer fiasco version.I replace generic timer with Aptimer, then l4linux can run well. So, If I want to assign anAptimer for each CPU, is there any ready-made case for reference?
Do you have others timers for each CPU? Maybe better (as easier), use one timer and distribute the timer tick to other CPUs: There's a timer_tick-broadcast and it is used in 3 BSPs. Does this help?
Yes , that solved my problem. Thank you so much!
participants (3)
-
Adam Lackorzynski -
li94575 -
Reinier Millo Sánchez