[Toybox] [PATCH] acpi: change when to recurse

[Isaac Dunham]

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 at 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

 1412662171.0