Wellicht onwaar of een gerucht:

Ingebouwde timers in hp printers,een productie pas na het jaar 2003 tot ? geen idee
een printer die dan stopt na 3 jaar omdat het inkt-sponsje te verzadigd raakt met inkt en blokkeert.

Er waren dan "zogenaamde unlock-codes" waarmee je de printer weer kon de-blokkeren,
deze zogenaamde unlock-codes waren overigens nergens te vinden.

Joop

2^15 = 32768, 2 bytes woord ergens?

lekker lullig zou ik zeggen dat er een kill switch in zit, altans , zo zou ik het omschrijven.

Dat zou 16 bits zijn ;-) en 2 x zo lang meegaan ......

En waarschijnlijk een signed integer, in plaats van unsigned - vandaaar dat 32768 magisch is - een volgende waarde wordt dan negatief. (feitelijk is de range van een signed short -32768 .. 32767.)

Ik ben benieuwd op welke manier dit leidt tot totaal verlies van de SSD.
Ik gok dat er iets van firmware flash maintenance of scrubbing gedaan wordt op regelmatige tijden (vandaar de poweron-uren teller), en dat daar iets heel raar mee misgaat als de input waarde negatief is.

shorts zijn signed dus daar gaat je extra bit heen.

Signed integer ;-)

Het waardebereik van een signed 16-bit integer loopt van -32768 tot +32767. Dit zit 1 erboven.

...behalve als het een signed 16-bits integer is, want dan wordt één bit gereserveerd voor de markering van + of -.

Dit is een domme integer overflow-fout.

Niet als er een signed integer wordt gebruikt (wat gangbaar is).

Als je 1 optelt bij decimaal 32767 (hexadecimaal 0x7FFF) in een signed integer-register van 16 bits, wordt de nieuwe waarde 0x8000, hetgeen (met de gebruikelijke two's complement interpretatie) leidt tot het decimale getal -32768.

De programmeur verwachtte waarschijnlijk geen negatieve getallen in zijn code, dit is een veel gemaakte fout - van ern type dat minder aan het licht komt naarmate CPU-registers (en de gebruikte geheugenruimte) toenemen, waardoor het steeds minder loont om variabelen in zo klein mogelijke registers te stoppen. En als je, "blind" test en dat, in dit geval, minder dan 32768 uur doet, kom je hier natuurlijk ook niet achter.

Gangbaar in moderne CPU's zijn registers van 32 of zelfs 64 bits , maar microcontrollers (ook die op de printplaat op de HDD/SSD) lopen vaak achter op dit punt.

Of het nu signed of unsigned integers zijn, het scheelt een factor 2. Het punt is dat het schandalig is dat er een timer ingebouwd zit. Ook na 7 jaar gebruik zijn die dingen onder normale omstandigheden nog niet kapot.

Van 0 tot en met 32767 (uur) = 32768.

Moet haast wel iets met de bedrijfsuren-teller in S.M.A.R.T. zijn. (https://en.wikipedia.org/wiki/S.M.A.R.T.)
Wel een erg suffe fout trouwens.
Typisch HP: soms zijn ze steengoed, en een andere keer denk je hoe krijgen ze het in hemelsnaam voor elkaar zo suf.

In hardware is dat dus weer niet gangbaar, kan idd eeen software engineer zijn die zomaar een int gebruikt waar dat niet nodig is

Het is gewoon een domme fout, geen bewust ingebouwde timer.

Oliedom is het zeker, maar "schandalig" zou ik het zeker niet noemen...

Zo'n timer met een vaste tijd is wel heel verdacht. Dan weet je zeker dat je door de mand gaat vallen. Nee dus.

Waarschijnlijker is het zoals anoniem 16:21 aanneemt: De code loopt plotseling tegen een negatieve tijd aan waardoor de software vast loopt of geheel verkeerde dingen gaat doen.

Een voorbeeld zou kunnen zijn dat hij bij de allereerste opstart bij tijd=0 de schijf moet initialiseren. Negatieve tijden zijn niet voorzien en worden ook als initialisatie opdracht gezien.

Gewoon de SSD's weer 3 jaar, 270 dagen en 8 uur aan laten staan en dan komt alles weer goed … hoop ik.

Dit doet zich bij elke piezo inkjet voor. Door de bij die technologie verplichte reiniging loopt er inderdaad een opvang(kussen) vol. Normaliter is dat een kwestie van vervangen en teller op nul zetten. Alleen op nul zetten van de teller resulteert uiteindelijk in een heel smerige kliederboel.

Misschien dat ze weer gaan werken als je ze nog eens 32768 uur aan laat staan en het getal weer positief wordt...

Ook mijn gedachte. Als de onverwachte waarde tot een exception leidt die niet goed wordt afgevangen, dan kan misschien de hele schijfcontroller crashen, en blijven crashen omdat de fout ook na een herstart blijft optreden.

Nog een gedachte: het hoeft geen signed integer te zijn om op 15 bits uit te komen, de klok kan een veel hogere resolutie hebben maar zo zijn ingeregeld dat de X meest significante bits keurig op uren uitkomen. Dat ligt eigenlijk wel voor de hand, want men moet ook uren kunnen tellen bij schijven met een gebruikspatroon waarin ze regelmatig minder dan 1 uur aaneengesloten in gebruik zijn en dat vergt een hogere tijdresolutie. Het hoeven niet per se de 15 meest significante bits te zijn, die fout kan ergens in de verwerking van de waarde liggen. Wellicht geeft daar een verkeerd gedimensioneerde integer een overflow exception die niet wordt afgevangen.

Ik weet niet of het suf van HP is. Onderschat niet hoe complex software (inclusief firmware) al snel is en hoe moeilijk het is om alle fouten af te vangen. Deze fout, als je hem kent, kan triviaal lijken, maar het is verre van triviaal om alle triviale fouten in een complex geheel op te sporen.

Alle mensen laten steekjes vallen. Degenen die iets programmeren, degenen die er unit tests voor maken, degenen die peer reviews doen, degenen die de apparaten door testprogramma's halen, degenen die die testprogramma's automatiseren, niemand is perfect.

Je kan nog zo'n indrukwekkende pijplijn aan filters maken die allemaal een hoop fouten afvangen, je kan geen enkel filter maken dat de volle 100% aan fouten afvangt, en als elk filter in een pijplijn iets doorlaat dan is er onvermijdelijk een kleine kans dat een fout door alle filters in de pijplijn doorgelaten wordt. En als je heel botte pech hebt is het een fout die niet meer te herstellen is als hij eenmaal is opgetreden. Daar kan dit een voorbeeld van zijn.

uh?

Twee weken terug werd HPE geïnformeerd door de klant..... o.a. mijn werkgever. En ondertussen bleek er na 2 dagen meer klanten het probleem te hebben.
Wij hadden het probleem dat er tegelijk 6 schijven onbereikbaar waren, in twee servers. Totaal 12 schijven dus. Je gaat er dan niet vanuit dat het de schijven zijn die stuk zijn.
Het leek op een error van de array controller. Of de backplane. Hoe dan ook een rare gewaarwording als de helft van je VDI cluster afsterft.. Blij dat je dan een alternatief hebt.

Overigens zijn wij zeer goed geholpen door HPE! We werden steeds goed geïnformeerd over de status.
Het duurde helaas wel 4 werkdagen (met nog een weekend er tussen) voor de oorzaak bekend was.
Er was alleen een error terug te vinden in de logs van de array controller. Niet via de ILO.
In de flink aantal jaren dat ik in de ict werk niet eerder een dergelijk probleem mee gemaakt.

SSD's gaan sowieso minder lang mee en als ze stuk gaan dan kan er wellicht 5 of 12volt de nandflash chips in vliegen ja, dan zijn de gegevens letterlijk weg gebrand ja.

Niet zelf meegemaakt, maar zien langskomen op een mailinglijst :

Een optic met een buggy controller - na 2**31 jiffies (1/100 seconde - ca 8 maanden) ging die de klok in de temperatuur-sensor area schrijven.
In de monitoring leek de temperatuur van -127 naar +127 lopen . En bij elke ronde was er een korte burst van CRC errors op de link.
Soms net lang genoeg om OAM het interface van de router in 'err-disable' te laten zetten.

Omdat tijdens maintenance vaak een aantal devices dicht bij elkaar gereload worden , zitten de uptimes van de devices (en dus van de optics) ook dicht bij elkaar . Daar sta je dan , met je multi-device, multi-link , multi-pad redundante netwerk als de uptimes de 8 maanden aantikken ...

('optic' : een module in één van de standaard maten en interfaces die je in een switch of router steekt . Er zit dus ook een controllertje op oa voor monitoring. zie https://en.wikipedia.org/wiki/Small_form-factor_pluggable_transceiver )

Onzin, je vergelijkt appels met peren, in veel gevallen gaat een SSD langer mee.

De hardware komt van een 3de leverancier die dit type SSD's maakt. Kans is heel groot, dat andere hardware leveranciers dit zelfde issue hebben.

Daarnaast is het HPe en niet de consumenten HP.

https://blocksandfiles.com/2019/11/25/hpe-issues-firmware-fix-to-to-stop-ssd-failure/

The HPE customer bulletin, dated 19 November, says SSD Firmware Version HPD8 is a critical fix. If it is not applied the drive will fail at 32,768 hours operating time, meaning 3 years, 270 days 8 hours, and data on the drive will be lost.

The company said in a statement: “A supplier notified HPE on 11/15 of a manufacturer firmware defect in certain solid state drives used in select HPE server and storage products. HPE immediately began working around the clock to develop a firmware update that will fix the defect. We are currently notifying customers of the need to install this update as soon as possible. Helping our customers to remediate this issue is our highest priority.”

Affected HPE systems include ProLiant servers, Synergy, Apollo, JBOD D3xxx, D6xxx, D8xxx, MSA and StoreVirtual 3200 arrays. 3PAR, Nimble and Primera arrays are not affected. The affected drives’ firmware should be updated immediately.

A series of HPE SSD SKUs are listed in HPE’s bulletin. These are all 2.5-inch, 12Gbit/s SAS SSDs with capacities of 400GB, 800GB, 1.6TB and 3.2TB. A second set of capacities are 480GB, 960GB, 1.92TB, 3.84TB, 7.68TB and 15.3TB.

To us this looks like a single SSD family with read-intensive and longer life models is affected. HPE is not identifying the supplier.

Volgens https://www.zdnet.com/article/hpe-tells-users-to-patch-ssds-to-prevent-failure-after-32768-hours-of-operation/:
Dus een andere SSD-fabrikant heeft blijkbaar de fout in de HPE-ssd gevonden. (is dat suf of wel?....)
De herstellende firmware-versie begint ook nog eens met HP. Lijkt me sterk dat dit toeval zou zijn.


P.S. Link naar HPE informatie:
https://support.hpe.com/hpsc/doc/public/display?docId=emr_na-a00092491en_us

Ik denk wel dat dit kan.
Een SSD bestaat uit NAND chips, een besturingscontroller en verdere electronica op een bord.
HPE maakt zelf geen chips , en heeft die dus ergens gekocht. Ze maken, denk ik, ook het printboardje niet .

Ik denk dat HPE , naast z'n naam erop plakken een SSD(lijn) met bepaalde specs gekocht heeft , of heeft laten maken.
Een andere SSD "fabrikant" - die de boel ook inkoopt kan dus dezelfde controller met zelfde firmware krijgen en de bug met concullega's delen.

De naam in de interface, en in de firmware zegt niet zo veel - als je genoeg koopt wil de fabrikant met alle plezier de boel rebranden. Dat wil niet zeggen dat de firmware totaal anders is . Namen, misschien sommige tweak/tuning parameters, maar de basisfuncties blijven hetzelfde.

Ik geloof dat je het punt hebt gemist. Dat was niet dat het suf van een ander dan HP zou zijn, maar dat het onhaalbaar is om alle suffe fouten uit een complex systeem te halen, hoe goed de kwaliteitscontroles ook zijn. Dus hoe scherp een organisatie ook is op het afvangen van suffe fouten, toch slipt er af en toe een door de controles, dat is onvermijdelijk. Daarom weet ik niet of dit suf van HP is. Het is ook mogelijk dat ze helemaal niet suf zijn maar dat er toch een fout door alle kwaliteitscontroles is geglipt.

Ik denk het niet, ik weet het wel 100% zeker.

https://www.serversupply.com/SSD%20W-TRAY/SATA-6GBPS/3.84TB/HPE/VK003840GWJPK.htm
Duidelijk een HPe SSD, maar gewoon van Intel.

|Dit soort SSD hebben vaak wel een custom firmware draaien, maar deze wordt eigenlijk altijd door de SSD leverancier bewerkt of gemaakt, wel icm met HPe voor de support.

Het zou in theorie kunnen dat HPe zelf de firmware heeft aangepast, maar de kans is groter dat de SSD leverancier een foutje in firmware had, waar HPe nu last van heeft.

Dat ze geïnformeerd worden vanuit de SSD leverancier is ook vrij logisch. Het probleem zal best wel veel voorkomen. Dus wordt er geëscaleerd, en zal er defecte hardware opgestuurd worden. De SSD zullen oa naar de SSD leverancier gestuurd worden. Waarna die een onderzoek zullen doen naar de RCA. En daar zal dit uitgekomen zijn.

Een vrij standaard probleem analyse.

HPE zegt zelf in https://support.hpe.com/hpsc/doc/public/display?docId=emr_na-a00092491en_us
De firmware waar de fout in zit is daarom blijkbaar afkomstig van HPE, maw HPE heeft een suffe fout in de firmware gemaakt.
Het is ook logisch dat HPE zelf de firmware ontwikkelt om het zo perfect mogelijk te laten aansluiten op hun systemen waar ze in moeten werken. (met eventuele propriety-features)

Zelf beschouw ik firmware fouten (= "programmeerfouten") standaard als suf, anders blijf je langer een sufferd.
Noem ik mezelf (of iemand anders) hierom suf, dan is dat eigenlijk een aanmoediging om voortaan scherper te zijn
zodat zulke suffe fouten in de toekomst niet meer (of in elk geval steeds minder) worden gemaakt.
(evenzo moeten bij HPE suffe managers die er een potje van maken tijdig de laan uit, en niet het betere personeel)

Dat hoeft nog steeds niet. HPe kan gewoon de leverancier aansturen voor een custom firmware icm hun eisen. Dit zodat alles goed samen werkt icm hun tooling en certificeringen. Daarbij hoeven ze vanuit HPe zelfs nog geen (firm)code regel voor te schrijven. OEM leveranciers doen niets anders.

Zo heb je ook soms suffe conclusies die getrokken kunnen worden.

Nou en of! Pas daar maar voor op.

Er bestaan meer bekende bedrijven die soms steen goed zijn en soms kei slecht.Dat is niet typisch HP(E).