On Sun, 15 Apr 2012, Martin Mokrejs wrote: > 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? Nothing wrong. > And there was nothing that the disk spun down at the very end of these two files? There was no indication in the log that the drive had spun down except when the computer tried to read the disk and had to retry. > 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. You don't seem to understand how USB works. The device (i.e., the JMicron bridge) cannot initiate a transmission to the computer. All transfers are started by the computer. So if the computer doesn't try to communicate with the bridge then there's no way for the bridge to tell it about spinning down the drive. > > 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. No, Linux will wait for about 30 seconds before aborting. In this case the JMicron bridge stopped waiting after 5 or 6 seconds. > 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). ;) The kernel did not have the short timeout; the JMicron bridge did. > > 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"? I was referring to hdparm's -S option. > It is enabled ... (the asterisk > on the line). Should the usb-to-sata bridge notify upstream or not? No; there's no way for it to do so. Alan Stern -- 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
