QNX Technical Articles

Date of this edition: August 16, 2006

Target OS: QNX^® Neutrino^® 6.3.0 SP1 or SP2

Host OS:

• Microsoft Windows XP SP1 or SP2, 2000 SP4, or NT SP6a
• Sun Solaris 7, 8, 9, or 10
• QNX^® Neutrino^® 6.3.0 SP1 or SP2
• Linux Red Hat 8, 9, or Enterprise WS 3 or 4

Contents

• What's new in the QNX Neutrino Core OS 6.3.2?
  • Kernel
    • Virtual memory manager
  • Libraries and header files
  • Utilities
  • Startup
• Known issues
  • Key issues you should know about
  • Kernel
  • Libraries and header files
  • Filesystems
  • Networking
  • Utilities
  • IDE (Professional Edition only)
  • Startup
  • Uninstalling
• Getting started with the documentation
• Technical support
• List of fixes

Throughout this document, you may see reference numbers associated with particular issues, changes, etc. When corresponding with our Technical Support staff about a given issue, please quote the relevant reference number. You might also find the reference numbers useful for tracking issues as they become fixed.

For the most up-to-date version of these release notes, go to our website, www.qnx.com, log into your myQNX account, and then go to the Download Center.

---

Make sure that Plug and Play OS is disabled in the BIOS before you run QNX Neutrino self-hosted.

---

What's new in the QNX Neutrino Core OS 6.3.2?

The QNX Neutrino Core OS 6.3.2 is an upgrade for QNX Neutrino 6.3.0 with Service Pack 1 or 2 that updates the kernel (procnto), libc, various utilities and daemons, and the system headers. On Windows, Linux, and Solaris hosts, it updates the development system that you use to create applications that you can run on a QNX Neutrino runtime system. On Neutrino hosts, it updates both the development and the runtime systems.

Because of the upgrades to libc and the system headers, once you've installed 6.3.2, you can no longer build code against the 6.3.0 headers and libraries. The value of _NTO_VERSION changes from 630 to 632. If you want to (natively) build code and run the executables using 6.3.0 and 6.3.2, you have to make separate installations on different partitions or machines. Code compiled with 6.3.0 SP1 or SP2 will run on a 6.3.2 system.

The following sections describe the main new features in the QNX Neutrino Core OS 6.3.2:

• Kernel
  • Virtual memory manager
• Libraries and header files
• Utilities
• Startup

---

You'll find a list of fixes at the end of this document.

---

What's new: Kernel

• Threads now have names, which can make debugging easier. (Ref# 27085)

  The following commands now support thread names:

  • pidin now displays the thread names
  • dumper maintains the thread-name information in core files

  ---

  The IDE can't currently display the thread names.

  ---

• We've improved the performance of message-passing for short (fewer than 256 bytes) single and multipart messages. This has improved the performance for process-to-process messages in this size range by 15-30% as compared to that under QNX Momentics 6.3.0 SP2.

The OS images that we ship start procnto with the -v option, so that the kernel provides you with more information when a signal terminates a process.

Virtual memory manager

The QNX Neutrino Core OS 6.3.2 includes a completely rearchitected virtual memory (VM) manager. This provides significant benefits and functionalities, as follows:

• consistent POSIX mmap() behavior across all supported architectures
• partial munmap() is now supported on all processor families
• POSIX memory-mapped files are now supported
• POSIX memory locking is supported
• POSIX typed memory is supported

Here are more details:

• The new manager implements tighter error checking, so programs that worked with earlier revisions of the OS might encounter errors now.
• In some cases, the new code may delay memory-manager operations until a page is referenced, which could affect some code. You can use the POSIX mlock() or mlockall() functions to disable this behavior.
• If a thread (e.g. a device driver) does a ThreadCtl(_NTO_TCTL_IO...), the memory manager super-locks the memory referenced by the process to ensure that a page fault never occurs during periods while interrupts are disabled, or an ISR is executing.
• With POSIX support for memory-mapped files, the msync() function now performs its intended operation of writing changes in the mapped memory back to the underlying file. This has an interaction with the QNX Neutrino extension of having the function flush or invalidate the data cache (via the MS_SYNC or MS_INVALIDATE flags respectively). To get the previous behavior of just data cache operations, add the new MS_CACHE_ONLY flag to the call in addition to MS_SYNC or MS_INVALIDATE.
• The mmap() flag MAP_NOSYNCFILE continues to be supported, but if the same region in a file is mapped twice, once with MAP_NOSYNCFILE and once without, the memmgr code may not be able to tell whether a change was made through the MAP_NOSYNCFILE mapping or not, and thus write out changes that weren't intended.
• Since a process that has requested I/O privileges (by calling ThreadCtl(_NTO_TCTL_IO,...)) can't allow page faults, the memory manager is unable to track individual page modifications. This means that although memory-mapped files obey the POSIX semantics, the memory-manager code may write more pages than it needs to back to the underlying file, and may write the same page multiple times.
• There's a new function:

  int munmap_flags(void *addr, size_t len, unsigned flags);
      

  The flags have the following allowable values:

  0

  Behave the same as munmap().

  UNMAP_INIT_REQUIRED

  POSIX initialization of the page to all zeros is required the next time the underlying physical memory is allocated.

  UNMAP_INIT_OPTIONAL

  Initialization of the underlying physical memory to zeros on its next allocation is optional.

• The mmap() function has a new flag, MAP_NOINIT. When specified, the POSIX requirement that the memory be zeroed is relaxed. This allows for faster starting, but can open a security vulnerability. By default, the kernel initializes the memory.

  The physical memory being used for this allocation must have been previously freed with UNMAP_INIT_OPTIONAL for this flag to have any effect.

• The procnto command line now has an -mmemmgr_configuration option. The memmgr_configuration string is a sequence of configuration options to enable (or if preceded with a ~ character, disable) memory-manager aspects. The configuration options include:

  i

  munmap() acts as if UNMAP_INIT_REQUIRED were specified (the default).

  ~i

  munmap() acts as if UNMAP_INIT_OPTIONAL were specified.

  l

  (“el”) Lock all memory; act as if mlockall(MCL_CURRENT|MCL_FUTURE) were specified at the start of every program.

  ~l

  Don't lock all memory (the default).

  L

  Superlock all memory; act as if ThreadCtl(_NTO_CTL_IO, 0) were specified at the start of every program. This affects only the locking of memory; programs don't actually get I/O privileges.

  ~L

  Don't superlock all memory (the default).

  b

  Enable backward compatibility (the default).

  We fixed some bugs when we redesigned the memory manager. In some cases, this could make application code that ran in earlier versions of the OS now fail, if they inadvertently depended on the buggy behavior. The b configuration option attempts to make the new memory manager act like the old one in terms of some bugs, so that old code can continue to work until you can correct the application.

  ---

  With 6.3.2, the b option is on by default. In the next major release of the OS, we intend to turn it off by default.

  ---

  Currently, the only thing it affects is the behavior of the MAP_BELOW16M flag to mmap(). Previous releases didn't respect this flag on non-x86 architectures. With backwards compatibility that continues to be the case. Without backwards compatibility, MAP_BELOW16M is honored on all architectures, which could cause a mmap() that worked before to now fail.

  ~b

  Disable backward compatibility.

• The pthread_attr_getstackprealloc() and pthread_attr_setstackprealloc() functions have been added to get and set the size of memory to preallocate for a MAP_LAZY stack. By default, the system allocate 4 KB of physical memory for the initial stack reference. These functions let you change that if you know that a thread is going to require more stack space. Semantically, there will be no difference in operation, but the memory manager may be able to arrange to use a bigger page-table entry for the stack if it knows up-front that more memory will be needed.

What's new: Libraries and header files

System headers

We've changed the following header files to make them more POSIX_compliant:

• <limits.h> (Ref# 26160)
• <setjmp.h> (Ref# 26162)
• <stdlib.h> (Ref# 26163)
• <stdint.h> (Ref# 26166)
• <confname.h> (Ref# 26167)
• <wordexp.h> (Ref# 26171)

<sys/platform.h>

We've removed the obsolete XBS_ILP32_* symbols and replaced them with the _XBS5_ILP32_* equivalents. If you use the old definitions, you should update your code. (Ref# 26159)

ENDIAN_*()

We've added PPC-specific versions of these macros. (Ref# 22140)

FILE* I/O functions

If a FILE* stream is placed into unbuffered mode (so theoretically all writes should physically happen immediately and any failures be detected), the low-level functions correctly indicate the errors, but the FILE*-oriented output functions (fwrite(), fprintf(), etc.) formerly didn't set errno. They now do. For example, if there's no space left on the disk, these functions now correctly indicate that an error has occurred. (Ref# 19598)

fork()

• Physically contiguous areas are now preserved across a fork(). If one process does a mmap() with MAP_ANON|MAP_PHYS to obtain a physically contiguous memory (drivers and the like), and then forks, the child process now enforces contiguous areas when copying the parent's mappings. (Ref# 17531)
• If you do a mmap() with MAP_ANON|MAP_SHARED with permissions of PROT_NONE, and use mprotect() to change a single page to PROT_READ|PROT_WRITE, and then fork(), the permissions of the MAP_ANON|MAP_SHARED mapping are now correctly set per-page. (Ref# 24585)

getgrouplist()

The list of groups that this function creates no longer includes the group ID that you pass as the basegid argument. (Ref# 15547)

iofunc_funcs_t

The iofunc_funcs_t structure is now larger, and the _IOFUNC_NFUNCS count has increased. If you use memset() to initialize this structure, the change in size won't affect your resource managers.

If your resource managers use this callout table to install their own OCB allocation routines, and you didn't use memset(), recompiling your resource managers will cause the new callouts (for OCB locking) to be used. The libc library is backwards-compatible in that resource managers that haven't been recompiled won't attempt to use the new callouts, and a NULL callout means to use the default/old behavior.

pthread_getname_np(), pthread_setname_np()

You can use these functions to get and set the name of the threads in your applications.

remove()

If path names a directory, remove(path) is now equivalent to rmdir(path) instead of unlink(path), due to a change in POSIX. (Ref# 19534, 28319)

sigevent

Future versions of the library might use hidden bits in the sigev_notify member of the sigevent structure. To avoid problems in the future, don't compare this member directly to a constant; use the new SIGEV_GET_TYPE() macro. For example, instead of:

if( my_event.sigev_notify == SIGEV_PULSE) 
  

use:

if( SIGEV_GET_TYPE(&my_event) == SIGEV_PULSE) 
  

siginfo_t

The siginfo_t structure now has a new field, si_bdslot. When a signal is caused by a program exception (SIGSEGV, SIGILL, etc.), the field is nonzero if the faulting instruction is in a branch delay slot on architectures with them (MIPS, SH).

---

This is currently implemented only for MIPS. Earlier versions of procnto left this field as a random value, so code should check the procnto version number before examining the field.

---

What's new: Utilities

on

This utility now supports these new options (Ref# 13645):

• -R runmask — set the CPU affinity to runmask. You can use this option multiple times to specify masks that are more than 32 bits long.
• -C cpunum — set the CPU Affinity to cpunum, where the first CPU is 0. You can use this option multiple times.

If you use both the -C and -R options or multiple instances of them, the resultant mask is the bitwise ORing of all -C and -R options. (Ref# 28501)

pidin

This utility now supports these new formatting codes:

• H — display scheduling-specific information for each thread
• h — display the thread name
• i — display the runmask

and these new arguments:

• sched — display useful scheduling parameters for each thread
• extsched — display details of the active extended scheduler configuration
• fds —: show information about the process's file descriptors
• rmasks — display the process's runmask.

(Ref# 27982, 28098)

qconfig

This utility now displays more information about the products you've installed:

• The new -b option shows only the installed baseline product, e.g. QNX Momentics 6.3.0 SP1 or SP2. The output is the same as the old qconfig command without any options.
• The new -p option shows only the installed product updates, e.g. the QNX Neutrino Core OS 6.3.2.
• The new -a option shows all products (baseline and product updates) in machine-readable form.
• Without any options, qconfig lists all products in human-readable form.
• qconfig no longer lists 6.3.0 SP1 and SP2 as separate installations.

(Ref# 29245, 29579)

slay

• The meanings of these options have changed somewhat:
  • -R runmask — set the CPU affinity to runmask. You can use this option multiple times to specify masks that are more than 32 bits long.
  • -C cpunum — set the CPU Affinity to cpunum, where the first CPU is 0. You can use this option multiple times.

  If you use both the -C and -R options or multiple instances of them, the resultant mask is the bitwise ORing of all -C and -R options. (Ref# 28083)

• There's a new -i option that also sets the inherit mask when used in conjunction with -R or -C. (Ref# 27716, 29576)
• When you use -R or -C without -T, all threads in the specified process or processes are now affected. Previously -R or -C would fail without -T (Ref# 27716)
• -P without -T now affects all threads in the specified process or processes. Previously it affected only thread 1. (Ref# 27817)
• You can now identify the processes by name or ID. By default, slay matches either name or pid; you can use the new -m name or -m pid option to restrict the match. (Ref# 28890)

tracelogger

If you specify a duration for the log (with the -s option), then the number of iterations logged is once again unlimited instead of being set to 32. (Ref# 26823)

What's new: Startup

• All startup-* commands have a new command-line option that lets you control the flags field in the cpuinfo section of the system page:

  -F value

  OR the flags field with value.

  -F ~value

  AND the flags field with ~value.

• We added support for the x86 NX (no-execute) page table bit. On processors that support it (AMD64, IA-32e), mmap()'d memory no longer lets you execute instructions in that memory unless you've specified the PROT_EXEC permission flag. If not specified, a SIGSEGV occurs.

  ---

  You must enable page-table extensions (with the -x startup option) in order for the NX bit to be effective.

  ---

  You can turn off support by putting -F ~0x4000 on the startup command line.

Known issues

The QNX Neutrino Core OS 6.3.2 contains known issues in these areas:

• Key issues you should know about
• Kernel
• Libraries and header files
• Filesystems
• Networking
• Utilities
• IDE (Professional Edition only)
• Startup
• Uninstalling

---

We're actively investigating all known issues. See also the release notes for the version of QNX Momentics (6.3.0 SP1 or SP2 ) that you've installed on your system.

---

Key issues you should know about

• Some calls to mmap() with MAP_ANON or MAP_LAZY may be slower with the QNX Neutrino Core OS 6.3.2 than with earlier releases on certain platforms. The difference is more pronounced for small sizes (e.g. 4 KB). For larger sizes (more than 32 KB), performance may be the same or better with 6.3.2. It might take longer to start applications and create threads. In part, this is due to the virtual memory manager's more complete data structures. (Ref# 26280, 27831, 29341)
• The kernel might crash on the Freescale Power Quicc III board when there's a heavy networking load. This problem occurs only when the core-to-system clock ratio is set to 2:1. The problem also exists with earlier releases of QNX Neutrino. We're still determining the root cause. (Ref# 27079)
• The change in the memory manager for the Core OS 6.3.2 generates information that causes the Process Memory Map view in the IDE (6.3.0 SP2 and earlier) to misclassify memory maps. In general, HEAP-type allocations are classified as OBJECTs. The memory block size and address information are correctly displayed. (Ref# 29748)
• procnto and the underlying filesystem may become deadlocked when you use read/write memory-mapped files with multiple threads, under the following circumstances:
  • If you have multiple writable mappings to the same region of the file (in different processes, for example), then calling msync() with MS_SYNC can cause a deadlock.
  • If you have multiple mappings to files that use the same underlying resource manager, and these mappings are first referenced simultaneously (e.g. the first reference in a program), there is the potential for a deadlock if the number of simultaneous first references exceeds the number of threads in the underlying resource manager.

  (Ref# 29596, 29440, 29380)

Known issues: Kernel

procnto

• Multiple concurrent calls to shm_unlink() for the same shared memory object can cause kernel corruption and crash the kernel. (Ref# 18121)
• We've observed some memory corruption for uncacheable memory with the Renesas BigSur (SH7751) board. It might be a problem with the hardware. (Ref# 27741)
• Some calls to mmap() with MAP_ANON or MAP_LAZY may be slower with the QNX Neutrino Core OS 6.3.2 than with earlier releases on certain platforms. The difference is more pronounced for small sizes (e.g. 4 KB). For larger sizes (more than 32 KB), performance may be the same or better with 6.3.2. It might take longer to start applications and create threads. In part, this is due to the virtual memory manager's more complete data structures. (Ref# 26280, 27831, 29341)
• A potential deadlock exists in the malloc library when you're using vfork() and exec() if the vforked child receives a termination signal while holding the malloc library mutex. (Ref# 28161)
• If you're in a directory on a remote machine, and you pipe the output of a command to xargs, and you redirect the output to a file, you get a “cannot fork” error. For example:

  cd /net/remote_machine/tmp
  find . -type f | xargs grep FAIL > report.txt
  /bin/sh: cannot fork - try again
      

  It seems to be a problem with permissions. Piping the output of xargs to less works. (Ref# 29834)

  Workaround: Log in as root.

• procnto and the underlying filesystem may become deadlocked when you use read/write memory-mapped files with multiple threads, under the following circumstances:
  • If you have multiple writable mappings to the same region of the file (in different processes, for example), then calling msync() with MS_SYNC can cause a deadlock.
  • If you have multiple mappings to files that use the same underlying resource manager, and these mappings are first referenced simultaneously (e.g. the first reference in a program), there is the potential for a deadlock if the number of simultaneous first references exceeds the number of threads in the underlying resource manager.

  (Ref# 29596, 29440, 29380)

• On PowerPC and SH4, if an msync() operation (with MS_INVALIDATE) is performed on a lazy mapping (a mmap() of anonymous memory with MAP_LAZY), the msync() causes the lazy pages to get allocated and mapped in. (Ref# 29647)

procnto-booke

• The kernel might crash on the Freescale Power Quicc III board when there's a heavy networking load. This problem occurs only when the core-to-system clock ratio is set to 2:1. The problem also exists with earlier releases of QNX Neutrino. We're still determining the root cause. (Ref# 27079)

mq

If you use the instrumented kernel to trace events while you're using mq, emitting _NTO_TRACE_COMM_SMSG communication-class events might cause your application to crash with an EFAULT when it calls mq_send(). We've encountered this problem on SHLE boards. (Ref# 38082)

Workaround: Filter out the _NTO_TRACE_COMM_SMSG events by doing one of the following:

• On the command line, filter out all COMM-class messages by passing the -F6 option to tracelogger.
• In your application, filter out COMM_SMSG messages by calling:

  TraceEvent( _NTO_TRACE_DELEVENT, _NTO_TRACE_COMM, _NTO_TRACE_COMM_SMSG);
      

• In the IDE, filter out COMM_SMSG messages with qconn by selecting the Class Specific mode in the System Profiler Configuration dialog, then selecting the Communication tab, selecting the Event Specific mode, and then disabling Send Message.

The side effect of filtering out these events is that the IDE's System Profiler won't be able to show you any message-passing.

Known issues: Libraries and header files

ENDIAN_*()

This release includes inline assembly optimization on some platforms for the ENDIAN_*() (byte-swapping) routines.

These routines are macros that determine the best method to perform the byte-swapping (as inline math using shift-and-mask operations that may be constant-folded at compile time, or as inline assembly using native CPU instructions at runtime). Due to a bug in the gcc 2.95.3 __builtin_constant_p() implementation, code compiled with gcc 2.95.3 always selects the assembly variant.

This means that if you use an ENDIAN_*() expression as a static initializer, it fails to compile. For example, if you use gcc 2.95.3 to compile the following code:

static uint32_t numbers[] = {
ENDIAN_LE32(0x39c39c39),
ENDIAN_BE32(0x39c39c39)
};
  

you'll get an initializer element is not constant compile error. (Ref# 27099)

Workaround: Do one of the following:

• If you're defining the structure inside a function body, remove the static qualifier, which causes the data structure to be initialized at runtime rather than compile time, at which stage inline assembly is valid.
• Compile affected code with gcc 3.3.5, which has a fixed __builtin_constant_p() that allows detection of a constant expression and implements the byte-swapping with shift and mask operations. You can choose gcc 3.3.5 by specifying the appropriate -V compiler version to cc or gcc, or by setting GCC_VERSION=3.3.5 within a Makefile or common.mk environment.

---

This affects only static initializers containing ENDIAN_*() expressions, and doesn't apply to any runtime use of these ENDIAN_*() macros.

---

libmalloc

The debug malloc library no longer works on SH platforms. (Ref# 27639)

Workaround: Download the Debug Malloc Library Patch (Patch ID 155) from our website.

Known issues: Filesystems

/dev/shmem

Large block writes to /dev/shmem are slower than in the last release. (Ref# 26280)

Known issues: Networking

io_net

On MIPSLE Malta boards, io-net may crash with a SIGBUS signal when using the pcnet network driver. This is due to a bug in the pcnet driver. (Ref# 28177)

Workaround: Download the Network Driver Patch (Patch ID 153) from our website.

Known issues: Utilities

slay

Trying to slay something on a node in a domain other than your own will fail. For example, if you're in domainX, and you try to slay something on node foo in domainY, you'll see this:

# slay -n foo.domainY process_name
slay: Unable to find process 'process_name'
  

(Ref# 29840)

Known issues: IDE (Professional Edition only)

• The kernel now supports thread names (Ref# 27085), but the IDE can't currently display them.
• The change in the memory manager for the Core OS 6.3.2 generates information that causes the Process Memory Map view in the IDE (6.3.0 SP2 and earlier) to misclassify memory maps. In general, HEAP-type allocations are classified as OBJECTs. The memory block size and address information are correctly displayed. (Ref# 29748)

Known issues: Startup

• A situation exists on PowerPC-based boards with less than 256 MB of RAM whereby a machine check can be received. This is due to a speculative load (for a branch not taken) from a memory address beyond the extent of physical RAM but within the first 256 MB window. This condition has been detected only on a Freescale MGT5200 Lite with 64 MB of memory and only during the execution of a specific sequence of regression and benchmark tests on the 6.3.2 kernel. The possibility of occurrence has existed in all previous Neutrino releases; however, to best of our knowledge, no such failures have been reported. (Ref# 28335)

  Workaround: A requirement of startup code for PowerPC-based boards is to configure the DBAT0 register. The register is currently configured for a minimum size of 256 MB. Initializing DBAT0U[BL] to the exact (power of 2) size of physical memory will eliminate this situation from producing a machine check exception. Alternatively, if possible on the particular board, disabling the assertion of TEA will also prevent the errant (speculative load for a branch not taken) machine check when this specific situation occurs. This option should be considered in the context of the entire system. Please contact QNX for specific questions about these and other workarounds

Known issues: Uninstalling

On self-hosted Neutrino systems, if you uninstall the QNX Neutrino Core OS 6.3.2, the uninstaller rebuilds the boot image in /.boot and tells you to rebuild the image manually if you use a custom image. If you rebuild your boot image at this point, mkifs will crash. (Ref# 30079)

Workaround: After the uninstaller has rebuild the boot image, do the following:

1. If you need a non-DMA image, copy the one that the uninstaller has just rebuilt:

   cp /boot/fs/qnxbase.ifs /.boot
     

2. Reboot your machine.
3. Rebuild your custom image:

   mkifs your_build_file /.boot

4. Reboot your machine again.

Getting started with the documentation

After you've installed your development suite, you'll find an extensive set of online documentation in HTML format. Go to the help menu item (e.g. in Windows XP: All Programs-->QNX Momentics-->Documentation) or look under the following directory:

${QNX_TARGET}/usr/help/product/momentics/bookset.html

This “roadmap” page contains links to the various HTML booksets that accompany the OS (e.g. System Architecture, Programmer's Guide, Library Reference, Utilities Reference, etc.).

You'll find the installation and release notes in the base_directory/install/ntocore/6.3.2 directory. To determine your base_directory, see the installation notes.

---

For the most up-to-date version of the installation and release notes, go to our website, www.qnx.com, log into your myQNX account, and then go to the Download Center.

---

You can install and work with multiple versions of QNX Neutrino. Whether you're using the command line or the IDE, you can choose which version of the OS to build programs for. For more information, see the IDE User's Guide or the QNX Neutrino Programmer's Guide.

---

Coexistence of 6.3 and 6.2.1 is supported only on Windows and Solaris hosts.

---

Technical support

If you have any questions, comments, or problems with a QNX product, please contact Technical Support. For more information, see the How to Get Help chapter of the online version of the Welcome to QNX Momentics guide, or visit our website, www.qnx.com.

---

The telephone numbers and email addresses for Technical Support in the printed version of the Welcome to QNX Momentics guide are now obsolete. (Ref# 26700)

---

List of fixes

The problems fixed in the QNX Neutrino Core OS 6.3.2 include the following: