Custom Query (1359 matches)

In the currently nightly, smartctl, when used on /dev/nvmeX rathern than /dev/nvmeXn1, selects the wrong device when two identical nvme modules are installed. Example:

# ls -l nvme-Samsung_SSD_970_EVO_2TB_S464NB0M200088N | cut -c40-
nvme-Samsung_SSD_970_EVO_2TB_S464NB0M200088N -> ../../nvme0n1
# ls -l nvme-Samsung_SSD_970_EVO_2TB_S464NB0M200161Y | cut -c40-
nvme-Samsung_SSD_970_EVO_2TB_S464NB0M200161Y -> ../../nvme1n1

# ./smartctl -a /dev/nvme0n1 | sed -n '1p;5,7p'
smartctl 7.1 2019-07-01 r4934 [x86_64-linux-4.18.0-24-generic] (local build)
Model Number:                       Samsung SSD 970 EVO 2TB
Serial Number:                      S464NB0M200088N
Firmware Version:                   2B2QEXE7
# ./smartctl -a /dev/nvme1n1 | sed -n '1p;5,7p'
smartctl 7.1 2019-07-01 r4934 [x86_64-linux-4.18.0-24-generic] (local build)
Model Number:                       Samsung SSD 970 EVO 2TB
Serial Number:                      S464NB0M200161Y
Firmware Version:                   2B2QEXE7

# ./smartctl -a /dev/nvme0 | sed -n '1p;5,7p'
smartctl 7.1 2019-07-01 r4934 [x86_64-linux-4.18.0-24-generic] (local build)
Model Number:                       Samsung SSD 970 EVO 2TB
Serial Number:                      S464NB0M200161Y
Firmware Version:                   2B2QEXE7
# ./smartctl -a /dev/nvme1 | sed -n '1p;5,7p'
smartctl 7.1 2019-07-01 r4934 [x86_64-linux-4.18.0-24-generic] (local build)
Model Number:                       Samsung SSD 970 EVO 2TB
Serial Number:                      S464NB0M200088N
Firmware Version:                   2B2QEXE7

On OpenBSD-current @powerpc smartctl 6.0 segfaults, here there are some info:

$ sudo smartctl -i /dev/wd0c smartctl 6.0 2012-10-10 r3643 [powerpc-unknown-openbsd5.2] (local build) Copyright (C) 2002-12, Bruce Allen, Christian Franke, www.smartmontools.org

Segmentation fault (core dumped)

Program received signal SIGSEGV, Segmentation fault. strcmp (s1=0xfffd5403 "ec2hour", s2=0x20436f6d <Address 0x20436f6d out of bounds>) at /usr/src/lib/libc/string/strcmp.c:47 47 while (*s1 == *s2++) Current language: auto; currently c (gdb) bt #0 strcmp (s1=0xfffd5403 "ec2hour", s2=0x20436f6d <Address 0x20436f6d out of bounds>) at /usr/src/lib/libc/string/strcmp.c:47 #1 0x0180bd54 in parse_attribute_def (opt=Variable "opt" is not available. ) at /usr/obj/ports/smartmontools-6.0/smartmontools-6.0/atacmds.cpp:213 #2 0x0181bf7c in parse_db_presets (presets=0x18588c4 "-v 9,seconds", defs=0xfffd5620, firmwarebugs=0xfffd7858, type=0x0)

at

/usr/obj/ports/smartmontools-6.0/smartmontools-6.0/knowndrives.cpp:221 #3 0x0181bf7c in parse_db_presets (presets=0xfffd7858 "", defs=0x0, firmwarebugs=0x0, type=0xfffd8269)

at

/usr/obj/ports/smartmontools-6.0/smartmontools-6.0/knowndrives.cpp:221 #4 0x0181bf7c in parse_db_presets (presets=0xffffffff <Address 0xffffffff out of bounds>, defs=0x30303800, firmwarebugs=0xf8c69177, type=0x1c00)

at

/usr/obj/ports/smartmontools-6.0/smartmontools-6.0/knowndrives.cpp:221 #5 0x0181bf7c in parse_db_presets (presets=0x0, defs=0x0, firmwarebugs=0x17, type=0xfffda354) at /usr/obj/ports/smartmontools-6.0/smartmontools-6.0/knowndrives.cpp:221 #6 0x0181bf7c in parse_db_presets (presets=0x1890e1c "\001\210\r
", defs=0x5, firmwarebugs=0x24000022, type=0x18a0f30)

at

/usr/obj/ports/smartmontools-6.0/smartmontools-6.0/knowndrives.cpp:221 #7 0x0181bf7c in parse_db_presets (presets=0x20 <Address 0x20 out of bounds>, defs=0x1890e1c, firmwarebugs=0xfffda404, type=0xfffda3b0)

at

/usr/obj/ports/smartmontools-6.0/smartmontools-6.0/knowndrives.cpp:221 #8 0x0181bf7c in parse_db_presets (presets=0x0, defs=0x20, firmwarebugs=0x1801eb0, type=0x1890e18)

at

/usr/obj/ports/smartmontools-6.0/smartmontools-6.0/knowndrives.cpp:221 Previous frame inner to this frame (corrupt stack?)

I'm running smartctl from SVN head (revision 2985) on an AMD64 system with Linux kernel 2.6.30-2 (Debian unstable)

Calling smartctl -d 3ware,0 -a /dev/sda results in a Segmentation fault.

Backtrace: #0 0x000000000042e2de in os_linux::linux_escalade_device::ata_pass_through (this=0x674010, in=..., out=...) at os_linux.cpp:1610 #1 0x000000000040cb99 in smartcommandhandler (device=0x674010, command=IDENTIFY, select=0, data=0x662d40 "\036") at atacmds.cpp:569 #2 0x000000000040e82d in ataReadHDIdentity (device=0x674010, buf=0x662d40) at atacmds.cpp:774 #3 0x0000000000413891 in ataPrintMain (device=0x674010, options=...) at ataprint.cpp:1758 #4 0x000000000040600d in main_worker (argc=5, argv=0x7fffffffe4e8) at smartctl.cpp:949 #5 0x000000000040614c in main (argc=5, argv=0x7fffffffe4e8) at smartctl.cpp:967

Debugging reveals:

passthru is initialized in os_linux.cpp:1471 in the (m_escalade_type==AMCC_3WARE_678K) section. It is then reset to NULL at os_linux.cpp:1576 The subsequent access at os_linux.cpp:1610 dereferences the NULL-Pointer, which segfaults.