Note: there are two things here in this email ...
1. JMS539 from the usb-to-sata bridge spins down its attached disk, probably without
notifying upstream USB and maybe that also means also ignoring CONFIG_USB_SUSPEND.
2. It takes about 15 second for the 3.5" drive to spin up. If I plugin the SATA disk
directly into my eSATA port, libata or whoever does not wait 15s at all for my disk
to come up (it has a chance maybe 5 seconds to catch up?).
Alan Stern wrote:
> On Sat, 14 Apr 2012, Martin Mokrejs wrote:
>
>> I booted up 3.3.2 kernel now and ran usbmon over all USB stuff but with
>> unplugged mouse and keyboard so I hope there was nothing extra other than the USB
>> ports of the laptop itself and traffic from the USB to SATA bridge in question.
>>
>> I started up the cat command catching the usb traffic and connected the external
>> bridge with JMS539 chip.
So there was nothing wrong when the bridge gets connected at the very beginning?
And there was nothing that the disk spun down at the very end of these two files?
3.3.2_plugging_in_external_JMS539_bridge.mon.out
3.3.2_JMS539_over_TI_controller__writing-end-of-the-disk.mon.out
In both cases I waited those 10-12 minutes for the disk to spin down and only after
that I stopped usbmon. So if there is nothing like that logged then JMS539 does this
completely silently.
>>
>> The JMS539 chip decided to spin down the disk after about 13 minutes (according to
I read somewhere today on the internet it is quite know for this JMS539 chip to
spin down its attached drives ... People referred to 10 minutes.
>> the timestamp of the file touched last time by cat writing down the usbmonitored
>> data, so maybe it did not flush some stuff meanwhile?). Can't say.
>>
>> After the disk was down I ran gdisk to fetch partition table of the disk, just to
>> make the disk spin up again. Then I killed the cat command but maybe should have
>> disconnected the drive first ... to get maybe more errors into the log? ;-)
>
> The log shows that gdisk's READ command had to be issued three times.
> The first two times it failed after six and five seconds, respectively.
> Each time, the device reported Not Ready to Ready Transition. Don't
> ask me why this had to happen twice. But the third READ worked okay.
The disk had first to spin up but linux did not anticipate that at all. I think linux
waits about "10 seconds" only, otherwise and then it gives an error.
For example, here is a case on eSATA port (I know, am on a wrong list but USB behaves
the same). When I plugin an eSATA data cable to the disk, it starts spinning up
provided it had power already ... but immediately after the data cable was plugged
in kernel tries to negotiate speed. That fails because the drive is still spinning
up ... and bridge or the disk does not reply, or whatever ... Kernel gives up
after those about 10 second and logs the last 5-6 lines (see below).
In reality, at about that time the procedure was logged the drive merely reached
its normal RPM speed and could have been accessible to negotiations.
Apr 14 15:34:11 vostro kernel: ata6: hard resetting link
Apr 14 15:34:12 vostro kernel: ata6: SATA link down (SStatus 0 SControl 300)
Apr 14 15:34:17 vostro kernel: ata6: hard resetting link
Apr 14 15:34:17 vostro kernel: ata6: SATA link down (SStatus 0 SControl 300)
Apr 14 15:34:17 vostro kernel: ata6: limiting SATA link speed to 1.5 Gbps
Apr 14 15:34:22 vostro kernel: ata6: hard resetting link
Apr 14 15:34:22 vostro kernel: ata6: SATA link down (SStatus 0 SControl 310)
Apr 14 15:34:22 vostro kernel: ata6.00: disabled
Apr 14 15:34:23 vostro kernel: ata6: EH complete
Apr 14 15:34:23 vostro kernel: ata6.00: detaching (SCSI 5:0:0:0)
Apr 14 15:34:23 vostro kernel: sd 5:0:0:0: [sdd] Synchronizing SCSI cache
Apr 14 15:34:23 vostro kernel: sd 5:0:0:0: [sdd] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
Apr 14 15:34:23 vostro kernel: sd 5:0:0:0: [sdd] Stopping disk
Apr 14 15:34:23 vostro kernel: sd 5:0:0:0: [sdd] START_STOP FAILED
Apr 14 15:34:23 vostro kernel: sd 5:0:0:0: [sdd] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
The "10s" are enough for 2.5 disk but NOT for 3.5" disk (or at least this one). I think
about 15s are ok.
So, back to the 3 attempts gdisk had to make. Those first two were useles but kernel
didn't know the disk is not spinning. Then, the gdisk wouldn't have to wait.
I don't have a problem with the first two attempts being lost, I understand why that
happened. Why kernel doesn't know that or why it has so short timeout that is another
issue (maybe an issue). ;)
>
> My guess is that the bridge didn't spin down the drive. Probably the
> drive spun down all by itself. There's an automatic spin-down delay
> time that you might be able to set using hdparm.
You mean the "Power Management feature set"? It is enabled ... (the asterisk
on the line). Should the usb-to-sata bridge notify upstream or not?
# hdparm -I /dev/sdc
/dev/sdc:
ATA device, with non-removable media
Model Number: ST3000DM001-9YN166
Serial Number: Z1F0JN1W
Firmware Revision: CC4C
Transport: Serial, SATA Rev 3.0
Standards:
Used: unknown (minor revision code 0x0029)
Supported: 8 7 6 5
Likely used: 8
Configuration:
Logical max current
cylinders 16383 16383
heads 16 16
sectors/track 63 63
--
CHS current addressable sectors: 16514064
LBA user addressable sectors: 268435455
LBA48 user addressable sectors: 5860533168
Logical Sector size: 512 bytes
Physical Sector size: 4096 bytes
Logical Sector-0 offset: 0 bytes
device size with M = 1024*1024: 2861588 MBytes
device size with M = 1000*1000: 3000592 MBytes (3000 GB)
cache/buffer size = unknown
Nominal Media Rotation Rate: 7200
Capabilities:
LBA, IORDY(can be disabled)
Queue depth: 32
Standby timer values: spec'd by Standard, no device specific minimum
R/W multiple sector transfer: Max = 16 Current = ?
Advanced power management level: 128
Recommended acoustic management value: 208, current value: 0
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=120ns IORDY flow control=120ns
Commands/features:
Enabled Supported:
* SMART feature set
Security Mode feature set
* Power Management feature set
* Write cache
* Look-ahead
* Host Protected Area feature set
* WRITE_BUFFER command
* READ_BUFFER command
* DOWNLOAD_MICROCODE
* Advanced Power Management feature set
SET_MAX security extension
* 48-bit Address feature set
* Device Configuration Overlay feature set
* Mandatory FLUSH_CACHE
* FLUSH_CACHE_EXT
* SMART error logging
* SMART self-test
* General Purpose Logging feature set
* WRITE_{DMA|MULTIPLE}_FUA_EXT
* 64-bit World wide name
Write-Read-Verify feature set
* WRITE_UNCORRECTABLE_EXT command
* {READ,WRITE}_DMA_EXT_GPL commands
* Segmented DOWNLOAD_MICROCODE
* Gen1 signaling speed (1.5Gb/s)
* Gen2 signaling speed (3.0Gb/s)
* Gen3 signaling speed (6.0Gb/s)
* Native Command Queueing (NCQ)
* Phy event counters
* unknown 76[15]
DMA Setup Auto-Activate optimization
Device-initiated interface power management
* Software settings preservation
* SMART Command Transport (SCT) feature set
* SCT LBA Segment Access (AC2)
unknown 206[7]
unknown 206[12] (vendor specific)
unknown 206[13] (vendor specific)
Security:
Master password revision code = 65534
supported
not enabled
not locked
not frozen
not expired: security count
supported: enhanced erase
326min for SECURITY ERASE UNIT. 326min for ENHANCED SECURITY ERASE UNIT.
Logical Unit WWN Device Identifier: 5000c50040280782
NAA : 5
IEEE OUI : 000c50
Unique ID : 040280782
Checksum: correct
#
Thank you for all your time Alan, really.
Martin
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
