Re: covoar SIGKILL Investigation
On 15/08/2018 19:13, Chris Johns wrote: > On 15/8/18 2:47 am, Joel Sherrill wrote: >> >> Ideas appreciated on how to debug this enough to find >> the cause. >> > > Does the attached patch help? > I have pushed this patch. I tested it on more than 500 executables on FreeBSD and the process was not killed. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] user: Update x86-64 chapter with end-of-GSoC status
This should be committed now. Thanks. On Mon, Aug 20, 2018 at 9:27 AM, Amaan Cheval wrote: > --- > user/bsps/bsps-x86_64.rst | 52 ++- > 1 file changed, 51 insertions(+), 1 deletion(-) > > diff --git a/user/bsps/bsps-x86_64.rst b/user/bsps/bsps-x86_64.rst > index 19c4461..c13f369 100644 > --- a/user/bsps/bsps-x86_64.rst > +++ b/user/bsps/bsps-x86_64.rst > @@ -136,10 +136,60 @@ After rebooting, the RTEMS kernel should run after > the UEFI firmware and > FreeBSD's bootloader. The ``-serial stdio`` QEMU flag will let the RTEMS > console > send its output to the host's ``stdio`` stream. > > +Paging > +-- > + > +During the BSP's initialization, the paging tables are setup to > identity-map the > +first 512GiB, i.e. virtual addresses are the same as physical addresses > for the > +first 512GiB. > + > +The page structures are set up statically with 1GiB super-pages. > + > +.. note:: > + Page-faults are not handled. > + > +.. warning:: > + RAM size is not detected dynamically and defaults to 1GiB, if the > + configuration-time ``RamSize`` parameter is not used. > + > +Interrupt Setup > +--- > + > +Interrupt vectors ``0`` through ``32`` (i.e. 33 interrupt vectors in > total) are > +setup as "RTEMS interrupts", which can be hooked through > +``rtems_interrupt_handler_install``. > + > +The Interrupt Descriptor Table supports a total of 256 possible vectors (0 > +through 255), which leaves a lot of room for "raw interrupts", which can > be > +hooked through ``_CPU_ISR_install_raw_handler``. > + > +Since the APIC needs to be used for the clock driver, the PIC is remapped > (IRQ0 > +of the PIC is redirected to vector 32, and so on), and then all > interrupts are > +masked to disable the PIC. In this state, the PIC may _still_ produce > spurious > +interrupts (IRQ7 and IRQ15, redirected to vector 39 and vector 47 > respectively). > + > +The clock driver triggers the initialization of the APIC and then the APIC > +timer. > + > +The I/O APIC is not supported at the moment. > + > +.. note:: > + IRQ32 is reserved by default for the APIC timer (see following section). > + > + IRQ255 is reserved by default for the APIC's spurious vector. > + > +.. warning:: > + Besides the first 33 vectors (0 through 32), and vector 255 (the APIC > spurious > + vector), no other handlers are attached by default. > + > Clock Driver > > > -The clock driver currently uses the idle thread clock driver. > +The clock driver currently uses the APIC timer. Since the APIC timer runs > at the > +CPU bus frequency, which can't be detected easily, the PIT is used to > calibrate > +the APIC timer, and then the APIC timer is enabled in periodic mode, with > the > +initial counter setup such that interrupts fire at the same frequency as > the > +clock tick frequency, as requested by ``CONFIGURE_MICROSECONDS_PER_ > TICK``. > > Console Driver > -- > -- > 2.18.0 > > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] user: Update x86-64 chapter with end-of-GSoC status
--- user/bsps/bsps-x86_64.rst | 52 ++- 1 file changed, 51 insertions(+), 1 deletion(-) diff --git a/user/bsps/bsps-x86_64.rst b/user/bsps/bsps-x86_64.rst index 19c4461..c13f369 100644 --- a/user/bsps/bsps-x86_64.rst +++ b/user/bsps/bsps-x86_64.rst @@ -136,10 +136,60 @@ After rebooting, the RTEMS kernel should run after the UEFI firmware and FreeBSD's bootloader. The ``-serial stdio`` QEMU flag will let the RTEMS console send its output to the host's ``stdio`` stream. +Paging +-- + +During the BSP's initialization, the paging tables are setup to identity-map the +first 512GiB, i.e. virtual addresses are the same as physical addresses for the +first 512GiB. + +The page structures are set up statically with 1GiB super-pages. + +.. note:: + Page-faults are not handled. + +.. warning:: + RAM size is not detected dynamically and defaults to 1GiB, if the + configuration-time ``RamSize`` parameter is not used. + +Interrupt Setup +--- + +Interrupt vectors ``0`` through ``32`` (i.e. 33 interrupt vectors in total) are +setup as "RTEMS interrupts", which can be hooked through +``rtems_interrupt_handler_install``. + +The Interrupt Descriptor Table supports a total of 256 possible vectors (0 +through 255), which leaves a lot of room for "raw interrupts", which can be +hooked through ``_CPU_ISR_install_raw_handler``. + +Since the APIC needs to be used for the clock driver, the PIC is remapped (IRQ0 +of the PIC is redirected to vector 32, and so on), and then all interrupts are +masked to disable the PIC. In this state, the PIC may _still_ produce spurious +interrupts (IRQ7 and IRQ15, redirected to vector 39 and vector 47 respectively). + +The clock driver triggers the initialization of the APIC and then the APIC +timer. + +The I/O APIC is not supported at the moment. + +.. note:: + IRQ32 is reserved by default for the APIC timer (see following section). + + IRQ255 is reserved by default for the APIC's spurious vector. + +.. warning:: + Besides the first 33 vectors (0 through 32), and vector 255 (the APIC spurious + vector), no other handlers are attached by default. + Clock Driver -The clock driver currently uses the idle thread clock driver. +The clock driver currently uses the APIC timer. Since the APIC timer runs at the +CPU bus frequency, which can't be detected easily, the PIT is used to calibrate +the APIC timer, and then the APIC timer is enabled in periodic mode, with the +initial counter setup such that interrupts fire at the same frequency as the +clock tick frequency, as requested by ``CONFIGURE_MICROSECONDS_PER_TICK``. Console Driver -- -- 2.18.0 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Disable old network stack for x86_64
On 14/08/18 01:21, Joel Sherrill wrote: This is a new port and I don't see any reason to even pretend that the old stack is an option. How do you all feel about forcing libnetworking to disabled on this port? The old network stack doesn't work on 64-bit targets. I spent roughly one day to fix/understand the problems and gave up afterwards. The new networks stack works fine on 64-bit targets (which is the default FreeBSD environment). -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] cpu-supplement: Remove empty index
On 20/08/2018 16:12, Sebastian Huber wrote: > On 13/08/18 02:01, Chris Johns wrote: >>> On 10 Aug 2018, at 5:39 pm, Sebastian Huber >>> wrote: >>> >>> Due to the hierarchical structure an index is not absolutely necessary >>> and an empty index is not helpful. >> Are there index entries in the doc source that are not being processed? If >> so >> the bug is in the generation and removing this entry may not be a solution. >> >> I did want to support indexes when the doc source was ported. HTML may not >> need them but does PDF benefit? > > grep -r -l 'index::' c-user/ cpu-supplement/ > c-user/dual_ports_memory_manager.rst > c-user/scheduling_concepts.rst > c-user/object_services.rst > c-user/constant_bandwidth_server.rst > c-user/timespec_helpers.rst > c-user/key_concepts.rst > c-user/barrier_manager.rst > c-user/symmetric_multiprocessing_services.rst > c-user/multiprocessing.rst > c-user/stack_bounds_checker.rst > c-user/red_black_trees.rst > c-user/configuring_a_system.rst > c-user/ada_support.rst > c-user/timer_manager.rst > c-user/message_manager.rst > c-user/board_support_packages.rst > c-user/directive_status_codes.rst > c-user/rtems_data_types.rst > c-user/fatal_error.rst > c-user/task_manager.rst > c-user/chains.rst > c-user/overview.rst > c-user/region_manager.rst > c-user/linker_sets.rst > c-user/clock_manager.rst > c-user/rate_monotonic_manager.rst > c-user/pci_library.rst > c-user/semaphore_manager.rst > c-user/interrupt_manager.rst > c-user/signal_manager.rst > c-user/partition_manager.rst > c-user/initialization.rst > c-user/user_extensions.rst > c-user/io_manager.rst > c-user/event_manager.rst > c-user/cpu_usage_statistics.rst > > It seems the CPU Supplement doesn't contain index directives. > OK, lets remove the index so it is clear there is no index in the document. how does that sound? > The RTEMS Classic API Guide contains index directives, however, the index > chapter is empty in the PDF > > https://docs.rtems.org/branches/master/c-user.pdf > > and non-empty in the HTML > > https://docs.rtems.org/branches/master/c-user/genindex.html > Thanks for this. I will need to take a look and figure this out. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] cpu-supplement: Remove empty index
On 13/08/18 02:01, Chris Johns wrote: On 10 Aug 2018, at 5:39 pm, Sebastian Huber wrote: Due to the hierarchical structure an index is not absolutely necessary and an empty index is not helpful. Are there index entries in the doc source that are not being processed? If so the bug is in the generation and removing this entry may not be a solution. I did want to support indexes when the doc source was ported. HTML may not need them but does PDF benefit? grep -r -l 'index::' c-user/ cpu-supplement/ c-user/dual_ports_memory_manager.rst c-user/scheduling_concepts.rst c-user/object_services.rst c-user/constant_bandwidth_server.rst c-user/timespec_helpers.rst c-user/key_concepts.rst c-user/barrier_manager.rst c-user/symmetric_multiprocessing_services.rst c-user/multiprocessing.rst c-user/stack_bounds_checker.rst c-user/red_black_trees.rst c-user/configuring_a_system.rst c-user/ada_support.rst c-user/timer_manager.rst c-user/message_manager.rst c-user/board_support_packages.rst c-user/directive_status_codes.rst c-user/rtems_data_types.rst c-user/fatal_error.rst c-user/task_manager.rst c-user/chains.rst c-user/overview.rst c-user/region_manager.rst c-user/linker_sets.rst c-user/clock_manager.rst c-user/rate_monotonic_manager.rst c-user/pci_library.rst c-user/semaphore_manager.rst c-user/interrupt_manager.rst c-user/signal_manager.rst c-user/partition_manager.rst c-user/initialization.rst c-user/user_extensions.rst c-user/io_manager.rst c-user/event_manager.rst c-user/cpu_usage_statistics.rst It seems the CPU Supplement doesn't contain index directives. The RTEMS Classic API Guide contains index directives, however, the index chapter is empty in the PDF https://docs.rtems.org/branches/master/c-user.pdf and non-empty in the HTML https://docs.rtems.org/branches/master/c-user/genindex.html -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
