Re: Problems with CPU throttling on HP 15-n066us laptop

[Ian Smith]

On Sat, 20 Aug 2016 09:50:22 -0400, am_d...@fastmail.fm wrote:
 > On Thu, Aug 18, 2016, at 09:14 AM, Anthony Jenkins wrote:
 > > Try this patch, that's what I'm running.

 > I applied this patch to the latest 11 source and built my kernel and now
 > I have cpu throttling on the AMD machine. I see the Cool'n'Quiet 2.0
 > driver attach and have frequencies in dev.cpu. The fans now run at a
 > much lower speed and I am saving upwards of 4 watts when running on
 > battery power. Thank you so much for this patch and to everyone else for
 > the suggestions on this issue. It is such a great feeling to know that
 > now I can use FreeBSD on my new laptop.

That's great news.  More good work, Anthony.

Is there a PR for this issue/fix?  It would be good to see this patch 
reviewed and headed into the tree, no?

cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: Problems with CPU throttling on HP 15-n066us laptop

[Ian Smith]

On Thu, 18 Aug 2016 06:07:45 -0400, am_d...@fastmail.fm wrote:
 > On Thu, Aug 18, 2016, at 03:46 AM, Konstantin Belousov wrote:
 > > On Wed, Aug 17, 2016 at 10:50:12PM -0400, am_d...@fastmail.fm wrote:
 > > > Hello,
 > > > I purchased a new laptop for FreeBSD and am having some problems with
 > > > CPU throttling. This laptop has an aMD a10-5745m processor. I cannot
 > > > start powerd and the frequency levels in dev.cpu are absent. I tried

Just to clear up any confusion: Adam Pribyl noted that "throttling" is 
disabled in 10(+) but that refers only to "relative" cpufreq drivers, 
p4tcc and acpi_throttle, whereas your main problem appears to be that 
cpufreq(4) isn't attaching at all, so there's no a) control over and b) 
no ability to read, let alone set, cpu.0.freq.

I don't know much about recent AMDs, but you mention Cool'n'Quiet, 
otherwise refered to in acpi(4) as:  [ note: reading stable/9 manpage]
  powernow   AMD PowerNow! and Cool'n'Quiet for K7 and K8
but again, these are subsidiary drivers to cpufreq(4).

 > > > with 11 and when that didn't work, I upgraded to Current. The laptop is
 > > > running very hot and the fans are often running at a high speed so I
 > > > think the cpu is running near full speed.  This is the only issue I am
 > > > having in general use of the laptop. I will include the url for my asl
 > > > below as well as the output of dmesg after boot -v and sysctl hw.acpi. I
 > > > noticed messages like "acpi_ec0: EcCommand: no response to 0x84" near

Yes, that stuck out.  I don't know whether it might be related to this.

 > > > the bottom of the dmesg but honestly don't know enough about acpi to say
 > > > whether this could be causing the problem. I tried Googling the error
 > > > and found people who seemed to be having trouble with temperature
 > > > readings and battery status. For me, the battery status is working fine
 > > > when I check it via acpiconf although I did notice some unusual
 > > > temperature readings in the dmesg output. There are some other

The only mentions are 3 of 'acpi_tz0: _CRT value is absurd, ignored (255.1C)

I don't know where the '.1' comes from, but hw.scpi.thermal shows:

hw.acpi.thermal.tz0._CRT: -1
hw.acpi.thermal.tz0._HOT: 100.1C
hw.acpi.thermal.tz0._PSV: 96.1C
hw.acpi.thermal.tz0.thermal_flags: 0
hw.acpi.thermal.tz0.passive_cooling: 1
hw.acpi.thermal.tz0.active: -1
hw.acpi.thermal.tz0.temperature: 46.1C

-1 = 255, which is surely not a useful critical shutdown temperature, 
indeed your laptop would be a pool of molten plsstic, probably with a 
nasty Li-ion battery fire/explosion as a topping, long before then.

FreeBSD doesn't actually use _HOT as far as I know, unsure about 11|12
!sysctl -d hw.acpi.thermal.tz0._HOT
 hw.acpi.thermal.tz0._HOT: too hot temp setpoint (suspend now)

But I don't believe it works.  Other(?) texts indiccte that should cause 
S4 (suspend to disk aka hibernation) but we don't support S4 at all, so 
if it does get too hot, you'll be relying on passive cooling cutting in 
at 96.1C (again, what's with this '.1'?) and I'm not sure if that can 
even happen without first using cpufreq?

 > > > temperature readings that appear in sysctl but I would have to study
 > > > them more during a work session to see if they remain reasonable. Thanks
 > > > in advance for any help.
 > > > 
 > > > 
 > > > asl url: http://pasted.co/5770b687
 > > > 
 > > > boot-v output: http://pasted.co/c8e9fb89
 > > > 
 > > > hw.acpi output: http://pasted.co/cc611266
 > > 
 > > It is more useful to show sysctl dev.cpu.  I suspect your bios
 > > reports C-states in a way which we do not parse properly.

Well it looks like C2 is being used 70-80% of the halt time, so I'm not 
sure that's so much of an issue, compared to cpufreq not attaching?

I don't know if it would provide more info on a verbose boot, but you 
might try setting, in /boot/loader.conf:

hw.acpi.verbose=1
debug.cpufreq.verbose=1
debug.hwpstate_verbose=1# also an AMD thing i think?

 > > I am not aware of AMD-specific analog for the Intel' document 'Processor
 > > Vendor-Specific ACPI Interface Specification'. If somebody has a pointer
 > > to AMD version and wants to test, I am willing to code that.

 > I will include the output of dev.cpu below. One observation that I made
 > is that it seems that the Cool'n'Quiet driver is not attaching. I used
 > FreeBSD on a laptop with a newer apu once which was the amd a4-5000 from
 > the Kabini generation and the Cool'n'Quiet 2.0 driver attached on that
 > machine. I would be willing to perform any testing that you would find
 > helpful.

Most likely cpufreq(4) also attached on that one too, and first?

 > output from dev.cpu:
 > dev.cpu.3.cx_method: C1/hlt C2/i
 > dev.cpu.3.cx_usage_counters: 2260 5108
 > dev.cpu.3.cx_usage: 30.67% 69.32% last 2992us
 > dev.cpu.3.cx_lowest: C8
 > dev.cpu.3.cx_supported: C1/1/0 C2/2/100
[..]
 > dev.cpu.2.cx_usage: 30.74% 69.25% last 1038us
[..]
 > dev.cpu.1.cx_usage: 22.77% 77.22% last 568us
[..]
 > dev

Re: Suspend to RAM problem

[Ian Smith]

On Sat, 23 Apr 2016 00:42:11 +0200, Michael Freisinger wrote:
 > Hi Ian,
 > Thank you very much for your answer.

I think you need advice from someone more conversant with FreeBSD 10.x 
.. I'm still running 9.3 until the broken loadavgs issue gets fixed, but 
that's another story.

I booted a 10.3 memstick in LiveCD mode for some tests tonight though ..

 > > Since it's based on 10.3, I'd suggest booting from a 10.3 CD or memstick
 > > in "Live CD" mode and testing suspend / resume from there, just to rule
 > > out any possible differences with the FreeNAS configuration?  If this
 > > problem then persists, people can test against a more familiar baseline.
 >
 > I tested my system with the Live CD mode. The result is the following:
 > After the command acpiconf -s 3 command the system is starting to suspend.
 > At least I think it is, because there are some suspend messages (very less
 > than with freenas).

You'll see a lot more of those having booted verbose, see below.

 > After that the display signal stops and the power button of my system 
 > is blinking. This state is stable.

Sounds right.

 > Then I sent a WOL-Package or press the power button and the blinking 
 > stops and it seemed that the system is resuming. However the display 
 > doesn't get a signal. So I have to do a hard reset to see anything. 
 > After this the system is booting normally, of course.

There's been a lot about missing video on resume, but I thought most of 
that had been resolved by now.  Hopefully somebody can advise?
 
 > I have to mention that I booted the Live CD from an USB stick. 
 > Perhaps the USB devices are not available directly after resuming, so 
 > the boot device is not available (I heard about this problem from 
 > another user).

I was going to say that I thought it would have been running from a 
memory filesystem in that mode, or that resuming from USB disks as root 
fs might have been fixed, but no, that's right, and while it seems to 
come back and you can eg 'ls -l /' ok, trying to read any file fails, 
and some userland utilities work, while some fail.

 > Finally I think my system supports the s3 mode correctly, so probably 
 > the freenas configuration is the reason for my problem.

Possibly, though you'll want to get the no video on resume issue sorted.

 > > Have you tried it without (from your sysctl hw.acpi)
 > > hw.acpi.handle_reboot: 1 ?
 > 
 > I think I don't understand your proposal right. Should I set
 > hw.acpi.handle_reboot to 0? Where can I do this?

Actually hw.acpi.handle_reboot=0 is the default, so maybe FreeNAS set 
that to 1?  In which case, that might be (part of?) the problem there? 
Generally, most sysctls can be set while running except loader tunables. 

% sysctl -d hw.acpi.handle_reboot
hw.acpi.handle_reboot: Use ACPI Reset Register to reboot
But I don't know what that really means :)

 > Have you tried with the advice from (online) section 11.13.2.2, namely:
 > >  # sysctl debug.bootverbose=1
 > >  # sysctl debug.acpi.suspend_bounce=1
 > >  # acpiconf -s 3
 >
 > The first and the second command work fine (the value are set to 1).
 > However when I enter the acpiconf command the behavior is unchanged (the
 > system is starting the suspend process and restarts directly). Did I do
 > something wrong?

No, that's what's supposed to happen .. everything in the suspend/resume 
path occurs except the actual suspend.  I don't know if anything useful 
would turn up in dmesg (or in /var/log/messages, which is about the same 
thing, with timestamps).  /var is on an md filesystem, so it's rw.

 > If nothing more informative turns up soon, you might want to add or
 > > point to a dmesg from booting in verbose mode.  From what's there now, I
 > > don't know whether these may be significant?
 > 
 > > ACPI Error: [\134_SB_.PCI0.XHC_.RHUB.HS11] Namespace lookup failure,
 > > AE_NOT_FOUND (20150515/dswload-219)
 > > ACPI Exception: AE_NOT_FOUND, During name lookup/catalog
 > > (20150515/psobject-233)
 > >
 > 
 > Could you tell me the necessary commands to do this?

On booting from the memstick, hit space on the FreeBSD boot menu (to 
stop the countdown) then select 'configure boot options' and set verbose 
booting on.  Then backspace to the menu and hit enter to boot.

Dominic asked if you could ssh in.  I tried 'service sshd onestart' 
after booting but sshd needs to write its initial keys but can't to the 
readonly / fs, so fails to start.  I don't know a workaround for that.

What I do is mount (rw) a small partition I have for such purposes on 
the HD, so I can write dmesg, sysctl -a and other stuff to the HD for 
later inspection.  You could instead mount another USB stick for that, 
though best unount it before trying suspend.

I did 'dmesg >/thatdisk/dmesg.presuspend' which wrote the full verbose 
dmesg, and then after suspend/resume - despite that I couldn't do much 
locally anymore - 'dmesg >/thatdisk/dmesg.postsuspend' worked, including 
the extra suspend/resume messages.

But that 

Re: Suspend to RAM problem

[Ian Smith]

On Thu, 21 Apr 2016 23:03:05 +0200, Michael Freisinger wrote:
 > Hello,
 > 
 > I've built up a NAS system with the following hardware:
 > 
 > - Mainboard: ASUS B150M-K D3 LGA1151
 > - CPU: Intel BX80662G4400 Prozessor
 > - RAM: 2x 8GB Kingston ValueRAM DDR3-1600 DIMM CL11 Single
 > 
 > As OS I'm using FreeNAS V9.10 that is based on FreeBSD.

FreeBSD 10.3-RELEASE #0 f935af8(freebsd10): Mon Apr 18 10:58:36 PDT 2016
r...@build.ixsystems.com:/tank/home/nightlies/build-freenas9/_BE/objs/tank/home/nightlies/
 build-freenas9/_BE/trueos/sys/FreeNAS.amd64 amd64

Since it's based on 10.3, I'd suggest booting from a 10.3 CD or memstick 
in "Live CD" mode and testing suspend / resume from there, just to rule 
out any possible differences with the FreeNAS configuration?  If this 
problem then persists, people can test against a more familiar baseline.

 > I'm using this OS, because it provides the possibility to encrypt my data.
 > Therefore it is necessary to enter a passphrase to unlock my hard drives
 > after each reboot.
 > Since I don't want to run the NAS all time and I don't want to enter the
 > passphrase for each access, the suspend to RAM mode is very important for
 > me.
 > 
 > And here is my problem:
 > When I execute the command "acpiconf -s 3" the system is starting to
 > suspend. However after a while (just a few seconds) the system is rebooting
 > (ASUS boot screen is displayed) and I have to type in the passphrase again.
 > 
 > I already tried to fix this with your description from chaptor "11.16.3.5
 > System Powers Up After Suspend or Shutdown", but without success.

It's section 11.13.2.5 in the current online Handbook.

Have you tried it without (from your sysctl hw.acpi)
hw.acpi.handle_reboot: 1 ?

Have you tried with the advice from (online) section 11.13.2.2, namely:
 # sysctl debug.bootverbose=1
 # sysctl debug.acpi.suspend_bounce=1
 # acpiconf -s 3

 > I attached some logs. I thing the names are self-explanatory.
 > The  ACPI Source Language file can be found here:
 > https://dl.dropboxusercontent.com/u/17336975/root-ASUSB150M-KD3LGA1151.asl
 > 
 > If you need further logs or information, please contact me.

If nothing more informative turns up soon, you might want to add or 
point to a dmesg from booting in verbose mode.  From what's there now, I 
don't know whether these may be significant?

ACPI Error: [\134_SB_.PCI0.XHC_.RHUB.HS11] Namespace lookup failure, 
AE_NOT_FOUND (20150515/dswload-219)
ACPI Exception: AE_NOT_FOUND, During name lookup/catalog (20150515/psobject-233)

cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: ACPI CMOS and HP laptops

[Ian Smith]

On Fri, 19 Feb 2016 19:03:17 -0500, Anthony Jenkins via freebsd-acpi wrote:

Hi Anthony,  It's been nearly 11 months, I see.

 > Just got another HP laptop and it also needs support for the ACPI CMOS device
 > to suspend/resume, power down, etc.  Simple enough to plop my patch into my
 > -CURRENT tree and get it working.  So what again do I need to do to get this
 > committed to -CURRENT?

Is there a PR with your latest patch?  Does it apply also to stable/10?  

cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: Regarding Wake On USB input from S3 Sleep

[Ian Smith]

On Sat, 13 Feb 2016 11:17:31 -0800, Luke wrote:
 > > I searched the wiki on 'USB power' but noticed only sections 4 and 10 of 
 > > https://wiki.freebsd.org/TuningPowerConsumption seemed to relate at all.  
 > > If that's it or not, I'd appreciate some more guidance ..

 > That's correct, section 10 from that wiki page.
 > Here's all I did:
 > 
 > $ sudo usbconfig
 > (it then lists all USB related devices)
 > $ sudo usbconfig -d 1.3 power_save
 > (then put a device into powersave mode. I put this in a script)
 > 
 > and that was it for me. The zenbook almost imediately reports an extra
 > hour of battery and I can confirm it does indeed extend it's life to
 > close to an hour.

Ah, right.  Mine (6 uhci and 2 ehci root hubs) are all already in 
pwr=SAVE mode, except for the so far unused webcam:

ugen3.2:  at usbus3, cfg=0 
md=HOST spd=HIGH (480Mbps) pwr=ON (100mA)

Setting that to power_save saved about 150mW, or 30mA at 5V.  Only a few 
extra minutes (~2%) of battery life, but every little bit helps, thanks.

Not that that's really anything to do with the $subject ..

cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: Regarding Wake On USB input from S3 Sleep

[Ian Smith]

On Fri, 12 Feb 2016 08:49:46 -0800, Luke wrote:
 > I think it was just a few sysctl calls I found on the FreeBSD wiki to
 > poweroff USBs. I can look once I get home if needed.
 > 
 > Luke
 > 
 > -- 
 >   l k
 >   lu...@fastmail.fm
 > 
 > On Fri, Feb 12, 2016, at 08:34 AM, Ian Smith wrote:
 > > On Thu, 11 Feb 2016 07:27:50 -0800, Luke wrote:
 > > 
 > >  > I am VERY new to this but was just doing some hacking on my laptop
 > >  > (zenbook) and found if I poweroff my USBs (while the rest of the machine
 > >  > is still being used) I gain an hour of battery life.
 > > 
 > > What exactly do you do to accomplish that?

I searched the wiki on 'USB power' but noticed only sections 4 and 10 of 
https://wiki.freebsd.org/TuningPowerConsumption seemed to relate at all.  
If that's it or not, I'd appreciate some more guidance ..

thanks, Ian
___
freebsd-acpi@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: Regarding Wake On USB input from S3 Sleep

[Ian Smith]

On Thu, 11 Feb 2016 07:27:50 -0800, Luke wrote:

 > I am VERY new to this but was just doing some hacking on my laptop
 > (zenbook) and found if I poweroff my USBs (while the rest of the machine
 > is still being used) I gain an hour of battery life.

What exactly do you do to accomplish that?

cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: Regarding Wake On USB input from S3 Sleep

[Ian Smith]

On Thu, 11 Feb 2016 13:16:48 +0100, Hans Petter Selasky wrote:
 > On 02/11/16 13:08, Dee Zay wrote:
 > > Hello,
 > > 
 > > So, is the BIOS handover to the USB stack a prerequisite when resuming from
 > > standby mode HC (not completely off HC)?
 > 
 > Hi,
 > 
 > I'm not sure. You'll have to find out. It is what happens when you suspend
 > which decides if you get the resume event or not. Once resumed the system
 > will manage somehow, either full reset or handover.
 > 
 > > In other words, do we need to implement BIOS handover before we can use
 > > wake on usb keyboard input?
 > 
 > Might depend on the BIOS make. I've never tested this on FreeBSD before so I
 > don't know.
 > 
 > > Or is there a workaround for this specific functionality?
 > 
 > Maybe check what Linux is doing.

Do you have any rough idea of the difference in battery power used in S3 
with HC(s?) running, or in standby, or off?  Depending on hardware of 
course, but I'm just wondering how relatively significant it might be?

cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: AMD A12-8800B ACPI questions (turbo mode, temp zones)

[Ian Smith]

On Tue, 15 Dec 2015 10:05:36 -0500, Johannes Dieterich wrote:
 > thanks for the response!
 > 
 > On Tue, Dec 15, 2015 at 9:15 AM, Ian Smith  wrote:
 > > On Sun, 13 Dec 2015 19:53:52 -0500, Johannes Dieterich wrote:
 > >  > Dear list,
 > >  >
 > >  > I am running CURRENT on an HP elitebook 745 G3 which comes with a AMD
 > >  > A12-8800B CPU. All in all, it runs very well with just a few nits to
 > >  > pick. Two of them are ACPI related.
 > >  >
 > >  > 1) there are 5 thermal zones defined out of which only two provide
 > >  > reasonable numbers it seems:
 > >  >
 > >  > hw.acpi.thermal.tz4.temperature: 34.1C
 > >  > hw.acpi.thermal.tz3.temperature: 0.1C
 > >  > hw.acpi.thermal.tz2.temperature: 0.1C
 > >  > hw.acpi.thermal.tz1.temperature: 0.1C
 > >  > hw.acpi.thermal.tz0.temperature: 56.1C
 > >  >
 > >  > my gut feeling is that tz0-tz3 may be the CPU cores and tz4 would be
 > >  > the GPU (which does not work in BSD ATM, hence consistently lower
 > >  > temp). I guess this is not a big deal (everything works) but I still
 > >  > wonder how to fix it.
 > >
 > > Not sure if anything needs fixing, but I only have Intel gear these
 > > days and am not up on the AMD side of things.  However, please show:
 > >
 > > % sysctl dev.cpu

 > dev.cpu.3.cx_method: C1/hlt C2/io
 > dev.cpu.3.cx_usage_counters: 25314 20561

These are both new in 11.0, I suppose _counters shows relative use of 
each C-state per CPU, which is then reflected in:

 > dev.cpu.3.cx_usage: 55.18% 44.81% last 979us

 > dev.cpu.2.cx_usage_counters: 25676 20634
 > dev.cpu.2.cx_usage: 55.44% 44.55% last 1300us

 > dev.cpu.1.cx_usage_counters: 27544 21225
 > dev.cpu.1.cx_usage: 56.47% 43.52% last 1836us

 > dev.cpu.0.cx_usage_counters: 35013 29515
 > dev.cpu.0.cx_usage: 54.26% 45.73% last 1686us
 > dev.cpu.0.cx_lowest: C2
 > dev.cpu.0.cx_supported: C1/1/0 C2/2/400
 > dev.cpu.0.freq_levels: 2100/4717 1800/3450 1400/2320
 > dev.cpu.0.freq: 2100
 > dev.cpu.0.%parent: acpi0
 > dev.cpu.0.%pnpinfo: _HID=none _UID=0
 > dev.cpu.0.%location: handle=\_PR_.C000
 > dev.cpu.0.%driver: cpu
 > dev.cpu.0.%desc: ACPI CPU
 > dev.cpu.%parent:

OK, noting that 400ns penalty for C2 state seems quite a lot, and that 
4.7, 3.45 and 2.32W suggests a very low power usage CPU (more below).

 > > % sysctl hw.acpi.thermal
 > hw.acpi.thermal.tz4._TSP: 300
 > hw.acpi.thermal.tz4._TC2: 0
 > hw.acpi.thermal.tz4._TC1: 50
 > hw.acpi.thermal.tz4._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1
 > hw.acpi.thermal.tz4._CRT: 128.1C
 > hw.acpi.thermal.tz4._HOT: -1
 > hw.acpi.thermal.tz4._PSV: 55.1C
 > hw.acpi.thermal.tz4.thermal_flags: 0
 > hw.acpi.thermal.tz4.passive_cooling: 1
 > hw.acpi.thermal.tz4.active: -1
 > hw.acpi.thermal.tz4.temperature: 29.1C

This is interesting; it's the only one using passive cooling, and has a 
very low _PSV cut-in temperature at 55C.  I think the .1C shown with 
each of these is probably bogus, slight miscalculation?  Unless this is 
CPU temperature, I don't know how passive cooling might be applied, but 
then I don't know anything about the 8-core GPU in this thing either, so 
it might indeed be for the GPU(s).

If it is the CPU(s) then the low _PSV figure of 55C might have something 
to do with controlling whether it could/would use the turbo mode/s, but 
that's merely wild speculation .. it may be controlled by CPU microcode 
without OS intervention, for all I know .. I've no time to research it.

 > hw.acpi.thermal.tz3._TSP: -1
 > hw.acpi.thermal.tz3._TC2: -1
 > hw.acpi.thermal.tz3._TC1: -1
 > hw.acpi.thermal.tz3._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1
 > hw.acpi.thermal.tz3._CRT: 128.1C
 > hw.acpi.thermal.tz3._HOT: -1
 > hw.acpi.thermal.tz3._PSV: -1
 > hw.acpi.thermal.tz3.thermal_flags: 0
 > hw.acpi.thermal.tz3.passive_cooling: 0
 > hw.acpi.thermal.tz3.active: -1
 > hw.acpi.thermal.tz3.temperature: 0.1C

[ and exactly the same for tz2 and tz1 - I've no idea about these ]

 > hw.acpi.thermal.tz0._TSP: -1
 > hw.acpi.thermal.tz0._TC2: -1
 > hw.acpi.thermal.tz0._TC1: -1
 > hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1
 > hw.acpi.thermal.tz0._CRT: 128.1C
 > hw.acpi.thermal.tz0._HOT: 102.1C
 > hw.acpi.thermal.tz0._PSV: -1
 > hw.acpi.thermal.tz0.thermal_flags: 0
 > hw.acpi.thermal.tz0.passive_cooling: 0
 > hw.acpi.thermal.tz0.active: -1
 > hw.acpi.thermal.tz0.temperature: 48.1C

This looks more like a typical active cooling setup, active meaning with 
a fan or such to control temperature, however there are no trip points 
set (_ACx) only the _HOT setting, so I'm really not sure.  I'm less sure 
this is likely to be a CPU temperatur

Re: AMD A12-8800B ACPI questions (turbo mode, temp zones)

[Ian Smith]

On Sun, 13 Dec 2015 19:53:52 -0500, Johannes Dieterich wrote:
 > Dear list,
 > 
 > I am running CURRENT on an HP elitebook 745 G3 which comes with a AMD
 > A12-8800B CPU. All in all, it runs very well with just a few nits to
 > pick. Two of them are ACPI related.
 > 
 > 1) there are 5 thermal zones defined out of which only two provide
 > reasonable numbers it seems:
 > 
 > hw.acpi.thermal.tz4.temperature: 34.1C
 > hw.acpi.thermal.tz3.temperature: 0.1C
 > hw.acpi.thermal.tz2.temperature: 0.1C
 > hw.acpi.thermal.tz1.temperature: 0.1C
 > hw.acpi.thermal.tz0.temperature: 56.1C
 > 
 > my gut feeling is that tz0-tz3 may be the CPU cores and tz4 would be
 > the GPU (which does not work in BSD ATM, hence consistently lower
 > temp). I guess this is not a big deal (everything works) but I still
 > wonder how to fix it.

Not sure if anything needs fixing, but I only have Intel gear these 
days and am not up on the AMD side of things.  However, please show:

% sysctl dev.cpu
% sysctl hw.acpi.thermal

which may provide more clues.  Perhaps all 4 cores are in one package, 
in which case individual CPU temperatures may not be too meaningful.  I 
don't know whether there's any equivalent to coretemp(4) for AMD CPUs?

Yours won't use est(4) but perhaps powernow(0) - 0 meaning no manpage :) 
but both are in GENERIC kernels.  You should be able to glean from dmesg 
which driver/s are in use; a verbose dmesg.boot might come in handy.

 > 2) turbo mode: this is a more major issue. sysctl reports the
 > following for all four cores:
 > 
 > dev.cpu.0.cx_lowest: C2
 > dev.cpu.0.cx_supported: C1/1/0 C2/2/400
 > dev.cpu.0.freq_levels: 2100/4717 1800/3450 1400/2320
 > dev.cpu.0.freq: 2100
 > 
 > >From the intel CPUs w/ turbo mode I had before I know that there
 > should be (at least) a 2101 frequency indicating the turbo clock. This
 > frequency is absent, I suspect this means turbo mode does not work.

Or that these CPUs just don't have a turbo mode, as such?  I expect the 
specs on AMD's site should mention that, either way?

 > How can I debug this? I believe also that this AMD chip has multiple
 > frequencies above the base clock of 2100, so how would that show?

What leads you to believe that?  Where is this documented?

 > Loaded modules:
 > 
 > Id Refs AddressSize Name
 >  1   23 0x8020 1e79670  kernel
 >  21 0x8207b000 384858   zfs.ko
 >  32 0x8240 ca38 opensolaris.ko
 >  41 0x8240d000 22b98geom_eli.ko
 >  51 0x82431000 ac60 aesni.ko
 >  61 0x8243d000 1c520fuse.ko
 >  71 0x82621000 358b ums.ko
 >  81 0x82625000 223c4ipfw.ko
 > 
 > I should note that I boot in legacy mode, not EFI.
 > 
 > asl dump available from http://llamapost.net/elitebook.asl

If it cxomes to that ..

 > Thanks a lot!
 > 
 > Johannes

Not much help, but I see noone else springing to your aid so far ..

cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: Get information about batteries

[Ian Smith]

On Thu, 10 Dec 2015 07:20:29 +0100, ga...@zahemszky.hu wrote:
 > 2015-12-09 21:03 idpontban Adrian Chadd ezt írta:
 > > acpiconf -i0 and acpiconf -i1? does that work?
 > 
 > OK, I've got it. Thanks for the quick answer.
 > ( Actually one of my batteries is full dead, even with acpiconf,
 > I could not get any answer, but it's another story.)

Some laptops have provision for more than two battery slots, perhaps in 
a docking station, so you could try acpiconf -i2 and -i3 too .. however 
dmesg should show if any others were detected on boot.

cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: ACPI problems op ASrock

[Ian Smith]

On Sat, 26 Sep 2015 10:17:20 +0200, Arthur van der Peijl wrote:
 > Thank you for assistance: powerd must clearly not be my focus: the 
 > CPU stays high and thus cannot go into idle mode.

 > No need to change performance_cx_lowest as I just have a Pentium 
 > G3220 running.
 > 
 > [root@zfsguru /home/ssh]# cat /boot/loader.conf | grep hint.
 > hint.p4tcc.0.disabled="1"
 > hint.acpi_throttle.0.disabled="1"
 > 
 > Tried to change lowest level on running system: 
 > 
 > [root@zfsguru /home/ssh]# sysctl dev.cpu.0.cx_lowest=C8
 > dev.cpu.0.cx_lowest: C8 -> C8

You really need to set hw.acpi.cpu.cx_lowest=C8 instead; this is then 
propogated to dev.cpu.*.cx_lowest, updated when /etc/rc.d/power_profile 
runs on losing or regaining mains power.  However, that won't help here.

 > We're already there. The document described some other setting which 
 > could be read:
 > 
 > [root@zfsguru /home/ssh]# sysctl dev.cpu | grep cx
 > dev.cpu.1.cx_usage: 100.00% last 5us
 > dev.cpu.1.cx_lowest: C8
 > dev.cpu.1.cx_supported: C1/1/1
 > dev.cpu.0.cx_usage: 100.00% 0.00% last 4us
 > dev.cpu.0.cx_lowest: C8
 > dev.cpu.0.cx_supported: C1/1/1 C2/2/117
 > 
 > I don't inderstand this. 100% CPU is my main issue, created by 
 > {acpi_task} in the kernal. However -> CPU1 supports different states 
 > as CPU0? Or is this a summary of last states?

I don't follow this either, and don't recall seeing different C-states 
available on different CPUs?  If cpu1 has only C1, I can't see how cpu0 
could ever use C2 - with its real win in terms of power consumption - as 
all CPUs are now set to the same C-state (and P-state) as far as I know.

Is cpu1 a real CPU, or HTT? Perhaps show the CPU detection details from 
dmesg.  powerd with standard parameters will always run at top speed 
with the CPU usage/idle figures you quoted; you could get it to run 
slower if you adjusted -i and -r settings, as an immediate workaround.

But listen to John about debugging the ACPI tasks CPU usage issue ..

cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: disabling sleep when shutting down

[Ian Smith]

On Sat, 26 Sep 2015 11:56:10 -0700, Colin Percival wrote:
 > On 09/26/15 10:59, Ian Smith wrote:
 > > On Sat, 26 Sep 2015 00:26:31 -0700, Colin Percival wrote:
 > >  > Points without consensus:
 > >  > * jkim thinks we should prevent suspend when we're dropping to 
 > > single-user
 > >  > mode; I'm not sure I see the point, but I don't think there's any harm 
 > > in
 > >  > doing that too.
 > > 
 > > We should prevent suspending _during_ shutdown to SU, of course.  Once 
 > > happily in SU, is there any reason to disallow suspend?  I've done it.
 > 
 > I think the question here was about suspending during the shutdown to
 > single-user mode.  This seemed a bit different to me since it's not a
 > "walk away from your laptop" sort of situation.  But I've included it
 > (or rather, not *excluded* it) anyway.

Sounds good.  As all this shows, we can't assume what anyone might do :)

 > >  > * Ian Smith would like to have suspend blocked for the last 5 minutes 
 > > before
 > >  > shutdown(8) signals init to shut the system down.  I don't think anyone 
 > > else
 > >  > has expressed a desire for this, and some people have raised concerns 
 > > about
 > >  > blocking suspend for too long in case a system is running out of 
 > > battery; so
 > >  > I'm inclined to leave this out at this point.  (It would be easy enough 
 > > to
 > >  > add the sysctl-frobbing to shutdown(8) if desired later.)
 > > 
 > > Sorry, but that rather misrepresents my position; I was trying to deal 
 > > specifically with the LID foot-shooting potential, in the case of user- 
 > > initiated shutdown, so looking at possible mechanisms.  Not to worry, I 
 > > clearly didn't express myself clearly :^\
 > 
 > Ok, so you're satisfied with having the suspend-disabling triggered by
 > init (i.e., not happening until shutdown(8) reaches "now")?

Sure, if you're satisfied that 'shutdown [..] now' - or hitting the 
power button as Dan mentioned - then quickly closing the lid will lose 
that race.  As you say, with this mechanism in place, accessing it from 
shutdown(8) would be straightforward if deemed necessary.  So, yes.

 > Should be trivial to MFC.

Cool.

Thanks, Ian
___
freebsd-acpi@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: disabling sleep when shutting down

[Ian Smith]

On Sat, 26 Sep 2015 00:26:31 -0700, Colin Percival wrote:
 > Hi all,
 > 
 > I think there is consensus for:
 > * Using a sysctl (simpler than a device node),
 > * Setting this sysctl on all architectures,
 > * Calling the sysctl kern.suspend_blocked,
 > * Consulting the sysctl from the ACPI code (for now) and possibly from
 > other platform-specific forms of sleeping (in the indefinite future).

Sounds all good to me, FWTW.

 > Points without consensus:
 > * jkim thinks we should prevent suspend when we're dropping to single-user
 > mode; I'm not sure I see the point, but I don't think there's any harm in
 > doing that too.

We should prevent suspending _during_ shutdown to SU, of course.  Once 
happily in SU, is there any reason to disallow suspend?  I've done it.

 > * Ian Smith would like to have suspend blocked for the last 5 minutes before
 > shutdown(8) signals init to shut the system down.  I don't think anyone else
 > has expressed a desire for this, and some people have raised concerns about
 > blocking suspend for too long in case a system is running out of battery; so
 > I'm inclined to leave this out at this point.  (It would be easy enough to
 > add the sysctl-frobbing to shutdown(8) if desired later.)

Sorry, but that rather misrepresents my position; I was trying to deal 
specifically with the LID foot-shooting potential, in the case of user- 
initiated shutdown, so looking at possible mechanisms.  Not to worry, I 
clearly didn't express myself clearly :^\

As jkim pointed out, code speaks for itself, and C is read-only here at 
best .. though after 30-odd years I can usually follow it around ..

 > With the above in mind, I've written (but not yet actually compiled or 
 > tested,
 > so beware of typos) a patch which I think makes sense.  If nobody is 
 > violently
 > opposed to this I'll make sure I got the details right and then commit this 
 > in
 > a few days.

+static void
+block_suspend(int block)
+{
+
+   sysctlbyname("kern.suspend_blocked", NULL, NULL, &block, 
sizeof(block));
+}

This doesn't appear to get called?

Any idea if any of this may not be straightforward to MFC, to 9 maybe?

Thanks for going for the generic solution.  Hope it wins that race :)

cheers, IanIndex: sbin/init/init.c
===
--- sbin/init/init.c	(revision 288249)
+++ sbin/init/init.c	(working copy)
@@ -1481,6 +1481,16 @@
 }
 
 /*
+ * Block (if block == 1) or unblock (if block == 0) suspend.
+ */
+static void
+block_suspend(int block)
+{
+
+	sysctlbyname("kern.suspend_blocked", NULL, NULL, &block, sizeof(block));
+}
+
+/*
  * Bring the system down to single user.
  */
 static state_func_t
@@ -1487,7 +1497,16 @@
 death(void)
 {
 	session_t *sp;
+	int block, blocked;
+	size_t len;
 
+	/* Temporarily block suspend. */
+	len = sizeof(blocked);
+	block = 1;
+	if (sysctlbyname("kern.suspend_blocked", &blocked, &len,
+	&block, sizeof(block)))
+		blocked = 0;
+
 	/*
 	 * Also revoke the TTY here.  Because runshutdown() may reopen
 	 * the TTY whose getty we're killing here, there is no guarantee
@@ -1503,6 +1522,11 @@
 	/* Try to run the rc.shutdown script within a period of time */
 	runshutdown();
 
+	/* Unblock suspend if we blocked it. */
+	if (!blocked)
+		sysctlbyname(kern.suspend_blocked", NULL, NULL,
+		&blocked, sizeof(blocked));
+
 	return (state_func_t) death_single;
 }
 
Index: sys/dev/acpica/acpi.c
===
--- sys/dev/acpica/acpi.c	(revision 288249)
+++ sys/dev/acpica/acpi.c	(working copy)
@@ -2574,8 +2574,11 @@
 if (!acpi_sleep_states[state])
 	return (EOPNOTSUPP);
 
-/* If a suspend request is already in progress, just return. */
-if (sc->acpi_next_sstate != 0) {
+/*
+ * If a reboot/shutdown/suspend request is already in progress or
+ * suspend is blocked due to an upcoming shutdown, just return.
+ */
+if (rebooting || sc->acpi_next_sstate != 0 || suspend_blocked) {
 	return (0);
 }
 
Index: sys/kern/kern_shutdown.c
===
--- sys/kern/kern_shutdown.c	(revision 288249)
+++ sys/kern/kern_shutdown.c	(working copy)
@@ -137,6 +137,10 @@
 SYSCTL_INT(_kern_shutdown, OID_AUTO, show_busybufs, CTLFLAG_RW,
 	&show_busybufs, 0, "");
 
+int suspend_blocked = 0;
+SYSCTL_INT(_kern, OID_AUTO, suspend_blocked, CTLFLAG_RW,
+	&suspend_blocked, 0, "Block suspend due to a pending shutdown");
+
 /*
  * Variable panicstr contains argument to first call to panic; used as flag
  * to indicate that the kernel has already called panic.
Index: sys/sys/systm.h
===
--- sys/sys/systm.h	(revision 288249)
+++ sys/sys/systm

Re: disabling sleep when shutting down

[Ian Smith]

On Tue, 22 Sep 2015 01:28:27 -0100, Colin Percival wrote:
 > On 09/20/15 03:04, Ian Smith wrote:
 > > On Sun, 20 Sep 2015 00:16:36 -0700, Colin Percival wrote:
 > >  > On 09/18/15 11:29, Anthony Jenkins wrote:
 > >  > > Is it possible for /etc/rc.shutdown to complete, but shutdown not
 > >  > > occur?  If so, there should be a mechanism to restore the ability to
 > >  > > suspend.  Other than that, I like it.
 > >  > 
 > >  > Hmm... well, rc.shutdown runs before the system drops into single-user
 > >  > mode.  Which makes me think that maybe we should be making the kernel
 > >  > call from inside init instead of from rc.shutdown.
 > > 
 > > I still think disabling suspend from shutdown.c, at the same time as 
 > > creating /var/run/nologin might be the best way to go, to avoid any 
 > > possibility of untimely suspending once committed to shutting down.
 > 
 > So you think we should disable suspend for the last 5 minutes before a
 > scheduled shutdown?  This seems a bit strange to me... and I honestly can't
 > imagine a situation where you'd need to announce an imminent shutdown of
 > your laptop to logged-in users.

Not necessarily 5 minutes, but maybe some time.  I've long used several 
laptops as servers, one with websites, DNS, mail, etc, and with login 
users .. but I've not considered suspending on such (rare) shutdowns, 
nor there used scheduled shutdowns.  It's hard sometimes imagining 
other peoples' experiences if they're very different from your own :)

 > > For one thing, shutdown's -o flag bypasses using init and calls halt or 
 > > reboot directly, though I don't know if anyone uses that.
 > 
 > Right, I figured it wasn't worth worrying about that case since anyone who
 > uses that hopefully knows what they're doing; also since that skips running
 > rc.shutdown there's a much smaller race window.

Fair enough.

 > On the other hand, "send a signal to init" and the sysv compatible approach
 > of running `init [runlevel]` are likely to be used by other tools (e.g.,
 > desktop environments), so I don't think we should assume that reboot/poweroff
 > requests always go through shutdown(8).

That's a good point, and I do think the approach you're developing is 
looking pretty good overall .. except for one point, below.  And I agree
with your latest point, that shutdown to SU shouldn't disable suspend.

 > > For another, 
 > > if shutdown fails for any reason, or is cancelled by signal by the user 
 > > .. or in any case, I gather .. finish() removes /var/run/nologin, and 
 > > could also there reenable suspend, covering Anthony's point.

I's almost suggested /var/run/nosuspend, possibly holding the previous 
value of hw.acpi.lid_switch_state, when considering just the LID issue, 
but that would require removing on startup.

 > This would also be accomplished by having the suspend-disabling done by init;
 > if you tell shutdown(8) to not shut the system down, then it never sends the
 > relevant signal to init.  The shutdown(8) utility doesn't do any shutting
 > down itself; it's just a front-end which makes an announcement, sets a timer,
 > and disables logins, and then ultimately asks init(8) to do the real work
 > (including spawning rc.shutdown).

Indeed, not to mention the handy logging.  However to come back to your 
initial issue: if you initiate a shutdown - I'd assumed you meant using 
'shutdown -p now' ono? - hit return and snap the lid shut - let's say 
with practice and some bruised fingers in 0.3s - then are we sure that 
shutdown will progress to init, or from init to rc.shutdown in the other 
scenario jkim offered, within say 0.3s?  IOW, are we sure a fix in init, 
or ever so shightly later in rc.shutdown, will always win that race, on 
a system that might be in a high load state?

If not, the lid switch race becomes almost a separate issue, which the 
bother of adding setting hw.acpi.lid_switch_state would deal with, while 
needing storage to restore it on a cancelled or failed shutdown.

Don't mind me, I've only used slower low-end gear for years now, and my 
concepts of how long things might take is conditioned on that.  On one 
laptop I can't trust shutdown to wind down KDE including a browser with 
maybe 15 tabs inside two minutes, so always shut KDE down first .. this
sort of stuff most people nowadays don't need to even consider.

cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: disabling sleep when shutting down

[Ian Smith]

On Sun, 20 Sep 2015 00:16:36 -0700, Colin Percival wrote:
 > On 09/18/15 11:29, Anthony Jenkins wrote:
 > > Is it possible for /etc/rc.shutdown to complete, but shutdown not
 > > occur?  If so, there should be a mechanism to restore the ability to
 > > suspend.  Other than that, I like it.
 > 
 > Hmm... well, rc.shutdown runs before the system drops into single-user
 > mode.  Which makes me think that maybe we should be making the kernel
 > call from inside init instead of from rc.shutdown.

I still think disabling suspend from shutdown.c, at the same time as 
creating /var/run/nologin might be the best way to go, to avoid any 
possibility of untimely suspending once committed to shutting down.

For one thing, shutdown's -o flag bypasses using init and calls halt or 
reboot directly, though I don't know if anyone uses that.  For another, 
if shutdown fails for any reason, or is cancelled by signal by the user 
.. or in any case, I gather .. finish() removes /var/run/nologin, and 
could also there reenable suspend, covering Anthony's point.

cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: disabling sleep when shutting down

[Ian Smith]

On Fri, 18 Sep 2015 13:51:15 -0400, Jung-uk Kim wrote:
 > On 09/17/2015 19:12, Colin Percival wrote:
 > > On 09/17/15 13:31, Jung-uk Kim wrote:
 > >> On 09/16/2015 23:49, Colin Percival wrote:
 > >>> I ran into an interesting glitch recently: I told my laptop to
 > >>> shut down, then closed the lid... and it promptly went into S3.
 > >>> When I opened the lid a couple days later, it resumed... and
 > >>> then finished the shutdown which it had started 2 days
 > >>> earlier.
 > >> 
 > >> Please try the attached patch.
 > > 
 > > No, this doesn't do what I wanted.  It might be a good idea anyway,
 > > but your patch only disables suspend once the kernel is trying to
 > > reboot; what I want is to disable suspend a bit earlier -- once
 > > rc.shutdown is running and the userland is trying to shut down,
 > > because at that point unless something breaks horribly we're *about
 > > to* tell the kernel to shut down even though we haven't gotten
 > > there quite yet.
 > 
 > Okay.  The attached patch is a quick-and-dirty & untested hack for you.

That looks .. comprehensive, given that it's run when rc.shutdown is 
called by init(8), if I'm correctly following the train of events from 
shutdown through init (unless -o) and then halt(8) or reboot(8).

Am I right assuming that if one ran say 'shutdown -p +2 [message]' then 
suspending would only be blocked after that interval has elapsed?

And with 'shutdown [-p|-h|-r] now' is there any appreciable delay (like
waiting on anything) before launching rc.shutdown?  i.e. anything that 
aforesaid fast lid-slammer might beat?

"Five minutes before shutdown, or immediately if shutdown is in less 
than 5 minutes, logins are disabled by creating /var/run/nologin and 
copying the warning message there."

Guess I'm still wondering if blocking suspend from shutdown, perhaps 
in a similar timeframe, might better prevent suspend-during-shutdown?

Aside perhaps, a point about acpiconf(8) I discovered tonight: every 
version of the man page since at least 5.5 states that S5 (soft off) is 
an option for -s.  That was true at 5.5, however acpiconf.c at least 
from 8.2 through 9.3 to HEAD (checked just now) allows only S1 to S4.

Noticed that because I was trying to find what else apart from shutdown, 
halt -p and the power button could initiate a poweroff halt.  Are there 
other ways, apart from doing it like acpiconf does?

cheers, IanIndex: etc/rc.shutdown
===
--- etc/rc.shutdown	(revision 287937)
+++ etc/rc.shutdown	(working copy)
@@ -43,6 +43,9 @@ HOME=/
 PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin
 export HOME PATH
 
+# Temporarily block any suspend requests.
+acpiconf -b 1 >/dev/null 2>&1
+
 . /etc/rc.subr
 
 load_rc_config 'XXX'
@@ -109,5 +112,8 @@ fi
 # Insert other shutdown procedures here
 
 
+# Unblock suspend requests.
+acpiconf -b 0 >/dev/null 2>&1
+
 echo '.'
 exit 0
Index: sys/dev/acpica/acpi.c
===
--- sys/dev/acpica/acpi.c	(revision 287937)
+++ sys/dev/acpica/acpi.c	(working copy)
@@ -98,6 +98,9 @@ struct callout	acpi_sleep_timer;
 /* Bitmap of device quirks. */
 int		acpi_quirks;
 
+/* Block suspend requests. */
+static int	acpi_sleep_blocked;
+
 /* Supported sleep states. */
 static BOOLEAN	acpi_sleep_states[ACPI_S_STATE_COUNT];
 
@@ -2574,10 +2577,12 @@ acpi_ReqSleepState(struct acpi_softc *sc, int stat
 if (!acpi_sleep_states[state])
 	return (EOPNOTSUPP);
 
-/* If a suspend request is already in progress, just return. */
-if (sc->acpi_next_sstate != 0) {
+/*
+ * If a reboot/shutdown/suspend request is already in progress
+ * or suspend is explicitly disabled, just return.
+ */
+if (rebooting || sc->acpi_next_sstate != 0 || acpi_sleep_blocked)
 	return (0);
-}
 
 /* Wait until sleep is enabled. */
 while (sc->acpi_sleep_disabled) {
@@ -3568,6 +3573,9 @@ acpiioctl(struct cdev *dev, u_long cmd, caddr_t ad
 	error = *(int *)addr;
 	error = acpi_AckSleepState(sc->acpi_clone, error);
 	break;
+case ACPIIO_BLKSLPSTATE:
+	acpi_sleep_blocked = *(int *)addr;
+	break;
 case ACPIIO_SETSLPSTATE:	/* DEPRECATED */
 	state = *(int *)addr;
 	if (state < ACPI_STATE_S0 || state > ACPI_S_STATES_MAX)
Index: sys/dev/acpica/acpiio.h
===
--- sys/dev/acpica/acpiio.h	(revision 287937)
+++ sys/dev/acpica/acpiio.h	(working copy)
@@ -41,6 +41,9 @@
 /* Allow suspend to continue (0) or abort it (errno). */
 #define ACPIIO_ACKSLPSTATE	_IOW('P', 5, int)
 
+/* Allow suspend request (0) or block it. */
+#define ACPIIO_BLKSLPSTATE	_IOW('P', 6, int)
+
 struct acpi_battinfo {
 int	 cap;/* percent */
 int	 min;/* remaining time (in minutes) */
Index: usr.sbin/acpi/acpiconf/acpiconf.8
===
--- usr.sbin/acpi/acpiconf/acpiconf.8	(revision 287937)
+++ usr.sbin/acpi/acpiconf/acpiconf

Re: disabling sleep when shutting down

[Ian Smith]

On Thu, 17 Sep 2015 16:22:55 -0700, Colin Percival wrote:
 > On 09/17/15 14:39, Dan Lukes wrote:
 > > Colin Percival wrote:
 > >> I considered that option but thought that disabling suspend completely
 > >> would be better in case it was triggered by something else
 > > 
 > > You has been affected by LID issue - and here I'm with you.
 > 
 > Ok.  But adjusting the sysctl might not be enough; KDE has a "suspend
 > when lid closed" setting which seems to be broken right now, but if it
 > worked we would need to figure out how to disable that as well.

If our KDE isn't using FreeBSD methods to manage suspend and/or shutdown 
(given it's generally pretty linux-centric), presumably acpiconf -S{3,5} 
or in the case of shutdown, perhaps invoking 'shutdown -p now [message]' 
then that's a separate issue that needs fixing in KDE.  I wouldn't even 
consider trawling through KDE power management code, if I could find it.

I think Dan's right, deal with the LID issue by disabling suspend-on-lid 
in shutdown.c, which needs adding a sysctl handler for it, and just set 
it to 'NONE' after validating options etc.  This won't need to consider 
any of the other possible circumstances, just disabling a convenience.

And then there's what type of shutdown has been issued?  -p powerdown? 
-r reboot?  -h halt?  No switches to drop to single user?  With any 
delay, or 'now'?

And there's the chance that someone has set hw.acpi.disable_on_reboot .. 
things could get messy, but early disabling of hw.acpi.lid_switch_state 
sounds pretty safe to me, and you can see by LEDs if the system hasn't 
suspended after closing the lid, or whether it's shut down, or rebooted.

 > > Suspend triggered by exhausted battery case needs to be evaluated
 > > carefully. Battery may be so exhausted so shutdown will not be
 > > completed. Note that some system (hardware) require no power to maintain
 > > suspend context, thus suspend may save system.

My X200 runs for something like a week suspended from full charge, but I 
do miss the control APM offered, running scripts at every 10% graduation 
and on critical low power, charging or discharging.  I've managed to get 
devd to run a script on CMBAT events that logs (among other things) the 
battery state via acpiconf -i0.  The X200 does so on power loss/returned 
and at 80% and 20%, charging or discharging, but I've yet to add code to 
parse those looking for capacity less than say 10% to invoke suspend, or 
critical low power to invoke shutdown, but it's functionality I'd like.

 > > And what about other reasons for suspends ? I can tell nothing about all
 > > those cases. Suspend may be triggered for any reason, thus so many
 > > possible causes. I can't claim all of them are illegitimate and can be
 > > safely ignored. I wish we should have stronger reason for system global
 > > behavior change than just feeling (no offense!).
 > 
 > The example of a system which can usefully suspend but doesn't have enough
 > battery life left to allow it to complete a normal shutdown seems a bit
 > implausible, but I'll concede that it's theoretically possible.  Maybe we
 > should have an rc.d script which checks an rc.conf setting?

Well I think this has shown there are plenty of possible conditions to 
consider and possible races to avoid, going down that path.  Disabling 
hw.acpi.lid_switch_state would seem to solve your original problem 
without needing to mess with ACPI, until such scenarios are examined?

cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: disabling sleep when shutting down

[Ian Smith]

On Thu, 17 Sep 2015 10:52:23 +0200, Dan Lukes wrote:

 > Colin Percival wrote:
 > > I ran into an interesting glitch recently: I told my laptop to shut down,
 > > then closed the lid... and it promptly went into S3.  When I opened the
 > > lid a couple days later, it resumed... and then finished the shutdown
 > > which it had started 2 days earlier.
 > 
 > Yes, it's well known behavior to me.

News to me, but I never suspend on lid down .. well I tested it once.

 > > I think we need to get the kernel ACPI bits to disable Suspend.
 > 
 > I consider it is suboptimal solution. I wish the suspend still happen if
 > shutdown will not complete for any reason. All I want is that lid close
 > doesn't trigger any action during shutdown.
 > 
 > So what about hw.acpi.lid_switch_state just to be set to NONE during
 > shutdown ?

That sounds sensible and likely much easier to accomplish.  It needs to 
happen early enough in shutdown to beat the fastest of lid-slammers :)

cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: HP Compaq CQ62/42 acpi

[Ian Smith]

On Thu, 26 Mar 2015 11:37:51 +1000, Da Rock wrote:
 > On 03/25/15 09:52, Kevin Oberman wrote:
 > > On Tue, Mar 24, 2015 at 3:23 AM, Da Rock
 > >  > > wrote:
 > > 
 > > I have 2 laptops as mentioned, 3 all amd athlon based. The 3rd is
 > > an asus which I'm relatively happy with.
 > > 
 > > What I have is when I pull the AC out of it, the sysctl for cpu
 > > speed goes from 2200 to 100 or 400. Basically the system becomes
 > > rather unusable.
 > > 
 > > I tried the acpi_hp module, and it now switches to 800. This is
 > > better, but barely usable still.
 > > 
 > > I'd like to see a response similar to the asus if its possible;
 > > this effectively stays the same, but drops speed if nothing is
 > > happening.
 > > 
 > > Ideally, I'd think that it would be better if the system adjusted
 > > speed to use requirements during operation, but neither does that.
 > > I suspect that the asus should (in theory) as it does do it on
 > > battery only; but unless I'm really hammering all the time, it
 > > just doesn't seem to happen when I'm looking at it.
 > > 
 > > The settings used on all for powerd is hiadaptive for AC, adaptive
 > > for battery.
 > > 
 > > If I'm doing something wrong let me know, if more data is required
 > > I'm happy to help the cause :)
 > > 
 > > TIA
 > > 
 > > First, let's get a bit more information. Please provide:
 > > sysctl dev.cpu.0 (on AC and then on battery)
 > AC:
 > 
 > dev.cpu.0.%desc: ACPI CPU
 > dev.cpu.0.%driver: cpu
 > dev.cpu.0.%location: handle=\_PR_.C000
 > dev.cpu.0.%pnpinfo: _HID=none _UID=0
 > dev.cpu.0.%parent: acpi0
 > dev.cpu.0.temperature: 85.3C
 > dev.cpu.0.freq: 200
 > dev.cpu.0.freq_levels: 2200/7543 1925/6600 1900/6150 1662/5381 1600/4777
 > 1400/4179 1300/3750 1137/3281 975/2812 800/2091 700/1829 600/1568 500/1306
 > 400/1045 300/784 200/522 100/261
 > dev.cpu.0.cx_supported: C1/1/0
 > dev.cpu.0.cx_lowest: C1
 > dev.cpu.0.cx_usage: 100.00% last 682us

Kevin appears to be psychic :) as for the second time in 3 days has 
replied while I was composing mine, but this time I heard the beep and 
saw 'new message from Kevin ..' and of course he's well covered it, 
except possibly regarding one aspect which I'll leave in:

The clue is all those freq_levels. For powerd to increase frequeny under 
load requires stepping through all of them, possibly one per polling 
interval, which as you've observed takes too long.  If you were running 
Intel I'd say you need to add to /boot/loader.conf these, and you should 
add them anyway:
hint.p4tcc.0.disabled=1
hint.acpi_throttle.0.disabled=1

But from your one (1) clue that this is an AMD system, I'm not so sure:
 > amdtemp0:  on hostb4

so you should check dmesg to check if you're running powernow(none!) 
instead of est(4) plus any other drivers providing 'thermal control', 
and if so, disable it (but not powernow or amdtemp) similarly.  It may 
already be using acpi_throttle?, or perhaps p4tcc also covers AMD CPUs
these days, I'm not sure?  If that's unclear, post /var/run/dmesg.boot

Yes, set both *_cx_lowest=Cmax and take delight in dev.cpu.0.cx_usage

Playing with powerd_flags can make quite a lot of difference to powerd's 
behaviour, so I echo Kevin's request to see those, and his advice to run 
powerd -v in a terminal while you play, especially with -i and -r flags, 
though reducing -p interval may be beneficial to responsiveness, at a 
slight increase in powerd's CPU usage.

I don't know if any of this changed between your 10.0 and 10.1 ..

cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: [PATCH] ACPI CMOS region support rev. 5

[Ian Smith]

On Thu, 19 Mar 2015 09:11:08 -0400, Anthony Jenkins wrote:
 > On 03/19/2015 04:10 AM, Ian Smith wrote:
 > > On Wed, 18 Mar 2015 15:30:23 -0600, Warner Losh wrote:
 > >  > > On Mar 18, 2015, at 10:06 AM, Anthony Jenkins 
 > >  wrote:
 > >  > > 
 > >  > > On 03/18/2015 11:29 AM, Warner Losh wrote:
 > >  > >>> On Mar 17, 2015, at 7:02 AM, Anthony Jenkins 
 > >  wrote:
 > >  > >>>> \Where else might ATRTC_VERBOSE be set otherwise?
 > >  > >>> I'm picturing a (future?) config(5) knob, e.g.
 > >  > >>> 
 > >  > >>>   device atrtc
 > >  > >>>   options ATRTC_VERBOSE=1
 > >  > >>> 
 > >  > >>> 
 > >  > >>> so it can be set at compile time.
 > >  > >> Why not just boot verbose? history has shown too many options like
 > >  > >> this is hard to use.
 > >
 > > You can blame this on me :)  I agree about the option not being needed; 
 > > the way it is you can just set sysctl hw.acpi.atrtc_verbose=0 to quell 
 > > reports of successful access, if it turns out these are routine on some 
 > > machines, especially outside of boot/suspend/resume contexts.
 > >
 > > However I'll still argue that, this being a new gadget and that we could 
 > > use finding out which vendors want to read or write which locations in 
 > > CMOS for whatever reason, at least while it's in head, we should log all 
 > > access by default unless setting atrtc_verbose=0,
 > 
 > So the default verbosity of ACPI CMOS region accesses should be
 > "verbose"?  I personally don't mind the default being "silent" and
 > asking people triaging an ACPI problem to boot verbosely and send the
 > logs (I think that's in the FreeBSD ACPI handbook anyway).

Assuming they know that their problem is ACPI related, sure.

 > > and in _any_ case we 
 > > should be logging attempts to R/W out-of-bounds CMOS locations.
 > 
 > Error logs are always printed; they don't honor atrtc_verbose.

That would be comforting.  However I was referring to rev. 5:

+   if (bitwidth == 0 || bitwidth > 32 || (bitwidth & 0x07) ||
+   addr + bytewidth - 1 > 63) {
+   ATRTC_DBG_PRINTF(1,
+   "Invalid bitwidth (%u) or addr (0x%08lx).\n",
+   bitwidth, addr);
+   return AE_BAD_PARAMETER;
+   }
+   if (!acpi_check_rtc_access(func == ACPI_READ, addr, bytewidth)) {
+   ATRTC_DBG_PRINTF(1, "Bad CMOS %s access at addr 0x%08lx.\n",
+   func == ACPI_READ ? "read" : "write", addr);
+   return AE_BAD_PARAMETER;
+   }

 > >  > > I think I understand what you're saying... I also prefer fewer 
 > > config(5)
 > >  > > knobs.  So you're suggesting I determine (at runtime) the boot verbose
 > >  > > setting (kenv(2) or however it's properly done) and dump the
 > >  > > compile-time verbosity setting?
 > >  > 
 > >  > if (bootverbose)
 > >  > do verbose things;
 > >  > 
 > >  > is how thatÿÿs done.
 > >
 > > Sure, and maybe successful access could be limited to bootverbose, and 
 > > we could ask people whose boxes fail to boot/suspend/resume/whatever to 
 > > boot verbose to reveal such as why Anthony's HP Envy either failed to 
 > > suspend or immediately resumed - which isn't entirely clear, even with 
 > > the messages - unless its ACPI AML succeeded in reading minute, hour and 
 > > weekday, but I have a feeling we may see more of this sort of thing.
 > 
 > Now that I think about it, adding this ACPI CMOS region access should
 > simply eliminate a class of failures where FreeBSD wasn't giving the
 > BIOS access to CMOS.

Do we have other examples than your HP Envy of such a class of failures?

 > Logging /successful/  R/W accesses to CMOS by the
 > BIOS (AML) won't really provide any useful info (IMHO), but the user can
 > flip on bootverbose if she's curious.  If a user's box fails to
 > boot/suspend/resume/whatever, we'll see any ACPI CMOS region access errors.

Well I've made a case otherwise, likely too avidly; I'll leave it there.

Thanks for flushing out this issue and doing something about it!

cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: [PATCH] ACPI CMOS region support rev. 5

[Ian Smith]

On Wed, 18 Mar 2015 15:30:23 -0600, Warner Losh wrote:
 > > On Mar 18, 2015, at 10:06 AM, Anthony Jenkins  
 > > wrote:
 > > 
 > > On 03/18/2015 11:29 AM, Warner Losh wrote:
 > >>> On Mar 17, 2015, at 7:02 AM, Anthony Jenkins  
 > >>> wrote:
 >  \Where else might ATRTC_VERBOSE be set otherwise?
 > >>> I'm picturing a (future?) config(5) knob, e.g.
 > >>> 
 > >>>   device atrtc
 > >>>   options ATRTC_VERBOSE=1
 > >>> 
 > >>> 
 > >>> so it can be set at compile time.
 > >> Why not just boot verbose? history has shown too many options like
 > >> this is hard to use.

You can blame this on me :)  I agree about the option not being needed; 
the way it is you can just set sysctl hw.acpi.atrtc_verbose=0 to quell 
reports of successful access, if it turns out these are routine on some 
machines, especially outside of boot/suspend/resume contexts.

However I'll still argue that, this being a new gadget and that we could 
use finding out which vendors want to read or write which locations in 
CMOS for whatever reason, at least while it's in head, we should log all 
access by default unless setting atrtc_verbose=0, and in _any_ case we 
should be logging attempts to R/W out-of-bounds CMOS locations.

 > > I think I understand what you're saying... I also prefer fewer config(5)
 > > knobs.  So you're suggesting I determine (at runtime) the boot verbose
 > > setting (kenv(2) or however it's properly done) and dump the
 > > compile-time verbosity setting?
 > 
 > if (bootverbose)
 >  do verbose things;
 > 
 > is how thatÿÿs done.

Sure, and maybe successful access could be limited to bootverbose, and 
we could ask people whose boxes fail to boot/suspend/resume/whatever to 
boot verbose to reveal such as why Anthony's HP Envy either failed to 
suspend or immediately resumed - which isn't entirely clear, even with 
the messages - unless its ACPI AML succeeded in reading minute, hour and 
weekday, but I have a feeling we may see more of this sort of thing.

cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: [PATCH] ACPI CMOS region support rev. 5

[Ian Smith]

On Mon, 16 Mar 2015 15:51:30 -0400, Anthony Jenkins wrote:
 > On 03/16/2015 01:49 PM, Ian Smith wrote:
 > > On Mon, 16 Mar 2015 11:50:59 -0400, Anthony Jenkins wrote:
 > >  > On 03/16/2015 11:00 AM, Anthony Jenkins wrote:
 > >  > > On 03/16/2015 09:59 AM, Ian Smith wrote:
 > >  > >> On Sat, 14 Mar 2015 23:40:34 -0400, Anthony Jenkins wrote:
 > >  > >>> +if (!acpi_check_rtc_byteaccess(function == ACPI_READ, address))
 > >  > >>> +return AE_BAD_PARAMETER;
 > >  > >> acpi_check_rtc_byteaccess() needs to be called per byte of 1, 2 or 4 
 > >  > >> bytes - or pass it 'bytes' also, and loop over each of them within?
 > >  > >> ===
 > >  > >>
 > >  > >> Otherwise (for example) a 2 byte read from 0x0b or 4 byte read from 
 > >  > >> 0x09-0x0b will read 0x0c (clearing interrupts), or a 2 or 4 byte 
 > > write 
 > >  > >> to (say) 0x01 will also write to 0x02 and 0x04 (clobbering the time).
 > >  > > Right, this is an (incorrect) hybrid of a few attempts, probably from
 > >  > > around the time I lost my SSD and only had a single backup copy of my
 > >  > > work to go from.  In one revision I had disallowed all multibyte
 > >  > > accesses (width > 8) since IMHO it was more consistent/correct with 
 > > the
 > >  > > suggested locking.  I wasn't ignoring your suggestion, just making one
 > >  > > or a few changes at a time (generally the simpler ones).
 > >  > 
 > >  > Okay now I remember why I was reluctant to do this - suppose ACPIBIOS
 > >  > does a multibyte op on a set of bytes whose last byte fails
 > >  > acpi_check_rtc_byteaccess().  I will have already performed n-1
 > >  > accesses.  At one point I had a revision (acpi_check_rtc_access()?) that
 > >  > permitted/denied the entire request (it took the starting address and
 > >  > byte length), but I guess that got lost too.  I'll just recreate it...
 > >
 > > Yep, validating all access before doing any sounds like the way to go.
 > >
 > > Also, bytes = width >> 3 is ok, since you then affirm !(width & 0x07), 
 > > so non-multiples of 8 bits are invalidated anyway.  You should still 
 > > check that width (or bytes) > 0, even if 0 should never be passed.
 > 
 > Oh yeah, forgot about that!
 > 
 > > I guess the Big Kids will start playing once this hits bugzilla? :)
 > 
 > I'm just glad I get to learn how to commit stuff to FreeBSD.
 > 
 > Here's another iteration...comments welcome.  Think I got (most)
 > everything in there.  I need to unit test acpi_check_rtc_access() to
 > make sure it DTRT?

You've fixed all my concerns, thanks Anthony.  A couple of questions:

+#ifndef ATRTC_VERBOSE
+#define ATRTC_VERBOSE 1
+#endif

Where else might ATRTC_VERBOSE be set otherwise?

+static unsigned int atrtc_verbose = ATRTC_VERBOSE;
+SYSCTL_UINT(_debug, OID_AUTO, atrtc_verbose, CTLFLAG_RWTUN,
+   &atrtc_verbose, 0, "AT-RTC Debug Level (0-2)");
+#define ATRTC_DBG_PRINTF(level, format, ...) \
+   if (atrtc_verbose >= level) printf(format, ##__VA_ARGS__)

Genuine question, I don't know .. but would not that 0 in SYSCTL_UINT 
initialise atrtc_verbose to 0?  Or does it keep its existing setting?
Or would replacing 0 there with ATRTC_VERBOSE work, or be clearer?

 static int
+acpi_check_rtc_access(int is_read, u_long addr, u_long len)
+{
+   int retval = 1; /* Success */
+
+   if (is_read) {
+   /* Reading 0x0C will muck with interrupts */
+   if (addr + len - 1 >= 0x0C && addr <= 0x0c)
+   retval = 0;

Looks alright to me, given my uncertainty with C operator precedence.

+   } else {
+   /* Allow single-byte writes to alarm registers and
+* addr >= 0x30, else deny.
+*/
+   if (!((len == 1 && (addr <= 5 && (addr & 1))) || addr >= 0x30))
+   retval = 0;
+   }
+   return retval;
+}

After a short struggle unwinding brackets, this looks right; but I will 
suggest clarifying the comment:

  +   /* Allow single-byte writes to alarm registers and
- +* addr >= 0x30, else deny.
+ +* multi-byte writes to addr >= 0x30, else deny.

I still wonder if there isn't a global acpi_loaded_and_running variable 
so you could avoid even attempting ACPI init calls, perhaps making this 
not so dependent on ACPI, at least at runtime.

But perhaps jkim's concern is more regarding building on platforms not 
supporting ACPI at all?  Is that the (only?) issue with this on ARM?

cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: [PATCH] ACPI CMOS region support rev. 4

[Ian Smith]

On Mon, 16 Mar 2015 11:50:59 -0400, Anthony Jenkins wrote:
 > On 03/16/2015 11:00 AM, Anthony Jenkins wrote:
 > > On 03/16/2015 09:59 AM, Ian Smith wrote:
 > >> On Sat, 14 Mar 2015 23:40:34 -0400, Anthony Jenkins wrote:
 > >>> +if (!acpi_check_rtc_byteaccess(function == ACPI_READ, address))
 > >>> +return AE_BAD_PARAMETER;
 > >> acpi_check_rtc_byteaccess() needs to be called per byte of 1, 2 or 4 
 > >> bytes - or pass it 'bytes' also, and loop over each of them within?
 > >> ===
 > >>
 > >> Otherwise (for example) a 2 byte read from 0x0b or 4 byte read from 
 > >> 0x09-0x0b will read 0x0c (clearing interrupts), or a 2 or 4 byte write 
 > >> to (say) 0x01 will also write to 0x02 and 0x04 (clobbering the time).
 > > Right, this is an (incorrect) hybrid of a few attempts, probably from
 > > around the time I lost my SSD and only had a single backup copy of my
 > > work to go from.  In one revision I had disallowed all multibyte
 > > accesses (width > 8) since IMHO it was more consistent/correct with the
 > > suggested locking.  I wasn't ignoring your suggestion, just making one
 > > or a few changes at a time (generally the simpler ones).
 > 
 > Okay now I remember why I was reluctant to do this - suppose ACPIBIOS
 > does a multibyte op on a set of bytes whose last byte fails
 > acpi_check_rtc_byteaccess().  I will have already performed n-1
 > accesses.  At one point I had a revision (acpi_check_rtc_access()?) that
 > permitted/denied the entire request (it took the starting address and
 > byte length), but I guess that got lost too.  I'll just recreate it...

Yep, validating all access before doing any sounds like the way to go.

Also, bytes = width >> 3 is ok, since you then affirm !(width & 0x07), 
so non-multiples of 8 bits are invalidated anyway.  You should still 
check that width (or bytes) > 0, even if 0 should never be passed.

I guess the Big Kids will start playing once this hits bugzilla? :)

cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: [PATCH] ACPI CMOS region support rev. 4

[Ian Smith]

On Sat, 14 Mar 2015 23:40:34 -0400, Anthony Jenkins wrote:

 > How about this one? :-)  Sorry it's a week late.

+static unsigned int atrtc_verbose = 0;
+SYSCTL_UINT(_debug, OID_AUTO, atrtc_verbose, CTLFLAG_RWTUN,
+   &atrtc_verbose, 0, "AT-RTC Debug Level (0-2)");
+#define ATRTC_DBG_PRINTF(level, format, ...) \
+   if (atrtc_verbose >= level) printf(format, ##__VA_ARGS__)
+

A sysctl is good, but it needs to default to 1 if we're ever going to 
find out what various vendors are wanting to do with CMOS settings; 
anyone annoyed by any extra messages outside boot or suspend/resume 
could turn it off - after we've had the opportunity to get a report.

I can only reiterate part of my message before last, of March 2nd:

===
> +static ACPI_STATUS
> +acpi_rtc_cmos_handler(UINT32 function, ACPI_PHYSICAL_ADDRESS address,
> +UINT32 width, UINT64 *value, void *context, void *region_context)
> +{
> +struct atrtc_softc *sc;
> +
> +sc = (struct atrtc_softc *)context;
> +if (!value || !sc)
> +return AE_BAD_PARAMETER;
> +if (width > 32 || (width & 0x07) || address >= 64)
> +return AE_BAD_PARAMETER;

Width 0 passes, and address 61 width 32 passes.  Maybe simpler:
int bytes;  /* or size, whatever, above */
bytes = width >> 3;
and substitute 'bytes' subsequently, and here, perhaps:

if (bytes < 1 || bytes > 4 || (width & 0x07) || address > (64 - bytes))

> +if (!acpi_check_rtc_byteaccess(function == ACPI_READ, address))
> +return AE_BAD_PARAMETER;

acpi_check_rtc_byteaccess() needs to be called per byte of 1, 2 or 4 
bytes - or pass it 'bytes' also, and loop over each of them within?
===

Otherwise (for example) a 2 byte read from 0x0b or 4 byte read from 
0x09-0x0b will read 0x0c (clearing interrupts), or a 2 or 4 byte write 
to (say) 0x01 will also write to 0x02 and 0x04 (clobbering the time).

Sorry if I'm too much of a stickler for defensive programming ..

cheers, IanIndex: sys/x86/isa/atrtc.c
===
--- sys/x86/isa/atrtc.c	(revision 279957)
+++ sys/x86/isa/atrtc.c	(working copy)
@@ -31,6 +31,7 @@
 __FBSDID("$FreeBSD$");
 
 #include "opt_isa.h"
+#include "opt_acpi.h"
 
 #include 
 #include 
@@ -53,9 +54,17 @@
 #include 
 #include "clock_if.h"
 
+#include 
+#include 
+#include 
+
 #define	RTC_LOCK	do { if (!kdb_active) mtx_lock_spin(&clock_lock); } while (0)
 #define	RTC_UNLOCK	do { if (!kdb_active) mtx_unlock_spin(&clock_lock); } while (0)
 
+#define IO_DELAY()	(void)inb(0x84)
+#define IO_RTC_ADDR	(IO_RTC + 0)
+#define IO_RTC_DATA	(IO_RTC + 1)
+
 int	atrtcclock_disable = 0;
 
 static	int	rtc_reg = -1;
@@ -62,6 +71,12 @@
 static	u_char	rtc_statusa = RTCSA_DIVIDER | RTCSA_NOPROF;
 static	u_char	rtc_statusb = RTCSB_24HR;
 
+static unsigned int atrtc_verbose = 0;
+SYSCTL_UINT(_debug, OID_AUTO, atrtc_verbose, CTLFLAG_RWTUN,
+	&atrtc_verbose, 0, "AT-RTC Debug Level (0-2)");
+#define ATRTC_DBG_PRINTF(level, format, ...) \
+	if (atrtc_verbose >= level) printf(format, ##__VA_ARGS__)
+
 /*
  * RTC support routines
  */
@@ -73,10 +88,10 @@
 
 	RTC_LOCK;
 	if (rtc_reg != reg) {
-		inb(0x84);
+		IO_DELAY();
 		outb(IO_RTC, reg);
 		rtc_reg = reg;
-		inb(0x84);
+		IO_DELAY();
 	}
 	val = inb(IO_RTC + 1);
 	RTC_UNLOCK;
@@ -89,16 +104,36 @@
 
 	RTC_LOCK;
 	if (rtc_reg != reg) {
-		inb(0x84);
+		IO_DELAY();
 		outb(IO_RTC, reg);
 		rtc_reg = reg;
-		inb(0x84);
+		IO_DELAY();
 	}
 	outb(IO_RTC + 1, val);
-	inb(0x84);
+	IO_DELAY();
 	RTC_UNLOCK;
 }
 
+static void
+acpi_cmos_read(ACPI_PHYSICAL_ADDRESS address, UINT8 *buf, UINT32 buflen)
+{
+	UINT32 offset;
+
+	for (offset = 0; offset < buflen; ++offset) {
+		buf[offset] = rtcin(address + offset) & 0xff;
+	}
+}
+
+static void
+acpi_cmos_write(ACPI_PHYSICAL_ADDRESS address, const UINT8 *buf, UINT32 buflen)
+{
+	UINT32 offset;
+
+	for (offset = 0; offset < buflen; ++offset) {
+		writertc(address + offset, buf[offset]);
+	}
+}
+
 static __inline int
 readrtc(int port)
 {
@@ -161,9 +196,68 @@
 	struct resource *intr_res;
 	void *intr_handler;
 	struct eventtimer et;
+	ACPI_HANDLE acpi_handle;	/* Handle of the PNP0B00 node */
+	int acpi_handle_registered;	/* 0 = acpi_handle not registered */
 };
 
 static int
+acpi_check_rtc_byteaccess(int is_read, u_long addr)
+{
+	int retval = 1;	/* Success */
+
+	if (is_read) {
+		/* Reading 0x0C will muck with interrupts */
+		if (addr == 0x0C)
+			retval = 0;
+	} else {
+		if (!((addr <= 0x05 && (addr & 0x01)) ||
+		   (addr >= 0x30 && addr < 0x40)))
+			retval = 0;
+	}
+	return retval;
+}
+
+static ACPI_STATUS
+acpi_rtc_cmos_handler(UINT32 function, ACPI_PHYSICAL_ADDRESS address,
+UINT32 width, UINT64 *value, void *context, void *region_context)
+{
+	struct atrtc_softc *sc;
+
+	sc = (struct atrtc_softc *)context;
+	if (!value || !sc) {
+		ATRTC_DBG_PRINTF(1, "%s: NULL parameter.\n", __FUNCTION__);
+		return AE_BAD_PARAMETER;
+	}
+	if (width > 32 || (width & 0x07) || address >= 64) 

Re: [PATCH] ACPI CMOS region support rev. 3 [was Re: No acpi_dell(4)]

[Ian Smith]

On Tue, 3 Mar 2015 11:45:49 -0500, Anthony Jenkins wrote:
 > On 03/01/2015 09:29 AM, Ian Smith wrote:
 [..]
 > No problem adding logging.  The bit I'm confused about (unless I'm
 > misunderstanding the argument) is why
 > 
 > # ugly pseudocode
 > function original_cmos_xfer():
 > lock();
 > transfer byte to/from CMOS
 > unlock();
 > 
 > function acpi_cmos_xfer():
 > foreach byte in num_bytes:
 > call original_cmos_xfer(byte)
 > end foreach
 > 
 > 
 > is preferable to
 > 
 > # ugly pseudocode
 > function acpi_cmos_xfer():
 > lock();
 > foreachbyte in num_bytes:
 > transfer byte to/from CMOS
 > end foreach
 > unlock();
 > 
 > function original_cmos_xfer():
 > call acpi_cmos_xfer(num_bytes = 1);
 > 
 > 
 > There was no "extra locking", but I did introduce an extra function call
 > which would slow down CMOS accesses to the RTC for some performance
 > timers; I assume that's the main complaint.

And slow down all other callers of rtcin() and writertc(), as well as 
any timer using the RTC periodic interrupt.  Most callers are right here 
in /sys/x86/isa/atrtc.c; I make it 37 plus another 9 #ifdef DDB.  This 
works for me on a 9.3-R system, not checked on 10.x or head ..

smithi@x200:~ % find /usr/src -type f -name "*.[ch]" \
-exec egrep -Hl 'rtcin\(|writertc\(|readrtc\(' {} + | xargs less
:/rtcin|writertc|readrtc

All in /sys/ of course.  Ignoring mips/malta, most callers likely don't 
care if these calls take twice(?) as long, but to me it seems suboptimal 
to impede likely more frequently used calls for the sake of a much less 
frequently used high-level function, that itself is not timing-critical.

I know nothing about how much xen/clock.c cares about timing.  nvram.c 
doesn't seem bothered, nor fetching memory size, fdc or vga parameters.

On the other hand, interrupt service needs to care a lot about timing.  
Remember that FreeBSD is running on other than latest kit, including eg 
266MHz 5x86 Soekris routers and the like, and smaller embedded systems 
that may very well need not to have RTC ISRs time-pessimised, at up to 
8kHz rates; such are also less likely to have HPETs to use as timers.

And for that matter, many older and smaller boards are unlikely to be 
running ACPI BIOS at all - which brings up another question, below ..

 > To me, the former
 > pseudocode is "incorrect" because it allows the possibility of another
 > thread of execution mucking with a multibyte CMOS access by ACPIBIOS.  I
 > agree it's /probably/ unlikely tho.

I've no idea whether that may be possible, or if or how it might matter.

But all that's just me, the Time Lords are likely having a good laugh :)


Regarding systems without ACPI loaded, or active: what happens when the 
below AcpiInstallAddressSpaceHandler() call fails, but returns 0?  Would 
not that prevent rtc_start() from running atrtc_start() etc for non-ACPI 
clock initialisation and registration?

I suppose there's a global kernel variable for acpi_is_active ono?

 > +static int
 >  rtc_start(struct eventtimer *et, sbintime_t first, sbintime_t period)
 >  {
 >
 > @@ -245,10 +323,17 @@
 >  int i;
 >
 >  sc = device_get_softc(dev);
 > +sc->acpi_handle = acpi_get_handle(dev);
 >  sc->port_res = bus_alloc_resource(dev, SYS_RES_IOPORT, &sc->port_rid,
 >  IO_RTC, IO_RTC + 1, 2, RF_ACTIVE);
 >  if (sc->port_res == NULL)
 >  device_printf(dev, "Warning: Couldn't map I/O.\n");
 > +if (ACPI_FAILURE(AcpiInstallAddressSpaceHandler(sc->acpi_handle,
 > +ACPI_ADR_SPACE_CMOS, acpi_rtc_cmos_handler, NULL, sc)))
 > +{
 > +device_printf(dev, "Error registering ACPI CMOS address space 
 > handler.\n");
 > +return 0;
 > +}
 >  atrtc_start();
 >  clock_register(dev, 100);
 >  bzero(&sc->et, sizeof(struct eventtimer));
 > @@ -286,6 +371,15 @@
 >  return(0);
 >  }
 
Might that not matter for detach, as you're not testing for return code?

 > +static int atrtc_detach(device_t dev)
 > +{
 > +struct atrtc_softc *sc;
 > +
 > +sc = device_get_softc(dev);
 > +AcpiRemoveAddressSpaceHandler(sc->acpi_handle, 
 >  ACPI_ADR_SPACE_CMOS, acpi_rtc_cmos_handler);
 > +return bus_generic_detach(dev);
 > +}
 
cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: [PATCH] ACPI CMOS region support rev. 3 [was Re: No acpi_dell(4)]

[Ian Smith]

On Fri, 27 Feb 2015 23:26:16 -0500, Anthony Jenkins wrote:
> On 02/27/15 21:56, Bruce Evans wrote:
> > On Sat, 28 Feb 2015, Ian Smith wrote:

I'm going to contract this down to a couple of points, ok fellas?

> > > Don't worry about any extra locking; this is going to be used at boot
> > > and/or resume we assume;
> 
> Bleah... I hate assumptions like that.


So let's log everything at least while this is experimental in head, get 
lots of people using all sorts of hardware to report any surprises, and 
find out whenever else such service might be requested?


Sure, add a sysctl hw.acpi.cmosaccess.STFU for when we find benign stuff 
being logged at other times than boot and suspend/resume, but when Jo 
Blo reports here or in questions@ or laptop@ that her Hidden Dragon 
Kneetop won't boot / suspend / resume / whatever with these funny lines 
in /var/log/messages, we'll know what it's about without undertaling the 
sort of research you had to do to get your HP Envy going, eh? :)


% sysctl smithi.STFU=1  # enough already ..

> +static ACPI_STATUS
> +acpi_rtc_cmos_handler(UINT32 function, ACPI_PHYSICAL_ADDRESS address,
> +UINT32 width, UINT64 *value, void *context, void *region_context)
> +{
> +struct atrtc_softc *sc;
> +
> +sc = (struct atrtc_softc *)context;
> +if (!value || !sc)
> +return AE_BAD_PARAMETER;
> +if (width > 32 || (width & 0x07) || address >= 64)
> +return AE_BAD_PARAMETER;

Width 0 passes, and address 61 width 32 passes.  Maybe simpler:
int bytes;  /* or size, whatever, above */
bytes = width >> 3;
and substitute 'bytes' subsequently, and here, perhaps:

if (bytes < 1 || bytes > 4 || (width & 0x07) || address > (64 - bytes))

> +if (!acpi_check_rtc_byteaccess(function == ACPI_READ, address))
> +return AE_BAD_PARAMETER;

acpi_check_rtc_byteaccess() needs to be called per byte of 1, 2 or 4 
bytes - or pass it 'bytes' also, and loop over each of them within?


Failing this _really_ needs a printf, as below + 'REJECTED' ono, IMO.

> +
> +switch (function) {
> +case ACPI_READ:
> +acpi_cmos_read(address, (UINT8 *)value, width >> 3);
> +break;
> +case ACPI_WRITE:
> +acpi_cmos_write(address, (const UINT8 *)value,
> +width >> 3);
> +break;
> +default:
> +return AE_BAD_PARAMETER;
> +}
> +printf("%s: %-5s%02u address=%04lx value=%08x\n",
> +__FUNCTION__, function == ACPI_READ ? "READ" : "WRITE", width >> 3,
> +address, *((UINT32 *)value));
> +return AE_OK;
> +}

cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: [PATCH] ACPI CMOS region support rev. 3 [was Re: No acpi_dell(4)]

[Ian Smith]

On Thu, 26 Feb 2015 10:35:57 -0500, Anthony Jenkins wrote:
 > On 02/25/2015 02:53 PM, John Baldwin wrote:
 > > On Monday, February 23, 2015 03:22:57 PM Anthony Jenkins wrote:
 [.. omissions reflecting change of subject ..]
 > >> I'd like to make the acpi_wmi(4) interface easier to use, but my backlog
 > >> of contributions I'm sitting on is only growing.

 > > I've been waiting to see if you were going to post an update to rev 3 of 
 > > your 
 > > CMOS patch after Ian's last round of feedback FWIW.  Much of his feedback 
 > > seemed relevant (and I know you've already accepted some other rounds of 
 > > feedback on that patch before then, hence 'v3')
 > >
 > I am... I've just been stalling, mostly because it "works for me" and I
 > didn't understand some of the critiques, particularly the
 > "pessimization" one (over my head I think).  I'll toss what I have out
 > there for further review; I'll shoot for today or tomorrow.
 > 
 > One of the things I felt I had to do in the CMOS handler was allow ACPI
 > to perform multibyte accesses to the CMOS region, but the existing CMOS
 > read/write functions were only byte accessors, and each byte access was
 > locked.  A multibyte access would lock, read/write a byte, unlock, lock,
 > read/write a byte, unlock  So I wrote multibyte accessors (which had
 > some issues I think I corrected) and had the original RTC CMOS accessor
 > functions call the multibyte ones.  The multibyte accessors performed
 > the locking, so a multibyte access would lock, read/write a byte,
 > read/write a byte..., unlock.
 > 
 > I believe one of the recommendations was to "put it back the way it
 > was", which I did, along with failing any attempt by ACPIBIOS to access
 > multiple bytes.

You can safely ignore the deeper and rather sideways discussion Bruce 
and I engaged in; I was bewildered by the idea of 'good pessimisations' 
too, which is why I pursued it, arguably too far, but I learned things.

However the takeaway was agreement that for multiple reasons, multibyte 
acpi_cmos access should loop on using the system rtcin() and writertc() 
as is - modulo your useful macros esp. IO_DELAY() documenting inb(0x84) 
- and that setting bit 7 on IO_RTC_ADDR, _possibly_ disabling NMI on 
some older hardware, is inadvisable.  As you pointed out, PNP0B00 only 
wants to access CMOS from 0x00-0x3f anyway, so why not just mask reg 
with 0x3f while calling rtcin()/writertc() ?

Don't worry about any extra locking; this is going to be used at boot 
and/or resume we assume; atrtc_settime() for one is called by default 
every 1800 seconds if running ntpd, and it doesn't bother holding the 
lock through multiple writertc() calls.  Any (optional) user of the RTC 
as an interval timer source, particularly at high rates, will appreciate
the existing pre-selection of last register used, as Bruce explained.

I'm unsure whether any stats or profiling still uses the RTC at all?
kern.clockrate: { hz = 1000, tick = 1000, profhz = 8126, stathz = 127 }

So I would suggest:

. reading any bytes except 0x0c is safe (though in the case of time or 
  date bytes, possibly invalid if read while what the datasheet calls 
  the UIP bit is set):
  #define RTC_STATUSA 0x0a/* status register A */
  #define  RTCSA_TUP   0x80   /* time update, don't look now */

. the only conceivable bytes permissable to allow writing are:

  . below 0x10: bytes 1, 3 and 5 (alarm seconds, minute, hour).  While
they're no use whilever we don't support wake on alarm and should
also be written during non-update periods, should be safe enough.

  . 0x10 - 0x2f: none, unless you're prepared to copy the procedure in
/sys/dev/nvram/nvram.c to calculate and write the checksum to 0x2e 
and 0x2f.  I think we should just deny and log such access, unless
and until someone shows log messages demonstrating a perceived need.

  . 0x30 through 0x3f: I guess you could allow write access, at least I
haven't heard of anything using that area for anything, but check ..
I recall reading that we don't use this, at least on x86:
#define RTC_CENTURY 0x32/* current century */

  . in any case, log all access, accepted or denied, at kern.notice ono.
  > acpi_rtc_cmos_handler: READ 01 address=0006 value=0006
  > acpi_rtc_cmos_handler: READ 01 address=0004 value=0015
  > acpi_rtc_cmos_handler: READ 01 address=0002 value=0006
Bruce called them ugly, but I'm happy such access is so obvious ..

 > I think the reason behind having an ACPI CMOS handler is to give the OS
 > a say when ACPIBIOS wants to access CMOS, to prevent it from stepping on
 > the toes of an RTC CMOS driver who's also twiddling CMOS registers and
 > (presumably) knows the state of the device.

Indeed.  Virtually all of the state, apart from the default reset state, 
is stored in RTC status/control registers, though different consumers 
presumably know more.  I haven't explored the code that may use the RTC 
as an eve

Re: Laptop Battery drains insanely Fast!

[Ian Smith]

On Thu, 12 Feb 2015 17:55:56 +0200, george ember wrote:

 > Also I don't know if helps
 > *$ sysctl hw.acpi.battery*
 > hw.acpi.battery.life: 22
 > hw.acpi.battery.time: 53
 > hw.acpi.battery.state: 1
 > hw.acpi.battery.units: 1
 > hw.acpi.battery.info_expire: 5

 > I guess that means 53 minutes already working / 22% power left on
 > battery. Sounds bad :(

smithi@x200:~ % sysctl -d hw.acpi.battery
hw.acpi.battery: battery status and info
hw.acpi.battery.life: percent capacity remaining
hw.acpi.battery.time: remaining time in minutes
hw.acpi.battery.state: current status flags
hw.acpi.battery.units: number of batteries
hw.acpi.battery.info_expire: time in seconds until info is refreshed

53 minutes remaining at 22% still works out to ~4 hours total, assuming 
it shows 100% when fully charged, after having been fully discharged.

cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: Laptop Battery drains insanely Fast!

[Ian Smith]

On Thu, 12 Feb 2015 17:36:00 +0200, george ember wrote:

 > Ok. I will try to write them more clear [?]
 >
 > My $ *sudo kldstat -v | grep ibm*
 >
 >  21 0x81956000 7808 acpi_ibm.ko (/boot/kernel/acpi_ibm.ko)  
 > 1 acpi/acpi_ibm

But sysctl dev.acpi_ibm still says nothing?  Weird.  Anybody have a clue?

Anything in /var/log/meesages about any failure regarding acpi_ibm?

 > PS: My battery still dropping too fast. The last five minutes dropped 
 > from 37% to 33% and is just open doing nothing!

So now you can report battery state, power used, time remaining etc.

If you let it fully discharge the battery then fully charge it up, it 
should recalibrate the chip inside the battery that calculates usage and 
reports state.  I did that recently and recovered about 5% that had been 
'lost' after months on AC.  Before that it had run for nearly 40 minutes 
from a reported (and unchanging) "5%" which was clearly not really the 
case, before hitting 3% then counting down properly until discharged.

You could try running your ./stat script (or relevant portions) every 
minute (for example) to a file while [dis]charging, maybe like this:

#!/bin/sh
sleep=60
outfile=/path/to/somefile
while true; do
/path/to/stat >> "$outfile" # any user can run this
echo "" # or some cute delimiter
sleep $sleep
done

Then watch it if desired by '% tail -f /path/to/somefile'

Of course you will see power use and load average change and perhaps 
proportion of C2/C3 states change as you do things to make it busy ..

cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: Laptop Battery drains insanely Fast!

[Ian Smith]

passive 
cooling potential, but I suppose it relies on the fan.

===
Now for the script, I have a little problem

The script now:

#!/bin/sh
t=" "   # a tab
echo -n "`date` "
sysctl dev.cpu.0.freq
echo "`sysctl -n dev.cpu.2.cx_usage` $t `sysctl -n vm.loadavg`"
echo "`sysctl -n dev.cpu.7.cx_usage` $t { `sysctl -n kern.eventtimer.timer` }"
sysctl dev.acpi_ibm | egrep 'fan_|thermal'
sysctl hw.acpi.thermal.tz0.temperature
acpiconf -i0 | egrep 'State|Remain|Present|Volt'

And

*sudo kldload acpi_ibm*
Password:
kldload: can't load acpi_ibm: module already loaded or in kernel

but

$ ./stat
Fri Feb 13 16:11:11 EET 2015 dev.cpu.0.freq: 1200
0.13% 0.11% 99.75% last 60305us   { 0.12 0.10 0.08 }
0.06% 0.06% 99.87% last 2029us   { LAPIC }
*sysctl: unknown oid 'dev.acpi_ibm': No such file or directory*
hw.acpi.thermal.tz0.temperature: 45.0C
State:discharging
Remaining capacity:46%
Remaining time:1:58
Present rate:9940 mW
Present voltage:14128 mV
===

Again, looking good for ~4 hours at idle.  If you get the video stuff 
sorted out - I know next to nothing about that - might save some more.

I've no idea what's wrong with acpi_ibm here.  I suppose that
 # kldstat -v | grep ibm
produces no output?  Maybe it doesn't work with this model?  Anyone?


===
ÿÿPS: Please do not get angry with me. I am from Greece. I don't speak good
English. I learned alone through FreeBSD forum!
===

Wouldn't dream of it.  You're doing fine.

Not top-posting - M$ outlock style - would be a nice touch though :)

cheers, Ian

===
2015-02-12 11:39 GMT+02:00 Ian Smith :
[..]
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: Laptop Battery drains insanely Fast!

[Ian Smith]

On Thu, 12 Feb 2015 20:39:14 +1100, Ian Smith wrote:

 > Thu Feb 12 20:12:47 EST 2015 dev.cpu.0.freq: 800
 > 0.79% 12.31% 86.89% last 694us   { 0.51 0.55 0.50 }
 > 0.64% 11.17% 88.17% last 227us   { HPET }
 > [..]
 > Ignore these load average figures shown with HPET timecounter, they're 
 > utter nonsense, this system is completely idle, and shows 0.00 0.00 0.00 
 > when using LAPIC timecounter - but that's an entirely separate issue :)

Sorry, both instances of 'timecounter' should read 'eventcounter' there. 
I'm working up to a post about these bogus load averages with HPET soon.

cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: Laptop Battery drains insanely Fast!

[Ian Smith]

On Wed, 11 Feb 2015 18:38:45 +0200, george ember wrote:

 > Hi. I have a lenovo Ideapad p400 touchscreen.
 > My problem is the battery.
 > Drains too fast. In idle ~1% per minute!!!
 > I tried almost everything but my battery still loses power extremely fast!
 > This is my post on FreeBSD forum
 > https://forums.freebsd.org/threads/laptop-battery-drains-extremly-fast.50344/
 > I don't like Linux. I am FreeBSD user almost 5 years. I don't want to
 > install again Linux on laptop.
 > I just want to make it work smooth with FreeBSD.
 > Any help could be appreciated.
 > George (sk8harddiefast on forum)

George, I read the forum post, but prefer to reply here, though I'll 
quote from bits there. There are a number of issues with your setup:

1) powerd:

 > powerd_enable="YES"
 > powerd_flags="-a maximum -b adaptive -i 85 -r 60 -p 100"

You shouldn't have -i (idle%) higher than -r (run%).  The defaults are 
-i 50 -r 75 and I suggest you start with those.  I use -i 70 -r 85 here 
on my X200 (Core2Duo 2.4GHz).  And -p 100 is polling faster than you 
need, increasing powerd's load somewhat.  The default of -p 250 is fine.

-a max is unnecessary.  -a hadp will work fine, especially as you've 
correctly disabled p4tcc and acpi_throttle in loader.conf, when you're 
doing things - but allow it to idle at a lower freq, which will reduce 
heat buildup on AC and perhaps fan usage on battery, at least initially.

2) C-states:

You have (misadvisedly) in /etc/sysctl.conf
 > dev.cpu.0.cx_lowest=C5
 > dev.cpu.1.cx_lowest=C2
 > dev.cpu.2.cx_lowest=C5
 > dev.cpu.3.cx_lowest=C5
 > dev.cpu.4.cx_lowest=C5
 > dev.cpu.5.cx_lowest=C5
 > dev.cpu.6.cx_lowest=C5
 > dev.cpu.7.cx_lowest=C5

Apart from the oddity of C2 on cpu1, setting these is NOT the way to do 
this, you have to set hw.acpi.cpu.cx_lowest instead, then cpufreq(4) 
uses that to set the individual cx_lowest per CPU (and all to the same 
state) which is usually and best accomplished by setting the below in 
rc.conf, as stated in https://wiki.freebsd.org/TuningPowerConsumption :

 performance_cx_lowest="Cmax"
 economy_cx_lowest="Cmax"

I expect Adrian will say more, but it looks to me that you're always
running in C1 state by your report at http://pastebin.com/GUJQqtX6
which is consistent with use of the defaults for *_cx_lowest as applied 
in /etc/defaults/rc.conf of:
 performance_cx_lowest="HIGH"# Online CPU idle state
 economy_cx_lowest="HIGH"# Offline CPU idle state

If you examine /etc/rc.d/power_profile you will see how these are used, 
along with the defaults of {performance,economy}_cpu_freq="NONE" which 
you should leave as is, to avoid conflicting with powerd when you apply 
or remove AC power.

Running in C1 all the time, it's no surprise your battery not lasting.

3) I didn't see mention in dmesg of loading acpi_ibm in loader.conf, 
which may help at least provide details for the script below, if it 
doesn't improve your access to Lenovo special Fn keys etc:
 
 acpi_ibm_load="YES"# or just '# kldload acpi_ibm' while running

4) please show output of
 sysctl -a | egrep 'cx|freq_'

5) try putting this script, suitably renamed, somewhere in $PATH.  It 
doesn't needroot access to run, I also have it (as a link) in ~/bin/

root@x200:~ # cat /root/bin/x200stat
#!/bin/sh
t=" "   # a tab
echo -n "`date` "
sysctl dev.cpu.0.freq
echo "`sysctl -n dev.cpu.0.cx_usage` $t `sysctl -n vm.loadavg`"
echo "`sysctl -n dev.cpu.1.cx_usage` $t { `sysctl -n kern.eventtimer.timer` }"
sysctl dev.acpi_ibm | egrep 'fan_|thermal'
sysctl hw.acpi.thermal.tz0.temperature
sysctl hw.acpi.thermal.tz1.temperature
acpiconf -i0 | egrep 'State|Remain|Present|Volt'

to which I would add in the approriate place for yours:
 echo "`sysctl -n dev.cpu.2.cx_usage`"
 through
 echo "`sysctl -n dev.cpu.7.cx_usage`"
and if yours has more thermal zones, those also.

This provides a convenient way to see how things are going, as it shows 
C-state usage and power comsumption (when on battery) directly:

Thu Feb 12 20:12:47 EST 2015 dev.cpu.0.freq: 800
0.79% 12.31% 86.89% last 694us   { 0.51 0.55 0.50 }
0.64% 11.17% 88.17% last 227us   { HPET }
dev.acpi_ibm.0.fan_speed: 3363
dev.acpi_ibm.0.fan_level: 0
dev.acpi_ibm.0.thermal: 39 41 -1 39 34 -1 33 -1
hw.acpi.thermal.tz0.temperature: 39.0C
hw.acpi.thermal.tz1.temperature: 36.0C
State:  high
Remaining capacity: 99%
Remaining time: unknown
Present rate:   0 mW
Present voltage:12413 mV

Ignore these load average figures shown with HPET timecounter, they're 
utter nonsense, this system is completely idle, and shows 0.00 0.00 0.00 
when using LAPIC timecounter - but that's an entirely separate issue :)

6) of course it's possible you have a dud battery, but if you get powerd 
and C-states working right you should see quite an improvement.

7) Your girlfriend is cuter than you :)

cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailma

Re: Problem reports for freebsd-acpi@FreeBSD.org that need special attention

[Ian Smith]

On Mon, 2 Feb 2015 16:14:37 +1100, Ian Smith wrote:

 > Reading the PR, it's not clear to me why this is still open?

Oops, about three minutes too fast on the trigger .. onya, Adrian!
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: Problem reports for freebsd-acpi@FreeBSD.org that need special attention

[Ian Smith]

On Sun, 1 Feb 2015 21:00:25 +, bugzilla-nore...@freebsd.org wrote:

 > Status  |Bug Id | Description
 > +---+---
 > Open|194884 | [acpi] Asus UX31E USB hangs during suspend, due t 
 > 
 > 1 problems total for which you should take action.

Reading the PR, it's not clear to me why this is still open?

cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: [Bug 162859] [acpi] ACPI battery/acline monitoring partialy working (switching)

[Ian Smith]

On Thu, 8 Jan 2015 21:30:10 +1100, Ian Smith wrote:

 > So it seems; I'll post a proper response based on the text above and my 
 > musings below to bugzilla .. such details are important, and I should 
 > have been game to speculate there originally, my apologies to all.

Argh.  After spending 10 minutes formatting a response to juris' message 
on bugzilla - yes, logged in - I couldn't find any sort of 'submit' 
button anywhere to actually post my message?

So I went to mark and copy my response and somehow lost the contents in 
the process.  Subsequent attempts to even get back to the bug were met 
with "Data Transfer Interrupted The connection to bugs.freebsd.org has 
terminated unexpectedly. Some data may have been transferred." after 
first warning of transferring to a non-encrypted page.  I'd also added 
myself as a cc but again there seemed no way to submit any of it.

Might my old Seamonkey lack some javascript thingy bugzilla needs?  I'll 
try again later, but can someone whack me with a clue please?

Confused, Ian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: [Bug 162859] [acpi] ACPI battery/acline monitoring partialy working (switching)

[Ian Smith]

On Wed, 7 Jan 2015 20:23:51 +0200, Juris Kaminskis wrote:
 > 2015-01-05 17:27 GMT+02:00 Juris Kaminskis :

 > > 2015-01-04 15:17 GMT+02:00 Ian Smith :
 > > >
 > > > On Sat, 3 Jan 2015 11:45:05 +, bugzilla-nore...@freebsd.org wrote:
 > > >
 > > > Please excuse this off-'zilla merely speculative response.  No time, but
 > > > I've spent (wasted?) some time chasing a couple of these outside the PR.
 > > >
 > > >  > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=162859
 > > >  >
 > > >  > --- Comment #14 from juris  ---
 > > >  > Problem on /head/ branch is introduced with revision 216942.
 > > >
 > > > If true (in all cases) this is great news for those with a variety of HP
 > > > laptops that have been experiencing partial - or in some cases complete
 > > > after boot - failures in CMBAT monitoring since 9.0.  And a Macbook Pro.
 > > >
 > > > So, reverting rev 216942 fixes it for you?  On what FreeBSD version?
 > >
 > > I have compiled head branch revision 216941 and battery status via
 > > acpiconf works. When compiling from source revision 216942 acpiconf stops
 > > responding. I also tried to remove r216942 and compiled from source release
 > > 9.3, but there battery status was not working. Apparently there are more
 > > things than just one that breaks HP ACPI .

 > Sorry for my previous email that was confusing. I did not revert r216941
 > when compiled release 9.3. So when I did that, battery status works. I also
 > compiled release 10.1 with excluding r216942, and battery status works. So
 > this single change for some reason creates problem for HP laptops.

So it seems; I'll post a proper response based on the text above and my 
musings below to bugzilla .. such details are important, and I should 
have been game to speculate there originally, my apologies to all.

It's important to note that this PR was originally filed on 2011-11-24 
21:50 UTC by msuszko, at version 9.0-PRERELEASE.  revision 216942 was 
committed to head on Jan 4 00:10:29 2011 UTC (4 years ago) by jkim, 
while head was 9-CURRENT, and hasn't changed since.  It seems fortunate, 
for HP laptops anyway, that this was not apparently merged back to 8.x.

cheers, Ian

 > > > If so, with scant comprehension of the code, questions that occur:
 > > >
 > > > a) did that revision fix some existing problem, the reverting of which
 > > > might reestablish problem/s in other machines?  jkim?
 > > >
 > > > b) what is it in various HP ACPI implementations that don't seem to be a
 > > > reported problem on other hardware, particularly concerning EC handling?
 > > >
 > > > c) if this was wrong (for HPs), what would be right?  (the hard one :)
 > > >
 > > > cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: [Bug 162859] [acpi] ACPI battery/acline monitoring partialy working (switching)

[Ian Smith]

On Sat, 3 Jan 2015 11:45:05 +, bugzilla-nore...@freebsd.org wrote:

Please excuse this off-'zilla merely speculative response.  No time, but 
I've spent (wasted?) some time chasing a couple of these outside the PR.

 > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=162859
 > 
 > --- Comment #14 from juris  ---
 > Problem on /head/ branch is introduced with revision 216942.

If true (in all cases) this is great news for those with a variety of HP 
laptops that have been experiencing partial - or in some cases complete 
after boot - failures in CMBAT monitoring since 9.0.  And a Macbook Pro.

So, reverting rev 216942 fixes it for you?  On what FreeBSD version?

If so, with scant comprehension of the code, questions that occur:

a) did that revision fix some existing problem, the reverting of which 
might reestablish problem/s in other machines?  jkim?

b) what is it in various HP ACPI implementations that don't seem to be a 
reported problem on other hardware, particularly concerning EC handling?

c) if this was wrong (for HPs), what would be right?  (the hard one :)

cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: ENXIOing non-present battery

[Ian Smith]

On Fri, 12 Dec 2014 14:36:18 -0800, Colin Percival wrote:
 > On 12/12/14 07:21, John Baldwin wrote:
 > > On Thursday, December 11, 2014 01:05:49 PM Colin Percival wrote:
 > >> On 12/11/14 11:08, John Baldwin wrote:
 > >>> Does setting hint.battery.1.disabled=1 work for you?
 > >>
 > >> That fixes the dev.battery sysctls and KDE's battery monitor.  The
 > >> hw.acpi.battery.units sysctl still reports "2", and `acpiconf -i 1`
 > >> still reports the phantom battery; but I suppose those don't matter
 > >> much...
 > > 
 > > Ok.  That is the "generic" thing we already have in place to disable 
 > > devices,
 > > so I'd probably prefer to use that as the known workaround rather than 
 > > adding
 > > another knob.
 > 
 > OK, I'll stick to using that one.  My original thinking was that disabling
 > "whatever isn't present" would avoid the need for a user to figure out which
 > number it was; but it's probably safe to assume that batteries will always
 > be probed in the same order...

I believe so, given that they're enumerated that way in the AML, and 
disassemble to such as BAT0 and BAT1.

On my X200 for instance, there's quite a bit of ASL code about whether 
it's docked or not controlling BATn notifications, as with these and 
some HPs I've tried to follow that's where a second battery may live.

It wouldn't surprise me to find 'DCK' or similar symbols in your ASL, 
and BAT0 or BAT1 conditionally enabled (or visible) or not, assuming 
there'd be a dock available for that model, or family?

 > > That said, it looks like we report the userland state of "not
 > > present" correctly.  I wonder if the bug is in KDE itself and its
 > > FreeBSD-specific power management bits (rather than hald)?
 > 
 > The FreeBSD-specific userland bits are in hald.

I've yet to update my 9.3-PRE X200 to new Xorg and a later KDE than that 
installed at 9.2-R, and disabled what I could of KDE's power mgmt stuff, 
but haven't noticed reports of other laptops having this specific issue.

Maybe hald is being misinformed?  Care to put up the acpidump somewhere? 
Not that I could follow it well enough to debug, if that were the issue, 
but there might be an obvious clue ..

Though you may be happy with the workaround and have other stuff to do!

cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: ENXIOing non-present battery

[Ian Smith]

On Tue, 9 Dec 2014 10:42:39 +0100, Dan Lukes wrote:
 > On 12/09/14 06:33, Ian Smith:
 > > Normally with 2 batteries catered for and only one fitted you'd expect to
 > > see
 > 
 > > battery1:  on acpi0
 > > battery1: battery initialization start
 > > battery1: battery initialization failed, giving up
 > 
 > Just for the completeness ...
 > 
 > ... it is expected behavior for non-present battery. Relevant part of code
 > (sys/dev/acpica/acpi_cmbat.c):
 > 
 > > ACPI_VPRINT(dev, acpi_device_get_parent_softc(dev),
 > > "battery initialization start\n");
 > ...
 > > for (retry = 0; retry < ACPI_CMBAT_RETRY_MAX; retry++,
 > > AcpiOsSleep(1)) {
 > ...
 > > if (!acpi_BatteryIsPresent(dev))
 > > continue;
 > ...
 > > }
 > > 
 > > if (retry == ACPI_CMBAT_RETRY_MAX) {
 > > ACPI_VPRINT(dev, acpi_device_get_parent_softc(dev),
 > > "battery initialization failed, giving up\n");

Yes, I just wanted to eliminate the battery being erroneously detected 
as being present on initialisation.

So this problem seems likely to be down to (at least) one of:

 a) a bug in our ACPI code;
 b) a bug in this machine's AML (which we haven't seen);
 c) a bug in hald.

.. which is hardly helpful, I know.  I had a quick browse of the scripts 
and FreeBSD backend bits of sysutils/hal, and was frankly too horrified 
to consider trying to browse its full sources.

cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: ENXIOing non-present battery

[Ian Smith]

On Mon, 8 Dec 2014 15:27:10 -0800, Adrian Chadd wrote:

 > What's the output of acpiconf -i0 and acpiconf -i1?
 > 
 > I wonder if changing 'state' to something else would keep everything happy.

 > On 8 December 2014 at 15:08, Colin Percival  wrote:
 > > On 12/07/14 08:03, Adrian Chadd wrote:
 > >> How's this work on other systems? KDE on Linux doesn't lose its mind
 > >> if the second battery is totally flat.
 > >
 > > I just booted Ubuntu 14.04, and both "batteries" appear in 
 > > /proc/acpi/battery;
 > > but BAT1 just shows "present: no" without any statistics, and the GUI shows
 > > the correct state for the single present battery.

And what does 'grep battery /var/run/dmesg.boot' have to say?  Normally 
with 2 batteries catered for and only one fitted you'd expect to see eg:

./nicks_acpi/dmesg-bootwithacpi-2-part.txt:battery0:  on acpi0
./nicks_acpi/dmesg-bootwithacpi-2-part.txt:battery1:  on acpi0
./nicks_acpi/dmesg-bootwithacpi-2-part.txt:battery0: battery initialization 
start
./nicks_acpi/dmesg-bootwithacpi-2-part.txt:battery1: battery initialization 
start
./nicks_acpi/dmesg-bootwithacpi-2-part.txt:battery0: battery initialization 
done, tried 1 times
./nicks_acpi/dmesg-bootwithacpi-2-part.txt:battery1: battery initialization 
failed, giving up

cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: Fwd: [Bug 194884] [acpi] Asus UX31E USB hangs during suspend, due to putting the USB controllers into D3 state

[Ian Smith]

On Sat, 8 Nov 2014 22:21:33 -0800, Adrian Chadd wrote:
 > Hi!
 > 
 > Please test this patch! It makes this Asus Zenbook suspend/resume correctly.
 > 
 > (And if you're knowledgable about such things, please comment on its
 > correctness!)
 > 
 > thanks!
 > 
 > 
 > -adrian

and more recently:

 > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194884
 >
 > Adrian Chadd  changed:
 >
 >What|Removed |Added
 > 

 >  Status|In Discussion   |Needs MFC

First, thanks for your earlier detailed respnse to my dumb questions.

Late to the party and short of time, I just hand-applied both patches 
from the commit to head later in this PR to my 9.3-PRE sources of 25th 
Jun and rebuilt its GENERIC amd64 kernel on my Lenovo Thinkpad X200 with 
latest BIOS.  Also previously applied, the vital acpi_powerres.c patch 
so Thinkpads don't lose USB on resume.

Verbose dmesg.boot shows no functional changes with one from back then.

Below is a dmesg diff from a suspend/resume cycle from then, and now.

Apart from the extra ACPI verbosity due to the kids answering the roll, 
and hearing more from PCI as well - all fine by me on a verbose boot - 
what sticks out is that these have at last gone (and good riddance :)

-pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP0: AE_BAD_PARAMETER
-pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP1: AE_BAD_PARAMETER
-pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP2: AE_BAD_PARAMETER
-pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP3: AE_BAD_PARAMETER

but in their place, as it were, appears:

+pcib0: failed to set ACPI power state D2 on \134_SB_.PCI0: AE_BAD_PARAMETER

Now the acpi.c patch was clean, same line number as head.  The pci.c 
patch was amongst other changed context, so may not be behaving as other 
changes in head would have it behave (re MFC) before assuming the +pcib0 
failure listed is real, let alone if it matters; it is new after all.

Note: the below is after an egrep -v 'Kingston|da0|umass|uhub|ugen|em0', 
after checking nothing useful was lost; the old one had a USB stick too, 
and usb hub to port to device mapping changes and/or reorders on resume 
anyway, distracting from seeing just functional differences.

It seems to be running sweet but I haven't stretched its legs at all.

Again, I didn't think it would be helpful to clutter the PR with this ..
sing out if any more detail on anything here might be useful.

cheers, Ian


smithi@x200:/root % cat sus_res.93PRE.pci_acpi_patched.diff
--- sus_res.old22014-11-14 19:39:51.0 +1100
+++ sus_res.new2nd  2014-11-14 23:44:23.0 +1100
@@ -1,43 +1,66 @@
-acpi_button0: sleep button pressed
 acpi_timer0: switching timecounter, HPET -> ACPI-fast
 acpi_lid0: wake_prep enabled for \134_SB_.LID_ (S3)
 acpi_button0: wake_prep enabled for \134_SB_.SLPB (S3)
 pci0:0:28:0: Transition from D0 to D3
 pci0:3:0:0: Transition from D0 to D3
 pci0:0:28:1: Transition from D0 to D3
 pci0:0:28:2: Transition from D0 to D3
 pci0:0:28:3: Transition from D0 to D3
 vga0: saving 4932 bytes of video state
 vga0: saving color palette
-pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP0: AE_BAD_PARAMETER
-pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP1: AE_BAD_PARAMETER
-pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP2: AE_BAD_PARAMETER
-pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP3: AE_BAD_PARAMETER
+pci0:0:2:0: Transition from D0 to D3
+pci0: set ACPI power state D3 on \134_SB_.PCI0.VID_
+pci0:0:2:1: Transition from D0 to D3
+pci0:0:25:0: Transition from D0 to D3
+pci0:0:26:7: Transition from D0 to D3
+pci0: set ACPI power state D3 on \134_SB_.PCI0.EHC1
+pci0:0:27:0: Transition from D0 to D3
+pci0:0:29:7: Transition from D0 to D3
+pci0: set ACPI power state D3 on \134_SB_.PCI0.EHC0
+pci0:0:31:2: Transition from D0 to D3
+pcib0: failed to set ACPI power state D2 on \134_SB_.PCI0: AE_BAD_PARAMETER
 acpi_lid0: run_prep cleaned up for \134_SB_.LID_
 acpi_button0: run_prep cleaned up for \134_SB_.SLPB
+cpu0: set ACPI power state D0 on \134_PR_.CPU0
+cpu1: set ACPI power state D0 on \134_PR_.CPU1
+acpi_sysresource0: set ACPI power state D0 on \134_SB_.MEM_
+acpi_sysresource1: set ACPI power state D0 on \134_SB_.PCI0.LPC_.SIO_
+attimer0: set ACPI power state D0 on \134_SB_.PCI0.LPC_.TIMR
+hpet0: set ACPI power state D0 on \134_SB_.PCI0.LPC_.HPET
+atrtc0: set ACPI power state D0 on \134_SB_.PCI0.LPC_.RTC_
+acpi_ec0: set ACPI power state D0 on \134_SB_.PCI0.LPC_.EC__
+pci_link0: set ACPI power state D0 on \134_SB_.LNKA
+pci_link1: set ACPI power state D0 on \134_SB_.LNKB
+pci_link2: set ACPI power state D0 on \134_SB_.LNKC
+pci_link3: set ACPI power state D0 on \134_SB_.LNKD
+pci_link4: set ACPI power state D0 on \134_SB_.LNKE
+pci_link5: set ACPI power state D0 on \134_SB_.LNKF
+pci_link6: set ACPI power sta

Re: [Bug 194884] [acpi] Asus UX31E USB hangs during suspend, due to putting the USB controllers into D3 state

[Ian Smith]

On Fri, 7 Nov 2014 19:08:58 +, bugzilla-nore...@freebsd.org wrote:

 > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194884
 > 
 > Adrian Chadd  changed:
 > 
 >What|Removed |Added
 > 
 >Assignee|freebsd-b...@freebsd.org|freebsd-acpi@FreeBSD.org

Not loving bugzilla all that much.  I'm going to reply here, after 
reformatting from cut'n'paste; do what thou wilt if anything's useful.

 > The laptop won't suspend with the USB drivers (ehci, xhci) loaded.

Won't suspend, or won't resume?

 > Suspend bounce works fine - everything gets powered down fine, then
 > comes back up.
 >
 > Unloading the USB drivers fixes the problem, but that's hiding the 
 > underlying causes - the trick is the transition of the USB ports into 
 > D3.

 > The ACPI BIOS has this:
 >
 >Device (EHC1)
 > {
 > Name (_ADR, 0x001D)  // _ADR: Address
 > OperationRegion (PWKE, PCI_Config, 0x62, 0x04)
 > Field (PWKE, DWordAcc, NoLock, Preserve)
 > {
 > ,   1, 
 > PWUC,   8
 > }
 >
 > Method (_PSW, 1, NotSerialized)  // _PSW: Power State Wake
 > {
 > If (Arg0)
 > {
 > Store (Ones, PWUC) /* \_SB_.PCI0.EHC1.PWUC */
 > }
 > Else
 > {
 > Store (0x00, PWUC) /* \_SB_.PCI0.EHC1.PWUC */
 > }
 > }
 >
 > Method (_S3D, 0, NotSerialized)  // _S3D: S3 Device State
 > {
 > Return (0x02)
 > }
 >
 > Method (_S4D, 0, NotSerialized)  // _S4D: S4 Device State
 > {
 > Return (0x02)
 > }
 >
 > .. so, we should be trying to put it into D2, not D3.

I can't figure this.  Methods _S3D and _S4D aren't apparently referenced 
or called anywhere else?, and there's nothing similar (I could spot) for 
EHC2.  Are you assuming 0x02 here is the requested power state?  How?

If so, even if it wanted to leave some? power on during suspend, what 
good would that do in S4 (hibernate/STDisk) when the power is turned 
right off? - not that we support that, but W*s and maybe Linux do ..

 > But then:
 >
 > ehci0 pnpinfo vendor=0x8086 device=0x1c26 subvendor=0x1043 
 > subdevice=0x1427 class=0x0c0320 at slot=29 function=0 
 > handle=\_SB_.PCI0.EHC1
 >
 > ehci0@pci0:0:29:0:   class=0x0c0320 card=0x14271043 chip=0x1c268086 
 > rev=0x05 hdr=0x00
 > vendor = 'Intel Corporation'
 > device = '6 Series/C200 Series Chipset Family USB Enhanced Host 
 > Controller'
 > class  = serial bus
 > subclass   = USB
 > cap 01[50] = powerspec 2  supports D0 D3  current D0
 > cap 0a[58] = EHCI Debug Port at offset 0xa0 in map 0x14
 > cap 13[98] = PCI Advanced Features: FLR TP
 >
 > .. we shouldn't be putting it into D2, because the device doesn't 
 > support it.

Right.  Or at least, so we detect ..

 > However, we are actually transitioning it into D3. I don't have a 
 > bootverbose output here, but just assume we are.
[..]
 > The full files can be found at 
 > http://people.freebsd.org/~adrian/asus_zenbook/

Actually a verbose boot - without the extra debugging - or with, if it's 
properly interleaved with ordinary verbose stuff - might be handy, even 
if it won't survive a suspend/resume, when it could be _really_ handy.

 > If I leave the driver loaded but I disable the suspend-to-d3 option, 
 > things suspend/resume fine.
 >
 > If I set the unconfigured-devices-get-d3 option and unload the usb 
 > modules, then the ehci controller ends up at d3 when I unload it. 
 > Then if I suspend, the laptop hangs.

Sorry, where are those options set?  Is that what they're called?

Probably not helpful, but have you considered changing the ASL?

The only reason I can think of for leaving anything in D2 state is if 
that provides external power for phone charging and the like?  My X200 
has a BIOS option for that; pretty sure I turned it off.  Does yours?

cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: ACPI debug messages

[Ian Smith]

On Sat, 11 Oct 2014 14:10:07 -0400, Eric McCorkle wrote:
 > Hello,
 > 
 > I decided to try tracing through the evaluation of the DSM method in order to
 > track down where the graphics driver failure I mentioned earlier is coming
 > from.
 > 
 > However, it looks like there's already an extensive debug logging system in
 > place in the acpica system.
 > 
 > Can this be controlled from user space (presumably through sysctls), or does
 > it need to be compiled in?

It's all in acpi(4), and in the Handbook in the nowadays rather 
poorly-named "Power and Resource Management" at section 12.13.4: 
http://www.freebsd.org/doc/handbook/acpi-overview.html

You can add it to your kernel, but I think acpi is now always loaded as 
a module, therefore you just need to rebuild the module, as described.

cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: ThinkPad X61s suspend/resume status

[Ian Smith]

On Sun, 5 Oct 2014 15:24:26 +0100, Sevan / Venture37 wrote:
 > On 5 October 2014 08:43, Ian Smith  wrote:
 > > "Current configuration does not allow embedding of the file devinfo.out
 > > because of its mimetype application/octet-stream.: devinfo.out"
 > >
 > > You may like to ask allanj...@freebsd.org what MIME type should be used
 > > on wiki attachments (eg https://wiki.freebsd.org/Laptops/Thinkpad_T530)
 > > as it's very handy being able to view them directly without downloading,
 > > apart from acpidumps anyway.
 > 
 > That should be fixed now.

Yes, thanks.

 > >  > Still need to get xorg installed to test the suspend/resume, but the 
 > > initial
 > >  > details are up on https://wiki.freebsd.org/SuspendResume
 > >
 > > As an aside, authors of T400s and X200 there should find the reported
 > > problem with losing USB ports on resume was fixed some months ago - on
 > > stable/9 on my X200 at least - thanks again John!
 > 
 > Worth testing with a 10 release or 11 current live env or was the fix MFC?

Always worth testing, 'my X200' is a relatively small sample :)

http://svnweb.freebsd.org/base?view=revision&revision=267983

MFC'd to 10 and 9 stable on Jun 27, just 2 days after the diff applied 
cleanly from head and worked on 9.3-PRE through many joyous! S/R cycles. 
Sorry to get carried away, but that made the X200 'fit for purpose'.

cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: ThinkPad X61s suspend/resume status

[Ian Smith]

On Sat, 4 Oct 2014 18:19:10 +0100, Sevan / Venture37 wrote:
 > On 22/09/2014 15:06, John Baldwin wrote:
 > > If you have a wiki account, can you create a page for your laptops at
 > > https://wiki.freebsd.org/Laptops
 > 
 > Created https://wiki.freebsd.org/Laptops/Thinkpad_X61s & started filling the
 > specs & output from the various commands.

Great, except:

"Current configuration does not allow embedding of the file devinfo.out 
because of its mimetype application/octet-stream.: devinfo.out"

You may like to ask allanj...@freebsd.org what MIME type should be used 
on wiki attachments (eg https://wiki.freebsd.org/Laptops/Thinkpad_T530) 
as it's very handy being able to view them directly without downloading, 
apart from acpidumps anyway.

 > Still need to get xorg installed to test the suspend/resume, but the initial
 > details are up on https://wiki.freebsd.org/SuspendResume

As an aside, authors of T400s and X200 there should find the reported 
problem with losing USB ports on resume was fixed some months ago - on 
stable/9 on my X200 at least - thanks again John!

cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

RE: Problems with acpi (battery status not shown)

[Ian Smith]

On Wed, 10 Sep 2014 00:51:40 +, Moore, Robert wrote:

 > What was used to disassemble the file in the first place?

I gather Nick followed the standard instructions for ACPI debugging.

 > Please send the acpidump for the machine, thanks.
 > Bob

At 925KiB it's a tad big to attach.  From Nick's OP (with verbose dmesg 
and sysctl hw.acpi attached):

 > here is ASL file link:
 > https://www.sendspace.com/file/do5xn7

Horrid site, careful where you click ..

>From these acpiconf readings, the problem with getting battery status is 
certainly real, despite battery init looking good and EC looking ok too.

cheers, Ian

 > > -Original Message-
 > > From: owner-freebsd-a...@freebsd.org [mailto:owner-freebsd-
 > > a...@freebsd.org] On Behalf Of nick gigashvili
 > > Sent: Tuesday, September 09, 2014 12:45 PM
 > > To: Ian Smith
 > > Cc: freebsd-acpi@freebsd.org
 > > Subject: Re: Problems with acpi (battery status not shown)
 > > 
 > > Hi again
 > > 
 > > I did as you suggested I tested with acpiconf with different times and
 > > different states here are the results. first two files are when laptop was
 > > charging only difference in these two files was in Present voltage last
 > > two files are when laptop was discharging there is no difference in these
 > > two. After couple hours it ran out of battery and l aptop was powered off
 > > then I put it on AC power and turned it on battery was at 0% and charging
 > > and after some time it is still at 0% and charging
 > > 
 > > Now regarding to ASL file I ran iasl my-asl.asl and on line 27104 there
 > > was syntax error with "Package  (0x06)" unfortunately I don'tunderstand a
 > > damn thing with ASL syntax ...
 > > maybe this will make no difference but still I tried
 > > 
 > > Thanks
 > > 
 > > On Mon, Sep 8, 2014 at 5:00 PM, Ian Smith  wrote:
 > > 
 > > > On Mon, 8 Sep 2014 14:41:46 +0400, nick gigashvili wrote:
 > > >
 > > >  > > When replying, please edit your Subject line so it is more
 > > > specific  > > than "Re: Contents of freebsd-acpi digest..."
 > > >
 > > > One has to be really careful replying to digests; not only to restore
 > > > the Subject but also to quote no more than necessary to follow the one
 > > > message or topic.  We already had your verbose dmesg etc ..
 > > >
 > > >  > Thanks Ian for response Ill do as you suggested...
 > > >
 > > > Let us know.  My X200 dropped back to 94% today but remains relaxed.
 > > >
 > > >  > what about ASL syntax error shouldn't I pay attantion to it ?
 > > >
 > > > I wouldn't know, only a little bit about batteries.  You need to show
 > > > exact error message/s to interest someone who knows what those mean.
 > > >
 > > > I had a brief dive into a few sections of your 925KiB hp-8570w.asl and
 > > > managed to surface before drowning .. little the wiser.
 > > >
 > > > Your original message below for context, without attachments.
 > > >
 > > > cheers, Ian
 > > >
 > > >  > > Message: 1
 > > >  > > Date: Fri, 5 Sep 2014 18:43:23 +0400  > > From: nick gigashvili
 > > >   > > To: freebsd-acpi@freebsd.org  > >
 > > > Subject: Problems with acpi (battery status not shown)  > >
 > > > Message-ID:
 > > >  > >  > >  > > w...@mail.gmail.com>
 > > >  > > Content-Type: text/plain; charset="utf-8"
 > > >  > >
 > > >  > > Hi
 > > >  > >
 > > >  > > I'm having problem with acpi battery status is not updated it is
 > > > freezed on  > > 96% when on AC power, I'm running FreeBSD 10-RELEASE
 > > > on HP Workstation  > > 8570w.
 > > >  > > I tested ASL with iasl and it has syntax error. I coultn't boot
 > > > with acpi  > > turned off so Im sending you dmesg output only with
 > > > acpi enabled.
 > > >  > >
 > > >  > > here is ASL file link:
 > > >  > > https://www.sendspace.com/file/do5xn7
 > > >  > >
 > > >  > > Thank you
 > > >  > > -- next part --  > > Table 'FACP' at
 > > > 0xbeffc000  > > Table 'HPET' at 0xbeffb000  > > Table 'APIC' at
 > > > 0xbeffa000
 > > >
 > > > [..]
 > > >
 > 
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: Problems with acpi (battery status not shown)

[Ian Smith]

On Mon, 8 Sep 2014 14:41:46 +0400, nick gigashvili wrote:

 > > When replying, please edit your Subject line so it is more specific
 > > than "Re: Contents of freebsd-acpi digest..."

One has to be really careful replying to digests; not only to restore 
the Subject but also to quote no more than necessary to follow the one
message or topic.  We already had your verbose dmesg etc ..

 > Thanks Ian for response Ill do as you suggested...

Let us know.  My X200 dropped back to 94% today but remains relaxed.

 > what about ASL syntax error shouldn't I pay attantion to it ?

I wouldn't know, only a little bit about batteries.  You need to show 
exact error message/s to interest someone who knows what those mean.

I had a brief dive into a few sections of your 925KiB hp-8570w.asl and 
managed to surface before drowning .. little the wiser.

Your original message below for context, without attachments.

cheers, Ian

 > > Message: 1
 > > Date: Fri, 5 Sep 2014 18:43:23 +0400
 > > From: nick gigashvili 
 > > To: freebsd-acpi@freebsd.org
 > > Subject: Problems with acpi (battery status not shown)
 > > Message-ID:
 > >  > w...@mail.gmail.com>
 > > Content-Type: text/plain; charset="utf-8"
 > >
 > > Hi
 > >
 > > I'm having problem with acpi battery status is not updated it is freezed on
 > > 96% when on AC power, I'm running FreeBSD 10-RELEASE on HP Workstation
 > > 8570w.
 > > I tested ASL with iasl and it has syntax error. I coultn't boot with acpi
 > > turned off so Im sending you dmesg output only with acpi enabled.
 > >
 > > here is ASL file link:
 > > https://www.sendspace.com/file/do5xn7
 > >
 > > Thank you
 > > -- next part --
 > > Table 'FACP' at 0xbeffc000
 > > Table 'HPET' at 0xbeffb000
 > > Table 'APIC' at 0xbeffa000

[..]
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: Problems with acpi (battery status not shown)

[Ian Smith]

On Fri, 5 Sep 2014 18:43:23 +0400, nick gigashvili wrote:
 > Hi
 > 
 > I'm having problem with acpi battery status is not updated it is freezed on
 > 96% when on AC power, I'm running FreeBSD 10-RELEASE on HP Workstation
 > 8570w.
 > I tested ASL with iasl and it has syntax error. I coultn't boot with acpi
 > turned off so Im sending you dmesg output only with acpi enabled.
 > 
 > here is ASL file link:
 > https://www.sendspace.com/file/do5xn7
 > 
 > Thank you

Your hw.acpi tree and verbose dmesg look alright on a very quick browse.  
No AE_* ACPI errors and battery initialisation looks good, assuming you 
have just one battery fitted of the two supported.

It's quite possible that there's no problem.  Li-Ion batteries are not 
trickle-charged like older technology batteries (NiCd or NiMH) but after 
a full charge gradually self-discharge over days, perhaps weeks while 
the laptop is powered, until the battery gets down to below around 95% 
(on my Thinkpads anyway), when it will get boosted back to 100% again.

My X200 is down to 95%; I'm expecting a charge cycle any day now :)

State:  high
Remaining capacity: 95%
Remaining time: unknown
Present rate:   0 mW
Present voltage:12418 mV

Try unplugging power and watching with acpiconf -i0 until down to say 
90% or lower, then reconnect power; it should charge up to 100% again, 
and stay up around 98-99% for a while before gradually dropping.

If it doesn't, try reporting the result of acpiconf -i0 at different 
states and times; just the lines above will do, except for the first.

And don't forget to let it run on battery sometimes, it's good for it; 
occasional deep (or even complete) discharges help keep the battery's 
internal 'coulomb counter' in good shape, and don't hurt battery life.

cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: [PATCH] ACPI CMOS region support rev. 3

[Ian Smith]

On Fri, 29 Aug 2014 11:30:49 -0400, Anthony Jenkins wrote:

 > Okay here's another revision of the patch, hopefully I made good 
 > progress in cleaning up the style and addressing everyone's 
 > concerns.  Comments/criticisms welcome as always!
 > 
 > Patches:
 >  *  Current: http://www.qtchat.org/docs/atrtc.c-20140829.patch
 >  *  Previous: http://www.qtchat.org/docs/atrtc.c.patch
 > Changes:
 >  *  Removed 'U' suffix from integer literals.
 >  *  Ensured all (my) lines were <= 40 columns
 >  *  Changed continuation indent to 4 columns.
 >  *  Replaced is_datetime_reg() with more generic acpi_check_rtc_byteaccess() 
 > to encapsulate (deeper) validation
 > of ACPI CMOS accesses.
 >  *  Replaced some ACPI Windows-like typenames with FreeBSD typenames where 
 > possible.
 > Booting my HP Envy 14 laptop and suspend/resuming shows the only ACPI CMOS 
 > accesses are byte reads of registers
 > 0x06, 0x04 and 0x02:
 > 
 >   uhub4: at usbus0, port 1, addr 1 (disconnected)
 >   ugen0.2:  at usbus0 (disconnected)
 >   ums0: at uhub4, port 3, addr 1 (disconnected)
 >   uhid0: at uhub4, port 3, addr 1 (disconnected)
 >   uhub3: at usbus1, port 1, addr 1 (disconnected)
 >   uhub2: at usbus2, port 1, addr 1 (disconnected)
 >   ugen2.2:  at usbus2 (disconnected)
 >   urtwn0: at uhub2, port 1, addr 2 (disconnected)
 >   uhub1: at usbus3, port 1, addr 1 (disconnected)
 >   ugen3.2:  at usbus3 (disconnected)
 >   ubt0: at uhub1, port 4, addr 2 (disconnected)
 >   uhub0: at usbus4, port 1, addr 1 (disconnected)
 >   ugen4.2:  at usbus4 (disconnected)
 >   acpi_rtc_cmos_handler: READ 01 address=0006 value=0006
 >   acpi_rtc_cmos_handler: READ 01 address=0004 value=0015
 >   acpi_rtc_cmos_handler: READ 01 address=0002 value=0006
 >   vgapci0: child drmn0 requested pci_set_powerstate
 >   info: [drm] PCIE GART of 512M enabled (table at 0x0004).
 >   drmn0: info: WB enabled
 >   drmn0: info: fence driver on ring 0 use gpu addr 0x2c00 
 > and cpu addr 0x0xf800b686cc00
 >   drmn0: info: fence driver on ring 1 use gpu addr 0x2c04 
 > and cpu addr 0x0xf800b686cc04
 >   drmn0: info: fence driver on ring 2 use gpu addr 0x2c08 
 > and cpu addr 0x0xf800b686cc08
 >   drmn0: info: fence driver on ring 3 use gpu addr 0x2c0c 
 > and cpu addr 0x0xf800b686cc0c
 >   drmn0: info: fence driver on ring 4 use gpu addr 0x2c10 
 > and cpu addr 0x0xf800b686cc10
 >   info: [drm] ring test on 0 succeeded in 3 usecs
 >   info: [drm] ring test on 3 succeeded in 2 usecs
 >   info: [drm] ring test on 4 succeeded in 2 usecs
 >   info: [drm] ib test on ring 0 succeeded in 0 usecs
 >   info: [drm] ib test on ring 3 succeeded in 0 usecs
 >   info: [drm] ib test on ring 4 succeeded in 0 usecs
 >   re0: link state changed to DOWN
 >   psm0: system resume hook called.
 >   psm0: current command byte: 0065 (reinitialize).

Ok, good knowing what your HP Envy 14 wants to know; minute, hour and 
day of week.  You'd said that without this it immediately resumed from 
suspend; I suppose that it might want to calculate (within a week) how 
long it had been suspended or when when it should awaken - perhaps to do 
with the wake on alarm settings in BIOS setup (?) - and that failing to 
retrieve those made it decide it was best (or due) to resume.  Rather 
odd, when it would also need to read day, hour and minute on resuming to 
compare, but apparently doesn't do so - or at least, not via ACPI ..

 > Backlight still doesn't resume, but can still ssh(1) into laptop.

I'd tend to treat and pursue this as a separate problem; it's been a 
common issue on a number of laptops.  Maybe try freebsd-mobile@ too?

 > Thanks,
 > Anthony Jenkins

Before quoting some issues with your patch, I'll say what I think:

 0) It would be better to leave the system rtcin() and writertc() more 
or less as is, including its present I/O timing and the optimisation for 
repetitive access, allowing (eg) use of RTC periodic interrupts at high 
rates, as Bruce discussed (albeit dismissively :) WRT profiling.  Your
IODELAY() macro is useful documentation, I had to hunt that up myself.

I'm wondering if mav@ (cc'd) has anything to say about all this?

There are 18 calls to each of rtcin() and writertc() just within 
atrtc.c itself, and other callers (in 9.3 sources) in:

smithi@x200:/sys % find . -type f -exec egrep -l 'rtcin\(|writertc\(' {} \; | 
uniq
/sys/isa/rtc.h
/sys/mips/malta/malta_machdep.c
/sys/i386/xen/clock.c
/sys/i386/i386/machdep.c
/sys/dev/fb/vga.c
/sys/dev/acpi_support/acpi_ibm.c
/sys/dev/nvram/nvram.c
/sys/dev/fdc/fdc.c
/sys/x86/isa/atrtc.c
/sys/pc98/cbus/fdc.c

/sys/dev/fb/vga.c depends on 2 bits in RTC_EQUIPMENT which is defined in 
that file - albeit for older VGA/EGA/CGA systems - as:
/* this should really be in `rtc.h' */
#define RTC_EQUIPMENT 

Re: [PATCH] ACPI CMOS region support - submission?

[Ian Smith]

On Wed, 6 Aug 2014 06:49:12 +1000, Bruce Evans wrote:
 > On Tue, 5 Aug 2014, Ian Smith wrote:
 > 
 > > On Sat, 2 Aug 2014 18:10:05 -0400, Anthony Jenkins wrote:
 > > 
 > > > I made a few minor changes since the last incarnation:
 > > >
 > > >  - Defined the CMOS address/data register addresses as macros
 > > >  - Defined the (apparent) I/O delay as a macro
 > > 
 > > Looks good, Anthony.
 > > 
 > > > I also verified the ACPI CMOS region code only accesses up to
 > > > register 63 (0x3F - in previous emails I mistakenly said 0x7F).
 > > 
 > > Is 0x3f what the ACPI spec limits ACPI access to?
 > > 
 > > This is mildly surprising, as all modern RTC chips are at least 128
 > > bytes; noone's actually used a MC146818 in over ten years, I gather.
 > 
 > BIOSes at least used to use much more.  It is good for ACPI to not allow
 > clobbering the BIOS state.
 > 
 > > > If/when this gets in, I'd like to add sysctl controls to e.g. allow
 > > > ACPI access to the date/time registers (I currently return failure
 > > > when attempting to write them via ACPI).  I don't see anything in the
 > > > spec (after re-reading it) that disallows ACPI from touching those.
 > > 
 > > I don't know about the spec, but I can't see allowing ACPI write access
 > > to time/alarm/date registers as being a sensible idea; this could allow
 > > completely out-of-band modification of time/alarm/date regs without the
 > > necessary precautions needed for setting these, namely use of the SET
 > > bit in status reg B (0x0b) to disable updates while setting time & date,
 > > and anyway why allow changing time/date without the OS knowing about it?
 > > Reading should be no problem, though without proper observance of UIP
 > > bit timing, data may not be consistent.
 > 
 > They might need to be read on resume.  I can't see how resume can possibly
 > work without reading them or some clock to reset the time.  But this should
 > be done by calling the standard time reading functions, not at a low level.

Well, we've long - not sure about 'always' - saved current timestamp to 
RTC clocktime (ts_to_ct) on suspend and recalled on resume (ct_to_ts), 
shown when bootverbose is enabled, x86 anyway; this has nothing to do 
with ACPI.

Actually, 9.x and presumably 10.x needs debug.clocktime=1 to see the 
messages re these, previously (eg below from 8.2-R) you see these by 
default every 30 minutes, having booted verbose, which was annoying:

Aug  8 00:41:32 t23 kernel: ts_to_ct(1407458492.000380514) = [2014-08-08 
00:41:32]
Aug  8 01:11:31 t23 kernel: ts_to_ct(1407460291.799401540) = [2014-08-08 
01:11:31]
Aug  8 01:41:31 t23 kernel: ts_to_ct(1407462091.598502848) = [2014-08-08 
01:41:31]
Aug  8 02:11:31 t23 kernel: ts_to_ct(1407463891.397341911) = [2014-08-08 
02:11:31]
Aug  8 02:41:31 t23 kernel: ts_to_ct(1407465691.196399111) = [2014-08-08 
02:41:31]
Aug  8 03:11:31 t23 kernel: ts_to_ct(1407467490.995395001) = [2014-08-08 
03:11:30]
Aug  8 03:41:30 t23 kernel: ts_to_ct(1407469290.794307971) = [2014-08-08 
03:41:30]

This reveals some warts; seconds are always rounded down, so that on 
resume you can expect, on average, to lose half a second; worst case 
almost a second.  Thus the first ntpd correction after (even immediate) 
resume is often positive, maybe more than a second, sometimes two or so.

Similarly when restoring time from RTC on resume, there's no synching 
with UIP so, on average, another half second will be dropped before ntpd 
picks up the pieces.  Whether sync is worth the bother or time is moot.

 > > I guess there may be a case for messing with the alarm bytes, though we
 > > don't currently allow use of the alarm for wake from poweroff (S5) or
 > > STR (S3) states, as doth Linux.  I looked into this some years ago when
 > > there were a few requests for the feature, however it would involve some
 > > major reworking to always preserve the alarm interrupt bit through init
 > > and suspend/resume, and appropriate clearing of same after use, along
 > > with a utility to setup the alarm .. a potential to leave open, perhaps?
 > 
 > I use the seconds alarm for pps, but don't use suspend.

Is it accurate enough for pps?  Are you using ntpd to update your RTC?

Ok, and others may want to use alarm or periodic interrupts for whatever 
purpose, possibly at much higher rates than once per second, so there's 
still a case for maintaining the reg select optimisation noted below ..

 > > Which leads to my other concern here: that you are allowing out-of-band
 > > access to especially status reg C (0x0c), which when read clears all
 > > enabled interrupts, and the other status regs whose s

Re: [PATCH] ACPI CMOS region support - submission?

[Ian Smith]

On Sat, 2 Aug 2014 18:10:05 -0400, Anthony Jenkins wrote:

 > I made a few minor changes since the last incarnation:
 > 
 >  - Defined the CMOS address/data register addresses as macros
 >  - Defined the (apparent) I/O delay as a macro

Looks good, Anthony.

 > I also verified the ACPI CMOS region code only accesses up to 
 > register 63 (0x3F - in previous emails I mistakenly said 0x7F).

Is 0x3f what the ACPI spec limits ACPI access to?

This is mildly surprising, as all modern RTC chips are at least 128 
bytes; noone's actually used a MC146818 in over ten years, I gather.

 > If/when this gets in, I'd like to add sysctl controls to e.g. allow 
 > ACPI access to the date/time registers (I currently return failure 
 > when attempting to write them via ACPI).  I don't see anything in the 
 > spec (after re-reading it) that disallows ACPI from touching those.

I don't know about the spec, but I can't see allowing ACPI write access 
to time/alarm/date registers as being a sensible idea; this could allow 
completely out-of-band modification of time/alarm/date regs without the 
necessary precautions needed for setting these, namely use of the SET 
bit in status reg B (0x0b) to disable updates while setting time & date, 
and anyway why allow changing time/date without the OS knowing about it? 
Reading should be no problem, though without proper observance of UIP 
bit timing, data may not be consistent.

I guess there may be a case for messing with the alarm bytes, though we 
don't currently allow use of the alarm for wake from poweroff (S5) or 
STR (S3) states, as doth Linux.  I looked into this some years ago when 
there were a few requests for the feature, however it would involve some 
major reworking to always preserve the alarm interrupt bit through init 
and suspend/resume, and appropriate clearing of same after use, along 
with a utility to setup the alarm .. a potential to leave open, perhaps?

Which leads to my other concern here: that you are allowing out-of-band 
access to especially status reg C (0x0c), which when read clears all 
enabled interrupts, and the other status regs whose settings are also 
too important to allow screwing with.

We used to use the RTC periodic interrupt as a clock source for a 128Hz 
interrupt (1024Hz while profiling) but since mav@'s reworking of all the 
clocks and timers sometime prior to 9.0-REL (IIRC), that's now rarely if 
ever used as such, but remains an available clock or timer source.

Reg A (0x0a) is r/w and sets clock divider and rate selection bits.  Do 
we want ACPI to be able to mess with these?  I think not.  Readonly, ok.

Reg B (0x0b) is r/w and contains the aforementioned SET bit, the three 
interrupt enable bits (PIE, AIE, UIE), the SQWE, DM, 24/12 and DSE bits, 
again none of which should be allowed to be written to out-of-band.

And reg C (0x0c) is read-only, and as mentioned clears interrupts; again 
not something that should be permitted without the OS knowing about it.

I suppose you have the MC146818 spec to hand?

Couple of things from your patch:

-static int rtc_reg = -1;

Indeed; I never could figure out the advantage in this, as how rarely 
would you want to read or write the same reg twice in a row anyway?

 static u_char  rtc_statusa = RTCSA_DIVIDER | RTCSA_NOPROF;
 static u_char  rtc_statusb = RTCSB_24HR;
 
+static void acpi_cmos_read(ACPI_PHYSICAL_ADDRESS address, UINT8 *buf, UINT32 
buflen)
 {
+   UINT32 offset;
 
RTC_LOCK;

+   for (offset = 0U; offset < buflen; ++offset) {
+   IO_DELAY();
+   outb(IO_RTC_ADDR, ((address + offset) | 0x80) & 0xFF);
+   IO_DELAY();
+   buf[offset] = inb(IO_RTC_DATA);

Sorry, but I don't get '| 0x80' there, and below in acpi_cmos_write ?  

+int
+rtcin(int reg)
+{
+   u_char val;
+
+   acpi_cmos_read(reg & 0xFF, &val, 1);

+void
+writertc(int reg, u_char val)
+{
+   acpi_cmos_write(reg & 0xFF, &val, 1);
+}

Reg is already masked to 0xFF here anyway, and AFAICT every other access 
system-wide is via rtcin() and writertc().

 static int
+is_datetime_reg(ACPI_PHYSICAL_ADDRESS address)
+{
+   return address == 0x00 ||
+   address == 0x02 ||
+   address == 0x04 ||
+   address == 0x04 ||
+   (address >= 0x06 && address <= 0x09);
+}

I guess that second 0x04 should be 0x06?  But why are you limiting to 
even addresses, ie time regs but not the alarm regs?  If anything, the 
alarm regs seem more likely something BIOS/AML may? want to know about?

+static ACPI_STATUS
+acpi_rtc_cmos_handler(UINT32 function, ACPI_PHYSICAL_ADDRESS address, UINT32 
width,
+   UINT64 *value, void *context, void *region_context)
+{
+   struct atrtc_softc *sc;
+
+   sc = (struct atrtc_softc *)context;
+   if (!value || !sc)
+   return AE_BAD_PARAMETER;
+   if (width > 32 || (width & 0x07) || address >= 64U)
+   return AE_BAD_PARAMETER;

Ok, addre

Re: ACPI support - Freebsd 10 on Sony Vaio VPCCA3C5E

[Ian Smith]

On Mon, 21 Jul 2014 12:30:23 -0400, John Baldwin wrote:
 > On Thursday 17 July 2014 03:16:10 Ian Smith wrote:
 > > On Wed, 16 Jul 2014 09:26:08 -0400, Anthony Jenkins wrote:
 > >  > On 07/16/2014 01:32, Daniele Mazzotti wrote:
 > >  >> Hi guys, thanks again for the support, but I am leaving for a
 > >  >> businesses trip and I will be forced to put this debug thing on hold
 > >  >> for a while. I will be back on track next week.
 > >  > 
 > >  > Bah... really wanted to figure out the patch problem.  I suspect the
 > >  > file picked up some corruption somewhere between the email and your
 > >  > FreeBSD filesystem.  Your OS version has the same revision of that
 > >  > source file as mine, so it should apply cleanly.  If you feel like
 > >  > tinkering with it in your free time, I've posted the patch here:
 > >  > http://pastebin.com/P0B44u0c
 > >  > 
 > >  > Good luck,
 > >  > Anthony
 > > 
 > > Either by show raw and save, or by download, the patch has ^M lineends.
 > > 
 > > Interesting, but I can't see atrtc.c being the right sort of place for
 > > this, seems way out of scope.  Couldn't you include its headers and use
 > > functions rtcin() and writertc() from elsewhere in kernel, perhaps a
 > > module living in the same hierarchy as acpi_ibm, acpi_asus and such,
 > > that one could build and kldload if useful on a certain machine/s?
 > 
 > I disagree, I think this is exactly the right place to do it.  The CMOS 
 > access
 > on x86 boxes is going to be via the RTC, and the folks from Intel even 
 > indicated that the proper place to put the CMOS region handler is in the 
 > driver that claims the RTC PNP ID.  The only pending question I was aware of 
 > is that Anthony had asked the Intel guys a question about a return code, but 
 > that barring that the patch was ready to go into the tree (and should 
 > probably 
 > go in soon so it can make 10.1).

I agree :)  Yes, as noted I was well under-researched, was myself out of 
scope, and missed the basis of this entirely.  I'm glad it's going ahead 
despite my distractions ..

cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: atrtc.c patch for ACPI CMOS region (was Re: ACPI support - Freebsd 10 on Sony Vaio VPCCA3C5E)

[Ian Smith]

On Wed, 16 Jul 2014 17:08:03 -0400, Anthony Jenkins wrote:
 > On 07/16/2014 13:16, Ian Smith wrote:
[..]
 > >  > http://pastebin.com/P0B44u0c
 > >
 > > Either by show raw and save, or by download, the patch has ^M lineends.

 > Bah!  Well that'd explain it... I'm generating the file on a pure 
 > FreeBSD box, opened in gvim, select all, copy, paste to pastebin.com.

Must be pastebin .. a sh script I grabbed from there came like that too.

 > > Interesting, but I can't see atrtc.c being the right sort of place for 
 > > this, seems way out of scope.  Couldn't you include its headers and use 
 > > functions rtcin() and writertc() from elsewhere in kernel, perhaps a 
 > > module living in the same hierarchy as acpi_ibm, acpi_asus and such, 
 > > that one could build and kldload if useful on a certain machine/s?

 > This is in support of the PNP0800 device, for which atrtc.c is the 
 > driver.  The ACPI spec (5.0 is what I'm reading) says that device 
 > should implement a handler to read offset 0x00-0x7F.

Fair enough.  I've since explored PNP0800 a bit, had a look at what 
Linux does in (apparently recent) acpi_cmos_rtc.c, asm-generic/rtc.h etc 
from mit.edu - much more complex and quirk-handling than ours - and soon 
realised how out of date my knowledge of any of this is; ACPI was at 3.0 
last time I read much of the spec ..

 > > If so, you haven't to do battle with Time Lords :) with something people 
 > > could add and load at own risk without messing with core kernel stuff.
 > >
 > > acpi_ibm should be a useful template, as it includes code to read CMOS 
 > > bytes in the 0x60-0x6f range, presumably updated by the BIOS, whether 
 > > opaquely or somehow via AML code I don't know.  It uses rtcin() so has 
 > > that scope in place.
 > >
 > > I'd still like to see your patch reject attempts to read or write to at 
 > > least below 0x10.  Even reading status register/s resets interrupts, and 
 > > why would anyone need to mess with clock and/or timer regs via ACPI?

 > I assume it'd be the BIOS AML which would use my CMOS region handler; 
 > it'd be a BIOS bug that reads/writes the clock regs.

Fair enough again.  My earlier impression was of a fix for a specific 
quirk for your HP, not realising you were implementing what is for 
FreeBSD a new handler for a new(er) ACPI feature, so ignore my musings.

 > > Maybe you could add a sysctl to limit access to some specific range?
 > I dunno... I really think what I have is the Right Thing To Do... 
 > Someone else from freebsd-acpi@ suggested this approach.  Maybe 
 > someone versed in ACPI could clarify from the spec?

I'd be happy to see more on-list information, but everyone's busy .. 

cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: ACPI support - Freebsd 10 on Sony Vaio VPCCA3C5E

[Ian Smith]

On Wed, 16 Jul 2014 09:26:08 -0400, Anthony Jenkins wrote:
 > On 07/16/2014 01:32, Daniele Mazzotti wrote:
 >> Hi guys, thanks again for the support, but I am leaving for a 
 >> businesses trip and I will be forced to put this debug thing on hold 
 >> for a while. I will be back on track next week.
 >
 > Bah... really wanted to figure out the patch problem.  I suspect the 
 > file picked up some corruption somewhere between the email and your 
 > FreeBSD filesystem.  Your OS version has the same revision of that 
 > source file as mine, so it should apply cleanly.  If you feel like 
 > tinkering with it in your free time, I've posted the patch here: 
 > http://pastebin.com/P0B44u0c
 > 
 > Good luck,
 > Anthony

Either by show raw and save, or by download, the patch has ^M lineends.

Interesting, but I can't see atrtc.c being the right sort of place for 
this, seems way out of scope.  Couldn't you include its headers and use 
functions rtcin() and writertc() from elsewhere in kernel, perhaps a 
module living in the same hierarchy as acpi_ibm, acpi_asus and such, 
that one could build and kldload if useful on a certain machine/s?

If so, you haven't to do battle with Time Lords :) with something people 
could add and load at own risk without messing with core kernel stuff.

acpi_ibm should be a useful template, as it includes code to read CMOS 
bytes in the 0x60-0x6f range, presumably updated by the BIOS, whether 
opaquely or somehow via AML code I don't know.  It uses rtcin() so has 
that scope in place.

I'd still like to see your patch reject attempts to read or write to at 
least below 0x10.  Even reading status register/s resets interrupts, and 
why would anyone need to mess with clock and/or timer regs via ACPI?

Have you found exactly which CMOS bytes your box needs to meddle with?
Maybe you could add a sysctl to limit access to some specific range?

Don't mind me, just thinking aloud, and I've no idea how this might 
relate to Daniele's issue with stale battery data?

cheers, Ian

PS Daniele: no, never tempted by Sonys; rusted-on Thinkpad kinda guy :)
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: ACPI support - Freebsd 10 on Sony Vaio VPCCA3C5E

[Ian Smith]

On Tue, 15 Jul 2014 20:47:44 +0200, Daniele Mazzotti wrote:
 > Hi Ian,
 > 
 > I have just rebooted the PC after turning the deep debug on. Here is the
 > output: http://pastebin.com/H61zJhqc. It is very likely that the dmesg has
 > been cut due to the large amount of output. Is there any way to have it all?
 > 
 > Cheers,
 > Daniele.

>From the boot menu you can drop to the loader, and enter something like:
  set kern.msgbufsize=12
  boot
where the default is about 64K these days, I think.

However I couldn't spot anything further regarding 'battery|BAT0', and 
you did catch the start of initialisation.  I'm out of my depth, but you 
might also try layer 'ACPI_EC' with high verbosity?

You shoudn't need to reboot to try things now that ACPI_DEBUG is enabled 
in your kernel; you can adjust them on the fly.  From section 11.16.6 on 
the acpi-debug page:

"If the information you want is triggered by a specific event (say, a 
suspend and then resume), you can leave out changes to loader.conf and 
instead use sysctl to specify the layer and level after booting and 
preparing your system for the specific event. The sysctls are named the 
same as the tunables in loader.conf."

So you could avoid all the boot messages, if they're not helpful, and 
log events like switching from AC to battery and vice versa, which might 
trigger interrogating the battery (via the EC, probably), by adjusting 
those sysctls, just for an example:

root# sysctl debug.acpi.layer="ACPI_EC ACPI_BATTERY ACPI_AC_ADAPTER"
root# sysctl debug.acpi.level="ACPI_LV_VERBOSITY3"

But I'm just stabbing in the dark, really .. good luck.

cheers, Ian

 > 2014-07-15 20:22 GMT+02:00 Ian Smith :
 > 
 > > On Tue, 15 Jul 2014 19:49:46 +0200, Daniele Mazzotti wrote:
 > >
 > >  > I made a few step ahead (at least on my side) and tried to follow the
 > >  > recommendation from the handbook (
 > >  > http://www.pl.freebsd.org/doc/handbook/acpi-debug.html).
 > >  >
 > >  > I was able to turn on the verbose boot and here you can find the output:
 > >  > http://pastebin.com/kkDAZEVb. At boot time I can see an error stating
 > >  > "battery0: battery initialization failed, giving up" which is thrown by
 > > the
 > >  > acpi_cmbat_init_battery within acpi_cmbat.c module. After six retries
 > > the
 > >  > error is printed out. Actually I am not able to figure out who is
 > > calling
 > >  > the method, but that is another story.
 > >
 > > Actually you'll see those messages on a 'normal' verbose boot, ie
 > > there's nothing extra logged of note regarding battery issues.  If you
 > > are up for lots more output on one boot at least, perhaps try what
 > > acpi(4) suggests:
 > >
 > >debug.acpi.layer="ACPI_ALL_COMPONENTS ACPI_ALL_DRIVERS"
 > >debug.acpi.level="ACPI_LV_ALL_EXCEPTIONS"
 > >
 > > which is less deep, but wider :)  Communications with batteries often,
 > > likely usually, is moderated by the embedded controler (ACPI_EC) and it
 > > wouldn't hurt to report any exceptions from other subsystems also. If
 > > that yields nothing useful you could increase the level ..
 > >
 > > Sorry, I can't read messages backwards very well, so I'll drop the tail.
 > >
 > > cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: ACPI support - Freebsd 10 on Sony Vaio VPCCA3C5E

[Ian Smith]

On Tue, 15 Jul 2014 19:49:46 +0200, Daniele Mazzotti wrote:

 > I made a few step ahead (at least on my side) and tried to follow the
 > recommendation from the handbook (
 > http://www.pl.freebsd.org/doc/handbook/acpi-debug.html).
 > 
 > I was able to turn on the verbose boot and here you can find the output:
 > http://pastebin.com/kkDAZEVb. At boot time I can see an error stating
 > "battery0: battery initialization failed, giving up" which is thrown by the
 > acpi_cmbat_init_battery within acpi_cmbat.c module. After six retries the
 > error is printed out. Actually I am not able to figure out who is calling
 > the method, but that is another story.

Actually you'll see those messages on a 'normal' verbose boot, ie 
there's nothing extra logged of note regarding battery issues.  If you 
are up for lots more output on one boot at least, perhaps try what 
acpi(4) suggests:

   debug.acpi.layer="ACPI_ALL_COMPONENTS ACPI_ALL_DRIVERS"
   debug.acpi.level="ACPI_LV_ALL_EXCEPTIONS"

which is less deep, but wider :)  Communications with batteries often, 
likely usually, is moderated by the embedded controler (ACPI_EC) and it 
wouldn't hurt to report any exceptions from other subsystems also. If 
that yields nothing useful you could increase the level ..

Sorry, I can't read messages backwards very well, so I'll drop the tail.

cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: HP Compaq 8710W Battery status problems

[Ian Smith]

On Sat, 12 Jul 2014 01:53:22 +0200, Old Fart wrote:
 >Sent: Friday, July 11, 2014 at 4:30 PM
 >From: "Old Fart" 
 >To: freebsd-acpi@freebsd.org
 >Subject: Re: HP Compaq 8710W Battery status problems
 >Sent: Thursday, July 10, 2014 at 2:31 PM
 >From: "Anthony Jenkins" 
 >To: "Ron Freidel" , freebsd-acpi@freebsd.org
 >Subject: Re: HP Compaq 8710W Battery status problems
 >
 >> Plugged in and fully charged
 >> acpiconf -i batt
 >Isn't this supposed to be 'acpiconf -i 0' and 'acpiconf -i 1'?
 >On my machine the two commands (-i 0 & -i batt) deliver identical
 >information, when I posted originally I was tired and bleary
 >eyed/headed...

Yes, '-i anyword' gets you battery 0.  Consider it a feature :)

 >
 >[ajenkins@ajenkins-hplaptop /usr/src/sys]$ acpiconf -i 1
 >acpiconf: get battery info (1) failed: Device not configured
 >Here's the output of acpiconf-i 1
 >[ronf@mobile] ~% acpiconf -i 1
 >Design capacity: 0 mWh
 >Last full capacity: 0 mWh
 >Technology: primary (non-rechargeable)
 >Design voltage: 0 mV
 >Capacity (warn): 0 mWh
 >Capacity (low): 0 mWh
 >Low/warn granularity: 0 mWh
 >Warn/full granularity: 0 mWh
 >Model number:
 >Serial number:
 >Type:
 >OEM info:
 >State: not present
 >Present voltage: unknown

 >Just for giggles I did run acpiconf -i 0 & -i 1 without the battery
 >installed, saw this...
 >[ronf@mobile] ~% acpiconf -i 0
 >Design capacity: unknown
 >Last full capacity: unknown
 >Technology: secondary (rechargeable)
 >Design voltage: unknown
 >Capacity (warn): 0 mWh
 >Capacity (low): 0 mWh
 >Low/warn granularity: 0 mWh
 >Warn/full granularity: 0 mWh
 >Model number:
 >Serial number:
 >Type:
 >OEM info:
 >State: not present
 >Present voltage: unknown

That looks completely normal for a removed battery.

 >[ronf@mobile] ~% acpiconf -i 1
 >Design capacity: 0 mWh
 >Last full capacity: 0 mWh
 >Technology: primary (non-rechargeable)
 >Design voltage: 0 mV
 >Capacity (warn): 0 mWh
 >Capacity (low): 0 mWh
 >Low/warn granularity: 0 mWh
 >Warn/full granularity: 0 mWh
 >Model number:
 >Serial number:
 >Type:
 >OEM info:
 >State: not present
 >Present voltage: unknown
 >Apparently if my sysapses are firing correctly, the os is seeing the
 >laptops main battery as secondary and a non existant battery as
 >primary.

I believe 'primary' and 'secondary' here are referring to power-source 
technology under ACPI, not their relative positions.  Why it should 
consider battery1 to be 'primary (non-rechargeable)' I don't know, 
unless it has provision for using a pack of non-rechargeable batteries?  
Or at least, some battery source that the machine won't try to charge?

 >A little more info..
 > 
 >Looking at dmesg I see
 > 
 >battery0:  on acpi0
 >battery1:  on acpi0
 > 
 >Battery1 does not exist.

No, your battery1 is not installed, but ACPI claims to be ready when you 
do install one in the other slot.  What does its manual say about this?

My old '98 Compaq 1500c - still running, but under APM rather than ACPI, 
only because its ACPI failed to switch to battery when AC was removed - 
worked with a second battery also installed, when it replaced the floppy 
disk drive.  It also showed both battery slots in dmesg just like that.

However, acpiconf showed both as 'secondary (rechargeable)', and did 
work properly to work out remaining capacity and time with both fitted, 
even properly discharging one until near empty before switching to the 
other, and charging them up in turn when AC was reconnected.

Not that this helps your issue of it discharging without updating the 
capacity %, time remaining etc.  This could be a fault in the embedded 
controller (if the Sony uses one of those?) but perhaps more likely a 
fault in the coulomb-counter chip in the battery itself.  Have you tried 
another battery?  It's not so uncommon for these chips to fail, or at 
least lose any sensible idea of what's going on with the battery, which 
sometimes a complete discharge/recharge cycle, or several, _might_ fix.

If it fails similarly with another battery, then it may be an issue with 
the ACPI implementation itself on that machine, in which case other 
instances of the problem occurring should show up on a search.  Are you 
running the latest BIOS upgrade for your laptop?

cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: Impossible shutdown

[Ian Smith]

On Thu, 26 Jun 2014 07:44:35 -0400, Anthony Jenkins wrote:
 > On 06/25/2014 18:29, Bykov Vladislav wrote:
 > > Hello.
 > >
 > > I have a problem with ACPI on HP Envy 4 that causes in impossible 
 > > shutdown. It
 > > reaches an error while prepairing to shutdown, and reboots the machine.
 > >
 > > I already did sent a bug report about 2-3 months ago, but things doesn't 
 > > seems
 > > to move on.
 > >
 > > Here's an error when booting the machine:
 > >
 > >ACPI Error: No handler for Region [RCM0] (0xfe0002b0f800) 
 > > [SystemCMOS] (20110527/evregion-421)
 > >ACPI Error: Region SystemCMOS (ID=5) has no handler 
 > > (20110527/exfldio-310)
 > >ACPI Error: Method parse/execution failed [\134_SB_.WMID.ESDT] (Node 
 > > 0xfe0002aee440), AE_NOT_EXIST (20110527/psparse-560)
 > >ACPI Error: Method parse/execution failed 
 > > [\134_SB_.PCI0.LPCB.EC0_._Q42] (Node 0xfe0002b16d40), AE_NOT_EXIST 
 > > (20110527/psparse-560)
 > >acpi_ec0: evaluation of query method _Q42 failed: AE_NOT_EXIST
 > >
 > > And here's the one when I'm trying to shut it down:
 > >
 > >usbus2: Controller shutdown complete
 > >ACPI Error: No handler for Region [RCM0] (0xfe0002b15900) 
 > > [SystemCMOS] (20110527/evregion-421)
 > >ACPI Error: Region SystemCMOS (ID=5) has no handler 
 > > (20110527/exfldio-310)
 > >ACPI Error: Method parse/execution failed [\_SB_.WMID.ESDT] (Node 
 > > 0xfe0002af5800), AE_NOT_EXIST (20110527/psparse-560)
 > >ACPI Error: Method parse/execution failed [\_PTS] (Node 
 > > 0xfe0002af86c0), AE_NOT_EXIST (20110527/psparse-560)
 > >acpi0: AcpiEnterSleepStatePrep failed - AE_NOT_EXIST
 > >Rebooting...
 > >
 > > I've tried FreeBSD 9, FreeBSD 10, and -CURRENT. All have the same problem.
 > 
 > Here's a case where my patch to implement the SystemCMOS region 
 > handler should help; it allows my HP Envy to power down and allows it 
 > to suspend/resume except the LCD backlight doesn't come back when 
 > resuming.  Biggest problem with the patch IMHO is I'm stealing 
 > ("borrowing") from the real time clock (RTC) I/O region, but I don't 
 > think we have an "actual" FreeBSD driver for that.
 > 
 > Reposting here, or search this list for "Naive implementation of 
 > AcpiExCmosSpaceHandler", let me know if it doesn't apply cleanly to 
 > your version of FreeBSD .  I've posted it upstream to the acpica 
 > mailing list, but no response.
 > 
 > diff --git a/source/components/events/evhandler.c 
 > b/source/components/events/evhandler.c

Interesting.  I wonder if this is needed for reading the RTC for the 
time on boot, and writing it back on shutdown - which I would have 
thought too generic to have left out on any machine?  Or is this perhaps 
retrieving at boot then restoring at shutdown some other system-specific 
information in NVRAM?

If the latter, then the usage in /sys/dev/acpi_support/acpi_ibm.c 
revealed below might illustrate another way of dealing with this?

% find /sys/ -type f -exec egrep -H 'rtcin|writertc' {} \; | grep -v 
drm_mode_set_crtcinfo

shows everything using the rtcin() and writertc() functions, implemented 
for x86 at least in /sys/x86/isa/atrtc.c .. but I have no idea whether 
you can access those functions from where / when you're tinkering here.

Yours looks more likely portable for upstream acpica, but it also looks 
potentially quite dangerous 'in the wrong hands' :)

cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: ACPI error messages on Lenovo W540

[Ian Smith]

On Tue, 24 Jun 2014 10:00:35 -0400, John Baldwin wrote:
 > On Monday, June 23, 2014 6:42:28 pm Eric McCorkle wrote:
 > > On 06/23/2014 09:53, John Baldwin wrote:
 > > > On Tuesday, June 17, 2014 9:54:57 am Eric McCorkle wrote:
 > > >> I suspect these might have something to do with the USB 3.0 system not
 > > >> working, though I don't have experience with either the ACPI or USB
 > > >> subsystems.
 > > >
 > > > Does it not work in general, or does it not work after resume?
 > > 
 > > Actually, USB seems to be working quite well.  It even detects an 
 > > already plugged-in mouse during the ith resume.
 > > 
 > > The sign of trouble are some messages that show up during resume:
 > > 
 > > usb_alloc_device: device init 2 failed (USB_ERR_IOERROR, ignored)
 > > ugen0.2:  at usbus2 (disconnected)
 > > uhub_reattach_port: could not allocate new device
 > > 
 > > There had been some timeout messages, which googling seemed to implicate 
 > > was a USB 3.0 issue with lenovos, but those seem to have disappeared (I 
 > > did do a kernel update).
 > > 
 > > Maybe I should test USB 3.0-specific features to see if they are 
 > > working.  Unfortunately, I'm not that familiar with the gritty details 
 > > of USB.  Any ideas for how to do that?
 > 
 > There was a recent fix to acpi_pwrres.c that fixed USB issues on resume for
 > several ThinkPads because the kernel wasn't properly turning certain things
 > back on during resume, so if your problems were only with resume, then 
 > there's
 > a good chance they should now be fixed (and it sounds like they did after you
 > updated).

Well, this is most timely for me; I was about to query you and hps@ for 
advice re debugging knobs to have another crack at debugging this issue!

Not nearly content to wait for MFC, I applied the diff-to-previous from 
r267647 of /sys/dev/acpica/acpi_powerres.c to stable/9, which was clean, 
so I updated source, applied the patch and rebuilt world and kernel:

FreeBSD x200.smithi.id.au 9.3-PRERELEASE FreeBSD 9.3-PRERELEASE #0: Wed 
Jun 25 15:29:28 EST 2014 r...@x200.smithi.id.au:/usr/obj/usr/src/sys/GENERIC  
amd64

After which I suspended and resumed 5 times, to be quintuply sure, and 
yes, my 1GB SwissFlash stick - normally annoying because it has a very 
bright red LED that's always on when the port is powered - lit up every 
time, so the external USB ports losing power problem is fixed on mine.

However, it loses touch with a mounted UFS partition on the stick after 
suspend/resume; I've never been sure if I should expect that to work?

Even so, umount, fsck then remount fixes it, so now my X200 is actually 
usable in traveling-without-rebooting-for-weeks mode, so I'm happy and 
am passing on this good news for all(?) Lenovo Thinkpads to mobile@ too.

Many thanks to you and trasz@, and I'm only slightly apologising for 
riding alongside Eric's other video problem ..

cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: ACPI error messages on Lenovo W540

[Ian Smith]

On Fri, 20 Jun 2014 22:27:17 -0400, Eric McCorkle wrote:
 > On 06/18/2014 03:17, Ian Smith wrote:
 > > On Tue, 17 Jun 2014 09:54:57 -0400, Eric McCorkle wrote:
 > > 
 > >   > I'm trying to set up on a lenovo W540 mobile workstation I recently
 > >   > purchased.  Things work well for the most part (including
 > > suspend/resume),
 > >   > however there's some error messages that I suspect are at the root of
 > > why the
 > >   > nvidia Xorg driver doesn't work, and possibly also at the root of why
 > > USB 3.0
 > >   > won't work either.
 > >   >
 > >   > At suspend/resume, the following error messages show up:
 > >   >
 > >   > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.PEG_:
 > >   > AE_BAD_PARAMETER
 > >   > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP1:
 > >   > AE_BAD_PARAMETER
 > >   > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP2:
 > >   > AE_BAD_PARAMETER
 > >   > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP3:
 > >   > AE_BAD_PARAMETER
 > >   > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP5:
 > >   > AE_BAD_PARAMETER
 > >   >
 > >   > I suspect these might have something to do with the USB 3.0 system not
 > >   > working, though I don't have experience with either the ACPI or USB
 > >   > subsystems.
 > >   >
 > >   > Also, the nvidia Xorg driver fails to work, and causes a similar error
 > >   > message:
 > >   >
 > >   > ACPI Warning: \134_SB_.PCI0.PEG_.VID_._DSM: Argument #4 type mismatch -
 > >   > Found [Buffer], APCI requires [Package] (20130823/nsarguments-97)
 > >   > (the same message gets repeated about 10 times)
 > >   >
 > >   > Again, I don't have any experience with ACPI, but this looks to me like
 > > a
 > >   > vendor-specific quirk.
 > >   >
 > >   > Any advice on how to go about fixing/working around this?
 > > 
 > > Hi Eric,
 > > 
 > > I refer you to freebsd-mobile@ archives for May re these 'failed to set
 > > ACPI power state D2' messages, in thread 'Thinkpad T410: resume broken'.
 > > I'm also cross-posting this back there.
 > 
 > I ran across those also.
 > 
 > > These appear on the suspend path on (AFAICT) all modern Lenovos; X2xx,
 > > T4xx and T5xx at least, though I get similar messages for the Cardbus
 > > bridges on my old T23s.  The EXPn messages at least do appear to be
 > > harmless though they keep causing your sort of concern, and it would be
 > > good in the long run to find out why attempts are being made to set
 > > state D2 on devices that (should indicate that they) don't support it.
 > > 
 > > John Baldwin (cc'd) explains in that thread that the EXPn devices are
 > > "probably PCI-PCI bridges that represent the downstream ports of your
 > > PCI-e root complex)" though I can't say I understand what that means ..
 > > with verbose boot messages you may also see that these are initialised
 > > back into D0 state twice, unlike the other devices.
 > 
 > Whatever they do, the messages suggest that it might just be what amounts to
 > a type error in the ACPI code (apologies for any inaccuracies; I have only
 > cursory knowledge of ACPI, but I know there's some kind of interpreted
 > language in there somewhere).

It's more a virtual machine than an interpreter, in the sense that Java 
isn't interpreted but runs precompiled bytecode, but yes, there could be 
a problem in the AML, derived from the source ASL .. see acpidump(8).

I am (it seems) fortunate that my X200 has pre-KMS i915 graphics that 
work fine including suspend/resume from X or (old) console, so I can't 
speculate about nvidea Xorg issues.

 > Again, sorry for lack of knowledge, but does FreeBSD have any sort of
 > functionality for working around these sort of vendor quirks?

If you could clearly identify the/a problem in the ASL, someone might be 
inspired to help fix it, though ASL-savvy people are thin on the ground; 
ACPI code is a non-trivial learning curve, for this old codger anyway :)

 > > The PEG_ message seems to appear on the more recent ones with integrated
 > > graphics.  I don't know if that message represents a problem or not,
 > > though the later warnings re \134_SB_.PCI0.PEG_.VID_._DSM seem ominous.
 > 
 > Some poking around on google seems to show other lenovos (the T440p) having
 > similar problems with the nvidia drivers.
 > 
 > I suppose a worthwhile experiment might be to remove ACPI from th

Re: ACPI error messages on Lenovo W540

[Ian Smith]

On Tue, 17 Jun 2014 09:54:57 -0400, Eric McCorkle wrote:

 > I'm trying to set up on a lenovo W540 mobile workstation I recently
 > purchased.  Things work well for the most part (including suspend/resume),
 > however there's some error messages that I suspect are at the root of why the
 > nvidia Xorg driver doesn't work, and possibly also at the root of why USB 3.0
 > won't work either.
 > 
 > At suspend/resume, the following error messages show up:
 > 
 > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.PEG_:
 > AE_BAD_PARAMETER
 > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP1:
 > AE_BAD_PARAMETER
 > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP2:
 > AE_BAD_PARAMETER
 > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP3:
 > AE_BAD_PARAMETER
 > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP5:
 > AE_BAD_PARAMETER
 > 
 > I suspect these might have something to do with the USB 3.0 system not
 > working, though I don't have experience with either the ACPI or USB
 > subsystems.
 > 
 > Also, the nvidia Xorg driver fails to work, and causes a similar error
 > message:
 > 
 > ACPI Warning: \134_SB_.PCI0.PEG_.VID_._DSM: Argument #4 type mismatch -
 > Found [Buffer], APCI requires [Package] (20130823/nsarguments-97)
 > (the same message gets repeated about 10 times)
 > 
 > Again, I don't have any experience with ACPI, but this looks to me like a
 > vendor-specific quirk.
 > 
 > Any advice on how to go about fixing/working around this?

Hi Eric,

I refer you to freebsd-mobile@ archives for May re these 'failed to set 
ACPI power state D2' messages, in thread 'Thinkpad T410: resume broken'.
I'm also cross-posting this back there.

These appear on the suspend path on (AFAICT) all modern Lenovos; X2xx, 
T4xx and T5xx at least, though I get similar messages for the Cardbus 
bridges on my old T23s.  The EXPn messages at least do appear to be 
harmless though they keep causing your sort of concern, and it would be 
good in the long run to find out why attempts are being made to set 
state D2 on devices that (should indicate that they) don't support it.

John Baldwin (cc'd) explains in that thread that the EXPn devices are 
"probably PCI-PCI bridges that represent the downstream ports of your 
PCI-e root complex)" though I can't say I understand what that means .. 
with verbose boot messages you may also see that these are initialised 
back into D0 state twice, unlike the other devices.

The PEG_ message seems to appear on the more recent ones with integrated 
graphics.  I don't know if that message represents a problem or not, 
though the later warnings re \134_SB_.PCI0.PEG_.VID_._DSM seem ominous.

It would be good to know if your USB3 issues are connected to the more 
generic issue all these Lenovos appear to have of USB failing entirely, 
only on the external ports, after - depending on model - one or two 
suspend/resume cycles.  There's not even any 5V on these ports, whether 
or not the BIOS has been set to provide 5V on these ports in suspend or 
power-off states.  Does that also happen on yours?

cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: sysctl hw.acpi.acline

[Ian Smith]

On Mon, 16 Jun 2014 16:36:42 +0200, CeDeROM wrote:

 > One application that I am porting needs to know the power supply
 > information from the system. I thought using SYSCTL + ACPI would be
 > the simplest and elegant way. But, I found out that information on the
 > power supply is only available on the laptop machines, while on the
 > desktop machines it does not apply. According to the "man acpi", the
 > "hw.acpi.acline" oid tells the AC line state, so I guess desktop
 > should always tell 1, but there is no such oid on my desktop..
 > 
 > Is this a bug or feature? :-)

Definitely a feature.  The absence of this OID is a sure way to tell if 
the machine you're talking to - which may be remote, so you may not know 
how it's being powered - is or is not (capable of) running on battery.

 > How can I tell the power source on my FreeBSD (i.e. AC, Battery, UPS)?
 > 
 > man acpi:
 > ...
 >  hw.acpi.acline
 >  AC line state (1 means online, 0 means on battery power).
 > 
 > root@hexagon:~ # sysctl hw.acpi.acline
 > sysctl: unknown oid 'hw.acpi.acline': No such file or directory

So this is an AC powered machine.  And it is, most certainly, ON.

Perhaps what you need to do is fit one of these to your machine:

  DED (pronounced "dead") (dark emitting diode) A variation of LED
  technology used exclusively by the CIA for clandestine equipment.
  Also popular as power-off indicators.
  http://www.rane.com/par-d.html

You could also add a DDR (dark dependant resistor) circuit to ring a
bell whenever the DED is emitting, just to be sure it really is OFF.

You should probably avoid using the new super-dark DEDs or you may find 
your room plunged into impenetrable darkness whenever power goes off.

Seriously for a moment: if you do have a UPS you'll need to interrogate 
the UPS software - which varies for different brands of UPS so can't be 
integrated with the BIOS/ACPI - for its state, as David mentioned.

cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: Missing: hw.acpi.thermal.tz%d._HOT

[Ian Smith]

On Sat, 14 Jun 2014 11:07:41 -0700, Sean Bruno wrote:

 > > Just for curious minds:
 > > 
 > > Afternoon and evenings bring direct sunlight to where the machine is.
 > > And I guess that is showing? probably?
 > > # sysctl dev.cpu | grep temp
 > > dev.cpu.0.temperature: 16.8C
 > > dev.cpu.1.temperature: 16.8C
 > > dev.cpu.2.temperature: 16.8C
 > > dev.cpu.3.temperature: 16.8C
 > > dev.cpu.4.temperature: 16.8C
 > > dev.cpu.5.temperature: 16.8C
 > > dev.cpu.6.temperature: 16.8C
 > > dev.cpu.7.temperature: 16.8C
 > 
 > 
 > I have an FX-8150 based system similar, but a bit older that this one:
 > Base Board Information
 > Manufacturer: ASUSTeK Computer INC.
 > Product Name: M5A88-M
 > 
 > Processor Information
 > Socket Designation: AM3R2
 > Type: Central Processor
 > Family: FX
 > Manufacturer: AMD  
 > ID: 12 0F 60 00 FF FB 8B 17
 > Version: AMD FX(tm)-8150 Eight-Core Processor   

Which family, model, stepping is that?

 > At idle, the machine reports pretty low temps:
 > dev.amdtemp.0.%desc: AMD CPU On-Die Thermal Sensors
 > dev.amdtemp.0.%driver: amdtemp
 > dev.amdtemp.0.%parent: hostb4
 > dev.amdtemp.0.sensor_offset: 0
 > dev.amdtemp.0.core0.sensor0: 16.2C

Is it water-cooled?  Roughly, what's the ambient temperature where it 
lives?  Short of forced water cooling, with the watertank feeling cool 
to the touch, I can't see how any electronic equipment can run anything 
like that cool.  If you touch the heatsink, is it cooler than ambient?

 > But when doing builds with all the cpus firing:
 > dev.amdtemp.0.core0.sensor0: 49.5C
 > ...
 > dev.amdtemp.0.core0.sensor0: 52.3C
 > ...
 > dev.cpu.0.temperature: 53.0C
 > 
 > 
 > Seems legit to me.

I don't think so.  Maybe becaus we use Centigrade here.  16C is ~62F, 
I'd have a wooly jumper on.  50C ~= 120F, we get days that hot outback.
  
There's mention in amdtemp.c of some models having a -28C offset:
#define AMDTEMP_FLAG_ALT_OFFSET 0x04 /* CurTmp starts at -28C. */

and later:

535 mask = (sc->sc_flags & AMDTEMP_FLAG_CT_10BIT) != 0 ? 0x3ff : 0x3fc;
536 offset = (sc->sc_flags & AMDTEMP_FLAG_ALT_OFFSET) != 0 ? 28 : 49;
537 temp = pci_read_config(dev, AMDTEMP_THERMTP_STAT, 4);
538 temp = ((temp >> 14) & mask) * 5 / 2;
539 temp += AMDTEMP_ZERO_C_TO_K + (sc->sc_offset - offset) * 10;

I'm not claiming to follow that through the masking, shift and factor, 
and it's returned in Kelvin anyway, but there's clearly a 21 $something 
difference in offset for some models, and see the XXX comments there.

16C + 21C = 37C, which is believable at idle.  53C + 21C = 74C, which is 
quite believable for 8 busy cores, assuming a good h/s & fan.  You can 
leave your finger, for a good while anyway, on a heatsink at 53C.  74C 
will burn you quite quickly; here anyway, most home hot water systems 
are set to deliver between 60 and 70C, which will scald before long.

Touch test?

cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: Missing: hw.acpi.thermal.tz%d._HOT

[Ian Smith]

On Sat, 14 Jun 2014 16:06:36 +1000, Ian Smith wrote:
 > On Fri, 13 Jun 2014 10:08:57 -0700, hiren panchasara wrote:
 >  > On Fri, Jun 13, 2014 at 9:22 AM, Ian Smith  wrote:
 >  > > On Thu, 12 Jun 2014 14:28:33 -0700, hiren panchasara wrote:
 >  > >  > On Tue, Jun 10, 2014 at 8:40 AM, Eric Neblock 
 >  wrote:
 >  > >  > > On Wed, 2014-06-11 at 01:33 +1000, Ian Smith wrote:
 >  > >  > >> On Tue, 10 Jun 2014 09:54:14 -0500, Eric Neblock wrote:
 >  > >  > >>  > Hello all,
 >  > >  > >>  >   I'm trying to figure out what is the _HOT temperature on my 
 > particular
 >  > >  > >>  > processor. I'm running FreeBSD 10 GENERIC on a Sunfire X2200.
 >  > >  > >>  >
 >  > >  > >>  > The processor is an Dual Core AMD Opteron 2218.
 >  > >  > >>  >
 >  > >  > >>  > In the GENERIC kernel, acpi is built in; so, kldload acpi 
 > fails. I've
 >  > >  > >>  > also loaded the amdtemp module at boot time to figure out what 
 > the
 >  > >  > >>  > current temp of the processor is.
 > [..]
 >  > >  > > sysctl: Unknown oid 'hw.acpi.thermal' : No such file or directory
 >  > >  >
 >  > >  > Similar thing here at home desktop running -CURRENT:
 >  > >  >
 >  > >  > CPU: AMD FX(tm)-8350 Eight-Core Processor(4000.24-MHz 
 > K8-class CPU)
 >  > >  >   Origin="AuthenticAMD"  Id=0x600f20  Family=0x15  Model=0x2  
 > Stepping=0
 > 
 > So looking at /sys/dev/amdtemp/amdtemp.c .. here on stable/9 from a few 
 > weeks ago, whic appears to be an MFC of this one on head: 
 > http://svnweb.freebsd.org/base/head/sys/dev/amdtemp/amdtemp.c?view=log
 > 
 > "Driver for the AMD CPU on-die thermal sensors for Family 0Fh/10h/11h 
 > procs." with support added recently also for the 0x16h family, but no 
 > mention of 0x15 .. going by Eric's report, his would appear suoported.

Sorry .. I didn't look closely enough at all.  The version on head does 
appear to support the 0x15 family as well, and quite a bit of the code 
has been reworked and augmented.  #define DEVICEID_AMD_MISC15 0x1603

 > Looking at amdtemp_gettemp() there, I suspect the 0x15 family uses yet 
 > another number or placement of register bits; your ~13C to 15C range of 
 > temps shown seems much more likely to be in the ~52C to 60C range ..

That's changed too .. but none of this explains why yours is reporting 
(apparently) one quarter of the real temperature.  Out of my depth ..

cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: Missing: hw.acpi.thermal.tz%d._HOT

[Ian Smith]

On Fri, 13 Jun 2014 10:08:57 -0700, hiren panchasara wrote:
 > On Fri, Jun 13, 2014 at 9:22 AM, Ian Smith  wrote:
 > > On Thu, 12 Jun 2014 14:28:33 -0700, hiren panchasara wrote:
 > >  > On Tue, Jun 10, 2014 at 8:40 AM, Eric Neblock  
 > > wrote:
 > >  > > On Wed, 2014-06-11 at 01:33 +1000, Ian Smith wrote:
 > >  > >> On Tue, 10 Jun 2014 09:54:14 -0500, Eric Neblock wrote:
 > >  > >>  > Hello all,
 > >  > >>  >   I'm trying to figure out what is the _HOT temperature on my 
 > > particular
 > >  > >>  > processor. I'm running FreeBSD 10 GENERIC on a Sunfire X2200.
 > >  > >>  >
 > >  > >>  > The processor is an Dual Core AMD Opteron 2218.
 > >  > >>  >
 > >  > >>  > In the GENERIC kernel, acpi is built in; so, kldload acpi fails. 
 > > I've
 > >  > >>  > also loaded the amdtemp module at boot time to figure out what the
 > >  > >>  > current temp of the processor is.
[..]
 > >  > > sysctl: Unknown oid 'hw.acpi.thermal' : No such file or directory
 > >  >
 > >  > Similar thing here at home desktop running -CURRENT:
 > >  >
 > >  > CPU: AMD FX(tm)-8350 Eight-Core Processor(4000.24-MHz 
 > > K8-class CPU)
 > >  >   Origin="AuthenticAMD"  Id=0x600f20  Family=0x15  Model=0x2  Stepping=0

So looking at /sys/dev/amdtemp/amdtemp.c .. here on stable/9 from a few 
weeks ago, whic appears to be an MFC of this one on head: 
http://svnweb.freebsd.org/base/head/sys/dev/amdtemp/amdtemp.c?view=log

"Driver for the AMD CPU on-die thermal sensors for Family 0Fh/10h/11h 
procs." with support added recently also for the 0x16h family, but no 
mention of 0x15 .. going by Eric's report, his would appear suoported.

Looking at amdtemp_gettemp() there, I suspect the 0x15 family uses yet 
another number or placement of register bits; your ~13C to 15C range of 
temps shown seems much more likely to be in the ~52C to 60C range ..

cc'ing jkim@, although others have messed with amdtemp more recently.

 > >  > acpi0: <7596MS A7596100> on motherboard

 > >  > # sysctl dev.amdtemp
 > >  > dev.amdtemp.0.%desc: AMD CPU On-Die Thermal Sensors
 > >  > dev.amdtemp.0.%driver: amdtemp
 > >  > dev.amdtemp.0.%parent: hostb4
 > >  > dev.amdtemp.0.sensor_offset: 0
 > >  > dev.amdtemp.0.core0.sensor0: 15.3C
 > >  >
 > >  > # sysctl -a dev.cpu | grep temp
 > >  > dev.cpu.0.temperature: 15.2C
[..]
 > >  > dev.cpu.7.temperature: 15.2C
 > >  >
 > >  > I am not sure how this ^ relates to what acpi reports under thermal.

I assume dev.amdtemp.0.core0.sensor0 is the source for all of those.

 > I am not sure how correct these numbers are but I've enabled AMD's
 > Cool'n'Quiet thingi in BIOS.

Looks like you need to ask someone to add support for family 0x15.  As 
for Eric, with no _TZ support, I don't know how you'd handle overtemps.

 > > And neither of these are reporting hw.acpi.thermal .. is it because the
 > > BIOS / ACPI doesn't present thermal zone information?
 > I'd believe so.
 > 
 > >  Or there aren't
 > > suitable drivers to interpret it?  I've no idea, but does seem curious.
 > >
 > > Any output from?
 > > # acpidump -dt | egrep -i 'TZ|thermal'
 > nothing.
 > 
 > # acpidump -dt | egrep -i 'TZ|thermal'
 > acpidump: RSDT entry 3 (sig OEMB) is corrupt
 > 
 > Now this ^^ error might also suggest something is wrong.

Don't know, but probably not related to the sensor temperatures.

 > > If so, you might want to put your full ASL up somewhere.
 > # acpidump -dt | gzip -c9 >  amd_fx8350.asl.gz
 > 
 > amd_fx8350.asl.gz is attached.

It's no use to me and the list swallowed it; you'd need to put it up at 
an URL somewhere .. but as it has no Thermal Zone section it can't help 
with this issue anyway.

 > By the time I collected everything,
 > 
 > # sysctl dev.cpu | grep temp
 > dev.cpu.0.temperature: 14.0C
 > dev.cpu.1.temperature: 14.0C
 > dev.cpu.2.temperature: 14.0C
 > dev.cpu.3.temperature: 14.0C
 > dev.cpu.4.temperature: 14.0C
 > dev.cpu.5.temperature: 14.0C
 > dev.cpu.6.temperature: 14.0C
 > dev.cpu.7.temperature: 14.0C

56C most likely, unless there's also an offset.  I'm out of clues ..

cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: Missing: hw.acpi.thermal.tz%d._HOT

[Ian Smith]

On Thu, 12 Jun 2014 14:28:33 -0700, hiren panchasara wrote:
 > On Tue, Jun 10, 2014 at 8:40 AM, Eric Neblock  wrote:
 > > On Wed, 2014-06-11 at 01:33 +1000, Ian Smith wrote:
 > >> On Tue, 10 Jun 2014 09:54:14 -0500, Eric Neblock wrote:
 > >>  > Hello all,
 > >>  >   I'm trying to figure out what is the _HOT temperature on my 
 > >> particular
 > >>  > processor. I'm running FreeBSD 10 GENERIC on a Sunfire X2200.
 > >>  >
 > >>  > The processor is an Dual Core AMD Opteron 2218.
 > >>  >
 > >>  > In the GENERIC kernel, acpi is built in; so, kldload acpi fails. I've
 > >>  > also loaded the amdtemp module at boot time to figure out what the
 > >>  > current temp of the processor is.
 > >>  >
 > >>  > With all of that, when performing `sysctl -a` I never seem to be able 
 > >> to
 > >>  > pull up the _HOT value.
 > >>  >
 > >>  > Are there any suggestions on how to be able to view it?
 > >>
 > >> Many thermal zones seen, including some CPUs, don't specify any _HOT
 > >> value, just _PSV and _CRT, which should trigger passive cooling (eg
 > >> clock slowing or throttling) and emergency shutdown, respectively.
 > >>
 > >> What says 'sysctl hw.acpi.thermal' ?
 > >>
 > >> cheers, Ian
 > >
 > > The result is as follows:
 > >
 > > sysctl: Unknown oid 'hw.acpi.thermal' : No such file or directory
 > 
 > Similar thing here at home desktop running -CURRENT:
 > 
 > CPU: AMD FX(tm)-8350 Eight-Core Processor(4000.24-MHz K8-class 
 > CPU)
 >   Origin="AuthenticAMD"  Id=0x600f20  Family=0x15  Model=0x2  Stepping=0
 > 
 > acpi0: <7596MS A7596100> on motherboard
 > 
 > Other related bits:
 > 
 > # sysctl hw.acpi
 > hw.acpi.supported_sleep_state: S3 S4 S5
 > hw.acpi.power_button_state: S5
 > hw.acpi.sleep_button_state: S3
 > hw.acpi.lid_switch_state: NONE
 > hw.acpi.standby_state: NONE
 > hw.acpi.suspend_state: S3
 > hw.acpi.sleep_delay: 1
 > hw.acpi.s4bios: 0
 > hw.acpi.verbose: 0
 > hw.acpi.disable_on_reboot: 0
 > hw.acpi.handle_reboot: 0
 > hw.acpi.reset_video: 0
 > hw.acpi.cpu.cx_lowest: C8
 > #
 > 
 > # sysctl dev.amdtemp
 > dev.amdtemp.0.%desc: AMD CPU On-Die Thermal Sensors
 > dev.amdtemp.0.%driver: amdtemp
 > dev.amdtemp.0.%parent: hostb4
 > dev.amdtemp.0.sensor_offset: 0
 > dev.amdtemp.0.core0.sensor0: 15.3C
 > 
 > # sysctl -a dev.cpu | grep temp
 > dev.cpu.0.temperature: 15.2C
 > dev.cpu.1.temperature: 15.2C
 > dev.cpu.2.temperature: 15.2C
 > dev.cpu.3.temperature: 15.2C
 > dev.cpu.4.temperature: 15.2C
 > dev.cpu.5.temperature: 15.2C
 > dev.cpu.6.temperature: 15.2C
 > dev.cpu.7.temperature: 15.2C
 > 
 > I am not sure how this ^ relates to what acpi reports under thermal.

Well first, unless you've just turned it on, it's idling and lives in a 
refrigerator or coldroom, those temperatures are at best a third of the 
minimum I'd expect to see reported .. and they wouldn't all be the same.

And neither of these are reporting hw.acpi.thermal .. is it because the 
BIOS / ACPI doesn't present thermal zone information?  Or there aren't 
suitable drivers to interpret it?  I've no idea, but does seem curious.

Any output from?
# acpidump -dt | egrep -i 'TZ|thermal'

If so, you might want to put your full ASL up somewhere.  Note: I'm not 
at all qualified to interpret it, just that I'd expect there to be some; 
eg on a Lenovo X200 (Core2 Duo):
root@x200:~ # acpidump -dt | egrep -i 'TZ|thermal'
Notify (\_TZ.THM0, 0x80)
Notify (\_TZ.THM1, 0x80)
Notify (\_TZ.THM0, 0x80)
Notify (\_TZ.THM1, 0x80)
"AdaptiveThermalManagementAC"
"AdaptiveThermalManagementBattery"
Notify (\_TZ.THM0, 0x80)
Notify (\_TZ.THM1, 0x80)
Notify (\_TZ.THM1, 0x80)
Notify (\_TZ.THM0, 0x81)
Scope (\_TZ)
ThermalZone (THM0)
ThermalZone (THM1)
Return (\_TZ.THM0._TMP ())
Notify (\_TZ.THM0, 0x80)

cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: Missing: hw.acpi.thermal.tz%d._HOT

[Ian Smith]

On Tue, 10 Jun 2014 10:40:19 -0500, Eric Neblock wrote:
 > On Wed, 2014-06-11 at 01:33 +1000, Ian Smith wrote:
 > > On Tue, 10 Jun 2014 09:54:14 -0500, Eric Neblock wrote:
 > >  > Hello all,
 > >  >   I'm trying to figure out what is the _HOT temperature on my particular
 > >  > processor. I'm running FreeBSD 10 GENERIC on a Sunfire X2200.
 > >  > 
 > >  > The processor is an Dual Core AMD Opteron 2218.
 > >  > 
 > >  > In the GENERIC kernel, acpi is built in; so, kldload acpi fails. I've
 > >  > also loaded the amdtemp module at boot time to figure out what the
 > >  > current temp of the processor is.
 > >  > 
 > >  > With all of that, when performing `sysctl -a` I never seem to be able to
 > >  > pull up the _HOT value. 
 > >  > 
 > >  > Are there any suggestions on how to be able to view it?
 > > 
 > > Many thermal zones seen, including some CPUs, don't specify any _HOT 
 > > value, just _PSV and _CRT, which should trigger passive cooling (eg 
 > > clock slowing or throttling) and emergency shutdown, respectively.
 > > 
 > > What says 'sysctl hw.acpi.thermal' ?
 > > 
 > > cheers, Ian
 > 
 > The result is as follows:
 > 
 > sysctl: Unknown oid 'hw.acpi.thermal' : No such file or directory
 > 
 > Eric

Sorry Eric, I know nothing about the Suns, and should have noticed. 
Suggest showing 'sysctl hw.acpi' and waiting for someone with a clue.

cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: Missing: hw.acpi.thermal.tz%d._HOT

[Ian Smith]

On Tue, 10 Jun 2014 09:54:14 -0500, Eric Neblock wrote:
 > Hello all,
 >   I'm trying to figure out what is the _HOT temperature on my particular
 > processor. I'm running FreeBSD 10 GENERIC on a Sunfire X2200.
 > 
 > The processor is an Dual Core AMD Opteron 2218.
 > 
 > In the GENERIC kernel, acpi is built in; so, kldload acpi fails. I've
 > also loaded the amdtemp module at boot time to figure out what the
 > current temp of the processor is.
 > 
 > With all of that, when performing `sysctl -a` I never seem to be able to
 > pull up the _HOT value. 
 > 
 > Are there any suggestions on how to be able to view it?

Many thermal zones seen, including some CPUs, don't specify any _HOT 
value, just _PSV and _CRT, which should trigger passive cooling (eg 
clock slowing or throttling) and emergency shutdown, respectively.

What says 'sysctl hw.acpi.thermal' ?

cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax

[Ian Smith]

On Mon, 5 May 2014 06:25:21 +, Poul-Henning Kamp wrote:
 > In message <20140505153421.w11...@sola.nimnet.asn.au>, Ian Smith writes:
 > 
 > >I need to do more tests on stable/9; it didn't work with the offered 
 > >workarounds on 9.2-RELEASE (leaving VESA out of kernel leaves me with no 
 > >screen on resume in console mode, setting sysctl dev.[ue]hci.*.wake=1 
 > 
 > Do we have a canonical page with all the various workarounds one should
 > attempt in order to get suspend/resume to work ?

Bits scattered all over the place.  For the above there's:
http://unethicalblogger.com/2013/12/03/scratchiest-neckbeard-freebsd-x200.html
which refers to te tail of this thread in -usb (and -stable)
http://lists.freebsd.org/pipermail/freebsd-usb/2013-July/thread.html#12242
which began with Adrian's post in
http://lists.freebsd.org/pipermail/freebsd-usb/2013-June/thread.html

Then there's the wiki page: https://wiki.freebsd.org/SuspendResume
which leads to some more bits, lots more scattered through -acpi and 
-laptop over the time.

There used to be lots of useful per-laptop snippets in the FLCL (freebsd 
laptop compatibility list) which sadly disappeared last year, but I just 
googled up an archive of it at http://archive.today/CVo46 latest from 
mid-2013.  Ah sorry, spoke too soon, individual pages redirect to eg: 
http://laptop.bsdgroup.de/freebsd/index.html?action=list_laptop_mf&mfid=1 
which is still down :(

Ian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax

[Ian Smith]

On Sun, 4 May 2014 13:51:20 -0700, Adrian Chadd wrote:
 > On 4 May 2014 13:00, Poul-Henning Kamp  wrote:

 > > I havn't seen suspend/resume work for ages on my T4xx laptops and
 > > as far as I recall it never worked on this T430s at all.
 > 
 > I've tested it (-HEAD) on:
 > 
 > * T43
 > * T60
 > * T60p
 > * T400
 > * T500
 > * T420
 > * X220
 > 
 > I'm actively using the T60, T400 and X220 right now.

So, is the USB not working after $n resumes on T4xx and T2xx (at least) 
now fixed in HEAD?  If so, it would be REALLY good to MFC whatever fixed 
it to 10 and hopefully to 9 before 9.3.

I need to do more tests on stable/9; it didn't work with the offered 
workarounds on 9.2-RELEASE (leaving VESA out of kernel leaves me with no 
screen on resume in console mode, setting sysctl dev.[ue]hci.*.wake=1 
fails to even start to resume) though if that works on 10 I'd give it a 
go, despite Darren Pilgrim's dvd1_to_memstick script failing to have pkg 
use any of the local DVD packages, which is why I went back to 9.2

I know you only like working on HEAD, but unless there's API/ABI reasons 
preventing MFC, it would be great to have 9.3 work in this respect .. my 
X200 is not useful for purpose if it won't suspend/resume 100% reliably, 
with USB, and I don't want to run 11 on it, it's needed for developing 
non-FreeBSD stuff (in freepascal, if that's not a dirty word here :) and 
for that it needs to be rock solid while travelling from place to place.

 > I'd like to see it working on more laptops and I've worked with
 > various people in the past to try and fix whichever resume issues I
 > find.

Indeed; last I heard was last July with unsolved USB issues on your 
T400, and the mysterious but related 'CPU0: local APIC error 0x40'

 > I'm happy leaving this as-is but at some point something has to be
 > bitten and the bugs in the drivers / ACPI stuff need to be fixed. :)

It's a bit disconcerting if fixes only ever make it into HEAD, for me.

cheers, Ian

(someone please sing out if I shouldn't be crossposting to -arch)
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax

[Ian Smith]

On Sun, 4 May 2014 17:25:50 -0700, Adrian Chadd wrote:
 > [snip]
 > 
 > The easy-to-run test is "sysctl dev.cpu.0.cx_lowest=Cmax" and then use stuff.

This doesn't work, on stable/9 at least, in that it only sets cpu.0 .. 
you need to set sysctl hw.acpi.cpu.cx_lowest - which rather surprised 
me, although that's what /etc/rc.d/power_profile has always set.  I 
guess it's only cpu.0.freq that still sets all CPUs in sync.

Further, rather than
 -economy_cx_lowest="HIGH" # Offline CPU idle state
 +economy_cx_lowest="Cmax" # Offline CPU idle state
you could use "LOW" which already sets it to "Cmax", though on 8.2:
 lowest_value="`(sysctl -n dev.cpu.0.cx_supported | \
awk '{ print "C" split($0, a) }' -) 2> /dev/null`"

I'm not sure what the point of setting cx_lowest to C8 is on a machine 
where lowest cx_supported is C3, but it seems to do no harm on mine.

Where does C8 come from anyway?  Is that the lowest on any known 
hardware, or the lowest the ACPI spec supports?

root@x200:~ # sysctl -a | grep cx
hw.acpi.cpu.cx_lowest: C3
dev.cpu.0.cx_supported: C1/1/1 C2/2/1 C3/3/57
dev.cpu.0.cx_lowest: C3
dev.cpu.0.cx_usage: 0.00% 0.79% 99.20% last 35us
dev.cpu.1.cx_supported: C1/1/1 C2/2/1 C3/3/57
dev.cpu.1.cx_lowest: C3
dev.cpu.1.cx_usage: 0.08% 1.59% 98.32% last 62us

root@x200:~ # sysctl dev.cpu.0.cx_lowest=Cmax
dev.cpu.0.cx_lowest: C3 -> C8
root@x200:~ # sysctl -a | grep cx
hw.acpi.cpu.cx_lowest: C3
dev.cpu.0.cx_supported: C1/1/1 C2/2/1 C3/3/57
dev.cpu.0.cx_lowest: C8 
dev.cpu.0.cx_usage: 0.00% 5.66% 94.33% last 73us
dev.cpu.1.cx_supported: C1/1/1 C2/2/1 C3/3/57
dev.cpu.1.cx_lowest: C3 
dev.cpu.1.cx_usage: 0.07% 1.91% 98.01% last 2us

root@x200:~ # sysctl dev.cpu.1.cx_lowest=C2
dev.cpu.1.cx_lowest: C3 -> C2
root@x200:~ # sysctl -a | grep cx
hw.acpi.cpu.cx_lowest: C3   
dev.cpu.0.cx_supported: C1/1/1 C2/2/1 C3/3/57
dev.cpu.0.cx_lowest: C8 
dev.cpu.0.cx_usage: 0.00% 0.19% 99.80% last 474us
dev.cpu.1.cx_supported: C1/1/1 C2/2/1 C3/3/57
dev.cpu.1.cx_lowest: C2 
dev.cpu.1.cx_usage: 3.47% 96.52% 0.00% last 1us

root@x200:~ # sysctl hw.acpi.cpu.cx_lowest=Cmax
hw.acpi.cpu.cx_lowest: C3 -> C8
root@x200:~ # sysctl -a | grep cx
hw.acpi.cpu.cx_lowest: C8
dev.cpu.0.cx_supported: C1/1/1 C2/2/1 C3/3/57
dev.cpu.0.cx_lowest: C8
dev.cpu.0.cx_usage: 0.00% 3.05% 96.94% last 351us
dev.cpu.1.cx_supported: C1/1/1 C2/2/1 C3/3/57
dev.cpu.1.cx_lowest: C8
dev.cpu.1.cx_usage: 0.00% 7.05% 92.94% last 2us

I've long run with C3 in AC power mode without issue, but don't know if 
that's true for all machines; all yours and mine are Thinkpads!

 > The problem is that we're not getting anywhere near enough exposure to
 > this kind of stuff because we don't have it on by default and we don't
 > have an active QA group with ridiculous amounts of hardware.
 > 
 > So, I'd like to flip it on and then start blacklisting devices that
 > actively don't work in halt states above C1. We're never going to
 > cross this bridge fully if we leave things at C1 out of fear.
 > 
 > I'm only suggesting we do this on -HEAD. If it's too scary then we can
 > always flip the default back to C1 for 11.0-RELEASE.

Yeah, I think this likely uncontroversial - unlike lid state S3 - and I 
don't recall hearing about machines that fail below C1 if lower states 
are shown as available.  As you say, this might shake these out.

But where would you put such a blacklist?  Someting like USB quirks?

cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax

[Ian Smith]

On Sun, 4 May 2014 01:27:38 -0700, Adrian Chadd wrote:
 > Hi,
 > 
 > I'd like to propose flipping a few things:
 > 
 > * Flipping the default lid state to S3. I think ACPI suspend/resume
 > seems to work well enough these days and I've not met anyone lately
 > who expects the default from their laptop to be "stay awake with the
 > lid shut."

Meet me; sitting here right now with the X200 lid closed, backlight off, 
idling but 'working' via ssh.  Laptops running as (mostly) headless 
servers would normally run with lid down - been doing this for years, 
keeps the cockroaches out, mostly :)  Anyway, this would be a very poor
default on any machine that didn't resume completely well every time.

'Seems to work well enough' on a still fairly limited range of laptops, 
I gather.  I've yet to get this X200 (on stable/9) to suspend without 
losing USB - after the _second_ suspend, unlike yours - and besides it's 
not a big deal to set it to S3 when desired.  Maybe an rc.conf knob like
'suspend_on_lid="YES"' ono rather than requiring sysctl.conf setting?

 > * Save chip bugs that we should add workarounds for, we should be OK
 > to enter lower sleep states when idling. Flipping this may expose some
 > further crazy driver, platform or timer bugs, but they again likely
 > should be fixed.

This seems likely less controversial, and should suit most, probably.

An Nate Lawson said often many years ago, we really need some sort of 
profile mechanism to describe as a package different ACPI and power 
settings for different brands / models / usage cases, plugins if you 
like; then 'resumes_reliably' could condition stuff.  But I digress ..

2c, and not assuming myself to be any sort of 'average user', Ian

 > what do people think?
 > 
 > 
 > -a
 > 
 > 
 > Index: etc/defaults/rc.conf
 > ===
 > --- etc/defaults/rc.conf (revision 265255)
 > +++ etc/defaults/rc.conf (working copy)
 > @@ -642,9 +642,9 @@
 >  devfs_set_rulesets="" # A list of /mount/dev=ruleset_name settings to
 >   # apply (must be mounted already, i.e. fstab(5))
 >  devfs_load_rulesets="YES" # Enable to always load the default rulesets
 > -performance_cx_lowest="HIGH" # Online CPU idle state
 > +performance_cx_lowest="Cmax" # Online CPU idle state
 >  performance_cpu_freq="NONE" # Online CPU frequency
 > -economy_cx_lowest="HIGH" # Offline CPU idle state
 > +economy_cx_lowest="Cmax" # Offline CPU idle state
 >  economy_cpu_freq="NONE" # Offline CPU frequency
 >  virecover_enable="YES" # Perform housekeeping for the vi(1) editor
 >  ugidfw_enable="NO" # Load mac_bsdextended(4) rules on boot
 > Index: sys/dev/acpica/acpi.c
 > ===
 > --- sys/dev/acpica/acpi.c (revision 265255)
 > +++ sys/dev/acpica/acpi.c (working copy)
 > @@ -620,11 +620,12 @@
 > 
 >  /*
 >   * Dispatch the default sleep state to devices.  The lid switch is set
 > - * to UNKNOWN by default to avoid surprising users.
 > + * to S3 to mirror what everything else iBook and later does.
 >   */
 >  sc->acpi_power_button_sx = acpi_sleep_states[ACPI_STATE_S5] ?
 >   ACPI_STATE_S5 : ACPI_STATE_UNKNOWN;
 > -sc->acpi_lid_switch_sx = ACPI_STATE_UNKNOWN;
 > +sc->acpi_lid_switch_sx = acpi_sleep_states[ACPI_STATE_S3] ?
 > +ACPI_STATE_S3 : ACPI_STATE_UNKNOWN;
 >  sc->acpi_standby_sx = acpi_sleep_states[ACPI_STATE_S1] ?
 >   ACPI_STATE_S1 : ACPI_STATE_UNKNOWN;
 >  sc->acpi_suspend_sx = acpi_sleep_states[ACPI_STATE_S3] ?
 > ___
 > freebsd-acpi@freebsd.org mailing list
 > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
 > To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
 > 
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: Re: ACPI bug submission

[Ian Smith]

On Mon, 21 Apr 2014 12:07:51 -0700, Kevin Oberman wrote:
 > On Mon, Apr 21, 2014 at 9:05 AM, Matt Grice  wrote:
 > 
 > > Sorry, PEBKAC error, it appears I've been replying off-list.

Ah, I would have left it to Kevin had I known.  However this raises a 
couple of interesting points .. cutting mercilessly ..

 > > hw.acpi.cpu.cx_lowest: C1
 > > Power saving Cx states are NOT enabled.

Which makes the cool temperatures you noted, Kevin, more amazing.

Matt, you might try adding to /etc/rc.conf:
  performance_cx_lowest=C3
  economy_cx_lowest=C3

 > > hw.acpi.thermal.tz0.temperature: 39.0C
 > > Thermal zone 0 is 39C. This is usually the CPU. 39C is VERY cool.

Yes it is, but see below ..

 > > Hopefully it i accurate.
 > > hw.acpi.thermal.tz0.active: -1
 > > ACPI is NOT throttling the CPU to control temperature
 > > hw.acpi.thermal.tz0.passive_cooling: 0
 > > ACPI is not increasing system cooling capability (usually the fan) to
 > > reduce temperature. NOTE: This does not mean non-ACPI controls are not 
 > > used!

Actually, active cooling is the fan/s, and passive cooling is CPU speed 
reduction and/or cycle throttling.

 > > hw.acpi.thermal.tz0.thermal_flags: 0
 > > hw.acpi.thermal.tz0._PSV: 95.0C
 > > At 95C, turn the cooling (fans) to maximum.

It's the passive (throttling) temperature that kicks in at 95C

 > > hw.acpi.thermal.tz0._HOT: -1
 > > hw.acpi.thermal.tz0._CRT: 98.0C
 > > At 98C, throttlethe CPU to reduce temperature

And that's the critical temperature that should cause shutdown.

 > > hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1
 > > hw.acpi.thermal.tz0._TC1: 0
 > > hw.acpi.thermal.tz0._TC2: 50
 > > hw.acpi.thermal.tz0._TSP: 0
 > > hw.acpi.thermal.tz1.temperature: 39.0C
 > > Odd that tz0 and tz1 are both 39C. Seems unlikely. May be different CPU
 > > sensor or something else.

But see below ..

 > > hw.acpi.thermal.tz1.active: -1
 > > hw.acpi.thermal.tz1.passive_cooling: 0
 > > hw.acpi.thermal.tz1.thermal_flags: 0
 > > hw.acpi.thermal.tz1._PSV: -1
 > > hw.acpi.thermal.tz1._HOT: -1
 > > hw.acpi.thermal.tz1._CRT: 98.0C
 > > At 98C, power down (if supported). This is different from the hardware
 > > shutdown on severe overtemp that simply kills power.

Right.  This zone just has _CRT, also 98C, no active or passive cooling.

[..]

 > > acpiconf -i 0
 > >
 > > [root@Raptor] /usr/ports/comms/wspr# acpiconf -i o
 > > Design capacity:   4400 mAh
 > > Last full capacity: 3757 mAh
 > > Battery is getting old and only will charge to 85% of it's design capacity.

It would be nice if it worked even that well, but ..

 > > Technology: secondary (rechargeable)
 > > Design voltage: 11100 mV
 > > Capacity (warn):185 mAh
 > > Capacity (low): 129 mAh
 > > Low/warn granularity:   56 mAh
 > > Warn/full granularity:  3572 mAh
 > > Model number: GRAPE32
 > > Serial number: 27
 > > Type: LION
 > > OEM info:   SANYO
 > > State:  critical
 > > Your battery is dying!
 > > Remaining capacity: 0%
 > > OK. It's dead.

Or just isn't getting charged (though leaving it fully discharged for 
long will kill it in the end anyway).  One of my Thinkpad T23s has a 
broken charging circuit, not unknown on that model; it runs on AC but a) 
won't charge any battery and b) dies on loss of AC power, even with a 
charged battery .. perhaps similar to what's happened to this one?

 > > Remaining time: unknown
 > > Present rate:   0 mA (0 mW)
 > > It's not discharging.

On AC power, present rate usually shows the charging rate until fully 
charged, so it's clearly not charging at all.

 > > Present voltage:7870 mV
 > > It is at 7.9 volts which is too low to run the system.
 > >
 > > Since the system appears to be on AC power, but the battery is not
 > > charging, something is wrong here. I have no idea what.
 > > It appears that either the charging system or the battery has
 > > failed.Neither involved the OS, but indicates a hardware issue with the
 > > device.

We concur.  Matt, you could maybe try this battery in another laptop if 
you have access to one, or an external charger, ie the battery may still 
be at least partially ok and only the charge circuit is broken (bummer!) 
or OTOH the battery may be so stuffed that the charge circuit refuses to 
try to charge it, but isn't broken as such - so a new battery may help.

 > > There are several ACPI variables I don't recognize or am simply not
 > > familiar with, but this will give you some   idea what many of
 > > the important ones are. Remember that ACPI is firmware and may have errors
 > > that result in its lying to the OS. I don't trust some of what I see,
 > > especially the temperature. Most laptops idle at between   50
 > > and 60C. Seeing two zones at 39C is very odd.

I'd have agreed with this before ~10 weeks ago, when my son bought me a 
Thinkpad X200 from an auction site out of the blue - without battery or 
charger, and with a dodgy serial 

Re: ACPI bug submission

[Ian Smith]

On Sat, 19 Apr 2014 22:15:00 +0100, Matt Grice wrote:
 > Hi all,
 > 
 > First of all, let me apologise if I have sent this report to you in
 > error. I am using the latest version of PC-BSD 10 which I believe uses
 > a "vanilla kernel" (excuse the linuxism) from FreeBSD.
 > 
 > Symptoms: Lid close does not initiate sleep, battery is not recognised
 > and does not charge.
 > 
 > 
 > My hardware is an Acer Extensa 5630EZ. I hope the rest of the
 > information you might find interesting is in the output of dmesg after
 > a verbose boot, which is attached.
 > 
 > The output of acpidump -dt can be found here:
 > 
 > http://pastebin.com/vpPN86qR

What Lars said about 'hw.acpi.lid_switch_state=S3' .. assuming suspend &
resume work properly normally (via 'acpiconf -s3' or your sleep button)

But regarding your battery, from your dmesg it IS being recognised:

 battery0:  on acpi0
 acpi_acad0:  on acpi0
  [..]
 battery0: battery initialization start
 acpi_acad0: acline initialization start
 battery0: critically low charge!
 acpi_acad0: On Line
  [..]
 battery0: battery initialization done, tried 1 times

.. but is reporting critically low state on startup.

Which is either a dead battery, or a broken charging circuit.  Usually 
that has nothing to do with the OS; if you have it plugged in when not 
running, it should fully charge, or at least charge past the critically 
low state fairly quickly - and even when running on AC power.

So as Kevin asked, 'sysctl hw.acpi' and 'acpiconf -i0' could be helpful.

cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: C-States configuration

[Ian Smith]

On Fri, 11 Apr 2014 00:22:43 -0700, hiren panchasara wrote:
 > On Thu, Apr 10, 2014 at 12:18 AM, Kevin Oberman  wrote:
 > > On Wed, Apr 9, 2014 at 11:22 AM, hiren panchasara
 > >  wrote:
 > >>
 > >> On Wed, Apr 9, 2014 at 11:07 AM, Anton Sayetsky  wrote:
 > >> > 2014-04-09 20:40 GMT+03:00 hiren panchasara
 > >> > :
 > >> >> I am running -current on my T420 at r263906M
 > >> >>
 > >> >> debug.acpi.acpi_ca_version: 20130823
 > >> >>
 > >> >> o/p of sysctl -a | grep acpi - http://bpaste.net/show/199806/
 > >> >>
 > >> >>  and I have following in my rc.conf:
 > >> >>
 > >> >> performance_cx_lowest="Cmax"
 > >> >> economy_cx_lowest="Cmax"
 > >> >>
 > >> >> But I still get:
 > >> >>
 > >> >> % sysctl -a | grep cx_lowest
 > >> >> hw.acpi.cpu.cx_lowest: C1
 > >> >> dev.cpu.0.cx_lowest: C1
 > >> >> dev.cpu.1.cx_lowest: C1
 > >> >> dev.cpu.2.cx_lowest: C1
 > >> >> dev.cpu.3.cx_lowest: C1
 > >> >>
 > >> >> And I can do:
 > >> >> # sysctl dev.cpu.0.cx_lowest=Cmax
 > >> >> dev.cpu.0.cx_lowest: C1 -> C8
 > >> >>
 > >> >> that tells me that Cmax is C8.
 > >> >>
 > >> >> % sysctl -d dev.cpu.0.cx_lowest
 > >> >> dev.cpu.0.cx_lowest: lowest Cx sleep state to use
 > >> >>
 > >> >> I was expecting cx_lowest to be set to C8 because of rc.conf config I
 > >> >> have.
 > >> >>
 > >> >> What am I missing here?
 > >> >>
 > >> >> cheers,
 > >> >> Hiren
 > >> > Try to set LOW instead of Cmax.
 > >>
 > >> I will try it again.
 > >>
 > >> Interestingly enough, on an amd machine, it worked as I expected with
 > >> a bit more current version of -head but same version of acpica:
 > >> debug.acpi.acpi_ca_version: 20130823
 > >>
 > >> cpus came up with cx_lowest set to C8 with Cmax in rc.conf
 > >>
 > >> cheers,
 > >> Hiren
 > >
 > >
 > > Setting Cx values is a bit confusing.  Things may not mean what you think.
 > > CMax is always C8 because this is the largest possible value of a Cx state,
 > > not because C8 is actually available.The reason for this is that some
 > > systems have non-sequencial Cx states. That is the maximum value my be C5,
 > > but C2 may not be available. So the idea is to allow ANY C-state up to the
 > > maximum. LOWEST works well as long as no states are skipped. If they are,
 > > you are limited to the states before the skipped state.
 > >
 > > To see the actual available states, look at dev.cpu.0.cx_supported.
 > >
 > > The recommended value for best power savings is :Cmax. That will allow
 > > skipping over missing C-states. Also, the available states often differ
 > > between AC power and battery. On my T320:
 > > AC dev.cpu.0.cx_supported: C1/1/1 C2/3/104
 > > Battery  dev.cpu.0.cx_supported: C1/1/1 C2/2/80 C3/3/109
 > 
 > AC:
 > hw.acpi.cpu.cx_lowest: C8
 > dev.cpu.0.cx_supported: C1/1/1 C2/3/104
 > dev.cpu.0.cx_lowest: C8
 > dev.cpu.0.cx_usage: 8.23% 91.76% last 38us
 > 
 > Battery:
 > hw.acpi.cpu.cx_lowest: C8
 > dev.cpu.0.cx_supported: C1/1/1 C2/2/80 C3/3/109
 > dev.cpu.0.cx_lowest: C8
 > dev.cpu.0.cx_usage: 12.35% 3.22% 84.42% last 3088us
 > 
 > So, pretty similar on my T420 with following in rc.conf
 > performance_cx_lowest="Cmax"
 > economy_cx_lowest="Cmax"
 > 
 > How do I know what C-state cpu0 is in, at any point in time? Or thats
 > not how things work?

smithi@x200:~ % x200stat
Fri Apr 11 18:24:19 EST 2014 dev.cpu.0.freq: 200
0.00% 2.47% 97.51% last 520us
0.01% 2.22% 97.75% last 817us
dev.acpi_ibm.0.fan_speed: 3391
dev.acpi_ibm.0.fan_level: 0
dev.acpi_ibm.0.thermal: 40 44 -1 41 36 -1 35 -1
hw.acpi.thermal.tz0.temperature: 40.0C
hw.acpi.thermal.tz1.temperature: 36.0C
State:  high
Remaining capacity: 96%
Remaining time: unknown
Present rate:   0 mW
Present voltage:12329 mV

I'm not sure that 'at any point in time' could be very meaningful.  The 
above shows sysctl -n dev.cpu.0.cx_usage & sysctl -n dev.cpu.1.cx_usage 
at one time - or rather at the two relativelty close times that each of 
those sysctls was retrieved, both covering less than 1ms.  Heisenberg's 
Uncertainty Principle would most likely apply to any closer examination, 
but you could chase down where the statistics are accumulated, somewhere 
in cpufreq IIRC.

cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: Current state of "RTC wakeup" support

[Ian Smith]

On Mon, 24 Feb 2014 18:13:16 +0100, Willi Eggeling wrote:
 > Hi!
 > 
 > According to the FreeBSD ACPI project page 
 > (http://www.freebsd.org/projects/acpi/) RTC support is not realized 
 > yet. As the last update was in 2006 I just wanted to ask if there is 
 > any change about RTC-triggered wakeup that has not been posted to the 
 > page. Is there any?
 > 
 > All I need is to time system wakeup from S4/S5 on a HP ProLiant N40L.

You're talking about 
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern%2F73823&cat=
which is now our oldest outstanding ACPI PR.

I did some RTC programming in a past life - in Turbo Pascal no less - 
and this is not hard to do.  I had a patch sort-of on the way when mav@ 
changed all the clocks and timers around, for 9.0 IIRC, and I got lost.

Without delving too deeply into details, there's an alarm wake bit in 
the RTC that we gratuitously clear whenever we write to the RTC, both on 
initialisation and when updating CMOS time, also perhaps on init for 
other uses such as using the RTC interrupt as a low res timer or for 
profiling, maybe?

ISTR that we mostly only needed to mask (ie not disturb) that wake 
interrupt bit once set and add a small userland utility to set, clear 
and enable/disable the wake timer bit and set the BCD time, the BIOS 
should do the rest.

We don't support S4 on anything these days, AFAIK, but this could work 
both from S5 (power off) and S3 (suspend to RAM).

cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: loud fan pavilion ze2000

[Ian Smith]

On Mon, 30 Dec 2013 17:39:04 -0500, ito wrote:
 > Ok, 
 > 
 >  So I have tried looking around more, and working on powerd.There seems 
 > to be no difference in any change I make aside from the temperature staying 
 > below where I set PSV.
 > 
 > hw.acpi.thermal.tz0_PSV: 85C
 > 
 > (set back to what it was)

So does your noisy fan run less often with powerd running?  Does it run 
cooler when idle now?  What freq does it run at when idle?  Here I run 
gkrellm which displays freq and temperature among many other goodies.

 > > I wouldn't worry about that.  Are you not running powerd(8)?  As Kevin 
 > > Oberman often points out, p4tcc is for thermal control - as we've just 
 > > exercised - but cpufreq(4), controlled by powerd, is the way to save 
 > > power when you don't need the CPU running at maximum frequency, which is 
 > > likely most times.  Running it slower when idle _greatly_ reduces heat.
 > 
 > cpufreq and powerd, but I have a question about that; in the man page
 >  for powerd, a bug is stated thus;
 > "if powerd is used with power_profile, they may override each other."
 > 
 > -in any case it seems to me both are being used on this machine.-
 > 
 > man cpu freq snip--
 > ..."The cpufreq driver provides a unified kernel and user interface to CPU
 > frequency control drivers.  It combines multiple drivers offering different
 > settings into a single interface of all possible levels.  Users can access 
 > this interface directly via sysctl(8) or by indicating to 
 > /etc/rc.d/power_profile that it should switch settings when the AC line state
 > changes via rc.conf(5)"...
 > 
 > snip
 > 
 > I thought that cpufreq calls or is called by /etc/rc.d/power_profile.  I see
 > in the script that is 'power_profile' that it is called via devd.
 > 
 > Does one actually edit the script, /etc/rc.d/power_profile?  Or is there 
 > a more user friendly approach? 

This is not really a problem; no, and yes.  devd only runs power_profile 
whenever the line state changes between AC power and battery.  When this 
happens, power_profile sets both C-state and CPU frequency to the values 
set in rc.conf of the below variables, the default settings of which are 
in /etc/defaults/rc.conf:

performance_cx_lowest="HIGH"# Online CPU idle state
performance_cpu_freq="NONE" # Online CPU frequency
economy_cx_lowest="HIGH"# Offline CPU idle state
economy_cpu_freq="NONE" # Offline CPU frequency

With performance_cpu_freq and economy_cpu_freq set to the default NONE, 
you'll see that power_profile makes no change to CPU frequency.  If you 
set it to say HIGH or LOW, then power_profile will set freq to the max 
or min freq - or other value you specify - but only until powerd next 
adjusts freq according to load, likely less than 500ms later, so even 
then it's really a non-issue .. only relevant when NOT using powerd.

You likely DO want to set performance_cx_lowest and economy_cx_lowest 
however.  I use "C3" for both but that may not be best for your Celeron:

smithi on t23% sysctl dev.cpu.0 | grep -v '\.%'
dev.cpu.0.freq: 733
dev.cpu.0.freq_levels: 1133/19100 733/12500
dev.cpu.0.cx_supported: C1/0 C2/84 C3/120
dev.cpu.0.cx_lowest: C3
dev.cpu.0.cx_usage: 0.02% 28.09% 71.87% last 681us

You can see mine's mostly running C3 state (on AC power), nice and cool 
and easy on power .. I'm only listening to a radio stream and typing :)

Read https://wiki.freebsd.org/TuningPowerConsumption for the good oil.

 > While trying to dig out the problem:

Non-problem, but digging is educational ..

 > I tried kldstat -v | grep cpu
 > 
 >  503  cpu/smist
 >  502  cpu/powernow
 >  501  cpu/p4tcc
 >  500  cpu/hwpstate
 >  499  cpu/est
 >  486  legacy/cpu
 >  33   cpu/acpi_perf
 >  24   acpi/cpu
 >  410  cpu/cpufreq
 >  112  cpu/ichss
 >  37   cpu/acpi_throttle
 > 
 > Most if not all of these are related to thermal control, no?  It looks like 
 > there
 > is redundancy, is that the case?

No, GENERIC contains drivers for many CPUs and chipsets.  See cpufreq(4) 
which mentions all those except hwpstate, for some AMDs I recall, as is 
powernow, though all the cpufreq drivers still lack their own man pages.

cheers, Ian

PS you may find freebsd-mobile a better list for many questions such as 
this one, not specifically to do with ACPI functioning and development.

[snip]
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: loud fan pavilion ze2000

[Ian Smith]

On Sat, 21 Dec 2013 18:01:35 -0500, ito wrote:
 > Hello Ian,
 > 
 > At 50 through 62C the dev.cpu.0.freq: 1298
 > 
 > at 70C , 1135
 > 
 > back up to 1298

Right, 1135 / 1298 ~= .875 = 7/8, so yes that's your 1.3GHz CPU dropping 
down one step for thermal control.

 >dev.cpu.0.freq_levels: 1298/-1 1298/-1 973/-1 811/-1
 > 649/-1 486/-1 324/-1 162/-1
 > 
 >   Also directly below that:
 > 
 >dev.p4tcc.0.freq_settings: 1/-1 8750/-1 7500/-1 6250/-1   5000/-1
 > 3750/-1 2500/-1 1250/-1
 > 
 > I suppose that is the 8 (freq_levels) you where referring to.  Further I
 > infer that this -1 means that the BIOS has set them or does set them. 

Yes, but here the -1 indicates for freq_levels that power consumption in 
milliwatts at that freq is unknown, likely the same for p4tcc settings.

 > I set hw.acpi.thermal.tz0._PSV: 70C
 > 
 > Trying "find / acpi" to see it work.
 > 
 > While doing the above (find) the fan is on but not full out.

find(1) works disk harder than CPU as a rule, though here that command 
gets xorg about 70% busy, and keeps going for ages after hitting ^C, as 
it lists each file on the disk :)  Maybe useful: find / -name "*acpi*"

>From below:
 > PS, is this the exact command?
 > "   dd if=/dev/random > of=/dev/null "

No, no.  I was careful to be precise, and yes a mistyped dd can be 
dangerous, and redirected to a file could indeed fill your disk.  
Fortunately that one doesn't work, invalid filename.  see dd(1).

 > I am reluctant to type anything like dd: anything: I'm not really that
 > confident with the command line.

Without your redirection it just reads from /dev/random, burning CPU, 
discarding the output, until you hit ^C .. perfectly safe.

 > After setting the PSV value it does not go above 71 when rendering
 > animation with blender.

Yeah rendering will busy the CPU (and GPU too) pretty well.  Good, so 
we know passive cooling works (in case your fan ever really packs up).

 > I will try cleaning it again, but I think I remember that I thought
 > cleaning would fix it before.

Unless you live in an extraordinarily dust-free environment, this needs 
doing with some regularity anyway.  I did mine the other day, as summer 
ambient temperatures over 30C are becoming normal here (happy solstice!)

At the temperatures you've quoted, apart from annoying fan noise, it 
doesn't seem broken to me.  How warm does it run just idling (versus 
what ambient temperature where you are)?

 > I looked at acpi_thermal, have to digest it.
 > 
 > Found the source online for freebsd acpi.

It'll be on your disk if you installed sources.

 > So I guess that I could adjust the throttling, through the process that
 > the machine uses to save power??

I wouldn't worry about that.  Are you not running powerd(8)?  As Kevin 
Oberman often points out, p4tcc is for thermal control - as we've just 
exercised - but cpufreq(4), controlled by powerd, is the way to save 
power when you don't need the CPU running at maximum frequency, which is 
likely most times.  Running it slower when idle _greatly_ reduces heat.

cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: loud fan pavilion ze2000

[Ian Smith]

On Fri, 20 Dec 2013 10:00:35 -0500, ito wrote:
 > Hi,
 > 
 > I posted a question to the freebsd forums (under mobile computing) in
 > which I was seeking help with a old laptop (hp pavilion ze2000) because
 > of fan noise.  The problem is not really that the fan is too loud,
 > although that is part of it, it is that it cycles frequently (about
 > every 21 sec, at average use).  I seems to me now that maybe here would
 > be more appropriate.
 > I am having trouble finding information about the acpi functions in
 > particular.  So I thought maybe I could get help here.  For instance,
 > according to the information below, is the passive cooling set to start
 > at 85.0C (Celsius) which would be 185 Fahrenheit?  Is this very hot to
 > start to cool down passively?  Why is active cooling set to -1?  Where
 > do I find the definitions of these things... like the flags?

Starting at the end, see acpi_thermal(4) ie 'man acpi_thermal'.  Not 
sure about the flags, you may need to consult the sources.

Apparently your BIOS is running the fan (ie active cooling) so there's 
no control of it you can access here.  Both .active: -1 and .ACx: -1.. 
indicate that, and the fact that your fan is cycling off and on.  The 
usual advice about cleaning out the airways with compressed air (or 
well-directed moderate vacuum) applies.  Old fans will sometimes need 
replacing, though it's when they stop being noisy (ie stop running), or 
are making grinding sounds (bearings) that you have to worry.

You might want to check sysctl hw.acpi.thermal.tz0.temperature through a 
few fan cycles to see what internal temperature setpoints it's using for 
fan on and off, usually with some hysteresis either way.  60C is not 
hot, though likely hot enough to be running the fan at some level.

85C is pretty warm, when passive cooling kicks in (throttling or 
otherwise slowing the CPU to reduce heat), and has nothing to do with 
the fan, although it should also be running flat out at that time.  You 
may need to monitor sysctl dev.cpu.0.freq to see that happening, if freq 
is variable.  95C should initiate an emergency shutdown.

You should be able to set .user_override=1 then temporarily set ._PSV a 
good deal lower (say 70C) and make it work hard ('dd if=/dev/random 
of=/dev/null' works for me :) if you want to see what your system does 
to implement passive cooling.  Old Celerons usually can be throttled to 
at least half speed, if not the full range of 1/8 to 7/8 max CPU speed.

cheers, Ian

 > sysctl -a | grep thermal
 > 
 > hw.acpi.thermal.min.runtime: 0
 > hw.acpi.thermal.polling_rate: 10
 > hw.acpi.thermal.user_override: 0
 > hw.acpi.thermal.tz0.temperature: 60.0C
 > hw.acpi.thermal.tz0.active: -1
 > hw.acpi.thermal.tz0.passive_cooling: 1
 > hw.acpi.thermal.tz0.thermal_flags: 0
 > hw.acpi.thermal.tz0._PSV: 85.0C
 > hw.acpi.thermal.tz0._HOT: -1
 > hw.acpi.thermal.tz0._CRT: 95.0C
 > hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1
 > hw.acpi.thermal.tz0._TC1: 2
 > hw.acpi.thermal.tz0._TC2: 3
 > hw.acpi.thermal.tz0._TSP: 50
 > 
 > 
 > Any insight would be appreciated,
 > 
 > -eg
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: ACPI Error

[Ian Smith]

On Tue, 3 Dec 2013 11:27:47 +0400, ??? ?? wrote:
 > Здравствуйте, Freebsd-acpi.

Dec  3 10:57:40 fw kernel: AcpiOsExecute: failed to enqueue task, consider 
increasing the debug.acpi.max_tasks tunable
Dec  3 10:57:40 fw kernel: ACPI Error: Method parse/execution failed 
[\_GPE._L24] (Node 0xfe000763cd40), AE_NO_MEMORY (20110527/psparse-560)
Dec  3 10:57:40 fw kernel: ACPI Exception: AE_NO_MEMORY, while evaluating GPE 
method [_L24] (20110527/evgpe-606)
Dec  3 10:57:40 fw kernel: AcpiOsExecute: failed to enqueue task, consider 
increasing the debug.acpi.max_tasks tunable

So have you tried increasing the debug.acpi.max_tasks tunable in your
/boot/loader.conf?  See acpi(4) /LOADER TUNABLES.  What happens then?

cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: P-state setting suddenly disappeared, what gives?

[Ian Smith]

On Fri, 15 Nov 2013, John Baldwin wrote:
 > On Thursday, November 14, 2013 6:13:43 pm Jung-uk Kim wrote:
 > > On 2013-11-14 17:41:44 -0500, Adrian Chadd wrote:
 > > > Hi all,
 > > >
 > > > I have this Lenovo T400 that I've been doing FreeBSD development on
 > > > for a while.
 > > >
 > > > It has a P8700 in it:
 > > >
 > > > CPU: Intel(R) Core(TM)2 Duo CPU P8700  @ 2.53GHz (2527.07-MHz
 > > > 686-class CPU)
 > > >
 > > > Now, up until yesterday, ACPI exported the required twiddles to
 > > > enter various different P-states.
 > > >
 > > > However, as of sometime yesterday, it stopped being able to do so.
 > > >
 > > > sysctl dev.cpu.0.freq returns nothing. Setting it to something
 > > > retuns "device not configured." The frequency list (ie, the P-state
 > > > list) is still fine.
 > > >
 > > > I had to load cpufreq.ko to get the enhanced speedstep stuff to
 > > > show up, but (a) it doesn't support this CPU (and it seems to have
 > > > stopped growing EST bits after Pentium M CPUs..) and (b) setting
 > > > the frequency using it versus P-state settings doesn't save as much
 > > > power.
 > > >
 > > > I'd like to try and debug why the heck this is.
 > > >
 > > > The laptop still works fine, things are just not as "nice" as they
 > > > once were.
 > > >
 > > > Any ideas? Any suggestions on where to start debugging this?
 > > 
 > > SSDT tables for Intel processors are usually dynamic and often times
 > > additional tables are loaded per _OSC or _PDC. [1]  Basically, we
 > > advertise our capabilities from sys/dev/acpica/acpi_cpu.c, depending
 > > on loaded device drivers.  Unfortunately, some times it is too late
 > > and some SSDTs are not properly loaded.  Also, warm booting from other
 > > OSes to FreeBSD may cause similar problems.
 > > 
 > > To debug the problem, you need to dump DSDT and SSDTs and try to
 > > understand _OSC (or _PDC), _PCT and _PSS for your system.
 > 
 > Also, the reason that est.c doesn't hardcode tables for modern CPUs is that 
 > on 
 > modern systems the tables are provided by ACPI via the acpi_perf(4) driver.

I hate to mention it again without offering to write them, but alas, 

http://www.freebsd.org/cgi/man.cgi?query=acpi_perf&apropos=0&sektion=0&manpath=FreeBSD+10-current&arch=default&format=html

as ever says: Sorry, no data found for `acpi_perf'.  Nor any of the 
absolute or relative drivers listed in cpufreq(4).  Good GSoC project?

cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: Xeon E5 cpu work in low status

[Ian Smith]

On Mon, 4 Nov 2013, Adrian Chadd wrote:
 > On 4 November 2013 14:24, Konstantin Belousov  wrote:
 > 
 > > My Intel board DQ67OW starts with the fixed CPU speed, which is
 > > configurable in BIOS. Unless OS starts managing the frequency with the
 > > cpufreq and powerd, CPU is locked to the pre-configured speed. It was
 > > not easy to understand why my single-user memory b/w benchmarks show
 > > half of the expected throughput for the cache, until I found the setting
 > > and found that Intel defaults to 1/2 of the marketing frequency.
 > >
 > > For my board, it is Performance->Processor Overrides->Maximum Non-Turbo
 > > Ratio.  It was set to 17, normal CPU mode is 34, turbo is 38 max.
 > 
 > Does powerd throttle each individual core like this? I don't have
 > anything laptop-y that's recent enough for that to matter.

Unless something's changed recently I've missed, no.  My 9 box is still 
broken, so ref to 8.2 sources .. start with /sys/kern/kern_cpu.c, 
cpufreq(4) and results of find /sys/ -name "*freq*".  Nate Lawson 
commented way back:

/*
 * Only initialize one set of sysctls for all CPUs.  In the future,
 * if multiple CPUs can have different settings, we can move these
 * sysctls to be under every CPU instead of just the first one.
 */
 
I recall that some CPUs had potential for individual settings (voltage, 
freq) but some only per-package rather than per-core, and then there's 
the thermal control settings as well.  I believe Kevin's right, p4tcc 
and acpi_throttle should be disabled by default, on most CPUs anyway, 
and that at least is just a simple change to hints, as a start.

It's quite a deep rabbit warren, and most docs are only in the code - eg 
still? no mans for most if not all of the absolute and relative cpufreq 
drivers mentioned in cpufreq(4), as I recall - and of course the moving 
targets with newer CPUs .. so have fun down there!

cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: Hyper mode for powerd

[Ian Smith]

On Wed, 10 Jul 2013 13:43:56 -0600, Warren Block wrote:
 > On Wed, 10 Jul 2013, Ian Smith wrote:
[..]
 > > > Interesting point.  100mS is a perceptible lag.
 > > 
 > > Maybe just.  On that beast I think you could use 50ms with no noticeable
 > > powerd CPU usage, maybe even 25ms.  In fact I think doing just that with
 > > hadp mode might get you all the interactive responsiveness you want, and
 > > still let powerd use a range of freqs as required.  Playing with -r and
 > > -i will also alter the responsiveness curve quite a bit.
 > > 
 > > With it then testing load and increasing frequency 5 times as often, on
 > > full load it should shift up 5 times more quickly, and hadp mode already
 > > shifts freq up by a factor of 4 on each poll_interval, so it should get
 > > from 1600 to 3601 in one! iteration, and even if using p4tcc/throttling,
 > > from 200 to 3601 in only two or three steps (200 x 4 = 800, 800 x 4 =
 > > 3200) with even three steps then taking only 150ms, well inside your
 > > current 250ms interval.  Maybe give that a try?
 > 
 > Wow!  -r 50 with either hadp or hyper mode feels fine interactively.

You sound surprised, but I'm not.  Nate Lawson introduced powerd at 
FreeBSD 6.0, using a Thinkpad T23 at that time, 1133/733 MHz, and 250mS 
was a reasonable default for laptops then.  In fact, I bought my first 
2ndhand T23 around 6.1-RELEASE precisely because Nate was working on 
ACPI and cpufreq etc, and the T23 was then one of the few machines that 
reliably suspended and resumed (and still is!), a must for me.

What powerd(8) could really use is an update to its man page (or a page 
in the handbook, or wiki?) suggesting some reasonable defaults for the 
range of hardware nowadays running it.  When mav@ added hiadaptive mode 
I was quite skeptical at first, and of course it proved useless for the 
two-speed T23, which would jump to max speed at the drop of a hat but 
then take forever to shuffle back down to lower speed, but is clearly 
advantageous for more modern machines - esp. with more frequent polling.

I guess powerd(8) would be also a good place to mention the advantage of 
turning off p4tcc and acpi_throttle in loader.conf, as at least a step 
towards deprecating their use with powerd?  [Kevin, what do you think?]

 > > > Timing 'periodic daily' now with a full cache and powerd not running:
 > > > 995.53 real28.15 user   132.17 sys
 > > >
 > > > With 'powerd -a hyper -n hyper -v > /tmp/powerd.log':
 > > > 2322.06 real58.72 user   305.22 sys
 > > >
 > > > Load varied enough that it would drop to 200MHz quite often.  Picking a
 > > > random part of the log:
[..]
 > > > changing clock speed from 3601 MHz to 200 MHz
 > > > load   4%, current freq  200 MHz (26), wanted freq  200 MHz
 > > > now operating on AC power; changing frequency to 3601 MHz
 > > > load  20%, current freq  200 MHz (26), wanted freq 3601 MHz
 > > > changing clock speed from 200 MHz to 3601 MHz
 > > > now operating on AC power; changing frequency to 200 MHz
 > > > load   3%, current freq 3601 MHz ( 0), wanted freq  200 MHz
 > 
 > > Hunting away.
 > 
 > Is that a bad thing, though?  Effectively, it's just PWM, if you see what I
 > mean.

I do, but to extend that analogy, compare an inverter with squarewave 
output to one using a stepped pseudo-sine wave, as most non-pure-sine 
inverters do today, much smoother and more efficient too.  I don't know 
the actual cost of changing freqs via sysctl, but suspect less often and 
smaller stepsizes are going to be more efficient and less likely to 
shift to a wildly inappropriate freq for load.  Perhaps my mechanical 
engineering bent worries about wear and tear on the 'gearbox', as it 
were, which of course we know to be a non-issue electronically :)

 > > Over twice as long to run.  Maybe now try at 50ms in hadp mode and you'll
 > > have a good idea how fast that runs, and how it feels.
 > 
 > The same periodic daily test as before, again with the first run discarded to
 > load the cache.
 > 
 > powerd -a hyper -n hyper -p 50 -v > /tmp/powerd.log
 > 977.44 real47.79 user   238.48 sys
 > 
 > powerd -a hadp -n hadp -p 50 -v > /tmp/powerd.log
 > 874.18 real28.89 user   140.00 sys

Well hadp here gets the job done more quickly at any rate, both 
absolutely and in terms of system and user time.

If you're really burning up to hack on powerd :) a timestamp including 
milliseconds on the -v output lines (which might be cut to two lines max 
per change) would make it far easier to see what was happening, when ..

cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: Hyper mode for powerd

[Ian Smith]

On Tue, 9 Jul 2013 12:40:11 -0600, Warren Block wrote:
 > On Tue, 9 Jul 2013, Ian Smith wrote:
 > > On Sat, 6 Jul 2013 20:09:46 -0600, Warren Block wrote:
 > > > On Sun, 7 Jul 2013, Ian Smith wrote:
[..]
 > > the only thing that adjusts freqs is powerd itself.  So no, it's not
 > > hunting for you.  But then, due to you having disabled p4tcc and
 > > acpi_throttle, your lowest speed is 1600, only 1/2.25 x 3600, a far cry
 > > from the up to 32:1 sort of ranges seen with p4tcc etc enabled.
 > > 
 > > What I'm concerned about is what happens engaging your hyper mode with
 > > out-of-the-box settings, ie with p4tcc or acpi_throttle enabled as by
 > > default.  Would you care to find out? :)  I have no means to do so.
 > 
 > > > /boot/loader.conf:
 > > > hint.p4tcc.0.disabled="1"
 > > > hint.acpi_throttle.0.disabled="1"
 > > > hw.acpi.cpu.cx_lowest="C3"
 > 
 > Commenting those entries out gives:
 > 
 > dev.cpu.0.freq_levels: 3601/30 3600/30 3500/30 3400/30
 > 3300/30 3200/30 3100/30 3000/30 2900/30 2800/30
 > 2700/30 2600/30 2500/30 2400/247000 2300/224000 2200/202000
 > 2100/182000 2000/163000 1750/142625 1600/91000 1400/79625 1200/68250
 > 1000/56875 800/45500 600/34125 400/22750 200/11375
 > dev.est.0.freq_settings: 3601/30 3600/30 3500/30 3400/30
 > 3300/30 3200/30 3100/30 3000/30 2900/30 2800/30
 > 2700/30 2600/30 2500/30 2400/247000 2300/224000 2200/202000
 > 2100/182000 2000/163000 1600/91000
 > dev.p4tcc.0.freq_settings: 1/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1
 > 2500/-1 1250/-1

Right, cpufreq has added 1750, 1400, 1200, 1000, 800, 600, 400 and 200, 
the latter being 1/8 of the lowest absolute freq of 1600, due to p4tcc. 
That's a range of 18:1, not as bad as 32:1 but still quite a lot.

You may find it instructive (though once is probably enough :) to set 
debug.cpufreq.verbose=1 in loader and watch cpufreq working out which 
freqs to use from those available.  It does prefer absolute freqs, but 
still uses the relative freqs to setup the lower freqs.  There's also 
debug.cpufreq.lowest, but messing with that requires custom tuning.

 > With only that change and powerd running in hyper mode, it subjectively feels
 > slower to start things.

At 1/8 the speed, that's not too surprising ..

[..]

 > > > /etc/rc.conf:
 > > > powerd_flags="-a hyper -n hyper"
 > > 
 > > Still on 9.1 at least,
 > > #define DEFAULT_ACTIVE_PERCENT 75
 > > #define DEFAULT_IDLE_PERCENT   50
 > > #define DEFAULT_POLL_INTERVAL  250 /* Poll interval in 
 > > milliseconds */
 > > 
 > > So hyper mode will select max freq if load at 1600MHz is > 75/4 = 18.75%
 > > after 250mS.  I use 200mS and there's no impact on powerd CPU usage even
 > > at my idle 733MHz; your responsiveness may benefit from using say 100mS?
 > 
 > Interesting point.  100mS is a perceptible lag.

Maybe just.  On that beast I think you could use 50ms with no noticeable 
powerd CPU usage, maybe even 25ms.  In fact I think doing just that with 
hadp mode might get you all the interactive responsiveness you want, and 
still let powerd use a range of freqs as required.  Playing with -r and 
-i will also alter the responsiveness curve quite a bit.

With it then testing load and increasing frequency 5 times as often, on 
full load it should shift up 5 times more quickly, and hadp mode already 
shifts freq up by a factor of 4 on each poll_interval, so it should get 
from 1600 to 3601 in one! iteration, and even if using p4tcc/throttling, 
from 200 to 3601 in only two or three steps (200 x 4 = 800, 800 x 4 = 
3200) with even three steps then taking only 150ms, well inside your 
current 250ms interval.  Maybe give that a try?

 > It occurs to me that CPU load is really a poor predictor of what is happening
 > on an interactive session.  powerd ought to have a wakeup signal.  On a
 > keypress or mouse move or some other type of user input, powerd would jump to
 > the highest frequency of the current profile.  It does not matter as much how
 > it decides to drop back down.

You're talking about some pretty major kernel hacking, apart from powerd 
in userland.  Maybe getting devd to notify on every keypress and mouse 
click (mouse movement would be insanely busy) but I think that'd be OTT 
and get you in far deeper water than you want, I suspect :)
 
 > Using devd to switch powerd profiles would be interesting.  powerd would have
 > to be able to switch profiles while running, I think.  Maybe startup cost is
 > not that high.

At the moment powerd uses devd notification for AC/battery state changes 
only.  I

Re: Hyper mode for powerd

[Ian Smith]

On Sat, 6 Jul 2013 20:09:46 -0600, Warren Block wrote:
 > On Sun, 7 Jul 2013, Ian Smith wrote:
 > 
 > > So even if cpu_running_mark were 100% (-r100), anything busier than 25%
 > > of our example 75MHz would shift to maximum freq immediately, where the
 > > load will likely plummet to just a few percent, way less than the 25%
 > > (at -r100) needed to keep it at that freq; ie it will most likely hunt.
 > 
 > It may do that, but if so it's doing it more quickly than is visible running
 > powerd -a hyper -n hyper -v.

Apart from some possible under-the-hood adjustment by thermal control in 
an over-temperature situation (?) and /etc/rc.d/power_profile poking the 
freq on AC/battery changes (not applicable to yours), as far as I know 
the only thing that adjusts freqs is powerd itself.  So no, it's not 
hunting for you.  But then, due to you having disabled p4tcc and 
acpi_throttle, your lowest speed is 1600, only 1/2.25 x 3600, a far cry 
from the up to 32:1 sort of ranges seen with p4tcc etc enabled.

What I'm concerned about is what happens engaging your hyper mode with 
out-of-the-box settings, ie with p4tcc or acpi_throttle enabled as by 
default.  Would you care to find out? :)  I have no means to do so.

 > > You don't appear to be taking any notice of the -i idle percentage here;
 > > perhaps that would be a more useful shift-down criterion?  Even so, with
 > > a full house of frequencies, I can't see this being easy to tune as is.
 > > 
 > > Show "sysctl -a | egrep 'freq|cx'" and we'll have something to chew on?
 > > And your powerd_flags setting?
 > 
 > /boot/loader.conf:
 > hint.p4tcc.0.disabled="1"
 > hint.acpi_throttle.0.disabled="1"
 > hw.acpi.cpu.cx_lowest="C3"
 > 
 > I've routinely used the first two since first reading about them, I think in
 > another post by Kevin.

Indeed, Kevin's been chewing on this bone for quite some time :) but I 
don't know if there's any PR + simple patch that may attract attention?  
I also don't know if the situation is the same on AMD CPUs, or others.

 > /etc/rc.conf:
 > powerd_flags="-a hyper -n hyper"

Still on 9.1 at least,
#define DEFAULT_ACTIVE_PERCENT  75
#define DEFAULT_IDLE_PERCENT50
#define DEFAULT_POLL_INTERVAL   250 /* Poll interval in milliseconds */

So hyper mode will select max freq if load at 1600MHz is > 75/4 = 18.75% 
after 250mS.  I use 200mS and there's no impact on powerd CPU usage even 
at my idle 733MHz; your responsiveness may benefit from using say 100mS?

 > performance_cx_lowest="Cmax"
 > performance_cpu_freq="HIGH"
 > 
 > That grep provides a lot of unrelated "freq" stuff, so here's a guess at what
 > you want to see:

Yes, I tried it on a borrowed Lenovo SL500; lots more than on my T23!

 > hw.acpi.cpu.cx_lowest: C8

Never heard of C8, but I'm way out of touch with latest hardware.

 > machdep.acpi_timer_freq: 3579545
 > machdep.i8254_freq: 1193182
 > machdep.tsc_freq: 3309792585
 > dev.cpu.0.freq: 3601
 > dev.cpu.0.freq_levels: 3601/30 3600/30 3500/30 3400/30
 > 3300/30 3200/30 3100/30 3000/30 2900/30 2800/30
 > 2700/30 2600/30 2500/30 2400/247000 2300/224000 2200/202000
 > 2100/182000 2000/163000 1600/91000

Interesting specifying 300W right down to 2500MHz before decreasing, and 
it's quite a large set of primary freqs, only 4 on one 2400MHz Core2Duo.

 > dev.cpu.0.cx_supported: C1/1/1 C2/2/64 C3/3/96
 > dev.cpu.0.cx_lowest: C8
 > dev.cpu.0.cx_usage: 31.99% 64.88% 3.12% last 1203us

Some changes in -current there.  cpu.1.* to cpu.3.* the same as usual, 
apart from varying cx_usage, so you can safely omit them from reports.

[..]

 > dev.est.0.freq_settings: 3601/30 3600/30 3500/30 3400/30
 > 3300/30 3200/30 3100/30 3000/30 2900/30 2800/30
 > 2700/30 2600/30 2500/30 2400/247000 2300/224000 2200/202000
 > 2100/182000 2000/163000 1600/91000

[.. same as freq_levels, without throttling ..]

 > This is an i5, with the "3601" being turbo mode.

With that beast I'm amazed you can really notice slower responsiveness 
w/ 4 CPUs @ 1600MHz, but then I get by with a P3-M at 1133/733MHz :)

It would be interesting to see cpu.0.freq_levels, est.0.freq_settings 
and the p4tcc.0 settings - and whether it hunts - with default tuning on 
some sort of lightish load - perhaps a big find like on the daily runs?

cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: USB ports on Lenovo T400 do not work after a suspend/resume

[Ian Smith]

On Sun, 7 Jul 2013 18:47:03 -0700, Adrian Chadd wrote:
 > On 7 July 2013 13:49, Lars Engels  wrote:
 > > On Sun, Jun 30, 2013 at 03:02:57PM -0700, Adrian Chadd wrote:
 > >> On 30 June 2013 07:22, Ian Smith  wrote:
 > >>
 > >> > After removing [numbers] (for WITNESS?), diff started making sense.
 > >> > The below is between the first and second suspend/resume cycles in
 > >> > dmesg-3.txt, encompassing the others.
 > >>
 > >> Cool!
 > >>
 > >> > Nothing of note that I can see, if that usb hub-to-bus remapping is
 > >> > normal.  As you said, 'CPU0: local APIC error 0x40' looks maybe sus.
 > >> > Maybe someone who knows might comment on that?
 > >> >
 > >> > Just checking: you've tried other USB devices apart from uftdi0?
 > >>
 > >> Yup, there's no 5v on the port.
 > >
 > > Oh, BTW: can you check if you have power on the ports after the first
 > > resume and no power after all next resumes until you reboot your
 > > notebook?
 > > That's the situation I had and maybe it can lead to something. ;)

 > Nope, no power after first resume if i have nothing plugged in.
 > 
 > Why?

Checking one more point .. do the USB ports come up ok if you originally 
boot with nothing plugged in?  If so (or if not), does that local APIC 
error message appear the same then too?

cheers, Ian

PS OT: finally found a USB keyboard but I'd forgotten that my friend's 
machine is an SL500, not T500.  Moreover, because its keyboard+trackpad 
etc is non-working (internally disconnected), I have no way to resume it 
without the kbd (and the 9.1-R memstick) plugged in.  Even with kbd and 
memstick left in and using acpiconf -s3 it suspends ok but is hung after 
resume by dabbing power button; no screen and kbd is dead too - sorry, 
no help there.  OTOH my son just bought a refurb T430 ('doze 7, beats 8 
anyway) which I should get to play with a bit this week.
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: USB ports on Lenovo T400 do not work after a suspend/resume

[Ian Smith]

On Sun, 7 Jul 2013 03:26:24 -0700, Jeremy Chadwick wrote:
 > On Sun, Jul 07, 2013 at 03:51:12PM +1000, Ian Smith wrote:
 > > On Sun, 30 Jun 2013 15:02:57 -0700, Adrian Chadd wrote:
 > >  > On 30 June 2013 07:22, Ian Smith  wrote:
 > > [..]
 > >  > > Nothing of note that I can see, if that usb hub-to-bus remapping is
 > >  > > normal.  As you said, 'CPU0: local APIC error 0x40' looks maybe sus.
 > >  > > Maybe someone who knows might comment on that?
 > > 
 > > Does noone know what that signifies?  Maybe it's not relevant to this.
 > 
 > It's too vague to know.  The error comes from lapic_handle_error(),
 > which is a generic/small routine which pulls the local APIC error status
 > register.  (Note I'm saying APIC, not ACPI -- two different things)

Indeed; I've been familiar with PICs since c.'79.  Googling to check 
what the 'A' stood for I found this .. from '97 but usefully descriptive 
perhaps: http://people.freebsd.org/~fsmp/SMP/papers/apicsubsystem.txt

I also found this from March 2011 involving Mike Tancsa, you and jhb@ :)
http://freebsd.1045724.n5.nabble.com/CPU0-local-APIC-error-0x40-CPU1-local-APIC-error-0x40-td3961805.html

 > apic_vector.S sets this up/makes use of this function, and its done as
 > an interrupt handler.

Whether an (unserviced?) interrupt error is related to Adrian's symptom 
- apparent total failure of USB reinitialisation on resume, but only if 
no USB devices exist in the external slots - remains to be seen.  hps@ 
has just confirmed that it should work the same as on boot, but then 
this error was flagged on boot - perhaps it also manifests on resume?

 > I think this is one of those situations where you have to know *what* is
 > being set up/done at that moment in time for the error code to mean
 > something.  Maybe booting verbose would give more information as to what
 > was being done that lead up to the line.
 > 
 > I've CC'd John Baldwin who might have some ideas.

Thanks.  We have verbose dmesg already.  Thread starts (in -stable) at
http://lists.freebsd.org/pipermail/freebsd-stable/2013-June/073917.html
and amidst some wild goose chases, pointer to verbose dmesg etc is at
http://lists.freebsd.org/pipermail/freebsd-stable/2013-June/074018.html

cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: USB ports on Lenovo T400 do not work after a suspend/resume

[Ian Smith]

On Sun, 30 Jun 2013 15:02:57 -0700, Adrian Chadd wrote:
 > On 30 June 2013 07:22, Ian Smith  wrote:
[..]
 > > Nothing of note that I can see, if that usb hub-to-bus remapping is
 > > normal.  As you said, 'CPU0: local APIC error 0x40' looks maybe sus.
 > > Maybe someone who knows might comment on that?

Does noone know what that signifies?  Maybe it's not relevant to this.

 > > Just checking: you've tried other USB devices apart from uftdi0?
 > 
 > Yup, there's no 5v on the port.

I was rather taken aback to hear this.  Would not this indicate a 
failure to reinitialise the basic underlying USB hardware on resume?

More than a bit bemused, Ian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: Hyper mode for powerd

[Ian Smith]

On Thu, 4 Jul 2013 30:12:12 -0600, Warren Block wrote:

 > Attached is a proposed patch for -head that adds a "hyper" mode to powerd.
 > Instead of slewing like the adaptive modes, this mode drops all the way to
 > the lowest frequency when the system is idle, and jumps all the way to the
 > highest frequency when there is any load.
 > 
 > Subjectively, it seems more responsive for desktop use than hiadaptive mode.
 > That's hard to benchmark.  Power usage is another question. This mode might
 > use less power than the adaptive modes, but that's also difficult to
 > benchmark.
 > 
 > Comments welcome.

I'll get to what Kevin talks about later, but want to address this in 
the context of how most modernish systems will run without deliberate 
tuning, that is with both absolute (eg est, powernow, acpi_perf) and 
relative (eg p4tcc, acpi_throttle) freq drivers enabled as shipped, see 
cpufreq(4) - though it may be somewhat out of date these days.

Kevin is on the money, I believe, about the relative drivers; they add 
freqs of 7/8 down to 1/8 in 12.5% steps of a base absolute frequency, 
but offer little or no power savings over the base freq, keep the same 
CPU voltage and frequency, merely dropping between 1 and 7 out of every 
8 cycles (to put it simply), by design to control excessive temperature. 

cpufreq merely treats these extra frequencies as equivalent in value to 
the primary, absolute levels, perhaps two to half a dozen from est / 
powernow, which shift both voltage and frequency, and there's nothing 
powerd can do to control - or even distinguish? - added relative freqs.

We've often seen lately freq_levels ranging from say 2400 down to 75MHz, 
a range of 32:1, using the absolute levels plus all possible rates in 
between from the relative drivers.  It's far from an exact science, most 
often I/O or network speed will be big factors, but it's perhaps fair to 
speculate that a process keeping a CPU (more likely CPUs) at 75MHz let's 
say 50% busy / 50% idle, is going to be something like only 1/32 as busy 
cranked up to 2400MHz - maybe less than 2% busy.

Looking at your patch, 'scuse trimming and tab loss,

+   if (load > cpu_running_mark / 4) {
+   freq = freqs[0];
+   if (curfreq != freq) {
+   if (vflag) {
[..]
+   }
+   idle = 0;
+   if (set_freq(freq) != 0) {
[..]
+   }
+   }
+   } else {
+   freq = freqs[numfreqs - 1];
+   if (curfreq != freq) {
+   if (vflag) {
[..]
+   }
+   idle = 0;
+   if (set_freq(freq) != 0) {
[..]
+   }
+   }
+   }

So even if cpu_running_mark were 100% (-r100), anything busier than 25% 
of our example 75MHz would shift to maximum freq immediately, where the 
load will likely plummet to just a few percent, way less than the 25% 
(at -r100) needed to keep it at that freq; ie it will most likely hunt.

You don't appear to be taking any notice of the -i idle percentage here; 
perhaps that would be a more useful shift-down criterion?  Even so, with 
a full house of frequencies, I can't see this being easy to tune as is.

Show "sysctl -a | egrep 'freq|cx'" and we'll have something to chew on?
And your powerd_flags setting?

Of course anyone having a large number of freqs down to very slow could
mitigate that by setting debug.cpufreq.lowest (or powerd's -m switch) to 
something more sensible, perhaps 300MHz or so, but even then it might be 
wise to chose an absolute rather than relative rate.  If you disable 
p4tcc and throttling, you'll see how many absolute levels your CPU runs, 
and you may find using only those with hadp mode satisfies your needs?

No argument this stuff is difficult to benchmark, even without the near
infinite variety of possible workload scenarios, and apart from mav@'s 
power measurements with various things tuned or disabled, I've seen very 
little in the way of real data over the years.

cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: USB ports on Lenovo T400 do not work after a suspend/resume

[Ian Smith]

On Sat, 29 Jun 2013, Adrian Chadd wrote:
 > On 27 June 2013 04:58, Ian Smith  wrote:
 > > We don't yet know if this is a bus, ACPI &/or USB issue.  Home yet? :)
 > 
 > Yup:
 > 
 > http://people.freebsd.org/~adrian/usb/
 > 
 > dmesg.boot = dmesg at startup
 > 
 > 1 - after powerup, usb device in
 > 2 - after acpiconf -s3 suspend/resume, w/ a USB device plugged in
 > 3 - after acpiconf -s3 suspend/resume, with a USB device removed
 > before suspend/resume

After removing [numbers] (for WITNESS?), diff started making sense.  
The below is between the first and second suspend/resume cycles in 
dmesg-3.txt, encompassing the others.

Nothing of note that I can see, if that usb hub-to-bus remapping is 
normal.  As you said, 'CPU0: local APIC error 0x40' looks maybe sus.  
Maybe someone who knows might comment on that?

Just checking: you've tried other USB devices apart from uftdi0?

Out of ideas, and my depth, Ian

===
--- dm3.a   2013-06-30 21:49:48.0 +1000
+++ dm3.b   2013-06-30 21:50:30.0 +1000
@@ -1,23 +1,21 @@
-ugen3.2:  at usbus3
-[] uftdi0:  on usbus3
+ugen3.2:  at usbus3 (disconnected)
+[] uftdi0: at uhub4, port 2, addr 2 (disconnected)
 (ada0:ahcich0:0:0:0): spin-down
 [] acpi_lid0: wake_prep enabled for \134_SB_.LID_ (S3)
 [] acpi_button0: wake_prep enabled for \134_SB_.SLPB (S3)
-[] uhub0: at usbus0, port 1, addr 1 (disconnected)
-[] uhub1: at usbus1, port 1, addr 1 (disconnected)
+[] uhub2: at usbus0, port 1, addr 1 (disconnected)
+[] uhub0: at usbus1, port 1, addr 1 (disconnected)
 ugen1.2:  at usbus1 (disconnected)
 ugen1.3:  at usbus1 (disconnected)
-[] ubt0: at uhub1, port 2, addr 3 (disconnected)
-[] uhub2: at usbus2, port 1, addr 1 (disconnected)
+[] ubt0: at uhub0, port 2, addr 3 (disconnected)
+[] uhub1: at usbus2, port 1, addr 1 (disconnected)
 ugen2.2:  at usbus2 (disconnected)
 pci0:0:28:0: Transition from D0 to D3
 pci0:0:28:1: Transition from D0 to D3
 pci0:0:28:3: Transition from D0 to D3
 pci0:0:28:4: Transition from D0 to D3
-[] uhub3: at usbus3, port 1, addr 1 (disconnected)
-ugen3.2:  at usbus3 (disconnected)
-[] uftdi0: at uhub3, port 2, addr 2 (disconnected)
-[] uhub4: at usbus4, port 1, addr 1 (disconnected)
+[] uhub4: at usbus3, port 1, addr 1 (disconnected)
+[] uhub3: at usbus4, port 1, addr 1 (disconnected)
 [] uhub5: at usbus5, port 1, addr 1 (disconnected)
 pci0:21:0:0: Transition from D0 to D2
 [] pci21: failed to set ACPI power state D2 on \134_SB_.PCI0.PCI1.CDBS: 
AE_BAD_PARAMETER
@@ -73,12 +71,12 @@
 kbdc: RESET_AUX ID:
 [] battery0: battery initialization start
 [] ahcich0: AHCI reset: device ready after 100ms
-[] uhub0:  on usbus1
-[] uhub1:  on usbus2
-[] uhub2:  on usbus0
-[] uhub3:  on usbus4
-[] uhub4:  on usbus3
-[] uhub5:  on usbus5
+[] uhub0:  on usbus0
+[] uhub1:  on usbus1
+[] uhub2:  on usbus3
+[] uhub3:  on usbus2
+[] uhub4:  on usbus5
+[] uhub5:  on usbus4
 CPU0: local APIC error 0x40
 [] battery0: battery initialization done, tried 1 times
 (ada0:ahcich0:0:0:0): resume
@@ -92,15 +90,13 @@
intpin=a, irq=16
powerspec 2  supports D0 D3  current D0
 [] cardbus0:  at device 0.0 (no driver attached)
-[] uhub0: 2 ports with 2 removable, self powered
 [] uhub1: 2 ports with 2 removable, self powered
 [] uhub2: 2 ports with 2 removable, self powered
+[] uhub0: 2 ports with 2 removable, self powered
 [] uhub3: 2 ports with 2 removable, self powered
-[] uhub5: 2 ports with 2 removable, self powered
 [] uhub4: 2 ports with 2 removable, self powered
+[] uhub5: 2 ports with 2 removable, self powered
 ugen1.2:  at usbus1
-ugen3.2:  at usbus3
-[] uftdi0:  on usbus3
 ugen2.2:  at usbus2
 ugen1.3:  at usbus1
 [] ubt0:  on usbus1
===
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: Resume on a Thinkpad L512

[Ian Smith]

On Fri, 28 Jun 2013 21:50:06 -0700, matt wrote:

 > Try kldunloading any loaded kernel modules including usb. You may need
 > to compile a more modular kernel.

On 8 (.1 and .2) I only had to leave uhci, ohci and ehci (not usb) out 
of kernel and load / unload those around suspend/resume, but that's no 
longer needed on 9 here.

 > Does suspend/resume work for anyone?

Likely not very exciting news for most, but my '02 Thinkpad T23 reliably 
suspends and resumes since 9.1-R with zero configuration.  Haven't tried 
it yet with X, might need hw.syscons.sc_no_suspend_vtswitch=1 for that 
as 6.x, 7.x and 8.x always required, but that's an old S3 Savage video, 
with working IBM-written ACPI/BIOS.

More modern video chips and drivers seem to be far more problematic, not 
to mention slightly dodgy ACPI code ..

cheers, Ian

 > Matt
 > 
 > On 06/28/13 15:19, Stefan Horomnea wrote:
 > > Yes, I did try, didn't help.
 > > 
 > > 
 > > On Mon, Jun 24, 2013 at 4:30 AM, matt 
 > > wrote:
 > > 
 > >> 
 > >>> which I think are after I manually power-off and power-on the 
 > >>> laptop. If this info helps, Ubuntu is able to suspend/resume 
 > >>> properly. I also did a recent upgrade of BIOS.
 > >>> 
 > >>> Can anyone help me make progress here ?
 > >>> 
 > >>> Thank you, Stefan
 > >>> ___ 
 > >>> freebsd-acpi@freebsd.org mailing list 
 > >>> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To 
 > >>> unsubscribe, send any mail to 
 > >>> "freebsd-acpi-unsubscr...@freebsd.org"
 > >>> 
 > >> 
 > >> Have you tried twiddling the values at hw.pci.do_power_resume
 > >> and hw.pci.do_power_suspend?
 > >> 
 > >> Rarely, this helps.
 > >> 
 > >> Matt
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: USB ports on Lenovo T400 do not work after a suspend/resume

[Ian Smith]

On Wed, 26 Jun 2013 12:53:43 -0700, Adrian Chadd wrote:
 > On 26 June 2013 12:51, Lars Engels  wrote:
 > > On Tue, Jun 25, 2013 at 11:09:20PM -0700, Adrian Chadd wrote:
 > >> [snip] ok, I'll do a boot -v tonight when I get home and log things.
 > >>
 > >> Thanks!
 > >
 > > Please also try a recent CURRENT. I was having the same issues with dead
 > > USB ports on my X200, but IIRC it suddenly worked a few weeks ago.
 > > Unfotunately with the new X.org resuming doesn't work for me, so I can't
 > > try it now.
 > 
 > .. having resume not work with xorg is a big, big red flag.
 > 
 > I'm happy to boot a -head snapshot on this thing, but I can't really
 > migrate to running -head if resume doesn't work. :(

Well if there's a functional change in head that fixes this on Lars' and 
yours, getting it into stable shouldn't be so hard I expect.  However if 
there's a fix (or some Lenovo workaround) for yours on 9 it'd be useful 
to hunt it down, no?  I utterly depend on 100% working resume too.

We don't yet know if this is a bus, ACPI &/or USB issue.  Home yet? :)

cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: USB ports on Lenovo T400 do not work after a suspend/resume

[Ian Smith]

On Tue, 25 Jun 2013 12:07:22 -0700, Adrian Chadd wrote:
 > On 21 June 2013 05:48, Ian Smith  wrote:
 > 
 > > No acpidump output on -stable or -acpi anyway .. likely best as an URL,
 > > if it comes down to ACPI.
 > 
 > Ok, I'll put it online in a sec.

Doubt I know enough to spot anything askance anyway, but others may.

 > > So the fingerprint reader, camera and bluetooth shown in your usbconfig
 > > don't serve as 'USB devices plugged in' in this regard?  Do they work ok
 > > after resume, or not?
 > 
 > they work after resume.

Ok.

 > > No, the above are still on the suspend path, but logged on resume.  I
 > > don't know what CDBS or EXP0,1,3,4 are.  You've left out something like

On reflection I think these are likely the card reader and subsidiaries?

 > > 'pci0:X:Y:0 Transition from D0 to D2' (or D3) before these ones, right?
 > 
 > Nope, nothing is left out. I can boot with -v to get _all_ of the
 > messages, if that'll help.

It might.  I've been running with -v for a while so had forgotten that 
very little other than USB stuff is logged on suspend/resume without.

 > > loading on boot and unload/reload in rc.suspend/resume.  This however
 > > was fixed by 9.1 for me, the first release where suspend/resume works
 > > flawlessly on the T23.  I haven't tried a recent 9-STABLE though.

Time I did so I guess, in case this may be a more recent regression and 
not specific to the T400.  As soon as I can find a USB keyboard I'll see 
how 9.1-RELEASE goes on a friend's T500, which seems generally similar 
(going on their combined service manuals).

 > > Well, the earlier resume issues on UHCI might still not be fixed?  You
 > > could try a kernel without UHCI, with the unload/reload dance ..
 > 
 > I just tried that. unloading/reloading uhci doesn't affect things -
 > the external ports are still powered down after a suspend/resume pass.

Right; more data anyway.  Hopefully some more clues from boot -v output.

cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: USB ports on Lenovo T400 do not work after a suspend/resume

[Ian Smith]

On Thu, 20 Jun 2013 14:19:21 -0700, Adrian Chadd wrote:
 > Hi,
 > 
 > FreeBSD-9 works fine on this Lenovo T400 - except that suspending with
 > no USB devices plugged in result in no ports working after resume.
 > 
 > If I have a device plugged in during suspend - on any port - then all
 > the ports work fine after resume.
 > 
 > I've attached usbconfig and acpidump output.

No acpidump output on -stable or -acpi anyway .. likely best as an URL, 
if it comes down to ACPI.

So the fingerprint reader, camera and bluetooth shown in your usbconfig 
don't serve as 'USB devices plugged in' in this regard?  Do they work ok
after resume, or not?

 > here's what is logged in the kernel buffer during suspend and resume:
 > 
 > 
 > Her'es the suspend:

With all but the USB-related stuff dropped, I assume?

 > Jun 20 14:03:34 lucy acpi: suspend at 20130620 14:03:34
 > Jun 20 14:03:38 lucy kernel: [100031] uhub0: at usbus0, port 1, addr 1
 > (disconnected)
 > Jun 20 14:03:38 lucy kernel: [100036] uhub1: at usbus1, port 1, addr 1
 > (disconnected)
 > Jun 20 14:03:38 lucy kernel: ugen1.2:  at usbus1 
 > (disconnected)
 > Jun 20 14:03:38 lucy kernel: ugen1.3:  at usbus1
 > (disconnected)
 > Jun 20 14:03:38 lucy kernel: [100036] ubt0: at uhub1, port 2, addr 3
 > (disconnected)
 > Jun 20 14:03:47 lucy kernel: [100041] uhub2: at usbus2, port 1, addr 1
 > (disconnected)
 > Jun 20 14:03:47 lucy kernel: [100046] uhub3: at usbus3, port 1, addr 1
 > (disconnected)
 > Jun 20 14:03:47 lucy kernel: ugen3.2:  at usbus3 (disconnected)
 > Jun 20 14:03:47 lucy kernel: [100046] umass0: at uhub3, port 1, addr 2
 > (disconnected)
 > Jun 20 14:03:47 lucy kernel: (da0:umass-sim0:0:0:0): lost device - 0
 > outstanding, 1 refs
 > Jun 20 14:03:47 lucy kernel: (da0:umass-sim0:0:0:0): removing device entry
 > Jun 20 14:03:47 lucy kernel: ugen3.3: 
 > at usbus3 (disconnected)
 > Jun 20 14:03:47 lucy kernel: uhci_interrupt: resume detect

The last message is news to me.

 > Jun 20 14:03:47 lucy kernel: [100052] uhub4: at usbus4, port 1, addr 1
 > (disconnected)
 > Jun 20 14:03:47 lucy kernel: [100057] uhub5: at usbus5, port 1, addr 1
 > (disconnected)
 > Jun 20 14:03:47 lucy kernel: [100062] uhub6: at usbus6, port 1, addr 1
 > (disconnected)
 > Jun 20 14:03:47 lucy kernel: [100067] uhub7: at usbus7, port 1, addr 1
 > (disconnected)
 > 
 > ..and resume: I wonder what these devices are?
 > 
 > Jun 20 14:03:47 lucy kernel: [100095] pci21: failed to set ACPI power
 > state D2 on \_SB_.PCI0.PCI1.CDBS: AE_BAD_PARAMETER
 > Jun 20 14:03:47 lucy kernel: [100095] pci0: failed to set ACPI power
 > state D2 on \_SB_.PCI0.EXP0: AE_BAD_PARAMETER
 > Jun 20 14:03:47 lucy kernel: [100095] pci0: failed to set ACPI power
 > state D2 on \_SB_.PCI0.EXP1: AE_BAD_PARAMETER
 > Jun 20 14:03:47 lucy kernel: [100095] pci0: failed to set ACPI power
 > state D2 on \_SB_.PCI0.EXP3: AE_BAD_PARAMETER
 > Jun 20 14:03:47 lucy kernel: [100095] pci0: failed to set ACPI power
 > state D2 on \_SB_.PCI0.EXP4: AE_BAD_PARAMETER

No, the above are still on the suspend path, but logged on resume.  I 
don't know what CDBS or EXP0,1,3,4 are.  You've left out something like 
'pci0:X:Y:0 Transition from D0 to D2' (or D3) before these ones, right?

On 9(.1-R so far) I always get the same sort of messages for the cardbus 
slots on my T23, eg pci2: failed to set ACPI power state D2 on 
\_SB_.PCI0.PCI1.CBS0: AE_BAD_PARAMETER, also for CBS1.  I've supposed it 
meant there was no D2 setting for these and they seem to resume alright, 
later on: pci2: set ACPI power state D0 on \_SB_.PCI0.PCI1.CBS0 (& CBS1)  
I suppose you'd have lines setting state back to D0 on these, later on?

 > Jun 20 14:03:47 lucy kernel: [100095] acpi0: cleared fixed power button 
 > status
 > Jun 20 14:03:47 lucy kernel: uhci_interrupt: resume detect
 > Jun 20 14:03:47 lucy kernel: wakeup from sleeping state (slept 00:00:06)

I hope 'slept' message is still in 10, I've seen a few listed without, 
and they're very handy if there's any resume delay, as I had up to 8.2 
(plus exactly 60 seconds) unless I unloaded (in particular) UHCI and 
reloaded it on resume, needing a kernel w/out uhci, ohci and ehci, 
loading on boot and unload/reload in rc.suspend/resume.  This however 
was fixed by 9.1 for me, the first release where suspend/resume works 
flawlessly on the T23.  I haven't tried a recent 9-STABLE though.

 > Jun 20 14:03:47 lucy kernel: [100067] uhub0:  class 9/0, rev 2.00/1.00, addr 1> on usbus7
 > Jun 20 14:03:47 lucy kernel: [100046] uhub1:  class 9/0, rev 2.00/1.00, addr 1> on usbus3
 > Jun 20 14:03:47 lucy kernel: [100031] uhub2:  class 9/0, rev 1.00/1.00, addr 1> on usbus0
 > Jun 20 14:03:47 lucy kernel: [100036] uhub3:  class 9/0, rev 1.00/1.00, addr 1> on usbus1
 > Jun 20 14:03:47 lucy kernel: [100057] uhub4:  class 9/0, rev 1.00/1.00, addr 1> on usbus5
 > Jun 20 14:03:47 lucy kernel: [100052] uhub5:  class 9/0, rev 1.00/1.00, addr 1> on usbus4
 > Jun 20 14:03:47 lucy kernel: [100062] uhub6:  class 9/0, rev 1.00/1.00

Re: FreeBSD acpi project

[Ian Smith]

On Tue, 9 Apr 2013 18:42:28 -0700, hiren panchasara wrote:
 > On Apr 9, 2013 6:12 PM, "Eitan Adler"  wrote:
 > >
 > > On 20 February 2013 23:57, Eitan Adler  wrote:
 > > > Is there anyone on this list willing and able to work on migrating the
 > > > old TODO page to the wiki?
 > >
 > > Is there anyone willing to migrate
 > > http://www.freebsd.org/projects/acpi/ to the wiki or update it?
 > >
 > > I would very much like to remove stale pages.
 > 
 > I am still relatively new to acpi but can take a stab at it.
 > 
 > Cheers,
 > Hiren

I think the first thing needs doing is to discover which of the many 
items on the TODO list have in fact been done, or partially done, since 
2004-2006 when Nate was ACPI-meister.  I suspect quite a few of them may 
have been tackled along the way, and where not it's a chance to freshen
the todo/wishlist.  Moving it first to wiki may make doing that easier?

Just a thought, Ian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: what is required to support a new laptop?

[Ian Smith]

On Tue, 29 Jan 2013 12:46:43 -0500, Eitan Adler wrote:
 > On 29 January 2013 12:29, Ian Smith  wrote:
 > > Ah right.  I don't suppose kldload -v shows anything useful about the
 > > problem loading it?  Ah, never mind, it may be obvious .. lightly
 > > skimming your asl.y530.gz, I recalled folks having to patch something
 > > for Lenovo rather than IBM OEMIDs .. hunt, hunt .. ok, here it is:
 > >
 > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/164538
 > 
 > 
 > This is after the install of a patched acpi_ibm
 > [3500 root@gravity /usr/src/sys/modules/acpi ]#kldload -v acpi_ibm
 > Loaded acpi_ibm, id=12

Which looks maybe successful, on the face of it? ..

 > [5507 eitan@gravity (100)% ~ !1!]%sysctl dev.acpi_ibm
 > sysctl: unknown oid 'dev.acpi_ibm'

.. but clearly wasn't.

 > > Hopefully adding the LEN0068 to ibm_ids might allow acpi_ibm to load; if
 > > not more digging may be needed for this model.
 > 
 > I'm not sure what ID this is matching so I don't even know what to
 > look at to try a different one.

Me neither.  My Thinkpad T23 ASL shows this ID at:

Device (HKEY)
{
Name (_HID, EisaId ("IBM0068"))
Method (_STA, 0, NotSerialized)
{
Return (0x0F)
}

but I see no obvious corresponding device or other reference in yours.

 > >  > I mentioned this was a Lenovo IdeaPad Y530
 > >
 > > I'm assuming running 9.x?  I didn't see uname output in this thread.
 > 
 > [5505 eitan@gravity (100)% ~ ]%uname -a
 > FreeBSD gravity 9.1-RELEASE FreeBSD 9.1-RELEASE #3 r244942M: Wed Jan
 > 2 08:00:02 EST 2013 root@gravity:/usr/obj/usr/src/sys/GENERIC
 > amd64
 > 
 > The "M" is a patched AR8161 driver and now a patched acpi_ibm driver.

Sorry, that was my one shot; now I'm out of my depth (and off to sleep)

[ Baptiste, fair enough that patch not making it into 9.1 .. and it 
seems there's more to getting this particular model going anyway. ]

cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: what is required to support a new laptop?

[Ian Smith]

On Tue, 29 Jan 2013 10:59:09 -0500, Eitan Adler wrote:
 > On 29 January 2013 10:50, Ian Smith  wrote:
 > > On Mon, 28 Jan 2013 22:24:29 -0800, Kevin Oberman wrote:
 > >  > On Mon, Jan 28, 2013 at 11:06 AM, Eitan Adler  
 > > wrote:
 > >  > > On 28 January 2013 06:49, Lars Engels  wrote:
 > >  > >> On Fri, Jan 25, 2013 at 08:55:40AM -0500, Eitan Adler wrote:
 > >  > >>> Hi all,
 > >  > >>>
 > >  > >>> I recently purchased a Lenovo Y530 and attempted to use some of the
 > >  > >>> ACPI features (brightness of backlight, etc.)
 > >  > >>>
 > >  > >>> I attempted to load acpi_ibm but devd reported no events (running 
 > > with
 > >  > >>> devd -dD).  What information might be useful to help support this
 > >  > >>> laptop?
 > >  > >>
 > >  > >> Did you set dev.acpi_ibm.0.events=1?
 > >  > >
 > >  > > I don't see this as an option at all.
 > >  >
 > >  > Setting dev.acpi_ibm.0.events=1 still does not cause the brightness
 > >  > functions to generate events. Could the initialmask and or availmask
 > >  > tie into this in some way?
 > >
 > > Have we seen 'sysctl dev.acpi_ibm' from this machine yet?  Maybe clues?
 > > Ideally after kldload acpi_ibm and before any sysctl changes ..
 > 
 > [3462 root@gravity /home/eitan ]#kldload acpi_ibm.ko
 > [3463 root@gravity /home/eitan ]#sysctl dev.acpi_ibm
 > sysctl: unknown oid 'dev.acpi_ibm'

Ah right.  I don't suppose kldload -v shows anything useful about the 
problem loading it?  Ah, never mind, it may be obvious .. lightly 
skimming your asl.y530.gz, I recalled folks having to patch something 
for Lenovo rather than IBM OEMIDs .. hunt, hunt .. ok, here it is:

http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/164538

 > I assume this is either missing a device ID and/or not the right driver at 
 > all.

Hopefully adding the LEN0068 to ibm_ids might allow acpi_ibm to load; if 
not more digging may be needed for this model.

 > I mentioned this was a Lenovo IdeaPad Y530

I'm assuming running 9.x?  I didn't see uname output in this thread.

Strange; according to that PR this was supposed to have been MFC'd last 
November, but didn't make it into 9.1-RELEASE sources.  Committer cc'd.

cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: what is required to support a new laptop?

[Ian Smith]

On Mon, 28 Jan 2013 22:24:29 -0800, Kevin Oberman wrote:
 > On Mon, Jan 28, 2013 at 11:06 AM, Eitan Adler  wrote:
 > > On 28 January 2013 06:49, Lars Engels  wrote:
 > >> On Fri, Jan 25, 2013 at 08:55:40AM -0500, Eitan Adler wrote:
 > >>> Hi all,
 > >>>
 > >>> I recently purchased a Lenovo Y530 and attempted to use some of the
 > >>> ACPI features (brightness of backlight, etc.)
 > >>>
 > >>> I attempted to load acpi_ibm but devd reported no events (running with
 > >>> devd -dD).  What information might be useful to help support this
 > >>> laptop?
 > >>
 > >> Did you set dev.acpi_ibm.0.events=1?
 > >
 > > I don't see this as an option at all.
 > 
 > Setting dev.acpi_ibm.0.events=1 still does not cause the brightness
 > functions to generate events. Could the initialmask and or availmask
 > tie into this in some way?

Have we seen 'sysctl dev.acpi_ibm' from this machine yet?  Maybe clues?
Ideally after kldload acpi_ibm and before any sysctl changes ..

cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"