Hi,
Ritesh Raj Sarraf's kernel wrote:
> [156278.815976] sd 1:0:0:0: [sdb] UNKNOWN(0x2003) Result: hostbyte=0x00
> driverbyte=0x00
> [156278.823864] sd 1:0:0:0: [sdb] CDB: opcode=0x28 28 00 9a 40 04 47 00 00 08
> 00
> [156278.831152] blk_update_request: I/O error, dev sdb, sector 2587886663
This was an attempt to read data from address 0x9a400447,
which would mean your storage medium has a capacity of 1.2 TB at least.
Is this log snippet preceded by lines with "Sense Key" or "Add. Sense" ?
The text "UNKNOWN(0x2003)" is quite popular in the web. But i did not find
further enlightenment yet. (The problem is near enough to my own sports
to make me curious.)
The message part seems to be quite new in the kernel:
/usr/src/linux-4.1.6/drivers/scsi/scsi_logging.c line 458
I cannot find it in Jessie's 3.16.
Reason for "UNKNOWN" is that scsi_mlreturn_string() in
drivers/scsi/constants.c did not find 0x2003 in scsi_mlreturn_arr.
This is riddling, because in include/scsi/scsi.h i see
#define FAILED 0x2003
which i see mentioned in drivers/scsi/constants.c as member of
scsi_mlreturn_arr[]:
#define scsi_mlreturn_name(result) { result, #result }
...
scsi_mlreturn_name(FAILED),
Looks like something with the macro magic of scsi_mlreturn_name()
does not work as expected.
https://gcc.gnu.org/onlinedocs/cpp/Stringification.html
Or scsi_mlreturn_string() does not search far enough. But the
many definitions of ARRAY_SIZE in kernel headers look ok to my
userlander eyes.
What kernel version exactly are you using ?
-------------------------------------------------------------------
Whatever, "FAILED" instead of "UNKNOWN(0x2003)" will not help much
to find the reason for the problem.
If it happened with an optical drive, i'd say it is a volatile hardware
error in one of the participating bus controllers or in their cabling.
(The current main suspect for controller problems is USB 3.)
Have a nice day :)
Thomas
