Version 3 (modified by Chris Johns, on 03/23/17 at 04:14:07) (diff) |
---|
4.11.2 (open)
Statistics
Total | 47 |
Fixed | 39 |
Invalid | 1 |
Works for me | 0 |
Duplicate | 1 |
Won't fix | 6 |
Distribution
defect |
40 / 40 |
|
---|---|---|
enhancement |
4 / 4 |
|
infra |
3 / 3 |
Summary
- #1523
- gethostbyname is not reenterant.
- #2002
- ioctl recursive perimeter lock driver deadlock vulnerability
- #2058
- RPC library audit required
- #2324
- Documentation and quick start for the RSB
- #2388
- [PATCH] [NFS client] Remove old CVS keywords
- #2401
- ARMv7M: Default exception handler doesn't support FPU
- #2479
- RTEMS Source Builder gets wrong version of rtems-tools for rtems4-11.
- #2499
- RSB 4.11 broken on FreeBSD 10 with default prefix.
- #2622
- FAT file corruption when pre-empted while appending to a file
- #2670
- epiphany tools fail to build on 4.11
- #2708
- 【rtems-bsp shell script does not list the available BSPS】
- #2755
- FAT mkdir() broken
- #2758
- SDCard driver for QoriQ
- #2815
- Add Preferred waf to top of various repositories
- #2827
- rtems-bsps broken on 4.11 branch
- #2886
- RTEMS version is wrong on 4.11 branch
- #2907
- BSP Script v4.11 Fix
- #2908
- FAT filename comparison is broken
- #2913
- RTEMS FAT32 formatter does not set the not dirty and no IO error bits
- #2914
- termios: Race condition in raw input buffer handling
- #2915
- termios: Potential infinite loop in canonical mode
- #2928
- FAT filename comparision is broken while using the UTF-8 support
- #2929
- FAT long file names accross cluster boundaries may be broken
- #2934
- FAT long file name padding is broken
- #2936
- Deadlock in filesystem location management
- #2937
- FAT race condition msdos_dir_read()
- #2939
- FAT file name search may not consider long file names
- #2940
- rtems-docs output and catalogue.xml verison numbering is wrong.
- #2947
- FreeBSD 11.0 check warnings for makeinfo and install-info
- #2948
- ARM: Optimize IEEE-754 sqrt implementation
- #2950
- doxygen does not install on sync.rtems.org
- #2952
- Support a release candidates residing in an `rc` directory.
- #2953
- Change Trac time format to absolute.
- #2955
- Backport libdl fixes to the 4.11 branch.
- #2956
- Backport rtems-tester qemu console fix.
- #2989
- doxygen crashes on sync.rtems.org
- #2996
- source download for RTEMS 4.11.2-rc1 Release
- #3002
- Incorrect bit reference in ARM GIC
- #3005
- Typo in RTEMS Source Builder 4.11.99
- #3030
- lm32-rtems4.11-gdb does not build on Windows.
- #3033
- MIPS does not build on FreeBSD
- #3035
- 4.11/rtems-moxie does not build.
- #3042
- 4.11/rtems-bfin does not build on Windows
- #3044
- 4.11/rtems-h8300 does not build on Windows.
- #3045
- 4.11/rtems-h8300 does not build on Windows
- #3060
- ARMv7-M interrupt processing is broken
- #3064
- RSB does not handle the `--rsb-file` option named sources with releases.
Details
Ticket | Resolution | Component | Reporter | Owner |
---|---|---|---|---|
#1523 | wontfix | network/legacy | ||
Summary |
gethostbyname is not reenterant. |
|||
Description |
The gethostbyname call uses global static data and therefore is not reenterant. |
|||
#2002 | wontfix | network/legacy | ||
Summary |
ioctl recursive perimeter lock driver deadlock vulnerability |
|||
Description |
In summary, a generalized deadlock potential exists any time rtems_bsdnet_ioctl calls rtems_bsdnet_ifconfig which calls the driver, and the driver tries to release the bsd networking semaphore, but the lock count doesn't decrement to zero, so the lock is never released. What happened to me (when writing an Altera Triple Speed Ethernet Driver for NIOS2) was as follows (names here are slightly different than reality). Of course other scenarios are possible. user calls rtems_bsdnet_ioctl which takes bsd stack lock, it calls rtems_bsdnet_ifconfig which locks bsd stack recursively, it calls driver_ioctl function when setting IF_UP flag to true, it calls driver_begin_communicating and it discovers it is already communicating, it calls driver_stop_communicating which iscovers that tx/rx threads are running, it calls bsd_locking_semaphore_release while waiting for the tx/rx threads to shutdown rip I fixed this of by changing to a noop if they set IF_UP flag and the driver is already up and running, but sometimes that might be less than robust because we are not forcing a restart of the auxiliary threads. Furthermore, if the user sets the UP flag to false then we cant avoid this issue; we will definitely need to release the lock when the driver threads are forced to exit? POTENTIAL FIX: Usually what is done is to make a rtems_bsdnet_ifconfig_nolock_private function and then call it form both rtems_bsdnet_ioctl and rtems_bsdnet_ifconfig; presumably the perimeter functions must lock only once on the way in, or in any case thats a common convention with multi-threaded code. On Jan 30, 2012, at 12:30 PM, Hill, Jeffrey O wrote:
-- Eric Norum |
|||
#2058 | wontfix | network/legacy | ||
Summary |
RPC library audit required |
|||
Description |
The RPC library needs an audit to verify that it is up to data. Some security problems existed in the SUN implementation, e.g http://www.cert.org/advisories/CA-2003-10.html Maybe it makes sense to use the recent FreeBSD or OpenBSD version. |
|||
#2324 | fixed | doc | ||
Summary |
Documentation and quick start for the RSB |
|||
Description |
https://ftp.rtems.org/pub/rtems/people/chrisj/source-builder/source-builder.html In this guide 2.5. Distributing and Archiving A Build
$ cd $ cd development/rtems/src/rtems-source-builder/rtems/tar $ tar --strip-components=3 -xjf rtems-4.11-sparc-rtems4.11-1.tar.bz2 instead of $ cd $ tar --strip-components=3 -xjf rtems-4.11-sparc-rtems4.11-1.tar.bz2 because cd leads to home directory and no tar file actually will be created at home directory .Every time it will be created at development/rtems/src/rtems-source-builder/rtems/tar and for extract the file ,user need migrate to this directory. |
|||
#2388 | fixed | fs | ||
Summary |
[PATCH] [NFS client] Remove old CVS keywords |
|||
Description |
The NFS client code in 4.11 and master at least contains CVS keywords that are printed to screen and no longer expanded in the post-CVS world |
|||
#2401 | fixed | score | ||
Summary |
ARMv7M: Default exception handler doesn't support FPU |
|||
Description |
On exception entry, _ARMV7M_Exception_default stores the previous Stack Pointer in a CPU_Exception_frame. The SP can be MSP or PSP, depending on the mode in which the exception was taken. To know this, we must check the value of LR. Right now the code checks whether it should store MSP or PSP by comparing LR to -3 (0xFFFFFFFD). However, this doesn't work if we're using an FPU since the error code would be either 0xFFFFFFE9 or 0xFFFFFFED. The result is that we always end up selecting MSP. This bug was found by Sudarshan Rajagopalan in the RTEMS git master. |
|||
#2479 | fixed | tool | ||
Summary |
RTEMS Source Builder gets wrong version of rtems-tools for rtems4-11. |
|||
Description |
When building the tool chain for RTEMS 4.11, RSB gets the 4.12 version of rtems-tools. |
|||
#2499 | invalid | tool/gdb | ||
Summary |
RSB 4.11 broken on FreeBSD 10 with default prefix. |
|||
Description |
Building gdb-7.9 with the default prefix on FreeBSD results in iconv not being found and used when linking. |
|||
#2622 | fixed | fs/fat | ||
Summary |
FAT file corruption when pre-empted while appending to a file |
|||
Description |
We've been circling around some odd problems for a while where some of our files end up with garbage sequences in them. I'll save you the hand-wringing diagnostic steps, and jump to the conclusion: when opening and appending to an existing file, sometimes a cluster gets written that contains data from another concurrent write operation (to a different file). An isolated repro is hard to get, but we wedged our code into a state where we can repro it 100% of the time. I traced the problem down to this sequence (introduced in commit 42a22f0824c4618b864582804ce1440b548a462f - 2012):
I have a task that wakes up every 5s, opens the file for append, and writes some hundreds of bytes. With a little bit of logging, we find that each operation that does not extend past the first cluster (4KiB) takes the FAT_OP_TYPE_READ branch. Then as soon as the first write to the second file cluster is made (which is usually an overflow from a user-level write that spanned the 4K boundary), all future writes take the FAT_OP_TYPE_GET branch. I was convinced for a while that perhaps some proximate code of ours was corrupting some bit of accounting, but upon reading through what this is doing, I cannot wrap my head around how the intention was correct. The "if (file_cln_initial < file_cln_cnt)" condition could be unpacked to: if (fat_fd->map.file_cln < (seek_disk_cln - start_disk_cln)) I don't see how this arithmetic is correct. We are comparing a file cln to the delta between two disk clns, which unless if I am missing something, is meaningless. Also, we are getting the file cln from the cache, the interpretation of which depends entirely on the operation that took place when it was queried (which is in fat_file_write). I think the only way this makes sense is if this check were instead passing if we are writing to the last cluster of the file at offset 0 within the cluster. At any other time, this needs to be a read-modify-write because we can't just overwrite the cluster. I'm not sure how to express this, though. It turns out that for many operations without considering pre-emption, the buffer you get back with fat_buf_access(FAT_OP_TYPE_GET) is populated with the cluster data. When writing sequentially to a file from a single task, this seems to hold together. However, being pre-empted by a higher priority writer may cause some buffer churn and will result in writing a cluster that has the beginning corrupted. We see this as periodic corruption, the beginning of which is always aligned to a 4KiB file offset boundary. If we hard-code overwrite_cluster to always be false, we do not experience corruption (assuming some performance penalty in these corner cases). Can someone either confirm or explain what this code is (supposed to be) doing? I'm not ruling out that we are causing a problem here, but right now I am leaning to a defect in the filesystem. |
|||
#2670 | wontfix | tool/rsb | ||
Summary |
epiphany tools fail to build on 4.11 |
|||
Description |
Looks like an incorrect hash but could be something more subtle. script: 80: build_top=$(pwd) script: 81: gcc_source=epiphany-gcc-f7051762470c42ce7f01baa7edeb113d51c7dd72 script: 82: source_dir_gcc=${gcc_source} source setup: epiphany-rtems4.11-gcc-4.9.1-newlib-ef23a12ff8f840cc571e47870cd5f4ad6bca4553-x86_64-linux-gnu-1: source gcc -q -n ${gcc_source} making dir: /home/joel/rtems-4.11-work/rtems-source-builder/rtems/sources download: https://github.com/adapteva/epiphany-gcc/archive/f7051762470c42ce7f01baa7edeb113d51c7dd72.zip -> sources/f7051762470c42ce7f01baa7edeb113d51c7dd72.zip download: https://github.com/adapteva/epiphany-gcc/archive/f7051762470c42ce7f01baa7edeb113d51c7dd72.zip -> sources/f7051762470c42ce7f01baa7edeb113d51c7dd72.zip
checksums: f7051762470c42ce7f01baa7edeb113d51c7dd72.zip: e089e67261c96c746e685bba018581f0 => c43c2e631418e932e2048607b694e99a warning: checksum error: f7051762470c42ce7f01baa7edeb113d51c7dd72.zip error: checksum failure file: sources/f7051762470c42ce7f01baa7edeb113d51c7dd72.zip
Build Set: Time 0:08:36.503865 |
|||
#2708 | fixed | unspecified | ||
Summary |
【rtems-bsp shell script does not list the available BSPS】 |
|||
Description |
It seems rtems-bsps does not work properly: loadrun@debian:~/code/rtems/rtems/4.11.0-rc3/rtems-4.11.0-rc3$ sh rtems-bsps find: paths must precede expression: 5 Usage: find [-H] [-L] [-P] [-Olevel] [-D help|tree|search|stat|rates|opt|exec] [path...] [expression] RTEMS 4.11
loadrun@debian:~/code/rtems/rtems/4.11.0-rc3/rtems-4.11.0-rc3$ uname -a Linux debian 3.16.0-4-686-pae #1 SMP Debian 3.16.7-ckt25-1 (2016-03-06) i686 GNU/Linux |
|||
#2755 | fixed | fs/fat | ||
Summary |
FAT mkdir() broken |
|||
Description |
FAT implementation in RTEMS incorrectly create directories. Reproducing is extremly simple:
sudo fsck_msdos /dev/rdisk3s1 ** /dev/rdisk3s1 ** Phase 1 - Preparing FAT ** Phase 2 - Checking Directories Directory /0 has size != 0 Correct? [yn] Both 4.11 and 4.12 have this bug. |
|||
#2758 | wontfix | bsps | ||
Summary |
SDCard driver for QoriQ |
|||
Description |
SDCard driver for QoriQ CPU family. Tested on P2020, Kontron COMe-cP2020 board. Usage example: bsp_register_esdhc_memcard(); rc = rtems_bdpart_register_from_disk("/dev/memcard"); |
|||
#2815 | fixed | build | ||
Summary |
Add Preferred waf to top of various repositories |
|||
Description |
The proper version of waf needs to be placed at the top of each repo. This is missing from at least rtems-libbsd. |
|||
#2827 | fixed | unspecified | ||
Summary |
rtems-bsps broken on 4.11 branch |
|||
Description |
Looks like at least this patch was not backported: commit 8aa75d0cb18c25fab2078a7641bd823bf0e93999 Author: Chris Johns <chrisj@…> Date: Wed Jul 6 13:01:39 2016 +1000
Probably worth a double check to ensure that the patch from Pavel to remove GNU find dependencies is also on the 4.11 branch. |
|||
#2886 | wontfix | unspecified | ||
Summary |
RTEMS version is wrong on 4.11 branch |
|||
Description |
cat m4_define([_RTEMS_API],[4.11]) AC_DEFUN([RTEMS_VERSIONING], m4_define([_RTEMS_VERSION],[4.10.99.0])) m4_define([_RTEMS_API],[4.11]) AC_DEFUN([RTEMS_VERSIONING], m4_define([_RTEMS_VERSION],[4.10.99.0])) m4_define([_RTEMS_API],[4.11]) AC_DEFUN([RTEMS_VERSIONING], m4_define([_RTEMS_VERSION],[4.10.99.0])) m4_define([_RTEMS_API],[4.11]) |
|||
#2907 | fixed | bsps | ||
Summary |
BSP Script v4.11 Fix |
|||
Description |
After some discussions on the mailing list, it seems that the "rtems_bsps" script in v4.11 never got a patch fixing the find command used to list available BSPs. Below is a patch I used to get things working.
diff -rupN RTEMS_v4.11.0/rtems-bsps RTEMS_v4.11.0_Fixed/rtems-bsps
--- RTEMS_OS_v4.11.0_New_Source/rtems-bsps 2017-02-10 12:52:01.875581452 -0500
+++ RTEMS_v4.11.0_Source/rtems-bsps 2017-02-10 12:06:15.587126976 -0500
@@ -5,7 +5,7 @@ base_e=$(echo ${base} | sed -e 's/\
-cfg_list=$(LANG=C LC_COLLATE=C find ${base} -depth 5 -name \*.cfg | sort) +cfg_list=$(LANG=C LC_COLLATE=C find ${base} -mindepth 5 -name \*.cfg | sort)
|
|||
#2908 | fixed | fs/fat | ||
Summary |
FAT filename comparison is broken |
|||
Description |
For a filename match the entry must match without anything remaining. |
|||
#2913 | fixed | fs/fat | ||
Summary |
RTEMS FAT32 formatter does not set the not dirty and no IO error bits |
|||
Description |
On FAT12 and FAT32 the FAT table entry 1 contains one bit to indicate that the filesystem is not dirty and one bit that no IO error occurred. Set these bits in the formatter to prevent a warning if mounted on Windows. |
|||
#2914 | fixed | score | ||
Summary |
termios: Race condition in raw input buffer handling |
|||
Description |
Use the device lock to protect the raw input buffer management, e.g. tail, head and buffer content updates. |
|||
#2915 | fixed | score | ||
Summary |
termios: Potential infinite loop in canonical mode |
|||
Description |
In canonical mode, the raw input buffer or the canonical buffer may overflow without an end of line. Avoid an infinite loop in this case. |
|||
#2928 | fixed | fs/fat | ||
Summary |
FAT filename comparision is broken while using the UTF-8 support |
|||
Description |
The handling of a maximum 8.3 short file name is broken while using the UTF-8 support. A simple "touch txtvsbin.txt" doesn't work. |
|||
#2929 | fixed | fs/fat | ||
Summary |
FAT long file names accross cluster boundaries may be broken |
|||
Description |
The procedure to create a long file name directory entry may not work correctly in case a cluster boundary is crossed. Simplify msdos_add_file() to avoid a potential issue. |
|||
#2934 | fixed | fs/fat | ||
Summary |
FAT long file name padding is broken |
|||
Description |
In msdos_add_file() the padding of long file names with 0xff is broken. This leads to problems on some Windows systems. |
|||
#2936 | fixed | fs | ||
Summary |
Deadlock in filesystem location management |
|||
Description |
Always perform a deferred location release to avoid a deadlock on the file system instance locks, for example during a chdir(). |
|||
#2937 | fixed | fs/fat | ||
Summary |
FAT race condition msdos_dir_read() |
|||
Description |
Obtain file system instance lock before member access. |
|||
#2939 | fixed | fs/fat | ||
Summary |
FAT file name search may not consider long file names |
|||
Description |
Do not use our long file name entry count to optimize the file name search. The Unicode comparison must be taken into account. |
|||
#2940 | fixed | doc | ||
Summary |
rtems-docs output and catalogue.xml verison numbering is wrong. |
|||
Description |
The version number management in rtems-docs.git is mixed up and it is not possible to embed a suitable release number in the release build of the documentation.
Remove the version and release from each doc's
Provide a command line option
Default the version to the branch number, eg |
|||
#2947 | fixed | tool/rsb | ||
Summary |
FreeBSD 11.0 check warnings for makeinfo and install-info |
|||
Description |
These have moved and the check needs to know. |
|||
#2948 | fixed | tool | ||
Summary |
ARM: Optimize IEEE-754 sqrt implementation |
|||
Description |
Use the vsqrt.f64 and vsqrt.f32 instructions if available. |
|||
#2950 | fixed | admin | ||
Summary |
doxygen does not install on sync.rtems.org |
|||
Description |
The dependent package graphviz does not install: [sync.rtems.org] [1/2] Extracting graphviz-2.40.1: 0%/usr/local/lib/libpkg.so.4: Undefined symbol "utimensat" The doxygen command is needed to build doxygen documentation for a release. |
|||
#2952 | fixed | tool/rsb | ||
Summary |
Support a release candidates residing in an |
|||
Description |
Update the RSB to look for release candidate packages in an |
|||
#2953 | fixed | admin | ||
Summary |
Change Trac time format to absolute. |
|||
Description |
Setting the Trac default time format to absolute makes better printed reports as the real time is displayed rather than the time being relative to time the report is printed. Applying the change via the Trac Admin results with the post timing out and I do not know if this is expected given trac,ini is (was) read-only. |
|||
#2955 | fixed | lib/dl | ||
Summary |
Backport libdl fixes to the 4.11 branch. |
|||
Description |
Back port the patches from tickets #2754 and #2767 to the 4.11 branch. |
|||
#2956 | fixed | unspecified | ||
Summary |
Backport rtems-tester qemu console fix. |
|||
Description |
Backport Ric's fix to the qemu console: |
|||
#2989 | fixed | admin | ||
Summary |
doxygen crashes on sync.rtems.org |
|||
Description |
Attempting to create a release on sync.rtems.org results in a core being dumped: Running dot for graph 3822/7363 Running dot for graph 3823/7363 Segmentation fault (core dumped) Run doxygen on a recent RTEMS kernel. This does not happen another 11.0 machine I have. That version of doxygen is 1.8.12 and sync.rtems.org as 1.8.13. I have seen other erratic behaviour such as git not working, disks not |
|||
#2996 | fixed | unspecified | ||
Summary |
source download for RTEMS 4.11.2-rc1 Release |
|||
Description |
A while back Following the instructions on https://ftp.rtems.org/pub/rtems/releases/4.11/rc/4.11.2-rc1/ and running: ../source-builder/sb-set-builder --prefix=$HOME/development/rtems/4.11.2-rc1 4.11/rtems-sparc making dir: /home/user/development/rtems/rtems-source-builder-4.11.2-rc1/rtems/sources download: ftp://ftp.rtems.org/pub/rtems/releases/4.11/4.11.2-rc1/rtems-tools-4.11.2-rc1.tar.xz -> sources/rtems-tools-4.11.2-rc1.tar.xz download: ftp://ftp.rtems.org/pub/rtems/releases/4.11/4.11.2-rc1/rtems-tools-4.11.2-rc1.tar.xz -> sources/rtems-tools-4.11.2-rc1.tar.xz download: ftp://ftp.rtems.org/pub/rtems/releases/4.11/4.11.2-rc1/rtems-tools-4.11.2-rc1.tar.xz: error: <urlopen error ftp error: 550 Failed to change directory.> error: downloading ftp://ftp.rtems.org/pub/rtems/releases/4.11/4.11.2-rc1/rtems-tools-4.11.2-rc1.tar.xz: all paths have failed, giving up The path does not exist. I tried to change the path in source-builder/defaults.mc: rtems_release_url: none, none, 'https://ftp.rtems.org/pub/rtems/releases/%{rtems_version}' As it seems *very* strange that ftp is used by default when https should work. In the end, i downloaded the files such as rtems-source-builder-4.11.2-rc1.tar.xz and placed them in the folder sources/ and then the build worked. |
|||
#3002 | fixed | bsps | ||
Summary |
Incorrect bit reference in ARM GIC |
|||
Description |
Incorrect bit reference in /c/src/lib/libbsp/arm/shared/include/arm-gic.h, line 46. The macro GIC_ID_TO_TWO_BITS_REG_OFFSET supposed to convert interrupt ID to an index of a two-bit field in a register. The correct way is: #define GIC_ID_TO_TWO_BITS_REG_OFFSET(id) (((id) & 0xfU) << 1) |
|||
#3005 | fixed | doc | ||
Summary |
Typo in RTEMS Source Builder 4.11.99 |
|||
Description |
Working from a clean Ubuntu 16.04 install, the following commands in section "3.1.4 Ubuntu" fail to install a working copy of GIT and RSB fails immediately: $ sudo apt-get build-dep binutils gcc g++ gdb unzip git $ sudo apt-get install python2.7-dev The following commands appear to work: $ sudo apt-get build-dep binutils gcc g++ gdb unzip $ sudo apt-get install python2.7-dev git |
|||
#3030 | fixed | unspecified | ||
Summary |
lm32-rtems4.11-gdb does not build on Windows. |
|||
Description |
Building LM32 on Windows fails in the simulator. The patch: https://git.rtems.org/rtems-tools/tree/tools/4.11/gdb/lm32/gdb-7.9-lm32uart.diff does not clean up the Window build. |
|||
#3033 | fixed | unspecified | ||
Summary |
MIPS does not build on FreeBSD |
|||
#3035 | fixed | tool/binutils | ||
Summary |
4.11/rtems-moxie does not build. |
|||
Description |
Moxie on 4.11 does not build because of asm errors. The compile will build with binutils-2.25 and moxie should be down graded to use that version. |
|||
#3042 | fixed | tool/gcc | ||
Summary |
4.11/rtems-bfin does not build on Windows |
|||
Description |
The attached RSB report details the failure.
The |
|||
#3044 | fixed | tool/gdb | ||
Summary |
4.11/rtems-h8300 does not build on Windows. |
|||
Description |
The attached RSB report details the failure. The simulator does not build on Windows. |
|||
#3045 | duplicate | tool/gdb | ||
Summary |
4.11/rtems-h8300 does not build on Windows |
|||
Description |
The attached RSB report details the failure. The simulator does not build on Windows. |
|||
#3060 | fixed | score | ||
Summary |
ARMv7-M interrupt processing is broken |
|||
Description |
Right after a "msr basepri_max, %[basepri]" instruction an interrupt service may still take place (observed at least on Cortex-M7). However, pendable service calls that are activated during this interrupt service may be delayed until interrupts are enable again. The _ARMV7M_Pendable_service_call() does currently not check that a thread dispatch is allowed. Move this test from _ARMV7M_Interrupt_service_leave() to _ARMV7M_Pendable_service_call(). |
|||
#3064 | fixed | tool/rsb | ||
Summary |
RSB does not handle the |
|||
Description |
The RBS needs to handle the |