GEOM_ELI: Crypto READ request failed (error=22)

[mr44er]

Die Festplatte muss dann die kinetische Restenergie der Spindel und Strom aus einem Stützkondensator nutzen um den Cache auszuschreiben und die Schreibköpfe in Parkposition zu bringen.

Genau...das ist ja einer der smart-werte Power-Off_Retract_Count, wenn die Köpfe nicht sauber geparkt werden und 'zurückknallen'.

Bild 2 ist der Link zwischen der in der CPU integrierten Northbridge (Neudeutsch: Uncore) und der Southbridge. Wenn es da ein Problem gäbe, würde es fast alle Geräte im System betreffen...

So auch mein verzweifelter Gedanke.

Könnte es sein, dass die Platten nach ca. 120 Minuten von "Standby" in "Sleep" wechseln?

Es könnte, aber ich wüsste nicht an welcher Stelle. 'So' eingestellt habe ich ja nichts, camcontrol sleep funktioniert mit SAS ja nicht und sie werden durchs spindown mit 'camcontrol stop' gestoppt.
Das specsheet habe ich gelesen, verstehe es aber so, dass nur die SATA-Ausgabe des Modells das kann.

 

[mr44er]

Update:
Ich dacht, ich wär schlau und hab mal da5 und da6 ohne geli in den pool gestopft. Ich wollte damit provozieren, dass ein anderer Layer mal ins dmesg reinmotzt, damit ich mal was anderes googlen kann. Zu geli error=22 findet man nur diesen Thread oder 2-3 andere, wo die Platten wirklich am krepieren sind.

zpool status atank
  pool: atank
state: ONLINE
  scan: scrub canceled on Fri Aug 17 13:11:26 2018
config:

    NAME                    STATE     READ WRITE CKSUM
    atank                   ONLINE       0     0     0
      raidz3-0              ONLINE       0     0     0
        label/K5GWGJVA-hd1  ONLINE       0     0     0
        label/K5GWGN5A-hd2  ONLINE       0     0     0
        label/K5GW31WA-hd3  ONLINE       0     0     0
        label/OG-da6-N9AY   ONLINE       0     0     0
        label/OG-da5-AZTA   ONLINE       0     0     0
        label/N4G1XV1K-hd6  ONLINE       0     0     0
        label/K5GW6SGA-hd7  ONLINE       0     0     0
        label/K5GWGL2A-hd8  ONLINE       0     0     0
    cache
      label/16GBIntenso     ONLINE       0     0     0

errors: No known data errors

Kurios ist jetzt, dass ich heute früh einen scrub nach 2h5min bei schlafenden Platten gestartet habe, ich somit auf auf der Lauer lag und keine Fehler kamen. Jetzt nochmal gut über 3 Stunden gewartet, wieder keine Fehler. Arg, arg seltsam!

Die einzige Änderung war, dass ich

device          cryptodev
device          aesni
options         GEOM_ELI

in den kernel gebaut habe, als Versuch wegen der doppelte PW-Abfrage in meinem anderen Thread.

FreeBSD 11.2-RELEASE-p2 #2 r337880: Thu Aug 16 00:45:02 CEST 2018
    mr44er@aserver.a.local:/usr/obj/usr/src/sys/AKERNEL amd64

Zu dem Zeitpunkt hatte ich auch die sourcen aktualisiert. Entweder wurde was an geli gepatcht oder es läuft im kernel besser als das geladene Modul. Da dürfte aber kein Unterschied sein?

Fiel mir jetzt im Nachhinein noch auf -> Wenn man smartctl -x aufruft, kommt man noch an Werte wie 'Invalid DWORD count = 0' und 'Loss of DWORD synchronization = 0'
Bei allen Platten sind diese im Moment auf 0. Ich kann mich erinnern, dass wenn die Fehler kamen, auf den Platten bei 'Loss of DWORD synchronization = 8' oder z.B. 6 angezeigt wurde. Würde ja schon zusammenpassen....Unit ist gestoppt, synchro geht flöten. Was die Platten intern mit ihrem Lesecache machen, wenn die Platte gestoppt wurde, weiß ich auch nicht. Ggf. startet da irgendein timer.
Der Schreib- und Lesecache ist bei denen standardmäßig aktiviert. Da könnte ich auch noch testen, ob das was bringt, wenn ich den deaktiviere...sofern ich denn mal wieder Fehlermeldungen bekomme. Love you, Murphy

Weiß nicht, was ich davon halten soll. Wo/wie kann ich kernel changes einsehen?

 

[Yamagi]

Entweder wurde was an geli gepatcht oder es läuft im kernel besser als das geladene Modul. Da dürfte aber kein Unterschied sein?

Also 11.2-RELEASE-p1 und 11.2-RELEASE-p2 haben nichts am Storage geändert: https://svnweb.freebsd.org/base/releng/11.2/sys/?view=log Das waren zweimal TCP Assembly (also Netzwerk), 1x WLAN und Intel aktueller Fuckup. Ob etwas im Kernel oder als Modul gelanden wird ist egal. Technisch gesehen sind es immer Module. Der einzige Unterschied kann sein, dass das Modul aus irgendwelchen Gründen mit anderen Optionen gebaut wird. Das wäre dann ein Bug.

 

[mr44er]

Yeah, danke! Sehr nützlich der Link und stimmt...nur drei Änderungen seit meiner Installation mit r337382.

Der einzige Unterschied kann sein, dass das Modul aus irgendwelchen Gründen mit anderen Optionen gebaut wird. Das wäre dann ein Bug.

Ich lerne was vs. *seufz*
Kann ich das rausfinden oder soll ich lieber gleich an die mailing list schreiben?

So exotisch finde ich meine Vorhaben gar nicht, da hätte doch schon wer anders drüberrumpeln sollen?

 

[Yamagi]

Erstmal würde ich es noch einige Tage beobachten um sicher zu sein, dass das Problem wirklich verschwunden ist. Dann kann man sich mal an die Fehleranalyse machen, eine Mail an die Mailingsliste wäre sicher der erste Schritt.

So exotisch finde ich meine Vorhaben gar nicht, da hätte doch schon wer anders drüberrumpeln sollen?

Ich bin über die Jahre sehr vorsichtig mit solchen Annahmen geworden. Ich habe einfach zu viele, für mich sehr offensichtliche Fehler gefunden. Nicht nur im FreeBSD, sondern in diverser anderer Software. Es ist einfach so, dass viele Fehler an Kombinationen hängen, die gar nicht sooo oft vorkommen. LSI-Controller mit mechanischen Platten, darüber GELI und darauf ein ZFS, dann noch Spindown... Wie viele solche Setups mag es weltweit geben? Und selbst wenn jemand die gleichen Probleme hat, macht sich kaum einer davon die Mühe sie wirklich zu ergründen. Stattdessen wird es als Inkompatiblität abgetan, man lebt damit, sitzt es aus, etc.

 

[mr44er]

Erstmal würde ich es noch einige Tage beobachten um sicher zu sein, dass das Problem wirklich verschwunden ist.

Maschine1 hatte die Platten schlafend über das ganze WE. Heute morgen 2x scrub gestartet, alles ohne Fehler aus sleepmode heraus.
Dann heute Mittag an Maschine2 gewesen,

device          cryptodev
device          aesni
options         GEOM_ELI

Kernel direkt so gebaut, aesni und geli in loader.conf auskommentiert und voilà, klappt auch da tadellos am SAS2008 und höchst unchristlichem Mischbetrieb von div. SAS und SATA-Platten. Uptime und Plattennickerchen weit über 7 Stunden jeweils.
Also....Bug? Kann ich dazu noch mehr rausfinden/eruieren, was da anders abläuft?

Ich bin über die Jahre sehr vorsichtig mit solchen Annahmen geworden. Und selbst wenn jemand die gleichen Probleme hat, macht sich kaum einer davon die Mühe sie wirklich zu ergründen. Stattdessen wird es als Inkompatiblität abgetan, man lebt damit, sitzt es aus, etc.

Stimmt auch wieder, wenn ich drüber nachdenke. Ich wollte es ja selber einfach aufgeben und spindown aufgeben oder eben nochmal einen Versuch mit anderen Controllern starten.

Und man darf gar nicht drüber nachdenken, dass diese Fehler die ganze Zeit bei dem überhitzten Controllerproblem mitgefahren sind.

 

[mr44er]

Kommando zurück, error 22 kam heute wieder von alleine auf Maschine1, ohne gestarteten scrub, einfach nur durch Zugriff.

 

[Yamagi]

*hrm* Aber es tritt mit Geli im Kernel statt Modul schon deutlich seltener auf?

 

[mr44er]

Jep, es war damit ein längerer Zeitraum mit spindown möglich ohne Fehler.
Das geschieht auch wirklich nur beim wakeup, vorher ist alles gediegen. So ähnlich wie hier -> https://forums.gentoo.org/viewtopic-p-7393910.html

Aber es gab dann doch noch einmal eine andere Fehlermeldung.
g_eli_read_done() failed (error=6)

Ich denke stark, dass geli einfach nur zwischen den Fronten ist und ich das Problem mit dem wakeup auch ohne geli hätte.
Hier werden specs gelistet, die bei avago in den pdfs nicht erwähnt werden:
https://www.servethehome.com/lsi-sas-2308-raid-controller-hba-information-listing/

Speziell:

Advanced Power Management support
Slumber and Partial power mode support for SAS and SATA devices
Programmable SAS link power down
Variable PCIe bandwidth negotiation

Da kann ich aber nicht wirklich was greifen, wo ich anfangen sollte. Z.B. weiß ich nicht, ob das einen Unterschied von IR zu IT macht.

In Foren findet man Vermutungen, dass der sync verloren gehen soll bzw. die Reihenfolge der commands falsch sein soll. Also erstmal Fehler bei der Platte melden, weil die nicht reagiert, erst dann 'tur', Platte geht hoch und dann gehts wieder so irgendwie Halbmast. Andere berichten das so und leben mit den Meldungen im log. Bei mir gibts irgendwann (zwischen 10 mins und 30 mins schon gesehen) ne garantierte kernelpanic mit reboot sobald der Fehler nur 1x auftaucht. Ohne spindown ist alles flockig.

Ich hab gestern dem SAS2308 doch mal das BIOS gegönnt. Darin hab ich die timeouts und delays alle auf 120 gestellt, ohne mir jetzt sicher zu sein ob diese Einstellung durch irgendwen respektiert wird (in einem pdf von supermicro wird das explizit beschrieben, IT und BIOS in kombi). Der HBA selber? mps? Bin ratlos...

Jedenfalls kam beim Boot ein neuer Eintrag seitdem das BIOS auch mitfährt:

mps0: IOCCapabilities: 5a85c<ScsiTaskFull,DiagTrace,SnapBuf,EEDP,TransRetry,EventReplay,MSIXIndex,HostDisc>

 

[Yamagi]

Also liegt es wahrscheinlich wirklich an der undurchsichtigen Firmware den Controller. Hast du denn gar keine Möglichkeit einen dummen AHCI-Controller zu nehmen? Das scheitert an den Kabeln, oder?

 

[mr44er]

Ich könnte die Backplane rausbauen, dann muss ich sehen, wie ich die 8 Platten mit Strom versorge. Das Netzteil hat nur 4-pin Molex. Kenne mich da nicht aus, gibt es da Adapterpeitschen für SAS auf SATA? Hab beim Überfliegen auch von reverse-/forward-Kabeln gelesen. Die sehen doch gleich aus?
Wenn das ginge, könnte ich die 8 Platten direkt ans Board stopfen.

Dann brauch ich noch einen PCI-E Controller mit bootrom für die 3 SATA-Platten zum Booten.

Da ists irgendwie einfacher, einen anderen Controller auszuprobieren, der einfach 2xSFF-8087 hat. Aber welchen?

Aber erstmal teste ich noch mit BIOS und den eingestellten timeouts seit gestern. Bisher problemloses wakeup, aber es ist wieder zu früh, um was sagen zu können.

 

[mr44er]

Kannst du damit noch was anfangen?

pciconf -lBbceVv mps0
mps0@pci0:5:0:0:    class=0x010700 card=0x30201000 chip=0x00871000 rev=0x05 hdr=0x00
    vendor     = 'LSI Logic / Symbios Logic'
    device     = 'SAS2308 PCI-Express Fusion-MPT SAS-2'
    class      = mass storage
    subclass   = SAS
    bar   [10] = type I/O Port, range 32, base 0xe000, size 256, enabled
    bar   [14] = type Memory, range 64, base 0xfeab0000, size 65536, enabled
    bar   [1c] = type Memory, range 64, base 0xfeac0000, size 262144, enabled
    cap 01[50] = powerspec 3  supports D0 D1 D2 D3  current D0
    cap 10[68] = PCI-Express 2 endpoint max data 128(4096) FLR NS
                 link x8(x8) speed 5.0(8.0) ASPM disabled(L0s)
    cap 03[d0] = VPD
    cap 05[a8] = MSI supports 1 message, 64 bit
    cap 11[c0] = MSI-X supports 16 messages, enabled
                 Table in map 0x14[0xe000], PBA in map 0x14[0xf000]
    ecap 0001[100] = AER 2 0 fatal 0 non-fatal 1 corrected
    ecap 0019[1e0] = PCIe Sec 1 lane errors 0
    ecap 0004[1c0] = Power Budgeting 1
    ecap 0016[190] = DPA 1
    ecap 000e[148] = ARI 1
  PCI-e errors = Correctable Error Detected
                 Unsupported Request Detected
     Corrected = Advisory Non-Fatal Error

 

[mr44er]

Platten schliefen seit 15 Uhr
17:45 Freigabe am Client gemountet, auf Verzeichnis gewechselt, Plattenspinup hörbar, direkt reboot.

Es gab einen dump:

root@aserver:/var/crash # kgdb81 /boot/kernel/kernel /var/crash/vmcore.0
GNU gdb (GDB) 8.1 [GDB v8.1 for FreeBSD]
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd11.1".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /boot/kernel/kernel...Reading symbols from /usr/lib/debug//boot/kernel/kernel.debug...done.
done.

Unread portion of the kernel message buffer:


Fatal trap 12: page fault while in kernel mode
cpuid = 4; apic id = 14
fault virtual address    = 0x0
fault code        = supervisor write data, page not present
instruction pointer    = 0x20:0xffffffff8032ff3a
stack pointer            = 0x28:0xfffffe07ccb737b0
frame pointer            = 0x28:0xfffffe07ccb73960
code segment        = base 0x0, limit 0xfffff, type 0x1b
            = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags    = interrupt enabled, resume, IOPL = 0
current process        = 4 (doneq1)
trap number        = 12
panic: page fault
cpuid = 4
KDB: stack backtrace:
#0 0xffffffff80b48ea7 at kdb_backtrace+0x67
#1 0xffffffff80b02447 at vpanic+0x177
#2 0xffffffff80b022c3 at panic+0x43
#3 0xffffffff80f8dfcf at trap_fatal+0x35f
#4 0xffffffff80f8e029 at trap_pfault+0x49
#5 0xffffffff80f8d7f7 at trap+0x2c7
#6 0xffffffff80f6e17c at calltrap+0x8
#7 0xffffffff8031c42b at xpt_done_process+0x6ab
#8 0xffffffff8031e626 at xpt_done_td+0x126
#9 0xffffffff80ac59c3 at fork_exit+0x83
#10 0xffffffff80f6f09e at fork_trampoline+0xe
Uptime: 3h13m11s
Dumping 1356 out of 32711 MB:..2%..11%..21%..31%..41%..51%..61%..71%..81%..91%

__curthread () at ./machine/pcpu.h:229
229        __asm("movq %%gs:%1,%0" : "=r" (td)
(kgdb) backtrace
#0  __curthread () at ./machine/pcpu.h:229
#1  doadump (textdump=<optimized out>) at /usr/src/sys/kern/kern_shutdown.c:315
#2  0xffffffff80b0205b in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:383
#3  0xffffffff80b02481 in vpanic (fmt=<optimized out>, ap=0xfffffe07ccb73500) at /usr/src/sys/kern/kern_shutdown.c:776
#4  0xffffffff80b022c3 in panic (fmt=<unavailable>) at /usr/src/sys/kern/kern_shutdown.c:707
#5  0xffffffff80f8dfcf in trap_fatal (frame=0xfffffe07ccb736f0, eva=0) at /usr/src/sys/amd64/amd64/trap.c:875
#6  0xffffffff80f8e029 in trap_pfault (frame=0xfffffe07ccb736f0, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:712
#7  0xffffffff80f8d7f7 in trap (frame=0xfffffe07ccb736f0) at /usr/src/sys/amd64/amd64/trap.c:415
#8  <signal handler called>
#9  0xffffffff8032ff3a in probedone (periph=<optimized out>, done_ccb=0xfffff800dc48d800) at /usr/src/sys/cam/scsi/scsi_xpt.c:1793
#10 0xffffffff8031c42b in xpt_done_process (ccb_h=0xfffff800dc48d800) at /usr/src/sys/cam/cam_xpt.c:5309
#11 0xffffffff8031e626 in xpt_done_td (arg=0xffffffff81aad800 <cam_doneqs+256>) at /usr/src/sys/cam/cam_xpt.c:5336
#12 0xffffffff80ac59c3 in fork_exit (callout=0xffffffff8031e500 <xpt_done_td>, arg=0xffffffff81aad800 <cam_doneqs+256>,
    frame=0xfffffe07ccb73a40) at /usr/src/sys/kern/kern_fork.c:1054
#13 <signal handler called>

Schnauze voll. Spindown vorübergehend deaktiviert.

 

[mr44er]

Der Befehl wird von dem Controller an die Festplatten geschickt, nachdem das Betriebssystem den Controller mitgeteilt hat, dass das System herunterfährt. Durch SSU bekommt die Festplatte die Gelegenheit sich sauber abzuschalten, bevor der Strom getrennt wird. Trennt man stattdessen einfach den Strom, ist das ein "Emergency Shutdown". Die Festplatte muss dann die kinetische Restenergie der Spindel und Strom aus einem Stützkondensator nutzen um den Cache auszuschreiben und die Schreibköpfe in Parkposition zu bringen.

Explizit nochmal dazu, was ich jetzt herausfand: Der mps-Treiber ignoriert 'hw.mps.enable_ssu', wenn nicht die IR-Firmware drauf ist. Dh. mit IT-Firmware knallen die Köpfe stark hörbar und das jedes Mal, wenn man herunterfährt.
Steht so im Quellcode vom Treiber. Kann ich dem manuell irgendwie entgegenwirken, sodass das nicht passiert? Evtl. in der rc.shutdown, da ich am Treiber direkt nicht rumpfuschen will? Wie machst du das in der Firma mit den 9300-8i? Als ITler fühlt sich das immer wie ein Tritt in die Klöten an, wenn die Köpfe knallen.

Update:
IT-Firmware + BIOS ist sinnlos. Die Einstellungen greifen anscheinend nicht.
Ich hatte noch 5 alte SATA-Platten rumfliegen in der Range 500-750 GB. Erstmal meinen pool exportiert, dann alle HDD-Trays raus.

Den SAS2308 nochmal gelöscht. Penibel mit '-o -e 7' damit der wirklich blanko ist. Dann die P207 frisch drauf, dann die SAS-Adresse neu gesetzt. *reboot* Keep it simple!

Eine Platte hab ich an ada0 gehängt, darauf 11.2-Release frisch installiert. Nichts getunt, nur den arc limitiert. Die vier Mischplatten hab ich jeweils in Trays verbaut und zwei unten und zwei oben reingesteckt, damit beide Backplanes benutzt werden. Mittendrin mal den Finger auf den Kühlkörper vom Controller, damit meine Hitzeparanoia nicht greift. Jedesmal knapp unter lauwarm dat Dingen.
Nun Standardprozedur: geli init da0-da3, glabel verbraten, zfs create raidz -f (weil unterschiedliche Größe) und dann Daten draufkopiert. Danach spindown auf 600s eingestellt und exzessiv seit Donnerstag scrubs gefahren und NFS-Zugriffe initiert, wenn die Platten schliefen. Null Fehler, null Panics. Verrückt!

Was mir dabei auffiel: Ich kann mit SATA-Platten 'camcontrol standby und camcontrol sleep' absetzen, das heißt, der Controller und mps-Treiber spielen da mit und wandeln SATA-Befehle korrekt um. Ebenfalls funktioniert 'camcontrol stop da0'. Egal wie ich sie aus dem Schlafmodus wecke, es hat jedesmal einwandfrei geklappt. Jedoch lag die Zeit des Gesamtspinups (staggered) bei um die 30s für die vier Platten.
Btw. staggered spinup: der mps-Treiber hat das fest drin und erlaubt gar nichts anderes. Wenn die Platten hochdrehen hab ich am Messgerät maximal 160W abgelesen, kann also auch nicht sein, dass das Netzteil wegschmiert und die Fehler erzeugt.

Jetzt gibt es ja noch schöne andere timeouts als bei dem mps. Wie z.B. standardmäßig 'kern.cam.da.default_timeout=60' und 'kern.cam.da.retry_count=4'.
kern.cam.da.default_timeout=300 hab ich jetzt gesetzt (dummes try and error) und die 8 HGST-SAS-Platten wieder reingestopft. Seit heute Nachmittag ebenfalls wieder exzessiv die Platten aus dem spindown rausgequält. Keine Fehler, keine panic.

Die manpage ist dazu nicht deutlich genug.
kern.cam.da.default_timeout ->

This variable determines how long the da driver will wait before timing out an outstanding command. The units for this value are seconds, and the default is currently 60 seconds.

Heißt das jetzt timeout je da-device oder zieht der sich lang über den ausstehenden Befehl insgesamt, wenn 8 Platten per staggered spinup länger als 60s benötigen?

kern.cam.da.retry_count ->

This variable determines how many times the da driver will retry a READ or WRITE command. This does not affect the number of retries used during probe time or for the da driver dump routine. This value currently defaults to 4.

Hier weiß ich auch nicht, ob die 4 Versuche bereits anlaufen, wenn der obere timeout erreicht ist und wieviel Zeit bis Versuch 2 vergehen (müssen) oder ist es so: 'Oh, 60s überschritten, retry 1-4 während Sekunde 70 auch nicht möglich, ich gebe auf und scheiße dmesg zu'?
Oder hat das mit dem timeout so gar nichts zu tun und das reagiert nur wenn eine Platte wirklich stirbt?

 

[mr44er]

Ok, passiert wieder. Entweder liegt es wirklich an genau meinem Typ Festplatte (HGST 7K6000) z.B. mit dem media caching oder was mit timeouts -> http://www.tomsitpro.com/articles/hgst-ultrastar-c15k600-hdd,2-906-3.html
Wenn die Platten schlafen und ich fahre den Server runter, bekomme ich nämlich 8x 'synchronize cache failed'

Während ich der Zwangsjacke davonrenne, hab ich mal das debugging vom mps hochgeschraubt und warte einfach mal.

 

[mr44er]

Ich möchte lösen.

Die HGST 7K6000 ist eine der ersten Platten mit dem neuen 'Power Disable Feature (PWDIS)'. -> https://www.hgst.com/sites/default/files/resources/HGST-Power-Disable-Pin-TB.pdf

Bis dato hatte ich davon noch nichts gehört. Es gibt die SAS-/SATA-Modelle jeweils mit und ohne PWDIS. Die Broschüre drückt sich vage aus: mit PWDIS-SATA an legacy-backplanes hat man definitiv oft ein Problem, mit PWDIS-SAS an legacy-backplanes soll es nie Probleme geben. In der Realität herrscht jedoch Chaos und es ist Glückssache, wie die backplane gedrahtet ist. Man muss einfach probieren, ob es funktioniert. Es kann nichts kaputt gehen, im schlimmsten Fall läuft die Platte einfach nur nicht an, was einen ohne dieses Wissen vllt. auch schon am Kopf kratzen lässt.
Mein genaues Modell der Platten hat natürlich () dieses Feature und obwohl die Stromzufuhr über Molex an die BP kommt und sie problemlos anläuft, hat mich das zuerst auf die falsche Fährte gelockt, weil sie zwar wieder anlief, aber mit errors.

https://zackreed.me/hgst-7k6000-not-spinning-not-working/
Also hab ich mich mit ner Pinzette ausgerüstet hingesetzt und Pin 3 überklebt. Fun fact: Auf dem Foto ist sogar die gleiche Nummer auf der Platine wie bei mir.

Ergebnis: keine Veränderung, immer noch errors. Umsonst war es aber nicht, ich hab was gelernt und 'pre-pimped' Platten, falls ich mal auf ne andere BP ausweichen muss.

Das hochgedrehte debugging warf mir 'check condition' und 'polling device' hin. Mhhhm....watn nu?

Auf den ersten Moment weist das hier auf den Fehlerablauf hin -> https://git.kernel.org/pub/scm/linu...c?id=14216561e164671ce147458653b1fea06a4ada1e

Danach für FreeBSD googlen brachte nur ein Ergebnis -> http://freebsd.1045724.x6.nabble.co...URs-until-good-status-returned-td6227460.html

Mhmmm....FBSD11 und Dezember 17 und noch genau der passende Fehlerfall. Kann es wirklich sein, dass der cam-layer...egal, ich studiere jetzt den Code davon und dann noch von mps uswusf. Trotz meiner nicht vorhanden Programmierkenntnisse konnte ich nichts rauslesen, was auf das Fehlverhalten hinweist, im Gegenteil.

Dann hab ich im dicken Spezifikationsblatt ( http://www.hgst.com/sites/default/files/resources/Ultrastar_7K6000_SAS_OEM_Specification_Rev1.6.pdf )der Platte die mode pages genauestens studiert. Viele Versuche und Anläufe, höhö.

Doch dann, Seite 157. -> CCF_STOPP muss von 2 auf 1 gesetzt werden.

sdparm -s ccf_stop=1 -S da0

sysutils/spindown stoppt wortwörtlich eine SAS-Platte und macht keinen standby. CCF_STOPP=2 (vendorspezifisch) sorgt dafür, dass ein START UNIT erforderlich ist, TUR bzw. normale i/o-requests gehen nicht/bringen nichts.
In meinem Fall sind die Platten zwar irgendwie wieder hochgekommen, aber wie schon beschrieben nur halbherzig. Ich nehme an, dass der cam-layer aggressiv genug hierbei ist, aber die Platte dann sämtlichen i/o verweigert und dann error 22 (das ist wohl generell ein Lesefehler) auf allen layern wirft, wie erlebt. Oder ZFS hat auf dem Plattencache rumnudeln können (8x128MB) und dann war Essig.

Der dumpauszug sagt auch genau das, wenn man sich die gemeldeten Zeilen von scsi_xpt.c und cam_xpt.c mal anschaut. Die requests timen irgendwann aus und die panic soll geschehen.

#9  0xffffffff8032ff3a in probedone (periph=<optimized out>, done_ccb=0xfffff800dc48d800) at /usr/src/sys/cam/scsi/scsi_xpt.c:1793
#10 0xffffffff8031c42b in xpt_done_process (ccb_h=0xfffff800dc48d800) at /usr/src/sys/cam/cam_xpt.c:5309
#11 0xffffffff8031e626 in xpt_done_td (arg=0xffffffff81aad800 <cam_doneqs+256>) at /usr/src/sys/cam/cam_xpt.c:5336

Mein Fazit: Augen auf beim nächsten Plattenkauf

sysutils/spindown nutze ich nun nur noch für SATA. Da ich die mode pages nun verstehe, bin ich auf den platteninternen standby und idle_c ausgewichen. Das ist wie APM in gut, weil feingranular.

Weitere kleine facts:
Sobald nur eine Platte eines pools CCF_STOPP=2 hat und aufgeweckt wird, werfen alle vdevs den error 22, selbst wenn die anderen SATA-Platten sind.
standby_z ist der tiefste Modus, wird im Handbuch auch so beschrieben. sdparm weist den Wert allerdings als 'standby' aus, was misinterpretiert werden kann oder ist das nur bei HGST so?
Der Pool kommt unter standby einen Tacken schneller hoch als wenn die Platten gestoppt sind. Stromverbauch ist der gleiche.
Beim Vorgänger 7K3000 sind 'CCF_IDLE' 'CCF_STAND' und 'CCF_STOPP' auf 0. Damit klappts. Bei der 7K6000 geht nur entweder 1 oder 2.