Date: Wed, 17 Jul 2019 18:27:26 +0200 From: Domagoj =?UTF-8?Q?Smol=C4=8Di=C4=87?= <rank1seeker@gmail.com> To: Larry Maloney <larry.maloney@hackerdojo.com> Cc: hackers@freebsd.org Subject: Re: For a first time completed S.M.A.R.T captive test Message-ID: <20190717182726.00003ad1@gmail.com> In-Reply-To: <C38B084F-7C98-4EF7-9C8A-7B811E42A02E@hackerdojo.com> References: <20190716190854.000061b2@gmail.com> <C38B084F-7C98-4EF7-9C8A-7B811E42A02E@hackerdojo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 16 Jul 2019 11:07:47 -0700 Larry Maloney <larry.maloney@hackerdojo.com> wrote: > It=E2=80=99s been a while,so I could be wrong, but I seem to recall havin= g to > unmount the device before testing. If you read below, this is implied. Only device node exists. Keyword here is CAPTIVE =3D=3D> '-C' flag. Regular tests always finish /w problems, even with mounted FS-es, i.e; # smartctl -t long /dev/... Try with captive, then you'll see if you can finish it: # smartctl -C -t long /dev/... Domagoj Smol=C4=8Di=C4=87 > /Larry >=20 > Sent from my iPhone >=20 > > On Jul 16, 2019, at 10:08 AM, Domagoj Smol=C4=8Di=C4=87 > > <rank1seeker@gmail.com> wrote: > >=20 > > 11.2-RELEASE-p9 > >=20 > > From the first time I started to use FreeBSD and upon to just > > recently, with smartmontools, I have NEVER successfully completed > > captive test. No matter which HDD or smartmontools version I used, > > upon initiating 'Extended captive' test, I would ALWAYS get error: > > 'Interrupted (host reset)' This implies nothing is being mounted > > from device, so only it's node exist in /dev/ and nothing "chats" > > with it except kernel. Stopping smartd service also didn't help. > >=20 > > Searching on the internet, I have never found anyone succeeding > > with it. Just a "solutions" that it should never be used?! > >=20 > > So I started to think a little bit out of the box ... > > HDD has it's OWN board with it's OWN BIOS + firmware, which > > actually holds S.M.A.R.T version/ability and IT executes issued > > test from OS, using it's own firmware to actually run a test. Once > > HDD receives test request from OS, HDD doesn't need OS at all! > >=20 > > So, in order to get rid of a results like: > > Num Test_Description Status Remaining > > LifeTime(hours) LBA_of_first_error # 2 Extended captive > > Interrupted (host reset) 90% 40743 - > >=20 > > And suspecting OS (kernel?!) is pestering HDD during it's captive > > test, thus interrupting it, AS SOON as captive CMD is issued and > > hangs occurs (it is too late when hang passes by itself!), I've > > pulled out SATA DATA cable and left SATA POWER cable attached. Hang > > is stopped as soon as SATA DATA cable is unplugged and it's used > > only to transfer test request anyway to HDD and all HDD needs from > > that point on, is JUST a power and it's "piece of mind"! RESULT: -- > > SMART Self-test log structure revision number 1 Num > > Test_Description Status Remaining > > LifeTime(hours) LBA_of_first_error # 1 Extended captive > > Completed without error 00% 40744 - # 2 Extended > > captive Interrupted (host reset) 90% 40743 - -- > >=20 > > FINALLY! =3D=3D> '# 1 Extended captive Completed without error' > >=20 > > So ..., what to conclude from this? > > Does kernel really must "chat" with HDD in order to keep alive it's > > device node in /dev/ or is it something else? If HDD supports > > captive test and during it, why it simply doesn't ignore OS/kernel > > (it is up to HDD's firmware code to make that decision). > >=20 > > Is this, I'm not even sure how to name it ..., a borderline bug? > >=20 > > Anyway, it is a little bit "impractical" to use terminal with one > > hand and with other to pull out SATA data cable. > >=20 > >=20 > > Domagoj Smol=C4=8Di=C4=87 > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to > > "freebsd-hackers-unsubscribe@freebsd.org" =20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190717182726.00003ad1>