-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Thursday 2007-06-21 at 00:52 +0200, Joachim Schrod wrote:
Carlos E. R. wrote:
...I had completely forgotten 'sdparm' :-)
sdparm --command=ready /dev/sdc # check ready state sdparm --command=start /dev/sdc # start a sleeping disk sdparm --command=stop /dev/sdc # put a disk in standby sdparm -al -f /dev/sdc # list all known mode flags sdparm -6 -p po --clear=STANDBY /dev/sdc # turn off standby feature sdparm -6 -p po --defaults /dev/sdc # establish it again
I have looked at the man page, but didn't find out more. Perhaps there is another one to learn the sleep timeout.
At my disk, the sleep timeout is shown by the -alf command:
pussy:~/log # sdparm -al -f /dev/sdc /dev/sdc: Seagate FreeAgentDesktop 100D RBC device parameters (RBC) [PS=1] mode page: WCD 0 [cha: n, def: 0, sav: 0] Write cache disable LBS 512 [cha: n, def:512, sav:512] Logical block size NLBS 0x3a386030 [cha: y, def:0x3a386030, sav:0x3a386030] Number of logical blocks P_P 0 [cha: n, def: 0, sav: 0] Power/performance READD 0 [cha: n, def: 0, sav: 0] Read disable WRITED 0 [cha: n, def: 0, sav: 0] Write disable FORMATD 0 [cha: n, def: 0, sav: 0] Format disable LOCKD 0 [cha: n, def: 0, sav: 0] Lock disable Power condition [PS=0] mode page: IDLE 0 [cha: n, def: 0, sav: 0] Idle timer active STANDBY 1 [cha: y, def: 1, sav: 1] Standby timer active ICT 0 [cha: n, def: 0, sav: 0] Idle condition timer (100 ms) SCT 9000 [cha: y, def:9000, sav:9000] Standby condition timer (100 ms)
The standby timer is set to 900sec (last line).
That line doesn't show in mine. It actually complains at the end: ... SESS_F 63 [cha: y, def: 63, sav: 63] Session format PACK_S 0 [cha: n, def: 0, sav: 0] Packet size
hereafter field position exceeds mode page length=12 APL 0 [cha: n, def: 0, sav: 0] Audio pause length (blocks) nimrodel:~ #
Does "sdparm -p po -l /dev/sda" output any values on your system? It does only work on my USB disks; my SATA disks output
Doesn't look too good: /dev/sda: ST360020 A 0000 Direct access device specific parameters: WP=0 DPOFUA=0
Power condition [po] mode page not supported
Power condition mode page not supported probably the stop command wouldn't work there either. (I don't want to stop one of them, they're in use. :-))
I have no sata, but in the past I did the experiment on pata: I could hear the motors spinning down, and after a few seconds they spinned up again, with perhaps a complaint from the kernel. Let me see, my hdb is not in use right now... nimrodel:~ # [...] Crash! I had a system crash just at that point, this is what I recovered of my email that served as notebook. What did I do? Well, I checked my /dev/hdb status via hdparm -C, which was "active/idle", then sent it to sleep (-y and or -Y), which it did, checked the status again, and now I'm not sure if it answered fast or took some time. A second time took a minute to answer. I think it said standby. I should have written it down on paper. However, the problem was that /dev/hda, where my home is (but not the system) stopped responding: Jun 21 01:59:54 nimrodel kernel: hdb: drive_cmd: status=0x51 { DriveReady SeekComplete Error } Jun 21 01:59:54 nimrodel kernel: hdb: drive_cmd: error=0x04 { DriveStatusError } Jun 21 01:59:54 nimrodel kernel: ide: failed opcode was: 0xe0 Jun 21 01:59:55 nimrodel kernel: hdb: drive_cmd: status=0x51 { DriveReady SeekComplete Error } Jun 21 01:59:55 nimrodel kernel: hdb: drive_cmd: error=0x04 { DriveStatusError } Jun 21 01:59:55 nimrodel kernel: ide: failed opcode was: 0x94 Jun 21 02:00:02 nimrodel kernel: hdb: drive_cmd: status=0x51 { DriveReady SeekComplete Error } Jun 21 02:00:02 nimrodel kernel: hdb: drive_cmd: error=0x04 { DriveStatusError } Jun 21 02:00:02 nimrodel kernel: ide: failed opcode was: 0xe0 Jun 21 02:00:02 nimrodel kernel: hdb: drive_cmd: status=0x51 { DriveReady SeekComplete Error } Jun 21 02:00:02 nimrodel kernel: hdb: drive_cmd: error=0x04 { DriveStatusError } Jun 21 02:00:02 nimrodel kernel: ide: failed opcode was: 0x94 Jun 21 02:00:17 nimrodel kernel: hdb: irq timeout: status=0xd0 { Busy } Jun 21 02:00:17 nimrodel kernel: ide: failed opcode was: 0xe5 Jun 21 02:00:27 nimrodel kernel: hda: lost interrupt Jun 21 02:00:47 nimrodel kernel: hda: dma_timer_expiry: dma status == 0x60 Jun 21 02:00:47 nimrodel kernel: hda: DMA timeout retry Jun 21 02:00:47 nimrodel kernel: hda: timeout waiting for DMA Jun 21 02:01:17 nimrodel kernel: hda: lost interrupt Jun 21 02:01:47 nimrodel kernel: hda: lost interrupt Jun 21 02:02:17 nimrodel kernel: hda: lost interrupt Jun 21 02:02:32 nimrodel kernel: hda: lost interrupt Jun 21 02:02:32 nimrodel kernel: hdb: status timeout: status=0xd0 { Busy } Jun 21 02:02:32 nimrodel kernel: ide: failed opcode was: 0xe5 Jun 21 02:02:32 nimrodel kernel: hdb: drive not ready for command Jun 21 02:02:52 nimrodel kernel: hda: dma_timer_expiry: dma status == 0x60 Jun 21 02:02:52 nimrodel kernel: hda: DMA timeout retry Jun 21 02:02:52 nimrodel kernel: hda: timeout waiting for DMA Jun 21 02:03:02 nimrodel kernel: hda: lost interrupt Jun 21 02:03:22 nimrodel kernel: hda: dma_timer_expiry: dma status == 0x60 Jun 21 02:03:22 nimrodel kernel: hda: DMA timeout retry Jun 21 02:03:22 nimrodel kernel: hda: timeout waiting for DMA Jun 21 02:03:32 nimrodel kernel: hda: lost interrupt Jun 21 02:03:52 nimrodel kernel: hda: dma_timer_expiry: dma status == 0x60 Jun 21 02:03:52 nimrodel kernel: hda: DMA timeout retry Jun 21 02:03:52 nimrodel kernel: hda: timeout waiting for DMA Jun 21 02:04:22 nimrodel kernel: hda: lost interrupt Jun 21 02:04:52 nimrodel kernel: hda: lost interrupt Jun 21 02:05:22 nimrodel kernel: hda: lost interrupt Jun 21 02:05:52 nimrodel kernel: hda: lost interrupt Jun 21 02:05:55 nimrodel kernel: end_request: I/O error, dev hda, sector 100834032 Now, my hda has been acting up for some time, and I suspect the 80 pin connector or cable, and I want to replace it. Thus I can not be fully sure that it coincidentally decided to act up again, or this time it was really caused by my tests (I should not have used -Y uppercase) I did try to awake both with -w: -w Perform a device reset (DANGEROUS). Do NOT use this option. It exists for unlikely situations where a reboot might otherwise be required to get a confused drive back into a useable state. But it didn't work. Actually, I go a kernel panic: Jun 21 02:05:55 nimrodel kernel: ------------[ cut here ]------------ Jun 21 02:05:55 nimrodel kernel: kernel BUG at drivers/ide/ide.c:1382! Jun 21 02:05:55 nimrodel kernel: invalid opcode: 0000 [#1] Jun 21 02:05:55 nimrodel kernel: last sysfs file: /block/sda/size ... and the system stopped with caps lock and scroll lock blinking. Power down and boot, and reboot (no network the first time) Well... a kernel bug is a kernel bug. I assume I should report it to bugzilla. Interesting times :-} - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFGekhitTMYHG2NR9URAqEPAJoCJu4sQ4IY9+OvCJbdG19Z/p+/3wCfd+xq 3crjQdD71vht3U+NMvDinoY= =06Vj -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org