Jurgen, I'm unsure whats happened these last hours. I've disabled a fetchmail service which occasionally did some logging on the disks (approx 180 sec interval - caused by a DNS error) and went for dinner.
When I returned a small miracle happened: the power usage fell to 28.7 Watt. So the disks must be standby. It works!!! My preliminary conclusion is that you can't trust the disk timer of these disks. No clue why. 60secs just don't seem to be 60 secs..... Or there is something wrong in the ata driver code. Which I very much doubt... Further testing shows that a standby=60 actually takes approx 600secs. Weird. Very weird. And a standby=6 also takes approx 600 secs.... What I've learned: - make really sure there is no i/o on the disks - for a long period (iostat -d and/or zpool iostat must read 0) - wait much longer than the standby period to make sure the disk go to standby - a power supply takes some time (a minute or so) to adopt to the lower demand. I think I leave it for now - my goal is reached. I've learned much from you and I really want to thank you for your support. I''l make some inquiries at WesternDigital.... Regards, Tom. J?rgen Keil wrote: >> Sofar I concluded: >> - I need to make sure that the IDLE command is actually send to the >> drives -> need to add some debug code to the driver. >> This looks feasable. > > You could try to verify that ata_disk_set_standby_timer is > called by using kmdb. Boot with options "-kdvs", and at the > kmdb prompt: > > ::bp ata`ata_disk_set_standby_timer > :c > > > This should stop during boot at the ata`ata_disk_set_standby_timer > function. The command ":c" continues. For your ata flash drive > and two s-ata drives on the via controller I expect that it stops > three times at the breakpoint, before we reach the single user > prompt. > > Instead of using ":c" after it has stopped at > ata`ata_disk_set_standby_timer you can also > use the key [ (shortcut for the "::step over" command), > to trace through the ata_disk_set_standby_timer code. > > Near the end of the function it should step over a > "call .. <ata^ata_command>" instruction. > > After that call, you can check the return value > from the ata_command function call by looking > at the cpu register "eax" (if you're using the 32-bit > kernel; for the 64-bit kernel it's "rax"): > > <eax=X > or > <rax=X > > Return value of 0 would be a failure, anything != 0 is OK. > > > Btw. I just tried the procedure in a virtualbox environment, > and apparently the virtual ide controller in virtualbox does not > like the IDLE command; when I ::step over the > "call <ata`ata_command>" instruction, the kernel prints this > error message: > > ata_command_status 0x41 error 0x4 DRDY 0x1 CMD 0xe3 F 0x0 N 0x2 S 0x0 H 0x0 > CL 0x0 CH 0x0 > > And the return value in <eax is 0 (== failure) > -- > This message posted from opensolaris.org > _______________________________________________ > pm-discuss mailing list > pm-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/pm-discuss