Oracle Solaris supports all USB 3.0 devices that use the USB 3.0 xhci host controller driver, with the exception of audio devices. Backward compatibility with previous USB versions enables you to use the same hardware and software components for USB 2.0 , 1.1, and 1.0 devices on USB 3.0 ports. However, for audio devices, only USB 2.0, 1.1, and 1.0 are supported.
A single XHCI host controller supports all speeds of the USB devices. If you are using USB 2.0 ports for devices, different host controller interface drivers are dynamically assigned depending on whether those devices support USB 2.0.
For better performance, always connect USB 3.0 and USB 2.0 devices to corresponding USB 3.0 and USB 2.0 ports. A USB 3.0 or USB 2.0 port can be on any of the following components:
A USB PCI card
A USB hub that is connected to a USB port
A SPARC or x86 computer motherboard
The following man pages provide information about USB versions:
The following man pages provide information about specific USB devices:
For information about specifications of different USB versions, go to http://www.usb.org/home.
To identify the speed of your USB device, check the /var/adm/messages file for messages similar to the following:
Dec 13 17:05:57 mysystem usba: [ID 912658 kern.info] USB 2.0 device (usb50d,249) operating at hi speed (USB 2.x) on USB 2.0 external hub: storage@4, scsa2usb0 at bus address 4
Except where indicated, Oracle Solaris supports USB devices on both SPARC and x86 based systems. Additional storage devices might work by modifying the scsa2usb.conf file. For more information, see the scsa2usb(7D) man page.
The following sections provide additional information about specific USB devices.
USB hubs are not self-powered. They supply power to connected devices by deriving it from the USB bus to which they are connected. Consequently, and also because of power management, power to these downstream devices is limited. Therefore, avoid overloading these hubs. Note specifically the following limitations:
You cannot cascade two bus-powered hubs.
Each bus-powered hub is limited to a maximum of 100 mA only for each port.
You can connect only self-powered or low bus-powered devices, not high bus-powered devices, to a bus-powered hub.
Some hubs or devices can report a false power source. With such hubs, the connection might be unpredictable.
On SPARC based systems, do not remove the keyboard and mouse during a system reboot or at the ok prompt. During the boot process, the OpenBoot PROM (OBP) limits keyboard and mouse devices to the motherboard root hub ports only. You can move the keyboard and mouse to another hub at any time after a system reboot. These devices become fully functional after you plug them to their ports.
On SPARC based systems, note the following issues with regards to these devices:
The power key behaves differently between a USB keyboard and a type 5 keyboard. On a USB keyboard, the SUSPEND/SHUTDOWN key suspends or shuts down the system. However, that key cannot power up the system.
On legacy SPARC based systems, USB keyboard and mouse devices do not work simultaneously with Type 3, 4, or 5 keyboards.
For information about multiple keyboard and mouse device support, see the virtualkm(7D) man page.
The USB host controller has an embedded hub called the root hub whose ports are visible on the system's back panel.
When using USB hubs, avoid the following:
Cascading hubs beyond four levels on either SPARC based systems or x86 based systems. On SPARC systems, the OpenBoot PROM cannot reliably probe beyond four levels of devices.
Cascading bus-powered hubs. A bus-powered hub does not have its own power supply.
Connecting a device that requires a large amount of power to a bus-powered hub might drain the hub of power for other devices. Bus-powered hubs might deny connection to these devices.
Suspending and resuming USB device services are fully supported on SPARC systems. However, do not suspend a device that is busy. Likewise, never remove a device when the system is powered off under a suspend shutdown.
When power management is enabled on the system, the USB framework manages power on all devices. For example, the hub driver suspends the port to which the device is connected.
Devices that support remote wake up can notify the system to restore power to the device's path so that the device can be used. The host system can also restore power to the device if an application sends an I/O to the device.
Power management is implemented on all devices that support remote wake-up capability. On USB printers, power management functions only between two print jobs. On devices that use the generic USB driver (UGEN), power management runs only when the devices are closed.