Chapter 29 Using USB Devices (Overview/Tasks)

This chapter provides an overview of Universal Serial Bus (USB) devices and step-by-step instructions for using USB devices in the Solaris environment.

For information on the procedures associated with using USB devices, see the following:

• Managing USB Devices in the Solaris Environment (Roadmap)

• Using USB Mass Storage Devices (Task Map)

• Hot-Plugging USB Devices (Task Map)

• Using USB Audio Devices (Task Map)

• Hot-Plugging USB Devices With the cfgadm Command (Task Map)

This is a list of the overview information in this chapter.

• What's New in USB Devices?

• Overview of USB Devices

• About USB in the Solaris Environment

• Using USB Mass Storage Devices

• Using USB Audio Devices

• Troubleshooting USB Audio Device Problems

For general information about dynamic reconfiguration and hot-plugging, see Chapter 28, Dynamically Configuring Devices (Tasks).

For information on configuring USB printers, see “What's New in Printing?” in System Administration Guide: Advanced Administration.

What's New in USB Devices?

The following sections describe USB device enhancements in this Solaris release.

USB Dual Framework

The existing USBA framework, found in the Solaris 9 12/03 release, was originally developed for USB 1.1 devices. A new framework, called USBA 1.0, was created to meet more demanding requirements of USB 2.0 devices. The framework operates USB 1.1 devices as well. This Solaris release provides both frameworks, hence the name dual framework. The purpose of the dual framework is to facilitate a smoother transition from the original framework to the newer framework.

• SPARC systems – The original USBA framework operates devices connected to a system's USB 1.1 ports, while the new USBA 1.0 framework operates devices connected to a system's USB 2.0 ports. All Sun motherboard ports are USB 1.1 ports, while most PCI card ports support USB 2.0.

• x86 systems – The original USBA framework operates devices connected to a system's UHCI USB 1.1 ports, whereas the new USBA 1.0 framework operates all other ports, including OHCI USB 1.1 ports.

For specific details on the how the USB dual framework works, go to http://www.sun.com/desktop/whitepapers.html.

USB Framework Compatibility Issues

A driver written for one USB framework will not work on the other USB framework. Most Sun-supplied USB drivers provide versions for both frameworks.

Compatibility problems might occur if you attempt to plug a USB device into a port, directed by a framework that does not recognize a proper driver for that device because the driver is incompatible. When a framework tries to attach a framework-incompatible driver for a device, you will see console messages similar to the following:

The driver for device binding name is not for USBA1.0  

This message will appear, for example, when a device operated by a non-Sun driver, which is compatible with USBA 1.0 framework, is plugged into a port supported by the original USBA 1.0 framework. The USBA 1.0 framework recognizes the device and tries to map the correct driver, but the driver is rejected because it is incompatible with the framework operating the port.

For information on identifying your USB framework configuration, see How to Display USB Device Information (prtconf).

Solaris Support for USB Devices

The following table describes Solaris support for USB 1.1 and USB 2.0 devices:

*Note that this is not the Solaris 8 releases, but the Solaris 8 HW releases, starting with the Solaris 8 HW 5/03 release. The patch number for the USB dual framework found in the Solaris 8 HW 5/03 release is 109896.

The following table provides a summary of USB support on Sun hardware:

For information about PCI cards verified on the Solaris release, go to: http://www.sun.com/io_technologies/USB.html

Sun Microsystems platforms that provide support for USB devices include the following:

• SPARC based systems with OHCI host controllers that support USB 1.1 provide low- and full-speed devices:

  • Sun Blade^TM systems that run the Solaris 8 or 9 releases.

  • Netra^TM X 1/T1 and some Sun Fire^TM systems that run the Solaris 9 release.

• SPARC based systems with OHCI and EHCI host controllers, such as the Sun Blade 1500 or 2500 systems, provide high-speed support for USB 2.0 devices and low- and full-speed support for USB 1.1 devices. Systems include any PCI-based sun4u system that run the Solaris 8 HW 5/03 release or Solaris 9 4/04 release, including the systems listed above when they are equipped with a USB 2.0 PCI card.

• x86 based systems that run the Solaris 8 or 9 x86 Platform Editions with the following controller types:

• OHCI or UHCI host controllers provide USB 1.1 support

• EHCI and OHCI host controllers together provide USB 1.1 and 2.0 support

• Use of USB 2.0 devices on ports that are operated by host controller hardware with EHCI and UHCI on the same chip or PCI card, is not recommended.

For additional USB support information, see Overview of USB Devices.

USB 2.0 Features

This Solaris release includes the following USB 2.0 features:

• Better performance – Increased data throughput for devices connected to USB 2.0 controllers, up to 40 times faster than USB 1.1 devices.

  You will be able to take advantage of the high-speed USB protocol when accessing high-speed mass storage devices, such as DVDs and hard drives.

• Compatibility – Backward compatibility with 1.0 and 1.1 devices and drivers so that you can use the same cables, connectors, and software interfaces.

For a description of USB devices and terminology, see Overview of USB Devices.

USB 2.0 Devices Features and Compatibility Issues

USB 2.0 devices are defined as high-speed devices that follow the USB 2.0 specification. You can refer to the USB 2.0 specification at http://www.usb.org.

Some of the USB device that are supported on SPARC based and x86 based systems in this Solaris release are as follows:

• Mass storage devices – CD-RWs, hard disks, DVD, digital cameras, Zip, diskettes, and tape drives

• Keyboard, mouse devices, speakers and microphones

• Audio devices

For a full listing of USB devices that have been verified on the Solaris release, go to:

http://www.sun.com/io_technologies/USB.html

Additional storage devices might work by modifying the scsa2usb.conf file. For more information, see the scsa2usb(7D) man page.

Solaris USB 2.0 device support includes the following features:

• Increased USB bus speed from 12 Mbps to 480 Mbps. This increase means devices that support the USB 2.0 specification can run significantly faster than their USB 1.1 counterparts, when they are connected to a USB 2.0 port.

  A USB 2.0 port is defined on SPARC and x86 systems as follows:

  • A port on a USB 2.0 PCI card

  • A port on a USB 2.0 hub that is connected to USB 2.0 port

  • x86 only - A system USB port, assuming that it has a USB 2.0 port on the motherboard

• USB 2.0 is Solaris Ready on all PCI-based platforms. A USB 2.0 PCI card is needed to provide USB 2.0 ports. For a list of USB 2.0 PCI cards that have been verified for the Solaris release, go to http://www.sun.com/io_technologies/USB.html.

• USB 1.1 devices work as they have in the past, even if you have both USB 1.1 and USB 2.0 devices on the same system, except as noted below.

  ---

  Note –

  USB 1.1 devices will not operate when connected to a USB 2.0 hub that is connected to a USB 2.0 port.

  ---

• While USB 2.0 devices operate on a USB 1.x port, their performance is significantly better when connected to a USB 2.0 port.

• Most USB 2.0 host controllers have one high-speed Enhanced Host Controller (EHCI) and one or more low- or full-speed OpenHCI Host Controller (OHCI) embedded controllers. Devices connected to a USB 2.0 port are dynamically assigned to either an EHCI or OHCI controller, depending on whether or not they support USB 2.0.

• Some USB 2.0 host controllers have one EHCI and one or more low- or full-speed Universal Host Controller (UHCI) embedded controllers. Low- and full-speed devices may be used with ports on these host controllers without issues. While high-speed devices connected to these ports might work as such, use of such devices on these ports is not recommended.

  ---

  Note –

  USB 2.0 storage devices connected to a port on a USB 2.0 PCI card, and that were used with a prior Solaris release in the same hardware configuration, can change device names after upgrading to this release. This change occurs because these devices are now seen as USB 2.0 devices and are taken over by the EHCI controller. The controller number, w in /dev/[r]dsk/cwtxdysz, is changed for these devices.

  ---

For more information on USB 2.0 device support, see the ehci(7D) and usba(7D) man pages.

USB 2.0 Cables

• Maximum cable length supported is 5 meters.

• Do not use cable extenders. For best results, use a self-powered hub to extend cable length.

• For more information, go to http://www.usb.org/channel/training/warning/

Bus-Powered Devices

Bus-powered hubs use power from the USB bus to which they are connected, to power devices connected to them. Special care must be taken to not overload these hubs, since the power these hubs offer to their downstream devices is limited.

• Do not cascade bus-powered hubs. For example, do not connect one bus-powered hub to another bus-powered hub.

• Avoid connecting bus-powered devices to bus-powered hubs, except for low-speed, low-power devices, such as keyboards or mice. Connecting high-powered devices such as disks, speakers, or microphones to a bus-powered hub could cause power-shortages for all devices connected to that hub. This scenario could cause these devices to behave unpredictably.

USB Mass Storage Devices

All USB storage devices in this Solaris release are now accessed as removable media devices. This change has the following advantages:

• USB storage devices with standard MS-DOS or Windows (FAT) file systems are now supported.

• You can use the user-friendly rmformat command instead of the format command to format and partition all USB storage devices. If the functionality of the format command is needed, use the format -e command.

• You can use the fdisk command if you need to do fdisk-style partitioning.

• Non-root users can now access USB storage devices, since the root-privileged mount command is no longer needed. The device is automatically mounted by vold and is available under the /rmdisk directory. If a new device is connected while the system is down, do a reconfiguration boot with the boot -r command so that vold recognizes the device. If a new device is connected while the system is up, restart vold. For more information, refer to the vold(1M) and scsa2usb(7D) man pages.

• Disks with FAT file systems can be mounted and accessed. For example:

  mount -F pcfs /dev/dsk/c2t0d0s0:c /mnt

• All USB storage devices are now power managed, except for those that support LOG SENSE pages. Devices with LOG SENSE pages are usually SCSI drives connected through a USB-to-SCSI bridge device. In previous Solaris releases, some USB storage devices were not power managed because they were not seen as removable media.

• Applications might work differently with USB mass storage devices. Keep the following issues in mind when using applications with USB storage devices:

  • Applications might make incorrect assumptions about the size of the media since only smaller devices like diskettes and Zip drives were removable previously.

  • Requests by applications to eject media on devices where this would be inapplicable, such as a hard drive, will succeed and do nothing.

  • If you prefer the behavior in previous Solaris releases where not all USB mass storage were treated as removable media devices, then you can force the old behavior by updating the /kernel/drv/scsa2usb.conf file.

For more information on using USB mass storage devices, see the scsa2usb(7D) man page.

Troubleshooting Tips for USB Mass Storage Devices

Keep the following tips in mind if you have problems adding or removing a USB mass storage device.

• If USB devices are added or removed when the system is down, you must perform a reconfiguration boot.

  ok boot -r

  If you have problems accessing a device that was connected while the system is running, try the following command:

  # devfsadm

• Do not move devices around if the system has been powered down by a suspend operation. For more information, see SPARC: USB Power Management.

• If a device has been hot removed while in use by applications and is no longer available, then stop the applications. Use the prtconf command to see whether the device node has been removed.

USB Driver Enhancements

This section describes USB driver enhancements in this Solaris release.

• New generic USB driver (ugen) features and support – USB devices can now be accessed and manipulated by applications using standard Unix read(2) and write(2) system calls, and without writing a special kernel driver. Additional features include:

  • Applications have access to raw device data and device status.

  • Supports control, bulk, and interrupt (in and out) transfers.

  Support for ugen is only available on ports operated by the USBA 1.0 framework.

  To discover whether a port is operated by the USBA 1.0 framework, plug the device into the port. Then, issue the prtconf -D command. The prtconf -D hierarchy tree shows the device on the port, which is currently unbound to a driver, as device. Traverse up the prtconf hierarchy tree until you see an entry that has a driver with ohci, ehci, or uhci in its name. The ohci, ehci, or uhci entry represents the host controller. If the host controller driver name begins with usba10_, the devices in it's subtree are operated by the USBA 1.0 framework.

  For more information, refer to the ugen(7D) man page and the USB DDK at:

  http://developers.sun.com/solaris/developer/support/driver/usb.html

• Digi Edgeport USB support – Provides support for several Digi Edgeport USB to serial port converter devices.

  • New devices are accessed as /dev/term/[0-9]* and /dev/cua/[0-9]*.

  • USB serial ports are usable as any other serial port would be, except that they cannot serve as a local serial console. The fact that their data is run through a USB port is transparent to the user.

  • x86 platforms – The Digi Edgeport USB serial driver is supported only on the USBA 1.0 framework. See the preceding section on ugen for information on determining how to tell which framework operates which ports.

  For more information, see usbser_edge(7D), or go to http://www.digi.com and http://www.sun.com/io.

• Documentation and binary support for user-written kernel and userland drivers – A Solaris USB Driver Development Kit (DDK) is available, and its documentation is applicable to the Solaris 10 release. For up-to-date information on USB driver development, including information on the DDK, go to:

  http://developers.sun.com/solaris/developer/support/driver/usb.html

The EHCI and OHCI Drivers

Features of the EHCI driver include:

• Complies with enhanced host controller interface that supports USB 2.0.

• Supports high-speed control, bulk, and interrupt transfers.

• Currently, there is no support for high-speed isochronous transactions. It is possible that some USB audio devices might eventually use high-speed isochronous transactions.

If there are USB 2.0 and USB 1.x devices on the system, the EHCI and OHCI drivers hand-off device control depending upon the type of device that is connected to the system.

• The USB 2.0 PCI card has one EHCI controller and one or more OHCI controllers.

• A USB 1.1 device is dynamically assigned to the OHCI controller when it is plugged in. A USB 2.0 device is dynamically assigned to the EHCI controller when it is plugged in.

Overview of USB Devices

Universal Serial Bus (USB) was developed by the PC industry to provide a low-cost solution for attaching peripheral devices, such as keyboards, mouse devices, and printers, to a system.

USB connectors are designed to fit only one type of cable, one way. The primary design motivation for USB was to alleviate the need for multiple connector types for different devices. This design reduces the clutter on the back panel of a system.

Devices connect to USB ports on external USB hubs, or on a root hub that is located on the computer itself. Since hubs have several ports, several branches of a device tree can stem from a hub.

This table lists specific USB devices that are supported in the Solaris environment.

Commonly Used USB Acronyms

The following table describes the USB acronyms that are used in the Solaris environment. For a complete description of USB components and acronyms, go to http://www.usb.org.

USB Bus Description

The USB specification is openly available and free of royalties. The specification defines the electrical and mechanical interfaces of the bus and the connectors.

USB employs a topology in which hubs provide attachment points for USB devices. The host controller contains the root hub, which is the origin of all USB ports in the system. For more information about hubs, see USB Host Controller and Root Hub.

Figure 29–1 USB Physical Device Hierarchy

Figure 29–1 shows a system with three active USB ports. The first USB port connects a Zip drive. The second USB port connects an external hub, which in turn, connects a cdrw device and a composite keyboard/mouse device. As a composite device, this keyboard contains a USB controller, which operates both the keyboard and an attached mouse. The keyboard and the mouse share a common USB bus address because they are directed by the same USB controller.

Figure 29–1 also shows an example of a hub and a printer as a compound device. The hub is an external hub that is enclosed in the same casing as the printer. The printer is permanently connected to the hub. The hub and printer have separate USB bus addresses.

The device tree path name for some of the devices that are displayed in Figure 29–1 are listed in this table.

USB Devices and Drivers

USB devices with similar attributes and services are grouped into device classes. Each device class has a corresponding driver, one for each framework. Devices within a class are managed by the same device driver pair. However, the USB specification also allows for vendor-specific devices that are not part of a specific class.

The Human Interface Device (HID) class contains devices that are user-controlled such as keyboards, mouse devices, and joysticks. The Communication Device class contains devices that connect to a telephone, such as modems or an ISDN interface. Other device classes include the Audio, Monitor, Printer, and Storage Device classes. Each USB device contains descriptors that reflect the class of the device. A device class specifies how its members should behave in configuration and data transfer. You can obtain additional class information from http://www.usb.org.

Solaris USB Architecture (USBA)

USB devices can be represented as two levels of device tree nodes. A device node represents the entire USB device. One or more child interface nodes represent the individual USB interfaces on the device.

Driver binding is achieved by using the compatible name properties. For more information, refer to 3.2.2.1 of the IEEE 1275 USB binding and Writing Device Drivers. A driver can either bind to the entire device and control all the interfaces, or can bind to just one interface. If no vendor or class driver claims the entire device, a generic USB multi-interface driver is bound to the device-level node. This driver attempts to bind drivers to each interface by using compatible names properties, as defined in section 3.3.2.1 of the IEEE 1275 binding specification.

The Solaris USB Architecture (USBA) adheres to the USB 1.1 and USB 2.0 specifications plus Solaris driver requirements. The USBA model is similar to Sun Common SCSI Architecture (SCSA). The USBA is a thin layer that provides a generic USB transport-layer abstraction to client drivers, providing them with services that implement core generic USB functionality.

Figure 29–2 Solaris USB Architecture (USBA)

About USB in the Solaris Environment

This section describes information you should know about USB in the Solaris environment.

USB Keyboards and Mouse Devices

Only Sun USB keyboards and mouse devices are supported. System configurations with multiple USB keyboards and mouse devices might work, but are not supported in the Solaris environment. See the following items for details.

• A USB keyboard and mouse can be connected anywhere on the bus and can be configured as the console keyboard and mouse. Booting the system is slower if the keyboard and mouse are connected to an external hub.

• Do not move the console keyboard and mouse during a reboot or at the ok prompt. You can move the console keyboard and mouse to another hub at any time after a system reboot. After you plug in a keyboard and mouse, they are fully functional again.

• SPARC – The power key on a USB keyboard behaves differently than the power key on the Sun type 5 keyboard. On a USB keyboard, you can suspend or shut down the system by using the SUSPEND/SHUTDOWN key, but you cannot use that key to power up the system.

• The keys just to the left of the keypad do not function on third-party USB keyboards.

• Multiple keyboards are not supported:

  • Multiple keyboards enumerate and are usable, but they are not plumbed as console keyboards.

  • The first keyboard that is probed at boot time becomes the console keyboard. The result of this probing might cause confusion if multiple keyboards are plugged in at boot time.

  • If you unplug the console keyboard, the next available USB keyboard does not become the console keyboard. The next hot-plugged keyboard becomes the console keyboard.

• Multiple mouse devices are not supported:

  • Multiple mouse devices enumerate and are usable, but they are not plumbed as console mouse devices.

  • The first mouse that is probed at boot time becomes the console mouse. The result of this probing might cause confusion if you have multiple mouse devices plugged in at boot time.

  • If you unplug the console mouse, the next available USB mouse does not become the console mouse. The next hot-plugged mouse becomes the console mouse.

• If you have a third-party composite keyboard with a PS/2 mouse, and the composite keyboard/mouse is the first one to be probed, it becomes the console keyboard/mouse even if the PS/2 mouse is not plugged in. Thus, another USB mouse plugged into the system cannot work because it is not configured as the console mouse.

• Only two-button and three-button mouse devices are supported. A wheel-on-wheel mouse acts like a plain-button mouse. A mouse with more than three buttons functions like a three–button mouse.

USB Host Controller and Root Hub

A USB hub is responsible for the following:

• Monitoring the insertion or removal of a device on its ports

• Power-managing individual devices on its ports

• Controlling power to its ports

The USB host controller has an embedded hub called the root hub. The ports that are visible at the system's back panel are the ports of the root hub. The USB host controller is responsible for the following:

• Directing the USB bus. Individual devices cannot arbitrate for the bus.

• Polling the devices by using a polling interval that is determined by the device. The device is assumed to have sufficient buffering to account for the time between the polls.

• Sending data between the USB host controller and its attached devices. Peer-to-peer communication is not supported.

USB Hub Devices

• Do not cascade hubs beyond four levels on either SPARC based or x86 based systems. On SPARC systems, the OpenBoot^TM PROM cannot reliably probe beyond four levels of devices.

• Do not plug a bus-powered hub into another bus-powered hub in a cascading style. A bus-powered hub does not have its own power supply.

• Do not connect a device that requires a large amount of power to a bus-powered hub. These devices might not work well on bus-powered hubs or might drain the hub of power for other devices. An example of such a device is a USB diskette device.

SPARC: USB Power Management

Suspending and resuming of USB devices is fully supported on SPARC systems. However, do not suspend a device that is busy and never remove a device when the system is powered off under a suspend shutdown.

The USB framework makes a best effort to power manage all devices on SPARC-based systems with power management enabled. Power managing a USB device means that the hub driver suspends the port to which the device is connected. Devices that support remote wake up can notify the system to wake up everything in the device's path, so that the device can be used. The host system could also wake up the device if an application sends an I/O to the device.

All HID (keyboard, mouse, speakers, microphones), hub, and storage devices are power-managed by default if they support remote wake up capability. A USB printer is power-managed only between two print jobs. Devices that are directed by the generic USB driver (UGEN) are power managed only when they are closed.

When power management is running to reduce power consumption, USB leaf devices are powered down first. After all devices that are connected to a hub's ports are powered down, the hub is powered down after some delay. To achieve the most efficient power management, do not cascade many hubs.

Guidelines for USB Cables

Keep the following guidelines in mind when connecting USB cables:

• Always use USB 2.0 compliant, fully rated (480 Mbit/sec) 20/28 AWG cables for connecting USB 2.0 devices.

• Always use USB 1.0 compliant, fully rated (12 Mbit/sec) 20/28 AWG cables for connecting USB 1.0 or 1.1 devices. Use bus-powered hubs for low-speed devices only. Always use fully rated (12 Mbit/sec) 20/28 AWG cables for connecting USB devices.

• Maximum cable length that is supported is 5 meters.

• Do not use cable extenders. For best results, use a self-powered hub to extend cable length.

For more information, go to http://www.usb.org/channel/training/warning.

Managing USB Devices in the Solaris Environment (Roadmap)

Use this map to identify all the tasks for managing USB devices in the Solaris environment. Each task points to a series of additional tasks such as using USB devices, hot-plugging USB devices, or adding USB audio devices.

Using USB Mass Storage Devices (Task Map)

Using USB Mass Storage Devices

For up-to-date information on using USB mass storage devices in this Solaris release, see USB Mass Storage Devices.

Starting in the Solaris 9 4/04 release, removable mass storage devices such as USB CD-RWs, hards disks, DVDs, digital cameras, Zip, Peerless, SmartMedia, CompactFlash, ORB, and USB diskette devices are supported by ports operated by the USBA 1.0 framework.

An easy way to find out which framework is operating your device is to use the prtconf -D command before and after plugging in your device. By using this method, you'll find your device in the latter output. The USBA 1.0 framework is operating your device if the prtconf entry above it says usba10_scsa2usb. scsa2usb implies the original framework.

For a complete list of USB devices that are supported in the Solaris environment, see http://www.sun.com/io_technologies/USB.html.

These devices can be managed with or without volume management. For information on managing devices with volume management, see vold(1M).

Using USB Diskette Devices

USB diskette devices appear as removable media devices like other USB devices. USB diskette devices are not managed by the fd (floppy) driver. Applications that issue ioctl(2) calls intended for the fd (native floppy) driver will fail. Applications that issue only read(2) and write(2) calls will succeed. Other applications, such as SunPCI and rmformat, will also succeed.

CDE's File Manager does not fully support USB diskettes at this time. However, you can open, rename, and format diskettes that contain a UFS file system from File Manager's Removable Media Manager. You can only open diskettes that contain a PCFS file system from the Removable Media Manager. If a diskette contains either type of file system, you can successfully drag and drop files between the diskette and File Manager.

Volume management (vold) sees the USB diskette device as a SCSI removable media device. Volume management makes the device available for access under the /rmdisk directory.

For more information on how to use USB diskette devices, see Chapter 17, Managing Removable Media (Overview).

Using Non-Compliant USB Mass Storage Devices

Some devices might be supported by the USB mass storage driver even though they do not identify themselves as compliant with the USB mass storage class or identify themselves incorrectly. The scsa2usb.conf file contains an attribute-override-list that lists the vendor ID, product ID, and revision for matching mass storage devices, as well as fields for overriding the default device attributes. The entries in this list are commented out by default, and can be copied and uncommented to enable support of particular devices.

If you connect a USB mass storage device to a system running this Solaris release and the system is unable to use it, you can check the /kernel/drv/scsa2usb.conf file to see if there is a matching, commented entry for this device. Follow the information given in the scsa2usb.conf file to see if a particular device can be supported by using the override information. For a listing of recommended USB mass storage devices, go to http://www.sun.com/io_technologies/USB.html.

For more information, see scsa2usb(7D).

Preparing to Use a USB Mass Storage Device With vold Running

If you are running the Solaris Common Desktop Environment (CDE), USB removable mass storage devices are managed by the Removable Media Manager component of the CDE File Manager. For more information on the CDE File Manager, see dtfile(1).

You must include the /usr/dt/man directory in your MANPATH variable to display the man pages that are listed in this section. You must also have the /usr/dt/bin directory in your path and have CDE running to use these commands, or have a DISPLAY variable set to use these commands remotely.

The following table identifies the commands that Removable Media Manager uses to manage storage devices from the CDE environment.

After the USB device is formatted, it is usually mounted under the /rmdisk/label directory. For more information on configuring removable storage devices, see rmmount.conf(4) or vold.conf(4).

The device nodes are created under the /vol/dev directory. For more information, see scsa2usb(7D).

The following procedures describe how to manage USB mass storage devices without vold running. The device nodes are created under the /dev/rdsk directory for character devices and under the /dev/dsk directory for block devices. Device links are created when the devices are hot-plugged. For more information, see scsa2usb(7D).

How to Prepare to Use USB Mass Storage Devices Without vold Running

You can use USB mass storage devices without the volume management (vold) running. Stop vold by issuing the following command:

# /etc/init.d/volmgt stop

Or, use the following procedure to keep vold running, but do not register the USB mass storage devices with vold.

1. Become superuser.

2. Remove volume manager registration of USB mass storage devices by commenting the following line in the /etc/vold.conf file, like this:

   # use rmdisk drive /dev/rdsk/c*s2 dev_rmdisk.so rmdisk%d

3. After this line is commented, restart vold.

   # /etc/init.d/volmgt start

   ---

   Caution –

   If you comment out this line and other SCSI or ATAPI Zip, Peerless or other removable devices are in the system, vold registration for these devices would be disabled as well.

   ---

   For more information, see vold.conf(4).

How to Display USB Device Information (prtconf)

Use the prtconf command to display information about USB devices.

On a SPARC system, the prtconf output should look similar to the following:

$ prtconf
        usb, instance #0
                 hub, instance #2
                     device, instance #8
                         interface (driver not attached)
                     printer (driver not attached)
                     mouse, instance #14
                     device, instance #9
                         keyboard, instance #15
                         mouse, instance #16
                     storage, instance #7
                         disk (driver not attached)
                     communications, instance #10
                         modem (driver not attached)
                         data (driver not attached)
                 storage, instance #0
                     disk (driver not attached)
                 storage, instance #1
                     disk (driver not attached)

On an x86 system, the PCI card number, made up of the vendor ID and device ID, is displayed instead of usb in the prtconf output. For example, pci1022,7460, instance #0, is displayed instead of usb, instance #0.

You can use the prtconf command's -D option to display additional driver information. This information can be used to tell which ports and devices are being driven by the USBA 1.0 framework, as displayed in the following example:

$ prtconf -D
.
.
.
SUNW,Sun-Blade-1500
.
.
.
1 pci, instance #0 (driver name: pcisch) 
           isa, instance #0 (driver name: ebus)
.
.
.
2 usb, instance #0 (driver name: ohci)
           usb, instance #1 (driver name: ohci)
.
.
.
3 pci, instance #0 (driver name: pci_pci)
4 usb, instance #0 (driver name: usba10_ohci)
            usb, instance #1 (driver name: usba10_ohci)
            usb, instance #0 (driver name: usba10_ehci)
                storage, instance #9 (driver name: usba10_scsa2usb)
                    disk, instance #9 (driver name: usb_sd)
            firewire, instance #0 (driver name: hci1394)
.
.
.

In the output above, note the following configuration characteristics:

• PCI card ports are distinguished by the number of hierarchical pci nodes in the output above their usb nodes.

  PCI card ports (4) fall under two hierarchical pci nodes 1 and 3 because they are driven through both the motherboard and the PCI card. Onboard ports (2) fall under a single PCI node (1) because they are one hardware architectural layer closer to the main system bus.

• The name of a driver associated with a device node indicates which framework is directing the device and the port to which the device is attached. The drivers for all USB instances of (4) begin with usba10, indicating that the USBA 1.0 framework is managing those ports and the devices attached to them. Only those ports can support USB 2.0 devices at high speed.

How to Format a USB Mass Storage Device Without vold Running

USB mass storage devices, as all others used by the Solaris operating system, must be formatted and contain a file system before they can be used. USB mass storage devices, including diskettes, support both PCFS and UFS file systems. Be sure the disk is formatted before putting either a PCFS or UFS file system on it.

1. See How to Prepare to Use USB Mass Storage Devices Without vold Running for information on disabling vold.

2. (Optional) Add the USB diskette device to your system.

   For information on hot-plugging USB devices, see:

   • Using USB Audio Devices (Task Map)

   • Hot-Plugging USB Devices With the cfgadm Command (Task Map)

3. (Optional) Identify the diskette device.

   For example:

   # cd /dev/rdsk # devfsadm -C # ls -l c*0 | grep usb lrwxrwxrwx 1 root root 55 Mar 5 10:35 c2t0d0s0 -> ../../devices/pci@1f,0/usb@c,3/storage@3/disk@0,0:a,raw

   In this example, the diskette device is c2t0d0s0.

4. Insert a diskette into the diskette drive.

5. Format the diskette.

   % rmformat -Flong raw-device

   For example:

   % rmformat -Flong /dev/rdsk/c2t0d0s0

6. Determine the file system type and select one of the following:

   1. Create a PCFS file system.

      # mkfs -F pcfs -o nofdisk,size=size raw-device

      Specify the -size option in 512–byte blocks.

      The following example shows how to create a PCFS file system on a 1.4 Mbyte diskette.

      # mkfs -F pcfs -o nofdisk,size=2880 /dev/rdsk/c4t0d0s0

      The following example shows how to create a UFS file system on a 100 Mbyte Zip drive.

      # mkfs -F pcfs -o nofdisk,size=204800 /dev/rdsk/c5t0d0s0

      This command can take several minutes to complete.

   2. Create a UFS file system.

      # newfs raw-device

      For example:

      # newfs /dev/rdsk/c4t0d0s0

      ---

      Note –

      UFS file system overhead consumes a significant portion of space on a diskette, due to a diskette's limited storage capacity.

      ---

How to Mount or Unmount a USB Mass Storage Device With vold Running

1. Display device aliases for all removable mass storage devices, including USB mass storage devices.

   $ eject -n . . . cdrom0 -> /vol/dev/rdsk/c0t6d0/audio_cd (Generic CD device) zip0 -> /vol/dev/rdsk/c1t0d0/zip100 (USB Zip device) zip1 -> /vol/dev/rdsk/c2t0d0/fat32 (USB Zip device) rmdisk0 -> /vol/dev/rdsk/c5t0d0/unnamed_rmdisk (Peerless, HD or floppy) rmdisk1 -> /vol/dev/rdsk/c4t0d0/clik40 (Generic USB storage)

2. Select one of the following to mount or unmount a USB mass storage device.

   1. Mount a USB mass storage device by using the device aliases listed previously.

      $ volrmmount -i device-alias

      This example shows how to mount a USB Zip drive (/rmdisk/zip0).

      $ volrmmount -i zip0

   2. Unmount a USB mass storage device.

      $ volrmmount -e device-alias

      This example shows how to unmount a USB Zip drive (/rmdisk/zip0).

      $ volrmmount -e zip0

3. Eject a USB device from a generic USB drive.

   $ eject device-alias

   For example:

   $ eject rmdisk0

   ---

   Note –

   The eject command also unmounts the device if the device is not unmounted already. The command also terminates any active applications that access the device.

   ---

How to Mount or Unmount a USB Mass Storage Device Without vold Running

1. See How to Prepare to Use USB Mass Storage Devices Without vold Running for information on disabling vold.

2. Become superuser.

3. (Optional) Identify the diskette device.

   For example:

   # cd /dev/rdsk # devfsadm -C # ls -l c*0 | grep usb lrwxrwxrwx 1 root root 55 Mar 5 10:35 c2t0d0s0 -> ../../devices/pci@1f,0/usb@c,3/storage@3/disk@0,0:a,raw

   In this example, the diskette device is c2t0d0s0.

4. Select one of the following to mount or unmount a USB mass storage device.

   1. Mount a USB mass storage device.

      # mount [ -F fstype ] block-device mount-point

      This example shows how to mount a device with a UFS file system.

      # mount /dev/dsk/c1t0d0s2 /mnt

      This example shows how to mount a device with a PCFS file system.

      # mount -F pcfs /dev/dsk/c1t0d0s0:c /mnt

      This example shows how to mount a CD with a read-only HSFS file system.

      # mount -F hsfs -o ro /dev/dsk/c1t0d0s2 /mnt

   2. Unmount a USB mass storage device.

      First, be sure no one is using the file system on the device.

      For example:

      # fuser -c -u /mnt # umount /mnt

   3. Eject the device.

      # eject /dev/[r]dsk/cntndnsn

      For example:

      # eject /dev/rdsk/c1t0d0s2

Disabling Specific USB Drivers

You can disable specific types of USB devices by disabling their client driver. For example, USB printers can be disabled by disabling the usbprn driver that directs them. Disabling usbprn does not affect other kinds of devices, such as USB storage devices.

Be careful that device types are disabled on both frameworks. You cannot disable device types on one framework only. The following table identifies some USB device types and their corresponding drivers.

If you disable a driver for a USB device that is still connected to the system, you will see a console message similar to the following:

usba10: WARNING: usba:    no driver found for device name

How to Disable Specific USB Drivers

1. Become superuser.

2. Record the driver aliases that you are about to remove.

   # cp /etc/driver_aliases /etc/driver_aliases.orig

3. Identify the specific USB driver alias name.

   For example:

   # grep usbprn /etc/driver_aliases usbprn "usbif,class7.1.1" usbprn "usbif,class7.1.2"

4. Remove the driver alias entry.

   For example:

   # update_drv -d -i '"usbif,class7.1.1"' usbprn # update_drv -d -i '"usbif,class7.1.2"' usbprn

5. Reboot the system.

   # init 6

How to Remove Unused USB Device Links

Use this procedure if a USB device is removed while the system is powered off. It is possible that removing the USB device while the system is powered off will leave device links for devices that do not exist.

1. Become superuser.

2. Close all applications that might be accessing the device.

3. Remove the unused links for a specific USB class.

   For example:

   # devfsadm -C -c audio

   Or, just remove the dangling links:

   # devfsadm -C

Hot-Plugging USB Devices (Task Map)

Hot-plugging a device means the device is added or removed without shutting down the operating system or powering off the system. All USB devices are hot-pluggable.

When you hot-plug a USB device, the device is immediately seen in the system's device hierarchy, as displayed in the prtconf command output. When you remove a USB device, the device is removed from the system's device hierarchy, unless the device is in use.

If the USB device is in use when it is removed, the hot-plug behavior is a little different. If a device is in use when it is unplugged, the device node remains, but the driver controlling this device stops all activity on the device. Any new I/O activity issued to this device is returned with an error.

In this situation, the system prompts you to plug in the original device. If the device is no longer available, stop the applications. After a few seconds, the port will become available again.

Data integrity might be impaired if you remove an active or open device. Always close the device before removing, except the console keyboard and mouse, which can be moved while active.

How to Add a USB Mass Storage Device With vold Running

This procedure describes how to add a USB device with vold running.

1. Connect the USB mass storage device.

2. Instruct vold to scan for new devices.

   # touch /etc/vold.conf

3. Restart vold.

   # pkill -HUP vold

4. Verify that the device has been added.

   $ ls device-alias

   For more information on volume management device names, see Chapter 17, Managing Removable Media (Overview).

How to Add a USB Mass Storage Device Without vold Running

This procedure describes how to add a USB device without vold running.

1. If needed, see How to Prepare to Use USB Mass Storage Devices Without vold Running for information on disabling vold.

2. Connect the USB mass storage device.

3. Verify that the USB device has been added.

   Locate the USB disk device links, which may be among device links of non-USB storage devices, as follows:

   $ cd /dev/rdsk $ ls -l c*0 | grep usb lrwxrwxrwx 1 root root 67 Apr 30 15:12 c1t0d0s0 -> ../../devices/pci@1f,0/pci@5/pci@0/usb@8,2/storage@1/disk@0,0:a,raw

How to Remove a USB Mass Storage Device With vold Running

The following procedure uses a Zip drive as an example of removing a USB device with vold running.

1. Stop any active applications that are using the device.

2. Unmount the device.

   For example:

   $ volrmmount -e zip0

3. Eject the device.

   For example:

   $ eject zip0

4. Become superuser and stop vold.

   # /etc/init.d/volmgt stop

5. Remove the USB mass storage device.

6. Start vold.

   # /etc/init.d/volmgt start

How to Remove a USB Mass Storage Device Without vold Running

This procedure describes how to remove a USB device without vold running.

1. If needed, see How to Prepare to Use USB Mass Storage Devices Without vold Running for information on disabling vold.

2. Become superuser.

3. Stop any active applications that are using the device.

4. Remove the USB device.

   1. Unmount the device.

      For example:

      # umount /mnt

   2. Remove the device.

How to Add a USB Camera

Use this procedure to add a USB camera.

1. Become superuser.

2. Plug in and turn on the USB camera.

   The system creates a logical device for the camera. After the camera is plugged in, output is written to the /var/adm/messages file to acknowledge the device's connection. The camera is seen as a storage device to the system.

3. Examine the output that is written to the /var/adm/messages file.

   Examining this output enables you to determine which logical device was created so that you can then use that device to access your images. The output will look similar to the following:

   # more /var/adm/messages Jul 15 09:53:35 buffy usba: [ID 349649 kern.info] OLYMPUS, C-3040ZOOM, 000153719068 Jul 15 09:53:35 buffy genunix: [ID 936769 kern.info] scsa2usb1 is /pci@0,0/pci925,1234@7,2/storage@2 Jul 15 09:53:36 buffy scsi: [ID 193665 kern.info] sd3 at scsa2usb1: target 0 lun 0

   Match the device with a mountable /dev/dsk link entry, by doing the following:

   # ls -l /dev/dsk/c*0 | grep /pci@0,0/pci925,1234@7,2/storage@2 lrwxrwxrwx 1 root root 58 Jul 15 2002 c3t0d0p0 -> ../../devices/pci@0,0/pci925,1234@7,2/storage@2/disk@0,0:a

4. Mount the USB camera file system.

   The camera's file system is most likely a PCFS file system. In order to mount the file system on the device created, the slice that represents the disk must be specified. The slice is normally s0 for a SPARC system, and p0 for an x86 system.

   For example, to mount the file system on an x86 system, execute the following command:

   # mount -F pcfs /dev/dsk/c3t0d0p0:c /mnt

   To mount the file system on a SPARC system, execute the following command:

   # mount -F pcfs /dev/dsk/c3t0d0s0:c /mnt

   For information on mounting file systems, see Chapter 40, Mounting and Unmounting File Systems (Tasks).

   For information on mounting different PCFS file systems, see mount_pcfs(1M).

5. Verify that the image files are available.

   For example:

   # ls /mnt/DCIM/100OLYMP/ P7220001.JPG* P7220003.JPG* P7220005.JPG* P7220002.JPG* P7220004.JPG* P7220006.JPG*

6. View and manipulate the image files created by the USB camera.

   # /usr/dt/bin/sdtimage P7220001.JPG &

7. Unmount the file system before disconnecting the camera.

   For example:

   # umount /mnt

8. Turn off and disconnect the camera.

Using USB Audio Devices (Task Map)

Using USB Audio Devices

This Solaris release provides USB audio support that is implemented by a pair of cooperating drivers, usb_ac and usb_as. The audio control driver, usb_ac, is a USBA (Solaris USB Architecture) compliant client driver that provides the controlling interface to user applications. The audio streaming driver, usb_as, is provided to process audio data messages during play and record. It sets sample frequency and precision, and encodes requests from the usb_ac driver. Both drivers comply to the USB audio class 1.0 specification.

Some audio devices can set volume under software control. A STREAMS module, usb_ah, is pushed on top of the HID driver for managing this function.

Solaris supports USB audio devices that are play-only, record-only, or record and play. Hot-plugging of USB audio devices is supported.

• USB audio devices are supported on SPARC Ultra and x86 platforms that have USB connectors.

• USB audio devices that are supported in the Solaris 8 10/01, Solaris 8 2/02, or Solaris 9 or 10 release must support a fixed 44100 or 48000 Hz sampling frequency to play or record.

• USB audio devices that are supported in the Solaris 10 release must support a 48000 Hz sample rate to play or record.

• For fully supported audio data format information, see usb_ac(7D).

The primary audio device is /dev/audio. You can verify that /dev/audio is pointing to USB audio by using the following command:

% mixerctl
Device /dev/audioctl:
  Name    = USB Audio
  Version = 1.0
  Config  = external

Audio mixer for /dev/audioctl is enabled

After you connect your USB audio devices, you access them with the audioplay and audiorecord command through the /dev/sound/N device links.

Note that the /dev/audio and /dev/sound/N devices can refer to speakers, microphones, or combo devices. If you refer to the incorrect device type, the command will fail. For example, the audioplay command will fail if you try to use it with a microphone.

You can select a specific default audio device for most Sun audio applications, such as audioplay and audiorecord, by setting the AUDIODEV shell variable or by specifying the -d option for these commands. However, setting AUDIODEV does not work for third-party applications that have /dev/audio hardcoded as the audio file.

When you plug in a USB audio device, it automatically becomes the primary audio device, /dev/audio, unless /dev/audio is in use. For instructions on changing /dev/audio from onboard audio to USB audio and vice versa, refer to How to Change the Primary USB Audio Device, and usb_ac(7D).

Hot-Plugging Multiple USB Audio Devices

If a USB audio device is plugged into a system, it becomes the primary audio device, /dev/audio. It remains the primary audio device even after the system is rebooted. If additional USB audio devices are plugged in, the last one becomes the primary audio device.

For additional information on troubleshooting USB audio device problems, see usb_ac(7D).

How to Add USB Audio Devices

Use the following procedure to add USB audio devices.

1. Plug in the USB speakers and microphone.

   The primary audio device, /dev/audio, usually points to the onboard audio. After you connect USB audio devices, /dev/audio points to the USB audio devices that are identified in the /dev/sound directory.

2. Verify that the audio device files have been created.

   % ls /dev/sound 0 0ctl 1 1ctl 2 2ctl

3. Test the left and right USB speakers.

   % cd /usr/share/audio/samples/au % audioplay -d /dev/sound/1 -b 100 spacemusic.au % audioplay -d /dev/sound/1 -b -100 spacemusic.au

4. Test the USB microphone.

   % cd $HOME/au % audiorecord -d /dev/sound/2 -p mic -t 30 test.au

How to Identify Your System's Primary Audio Device

This procedure assumes that you have already connected USB audio devices.

1. Identify the state of your current audio device links.

   For example:

   % ls -lt /dev/audio* lrwxrwxrwx 1 root root 7 Jul 23 15:41 /dev/audio -> sound/0 lrwxrwxrwx 1 root root 10 Jul 23 15:41 /dev/audioctl -> sound/0ctl % ls -lt /dev/sound/* lrwxrwxrwx 1 root other 66 Jul 23 14:21 /dev/sound/0 -> ../../devices/pci@1f,4000/ebus@1/SUNW,CS4231@14,200000:sound,audio lrwxrwxrwx 1 root other 69 Jul 23 14:21 /dev/sound/0ctl -> ../../devices/pci@1f,4000/ebus@1/SUNW,CS4231@14,200000:sound,audioctl %

   The primary audio device, /dev/audio, is currently pointing to the onboard audio, which is /dev/sound/0.

2. (Optional) Add a new USB audio device.

3. Examine your system's new audio links.

   For example:

   % ls -lt /dev/audio* lrwxrwxrwx 1 root root 7 Jul 23 15:46 /dev/audio -> sound/1 lrwxrwxrwx 1 root root 10 Jul 23 15:46 /dev/audioctl -> sound/1ctl % ls -lt /dev/sound/* lrwxrwxrwx 1 root root 74 Jul 23 15:46 /dev/sound/1 -> ../../devices/pci@1f,4000/usb@5/hub@1/device@3/sound-control@0:sound,... lrwxrwxrwx 1 root root 77 Jul 23 15:46 /dev/sound/1ctl -> ../../devices/pci@1f,4000/usb@5/hub@1/device@3/sound-control@0:sound,... lrwxrwxrwx 1 root other 66 Jul 23 14:21 /dev/sound/0 -> ../../devices/pci@1f,4000/ebus@1/SUNW,CS4231@14,200000:sound,audio lrwxrwxrwx 1 root other 69 Jul 23 14:21 /dev/sound/0ctl -> ../../devices/pci@1f,4000/ebus@1/SUNW,CS4231@14,200000:sound,audioctl %

   Notice that the primary audio device, /dev/audio, is pointing to the newly plugged in USB audio device, /dev/sound/1.

   If you remove the USB audio device now, the primary audio device, /dev/audio, does not revert back to the onboard audio. See the following procedure for instructions on changing the primary audio device back to the system's onboard audio.

   You can also examine your system's USB audio devices with the prtconf command and look for the USB device information.

   % prtconf . . . usb, instance #0 hub, instance #0 mouse, instance #0 keyboard, instance #1 device, instance #0 sound-control, instance #0 sound, instance #0 input, instance #0 . . .

How to Change the Primary USB Audio Device

Follow these steps if you remove or change your USB audio devices and you want to make one particular audio device the primary audio device. The procedure changes the primary audio device to the onboard audio device as an example.

1. Become superuser.

2. Close all audio applications.

3. Verify that the audio and USB drivers are loaded.

   # modinfo | grep -i audio 124 780e6a69 bb6e - 1 audiosup (Audio Device Support 1.12) # modinfo | grep -i usb 48 13dba67 18636 199 1 ohci (USB OpenHCI Driver 1.31) 49 78020000 1dece - 1 usba (USBA: USB Architecture 1.37) 50 12e5f1f 35f 195 1 hubd (USB Hub Driver 1.4) 51 13ef53d 5e26 194 1 hid (USB HID Client Driver 1.16) 54 13f67f2 1b42 10 1 usbms (USB mouse streams 1.6) 56 127bbf0 2c74 11 1 usbkbm (USB keyboard streams 1.17) #

4. Load and attach the onboard audio driver.

   # devfsadm -i audiocs

   The onboard audio driver is audiocs on a Sunblade 1000, and audiots on a Sunblade 100.

5. Verify that the primary audio device link is pointing to the onboard audio.

   # ls -lt /dev/audio* lrwxrwxrwx 1 root other 7 Jul 23 15:49 /dev/audio -> sound/0 lrwxrwxrwx 1 root other 10 Jul 23 15:49 /dev/audioctl -> sound/0ctl # ls -lt /dev/sound/* lrwxrwxrwx 1 root other 66 Jul 23 14:21 /dev/sound/0 -> ../../devices/pci@1f,4000/ebus@1/SUNW,CS4231@14,200000:sound,audio lrwxrwxrwx 1 root other 69 Jul 23 14:21 /dev/sound/0ctl -> ../../devices/pci@1f,4000/ebus@1/SUNW,CS4231@14,200000:sound,audioctl #

6. Confirm the onboard audio is the primary audio device.

   % audioplay /usr/demo/SOUND/sounds/bark.au

   The audioplay command defaults to the onboard audio device.

7. (Optional) Unload all the audio drivers that can be unloaded before plugging in another USB audio device.

   1. Close all the audio applications.

   2. Display the audio driver information to verify that no audio drivers are currently loaded.

      # modinfo | grep -i audio 60 78048000 bb6e - 1 audiosup (Audio Device Support 1.12) 61 78152000 39a97 - 1 mixer (Audio Mixer 1.49) 62 78118000 bf9f - 1 amsrc1 (Audio Sample Rate Conv. #1 1.3) 128 7805e000 14968 54 1 audiocs (CS4231 mixer audio driver 1.21) #

   3. Unload the audio drivers.

      # modunload -i 0 # modinfo | grep -i audio 60 78048000 bb6e - 1 audiosup (Audio Device Support 1.12) 61 78152000 39a97 - 1 mixer (Audio Mixer 1.49) #

      At this point, audiocs, the onboard audio driver, has been unloaded and guaranteed not to be open. However, the primary audio device, /dev/audio, does not change if it is held open by an application.

8. (Optional) Plug in a USB audio device.

9. (Optional) Examine the new audio links.

   % ls -lt /dev/audio* lrwxrwxrwx 1 root root 7 Jul 23 16:12 /dev/audio -> sound/1 lrwxrwxrwx 1 root root 10 Jul 23 16:12 /dev/audioctl -> sound/1ctl % ls -lt /dev/sound/* lrwxrwxrwx 1 root root 77 Jul 23 16:12 /dev/sound/1ctl -> ../../devices/pci@1f,4000/usb@5/hub@1/device@3/sound-control@0:sound,... lrwxrwxrwx 1 root root 74 Jul 23 16:12 /dev/sound/1 -> ../../devices/pci@1f,4000/usb@5/hub@1/device@3/sound-control@0:sound,... lrwxrwxrwx 1 root root 66 Jul 23 15:59 /dev/sound/0 -> ../../devices/pci@1f,4000/ebus@1/SUNW,CS4231@14,200000:sound,audio lrwxrwxrwx 1 root root 69 Jul 23 15:59 /dev/sound/0ctl -> ../../devices/pci@1f,4000/ebus@1/SUNW,CS4231@14,200000:sound,aud... %

Troubleshooting USB Audio Device Problems

This section describes how to troubleshoot USB audio device problems.

Solving USB Audio Problems

Sometimes USB speakers do not produce any sound even though the driver is attached and the volume is set to high. Hot-plugging the device might not change this behavior.

The workaround is to power cycle the USB speakers.

Key Points of Audio Device Ownership

Keep the following key points of audio device ownership in mind when working with audio devices.

• When you plug in a USB audio device and you are logged in on the console, the console is the owner of the /dev/* entries. This situation means you can use the audio device as long as you are logged into the console.

• If you are not logged into the console when you plug in a USB audio device, root becomes the owner of the device. However, if you log into the console and attempt to access the USB audio device, device ownership changes to the console. For more information, see logindevperm(4).

• When you remotely login with the rlogin command and attempt to access the USB audio device, the ownership does not change. This means that, for example, unauthorized users cannot listen to conversations over a microphone owned by someone else.

Hot-Plugging USB Devices With the cfgadm Command (Task Map)

Hot-Plugging USB Devices With the cfgadm Command

You can add and remove a USB device from a running system without using the cfgadm command. However, a USB device can also be logically hot-plugged without physically removing the device. This scenario is convenient when you are working remotely and you need to disable or reset a non-functioning USB device. The cfgadm command also provides a way to display the USB device tree including manufacturer and product information.

The cfgadm command displays information about attachment points, which are locations in the system where dynamic reconfiguration operations can occur. An attachment point consists of:

• An occupant, which represents a hardware resource, such as a USB device, that might be configured into the system, and

• A receptacle, which is the location that accepts the occupant, such as a USB port.

Attachment points are represented by logical and physical attachment point IDs (Ap_Ids). The physical Ap_Id is the physical pathname of the attachment point. The logical Ap_Id is a user-friendly alternative for the physical Ap_Id. For more information on Ap_Ids, see cfgadm_usb(1M).

The cfgadm command provides the following USB device status information.

The following sections describe how to hot-plug a USB device through the software with the cfgadm command. All of the sample USB device information in these sections has been truncated to focus on relevant information.

How to Display USB Bus Information (cfgadm)

Use the cfgadm command to display USB bus information. For example:

% cfgadm
Ap_Id                       Type         Receptacle   Occupant     Condition
usb0/4.5                    usb-hub      connected    configured   ok
usb0/4.5.1                  usb-device   connected    configured   ok
usb0/4.5.2                  usb-printer  connected    configured   ok
usb0/4.5.3                  usb-mouse    connected    configured   ok
usb0/4.5.4                  usb-device   connected    configured   ok
usb0/4.5.5                  usb-storage  connected    configured   ok
usb0/4.5.6                  usb-communi  connected    configured   ok
usb0/4.5.7                  unknown      empty        unconfigured ok
usb0/4.6                    usb-storage  connected    configured   ok
usb0/4.7                    usb-storage  connected    configured   ok

In the preceding example, usb0/4.5.1 identifies a device connected to port 1 of the second-level external hub, which is connected to port 5 of first-level external hub, which is connected to the first USB controller's root hub, port 4.

Use the following cfgadm command to display specific USB device information. For example:

% cfgadm -l -s "cols=ap_id:info"
Ap_Id       Information
 usb0/4.5.1  Mfg: Inside Out Networks Product: Edgeport/421 NConfigs: 1 
Config: 0  : ...
 usb0/4.5.2  Mfg: <undef> Product: <undef>   NConfigs: 1 Config: 0 ...
 usb0/4.5.3  Mfg: Mitsumi Product: Apple USB Mouse NConfigs: 1 Config: 0 ...
 usb0/4.5.4  Mfg: NMB  Product: NMB USB KB/PS2 M NConfigs: 1 Config: 0
 usb0/4.5.5  Mfg: Hagiwara Sys-Com  Product: SmartMedia R/W  NConfigs: 1 
Config: 0 : ...
 usb0/4.5.6  Mfg: 3Com Inc.  Product: U.S.Robotics 56000 Voice USB Modem 
NConfigs: 2 ...
 usb0/4.5.7
 usb0/4.6    Mfg: Iomega  Product: USB Zip 250  NConfigs: 1  Config: 0
 : Default
 usb0/4.7    Mfg: Iomega  Product: USB Zip 100  NConfigs: 1  Config: 0
 : Default

For examples of using the prtconf command to display USB configuration information, see How to Display USB Device Information (prtconf).

How to Unconfigure a USB Device

You can unconfigure a USB device that is still physically connected to the system, but a driver will never attach to it. Note that a USB device remains in the prtconf output even after that device is unconfigured.

1. Become superuser.

2. Unconfigure the USB device.

   # cfgadm -c unconfigure usb0/4.7 Unconfigure the device: /devices/pci@8,700000/usb@5,3/hub@4:4.7 This operation will suspend activity on the USB device Continue (yes/no)? y

3. Verify that the device is unconfigured.

   # cfgadm Ap_Id Type Receptacle Occupant Condition usb0/4.5 usb-hub connected configured ok usb0/4.5.1 usb-device connected configured ok usb0/4.5.2 usb-printer connected configured ok usb0/4.5.3 usb-mouse connected configured ok usb0/4.5.4 usb-device connected configured ok usb0/4.5.5 usb-storage connected configured ok usb0/4.5.6 usb-communi connected configured ok usb0/4.5.7 unknown empty unconfigured ok usb0/4.6 usb-storage connected configured ok usb0/4.7 usb-storage connected unconfigured ok

How to Configure a USB Device

1. Become superuser.

2. Configure a USB device.

   # cfgadm -c configure usb0/4.7

3. Verify that the USB device is configured.

   # cfgadm usb0/4.7 Ap_Id Type Receptacle Occupant Condition usb0/4.7 usb-storage connected configured ok

How to Logically Disconnect a USB Device

If you want to remove a USB device from the system and the prtconf output, but you are not physically near the system, just logically disconnect the USB device. The device is still physically connected, but it is logically disconnected, unusable, and not visible to the system.

1. Become superuser.

2. Disconnect a USB device.

   # cfgadm -c disconnect -y usb0/4.7

3. Verify that the device is disconnected.

   # cfgadm usb0/4.7 Ap_Id Type Receptacle Occupant Condition usb0/4.7 unknown disconnected unconfigured ok

How to Logically Connect a USB Device

Use this procedure to logically connect a USB device that was previously logically disconnected or unconfigured.

1. Become superuser.

2. Connect a USB device.

   # cfgadm -c configure usb0/4.7

3. Verify that the device is connected.

   # cfgadm usb0/4.7 Ap_Id Type Receptacle Occupant Condition usb0/4.7 usb-storage connected configured ok

   The device is now available and visible to the system.

How to Logically Disconnect a USB Device Subtree

Use this procedure to disconnect a USB device subtree, which is the hierarchy (or tree) of devices below a hub.

1. Become superuser.

2. Remove a USB device subtree.

   # cfgadm -c disconnect -y usb0/4

3. Verify that the USB device subtree is disconnected.

   # cfgadm usb0/4 Ap_Id Type Receptacle Occupant Condition usb0/4 unknown disconnected unconfigured ok

How to Reset a USB Device

If a USB device behaves erratically, use the cfgadm command to reset the device, which logically removes and recreates the device.

1. Become superuser.

2. Make sure the device is not in use.

3. Reset the device.

   # cfgadm -x usb_reset -y usb0/4.7

4. Verify that the device is connected.

   # cfgadm usb0/4.7 Ap_Id Type Receptacle Occupant Condition usb0/4.7 usb-storage connected configured ok

How to Change the Default Configuration of a Multi-Configuration USB Device

Keep the following in mind when working with multi-configuration USB devices:

• A USB device configuration defines how a device presents itself to the operating system. This is different from system device configurations discussed in other cfgadm sections.

• Some USB devices support multiple configurations, but only one configuration can be active at a time.

• Multi-configuration devices can be identified by examining the cfgadm -lv output. Nconfigs will be greater than 1.

• The default USB configuration is configuration 1. The current configuration is reflected in cfgadm -lv output as Config.

• Changes to the default configuration will persist across reboots, hot-removes, and reconfiguration of the device, as long as it is reconnected to the same port.

1. Make sure the device is not in use.

2. Change the default USB configuration.

   For example:

   # cfgadm -x usb_config -o config=2 usb0/4 Setting the device: /devices/pci@1f,0/usb@c,3:4 to USB configuration 2 This operation will suspend activity on the USB device Continue (yes/no)? yes

3. Verify the device change.

   For example:

   # cfgadm -lv usb0/4 Ap_Id Receptacle Occupant Condition Information When Type Busy Phys_Id usb0/4 connected unconfigured ok Mfg: Sun 2000 Product: USB-B0B0 aka Robotech With 6 EPPS High Clk Mode NConfigs: 7 Config: 2 : EVAL Board Setup unavailable usb-device n /devices/pci@1f,0/usb@c,3:4

   Config now shows 2.