On Mon, Oct 06, 2014 at 06:28:16PM -0500, Rob Landley wrote: > On 10/06/14 17:23, Isaac Dunham wrote: > > On Mon, Oct 06, 2014 at 12:36:08AM -0500, Rob Landley wrote: > >> My LCD has a cooling device? Really? > >> > >> Ok, it's got a max state of 9 and a cur state of 0. Meaning...? > > > > /sys/class/thermal contains fans, and all the things that can *readily* be > > throttled back to cut power (ie, LCDs and CPUs). > > > > For a CPU, the CPU speed steps are numbered, with 0 as "slow as possible" > > and max_state corresponding to the maximum speed. > > > > Ostensibly, LCD max brightness is max_state; dimmest (or is it off?) > > is cur_state=0. > > In reality, many laptops are wired backwards, so max_state actually means > > the dimmest state possible for them. > > > > ...Do you have anything in /sys/class/pwm? > > $ ls /sys/class/pwm > ls: cannot access /sys/class/pwm: No such file or directory > > Same on both boxes. Thanks. pwm is the method used for fan control on many systems, and I was wondering if fans sometimes show up there. It sounds like they don't.
> >> (Devices 0 and 1 are both "Processor" and cur_state 0, one has max state > >> of 3 the other 10.) > >> > >> So... yay thermal. That's easy to recurse on, but all we do is print out > >> the numbers? > > > > Believe it or not, that's all we do. > > After all, any interpretation *will* be wrong somewhere. > > Lovely. > >> (And yes, give it its own dirtree callback function. If !parent then > >> recurse following symlinks, otherwise openat() cur_state max_state and > >> type relative to dirtree_parentfd().) > > > > For temperature, we'll need to recurse through more of /sys/class; > > my phone has a temperature sensor on its battery, and there's no telling > > where else we might find one. > > That means > > if (!tree->parent || !tree->parent->parent) > > return DIRTREE_RECURSE|DIRTREE_SYMFOLLOW; > > Reasonable. > >>>>> The above method does ignore quite a few sensors; > >>>>> there's no obvious way to get HDD temps besides these commands: > >>>>> smartctl -A -d ata /dev/sda |grep Temperature > >>>>> # or (Hitachi-only, but no spin-up) > >>>>> hdparm -H /dev/sda > >>>> > >>>> strace, the breakfast of champions. > >>> > >>> Yes, I've tried that and ltrace. > >>> hdparm calls ioctl(fd, SG_IO, ...) with a very large struct that I haven't > >>> figured out. > >> > >> SG_IO sounds like it's sending its own scsi command. Possibly: > >> > >> http://www.t10.org/lists/2op.htm > >> > >> I can dig down into the kernel and try to reverse engineer it... Ah, > >> there's docs: > >> > >> http://tldp.org/HOWTO/SCSI-Generic-HOWTO/sg_io.html > >> http://tldp.org/HOWTO/SCSI-Generic-HOWTO/pexample.html > >> > >> Lots of docs: > >> > >> http://sg.danny.cz/sg/sg_io.html > > <snip> > >> There are standard scsi commands for basic status info, which are > >> repeated in a bunch of places (such as the wikipedia page about scsi). > > > > hdparm -H is supposedly a Hitachi-specific extension, which is > > preferable to the standard way because it doesn't spin up the disk to read > > temperature. > > Indeed, but the hitachi-specific extension is probably just a custom > scsi command packet. (It has to send a packet to talk to the onboard > electronics. Whether they decide to spin up the disk is their call.) > > > I'm inclined to avoid reading the disk temperature via scsi commands. > > It would make for a bit of a mess and could have "surprising" effects on > > time you can run on battery, depending on the disk vendor. > > I happily leave this to you, dunno enough about it to have an opinion. > > > Now if someone decided to write a driver that can export it to sysfs, > > I would be fine with reading that. > > That sounds like a question for James Bottomley. > > >> That would actually be a fun thing to try thermal sensor stuff on, > >> because the reason I know it has an overheating problem is dmesg says > >> "thermal limit reached, processors throttled" when I leave it doing a 3 > >> hour build. > > > > Much better than my Thinkpad. > > Back in ~2009-2010 (late netbook craze era) AMD decided to put one of its > > processors in the "mobile" market; it was higher power use than the Atom, > > but it was (a) 64-bit, (b) AMD, (c) faster in terms of real performance, > > and (d) had virtualization support. > > Yes. AMD-C60. that's what's in my netbook. No. AMD Neo, which is older, higher power, and hotter than the C60. (They basically rebranded one of their lowest power designs as the Neo. Then they did a series of special mobile designs.) > > Besides that, it came with a Radeon GPU, instead of Poulsbo. > > So when I found that out that Lenovo had made a cheap 11.6" laptop with > > that, > > I went for it. > > And I went for the dual-core version. > > It's craptacular, isn't it? > > Acer Aspire one 722 here. It manages to be _slower_ than the Atom (even > before you take the 2 way vs hyperthreaded 4-way in that my D255E-1802 > had) but it can take 8 gigs of ram and the atom maxes at 2. I'm comparing the Atom N270 to the Neo, and one core of a Neo@800MHz builds stuff faster than both threads of the Atom N270 (which is single-core but hyperthreaded.) >From what I understand, AMD performance per clock has been going downwards. Meanwhile, the Atoms have been getting better--the early Atoms saved power partly by leaving out all the performance optimizations. I have oone of the ones that ran like crap. > > The sole problem is that the fan wasn't quite enough for a single-core; > > it would frequently shut down when I tried to do something like build > > a kernel. > > Acer manages to cool it just fine. The fan seldom even comes on. > Possibly mine's lower GHz. Slightly lower, and the next generation. > > (If I would blow out the fan, lock it in "powersave" mode at 800 MHz, > > set the fan to full-speed, and run it with make -j1 at nice 19 or 20, > > it would "only" get to the mid-80 degree C range. Thermal shutdown is > > 92 C.) > > That's... sad. > > >> Hmmm... > >> > >> $ ls /sys/class/thermal > >> cooling_device0 cooling_device3 cooling_device6 thermal_zone0 > >> cooling_device1 cooling_device4 cooling_device7 > >> cooling_device2 cooling_device5 cooling_device8 > >> > >> $ ls /sys/class/thermal/thermal_zone0 > >> device passive power temp trip_point_0_type uevent > >> mode policy subsystem trip_point_0_temp type > > > > thermal_zone0 is probably the fan. > > Speaking of which, do you have a fan driver that allows setting fan speed? > > Maybe? The entire bottom back strip of this netbook seems to be a giant > heat sink (gets a bit warm on the knees in shorts when doing > cpu-intensive stuff) so the fan doesn't come up much. If I listen at the > ethernet port it's got one running, though. Dunno what would make it go > faster. > (The System76 meanwhile is hissing like an annoyed cat. I have sometimes > forced all the processors to 1.7ghz and locked there to get the fans to > shut up.) > > > See previous comment about backlights being wired backwards. > > Indeed. My main concern here is not knowing what the requirements are > for this command (there being no spec), but if "spit out the raw data > from /sys" is enough of a mandate, by all means... > > Incidentally... > > I was thinking that I might need to use glob() in the callback for the > > Thinkpad temperatures. > > But it seems that I could just do > > err = glob("/sys/class/*/*/temp", 0, NULL, &pglob); > > glob("/sys/class/*/*/temp*_input", err?GLOB_APPEND:0, NULL, &pglob); > > > > And check if there are any matches. > > I'm not sure what you're trying to do here, but it seems unlikely that > you'd need dirtree _and_ glob here? temp*_input is standard form for hwmon/thinkpad_acpi temperature sensors. Per ltrace, acpi will sprintf() the right number into a buffer. I had been pondering how to read multiple ones, and the thought of using glob() crossed my mind; then I realized that I can just use glob() and skip dirtree_read() altogether for acpi -t. This does sound appealing, because it's a fixed depth. Speaking of which, I think it would be possible to completely replace dirtree_read() in acpi with glob(). In the end, acpi -a and -b use dirtree_read() as a longer way of writing: glob("/sys/class/power_supply/*",0, NULL, &globbuf) for (i=0; i<globbuf.gl_pathc; i++) { if (0 <= (dfd = open(globbuf.gl_pathv[i], O_RDONLY))) { //main body of acpi_callback goes here done: close(dfd); } } if (globbuf.gl_pathc) globfree(&globbuf); By my reckoning, glob() would be ~9 lines shorter per callback, plus much simpler handling of hwmon-type sensors. I've written a non-hwmon-aware version of -t, but it needs to be fixed to avoid the assumption that all relevant nodes are symlinks. ... Now that I look at what glob pulls into a static binary, I'm not sure about using it. For a standalone binary equivalent to 'acpi -t' I get a binary that's 246120 bytes unstripped, with 144 functions. sstrip'd it's 49292 bytes, which is not much larger than acpi is. > > Thanks, > > Isaac Dunham > > Rob Isaac Dunham _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
