> > Is somebody able to post a little example how to > get > > such a pm-info for one disk? > > I don't need a detailed comment for everything, > just > > some lines of code to play with. > > > > for example i would like to know the idle time ( > > PM_GET_TIME_IDLE ) of disk "/dev/dsk/c0t1d0" .. > > See http://www.smart.net/~rlhamil/pm_status.c > for something that _maybe_ does what you want. The > output isn't > pretty, I don't think I know what I'm doing, and some > of it doesn't make > much sense to me. But some of it does, and it didn't > core dump for me. > So maybe it works. If it does, suggestions on how to > pretty it up (not the least > of which would be a reasonably easy way to find more > recognizable names, like c#t#d# > for disks) might be in order, or someone could just > take it from here and post the > results. > > To anyone else that reads this more that a few weeks > after the date posted: > I don't promise that URL will remain valid forever!
Ok, I tried to fetch one (well, two) more items of info, namely the descriptive names of the power levels (the component names, along with these, can be viewed buried in prtconf -v output). For some reason, the PM_GET_POWER_NAME ioctl would sometimes fail with EINVAL for the full power value. Modified version at http://www.smart.net/~rlhamil/pm_status2.c I'd be interested if anyone can tell me why that's failing when prtconf -v shows a corresponding name available. e.g. prtconf -v shows scsi, instance #1 Driver properties: name='pm-components' type=string items=4 dev=none value='NAME=glm1' + '0=Off (PCI D3 State)' + '1=Coma(PCI D2 State)' + '3=On (PCI D0 State)' but the corresponding output from my program is scsi(1): /[EMAIL PROTECTED],700000/[EMAIL PROTECTED],1 glm1 cur=0[Off (PCI D3 State)] full=3 idle=1647261 (note no name following full=3), and the corresponding line of the truss for the ioctl that failed is 23517/1: ioctl(3, 0x001A, 0xFFBFE2F8) Err#22 EINVAL I figure either I'm incorrectly initializing the pmreq struct, or there's a bug in the pm driver; not sure which, since this stuff _really_ isn't documented! Although I suspect the latter, since for those that work, it seems to fetch the correct value. Sometimes it would of course also fail to fetch the current power value, when that equalled the full power value. But in other cases, it had no trouble fetching both. In no case would it succeed for the greater value but fail for the lesser (assuming they were different), which is one of the reasons I think it may not be my bug, but rather a problem with boundary cases in .../usr/src/uts/common/io/pm.c or something it calls or refers to. This message posted from opensolaris.org _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
