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:
This is a list of the overview information in this chapter.
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.
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. Additional advantages of using USB devices are as follows:
USB devices are hot-pluggable. For more information, see Hot-Plugging USB Devices.
USB 1.1 devices are supported in the Solaris 9 environment.
Supports a maximum of 126 devices per host controller in the Solaris environment.
Supports a maximum of 12 Mbit/sec data transfer.
Supports low speed (1.5 Mbit/sec) and full speed (12 Mbit/sec) devices.
Solaris Ready USB PCI controllers are available. For more information, see http://www.sun.com/io.
The bus can be easily extended by adding low-cost external hubs. Hubs can be connected to hubs to form a tree topology. Devices can connect to hub devices, which connect several devices, including other hub devices.
Sun Microsystems platform support for USB devices includes the following:
SPARC systems with ohci host controllers:
Sun BladeTM systems that run the Solaris 8 or 9 release.
NetraTM X1/T1 and some Sun FireTM systems that run the Solaris 9 release.
x86 based systems with uhci host controllers that run the Solaris 8 and Solaris 9 x86 Platform Editions.
This table lists specific USB devices that are supported in the Solaris environment.
USB Devices |
Systems Supported |
---|---|
HID control on audio devices |
SPARC based and x86 based systems. |
Hubs |
SPARC based and x86 based systems. |
Keyboards and mouse devices |
SPARC based systems with Sun USB support based on the ohci controller. x86 based systems with a USB bus based on the uhci controller. Only on-board USB controllers are supported. |
Mass storage devices |
SPARC based and x86 based systems. |
Printers |
SPARC based and x86 based systems. |
Speakers and microphones |
SPARC based and x86 based systems. |
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.
Acronym |
Definition |
---|---|
USB |
Universal Serial Bus |
USBA |
Universal Serial Bus Architecture (Solaris) |
USBAI |
USBA Client Driver Interface (Solaris) |
HCD |
USB host controller driver |
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 shows a system with three active USB ports. The first USB port has a Zip drive that does not have an embedded hub, so you cannot attach additional devices. The second USB port has a hub with a cdrw device and a composite keyboard and mouse device connected. One port from the secondary hub has a keyboard with an embedded hub where the mouse is attached.
Figure 29–1 also shows an example of a hub and printer as a compound device. Both the hub and the printer are enclosed in the same plastic case, but the hub and the printer have separate USB bus addresses. The same diagram shows an example of a composite device. The composite device is a USB mouse/keyboard with one USB address. A cable connects the mouse to the keyboard, which contains the USB controller.
The device tree path name for some of the devices that are displayed in Figure 29–1 are listed in this table.
Zip drive |
/pci@1f,4000/usb@5/storage@1 |
Keyboard |
/pci@1f,4000/usb@5/hub@2/device@1/keyboard@0 |
Mouse |
/pci@1f,4000/usb@5/hub@2/device@1/mouse@1 |
cdrw device |
/pci@1f,4000/usb@5/hub@2/storage@3 |
Printer |
/pci@1f,4000/usb@5/hub@3/printer@1 |
USB devices are divided into device classes. Each device class has a corresponding driver. Devices within a class are managed by the same device driver. However, the USB specification also allows for vendor-specific devices that are not part of a specific class. Devices with similar attributes and services are grouped.
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.
USB devices are 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. For special cases, the device nodes and interface nodes are combined into a single combined node.
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 1275 binding.
The Solaris USB Architecture (USBA) adheres to the USB 1.1 specification 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 the client driver.
This section describes information you should know about USB in the Solaris environment.
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 not on the root 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 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.
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.
Do not cascade hubs beyond four levels on either SPARC based or x86 based systems. On SPARC systems, the OpenBootTM PROM cannot reliably probe beyond four levels of devices.
Do not cascade bus-powered hubs. (Plug a bus-powered hub into another bus-powered hub.) 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.
Suspending and resuming USB devices are 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.
If the SPARC based system has power management enabled, the USB framework makes a best effort to power-manage all devices. Power-managing a USB device means that the hub driver suspends the port to which the device is connected. The device might or might not support remote wake up. If the device supports remote wake up, it wakes up all devices in its path back to the system, and possibly, the system itself. 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.
When power management is running to reduce power consumption, USB leaf devices are powered down first. When all devices that are connected to this hub's ports are powered down, the hub is powered down after some delay.
Always use USB 1.0 compliant cables. Use bus-powered hubs for low-speed devices only. Always use fully rated (12 Mbit/sec) 20/28 AWG cables for connecting USB devices.
Task |
Description |
For Instructions |
---|---|---|
1. Add a USB mass storage device |
Add a USB mass storage device with vold running. | |
Add a USB mass storage device without vold running. | ||
2. Remove a USB mass storage device |
Remove a USB mass storage device with vold running. | |
Remove a USB mass storage device without vold running. |
How to Remove a USB Mass Storage Device Without vold Running |
|
3. Mount a USB mass storage device |
Mount a USB mass storage device with vold running. |
How to Mount or Unmount a USB Mass Storage Device With vold Running |
|
Mount a USB mass storage device without vold running. |
How to Mount or Unmount a USB Mass Storage Device Without vold Running |
4. Add a USB camera |
Add a USB camera to access digital images. |
Removable mass storage devices such as USB CD-RWs, disks, DVDs, digital cameras, Zip, SmartMedia, CompactFlash, and ORB are supported, starting with the Solaris 9 release.
For a complete list of USB devices that are supported in the Solaris environment, see http://www.sun.com/io_technologies/storagesolutions.html.
These devices can be managed with or without volume management. For information on managing devices with volume management, see vold(1M).
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 the 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.
For more information, see scsa2usb(7D).
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.
This procedure describes how to add a USB device with vold running.
Insert the USB mass storage device.
Instruct vold to scan for new devices.
# touch /etc/vold.conf |
Restart vold.
# pkill -HUP vold |
Verify that the device has been added.
$ ls device-alias |
This procedure describes how to add a USB device without vold running.
Add a USB device into the USB port.
Verify that the USB device has been added.
$ ls /dev/rdsk/cntndnsn |
The following procedure uses a Zip drive as an example of removing a USB device with vold running.
Unmount the device.
$ volrmmount -e zip0 |
Stop any active applications that are using the device.
Eject the device.
$ eject zip0 |
Become superuser and stop vold.
# /etc/init.d/volmgt stop |
Remove the USB mass storage device.
Start vold.
# /etc/init.d/volmgt start |
This procedure describes how to remove a USB device without vold running.
If you are running Solaris Common Desktop Environment (CDE), the 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.
Command |
Man Page |
Task |
---|---|---|
sdtmedia_format |
sdtmedia_format(1) |
Format and label a device |
sdtmedia_prop |
sdtmedia_prop(1) |
Display properties of a device |
sdtmedia_prot |
sdtmedia_prot(1) |
Change device protection |
sdtmedia_slice |
sdtmedia_slice(1) |
Create or modify slices on a device |
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).
You can use USB mass storage devices without the volume manager (vold) running. Here are two ways to avoid using the volume manager.
Stop vold by issuing this command:
# /etc/init.d/volmgt stop |
Keep vold running, but do not register the USB mass storage devices with vold. 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 |
After this line is commented, restart vold.
# /etc/init.d/volmgt start |
If you comment out this line and other SCSI or ATAPI Zip or Jaz removable devices are in the system, vold registration for these devices would be disabled as well.
For more information, see vold.conf(4).
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. For more information, see scsa2usb(7D).
Display device aliases for all removable mass storage devices, including USB mass storage devices.
$ eject -n . . . rmdisk0 -> /vol/dev/rdsk/c4t0d0/clik40 (Generic USB storage) cdrom0 -> /vol/dev/rdsk/c0t6d0/audio_cd (Generic CD device) zip1 -> /vol/dev/rdsk/c2t0d0/fat32 (USB Zip device) zip0 -> /vol/dev/rdsk/c1t0d0/zip100 (USB Zip device) jaz0 -> /vol/dev/rdsk/c3t0d0/jaz1gb (USB Jaz device) |
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 |
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 |
Eject a USB device from a generic USB drive.
$ eject device-alias |
For example:
$ eject rmdisk0 |
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.
Become superuser.
Mount a USB mass storage device.
# mount -F fs-type /dev/dsk/cntndnsn /mount-point |
This command might fail if the device is read-only. Use the following command for CD-ROM devices.
# mount -F fs-type -o ro /dev/dsk/cntndnsn /mount-point |
For example:
# mount -F hsfs -o ro /dev/dsk/c0t6d0s2 /mnt |
Unmount a USB mass storage device.
# umount /mount-point |
Eject the device.
# eject /dev/[r]dsk/cntndnsn |
Use this procedure to add a USB camera.
Become superuser.
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.
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 |
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).
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* |
View and manipulate the image files created by the USB camera.
# /usr/dt/bin/sdtimage P7220001.JPG & |
Unmount the file system before disconnecting the camera.
For example:
# umount /mnt |
Turn off and disconnect the camera.
Task |
Description |
For Instructions |
---|---|---|
1. Add USB audio devices |
Add a USB microphone and speakers. | |
2. Identify your system's primary audio device |
Identify which audio device is your primary audio device. | |
3. Change the primary USB audio device |
You might want to make one particular audio device the primary audio device if you remove or change your USB audio devices. | |
4. Remove unused USB audio device links |
If you remove a USB audio device while the system is powered off, the /dev/audio device might be pointing to a /dev/sound/* device that doesn't exist. | |
5. Troubleshoot USB audio device problems |
You might have to power cycle USB speakers. |
This Solaris release provides USB audio support which 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 and set sample frequency, precision, and encoding requests from the usb_ac driver.
Both drivers comply to the USB audio class 1.0 specification.
Solaris supports external USB audio devices that are play-only or record-only. Onboard USB audio devices are not supported. For supported audio data format information, see usb_ac(7D).
If the audio device has volume under software control, usb_ah, a STREAMS module, is pushed on top of the HID driver for managing this button.
USB audio devices are supported on SPARC Ultra and x86 platforms that have USB connectors.
Hot-plugging USB audio devices is supported.
USB audio devices must support a continuous sample rate of between 8000 and 48000 Hz. Or, the USB audio devices must support a 48000 Hz sample rate to play or record on the Solaris 8 10/01, Solaris 8 2/02, or Solaris 9 release.
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 following files:
/dev/sound/N |
You can select a specific audio device by setting the AUDIODEV environment variable or by specifying the -d option to the audioplay and audiorecord commands. However, setting AUDIODEV does not work for 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).
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).
Use the following procedure to add USB audio devices.
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.
Verify that the audio device files have been created.
% ls /dev/sound 0 0ctl 1 1ctl 2 2ctl |
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 |
Test the USB microphone.
% cd $HOME/au % audiorecord -d /dev/sound/2 -p mic -t 30 test.au |
This procedure assumes that you have already connected USB audio devices.
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.
(Optional) Add a new USB audio device.
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,audio 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,aud... 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 . . . |
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.
Become superuser.
Close all audio applications.
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) # |
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.
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 # |
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.
(Optional) Unload all the audio drivers that can be unloaded before plugging in another USB audio device.
Close all the audio applications.
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) # |
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.
(Optional) Plug in a USB audio device.
(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,aud... 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,aud... 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... % |
Use this procedure if a USB audio device is removed while the system is powered off. It is possible that removing the USB audio device while the system is powered off will leave the /dev/audio device still pointing to a /dev/sound/* device that doesn't exist.
Become superuser.
Close all audio applications.
Remove the unused audio links.
# devfsadm -C -c audio |
This section describes how to troubleshoot USB audio device 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.
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.
Task |
Description |
For Instructions |
---|---|---|
1. Display USB device information |
Display information about USB devices and buses. | |
2. Unconfigure a USB device |
Logically unconfigure a USB device that is still physically connected to the system. | |
3. Configure a USB device |
Configure a USB device that was previously unconfigured. | |
4. Logically disconnect a USB device |
You can logically disconnect a USB device if you are not physically near the system. | |
5. Logically connect a USB device |
Logically connect a USB device that was previously logically disconnected or unconfigured. | |
6. Disconnect a USB device subtree |
Disconnect a USB device subtree, which is the hierarchy (or tree) of devices below a hub. | |
7. Reset a USB device |
Reset a USB device to logically remove and recreate the device. |
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 that might be configured into the system, and
A receptacle, which is the location that accepts the occupant.
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.
Receptacle State |
Description |
---|---|
empty/unconfigured |
The device is not connected. |
disconnected/unconfigured |
The device is logically disconnected and unavailable. The devinfo node is removed even though the device could still be physically connected. |
connected/unconfigured |
The device is logically connected, but unavailable. The devinfo node is present. |
connected/configured |
The device is connected and available. |
The following sections describe how to hot-plugging a USB device with the cfgadm command. All of the sample USB device information in these sections has been truncated to focus on relevant information.
Use the prtconf command to display information about USB devices.
$ 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) |
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 <no cfg str descr> usb0/4.5.3 Mfg: Mitsumi Product: Apple USB Mouse NConfigs: 1 Config: 0 <no cfg str descr> 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 : Default 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 # |
You can unconfigure a USB device that is still physically connected to the system, but a driver will never attach to it. After the USB device is unconfigured, the device is visible in the prtconf output.
Become superuser.
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 |
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 |
Become superuser.
# cfgadm -c configure usb0/4.7 |
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 |
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.
Become superuser.
Disconnect a USB device.
# cfgadm -c disconnect -y usb0/4.7 |
Verify that the device is disconnected.
# cfgadm usb0/4.7 Ap_Id Type Receptacle Occupant Condition usb0/4.7 unknown disconnected unconfigured ok |
Use this procedure to logically connect a USB device that was previously logically disconnected or unconfigured.
Become superuser.
# cfgadm -c configure usb0/4.7 |
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.
Use this procedure to disconnect a USB device subtree, which is the hierarchy (or tree) of devices below a hub.
Become superuser.
# cfgadm -c disconnect -y usb0/4 |
Verify that the USB device subtree is disconnected.
# cfgadm usb0/4 Ap_Id Type Receptacle Occupant Condition usb0/4 unknown disconnected unconfigured ok |
If a USB device behaves erratically, use the cfgadm command to reset the device, which logically removes and recreates the device.