It looks like the drive is replying with an ILLEGAL REQUEST/INVALID FIELD IN CDB error to all the interesting SCSI commands, and to pretty much anything hdparm sends it.
I've also tried throwing sdparm at it. The only page sdparm can get out of it is the basic identification page:
But this has convinced me that I am actually communicating with the disk itself. Is there any way the kernel/driver could be tinkering with the commands that hdparm used to send that worked and which now fail? Or is there some kind of initialization that isn't being done that would put the disk in a mode where it is willing to do more things?
It looks like the drive is replying with an ILLEGAL REQUEST/INVALID FIELD IN CDB error to all the interesting SCSI commands, and to pretty much anything hdparm sends it.
I've also tried throwing sdparm at it. The only page sdparm can get out of it is the basic identification page:
[anovak@octagon hdparm-9.54]$ sudo sdparm -i /dev/sdg 000000001
/dev/sdg: Seagate Backup+ Hub BK D781
Device identification VPD page:
Addressed logical unit:
designator type: NAA, code set: Binary
0x5000000
But this has convinced me that I am actually communicating with the disk itself. Is there any way the kernel/driver could be tinkering with the commands that hdparm used to send that worked and which now fail? Or is there some kind of initialization that isn't being done that would put the disk in a mode where it is willing to do more things?