-----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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
