Problems with [hdparm] after swapping hard drives?

zekepliskin

Member
So I swapped drives between two HDR Fox T2s recently as I'm planning to gift my first one and keep a newer one I picked up for £20 in mint condition the other day (the first 1TB model I've come across and it has a brighter VFD due to being barely used). Now before I did this, hdparm wasn't returning any errors on either box. It does now though :-

Code:
hdparm /dev/sda

/dev/sda:
SG_IO: bad/missing sense data, sb[]:  f0 00 05 00 00 00 00 0a 00 00 00 00 24 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 multcount     =  0 (off)
 readonly      =  0 (off)
 readahead     = 256 (on)
 geometry      = 4/4/8, sectors = 128, start = 0

Originally I thought it was because I'd used the -K 1 flag to try and impose a -M 128 on the drive in the box I'm going to gift as it's a bit noisy and didn't have anything set for AAM by default - I figured it would either keep the value by default or I could add a S99xxxxx type script to the boot process so it sets that every boot if not. But the above code is actually from the WD-AV-GP 4TB drive I've been using for a few years now and it didn't used to return sense data errors. Anything to worry about?
 
£20 for a 1T T2, bargain, where did you find that?

Gumtree, in Southampton. The seller had it listed as "Human HDR Fox T2" which is I assume why it hadn't sold after 2 weeks of being listed. It got used for about a year if that and then sat on a shelf for nearly 6 from the little I was told. The bundled 1TB Seagate Pipeline .2 drive was working fine but surprisingly noisy, in contrast to the 500GB version which is a lot quieter. Although the 4TB WD-AV-GP in my main box is quieter than pretty much anything; I really wish Western would release a 6TB or 8TB version with similar low dB and low power attributes so I could upgrade it, that's how impressed I've been with the performance.
 
Human? That's the auto-correct kicking in as it seems that Apple don't like Humax. And some people just don't check their posts/listings before committing the to the interweb, consequently look stupid.
 
Human? That's the auto-correct kicking in as it seems that Apple don't like Humax. And some people just don't check their posts/listings before committing the to the interweb, consequently look stupid.

Both things I knew and agree with! And allowed me to swoop in and grab a super bargain. So for the 3 HDR Fox T2s I've bought it's been £75 (500GB), £41 (500GB) and £20 (1TB). Funnily enough the less I've paid the better aesthetic condition the boxes have been in too, and it doesn't matter if the hard drives are toast because I always swap them out for bigger ones! Win.
 
Damn straight.

Anyway as much as I love a bit of banter-and-forth, any of the knowledgable people here have an idea about that error? The hdparm manpage doesn't mention it, no surprise there.
 
... before I [swapped drives between two HDR Fox T2s], hdparm wasn't returning any errors on either box. It does now though :-

Code:
hdparm /dev/sda

/dev/sda:
SG_IO: bad/missing sense data, sb[]:  f0 00 05 00 00 00 00 0a 00 00 00 00 24 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 multcount     =  0 (off)
 readonly      =  0 (off)
 readahead     = 256 (on)
 geometry      = 4/4/8, sectors = 128, start = 0

...
But the above code is actually from the WD-AV-GP 4TB drive I've been using for a few years now and it didn't used to return sense data errors. Anything to worry about?
I don't suppose it's relevant but the CF installs /sbin/hdparm v9.48 while the hdparm package has /mod/sbin/hdparm v9.43, not on the default PATH.

Naively one might think SG = Seagate, so is it correct for this to be checked on a WD drive, but actually SG is the code for the SCSI driver.

Following this email, we can install sg3_utils and try this:
Code:
# opkg files sg3utils
Installing sg3utils (1.41) to root...
Downloading http://hpkg.tv/hdrfoxt2/base/sg3utils_1.41_mipsel.opk.
Configuring sg3utils.
# sg_decode_sense f0 00 05 00 00 00 00 0a 00 00 00 00 24 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 Fixed format, current;  Sense key: Illegal Request
 Additional sense: Invalid field in cdb
  Info fld=0x0 [0] 

#
More about the sense buffer (sb[]) here.
But all this only confirms that hdparm is sending an invalid ("Illegal") request and getting an error, and not why.
 
Ah. I re-red that about a duzen tomes and mised it evry thyme. :frantic:
And I'm not sure that it was ironic at all. It doesn't come close to saying the opposite of what you mean. AvP?
 
...
Anyway as much as I love a bit of banter-and-forth, any of the knowledgable people here have an idea about that error? The hdparm manpage doesn't mention it, no surprise there.
On reflection I think we need to see the output of mount in each case.

Is it right that the aim in running hdparm was to set the acoustic parameters for one HDR's noisy drive, which produced the sense data diagnostic, and then the command was run on the other machine as a test?
 
Ah. I re-red that about a duzen tomes and mised it evry thyme.
Yes, because the author reads what he thinks he wrote, not what is actually there. That's why it is never a good idea to do without an editor (or at least a proof reader) when self-publishing!

And I'm not sure that it was ironic at all. It doesn't come close to saying the opposite of what you mean.
You are confusing sarcasm with irony - don't fall into the American English trap! Yes, this is an example of irony.
 
On reflection I think we need to see the output of mount in each case.

Is it right that the aim in running hdparm was to set the acoustic parameters for one HDR's noisy drive, which produced the sense data diagnostic, and then the command was run on the other machine as a test?

Well let's put it this way :-

Humax A had Drive A (this was my original one). This was not the noisy drive. It originally reported no acoustic management present.
Humax B had Drive B (the noisy one). This was noisy and reported AAM was off, so I enabled it using the default quiet setting of 128 with the -M flag.

When Drive B was swapped into Humax A, it started producing the error. When Drive A was swapped into Humax B, it also had the error, but now reported an AAM setting of 81 from cold boot.

AFAIK the noisy drive (Drive B) does respond to AAM -M flag setting with hdparm but I figured, before I put in a one-line boot script or add a line to an existing one I wanted to check it's not going to cause any issues. The reason being, this one is going to my parents to replace their HDR-2000T which sometimes doesn't boot so I don't want any problems with it after I install it!

Incidentally, wasn't there something mentioned about Foxy being able to pull and decrypt files from a HDR-2000T in the wiki... is this still the correct way to do it? From the searching I did I never saw custom firmware making it's way to the 2000 series, and to be honest considering it's basically the same UI as the HDR Fox T2 but a weaker machine I don't blame the team for not bothering!
 
I never saw custom firmware making it's way to the 2000 series... but a weaker machine I don't blame the team for not bothering!
A weaker machine maybe, but it doesn't have the security weaknesses of the HDR-FOX so there is no (discovered) way to inject our own code.

Yes, the Foxy process works, but it only prepares a recording for decryption – not actually decrypt it. See Decryption Guide (click), footnote 10. See also https://hummy.tv/forum/threads/downloading-decrypted-recordings-to-pc-including-hidef.5379/ (which is pinned at the top of the HDR-1800T/2000T section of the forum).
 
A weaker machine maybe, but it doesn't have the security weaknesses of the HDR-FOX so there is no (discovered) way to inject our own code.

Yep, that's about as far as I got with my reading, that and firmware downgrading just wasn't possible. My parents machine has a failed remote replaced with a third party one, is slow/inconsistent to boot and from what I can tell without being able to do a SMART test, a hard drive that won't last much longer. The build quality is clearly not as premium as the HDR Fox T2.

Yes, the Foxy process works, but it only prepares a recording for decryption – not actually decrypt it. See Decryption Guide (click), footnote 10. See also https://hummy.tv/forum/threads/downloading-decrypted-recordings-to-pc-including-hidef.5379/ (which is pinned at the top of the HDR-1800T/2000T section of the forum).

Thank you, I knew I'd seen this somewhere a few weeks ago! They have some recordings unlikely to get repeated in the near future, a few of which are HD and I wouldn't mind adding to my Fox T2, so getting them off for backup and restore purposes would be VERY useful.

EDIT: Wishful thinking, but there's no way of getting the decryption key from the HDR-2000T is there? Only using Foxy to unlock the .HMT, copy it back then download after the DLNA server reindexes the file and removes the (Enc) flag. I was thinking the HDR-2000T's hard drive could be removed, dropped into a HDR Fox T2, encryption key changed to match the HDR-2000T and then set the root My Video folder to auto-decrypt but I'm pretty sure that's not possible.
 
Last edited:
Well let's put it this way :-

Humax A had Drive A (this was my original one). This was not the noisy drive. It originally reported no acoustic management present.
Humax B had Drive B (the noisy one). This was noisy and reported AAM was off, so I enabled it using the default quiet setting of 128 with the -M flag.

When Drive B was swapped into Humax A, it started producing the error. When Drive A was swapped into Humax B, it also had the error, but now reported an AAM setting of 81 from cold boot.

AFAIK the noisy drive (Drive B) does respond to AAM -M flag setting with hdparm but I figured, before I put in a one-line boot script or add a line to an existing one I wanted to check it's not going to cause any issues. The reason being, this one is going to my parents to replace their HDR-2000T which sometimes doesn't boot so I don't want any problems with it after I install it!
...
So my hypothesis was that you might have a drive connected by USB (or virtual USB) that was being discovered before the SATA drive in the HDR. This does indeed result in the sense data error that you reported if you had run hdparm /dev/sda, since /dev/sda is a USB drive. The output of mount would show whether this was so, although it would be a little strange if just swapping drives would alter the startup timings enough.
 
Back
Top