|
|
This technical note explains issues that some developers may see when using their drivers in Panther (the next major version of Mac OS X) or later, along with issues specific to the Power Macintosh G5.
[Jun 24, 2003]
|
Introduction:
This technical note explains issues that some developers may see when using their drivers in Panther or later. These changes were necessitated by a combination of hardware and underlying OS changes; however, you may see problems resulting from the changes even on existing hardware.
There are three basic areas of change in Panther. These are:
IOMemoryDescriptor changes
- VM system (pmap) changes
- Kernel dependency changes
These are described in detail in the sections that follow.
Back to top
Background Info on PCI Address Translation:
To allow existing device drivers to work with upcoming 64-bit
system architectures, a number of changes were required. To explain
these, a brief introduction to PCI bus bridges is needed.
When a PCI device needs to perform a data transaction to or from
main memory, the device driver calls a series of functions intended
to prepare this memory for I/O. In an architecture where both the
device drivers and the memory subsystem use 32-bit addressing,
everything just works, so long as the memory doesn't get paged out
during the I/O operation. As kernel memory is generally not
pageable, the preparation is largely superfluous.
On a system whose memory subsystem uses 64-bit addressing,
however, this becomes a bit of a problem. Because the hardware
devices on the PCI bus can only handle 32-bit addresses, the device
can only "see" a 4 gigabyte aperture into the (potentially much
larger) main memory at any given time.
There are two possible solutions for this problem. The easy (but
slow) solution would be to use "bounce buffers". In such a design,
device drivers would copy data into memory specifically allocated
within the bottom 4 gigs of memory. However, this incurs a
performance penalty and also puts additional constraints on the lower
4 gigs of memory, causing numerous problems for the VM system.
The other solution, the one chosen in Apple's 64-bit
implementation, is to use address translation to "map" blocks of
memory into the 32-bit address space of the PCI devices. While the
PCI device can still only see a 4 gig aperture, that aperture can
then be non-contiguous, and thus bounce buffers and other
restrictions are unnecessary. This address translation is done using
a part of the memory controller known as DART, which stands for
Device Address Resolution Table.
This introduces a number of potential problems, however. First,
physical addresses as seen by the processor no longer map 1:1 onto
the addresses as seen by PCI devices. Thus, a new term, I/O
addresses, is introduced to describe this new view. Because I/O
addresses and physical addresses are no longer the same, the DART
must keep a table of translations to use when mapping between them.
Fortunately, if your driver is written according to Apple guidelines
(using only documented APIs), this process is handled
transparently.
Back to top
IOMemoryDescriptor changes:
When your driver calls IOMemoryDescriptor::prepare, a
mapping is automatically injected into the DART. When it calls
IOMemoryDescriptor::release, the mapping is removed. If
you fail to do this, your driver could experience random data
corruption or panics.
Because the DART requires different caching for reads and writes,
the DMA direction is important on hardware that includes a DART.
While you may receive random failures if the direction is wrong in
general (on any system), if you attempt to call
WriteBytes on a memory region whose DMA direction is set
up for reading, you will cause a kernel panic on 64-bit hardware.
If you attempt to perform a DMA transaction to unwired (user)
memory, on previous systems, you would only get random crashes,
panics, and data corruption. On machines with a DART, you will
likely get no data whatsoever.
As a side-effect of changes in the memory subsystem, Mac OS X is
much more likely to return physically contiguous page ranges in
memory regions. Historically, Mac OS X returned multi-page memory
regions in reverse order, starting with the last page and moving
towards the first page. The result of this was that multi-page
memory regions essentially never had a contiguous range of physical
pages.
Because of the increased probability of seeing physically
contiguous blocks of memory in a memory region, this change may
expose latent bugs in some drivers that only show up when handling
contiguous ranges of physical pages, which could result in incorrect
behavior or panics.
Note that the problems mentioned above are caused by bugs in the drivers, and could result in problems on older hardware prior to Panther. These issues are more likely to occur in Panther and later versions of Mac OS X, however, because of the new hardware designs and the OS changes that were made to support those designs.
Back to top
VM System and pmap Changes:
In Panther, as a result of the changes described in detail in the section on PCI address translation, physical addresses obtained directly from the pmap layer have no useful purpose outside the VM system itself. To prevent their inadvertent use in device drivers, the pmap calls are no longer available from kernel extensions.
A few drivers written prior to the addition of the
IOMemoryDescriptor class still use pmap calls to get the
physical pages associated with a virtual address. Also, a few
developers have looked at the IOMemoryDescriptor
implementation and chosen to obtain addresses directly from the pmap
layer to remove what was perceived as an unnecessary abstraction
layer.
Even without removing access to the pmap calls, these drivers would not function on systems with a DART (see the PCI section above for info on DARTs). To better emphasize this upcoming failure, Panther will cause these drivers to fail to load with an undefined symbol error (generally for pmap_extract) even
on systems without a DART.
Back to top
Kernel Dependency Changes:
Beginning in Panther, device drivers that declare a dependency on version 7 (the Panther version) of the I/O Kit will no longer automatically get symbols from Mach and BSD. This change was made to discourage I/O Kit developers from relying on symbols that are not explicitly approved for use in the I/O Kit.
Existing drivers are unaffected by this change. This change only
affects you if you explicitly modify your device driver to declare a
dependency on version 7 of the I/O Kit to take advantage of new I/O
Kit features.
Back to top
Summary:
As described above, some device drivers may require minor modifications to support Panther and higher. Apple has made every effort to ensure compatibility with existing device drivers to the greatest extent possible, but a few drivers may break. If your driver breaks, you should first check to see if your driver includes any of the bugs described in the previous sections. If it does not, contact Apple Developer Technical Support for additional debugging suggestions.
| 
