Hello Thomas,
Thank you for your response.
On Tue, 2016-02-09 at 11:17 +0100, Thomas Schmitt wrote:
> 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.
Yes. This is a 2 TB Seagate drive.
[ 4.247833] scsi 0:0:0:0: Direct-Access Seagate FA GoFlex
Desk 0155 PQ: 0 ANSI: 4
[ 4.253080] sd 0:0:0:0: [sda] 3907029167 512-byte logical blocks:
(2.00 TB/1.81 TiB)
[ 4.253598] sd 0:0:0:0: [sda] Write Protect is off
[ 4.253613] sd 0:0:0:0: [sda] Mode Sense: 1c 00 00 00
[ 4.254114] sd 0:0:0:0: [sda] Write cache: enabled, read cache:
enabled, doesn't support DPO
or FUA
[ 4.273477] bcm2708_rng_init=b3a1c000
[ 4.287442] sda: sda1
[ 4.298911] sd 0:0:0:0: [sda] Attached SCSI disk
>
> Is this log snippet preceded by lines with "Sense Key" or "Add.
> Sense" ?
>
No. Those were the only lines reported. I recently lost another drive
that was attached to the same Raspberry Pi. But that one had a FAT file
system.
>
> 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 ?
>
I am on a fairly recent kernel.
pi@pi:~$ uname -a
Linux pi 4.1.16-v7+ #833 SMP Wed Jan 27 14:32:22 GMT 2016 armv7l
GNU/Linux
> -------------------------------------------------------------------
>
> 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
>
The RPi2 is a USB 2.0 only device. But yes, I think the drive is 3.0
capable.
Bus 001 Device 004: ID 0bc2:5071 Seagate RSS LLC
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x0bc2 Seagate RSS LLC
idProduct 0x5071
bcdDevice 1.55
iManufacturer 1 Seagate
iProduct 2 FA GoFlex Desk
iSerial 3 NA0K1JZA
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 32
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 2mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk-Only
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
I just hope it is not another HDD failure.
I am hoping the fsck results are reliable. I only tried the "-c" read-
only option. The other was with "-cc" which would also perform a
read/write test.
--
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
"Necessity is the mother of invention."
Attachment:
signature.asc
Description: This is a digitally signed message part