Date: Mon, 23 Nov 2009 18:27:50 +0000 From: Jerry Marles <jerry@marles.org> To: freebsd-acpi@freebsd.org Subject: Re: HP Pavillion does not power off Message-ID: <1259000870.3465.14.camel@lenny.internal> In-Reply-To: <20091122235353.R65262@sola.nimnet.asn.au> References: <1257798198.3265.12.camel@lenny.internal> <1257805380.3265.21.camel@lenny.internal> <20091115164712.D65262@sola.nimnet.asn.au> <1258394735.3278.34.camel@lenny.internal> <1258714188.3487.38.camel@lenny.internal> <20091122235353.R65262@sola.nimnet.asn.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2009-11-23 at 01:23 +1100, Ian Smith wrote: > On Fri, 20 Nov 2009, Jerry Marles wrote: > > On Mon, 2009-11-16 at 18:05 +0000, Jerry Marles wrote: > > > On Sun, 2009-11-15 at 16:58 +1100, Ian Smith wrote: > > > > On Mon, 9 Nov 2009, Jerry Marles wrote: > > > > > On Mon, 2009-11-09 at 20:23 +0000, Jerry Marles wrote: > > > > > > On Sun, 2009-11-08 at 10:41 +0000, Jerry Marles wrote: > > > > > > Hello, > > > > > > > > > > > > > > I have a HP Pavillion desktop PC model g3001.uk. The problem I have is > > > > > > > that halt -p does not power it off. The light on the power button goes > > > > > > > off but I can hear that it is still running. If I hold down the power > > > > > > > button for a few seconds the power can be heard to go off but then it > > > > > > > boots right back up again. Windows and Linux can power it off > > > > > > > successfully. > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > Jerry Marles > > > > > > > > > > > > > > > > > > > with further investigation I have found that > > > > > > > > > > > > acpiconf -s 5 results in invalid sleep type (5) > > > > > > > > > > > > but acpiconf -s 4 powers it off successfully so if I could just make > > > > > > halt -p do whatever acpiconf -s 4 is doing the problem would be solved. > > > > > > > > > > > > any advice would be much appreciated. > > > > > > > > > > dmesg after boot -v is here http://www.marles.org/acpi/dmesg.txt > > > > > > > > > > sysctl hw.acpi is here http://www.marles.org/acpi/hwacpi.txt > > > > > > > > > > acpidump is here http://www.marles.org/acpi/acpidump.txt > > > > > > > > Seeing noone else has had a go: > > > > > > > > It seems pretty strange that acpiconf -s 4 powers it off properly. > > > > your hwacpi.txt only shows .. > > > > > > > > hw.acpi.supported_sleep_state: S1 S3 S4 S5 > > > > hw.acpi.power_button_state: S5 > > > > hw.acpi.sleep_button_state: S1 > > > > hw.acpi.lid_switch_state: NONE > > > > hw.acpi.standby_state: S1 > > > > hw.acpi.suspend_state: S3 > > > > hw.acpi.sleep_delay: 1 > > > > hw.acpi.s4bios: 0 > > > > 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 > > > > > > > > .. but s4bios is 0 (no BIOS support for S4) and I wonder what's happened > > > > to your hw.acpi.thermal settings also, but .. just a long shot .. > > > > > > > > What happens if you set sysctl hw.acpi.power_button_state=S4 and then > > > > try halt -p ? .. probably better off using 'shutdown -p now' actually. > > > > That does change things in that now if I hold down the power button > > > after halt -p it just goes off rather than booting straight back up > > > again. So that is an improvement. Thanks. > > This is not the right way to do things though .. > > > > Jerry > > > > As Windows, Linux and Solaris can power this machine off would it be > > reasonable to conclude that this is just a feature of FreeBSD and not a > > fault in my ACPI tables? looking at the source code for acpiconf leads > > No I don't think you can assume that; S5 poweroff works for most folks, > and there seems to be a lot of sloppy if not broken AML out there. > > > me to conclude that FreeBSD just does not implement ACPI sleep state S5, > > acpiconf certainly does not. In the handbook 11.16 Using and Debugging > > FreeBSD ACPI says > > > > "This means that we can use acpiconf -s to test S3, S4OS, and S5." > > > > That is clearly wrong. > > It's wrong on two counts, at least on my 7.0-R and your 7.2-R; you're > right that acpiconf doesn't try S5, and AFAIK S4OS does not yet exist on > FreeBSD, so the handbook is, er, a bit optimistic in a couple of places! > > (I haven't checked what's new in 8.0, but think I'd have heard if S4OS > was any further along than an incomplete Google SoC project a while ago) > > To be fair, acpi(4) under S4 does say that S4OS isn't yet supported. > > Here S5 (from the power button) works fine on my Thinkpad T23; properly > running shutdown scripts and synching disks before powering off cleanly. > > And S3 (suspend to RAM) and subsequent resume works fine either by using > acpiconf -s3 or the sleep button, which is Fn-F4 here. > > You didn't mention whether your system works with S3 suspend/resume? > > So just for kicks I tried acpiconf -s4 which hard powered down, without > properly shutting down or synching disks (ie dirty after reboot) which I > guess is a "don't do that then!" though in theory it should check that > S4bios is 1 (or S4OS has arrived!) before diving off into space. > > > I discovered that the motherboard is actually made by Foxconn a > > 945GZ7MC. Googling Foxconn lead me to all sorts of interesting rants > > about Linux ACPI. I also found some useful articles about how to go > > about debugging ACPI tables and wondered if I could contribute > > something that might be useful to others if I could get to the bottom > > of the problem. I guess I would probably just waste a lot of time > > going down that road. > > You'd likely spend a lot of time, can't say if it'd be wasted or not :) > > > I have been using FreeBSD since 2.15 around 1996 so I will be very > > disappointed to have to confine it to VirtualBox until I replace this > > hardware. I also find it hard to believe that I am the only one with > > this problem should I just create a PR? > > You got me rereading the handbook section, after a long time. There are > some things you could try before (or while preparing to) submit a PR, in > the light of scanning your posted AML. Have you tried? (from handbook): > > 11.16.3.5 System Powers Up After Suspend or Shutdown > > "First, try setting hw.acpi.disable_on_poweroff="0" in loader.conf(5). > This keeps ACPI from disabling various events during the shutdown > process. Some systems need this value set to 1 (the default) for the > same reason. This usually fixes the problem of a system powering up > spontaneously after a suspend or poweroff." > > And/or from acpi(4) have you tried? maybe playing with: > > hw.acpi.disable_on_reboot > Disable ACPI during the reboot process. Most systems reboot fine > with ACPI still enabled, but some require exiting to legacy mode > first. Default is 0, leave ACPI enabled. > > hw.acpi.handle_reboot > Use the ACPI Reset Register capability to reboot the system. > Default is 0, use legacy reboot support. Some newer systems > require use of this register, while some only work with legacy > rebooting support. > > Now I know very little about AML, and the folks that do must be on > holidays :) but starting at the end, methods PTS and WAK are clearly > about suspend and wakeup, and method _PTS refers to OSFL () which > returns OSVR according to OS version: if I read it right, 4 for win2k > and NT, 0 for most windows versions, 2 for winME (hee) and - perhaps > usefully - 3 for Linux, and 1 otherwise, with reference to: > > 11.16.5.1 _OS dependencies > > "Some AML assumes the world consists of various Windows versions. You can > tell FreeBSD to claim it is any OS to see if this fixes problems you may > have. An easy way to override this is to set hw.acpi.osname="Windows > 2001" in /boot/loader.conf or other similar strings you find in the ASL." > > OSFL is called in various places as well as in _PTS (put to sleep?) so a > choice may well influence other aspects of ACPI as well as sleep states. > > (If anyone who actually knows what they're talking about is out there, > please chime in; you can see I'm paddling way out of my depth ..) > > cheers, Ian Thanks Ian, Suspend/Resume does not work either but that is not a problem as this is not a laptop so I don't have any need to use it. I have tried all the above suggestions and none of them have helped. I thought I had read somewhere that FreeBSD and Linux are already pretending to be Windows in order to avoid acpi bugs that don't show up in testing because hardware often only gets tested on Windows. Perhaps the handbook and man pages are a little out of date. I tried changing acpiconf.c to make it try to do sleep state S5 the result was. # ./acpiconf -s 5 power off via acpi ioctl not supported acpiconf: request sleep type (5) failed: Device not configured I guess I am looking for a device that is not being detected properly. Perhaps the power button? acpi0: Power Button (fixed) Is it really fixed? Or is this the problem? acpi0: reservation of 0, a0000 (3) failed I am trying to compare what Linux does with FreeBSD but I have not found any other clues yet. Any suggestions on where to look would be very welcome. . Regards Jerry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1259000870.3465.14.camel>