On Fri, Jun 03, 2016 at 10:38:50AM +0200, Bruno Friedmann wrote:
On 2016-06-03 10:26, Andrei Borzenkov wrote:
On Fri, Jun 3, 2016 at 11:06 AM, Johannes Thumshirn <jthumshirn@suse.de> wrote:
On Fri, Jun 03, 2016 at 10:48:05AM +0300, Andrei Borzenkov wrote:
On Fri, Jun 3, 2016 at 10:31 AM, Johannes Thumshirn <jthumshirn@suse.de> wrote:
On Thu, Jun 02, 2016 at 04:21:22PM -0400, Greg Freemyer wrote:
On Thu, Jun 2, 2016 at 3:56 PM, Andrei Borzenkov <arvidjaar@gmail.com> wrote: > 02.06.2016 16:27, Greg Freemyer пишет: === M.2 M Key device using AHCI protocol ===
Samsung XP941 SSD PCIe M Key 2280 MZHPU128HCGM-00000
AHCI is _not_ NVMe!!!
While that is true ...
AHCI is SATA.
... this is not always. M.2 storage can be connected either using SATA to HBA on motherboard or it can be connected using PCIe to PCIe switch on motherboard. In the latter case it can either contain AHCI compatible controller *on M.2 card itself* or it can contain NVMe compatibel controller. In both cases host interface is still PCIe which provides advantage over plain SATA.
The above card seems to be AHCI over PCIe, so no SATA :)
OK, this card above connects the Serial ATA AHCI via PCIe to your CPU instead of using the SoC's or Chipset's AHCI. [1] is a good read for that.
Do you say that this card internally has SATA link between actual storage and host controller? Do you *know* it? How can it achieve 1170 MB/s (from data sheet) during sequential read in this case?
Do not be confused by reusing AHCI as host controller interface; it does not imply that internal data transfer must be SATA.
Protocol and kernel driver wise (which I think is what is of interest here) AHCI will be handled by ahci.ko, libahci.ko, scsi_mod.ko and sd.ko. This will give you the beloved /dev/sd* devices. [2] has a nice diagram for the principal operation.
Yes. And that is exact reason for existence of AHCI emulation in NVMe devices - because they do not require additional drivers and are fully transparent. It does not really mean that NVMe devices are using SATA *internally*.
So will I have to report a bug ?
nvme version nvme version 0.5 qt-kt:/ # nvme list /dev/nvme0n1 nvme0 failed to map
qt-kt:/ # nvme list /dev/nvme nvme0 failed to map
qt-kt:/ # lsmod | grep nvme nvme 73728 4 qt-kt:/ # nvme list-ctrl /dev/nvme0n1 NVMe Status:INVALID_FIELD(2002) cntid:0 qt-kt:/ # nvme list-ctrl /dev/nvme0 NVMe Status:INVALID_FIELD(2002) cntid:0 qt-kt:/ # nvme list-ctrl /dev/nvme0 NVMe Status:INVALID_FIELD(2002) cntid:0 qt-kt:/ # nvme smart-log /dev/nvme0n1 Smart Log for NVME device:nvme0n1 namespace-id:ffffffff critical_warning : 0 temperature : 33 C available_spare : 100% available_spare_threshold : 50% percentage_used : 0% data_units_read : 7915800 data_units_written : 39064599 host_read_commands : 88286900 host_write_commands : 1142492157 controller_busy_time : 1348 power_cycles : 555 power_on_hours : 2722 unsafe_shutdowns : 200 media_errors : 0 num_err_log_entries : 134 Warning Temperature Time : 0 Critical Composite Temperature Time : 0 Temperature Sensor 1 : 0 C Temperature Sensor 2 : 0 C Temperature Sensor 3 : 0 C Temperature Sensor 4 : 0 C Temperature Sensor 5 : 0 C Temperature Sensor 6 : 0 C Temperature Sensor 7 : 0 C Temperature Sensor 8 : 0 C qt-kt:/ # nvme error-log /dev/nvme0n1 Error Log Entries for device:nvme0n1 entries:64 ................. Entry[ 0] ................. error_count : 134 sqid : 0 cmdid : 0 status_field : 0x4004 parm_err_loc : 0 lba : 0 nsid : 0 vs : 0 ................. Entry[ 1] ................. error_count : 133 sqid : 0 cmdid : 0 status_field : 0x4004 parm_err_loc : 0 lba : 0 nsid : 0 vs : 0 .................
I've submitted nvme-cli v0.7 yesterday or the day before yesterday to factory. You might give that one a try first before submitting the bug. If the bug is still there with v0.7 please also note down you kernel version. The driver side is a moving target as well.
--
Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch
openSUSE Member, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- Johannes Thumshirn Storage jthumshirn@suse.de +49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org