Re: ACPI bug submission

2014-04-21 Thread Lars Engels
On Sat, Apr 19, 2014 at 10:15:00PM +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.

To suspend the notebook when the lid is closed, add this to
/etc/sysctl.conf:

hw.acpi.lid_switch_state=S3


pgpuz3wOm1LkA.pgp
Description: PGP signature


Current problem reports assigned to freebsd-acpi@FreeBSD.org

2014-04-21 Thread FreeBSD bugmaster
Note: to view an individual PR, use:
  http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.


S Tracker  Resp.  Description

o kern/187965  acpi   [acpi] [patch] Intel Baytrail-M NUC panics because of 
o kern/187152  acpi   [i386] [acpi] resume from ACPI suspend (s3) sometimes 
o kern/181665  acpi   [acpi] System will not go into S3 state.
o kern/180897  acpi   [acpi] ACPI error with MB p8h67 v.1405
o kern/174766  acpi   [acpi] Random acpi panic
o kern/174504  acpi   [ACPI] Suspend/resume broken on Lenovo x220
o kern/173414  acpi   [acpi] ACPI battery time incorrect
o kern/173408  acpi   [acpi] [regression] ACPI Regression: battery does not 
o kern/171305  acpi   [acpi] acpi_tz0: _CRT value is absurd, ignored (256.0C
o kern/165381  acpi   [cpufreq] powerd(8) eats CPUs for breakfast
o kern/164329  acpi   [acpi] hw.acpi.thermal.tz0.temperature shows strange v
o kern/162859  acpi   [acpi] ACPI battery/acline monitoring partialy working
o kern/161715  acpi   [acpi] Dell E6520 doesn't resume after ACPI suspend
o kern/161713  acpi   [acpi] Suspend on Dell E6520
o kern/160838  acpi   [acpi] ACPI Battery Monitor Non-Functional
o kern/160419  acpi   [acpi_thermal] acpi_thermal kernel thread high CPU usa
o kern/158689  acpi   [acpi] value of sysctl hw.acpi.thermal.polling_rate ne
o kern/154955  acpi   [acpi] Keyboard or ACPI doesn't work on Lenovo S10-3
o kern/152098  acpi   [acpi] Lenovo T61p does not resume
o i386/146715  acpi   [acpi] Suspend works, resume not on a HP Probook 4510s
o kern/145306  acpi   [acpi]: Can't change brightness on HP ProBook 4510s
o i386/143798  acpi   [acpi] shutdown problem with SiS K7S5A
o kern/143420  acpi   [acpi] ACPI issues with Toshiba
o kern/142009  acpi   [acpi] [panic] Panic in AcpiNsGetAttachedObject
o kern/139088  acpi   [acpi] ACPI Exception: AE_AML_INFINITE_LOOP error
o amd64/138210 acpi   [acpi] acer aspire 5536 ACPI problems (S3, brightness,
o i386/136008  acpi   [acpi] Dell Vostro 1310 will not shutdown (Requires us
o kern/132602  acpi   [acpi] ACPI Problem with Intel SS4200: System does not
a i386/122887  acpi   [panic] [atkbdc]  7.0-RELEASE on IBM HS20 panics immed
s kern/112544  acpi   [acpi] [patch] Add High Precision Event Timer Driver f
o kern/73823   acpi   [request] acpi / power-on by timer support

31 problems total.

___
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 bug submission

2014-04-21 Thread 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: ACPI Control Method Battery on acpi0
 acpi_acad0: AC Adapter 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


Fwd: Re: ACPI bug submission

2014-04-21 Thread Matt Grice
Sorry, PEBKAC error, it appears I've been replying off-list.

Please find below my response. It appears that the latest problem is something 
to do with X as it crashes out when trying to return to the console when 
pressing Ctrl-Alt-F1 too.

Thanks

Matt Grice

div Original message /divdivFrom: Matt Grice 
m...@atarian.co.uk /divdivDate:21/04/2014  14:51  (GMT+00:00) 
/divdivTo: Kevin Oberman rkober...@gmail.com /divdivSubject: Re: ACPI 
bug submission /divdiv
/divThanks for the help Kevin, I'm quite new to FreeBSD. I noticed the sysctl 
for lid_switch wasn't set, but I just thought it was for information only. man 
8 sysctl is my friend.

Sleep now works, it just won't wake up. I've debugged this kind of thing before 
with Linux so I'll plough on from here, I expect I'll just have to work out 
which systems are shut down at sleep and which ones are restarted afterwards. 
I've had issues with sound modules doing this kind of thing in the past. I 
think a serial console might be in order.

The battery thing is really odd as it's a virtually new battery, and I wasn't 
aware there were issues before the install. However, the thing won't charge 
when it's switched off, which screams HARDWARE! It's probably one of those 
black swan situations.

Thanks again for taking the time out to help. It's really appreciated.


Matt Grice



On 20/04/2014 16:12, Kevin Oberman wrote:
On Sun, Apr 20, 2014 at 2:39 AM, Matt Grice m...@atarian.co.uk wrote:
Could you provide the output of:
sysctl hw.acpi

[root@Raptor] /usr/ports/comms/wspr# sysctl hw.acpi
hw.acpi.supported_sleep_state: S3 S4 S5
S3 is suspend to RAM, S4 is suspend to disk, and S5 is shutdown
hw.acpi.power_button_state: S5
Power button will do a system shutfown and power off 
hw.acpi.sleep_button_state: S3
Sleep button will suspend to RAM. Little power use and supported by BIOS with 
minimal OS support. Works on FreeBSD
hw.acpi.lid_switch_state: NONE
Closing the lid does nothing in BIOS. Display backlight my turn off, but that's 
it. 
hw.acpi.standby_state: NONE
If the power management system wants to go to a standby mode, nothing happens. 
hw.acpi.suspend_state: S3
If a suspend is requested by the OS, suspend to RAM is used 
hw.acpi.sleep_delay: 1
Delay 1 second for OS to do preparation for suspend to RAM 
hw.acpi.s4bios: 0
BIOS does not support suspend to disk. OS support is required. FreeBSD does not 
have this support.
hw.acpi.verbose: 1
hw.acpi.disable_on_reboot: 0
hw.acpi.handle_reboot: 0
hw.acpi.reset_video: 0
hw.acpi.cpu.cx_lowest: C1
Power saving Cx states are NOT enabled. 
hw.acpi.thermal.min_runtime: 0
hw.acpi.thermal.polling_rate: 10
ACPI will update temperature information every 10 seconds 
hw.acpi.thermal.user_override: 0
hw.acpi.thermal.tz0.temperature: 39.0C
Thermal zone 0 is 39C. This is usually the CPU. 39C is VERY cool. 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!
hw.acpi.thermal.tz0.thermal_flags: 0
hw.acpi.thermal.tz0._PSV: 95.0C
At 95C, turn the cooling (fans) to maximum.
hw.acpi.thermal.tz0._HOT: -1
hw.acpi.thermal.tz0._CRT: 98.0C
At 98C, throttlethe CPU to reduce temperature 
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.
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.
hw.acpi.thermal.tz1._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1
hw.acpi.thermal.tz1._TC1: -1
hw.acpi.thermal.tz1._TC2: -1
hw.acpi.thermal.tz1._TSP: -1
hw.acpi.battery.life: 0
hw.acpi.battery.time: -1
hw.acpi.battery.state: 4
hw.acpi.battery.units: 1
hw.acpi.battery.info_expire: 5
hw.acpi.acline: 1
hw.acpi.video.crt0.active: 0
hw.acpi.video.lcd0.active: 1
hw.acpi.video.lcd0.brightness: 100
hw.acpi.video.lcd0.fullpower: 100
hw.acpi.video.lcd0.economy: 60
hw.acpi.video.lcd0.levels: 100 60 10 20 30 40 50 60 70 80 90 100
 
If you want the system to suspend when the lid closes, sysctl 
hw.acpi.lid_switch_state=S3.




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. 
Technology: secondary (rechargeable)
Design voltage: 11100 mV
Capacity (warn):185 mAh
Capacity (low): 129 mAh
Low/warn granularity:   56 mAh
Warn/full granularity:  3572 

Re: kern/187965: [acpi] [patch] Intel Baytrail-M NUC panics because of buggy ACPI table

2014-04-21 Thread jhb
Synopsis: [acpi] [patch] Intel Baytrail-M NUC panics because of buggy ACPI table

State-Changed-From-To: open-patched
State-Changed-By: jhb
State-Changed-When: Mon Apr 21 18:28:02 UTC 2014
State-Changed-Why: 
This was fixed in HEAD in r263795 and r263859.


Responsible-Changed-From-To: freebsd-acpi-takawata
Responsible-Changed-By: jhb
Responsible-Changed-When: Mon Apr 21 18:28:02 UTC 2014
Responsible-Changed-Why: 
This was fixed in HEAD in r263795 and r263859.

http://www.freebsd.org/cgi/query-pr.cgi?pr=187965
___
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