Custom Query (47 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Ticket Created Resolution Component Reporter Owner Modified
#3064 7 years ago fixed tool/rsb Chris Johns Chris Johns 6 years ago
Summary

RSB does not handle the --rsb-file option named sources with releases.

Description

The RBS needs to handle the --rsb-file option when downloading release sources. The RSB currently attempts to use the path in the config file however the file in the sources is the name given to --rsb-file.

#3060 7 years ago fixed score Sebastian Huber Sebastian Huber 7 years ago
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().

#3045 7 years ago duplicate tool/gdb Chris Johns Chris Johns 7 years ago
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.

#3044 7 years ago fixed tool/gdb Chris Johns Chris Johns 7 years ago
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.

#3042 7 years ago fixed tool/gcc Chris Johns joel.sherrill@… 6 years ago
Summary

4.11/rtems-bfin does not build on Windows

Description

The attached RSB report details the failure.

The cfns.gperf changes need to be ported to the bfin specific version of gcc. This gcc is used because the standard 4.11 does not build due to a gcc ICE.

#3035 7 years ago fixed tool/binutils Chris Johns Chris Johns 7 years ago
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.

#3033 7 years ago fixed unspecified Chris Johns Chris Johns 7 years ago
Summary

MIPS does not build on FreeBSD

#3030 7 years ago fixed unspecified Chris Johns Chris Johns 7 years ago
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.

#3005 7 years ago fixed doc Linda Huxley chrisj@… 6 years ago
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

#3002 7 years ago fixed bsps munster Sebastian Huber 7 years ago
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)
#2996 7 years ago fixed unspecified tnagy Chris Johns 7 years ago
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.

#2989 7 years ago fixed admin Chris Johns Amar Takhar 7 years ago
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

#2956 7 years ago fixed unspecified Chris Johns Chris Johns 6 years ago
Summary

Backport rtems-tester qemu console fix.

Description

Backport Ric's fix to the qemu console:

https://git.rtems.org/rtems-tools/commit/tester/rtems/testing/qemu.cfg?id=92935ed1a3b5cefa37d7ee5701276cd8383e170e

#2955 7 years ago fixed lib/dl Chris Johns chrisj@… 7 years ago
Summary

Backport libdl fixes to the 4.11 branch.

Description

Back port the patches from tickets #2754 and #2767 to the 4.11 branch.

#2953 7 years ago fixed admin Chris Johns amar@… 7 years ago
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.

#2952 7 years ago fixed tool/rsb Chris Johns Chris Johns 7 years ago
Summary

Support a release candidates residing in an rc directory.

Description

Update the RSB to look for release candidate packages in an rc directory. This removes these packages from the main release directory and stops them cluttering the main release directory keeping the focus on the releases.

#2950 7 years ago fixed admin Chris Johns Amar Takhar 7 years ago
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.

#2948 7 years ago fixed tool Sebastian Huber Sebastian Huber 7 years ago
Summary

ARM: Optimize IEEE-754 sqrt implementation

Description

Use the vsqrt.f64 and vsqrt.f32 instructions if available.

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=commit;h=baf32fb85fd6ef5e3e5975a357a40de72dc92e15

#2947 7 years ago fixed tool/rsb Chris Johns Chris Johns 7 years ago
Summary

FreeBSD 11.0 check warnings for makeinfo and install-info

Description

These have moved and the check needs to know.

#2940 7 years ago fixed doc Chris Johns Chris Johns 6 years ago
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 conf.py and move it into the common/waf.py support.

Provide a command line option --release to specify the release string.

Default the version to the branch number, eg 4.11 (branch).

#2939 7 years ago fixed fs/fat Sebastian Huber Sebastian Huber 6 years ago
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.

#2937 7 years ago fixed fs/fat Sebastian Huber Sebastian Huber 6 years ago
Summary

FAT race condition msdos_dir_read()

Description

Obtain file system instance lock before member access.

#2936 7 years ago fixed fs Sebastian Huber Sebastian Huber 7 years ago
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().

#2934 7 years ago fixed fs/fat Sebastian Huber Sebastian Huber 6 years ago
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.

#2929 7 years ago fixed fs/fat Sebastian Huber Sebastian Huber 6 years ago
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.

#2928 7 years ago fixed fs/fat Sebastian Huber Sebastian Huber 6 years ago
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.

#2915 7 years ago fixed score Sebastian Huber Sebastian Huber 7 years ago
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.

#2914 7 years ago fixed score Sebastian Huber Sebastian Huber 7 years ago
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.

#2913 7 years ago fixed fs/fat Sebastian Huber Sebastian Huber 6 years ago
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.

#2908 7 years ago fixed fs/fat Sebastian Huber Sebastian Huber 6 years ago
Summary

FAT filename comparison is broken

Description

For a filename match the entry must match without anything remaining.

#2907 7 years ago fixed bsps Joey DiGiorgio 7 years ago
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/\
\

last_arch=""

-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)

max_bsp_len=0 arch_count=0

#2886 7 years ago wontfix unspecified Sebastian Huber Sebastian Huber 7 years ago
Summary

RTEMS version is wrong on 4.11 branch

Description

cat find -name version.m4 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]) AC_DEFUN([RTEMS_VERSIONING], m4_define([_RTEMS_VERSION],[4.10.99.0]))

m4_define([_RTEMS_API],[4.11])

#2827 7 years ago fixed unspecified Joel Sherrill Chris Johns 7 years ago
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

Config (.cfg) files are only valid if deeper than 5.

Probably worth a double check to ensure that the patch from Pavel to remove GNU find dependencies is also on the 4.11 branch.

#2815 7 years ago fixed build Joel Sherrill Chris Johns 6 years ago
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.

#2758 8 years ago wontfix bsps snob-wolpike 7 years ago
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");
#2755 8 years ago fixed fs/fat snob-wolpike Sebastian Huber 6 years ago
Summary

FAT mkdir() broken

Description

FAT implementation in RTEMS incorrectly create directories. Reproducing is extremly simple:

  • Run any application using 'mkdir()' on mounted FAT partition.
  • Run fsck under any operating system (Linux, MacOSX, Windows)
  • You will get smth like this:
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.

#2708 8 years ago fixed unspecified koreny Chris Johns 7 years ago
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

Architectures: 0 BSP Count: 0

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

#2670 8 years ago wontfix tool/rsb Joel Sherrill Chris Johns 7 years ago
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

redirect: https://codeload.github.com/adapteva/epiphany-gcc/zip/f7051762470c42ce7f01baa7edeb113d51c7dd72 redirect: https://codeload.github.com/adapteva/epiphany-gcc/zip/f7051762470c42ce7f01baa7edeb113d51c7dd72

checksums: f7051762470c42ce7f01baa7edeb113d51c7dd72.zip: e089e67261c96c746e685bba018581f0 => c43c2e631418e932e2048607b694e99a warning: checksum error: f7051762470c42ce7f01baa7edeb113d51c7dd72.zip error: checksum failure file: sources/f7051762470c42ce7f01baa7edeb113d51c7dd72.zip

See error report: rsb-report-epiphany-rtems4.11-gcc-4.9.1-newlib-ef23a12ff8f840cc571e47870cd5f4ad6bca4553-x86_64-linux-gnu-1.txt

Build Set: Time 0:08:36.503865

#2622 8 years ago fixed fs/fat Stella Laurenzo Sebastian Huber 6 years ago
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):

In fat_file_write_fat32_or_non_root_dir:

        if (file_cln_initial < file_cln_cnt)
            overwrite_cluster = true;

Triggers (in fat_block_write):

        if (   overwrite_block
            || (bytes_to_write == fs_info->vol.bytes_per_block))
        {
            rc = fat_buf_access(fs_info, sec_num, FAT_OP_TYPE_GET, &blk_buf);
        }
        else {
            rc = fat_buf_access(fs_info, sec_num, FAT_OP_TYPE_READ, &blk_buf);
        }

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.

#2499 8 years ago invalid tool/gdb Chris Johns 7 years ago
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.

#2479 8 years ago fixed tool Mike Westfall 7 years ago
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.

#2401 9 years ago fixed score Martin Galvan Sudarshan Rajagopalan <sudarshan.rajagopalan@…> 7 years ago
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.

#2388 9 years ago fixed fs Nick Withers Nick Withers <nick.withers@…> 7 years ago
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

#2324 9 years ago fixed doc punitvara Chris Johns 6 years ago
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

It would be better if

$ 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.

#2058 12 years ago wontfix network/legacy Sebastian Huber Eric Norum 7 years ago
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.

#2002 12 years ago wontfix network/legacy Jeffrey Hill Joel Sherrill 7 years ago
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:


From: Eric Norum Sent: Monday, January 30, 2012 11:21 AM To: Hill, Jeffrey O Cc: Till Straumann Subject: Re: rtems bsd network deadlock potential

The network mutex is to be taken whenever making the transition from 'user' code from 'kernel' code. I did this because the BSD kernel from which the networking code was lifted was, like many (all?) old UNIXes, non-reentrant. It's possible that over the years some code has been added to the IOCTL support that ends up calling a 'user' level routine from 'kernel' level which then calls some 'kernel' code again. This should be fixed. kernel code should never call user code -- just to avoid the nested mutex problem that Jeff is reporting. Perhaps some IOCTL routine need to be split up with a user-level wrapper that takes the mutex then calls the kernel level routine -- and that kernel level routine should be what any other kernel level code invokes.

I'm afraid that I don't have time to look at this now.

On Jan 30, 2012, at 9:30 AM, Hill, Jeffrey O wrote:

It could well be that the intention is that rtems_bsdnet_ioctl()

executes

atomically w/o the driver temporarily releasing the lock and doing communication. That could alter internal state in unintended ways.

Ok, maybe this is just part of the design, but I am left with some

doubts if this type of (taking the lock twice to prevent the state from changing while in the driver) enforcement policy is applied uniformly. It might even be that this is in place purely because of accidental inconsistencies in the way the lock is acquired on the way in.

Considering this further, isn't it quite routine and normal for the

driver to shutdown auxiliary threads (which take the lock) when inside the driver ioctl function if the user sets the UP flag to false? Presumably this can't be done reliably w/o releasing the lock in the driver?

Of course the RTEMS designers, who know all of the consequences will

need to decide. I am only identifying what appear to be issues when I see them.

Jeff


From: Till Straumann Sent: Monday, January 30, 2012 10:07 AM To: Hill, Jeffrey O Cc: Eric Norum Subject: Re: rtems bsd network deadlock potential

I see. However, I'm not sure if that is not a programming error in the driver. It could well be that the intention is that rtems_bsdnet_ioctl()

executes

atomically w/o the driver temporarily releasing the lock and doing communication. That could alter internal state in unintended ways.

T.

On 01/30/2012 10:58 AM, Hill, Jeffrey O wrote:

Hi Till,

What happened to me was as follows (names are slightly different than

reality), but of course other scenarios are possible.

rtems_bsdnet_ioctl calls (it locks), it calls rtems_bsdnet_ifconfig calls (it locks recursively), it calls driver_ioctl function (because IF_UP flag is being set to true), it

calls

driver_begin_communicating (which discovers that it is already

communicating), it calls

driver_stop_communicating (which discovers 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 course 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 robust because we are not forcing a restart of the auxiliary threads.

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 semaphore, but the lock count doesn't decrement to zero, so the lock is never released.

Usually what is done is to make a rtems_bsdnet_ifconfig_nolock_private

and then call it form both rtems_bsdnet_ioctl and

rtems_bsdnet_ifconfig;

the perimeter functions must lock only once on the way in.

Jeff


From: Till Straumann Sent: Friday, January 27, 2012 3:36 PM To: Hill, Jeffrey O Cc: Eric Norum Subject: Re: rtems bsd network deadlock potential

Maybe I'm missing something but AFAIK the networking semaphore is basically a mutex which you can take multiple times from the same thread.

Could you please explain in more detail?

T.

On 01/27/2012 04:28 PM, Hill, Jeffrey O wrote:

Hi Eric, Till,

FWIW, I noticed today that there is a situation where

rtems_bsdnet_ioctl

calls rtems_bsdnet_ifconfig, but both functions take the bsd

networking

semaphore resulting in a recursive reference counted lock. Therefore

if

the driver's implementation of ioctl calls rtems_bsdnet_event_receive there will be a deadlock (because the internal attempt to unlock is silently unsuccessful). I will no-doubt try to come up with a

workaround

but perhaps the situation is somewhat precarious.

Is this serious enough that I should report a bug to the RTEMS bug

tracking system?

#0 ( rtems_bsdnet_event_receive(event_in=8, option_set=0, ticks=0,

event_out=0xa7a9f4) (/home/hill/nios2-rtems/rtems/rtems-4.11.0- /cpukit/libnetworking/rtems/rtems_glue.c:687)

#1 0x5f34 alt_tse_soft_tx_stop(pSoftSgdmaTx=0xb24084)

(/home/hill/nios2-

rtems/rtems/rtems-4.11.0- /c/src/lib/libbsp/nios2/neek/network/if_alttse.c:206)

#2 0x5fa8 alt_tse_soft_tx_destroy(pSoftSgdmaTx=0xb24084)

(/home/hill/nios2-rtems/rtems/rtems-4.11.0- /c/src/lib/libbsp/nios2/neek/network/if_alttse.c:216)

#3 0x8808 alt_tse_stop_comm(ifp=0xb23c3c) (/home/hill/nios2-

rtems/rtems/rtems-4.11.0- /c/src/lib/libbsp/nios2/neek/network/if_alttse.c:1554)

#4 0x88a8 alt_tse_start_comm(pParm=0xb23c3c) (/home/hill/nios2-

rtems/rtems/rtems-4.11.0- /c/src/lib/libbsp/nios2/neek/network/if_alttse.c:1576)

#5 0x8a90 alt_tse_start_comm_no_status(pParm=0xb23c3c)

(/home/hill/nios2-rtems/rtems/rtems-4.11.0- /c/src/lib/libbsp/nios2/neek/network/if_alttse.c:1651)

#6 0xe5a8 ether_ioctl(ifp=0xb23c3c, command=1, data=<value

optimized

out>) (/home/hill/nios2-rtems/rtems/rtems-4.11.0- /cpukit/libnetworking/net/if_ethersubr.c:838)

#7 0x8bc0 alt_tse_ioctl(ifp=0xb23c3c, cmmd=2149607692,

data=0xb24648

"\210F\262") (/home/hill/nios2-rtems/rtems/rtems-4.11.0- /c/src/lib/libbsp/nios2/neek/network/if_alttse.c:1680)

#8 0x3272c in_ifinit(ifp=0xb23c3c, ia=0xb24648, sin=<value

optimized

out>, scrub=1) (/home/hill/nios2-rtems/rtems/rtems-4.11.0- /cpukit/libnetworking/netinet/in.c:480)

#9 0x331a0 in_control(so=<value optimized out>, cmd=2149607692,

data=0xa7aba0 "tse0", ifp=0xb23c3c) (/home/hill/nios2-

rtems/rtems/rtems-

4.11.0-/cpukit/libnetworking/netinet/in.c:312)

#10 0x2632c old_control(so=0x0, cmd=10987900, data=0xa7a9f4

"\034\252\247", ifp=<value optimized out>) (/home/hill/nios2- rtems/rtems/rtems-4.11.0-

/cpukit/libnetworking/kern/uipc_socket2.c:801)

#11 0xfcc8 ifioctl(so=0xb23e08, cmd=1, data=0xa7aba0 "tse0",

p=<value

optimized out>) (/home/hill/nios2-rtems/rtems/rtems-4.11.0- /cpukit/libnetworking/net/if.c:605)

#12 0x1c3e8 so_ioctl(iop=0xaf2544, command=1, buffer=<value

optimized out>) (/home/hill/nios2-rtems/rtems/rtems-4.11.0- /cpukit/libnetworking/rtems/rtems_syscall.c:713)

#13 ( rtems_bsdnet_ioctl(iop=0xaf2544, command=1, buffer=<value

optimized out>) (/home/hill/nios2-rtems/rtems/rtems-4.11.0- /cpukit/libnetworking/rtems/rtems_syscall.c:731)

#14 0x3093c ioctl(fd=<value optimized out>, command=1)

(/home/hill/nios2-rtems/rtems/rtems-4.11.0- /cpukit/libcsupport/src/ioctl.c:50)

#15 0x194b8 rtems_bsdnet_ifconfig(ifname=0x4afb4 "tse0",

cmd=2149607692, param=0xa7abe0) (/home/hill/nios2-rtems/rtems/rtems- 4.11.0-/cpukit/libnetworking/rtems/rtems_glue.c:1114)

#16 0x19718 rtems_bsdnet_setup_interface(name=0x4afb4 "tse0",

ip_address=0x4afbc "128.165.34.102", ip_netmask=0x4afcc

"255.255.255.0")

(/home/hill/nios2-rtems/rtems/rtems-4.11.0- /cpukit/libnetworking/rtems/rtems_glue.c:879)

#17 0x19d88 rtems_bsdnet_setup() (/home/hill/nios2-

rtems/rtems/rtems-4.11.0-

/cpukit/libnetworking/rtems/rtems_glue.c:959)

#18 ( rtems_bsdnet_initialize_network() (/home/hill/nios2-

rtems/rtems/rtems-4.11.0-

/cpukit/libnetworking/rtems/rtems_glue.c:1018)

#19 0x360 Init(ignored=336840) (init.c:51) #20 0x3a268 _Thread_Handler() (/home/hill/nios2-rtems/rtems/rtems-

4.11.0-/cpukit/score/src/threadhandler.c:157)

#21 0x132c boot_card(cmdline=0xa74338 "DD\247") (/home/hill/nios2-

rtems/rtems/rtems-4.11.0- /c/src/lib/libbsp/nios2/neek/../../shared/bootcard.c:268)

#22 ( 0x00000000 in ??() (??:??)

Jeff

-- Eric Norum

-- Eric Norum

#1523 14 years ago wontfix network/legacy Chris Johns Chris Johns 7 years ago
Summary

gethostbyname is not reenterant.

Description

The gethostbyname call uses global static data and therefore is not reenterant.

Note: See TracQuery for help on using queries.