From sacadmin Mon Apr 4 17:10:37 2005 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j350AbSp013646 for ; Mon, 4 Apr 2005 17:10:37 -0700 (PDT) Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id j3508me08362; Mon, 4 Apr 2005 18:08:48 -0600 (MDT) Received: from phys-bos-2.sfbay.sun.com (phys-bos-2.SFBay.Sun.COM [129.146.14.24]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j3508mjg006481; Mon, 4 Apr 2005 17:08:48 -0700 (PDT) Received: from vanburen (vpn-129-150-26-135.SFBay.Sun.COM [129.150.26.135]) by bos-mail1.sfbay.sun.com (Sun Java System Messaging Server 6.2 HotFix 0.05 (built Jan 10 2005)) with SMTP id <0IEG007JC5QNT780@bos-mail1.sfbay.sun.com>; Mon, 04 Apr 2005 17:08:48 -0700 (PDT) Date: Mon, 04 Apr 2005 17:08:26 -0700 (PDT) From: frits Subject: PSARC/2004/779 SATA HBA Framework Support To: psarc@sun.com Cc: sata-dev@sun.com Reply-to: frits Message-id: <0IEG007JD5QNT780@bos-mail1.sfbay.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_43 SunOS 5.10 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-MD5: eP8d2bArFmYBgwoCyYUw1w== Status: RO Content-Length: 36591 I am sponsoring this fast track for Pawel Wojcik and the sata development team. The timer has been set to 4/13/2005 The proposed interfaces are Consolidation Private and may be promoted in a future case after more HBA drivers have been written. The man pages have been deposited in the case directory The release binding is "patch/micro". A glossary is in section 6. fritS 1 Introduction ---------------- Serial ATA (SATA) is the next generation storage interconnect, designed to replace parallel ATA (PATA) technology. SATA is the proactive evolution of the ATA interface from a parallel bus to a serial bus architecture. SATA delivers better functionality and higher performance then parallel ATA (PATA) technology. Some of the features include enhanced command queuing, hotplugging support, point-to-point connectivity and fine-grained power managment. Command Queuing and it's SATA-2 enhanced version called Native Command Queueing (NCQ) provides I/O throughput comparable to SCSI, at lower device cost. Hotplugging support increases system maintainability. Point-to-point connectivity eliminates bus arbitration and contention. Fine-grained power managment allows better power managment with lesser performance impact. Serial ATA International Organization (SATA-IO) is the group responsible for defining the specification and driving the adoption of SATA technology. See the reference [4,5] for more information. Other operating systems, like Windows XP and Linux already have SATA controller drivers utilizing advances SATA features such as command queuing and hotplug. Existing SATA support in Solaris does not support these features, rendering Solaris-running systems slower and less competitive. Current Solaris support for SATA controllers utilizes pci-ide/ata driver combination and is limited to controllers operating in a compatibility mode, emulating generic parallel ATA controllers (register layout and functionality). These drivers limits the SATA controllers and devices functionality to that of a PATA functionality. Some of the limitations are: * Non-compatibility mode is not supported * Hotplug feature is not supported * 'cmdk' target driver doesn't have all the functionality as in 'sd' driver (e.g: Tag Queuing feature). * The current 'cmdk' devinfo model doesn't cover all possible SATA hw configurations (e.g: port multiplier, multiple ports for each controller, etc.). * Existing implementation of ATA controllers are platform specific, one set of drivers for sparc, and one for x86. * Existing pci-ide/ata framework interfaces are not public, thus requiring Sun to invest into development of drivers for any new SATA controllers. Extensive modification of existing, generic pci-ide and ata drivers to support advanced SATA features and variety of SATA controllers that do not emulate parallel ATA controller cannot be justified. Instead, a new SATA framework is being developed that is designed from the start to incorporate the SATA features, and designed to allow for the eventual development of SATA HBA drivers by third parties. SATA controllers are expected to evolve fast and be increasingly employed in a variety of platforms, including systems manufactured by Sun. Unification of the driver for all platforms is desired, to lower maintenance cost. NSG platforms (e.g: Thumper) based on Opteron processors use SATA controllers operating in non-compatible mode. SATA hotplug feature is one of the requirements for Thumper platform. Also, there are several new platforms from OEMs like Intel, Dell, HP, etc. that use new SATA controller interfaces which are considered Tier 1 systems for Solaris/X86 market. 2 Proposal Summary -------------------- This project proposes a new framework for supporting SATA HBA controller drivers working in conjunction with existing SCSA framework and the common sd target driver. Attached SATA devices will be seen by the operating system as SCSI devices. The SATA HBA framework will take care of SCSA interface, SCSI to SATA translation, command emulation, hotplug support and cfgadm interfacing, port multiplier support, SCSI device enumeration and target, control and attachment point nodes creation. The controller specific SATA HBA driver will only deal with hardware specific implementation of the SATA port interfaces and device detection and control. SATA HBA framework with cooperating SATA HBA driver emulates SCSI HBA driver and SCSI drives behavior and functionality, satisfying the SCSA interface and sd target driver expectations like a typical SCSI HBA driver. The implementation will based on the SATA specification version 1.0a with selected SATA II extensions, for hotplugging, Port Multiplier, Native Command Queuing (NCQ) and Gen-2 Signaling Speed. The SATA framework interfaces requested committment level is Consolidation Private. The major components of the project are: o SATA HBA framework kernel module, platform neutral o cfgadm(1m) plug-in for SATA hotplug support o SATA HBA driver for Marvel controller hardware (88SX50XX/88SX60XX), platform neutral o Man page describing SATA cfgadm user interface o Man pages describing the interface for SATA HBA driver The implementation will be tested on the NSG platform, code named 'Thumper', that uses Marvel SATA controller (88SX5080 and 88SX6080). Additional SATA HBA driver for a different architecture SATA controller (SiliconImage 3124) is developed in parallel to this project to validate the generality of the SATA HBA framework functionality and interface. Initially delivered components will not support Fault Managment Architecture, i.e. will declare to FMA that they do not support any FMA features. The FMA support will be added in the second phase of the project. The PSARC Fast Track review is expected to provide overall review of the proposed architecture and proposed interfaces. 3 Goals and Requirements ------------------------- The main goal of this project is to implement generic SATA HBA driver framework in Solaris with stable interfaces facilitaiting internal SATA drivers development, as well as unification of SATA support for x86 and SPARC platforms and reuse of established SCSA framework and sd target driver. In the future, raising commitment level will facilitate development of SATA HBA driver by third-party developers. The requirements for the SATA HBA framework are: * Re-use of existing SCSA framework functionality and interfaces. * Re-use of common sd driver as a target driver. * Simple interface to SATA HBA drivers. * Support for SATA II features: hotplugging support, Native Command Queuing, Port Multiplier support. * Compatibility with cfgadm interface for hotplug. * Platform neutrality. * Flexibility and extensibility of the SATA HBA interface to accommodate needs of existing and future SATA controllers and Solaris OS. * Stable and fully defined interface with SATA HBA drivers suitable for third-party driver developers. 4 Technical Description ------------------------- 4.1 Architecture 4.1.1 Basic Architecture Model +-----------------+ | cfgadm | +-------^---------+ | v +=================+ | SATA Hot Plug | SATA specific | library | plug-in +=======^=========+ library | Solaris I/O | ^ | USER | ======================|================================|================ | KERNEL | | +-------v---------+ cfgadm plug-in | | SD driver | IOCTLs | | (target driver) | | +-------^---------+ | ^ | SCSA | +=========v==========+ Interface +-------v---------+ | SATA HBA Framework |<----------->| SCSA Framework | +=========^==========+ +-----------------+ | | SATA HBA | Interface | +=========v==========+ | SATA HBA Driver | | (eg. Marvel driver)| +====================+ | V ( SATA devices: SATA disks, SATA ATAPI CDROMs, ...) Figure 1: Basic Architecture Model Diagram 4.1.2 Components The proposed SATA driver architecture model consists of the following components: 4.1.2.1 SATA HBA Framework (new) Implemented as a kernel module that interfaces with the SCSA framework and cfgadm and provides generic SATA interfaces to hardware specific SATA HBA driver. The SATA HBA framework : * Implements and exports generic SCSI HBA interface. * Performs initial SATA devices configuration and setup, including Port Multipliers. * Emulates SCSI operations that have no equivalent in SATA. * Translates SCSI operations into appropriate SATA operations. * Controls SATA operation sequences needed for SCSI operations. * Provides data buffer DMA resources setup. * Translates SATA operation status and error information into SCSI format. * Provides devctl interface for cfgadm. * Controls hotplug and operator-directed operations. * Performs dynamic reconfiguration based on asynchronous hotplug events. All access to the SATA HBA driver (and SATA HBA) is via SATA HBA framework. SATA HBA framework presents to the system each registered instance of the SATA HBA as the SCSI HBA instance. The basic functionality of SCSI HBA driver is provided by combined SATA HBA framework and SATA HBA driver functionality. Attached SATA devices are treated as SCSI devices and are controlled by the sd target driver via SCSI transport layer. The SATA device nodes are self-identifying, as they are connected point-to-point to device ports. The sd nodes and their properties are created dynamically (using standard nexus mechanisms) by SATA HBA framework during SATA HBA instance attachment process and are removed/added dynamically in response to hotplug events. Operation requests for the SATA HBA passed via sata packet driver are simple basic operations on the SATA ports and requests for handling SATA device commands. Operations specified by scsi packets are translated by SATA HBA framework into equivalent SATA device operations (in SATA packet envelope - sata packet), or emulated within the framework, or rejected if none of the above could be done. Data buffer DMA mapping and DMA resources allocation is performed by the SATA HBA framework. While translating SCSI operations into SATA operations, SATA HBA framework takes into consideration SATA HBA capabilities and attached devices capabilities and sends to SATA HBA driver (via SATA HBA Interface) fully formed SATA device commands, including standard registers setup. The status of the SATA operation, including error information is translated into SCSI format by SATA HBA framework. SATA HBA framework creates control nodes for each device port. Device control IOCTLs are processed by the SATA HBA framework and are translated into SATA operations, if necessary. IOCTLs that cannot be handled by SATA HBA framework are passed to standard nexus IOCTL handler ndi_devctl_ioctl(). Hotplug events detected by the SATA HBA driver are handled by SATA HBA framework which performs necessary internal configuration/reconfiguration and error handling operations. 4.1.2.2 SATA HBA driver (new) Controller/Hardware specific driver (e.g: Marvel driver) in Solaris written for the interfaces defined by the SATA HBA framework. The controller-specific SATA HBA driver: * Registers itself with the SATA HBA framework * Attaches/detaches each instance of the HBA via SATA HBA framework service functions * Monitors and reports state of the SATA device ports * Maintains connection with attached SATA devices and Port Multipliers * Reports changes of SATA device ports state * Sends SATA commands to attached devices and controls transfer of data and status of the operations * Controls SATA commands queuing and execution order * Performs control operations requested by SATA HBA framework on ports and devices HBA capabilities and configuration are exposed to SATA HBA framework via sata_hba_tran interface structure along with the vector of interface functions. SATA HBA framework invokes HBA services by calling exported functions. SATA HBA driver is not aware of SCSA interface requirements nor SCSI-to-SATA translations. 4.1.2.3 SCSA Framework The current SCSA framework in Solaris. The SCSI transport layer provides interface between sd target driver and SATA HBA framework/SATA HBA instance registered with the SCSA framework as SCSI HBA instance. 4.1.2.4 sd target Driver The current Solaris 'sd' driver. No changes are necessary. Some performance improvement may be gained if sd driver could be made aware of the SATA queue depth. 4.1.2.5 cfgadm(1m) plug-in for SATA (new) Implements SATA specific hotplug operations for cfgadm(1m) framework. It uses devctl_* interfaces defined in libdevice.so to communicate with the SATA HBA framework to perform hotplug operations on the attachment point. This plug-in will not support enclosure nor storage arrays hotplugging. 4.2 Interfaces The new interfaces are of Consolidation Private stability classifications. Interfaces on Figure 1 labeled 'SATA HBA Interface' and 'cfgadm plug-in IOCTLs' are of particular interest as they are defined on the SATA HBA framework boundary. 4.2.1 Exported Interfaces Exported Interfaces are new interfaces (to be reviewed by PSARC). All new interfaces are Consolidation Private. +------------------------------------------------------------------------------+ | Interface | Classification | Comments | | | | | |------------------------------------------------------------------------------| | sata | Consolidation | New kernel module | |------------------------------------------------------------------------------| | sata_hba_tran | Consolidation | SATA Host Bus Adapter (HBA) | | | Private | driver transport vector struct| |------------------------------------------------------------------------------| | sata_tran_probe_port() | Consolidation | sata_hba_tran component | | | Private | | |------------------------------------------------------------------------------| | sata_tran_start() | Consolidation | sata_hba_tran component | | | Private | | |------------------------------------------------------------------------------| | sata_tran_abort() | Consolidation | sata_hba_tran component | | | Private | | |------------------------------------------------------------------------------| | sata_tran_reset_dport() | Consolidation | sata_hba_tran component | | | Private | | |------------------------------------------------------------------------------| | sata_tran_selftest() | Consolidation | sata_hba_tran component | | | Private | | |------------------------------------------------------------------------------| | sata_tran_hotplug_ops | Consolidation | sata_hba_tran component | |------------------------------------------------------------------------------| | sata_tran_port_activate() | Consolidation | sata_tran__hotplug_ops | | | Private | component | |------------------------------------------------------------------------------| | sata_tran_port_deactivate()| Consolidation | sata_tran_hotplug_ops | | | Private | component | |------------------------------------------------------------------------------| | sata_tran_pwrmgt_ops | Consolidation | sata_hba_tran component | | | Private | | |------------------------------------------------------------------------------| | sata_tran_get_pwr_level() | Consolidation | sata_tran_pwrmgt_ops | | | Private | component | |------------------------------------------------------------------------------| | sata_tran_ioctl() | Consolidation | sata_hba_tran component | | | Private | | |------------------------------------------------------------------------------| | sata_address | Consolidation | structure specifying SATA | | | Private | or device location | |------------------------------------------------------------------------------| | sata_device | Consolidation | structure describing state of | | | Private | SATA port and type of an | | | | attached device | |------------------------------------------------------------------------------| | sata_pkt | Consolidation | structure defining sata packet| | | Private | - device, buffer, operation, | | | | status, etc. | |------------------------------------------------------------------------------| | sata_cmd | Consolidation | Structure specifying SATA cmd | | | Private | and information necessary for | | | | cmd execution. | |------------------------------------------------------------------------------| | sata_hba_init() | Consolidation | Register SATA HBA driver with | | | Private | SATA HBA framework | |------------------------------------------------------------------------------| | sata_hba_attach() | Consolidation |Attach SATA HBA driver instance| | | Private | | |------------------------------------------------------------------------------| | sata_hba_detach() | Consolidation |Detach SATA HBA driver instance| | | Private | | |------------------------------------------------------------------------------| | sata_hba_fini() | Consolidation | Unregister SATA HBA driver | | | Private | from SATA HBA framework | |------------------------------------------------------------------------------| | sata_hba_event_notify() | Consolidation | Report asynchronous event | | | Private | SATA HBA framework | |------------------------------------------------------------------------------| | sata.so.1 | Consolidation | Class bound cfgadm plug-in for| | | Private | attachment point of class sata| |------------------------------------------------------------------------------| | SATA devctl node | Consolidation | Devctl node (minor number | | (minor number) | Private | format) | |------------------------------------------------------------------------------| | SATA AP node | Consolidation | Attachment Point node | | (minor number) | Private | (minor number format) | |------------------------------------------------------------------------------| | SATA_AP_MINOR_TO_SATA_ADDRESS | Consolidation| Macro used by cfgadm plug-in | | | Private | | |------------------------------------------------------------------------------| | SATA_AP_MINOR_TO_INSTANCE | Consolidation | Macro used by cfgadm plug-in | | | Private | | |------------------------------------------------------------------------------| | DDI_NT_SATA_ATTACHMENT_POINT | Consolidation | SATA attachment point type | | | Private | | |------------------------------------------------------------------------------| | SATA_CFGA_RESET_PORT | Consolidation | Subcommand of | | | Private | DEVCTL_AP_CONTROL | |------------------------------------------------------------------------------| | SATA_CFGA_RESET_DEVICE | Consolidation | Subcommand of | | | Private | DEVCTL_AP_CONTROL | |------------------------------------------------------------------------------| | SATA_CFGA_SELF_TEST | Consolidation | Subcommand of | | | Private | DEVCTL_AP_CONTROL | |------------------------------------------------------------------------------| | SATA_CFGA_GET_AP_TYPE | Consolidation | Subcommand of | | | Private | DEVCTL_AP_CONTROL | |------------------------------------------------------------------------------| | SATA_CFGA_GET_AP_INFO | Consolidation | Subcommand of | | | Private | DEVCTL_AP_CONTROL | +------------------------------------------------------------------------------+ 4.2.1.1 Exported Interfaces Description The sata_hba_tran structure is the basic interface between SATA HBA framework and SATA HBA driver. It describes SATA HBA instance capabilities and basic SATA ports configuration and contains a functions vector used for passing requests from SATA HBA framework to SATA HBA driver. This structure is linked with a SATA HBA framework software state structure specific to the attached SATA HBA instance. The sata_address structure is used to specify address of the sata port or the SATA device itself. The sata_device structure contains sata_address and information related to the addressed SATA port or SATA device. The sata_pkt structure is used to pass fully formed SATA command and all information necessary for execution of such SATA command, including data buffer, allocated data buffer DMA resources, status and error information. This structure is linked (using opaque pointer) to scsi packet, so SATA HBA framework can maintain corelation between scsi packet sent from sd target driver and sata packet used to communicate with SATA HBA driver. The sata_cmd structure is used to specify in SATA command, including standard register content, and adition information needed for cmd setup and execution. The sata_hba_init() and sata_hba_fini() are SATA HBA framework functions used to register/unregister SATA HBA driver to/from SATA HBA framework. SATA HBA driver calling these function causes SATA HBA framework to call SCSA interface registering/unregistering SCSI HBA driver. The sata_hba_attach() and sata_hba_detach() are SATA HBA framework functions used to attach/detach specific SATA HBA instance. The sata_hba_event_notify() is SATA HBA framework function used by SATA HBA driver to pass hotplug event notification. The sata.so.1 is sata-specific cfgadm plug-in implementing SATA hotplug operations and sata-specific control operations. The devctl and Attachment Point minor number is used to specify controller and attachment point (SATA device port). The format of the minor number allows for 64 controllers with up to 32 SATA ports each, up to 2048 directly attached SATA devices and up to 30720 attached SATA devices when port multipliers are employed. 17 bits of the minor device number are used for this purpose. SATA_AP_MINOR_TO_* are macros converting minor number to controller instance and to SATA port address. DDI_NT_SATA_ATTACHMENT_POINT is a new type of the attachment point created for each SATA device port. SATA_CFGA_* are subcommands of DEVCTL_AP_CONTROL ioctl used by cfgadm SATA plug-in to fetch an attachement point related data and to request SATA device port related test and recovery operations. For further details please refer to SATA HBA framework Specification http://solaris-x86.sfbay/Projects/SATA/SHF_Functional_Spec.html 4.2.2 Imported Interfaces These interfaces are stable or Consolidation Private interfaces. +------------------------------------------------------------------------------+ | Interface | Classification | Comments | | | | | |------------------------------------------------------------------------------| | scsi | stable | Existing SCSA framework | | | | Kernel module | |------------------------------------------------------------------------------| | scsi_hba_tran | stable | SCSI Host Bus Adapter (HBA) | | | | driver transport vector struct| | | | scsi_hab_tran(9s) | |------------------------------------------------------------------------------| | scsi_hba_attach() | stable | scsi_hba_attach(9F) | |------------------------------------------------------------------------------| | scsi_hba_detach() | stable | scsi_hba_detach(9F) | |------------------------------------------------------------------------------| | scsi_hba_pkt_alloc() | stable | scsi_hba_pkt_alloc(9F) | |------------------------------------------------------------------------------| | scsi_hba_pkt_free() | stable | scsi_hba_pkt_free(9F) | |------------------------------------------------------------------------------| | scsi_hba_init() | stable | scsi_hba_init(9F) | |------------------------------------------------------------------------------| | scsi_hba_fini() | stable | scsi_hba_fini(9F) | |------------------------------------------------------------------------------| | scsi_pkt | stable | scsi_pkt(9S) | |------------------------------------------------------------------------------| | SCMD_* | stable | Subset of SCSA command list. | | | | Mandatory comands only | |------------------------------------------------------------------------------| | ddi_dma_attr | stable | ddi_dma_attr_t(9s) | |------------------------------------------------------------------------------| | cb_ops | stable | cb_ops(9s) | |------------------------------------------------------------------------------| | cb_open | stable | cb_open(9s) | |------------------------------------------------------------------------------| | cb_close | stable | cb_close(9s) | |------------------------------------------------------------------------------| | cb_ioctl | stable | cb_ioctl(9s) | |------------------------------------------------------------------------------| | ndi_devi_alloc_sleep()| Consolidation Private| Nexus interface | |------------------------------------------------------------------------------| | ndi_devi_online() | Consolidation Private | Nexus interface | |------------------------------------------------------------------------------| | ndi_devi_offline() | Consolidation Private | Nexus interface | |------------------------------------------------------------------------------| | ndi_devi_free() | Consolidation Private | Nexus interface | |------------------------------------------------------------------------------| | ndi_devi_ioctl() | Consolidation Private | Nexus interface | |------------------------------------------------------------------------------| | DEVCTL_BUS_GETSTATE | Consolidation Private | passed to ndi_devctl_ioctl() | |------------------------------------------------------------------------------| | DEVCTL_DEVICE_ONLINE | Consolidation Private | passed to ndi_devctl_ioctl() | |------------------------------------------------------------------------------| | DEVCTL_DEVICE_OFFLINE| Consolidation Private | passed to ndi_devctl_ioctl() | |------------------------------------------------------------------------------| | DEVCTL_DEVICE_GETSTATE| Consolidation Private| passed to ndi_devctl_ioctl() | |------------------------------------------------------------------------------| | DEVCTL_DEVICE_REMOVE | Consolidation Private | passed to ndi_devctl_ioctl() | |------------------------------------------------------------------------------| | DEVCTL_BUS_DEV_CREATE| Consolidation Private | passed to ndi_devctl_ioctl() | |------------------------------------------------------------------------------| | DEVCTL_BUS_RESET | Consolidation Private | converted to port reset | |------------------------------------------------------------------------------| | DEVCTL_BUS_RESETALL | Consolidation Private | no op | |------------------------------------------------------------------------------| | DEVCTL_BUS_QUIESCE | Consolidation Private | no op | |------------------------------------------------------------------------------| | DEVCTL_BUS_UNQUIESCE | Consolidation Private | no op | |------------------------------------------------------------------------------| | cfgadm | stable | cfgadm(1M) | |------------------------------------------------------------------------------| | DEVCTL_AP_DISCONNECT | Consolidation Private | existing attachment point | | | | operation | |------------------------------------------------------------------------------| | DEVCTL_AP_UNCONFIGURE| Consolidation Private | existing attachment point | | | | operation | |------------------------------------------------------------------------------| | DEVCTL_AP_CONNECT | Consolidation Private | existing attachment point | | | | operation | |------------------------------------------------------------------------------| | DEVCTL_AP_CONFIGURE | Consolidation Private | existing attachment point | | | | operation | |------------------------------------------------------------------------------| | DEVCTL_GET_STATE | Consolidation Private | existing attachment point | | | | operation | |------------------------------------------------------------------------------| | DEVCTL_AP_CONTROL | Consolidation Private | existing attachment point | | | | operation | +------------------------------------------------------------------------------+ 4.2.1.1 Imported Interfaces Description Majority of imported interfaces are public, stable interfaces described in man pages. Nexus interfaces are Consolidation Private. The SCSI command set SCMD_* is a minimal required SCSI command set, a subset of all SCSI commands supported by the sd target driver. Unsupported SCSI commands are rejected by the SATA HBA framework or SATA HBA driver with appropriate sense information returned in scsi_pkt, emulating the behavior of a SCSI device that rejects unsupported command. 4.3 User Interface This project uses standard cfgadm(1M) user command interface to manually control hotplug operations. No other user interface is defined. The proposal for SATA-specific cfgadm plug-in user interface will be submitted as a separate Fast Track PSARC case. For details refer to http://solaris-x86.sfbay.sun.com/Projects/SATA/cfgadm_sata.txt In the future expansion of the SATA HBA framework functionality the automatic detection of the hotplug events by a SATA HBA driver may be propagated to the event framework. 5 References -------------- [1] Information Technology AT Attachment with Packet Interface - 7, Volume 1 [2] Information Technology AT Attachment with Packet Interface - 7, Volume 2 [3] Information Technology AT Attachment with Packet Interface - 7, Volume 2 [4] Serial ATA: High Speed Serialized AT Attachment 1.0.a [5] Serial ATA II: Extensions to Serial ATA 1.0.a [6] Serial ATA II: Port Multiplier; rev 1.1 [7] SCSI/ATA Translation (SAT) draft T10/1711-D rev 2 [8] SATA HBA Framework Functional Specification 6 Glossary ----------- Explanation of uncommon terms: Compatibilty mode / non-compatability mode: These terms are used in other offcial documents in differing contexts. In this document, compatibility mode refers to a tranditional PATA controller which presents a standardized ATA register set layout and register functionality. Non-compatible mode refers to controllers that do not not present such a standard layout and a registers functionality. Often a layout is proprietary and not compatible with any other SATA controller. GEN-2 Signaling Speed: 3.0 Gbps, signaling speed of SATA II physical interface NCQ (Native Command Queuing): The command queuing model derived from legacy queuing but with enhancement to take advantage of Serial ATA and minimizing required protocol round trips to reduce overhead. Port Multiplier: A device allowing one active host serial connection to be multiplexed to multiple device connections. Only one active host connection is supported (via dedicated "host" port) and up to 15 device connections (device ports). Port multipliers cannot be cascaded. SATA: Serial ATA. An evolution of Parallel ATA physical storage interface. Serial ATA is a serial link -- a single cable with a minimum of four wires creates a point-to-point connection between devices. The serial protocol was defined by ATA/ATAPI-7 V3 specification. The Serial ATA International Organization (SATA-IO) is currently the group responsible for developing, managing and driving adoption of the Serial ATA specification (currently revision 1.0a.) SATA II: Enhancement to Serial ATA 1.0a specification that provides additional capabilities while retaining Serial ATA 1.0a compatibility and desktop cost structure. SATA Device Port: A port (with PHY) that can be used to connect SATA device. SATA PHY SATA Physical Layer interface From sacadmin Mon Apr 4 17:42:52 2005 Received: from sunmail3.sfbay.sun.com (sunmail3.SFBay.Sun.COM [129.149.247.180]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j350gqSp014588 for ; Mon, 4 Apr 2005 17:42:52 -0700 (PDT) Received: from eastmail2bur.East.Sun.COM (eastmail2bur.East.Sun.COM [129.148.13.40]) by sunmail3.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id j350f4Z16153; Mon, 4 Apr 2005 17:41:04 -0700 (PDT) Received: from thunk (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j350f3Op007829; Mon, 4 Apr 2005 20:41:03 -0400 (EDT) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk (8.13.3+Sun/8.13.3) with ESMTP id j350f2dE017446; Mon, 4 Apr 2005 20:41:03 -0400 (EDT) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.3+Sun/8.13.3/Submit) id j350f2cq017445; Mon, 4 Apr 2005 20:41:02 -0400 (EDT) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: PSARC/2004/779 SATA HBA Framework Support From: Bill Sommerfeld To: frits Cc: psarc@sun.com, sata-dev@sun.com In-Reply-To: <0IEG007JD5QNT780@bos-mail1.sfbay.sun.com> References: <0IEG007JD5QNT780@bos-mail1.sfbay.sun.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1112661661.13395.744.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.309 Date: Mon, 04 Apr 2005 20:41:02 -0400 Status: RO Content-Length: 253 what's the user experience for migration to the new driver? i.e., if you have a system running with the existing driver in compat mode and you switch to the new driver, do disks get renumbered/renamed? how is the transition managed? - Bill From sacadmin Mon Apr 4 17:50:44 2005 Received: from sunmail2.sfbay.sun.com (sunmail2.SFBay.Sun.COM [129.149.246.180]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j350oiSp014806 for ; Mon, 4 Apr 2005 17:50:44 -0700 (PDT) Received: from westmail1mpk.West.Sun.COM (westmail1mpk.West.Sun.COM [129.153.100.33]) by sunmail2.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id j350n0w00011; Mon, 4 Apr 2005 17:49:00 -0700 (PDT) Received: from hs-uego02-02.West.Sun.COM (hs-uego02-02.West.Sun.COM [129.153.3.2]) by westmail1mpk.West.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j350mx38009087; Mon, 4 Apr 2005 17:48:59 -0700 (PDT) Received: from [129.153.3.91] (palermo [129.153.3.91]) by hs-uego02-02.West.Sun.COM (8.12.10+Sun/8.12.10) with ESMTP id j350mx0O007966; Mon, 4 Apr 2005 17:48:59 -0700 (PDT) Message-ID: <4251E07B.60009@sun.com> Date: Mon, 04 Apr 2005 17:48:59 -0700 From: Pawel Wojcik Reply-To: pawel.wojcik@sun.com User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20041101 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bill Sommerfeld CC: frits , psarc@sun.com, sata-dev@sun.com Subject: Re: PSARC/2004/779 SATA HBA Framework Support References: <0IEG007JD5QNT780@bos-mail1.sfbay.sun.com> <1112661661.13395.744.camel@thunk> In-Reply-To: <1112661661.13395.744.camel@thunk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1043 Bill Sommerfeld wrote: > what's the user experience for migration to the new driver? > > i.e., if you have a system running with the existing driver in compat > mode and you switch to the new driver, do disks get renumbered/renamed? > how is the transition managed? > > - Bill > > The devices covered by the new drivers have not been supported before. If you physically move the devices from SATA controllers running in compatibility mode to the new SATA controllers covered by new drivers, the paths and names will change. -- Pawel Wojcik Sun Microsystems pawel.wojcik@Sun.com ********************************************* From sacadmin Mon Apr 4 18:01:39 2005 Received: from sunmail3.sfbay.sun.com (sunmail3.SFBay.Sun.COM [129.149.247.180]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j3511dSp017159 for ; Mon, 4 Apr 2005 18:01:39 -0700 (PDT) Received: from eastmail2bur.East.Sun.COM (eastmail2bur.East.Sun.COM [129.148.13.40]) by sunmail3.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id j350xpZ24531; Mon, 4 Apr 2005 17:59:51 -0700 (PDT) Received: from thunk (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j350xmOp010231; Mon, 4 Apr 2005 20:59:48 -0400 (EDT) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk (8.13.3+Sun/8.13.3) with ESMTP id j350xm9p017492; Mon, 4 Apr 2005 20:59:48 -0400 (EDT) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.3+Sun/8.13.3/Submit) id j350xmY2017491; Mon, 4 Apr 2005 20:59:48 -0400 (EDT) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: PSARC/2004/779 SATA HBA Framework Support From: Bill Sommerfeld To: pawel.wojcik@sun.com Cc: frits , psarc@sun.com, sata-dev@sun.com In-Reply-To: <4251E07B.60009@sun.com> References: <0IEG007JD5QNT780@bos-mail1.sfbay.sun.com> <1112661661.13395.744.camel@thunk> <4251E07B.60009@sun.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <1112662787.13395.792.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.309 Date: Mon, 04 Apr 2005 20:59:48 -0400 Status: RO Content-Length: 688 On Mon, 2005-04-04 at 20:48, Pawel Wojcik wrote: > The devices covered by the new drivers have not been supported before. ok. > If you physically move the devices from SATA controllers running in > compatibility mode to the new SATA controllers covered by new drivers, > the paths and names will change. right, but you'd expect that sort of thing with any disk recabling operation. digging further: is compatibility mode something which is hardwired in how a SATA controller chip is wired up, or is it switchable from software/firmware/bios? if it's switchable, aren't we going to face requests to exploit the whizzy new SATA features on existing platforms? - Bill From sacadmin Mon Apr 4 18:42:02 2005 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j351g2Sp017707 for ; Mon, 4 Apr 2005 18:42:02 -0700 (PDT) Received: from westmail2san.west.sun.com (westmail2san.West.Sun.COM [129.153.85.6]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id j351eHe19587; Mon, 4 Apr 2005 19:40:17 -0600 (MDT) Received: from hs-uego02-02.West.Sun.COM (hs-uego02-02.West.Sun.COM [129.153.3.2]) by westmail2san.west.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j351eG69015845; Mon, 4 Apr 2005 18:40:16 -0700 (PDT) Received: from [129.153.3.91] (palermo [129.153.3.91]) by hs-uego02-02.West.Sun.COM (8.12.10+Sun/8.12.10) with ESMTP id j351eF0O012029; Mon, 4 Apr 2005 18:40:16 -0700 (PDT) Message-ID: <4251EC7F.6030000@sun.com> Date: Mon, 04 Apr 2005 18:40:15 -0700 From: Pawel Wojcik Reply-To: pawel.wojcik@sun.com User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20041101 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bill Sommerfeld CC: frits , psarc@sun.com, sata-dev@sun.com Subject: Re: PSARC/2004/779 SATA HBA Framework Support References: <0IEG007JD5QNT780@bos-mail1.sfbay.sun.com> <1112661661.13395.744.camel@thunk> <4251E07B.60009@sun.com> <1112662787.13395.792.camel@thunk> In-Reply-To: <1112662787.13395.792.camel@thunk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 2428 Bill Sommerfeld wrote: > On Mon, 2005-04-04 at 20:48, Pawel Wojcik wrote: > >>The devices covered by the new drivers have not been supported before. > > > ok. > > >>If you physically move the devices from SATA controllers running in >>compatibility mode to the new SATA controllers covered by new drivers, >>the paths and names will change. > > > right, but you'd expect that sort of thing with any disk recabling > operation. > > digging further: is compatibility mode something which is hardwired in > how a SATA controller chip is wired up, or is it switchable from > software/firmware/bios? > It is usually hardwired. In controllers that support compatibility mode there is a set of registers conforming to old PATA interface and additional set of registers that allow enhanced SATA control. Additionally, pci subclass code may specify operation mode of the controller. Existing pci-ide/ata drivers will attach to such controller only if it exports MASS-STOREAGE/IDE class or MASS-STORAGE/OTHER class. > if it's switchable, aren't we going to face requests to exploit the > whizzy new SATA features on existing platforms? > > - Bill > > One popular controller that we care about falls into this category - Intel ICH6 SATA. Theoretically it could be "switched" from one mode to another by changing subclass code, the code is most likely fixed on system bases - the subclass code register has read-only attribute. The sunclass code "switching" was not fully investigated (no business justification yet). However, this controller is not officially supported even in compatibility mode and the plan is to create for it SATA driver using SATA HBA framework, when controller exports MASS-STORAGE/SATA class. There is similar situation with NVidia SATA controller - we plan to support it only in "native" SATA mode, and it is not officially supported in a compatible mode. > > > > -- Pawel Wojcik Sun Microsystems pawel.wojcik@Sun.com ********************************************* From sacadmin Tue Apr 5 04:35:49 2005 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j35BZmSp017745 for ; Tue, 5 Apr 2005 04:35:48 -0700 (PDT) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id j35BXxe07100; Tue, 5 Apr 2005 05:34:00 -0600 (MDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j35BXxRJ000134; Tue, 5 Apr 2005 07:33:59 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j35BXxVi000131; Tue, 5 Apr 2005 07:33:59 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16978.30631.5495.800994@gargle.gargle.HOWL> Date: Tue, 5 Apr 2005 07:33:59 -0400 From: James Carlson To: Pawel.Wojcik@Sun.COM Cc: Bill Sommerfeld , frits , psarc@Sun.COM, sata-dev@Sun.COM Subject: Re: PSARC/2004/779 SATA HBA Framework Support In-Reply-To: Pawel Wojcik's message of 4 April 2005 18:40:15 References: <0IEG007JD5QNT780@bos-mail1.sfbay.sun.com> <1112661661.13395.744.camel@thunk> <4251E07B.60009@sun.com> <1112662787.13395.792.camel@thunk> <4251EC7F.6030000@sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 1005 Pawel Wojcik writes: > > if it's switchable, aren't we going to face requests to exploit the > > whizzy new SATA features on existing platforms? > > > > - Bill > > > > > One popular controller that we care about falls into this category - > Intel ICH6 SATA. Theoretically it could be "switched" from one mode to > another by changing subclass code, the code is most likely fixed on > system bases - the subclass code register has read-only attribute. The > sunclass code "switching" was not fully investigated (no business > justification yet). What about Si3114? It's supported today, but runs with the old cmdk driver. Will this switch over to the new framework (and thus see drive renaming), or are existing platforms using Si3114 stuck with the cmdk forever? -- James Carlson, KISS Interop Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From sacadmin Tue Apr 5 09:00:12 2005 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j35G0BSp004581 for ; Tue, 5 Apr 2005 09:00:12 -0700 (PDT) Received: from westmail2san.west.sun.com (westmail2san.West.Sun.COM [129.153.85.6]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id j35FwRe02574; Tue, 5 Apr 2005 09:58:28 -0600 (MDT) Received: from hs-uego02-02.West.Sun.COM (hs-uego02-02.West.Sun.COM [129.153.3.2]) by westmail2san.west.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j35FwR69025348; Tue, 5 Apr 2005 08:58:27 -0700 (PDT) Received: from thora (thora [129.153.3.52]) by hs-uego02-02.West.Sun.COM (8.12.10+Sun/8.12.10) with SMTP id j35FwR0P023166; Tue, 5 Apr 2005 08:58:27 -0700 (PDT) Message-Id: <200504051558.j35FwR0P023166@hs-uego02-02.West.Sun.COM> Date: Tue, 5 Apr 2005 08:58:27 -0700 (PDT) From: Mike Riley Reply-To: Mike Riley Subject: Re: PSARC/2004/779 SATA HBA Framework Support To: psarc@sun.com, sata-dev@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: ZFaK0kC3PyHDfZ2DCroO6Q== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.5 SunOS 5.9 sun4u sparc Status: RO Content-Length: 2032 > Date: Mon, 04 Apr 2005 18:40:15 -0700 > From: Pawel Wojcik > To: Bill Sommerfeld > CC: frits , psarc@sun.com, sata-dev@sun.com > Subject: Re: PSARC/2004/779 SATA HBA Framework Support > > One popular controller that we care about falls into this category - > Intel ICH6 SATA. Theoretically it could be "switched" from one mode to > another by changing subclass code, the code is most likely fixed on > system bases - the subclass code register has read-only attribute. The > sunclass code "switching" was not fully investigated (no business > justification yet). > However, this controller is not officially supported even in > compatibility mode and the plan is to create for it SATA driver using > SATA HBA framework, when controller exports MASS-STORAGE/SATA class. > > There is similar situation with NVidia SATA controller - we plan to > support it only in "native" SATA mode, and it is not officially > supported in a compatible mode. Saying that it is not "officially supported" is one thing, but if the current ata driver will recognize it as a device it can support customers *will* use it. It sounds like there is no migration path for such customers that are early adopters of SATA hardware when our sata driver starts supporting that hardware in SATA mode. It would be a nasty surprise to them when they upgrade or patch a working system and find it won't boot because of changed device paths. Mike Riley Mail: EGO-02 o Work: (310) 464-5997 Ext.: 67190 | \ \ | Page: (800) 759-8888 + PIN 8738187 |=|====================\O/==|=| Fax: (310) 464-5997 | | o \ | | E-mail: michael.riley@Sun.COM |=|==O===============/\==|=| E-mail Page: 8738187@skytel.com | |\o | \ \ | Work Home Page: http://lasc.west/~mikeri | / ) ( ) | From sacadmin Tue Apr 5 10:20:14 2005 Received: from sunmail3.sfbay.sun.com (sunmail3.SFBay.Sun.COM [129.149.247.180]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j35HKESp011152 for ; Tue, 5 Apr 2005 10:20:14 -0700 (PDT) Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sunmail3.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id j35HIQZ10764; Tue, 5 Apr 2005 10:18:26 -0700 (PDT) Received: from phys-mpk-2 (phys-mpk-2.SFBay.Sun.COM [129.146.11.82]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j35HIQjg002561; Tue, 5 Apr 2005 10:18:26 -0700 (PDT) Received: from conversion-daemon.mpk-mail1.sfbay.sun.com by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IEH00501GVBK7@mpk-mail1.sfbay.sun.com> (original mail from Narayana.Aroori@Sun.COM); Tue, 05 Apr 2005 10:18:26 -0700 (PDT) Received: from Sun.COM (sr1-umpk-02.SFBay.Sun.COM [129.146.11.154]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IEH004JDHEPR1@mpk-mail1.sfbay.sun.com>; Tue, 05 Apr 2005 10:18:26 -0700 (PDT) Date: Tue, 05 Apr 2005 10:18:25 -0700 From: Narayana Aroori Subject: Re: PSARC/2004/779 SATA HBA Framework Support In-reply-to: <200504051558.j35FwR0P023166@hs-uego02-02.West.Sun.COM> To: Mike Riley Cc: psarc@Sun.COM, sata-dev@Sun.COM Reply-to: Narayana.Aroori@Sun.COM Message-id: <4252C861.10207@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20041214 References: <200504051558.j35FwR0P023166@hs-uego02-02.West.Sun.COM> Status: RO Content-Length: 2754 Any of the controllers which work in legacy mode need a manual change in BIOS to turn it into native sata mode. Such a manual change in BIOS config results in the change of either pci class code or subclass code. In future, if we decide to implement a native sata driver for either ICH6 or Nvidia or Si3114, such a native driver needs to probe the class/subclass code and decide to not bind to legacy mode settings. That would make driver binding logic (i.e. either legacy cmdk stack or new sata stack) to depend on BIOS setting. Just upgrading or patching will not bind to new stack.. It would need customer's manual change of settings in BIOS. =Narayana Mike Riley wrote: >>Date: Mon, 04 Apr 2005 18:40:15 -0700 >>From: Pawel Wojcik >>To: Bill Sommerfeld >>CC: frits , psarc@sun.com, sata-dev@sun.com >>Subject: Re: PSARC/2004/779 SATA HBA Framework Support >> >>One popular controller that we care about falls into this category - >>Intel ICH6 SATA. Theoretically it could be "switched" from one mode to >>another by changing subclass code, the code is most likely fixed on >>system bases - the subclass code register has read-only attribute. The >>sunclass code "switching" was not fully investigated (no business >>justification yet). >>However, this controller is not officially supported even in >>compatibility mode and the plan is to create for it SATA driver using >>SATA HBA framework, when controller exports MASS-STORAGE/SATA class. >> >>There is similar situation with NVidia SATA controller - we plan to >>support it only in "native" SATA mode, and it is not officially >>supported in a compatible mode. > > > Saying that it is not "officially supported" is one thing, but if the > current ata driver will recognize it as a device it can support customers > *will* use it. > > It sounds like there is no migration path for such customers that are > early adopters of SATA hardware when our sata driver starts supporting that > hardware in SATA mode. It would be a nasty surprise to them when they > upgrade or patch a working system and find it won't boot because of changed > device paths. > > > Mike Riley Mail: EGO-02 o > Work: (310) 464-5997 Ext.: 67190 | \ \ | > Page: (800) 759-8888 + PIN 8738187 |=|====================\O/==|=| > Fax: (310) 464-5997 | | o \ | | > E-mail: michael.riley@Sun.COM |=|==O===============/\==|=| > E-mail Page: 8738187@skytel.com | |\o | \ \ | > Work Home Page: http://lasc.west/~mikeri | / ) ( ) | > From sacadmin Tue Apr 5 10:24:22 2005 Received: from sunmail3.sfbay.sun.com (sunmail3.SFBay.Sun.COM [129.149.247.180]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j35HOMSp011626 for ; Tue, 5 Apr 2005 10:24:22 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.82.166]) by sunmail3.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id j35HMYZ13627; Tue, 5 Apr 2005 10:22:35 -0700 (PDT) Received: from heckle (vpn-129-150-25-60.SFBay.Sun.COM [129.150.25.60]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with SMTP id j35HMXMr372125; Tue, 5 Apr 2005 10:22:34 -0700 (PDT) Message-Id: <200504051722.j35HMXMr372125@jurassic.eng.sun.com> Date: Tue, 5 Apr 2005 10:22:10 -0700 (PDT) From: "Joseph E. Kowalski III" Reply-To: "Joseph E. Kowalski III" Subject: Re: PSARC/2004/779 SATA HBA Framework Support To: Michael.Riley@sun.com, Narayana.Aroori@sun.com Cc: psarc@sun.com, sata-dev@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: nZaKuUh7bIstgTPrDbeV1g== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6 SunOS 5.10 sun4u sparc Status: RO Content-Length: 360 > From: Narayana Aroori ... > That would make driver binding logic (i.e. > either legacy cmdk stack or new sata stack) > to depend on BIOS setting. > > Just upgrading or patching will not bind to > new stack.. It would need customer's manual > change of settings in BIOS. I like this answer. Where will it be documented? - jek3 From sacadmin Tue Apr 5 10:26:49 2005 Received: from sunmail2.sfbay.sun.com (sunmail2.SFBay.Sun.COM [129.149.246.180]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j35HQnSp011760 for ; Tue, 5 Apr 2005 10:26:49 -0700 (PDT) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sunmail2.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id j35HP1w15068; Tue, 5 Apr 2005 10:25:02 -0700 (PDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j35HP1RL001977; Tue, 5 Apr 2005 13:25:01 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j35HP10K001974; Tue, 5 Apr 2005 13:25:01 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16978.51693.462309.526636@gargle.gargle.HOWL> Date: Tue, 5 Apr 2005 13:25:01 -0400 From: James Carlson To: Narayana.Aroori@Sun.COM Cc: Mike Riley , psarc@Sun.COM, sata-dev@Sun.COM Subject: Re: PSARC/2004/779 SATA HBA Framework Support In-Reply-To: Narayana Aroori's message of 5 April 2005 10:18:25 References: <200504051558.j35FwR0P023166@hs-uego02-02.West.Sun.COM> <4252C861.10207@Sun.COM> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 702 Narayana Aroori writes: > Such a manual change in BIOS > config results in the change of either pci class > code or subclass code. In future, if we decide to > implement a native sata driver for either ICH6 or > Nvidia or Si3114, such a native driver needs to > probe the class/subclass code and decide to not > bind to legacy mode settings. ... and such a thing (and its implications) would be part of a new case, and not this case. Thanks; that answers the question for me. -- James Carlson, KISS Interop Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From sacadmin Tue Apr 5 11:04:21 2005 Received: from sunmail3.sfbay.sun.com (sunmail3.SFBay.Sun.COM [129.149.247.180]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j35I4KSp015238 for ; Tue, 5 Apr 2005 11:04:20 -0700 (PDT) Received: from westmail1mpk.West.Sun.COM (westmail1mpk.West.Sun.COM [129.153.100.33]) by sunmail3.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id j35I2TZ14625; Tue, 5 Apr 2005 11:02:34 -0700 (PDT) Received: from hs-uego02-02.West.Sun.COM (hs-uego02-02.West.Sun.COM [129.153.3.2]) by westmail1mpk.West.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j35I2T38006266; Tue, 5 Apr 2005 11:02:29 -0700 (PDT) Received: from thora (thora [129.153.3.52]) by hs-uego02-02.West.Sun.COM (8.12.10+Sun/8.12.10) with SMTP id j35I2S0P009555; Tue, 5 Apr 2005 11:02:28 -0700 (PDT) Message-Id: <200504051802.j35I2S0P009555@hs-uego02-02.West.Sun.COM> Date: Tue, 5 Apr 2005 11:02:28 -0700 (PDT) From: Mike Riley Reply-To: Mike Riley Subject: Re: PSARC/2004/779 SATA HBA Framework Support To: psarc@sun.com, sata-dev@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: f90pT2S7C6nbbiVGYPzMvg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.5 SunOS 5.9 sun4u sparc Status: RO Content-Length: 1760 > Date: Tue, 05 Apr 2005 10:18:25 -0700 > From: Narayana Aroori > Subject: Re: PSARC/2004/779 SATA HBA Framework Support > To: Mike Riley > Cc: psarc@sun.com, sata-dev@sun.com > > Any of the controllers which work in legacy mode > need a manual change in BIOS to turn it into > native sata mode. Such a manual change in BIOS > config results in the change of either pci class > code or subclass code. In future, if we decide to > implement a native sata driver for either ICH6 or > Nvidia or Si3114, such a native driver needs to > probe the class/subclass code and decide to not > bind to legacy mode settings. > > That would make driver binding logic (i.e. > either legacy cmdk stack or new sata stack) > to depend on BIOS setting. > > Just upgrading or patching will not bind to > new stack.. It would need customer's manual > change of settings in BIOS. > > =Narayana True, but it still leaves that customer with a brick. How will they be told to make it back into a bootable computer? It may simply require that we document going into the DCA and choosing a new default boot device to correctly set the BOOTPATH. But it needs to be documented as to the process. Mike Riley Mail: EGO-02 o Work: (310) 464-5997 Ext.: 67190 | \ \ | Page: (800) 759-8888 + PIN 8738187 |=|====================\O/==|=| Fax: (310) 464-5997 | | o \ | | E-mail: michael.riley@Sun.COM |=|==O===============/\==|=| E-mail Page: 8738187@skytel.com | |\o | \ \ | Work Home Page: http://lasc.west/~mikeri | / ) ( ) | From sacadmin Tue Apr 5 11:11:04 2005 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j35IB4Sp015377 for ; Tue, 5 Apr 2005 11:11:04 -0700 (PDT) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id j35I9Ge13365; Tue, 5 Apr 2005 12:09:16 -0600 (MDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j35I9F45002136; Tue, 5 Apr 2005 14:09:15 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j35I9Fu4002133; Tue, 5 Apr 2005 14:09:15 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16978.54347.679061.478875@gargle.gargle.HOWL> Date: Tue, 5 Apr 2005 14:09:15 -0400 From: James Carlson To: Mike Riley Cc: psarc@Sun.COM, sata-dev@Sun.COM Subject: Re: PSARC/2004/779 SATA HBA Framework Support In-Reply-To: Mike Riley's message of 5 April 2005 11:02:28 References: <200504051802.j35I2S0P009555@hs-uego02-02.West.Sun.COM> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 832 Mike Riley writes: > True, but it still leaves that customer with a brick. How will they be > told to make it back into a bootable computer? > > It may simply require that we document going into the DCA and choosing a new > default boot device to correctly set the BOOTPATH. But it needs to be > documented as to the process. Not if none of the SATA devices that are now supported via "legacy" mode are supported by this new driver. Once a new case appears that provides native SATA support for the controllers that are already supported in "legacy" mode, I agree that special documentation is needed. -- James Carlson, KISS Interop Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From sacadmin Tue Apr 5 13:08:32 2005 Received: from sunmail3.sfbay.sun.com (sunmail3.SFBay.Sun.COM [129.149.247.180]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j35K8WSp024490 for ; Tue, 5 Apr 2005 13:08:32 -0700 (PDT) Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sunmail3.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id j35K6iZ10030; Tue, 5 Apr 2005 13:06:44 -0700 (PDT) Received: from phys-mpk-2 (phys-mpk-2.SFBay.Sun.COM [129.146.11.82]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j35K6ijg001929; Tue, 5 Apr 2005 13:06:44 -0700 (PDT) Received: from conversion-daemon.mpk-mail1.sfbay.sun.com by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IEH00801P6NJ2@mpk-mail1.sfbay.sun.com> (original mail from Narayana.Aroori@Sun.COM); Tue, 05 Apr 2005 13:06:44 -0700 (PDT) Received: from Sun.COM (sr1-umpk-02.SFBay.Sun.COM [129.146.11.154]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IEH0048VP775J@mpk-mail1.sfbay.sun.com>; Tue, 05 Apr 2005 13:06:43 -0700 (PDT) Date: Tue, 05 Apr 2005 13:06:43 -0700 From: Narayana Aroori Subject: Re: PSARC/2004/779 SATA HBA Framework Support In-reply-to: <200504051722.j35HMXMr372125@jurassic.eng.sun.com> To: "Joseph E. Kowalski III" Cc: Michael.Riley@Sun.COM, psarc@Sun.COM, sata-dev@Sun.COM Reply-to: Narayana.Aroori@Sun.COM Message-id: <4252EFD3.6010107@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20041214 References: <200504051722.j35HMXMr372125@jurassic.eng.sun.com> Status: RO Content-Length: 690 Joseph E. Kowalski III wrote: >>From: Narayana Aroori > > ... > >>That would make driver binding logic (i.e. >>either legacy cmdk stack or new sata stack) >>to depend on BIOS setting. >> >>Just upgrading or patching will not bind to >>new stack.. It would need customer's manual >>change of settings in BIOS. > > > I like this answer. > > Where will it be documented? > I am not fully sure what would be the ideal place for documenting it. Possibly, the sata man pages, Solaris release notes and hardware documentation of any Sun sold hardware if they are shipped with sata configurations may be a good place to capture this info. =Narayana > - jek3 > From sacadmin Tue Apr 5 13:15:56 2005 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j35KFuSp024575 for ; Tue, 5 Apr 2005 13:15:56 -0700 (PDT) Received: from westmail2san.west.sun.com (westmail2san.West.Sun.COM [129.153.85.6]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id j35KEBe12464; Tue, 5 Apr 2005 14:14:11 -0600 (MDT) Received: from hs-uego02-02.West.Sun.COM (hs-uego02-02.West.Sun.COM [129.153.2.1]) by westmail2san.west.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j35KE969018429; Tue, 5 Apr 2005 13:14:10 -0700 (PDT) Received: from [129.153.3.91] (palermo [129.153.3.91]) by hs-uego02-02.West.Sun.COM (8.12.10+Sun/8.12.10) with ESMTP id j35KE90O024997; Tue, 5 Apr 2005 13:14:09 -0700 (PDT) Message-ID: <4252F191.90704@sun.com> Date: Tue, 05 Apr 2005 13:14:09 -0700 From: Pawel Wojcik Reply-To: pawel.wojcik@sun.com User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20041101 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Carlson CC: Bill Sommerfeld , frits , psarc@sun.com, sata-dev@sun.com Subject: Re: PSARC/2004/779 SATA HBA Framework Support References: <0IEG007JD5QNT780@bos-mail1.sfbay.sun.com> <1112661661.13395.744.camel@thunk> <4251E07B.60009@sun.com> <1112662787.13395.792.camel@thunk> <4251EC7F.6030000@sun.com> <16978.30631.5495.800994@gargle.gargle.HOWL> In-Reply-To: <16978.30631.5495.800994@gargle.gargle.HOWL> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1444 James Carlson wrote: > Pawel Wojcik writes: > >>>if it's switchable, aren't we going to face requests to exploit the >>>whizzy new SATA features on existing platforms? >>> >>> - Bill >>> >>> >> >>One popular controller that we care about falls into this category - >>Intel ICH6 SATA. Theoretically it could be "switched" from one mode to >>another by changing subclass code, the code is most likely fixed on >>system bases - the subclass code register has read-only attribute. The >>sunclass code "switching" was not fully investigated (no business >>justification yet). > > > What about Si3114? It's supported today, but runs with the old cmdk > driver. Will this switch over to the new framework (and thus see > drive renaming), or are existing platforms using Si3114 stuck with the > cmdk forever? > Si3114, 3112, 3512 work in the compatibility mode only. There is absolutely no reason to provide new driver for them. -- Pawel Wojcik Sun Microsystems pawel.wojcik@Sun.com ********************************************* From sacadmin Tue Apr 5 13:18:40 2005 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j35KIdSp024618 for ; Tue, 5 Apr 2005 13:18:40 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.89.31]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id j35KGke15136; Tue, 5 Apr 2005 14:16:47 -0600 (MDT) Received: from heckle (vpn-129-150-25-60.SFBay.Sun.COM [129.150.25.60]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with SMTP id j35KGig9423088; Tue, 5 Apr 2005 13:16:46 -0700 (PDT) Message-Id: <200504052016.j35KGig9423088@jurassic.eng.sun.com> Date: Tue, 5 Apr 2005 13:16:22 -0700 (PDT) From: "Joseph E. Kowalski III" Reply-To: "Joseph E. Kowalski III" Subject: Re: PSARC/2004/779 SATA HBA Framework Support To: Joseph.Kowalski@Sun.COM, Narayana.Aroori@Sun.COM Cc: Michael.Riley@Sun.COM, psarc@Sun.COM, sata-dev@Sun.COM MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 4yJa0KSwtNk0HRCMXXEQ9g== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6 SunOS 5.10 sun4u sparc Status: RO Content-Length: 991 > From: Narayana Aroori ... > Joseph E. Kowalski III wrote: > >>From: Narayana Aroori > > > > ... > > > >>That would make driver binding logic (i.e. > >>either legacy cmdk stack or new sata stack) > >>to depend on BIOS setting. > >> > >>Just upgrading or patching will not bind to > >>new stack.. It would need customer's manual > >>change of settings in BIOS. > > > > > > I like this answer. > > > > Where will it be documented? > > > > I am not fully sure what would be the ideal place > for documenting it. Possibly, the sata man pages, > Solaris release notes and hardware documentation of > any Sun sold hardware if they are shipped with sata > configurations may be a good place to capture this > info. As per the intervening discussion, this documentation issue should be attached to a future case which provides full SATA support for one of the controllers currently operating in ATA legacy mode. Never mind ... - jek3 From sacadmin Tue Apr 5 13:27:30 2005 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j35KRUSp024679 for ; Tue, 5 Apr 2005 13:27:30 -0700 (PDT) Received: from westmail2san.west.sun.com (westmail2san.West.Sun.COM [129.153.85.6]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id j35KPje21111; Tue, 5 Apr 2005 14:25:45 -0600 (MDT) Received: from hs-uego02-02.West.Sun.COM (hs-uego02-02.West.Sun.COM [129.153.2.1]) by westmail2san.west.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j35KPj69019397; Tue, 5 Apr 2005 13:25:45 -0700 (PDT) Received: from [129.153.3.91] (palermo [129.153.3.91]) by hs-uego02-02.West.Sun.COM (8.12.10+Sun/8.12.10) with ESMTP id j35KPi0O026366; Tue, 5 Apr 2005 13:25:44 -0700 (PDT) Message-ID: <4252F448.3020709@sun.com> Date: Tue, 05 Apr 2005 13:25:44 -0700 From: Pawel Wojcik Reply-To: pawel.wojcik@sun.com User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20041101 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mike Riley CC: psarc@sun.com, sata-dev@sun.com Subject: Re: PSARC/2004/779 SATA HBA Framework Support References: <200504051558.j35FwR0P023166@hs-uego02-02.West.Sun.COM> In-Reply-To: <200504051558.j35FwR0P023166@hs-uego02-02.West.Sun.COM> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 3618 Mike Riley wrote: >>Date: Mon, 04 Apr 2005 18:40:15 -0700 >>From: Pawel Wojcik >>To: Bill Sommerfeld >>CC: frits , psarc@sun.com, sata-dev@sun.com >>Subject: Re: PSARC/2004/779 SATA HBA Framework Support >> >>One popular controller that we care about falls into this category - >>Intel ICH6 SATA. Theoretically it could be "switched" from one mode to >>another by changing subclass code, the code is most likely fixed on >>system bases - the subclass code register has read-only attribute. The >>sunclass code "switching" was not fully investigated (no business >>justification yet). >>However, this controller is not officially supported even in >>compatibility mode and the plan is to create for it SATA driver using >>SATA HBA framework, when controller exports MASS-STORAGE/SATA class. >> >>There is similar situation with NVidia SATA controller - we plan to >>support it only in "native" SATA mode, and it is not officially >>supported in a compatible mode. > > > Saying that it is not "officially supported" is one thing, but if the > current ata driver will recognize it as a device it can support customers > *will* use it. > That does not differ from current situation with unsupported NICs or other hardware. If it is reported to work it does not constitute any obligation for Sun to support it. We have to look at this form the "making money" perspective. > It sounds like there is no migration path for such customers that are > early adopters of SATA hardware when our sata driver starts supporting that > hardware in SATA mode. It would be a nasty surprise to them when they > upgrade or patch a working system and find it won't boot because of changed > device paths. > There are probably very few controllers that do not have different pci class code when they are used in differnt operating mode. New drivers will not support hardware that is currently covered by Solaris SATA support - there will be no upgrade here, because there is not rational reason for it. The new drivers are hardware-specific, not generic like old pci-ide/ata. bacsuse there is not standarized hardware interface. Intel is trying to create "de facto" standard with AHCI, but their ICH6 SATA controller is the only one using it. For those controllers that are switchable from one mode to another, the changed device path and different target driver are real obstacle. There is no reliable way of changing storage device paths and names transparently to the system. > > Mike Riley Mail: EGO-02 o > Work: (310) 464-5997 Ext.: 67190 | \ \ | > Page: (800) 759-8888 + PIN 8738187 |=|====================\O/==|=| > Fax: (310) 464-5997 | | o \ | | > E-mail: michael.riley@Sun.COM |=|==O===============/\==|=| > E-mail Page: 8738187@skytel.com | |\o | \ \ | > Work Home Page: http://lasc.west/~mikeri | / ) ( ) | > -- Pawel Wojcik Sun Microsystems pawel.wojcik@Sun.com ********************************************* From sacadmin Tue Apr 5 13:33:44 2005 Received: from sunmail2.sfbay.sun.com (sunmail2.SFBay.Sun.COM [129.149.246.180]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j35KXiSp024935 for ; Tue, 5 Apr 2005 13:33:44 -0700 (PDT) Received: from westmail1mpk.West.Sun.COM (westmail1mpk.West.Sun.COM [129.153.100.33]) by sunmail2.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id j35KW0w22385; Tue, 5 Apr 2005 13:32:00 -0700 (PDT) Received: from hs-uego02-02.West.Sun.COM (hs-uego02-02.West.Sun.COM [129.153.3.2]) by westmail1mpk.West.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j35KW038019496; Tue, 5 Apr 2005 13:32:00 -0700 (PDT) Received: from thora (thora [129.153.3.52]) by hs-uego02-02.West.Sun.COM (8.12.10+Sun/8.12.10) with SMTP id j35KW00P027073; Tue, 5 Apr 2005 13:32:00 -0700 (PDT) Message-Id: <200504052032.j35KW00P027073@hs-uego02-02.West.Sun.COM> Date: Tue, 5 Apr 2005 13:32:00 -0700 (PDT) From: Mike Riley Reply-To: Mike Riley Subject: Re: PSARC/2004/779 SATA HBA Framework Support To: psarc@sun.com, sata-dev@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: NJwIYbT474lF2RVCuNzPtw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.5 SunOS 5.9 sun4u sparc Status: RO Content-Length: 3907 > Date: Tue, 05 Apr 2005 13:25:44 -0700 > From: Pawel Wojcik > To: Mike Riley > CC: psarc@sun.com, sata-dev@sun.com > Subject: Re: PSARC/2004/779 SATA HBA Framework Support > > > > Mike Riley wrote: > >>Date: Mon, 04 Apr 2005 18:40:15 -0700 > >>From: Pawel Wojcik > >>To: Bill Sommerfeld > >>CC: frits , psarc@sun.com, sata-dev@sun.com > >>Subject: Re: PSARC/2004/779 SATA HBA Framework Support > >> > >>One popular controller that we care about falls into this category - > >>Intel ICH6 SATA. Theoretically it could be "switched" from one mode to > >>another by changing subclass code, the code is most likely fixed on > >>system bases - the subclass code register has read-only attribute. The > >>sunclass code "switching" was not fully investigated (no business > >>justification yet). > >>However, this controller is not officially supported even in > >>compatibility mode and the plan is to create for it SATA driver using > >>SATA HBA framework, when controller exports MASS-STORAGE/SATA class. > >> > >>There is similar situation with NVidia SATA controller - we plan to > >>support it only in "native" SATA mode, and it is not officially > >>supported in a compatible mode. > > > > > > Saying that it is not "officially supported" is one thing, but if the > > current ata driver will recognize it as a device it can support customers > > *will* use it. > > > > That does not differ from current situation with unsupported NICs or > other hardware. If it is reported to work it does not constitute any > obligation for Sun to support it. We have to look at this form the > "making money" perspective. Except the NIC drivers don't attach to something because the PCI class is the same as legacy PATA devices, but the ata driver does. A customer would have to edit /etc/driver_aliases to get a NIC driver to load for a new version of a NIC card. But for some SATA devices they only have to change their BIOS settings to the PATA compatability mode and Solaris will use it. > > It sounds like there is no migration path for such customers that are > > early adopters of SATA hardware when our sata driver starts supporting that > > hardware in SATA mode. It would be a nasty surprise to them when they > > upgrade or patch a working system and find it won't boot because of changed > > device paths. > > > > There are probably very few controllers that do not have different pci > class code when they are used in differnt operating mode. New drivers > will not support hardware that is currently covered by Solaris SATA > support - there will be no upgrade here, because there is not rational > reason for it. The new drivers are hardware-specific, not generic like > old pci-ide/ata. bacsuse there is not standarized hardware interface. > Intel is trying to create "de facto" standard with AHCI, but their ICH6 > SATA controller is the only one using it. > > For those controllers that are switchable from one mode to another, the > changed device path and different target driver are real obstacle. There > is no reliable way of changing storage device paths and names > transparently to the system. Then we have to be sure and document it, preferably in several places to reduce Support calls about it. Mike Riley Mail: EGO-02 o Work: (310) 464-5997 Ext.: 67190 | \ \ | Page: (800) 759-8888 + PIN 8738187 |=|====================\O/==|=| Fax: (310) 464-5997 | | o \ | | E-mail: michael.riley@Sun.COM |=|==O===============/\==|=| E-mail Page: 8738187@skytel.com | |\o | \ \ | Work Home Page: http://lasc.west/~mikeri | / ) ( ) | From sacadmin Tue Apr 5 13:34:02 2005 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j35KY1Sp024951 for ; Tue, 5 Apr 2005 13:34:01 -0700 (PDT) Received: from westmail2san.west.sun.com (westmail2san.West.Sun.COM [129.153.85.6]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id j35KWHe26236; Tue, 5 Apr 2005 14:32:17 -0600 (MDT) Received: from hs-uego02-02.West.Sun.COM (hs-uego02-02.West.Sun.COM [129.153.2.1]) by westmail2san.west.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j35KWG69019948; Tue, 5 Apr 2005 13:32:16 -0700 (PDT) Received: from [129.153.3.91] (palermo [129.153.3.91]) by hs-uego02-02.West.Sun.COM (8.12.10+Sun/8.12.10) with ESMTP id j35KWG0O027084; Tue, 5 Apr 2005 13:32:16 -0700 (PDT) Message-ID: <4252F5D0.6070008@sun.com> Date: Tue, 05 Apr 2005 13:32:16 -0700 From: Pawel Wojcik Reply-To: pawel.wojcik@sun.com User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20041101 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mike Riley CC: psarc@sun.com, sata-dev@sun.com Subject: Re: PSARC/2004/779 SATA HBA Framework Support References: <200504051802.j35I2S0P009555@hs-uego02-02.West.Sun.COM> In-Reply-To: <200504051802.j35I2S0P009555@hs-uego02-02.West.Sun.COM> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 2508 Mike Riley wrote: >>Date: Tue, 05 Apr 2005 10:18:25 -0700 >>From: Narayana Aroori >>Subject: Re: PSARC/2004/779 SATA HBA Framework Support >>To: Mike Riley >>Cc: psarc@sun.com, sata-dev@sun.com >> >>Any of the controllers which work in legacy mode >>need a manual change in BIOS to turn it into >>native sata mode. Such a manual change in BIOS >>config results in the change of either pci class >>code or subclass code. In future, if we decide to >>implement a native sata driver for either ICH6 or >>Nvidia or Si3114, such a native driver needs to >>probe the class/subclass code and decide to not >>bind to legacy mode settings. >> >>That would make driver binding logic (i.e. >>either legacy cmdk stack or new sata stack) >>to depend on BIOS setting. >> >>Just upgrading or patching will not bind to >>new stack.. It would need customer's manual >>change of settings in BIOS. >> >>=Narayana > > > True, but it still leaves that customer with a brick. How will they be > told to make it back into a bootable computer? > All it takes to recover is to switch the controller back to the legacy mode. > It may simply require that we document going into the DCA and choosing a new > default boot device to correctly set the BOOTPATH. But it needs to be > documented as to the process. > This hipothetical issue, because we do not have yet a supported controller that would create such problem. > > Mike Riley Mail: EGO-02 o > Work: (310) 464-5997 Ext.: 67190 | \ \ | > Page: (800) 759-8888 + PIN 8738187 |=|====================\O/==|=| > Fax: (310) 464-5997 | | o \ | | > E-mail: michael.riley@Sun.COM |=|==O===============/\==|=| > E-mail Page: 8738187@skytel.com | |\o | \ \ | > Work Home Page: http://lasc.west/~mikeri | / ) ( ) | > -- Pawel Wojcik Sun Microsystems pawel.wojcik@Sun.com ********************************************* From sacadmin Tue Apr 5 13:35:18 2005 Received: from sunmail2.sfbay.sun.com (sunmail2.SFBay.Sun.COM [129.149.246.180]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j35KZISp025064 for ; Tue, 5 Apr 2005 13:35:18 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.84.31]) by sunmail2.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id j35KXSw23329; Tue, 5 Apr 2005 13:33:28 -0700 (PDT) Received: from 129.146.86.198 (braveheart.SFBay.Sun.COM [129.146.86.198]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j35KXRrb428909 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 5 Apr 2005 13:33:27 -0700 (PDT) Subject: Re: PSARC/2004/779 SATA HBA Framework Support From: Darren J Moffat To: Narayana.Aroori@Sun.COM Cc: Mike Riley , psarc@Sun.COM, sata-dev@Sun.COM In-Reply-To: <4252C861.10207@Sun.COM> References: <200504051558.j35FwR0P023166@hs-uego02-02.West.Sun.COM> <4252C861.10207@Sun.COM> Content-Type: text/plain; charset=iso-8859-15 Organization: Sun Microsystems, Inc. Message-Id: <1112733207.12348.40.camel@braveheart.SFBay.Sun.COM> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Tue, 05 Apr 2005 13:33:27 -0700 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 368 On Tue, 2005-04-05 at 10:18, Narayana Aroori wrote: > code or subclass code. In future, if we decide to > implement a native sata driver for either ICH6 or > Nvidia or Si3114, such a native driver needs to > probe the class/subclass code and decide to not > bind to legacy mode settings. Isn't the Si the chipset that is in our W2100z product ? -- Darren J Moffat From sacadmin Tue Apr 5 13:41:27 2005 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j35KfRSp025088 for ; Tue, 5 Apr 2005 13:41:27 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.87.130]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id j35Kdde00912; Tue, 5 Apr 2005 14:39:39 -0600 (MDT) Received: from 129.146.86.198 (braveheart.SFBay.Sun.COM [129.146.86.198]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j35KdcXw430649 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 5 Apr 2005 13:39:38 -0700 (PDT) Subject: Re: PSARC/2004/779 SATA HBA Framework Support From: Darren J Moffat To: Mike Riley Cc: psarc@Sun.COM, sata-dev@Sun.COM In-Reply-To: <200504051802.j35I2S0P009555@hs-uego02-02.West.Sun.COM> References: <200504051802.j35I2S0P009555@hs-uego02-02.West.Sun.COM> Content-Type: text/plain Organization: Sun Microsystems, Inc. Message-Id: <1112733578.12348.49.camel@braveheart.SFBay.Sun.COM> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Tue, 05 Apr 2005 13:39:38 -0700 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 904 On Tue, 2005-04-05 at 11:02, Mike Riley wrote: > > That would make driver binding logic (i.e. > > either legacy cmdk stack or new sata stack) > > to depend on BIOS setting. > > > > Just upgrading or patching will not bind to > > new stack.. It would need customer's manual > > change of settings in BIOS. > > > > =Narayana > > True, but it still leaves that customer with a brick. How will they be > told to make it back into a bootable computer? Why is it our fault if the customer went in and changed BIOS settings on purpose ? They can just change the back again and it should work as it did before. > It may simply require that we document going into the DCA and choosing a new > default boot device to correctly set the BOOTPATH. But it needs to be > documented as to the process. There may not be a DCA by the time this ships, we may have the new boot architecture. -- Darren J Moffat From sacadmin Tue Apr 5 13:44:46 2005 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j35KikSp025158 for ; Tue, 5 Apr 2005 13:44:46 -0700 (PDT) Received: from westmail2san.west.sun.com (westmail2san.West.Sun.COM [129.153.85.6]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id j35Kh2e03172; Tue, 5 Apr 2005 14:43:02 -0600 (MDT) Received: from hs-uego02-02.West.Sun.COM (hs-uego02-02.West.Sun.COM [129.153.2.1]) by westmail2san.west.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j35Kh169020862; Tue, 5 Apr 2005 13:43:01 -0700 (PDT) Received: from [129.153.3.91] (palermo [129.153.3.91]) by hs-uego02-02.West.Sun.COM (8.12.10+Sun/8.12.10) with ESMTP id j35Kh10O028360; Tue, 5 Apr 2005 13:43:01 -0700 (PDT) Message-ID: <4252F854.7000206@sun.com> Date: Tue, 05 Apr 2005 13:43:00 -0700 From: Pawel Wojcik Reply-To: pawel.wojcik@sun.com User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20041101 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Darren J Moffat CC: Narayana.Aroori@sun.com, Mike Riley , psarc@sun.com, sata-dev@sun.com Subject: Re: PSARC/2004/779 SATA HBA Framework Support References: <200504051558.j35FwR0P023166@hs-uego02-02.West.Sun.COM> <4252C861.10207@Sun.COM> <1112733207.12348.40.camel@braveheart.SFBay.Sun.COM> In-Reply-To: <1112733207.12348.40.camel@braveheart.SFBay.Sun.COM> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1028 Darren J Moffat wrote: > On Tue, 2005-04-05 at 10:18, Narayana Aroori wrote: > >>code or subclass code. In future, if we decide to >>implement a native sata driver for either ICH6 or >>Nvidia or Si3114, such a native driver needs to >>probe the class/subclass code and decide to not >>bind to legacy mode settings. > > > Isn't the Si the chipset that is in our W2100z product ? > Yes, it uses Si3512 operating exclusively in compatibility mode. There is no advantage to provide separate hardware-specific driver for it. -- Pawel Wojcik Sun Microsystems pawel.wojcik@Sun.com ********************************************* From sacadmin Tue Apr 5 13:47:00 2005 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j35KkxSp025225 for ; Tue, 5 Apr 2005 13:47:00 -0700 (PDT) Received: from westmail1mpk.West.Sun.COM (westmail1mpk.West.Sun.COM [129.153.100.33]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id j35KjFe04810; Tue, 5 Apr 2005 14:45:15 -0600 (MDT) Received: from hs-uego02-02.West.Sun.COM (hs-uego02-02.West.Sun.COM [129.153.3.2]) by westmail1mpk.West.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j35KjE38020661; Tue, 5 Apr 2005 13:45:14 -0700 (PDT) Received: from [129.153.3.91] (palermo [129.153.3.91]) by hs-uego02-02.West.Sun.COM (8.12.10+Sun/8.12.10) with ESMTP id j35KjE0O028656; Tue, 5 Apr 2005 13:45:14 -0700 (PDT) Message-ID: <4252F8DA.2050704@sun.com> Date: Tue, 05 Apr 2005 13:45:14 -0700 From: Pawel Wojcik Reply-To: pawel.wojcik@sun.com User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20041101 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Darren J Moffat CC: Mike Riley , psarc@sun.com, sata-dev@sun.com Subject: Re: PSARC/2004/779 SATA HBA Framework Support References: <200504051802.j35I2S0P009555@hs-uego02-02.West.Sun.COM> <1112733578.12348.49.camel@braveheart.SFBay.Sun.COM> In-Reply-To: <1112733578.12348.49.camel@braveheart.SFBay.Sun.COM> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1617 Darren J Moffat wrote: > On Tue, 2005-04-05 at 11:02, Mike Riley wrote: > >>>That would make driver binding logic (i.e. >>>either legacy cmdk stack or new sata stack) >>>to depend on BIOS setting. >>> >>>Just upgrading or patching will not bind to >>>new stack.. It would need customer's manual >>>change of settings in BIOS. >>> >>>=Narayana >> >>True, but it still leaves that customer with a brick. How will they be >>told to make it back into a bootable computer? > > > Why is it our fault if the customer went in and changed BIOS settings > on purpose ? They can just change the back again and it should > work as it did before. > > >>It may simply require that we document going into the DCA and choosing a new >>default boot device to correctly set the BOOTPATH. But it needs to be >>documented as to the process. > > > There may not be a DCA by the time this ships, we may have the new > boot architecture. > New SATA Framework and driver was already checked against new-boot architecture. It works. There is no plans to provide real-mode SATA support other than what is in Solaris already. -- Pawel Wojcik Sun Microsystems pawel.wojcik@Sun.com ********************************************* From sacadmin Tue Apr 5 13:47:54 2005 Received: from sunmail3.sfbay.sun.com (sunmail3.SFBay.Sun.COM [129.149.247.180]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j35KlrSp025392 for ; Tue, 5 Apr 2005 13:47:53 -0700 (PDT) Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sunmail3.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id j35Kk7Z04867; Tue, 5 Apr 2005 13:46:07 -0700 (PDT) Received: from phys-mpk-2 (phys-mpk-2.SFBay.Sun.COM [129.146.11.82]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j35Kk6jg020422; Tue, 5 Apr 2005 13:46:07 -0700 (PDT) Received: from conversion-daemon.mpk-mail1.sfbay.sun.com by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IEH00701QXETX@mpk-mail1.sfbay.sun.com> (original mail from Narayana.Aroori@Sun.COM); Tue, 05 Apr 2005 13:46:06 -0700 (PDT) Received: from Sun.COM (sr1-umpk-02.SFBay.Sun.COM [129.146.11.154]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IEH004PMR0L5J@mpk-mail1.sfbay.sun.com>; Tue, 05 Apr 2005 13:45:57 -0700 (PDT) Date: Tue, 05 Apr 2005 13:45:57 -0700 From: Narayana Aroori Subject: Re: PSARC/2004/779 SATA HBA Framework Support In-reply-to: <1112733207.12348.40.camel@braveheart.SFBay.Sun.COM> To: Darren J Moffat Cc: Mike Riley , psarc@Sun.COM, sata-dev@Sun.COM Reply-to: Narayana.Aroori@Sun.COM Message-id: <4252F905.9050208@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20041214 References: <200504051558.j35FwR0P023166@hs-uego02-02.West.Sun.COM> <4252C861.10207@Sun.COM> <1112733207.12348.40.camel@braveheart.SFBay.Sun.COM> Status: RO Content-Length: 569 Darren J Moffat wrote: > On Tue, 2005-04-05 at 10:18, Narayana Aroori wrote: > >>code or subclass code. In future, if we decide to >>implement a native sata driver for either ICH6 or >>Nvidia or Si3114, such a native driver needs to >>probe the class/subclass code and decide to not >>bind to legacy mode settings. > > > Isn't the Si the chipset that is in our W2100z product ? > Yes, Si was in W2100z; it works in PATA legacy mode with old cmdk-ata stack. I was referring to Si only as an example. We don't have any plans for native stack for it.. =Narayana From sacadmin Tue Apr 5 13:54:58 2005 Received: from sunmail3.sfbay.sun.com (sunmail3.SFBay.Sun.COM [129.149.247.180]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j35KsvSp027197 for ; Tue, 5 Apr 2005 13:54:57 -0700 (PDT) Received: from eastmail2bur.East.Sun.COM (eastmail2bur.East.Sun.COM [129.148.13.40]) by sunmail3.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id j35Kr6Z08836; Tue, 5 Apr 2005 13:53:06 -0700 (PDT) Received: from thunk (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j35Kr1Op029146; Tue, 5 Apr 2005 16:53:01 -0400 (EDT) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk (8.13.3+Sun/8.13.3) with ESMTP id j35Kr0rM021918; Tue, 5 Apr 2005 16:53:01 -0400 (EDT) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.3+Sun/8.13.3/Submit) id j35Kr0vd021917; Tue, 5 Apr 2005 16:53:00 -0400 (EDT) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: PSARC/2004/779 SATA HBA Framework Support From: Bill Sommerfeld To: Pawel.Wojcik@sun.com Cc: Darren J Moffat , Narayana.Aroori@sun.com, Mike Riley , psarc@sun.com, sata-dev@sun.com In-Reply-To: <4252F854.7000206@sun.com> References: <200504051558.j35FwR0P023166@hs-uego02-02.West.Sun.COM> <4252C861.10207@Sun.COM> <1112733207.12348.40.camel@braveheart.SFBay.Sun.COM> <4252F854.7000206@sun.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1112734379.19907.144.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.309 Date: Tue, 05 Apr 2005 16:53:00 -0400 Status: RO Content-Length: 479 [I think we're discussing requirements for the next case...] On Tue, 2005-04-05 at 16:43, Pawel Wojcik wrote: > Yes, it uses Si3512 operating exclusively in compatibility mode. > There is no advantage to provide separate hardware-specific driver for it. I'm having difficulty reconciling that statement with the case materials. Of the feature set listed, wouldn't the various forms of enhanced command queueing feature be relevant to all systems using SATA? - Bill From sacadmin Tue Apr 5 14:08:54 2005 Received: from sunmail2.sfbay.sun.com (sunmail2.SFBay.Sun.COM [129.149.246.180]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j35L8sSp028242 for ; Tue, 5 Apr 2005 14:08:54 -0700 (PDT) Received: from westmail1mpk.West.Sun.COM (westmail1mpk.West.Sun.COM [129.153.100.33]) by sunmail2.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id j35L79w16096; Tue, 5 Apr 2005 14:07:09 -0700 (PDT) Received: from hs-uego02-02.West.Sun.COM (hs-uego02-02.West.Sun.COM [129.153.3.2]) by westmail1mpk.West.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j35L7738022782; Tue, 5 Apr 2005 14:07:08 -0700 (PDT) Received: from [129.153.3.91] (palermo [129.153.3.91]) by hs-uego02-02.West.Sun.COM (8.12.10+Sun/8.12.10) with ESMTP id j35L770O001741; Tue, 5 Apr 2005 14:07:07 -0700 (PDT) Message-ID: <4252FDFB.3080203@sun.com> Date: Tue, 05 Apr 2005 14:07:07 -0700 From: Pawel Wojcik Reply-To: pawel.wojcik@sun.com User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20041101 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bill Sommerfeld CC: Darren J Moffat , Narayana.Aroori@sun.com, Mike Riley , psarc@sun.com, sata-dev@sun.com Subject: Re: PSARC/2004/779 SATA HBA Framework Support References: <200504051558.j35FwR0P023166@hs-uego02-02.West.Sun.COM> <4252C861.10207@Sun.COM> <1112733207.12348.40.camel@braveheart.SFBay.Sun.COM> <4252F854.7000206@sun.com> <1112734379.19907.144.camel@thunk> In-Reply-To: <1112734379.19907.144.camel@thunk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1309 Bill Sommerfeld wrote: > [I think we're discussing requirements for the next case...] > > On Tue, 2005-04-05 at 16:43, Pawel Wojcik wrote: > >>Yes, it uses Si3512 operating exclusively in compatibility mode. >>There is no advantage to provide separate hardware-specific driver for it. > > > I'm having difficulty reconciling that statement with the case > materials. > > Of the feature set listed, wouldn't the various forms of enhanced > command queueing feature be relevant to all systems using SATA? > > - Bill > Not for all systems using SATA. This particular controller does not support command queuing nor provide any other functionality of SATA, except the serial link. So it make sense to create new drivers only for these controllers that provide true SATA I/II functionality. -- Pawel Wojcik Sun Microsystems pawel.wojcik@Sun.com *********************************************