QNX Technical Articles

Date of this edition: January 14, 2005

Target OS: QNX^® Neutrino^® 6.3.0

Host OS: Microsoft Windows XP SP1 or 2000 SP4; Sun Solaris 7/8; QNX^® Neutrino^® 6.3.0; Linux (Red Hat 8/9)

This patch addresses various problems, but most importantly, it fixes the one reported earlier for the SH4 architecture:

When mapping a region of either anonymous memory or a shared memory object as non-cacheable, the contents on the underlying memory may become inconsistent. This is due to stale data from previous mappings of the same page(s) that are still resident in the processor cache. This can result in random corrupted memory with serious consequences, such as improper audio playback and device driver faults. This problem is limited to the SH4 architecture.

To fix the problem of stale data corrupting a non-cached memory mapping, the temporary cached mapping used to initialize the mapping is explicitly flushed after initialization. This ensures that the initialized data has been propagated out to the main memory, and thus the non-cached view should be consistent.

This patch is included in QNX Momentics 6.3.0 Service Pack 1. We highly recommend that you install SP1 instead of this patch. For information on installing this patch, see the SH4 Critical Patch Installation Note.

Contents...

• Fixed issues
  • procnto*, procnto*-instr
  • Other components
• Known issues
• Documentation
• Technical support

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.

Fixed issues

procnto*, procnto*-instr

This patch addresses the following issues for procnto* and procnto*-instr:

• The pidin utility blocked when reporting process states in a CIFS system.

  Due to some other problems (Ref# 21521 and 21484), a thread in procnto was spinning, trying to call msync() because of a failed mapping. Because the address space of the process that called msync() was locked, pidin couldn't access it. (Ref# 21434)

• On all SH4 systems with multiple-way cache systems, the system could incorrectly report an out-of-memory condition under low-memory conditions. (Ref# 21452)
• Attempting to call msync() on an illegal or unmapped address caused a thread in procnto to lock up and never return. The process's address space was also held locked during this time, which could have caused other messages (such as mmap()) to block. (Ref# 21484)
• During the creation of a shared object, an error during the initialization (either allocation of backing store memory or reading of contents from the filesystem) resulted in a partially created object. The mmap() function returned a virtual address, but accessing that memory resulted in a SIGSEGV. (Ref# 21521)
• During creation of a shared object, the object was initialized via a (temporary) cached mapping. If the final mapping was non-cached (i.e. PROT_NOCACHE), it's possible that writes to this object could then have been overwritten by data that was being flushed from the previous cached copy. (Ref# 21335)
• A color misconfiguration/misuse contributed to an early ENOMEM as memory was exhausted in SH4 platforms. We fixed the pgtbl mapping (mem_page_map), so that table allocations that are non-cached really have no color preference (0 is actually a color). (Ref# 21156)
• The kernel wasn't clearing all session data when Qnet was terminated. This could have occurred only if there were open connections to a remote node at the time. If you restarted Qnet, it could have been unstable, causing data corruption on a new Qnet session, or causing io-net to fault. This has been fixed. (Ref# 20817)
• If you used mmap() with the MAP_ANON|MAP_PHYS|MAP_SHARED flag combination to create a mapping to an anonymous shared object with physically contiguous anonymous memory, you may not have always ended up with physically contiguous memory. (Ref# 20478)
• Using the debug procfs interface to read memory from io-net (with Qnet loaded) on a remote node could lock up, due to a resource deadlock. (Ref# 19697)
• When building a driver that took over an interrupt from a mini-driver, if you used InterruptAttachEvent() with the bit _NTO_INTR_FLAGS_END ORed in the flag argument, the interrupt wasn't properly unmasked or masked after the interrupt was enabled at the source. This caused "out of interrupt events" messages to appear. (Ref# 20110)
• Single-stepping into a kernel call could have caused the kernel call to fail with an ENOSYS. On taking a debug exception on entering the kernel, the EAX register holding the syscall number was corrupted. When returning to the normal code path for kernel entry, the syscall number was invalid, resulting in a bad kernel call.

  This could have shown up when you used gdb to do a source-line step over a kernel call (or a library function that did a kernel call, such as mmap()). (Ref# 19351)

• Passing an invalid file descriptor to mmap() for operations that require a valid file descriptor could have caused procnto to crash. (Ref# 19126)
• The previous versions of procnto and procnto-instr for SHLE didn't invalidate the data cache properly on requests for PROT_NOCACHE memory. As a result, if that memory had been used through a cached mapping (and unmapped) shortly before, a cache line castout/flush could have corrupted an already in-use noncacheable mapping.

  This memory-corruption bug affected programs that allocated noncacheable RAM from the system. This bug didn't affect noncacheable mapping to device registers in device drivers.

  We saw the impact of this bug on the QNX SH4 USB driver, which couldn't start properly because its noncacheable RAM mapping was corrupted. Other QNX-supplied drivers on the SH4 platform that might have been affected by this problem are devb* (e.g. devb-eide), most*, deva* (e.g. deva-tahoe), devn*, devu*, and devg* (e.g. devg-amanda). (Ref# 19459)

• A problem with instrumentation could have caused kernel stack overflow when instrumentation was turned on in SH4 platform. We moved the instrumentation event after the shadow mask snapshot. The event itself was modifying the SR register before we could snapshot it properly, enabling interrupts being they should have been. (Ref# 21039)

Other components

This patch also addresses the following issues:

fs-nfs2, fs-nfs3

If an unexpected packet taking the form of a RPC response "NFS NULL" packet arrived while there was a pending open() from a client application that the server hadn't yet responded to, fs-nfs2 or fs-nfs3 may have faulted. A packet like this could be generated by a misconfigured server. (Ref# 21480)

fs-cifs

When fs-cifs connected to a Windows server, a unique session was created. When a second fs-cifs process was started, it didn't specify an identifier different from the first instance, and confused the server, which thought that the original fs-cifs process had reestablished its connection. The server then terminated the first session.

This repeated: the second session was disconnected when the first fs-cifs detected that it had been disconnected, and so reestablished its link to the server. This continued back and forth each time file access was required from the server.

This issue has been fixed, and multiple CIFS sessions are supported, which can enhance performance. These modifications also allow a fs-cifs process to create a local mountpoint nested within the local mountpoint path of another fs-cifs process. (Ref# 15452, 21532)

io-hid, hidview

Release 6.3.0 didn't include these utilities for SHLE. (Ref# 20843)

io-usb

• The io-usb server may have faulted if a USB client driver detached from a device without aborting active transactions. Drivers should abort transactions before detaching from a device. We changed io-usb to automatically abort transactions for a client driver when it detaches from a device. (Ref# 21424)
• We fixed a problem with USB hubs on Big Sur/Amanda. URBs didn't automatically abort when the usb utility detached from the stack. This caused an error if you ran usb before and after unplugging a USB device from a USB hub. (Ref# 21624)

devu-mouse, devu-keyboard

While slaying devu-mouse or devu-kbd, the driver could have faulted. The driver was changed to properly abort/wait for all USB transactions to complete before freeing memory used in the enqueued USB transactions. (Ref# 21422)

devb-umass

The mass-storage driver didn't work on Big Sur/Amanda. The driver would run, and the device entry would be created, but the partition information wouldn't show up. (Ref# 21251)

libusbdi.so.2

In some circumstances, USB client drivers would fault on startup. Clients were notified of device insertion before the memory was completely initialized. (Ref# 21432)

devu-ehci.so

• The driver aborted transactions but the hardware still issued tokens on the USB bus for the aborted transaction. The EHCI chip cached the schedule for device endpoints and overwrote the status for the aborted transaction. (Ref# 21545)
• When enqueuing a transaction while some other transaction completed and was being processed, it was possible for the completion code to complete the transaction currently being enqueued for a device. (Ref# 21546)
• It was possible for clients not to be notified of a completed transaction until a successive USB transfer occurred. The EHCI chip hadn't updated the in-memory transaction status at the the time of interrupt. The driver was changed to also check the status from the schedule's "endpoint cached area." See the EHCI documentation for details. (Ref# 21547)

devn-smc9000

• We implemented a workaround for a device-lockup condition that happened when a receive overrun occurred on the devn-smc9000.so driver. (Ref# 21392)
• We fixed an unaligned data access in the devn-smc9000.so driver that may have caused io-net to SIGBUS. The SH4 Critical Patch includes the new binary; the BSP source patches include the new source. (Ref# 19170)

libgri.a, libgri.so

Entering into Photon direct mode could have failed, due to an error in the size of the region data used for a region change. (Ref# 21708)

<netinet6/in6.h>

Compiling a C++ application using this header file (which <arpa/inet.h> includes) resulted in an error:

In file included from /usr/qnx630/target/qnx6/usr/include/arpa/inet.h:79,
from tst.cc:3:
/usr/qnx630/target/qnx6/usr/include/sys/types.h:263: error: `size_t' not
declared

This has been fixed. (Ref# 21204)

<kvm.h>

Compiling a C++ application using this header file results in an error related to undefined references. This has been fixed. (Ref# 19974)

npm-qnet.so

Depending on how the discovery takes place, a 128-byte buffer of memory can be lost at the initial discovery of each peer node on the network. This has been fixed. (Ref# 19242)

npm-pppmgr.so

The PPPD dial-on-demand feature didn't work when used in combination with the persist pppd option. This has been fixed. (Ref# 19667)

Known issues

The SH4 Critical Patch contains known problems in these areas:

devn-smc9000

• The SMC9000 driver has an auto-negotiation issue. (Ref# 21541)

  Workaround: Use command-line arguments to specify the speed and duplex setting for the driver.

• Not all IPv6 multicast protocols function properly with this driver. (Ref# 21720)

io-usb

The following issues will be fixed in a future version of io-usb:

• Mounting and unmounting USB DLLs in a tight loop while plugging and unplugging USB devices that are using the DLLs may cause io-usb to crash. (Ref# 21556)
• In some cases when unmounting DLLs and running the usb utility at the same time, some memory allocated by io-usb isn't freed. This is a rare situation. (Ref# 21716)

The upcoming SH4 Floating Point Patch will address the issues concerning floating-point arithmetic.

Documentation

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

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 Welcome to QNX Momentics guide or visit our website, www.qnx.com.