Re: sysctl hw.acpi.acline
Hi, ACPI have tons of optional stuff that isn't required to be present, and apparently acline is one of them. Also, acline is only useful if there are multiple power sources, what if you have a desktop machine always running off a battery, if we defaulted acline=1, then you'd complain that the status is wrong... :) There is no information in the ACPI Manual that the OID's are optional and may not exist in some cases. This is exactly the problem, an undefined and undocumented situation. Maybe its just worth putting a note :-) hw.acpi.acline AC line state (1 means online, 0 means on battery power). OK, how about adding the following line? Note that this OID exists only if there is a ACPI Device ID ACPI0003 in ACPI Namespace of the system. I expect code based on this oid to work on both desktop and laptop with no additional guessing. For me this manual information means that acline oid is always available, and will show 1 in case of desktop where no battery (maybe no UPS as well) is available. There is no information that this oid is optional. For desktop/server a battery power would mean UPS, right, so then I would also expect to see the battery charge status information.. but I understand this would be more complicated than in a laptop thus may not be implemented. Still, I would always expect power source type OID to tell me what is the power source, even if there can be only one. Unfortunately, UPS is not covered by ACPI specification. I think that new OID would be needed in generic place (not under hw.acpi) in order to get the state of power sources. In that case, hw.acpi.battery should be moved to new place too. Thanks ___ 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: [CFT] SMP/i386 suspend/resume
Hi, From: mbsd m...@isgroup.com.ua Subject: Re: [CFT] SMP/i386 suspend/resume Date: Wed, 20 Jun 2012 22:31:44 +0300 Message-ID: 1340220704.2098.8.camel@localhost Hi developers. I want help you with your acpi work. I have thinkpad t61. Could you write a small to do. Step by step, how tests your patches? Which information is important for send. The patches were already merged to CURRENT and RELENG_9. So, please try RELENG_9 and report any problems suspend/resume. I'll try to fix them until 9.1-RELEASE :) Thanks! On Wed, 2012-05-16 at 11:31 +0900, Mitsuru IWASAKI wrote: Hi, First of all, thank you very much for your work! I wanted to do it for very long time but I had no time to actually implement it. :-) Welcome! I also wanted to do this for very long time but I had no time and test machines ;) Recently I got Core Duo (Thinkpad X60) and Core 2 Duo (X61) machines. I have some more ideas on wakecode but I'm not sure whether it is possible for now. I'll propose it when it is ready. I know for sure it is not related to your patches. In fact, we cannot resume most NVIDIA controllers without NVIDIA kernel driver + binary X.org driver + VT switching hack (i.e., Hmm, my knowledge on recent hardware is very poor, so your comments are very helpful to catch up. Thanks. We can improve video initialization on another opportunity. Linux have many video hacks while we have only hw.acpi.reset_video ;) FYI, we don't need hw.acpi.reset_video any more (and it is even harmful). It is done from vesa.ko now. Yeah, I thought that we need INT10 to set video mode again in realmode, but found it can be done in protected mode with x86bios_intr(), great! Anyway, thanks for many things! ___ 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: cpu stopping
Hi, thanks for comments.
As the first thing I must admit that I haven't looked at the patch :-)
Never mind :) What I'm trying to do in the patches is just to unify
amd64/i386 independent part (acpi_wakeup.c) for the code maintenance,
so please let's commit it first, then start re-design the
cpususpend_handler().
But really I don't see why we need to differentiate between stopped and
suspended state as both of them ultimately mean exactly the same thing - CPUs
are spinning on some condition (and they are in a well-defined place and
state).
Yes, amd64/i386 cpususpend_handler() is very similar to cpustop_handler()
actually, some resume related procedures are added for suspend.
My view of how this should work is:
- there can be only one master CPU that controls all other (slave) CPUs
- the master sets entry and exit hooks
Entry hook for suspending might be
ctx_fpusave(suspfpusave[cpu]);
wbinvd();
CPU_SET_ATOMIC(cpu, stopped_cpus);
and for stopping is
/* Indicate that we are stopped */
CPU_SET_ATOMIC(cpu, stopped_cpus);
Correct?
I think stopping hook can be replaced with suspending hook.
Exit hook for suspending is
pmap_init_pat();
load_cr3(susppcbs[cpu]-pcb_cr3);
initializecpu();
PCPU_SET(switchtime, 0);
PCPU_SET(switchticks, ticks);
[snip]
/* Resume MCA and local APIC */
mca_resume();
lapic_setup(0);
For stopping should be
if (cpu == 0 cpustop_restartfunc != NULL) {
cpustop_restartfunc();
cpustop_restartfunc = NULL;
}
- the master signals slaves to enter the stop state
- the slaves execute the enter hook and start spinning on the release
condition
- the master does whatever it wants to do in this special system state
- the master signals the slaves to resume
- the slave exit the spin loop and execute the exit hook
I think it would be possible. However I personally think that
priority of x86/x86/mp_machdep.c is higher and more effective than
merging cpususpend/stop_handler().
Thanks
___
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
preparation for x86/acpica/acpi_wakeup.c
Hi, Well I think we are ready to have x86/acpica/acpi_wakeup.c to share acpi_sleep_machdep() and acpi_wakeup_machdep() between amd64 and i386. http://people.freebsd.org/~iwasaki/acpi/x86-acpi_wakeup-20120602.diff There are no functional changes. The following is major changes. amd64: - Add suspend/resume related members in PCB. - Add suspendctx() in cpu_switch.S. - acpi_switch.S moved into cpu_switch.S as resumectx(). amd64, i386: - Add pcb_flags bit PCB_SUSPENDING to indicate AP is wakeup or not. Please review the patches, suggestions welcome. I'm going to commit this 1 week later. Thanks ___ 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: [CFT] SMP/i386 suspend/resume
Hi, +1. I've really liked to use more than one CPU on my netbook for a while :). A basic suspend test worked on my netbook. I'll have to see about some edgecases I've run into in the past where UP wouldn't resume if the system had been sitting for an extensive period of time, etc. Very cool though -- thanks for your work so far on this ;)! I'm glad to hear this :) I'll try to fix suspend/resume related problems when I have spare time. Thanks! ___ 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: [CFT] SMP/i386 suspend/resume
Hi, First of all, thank you very much for your work! I wanted to do it for very long time but I had no time to actually implement it. :-) Welcome! I also wanted to do this for very long time but I had no time and test machines ;) Recently I got Core Duo (Thinkpad X60) and Core 2 Duo (X61) machines. I have some more ideas on wakecode but I'm not sure whether it is possible for now. I'll propose it when it is ready. I know for sure it is not related to your patches. In fact, we cannot resume most NVIDIA controllers without NVIDIA kernel driver + binary X.org driver + VT switching hack (i.e., Hmm, my knowledge on recent hardware is very poor, so your comments are very helpful to catch up. Thanks. We can improve video initialization on another opportunity. Linux have many video hacks while we have only hw.acpi.reset_video ;) FYI, we don't need hw.acpi.reset_video any more (and it is even harmful). It is done from vesa.ko now. Yeah, I thought that we need INT10 to set video mode again in realmode, but found it can be done in protected mode with x86bios_intr(), great! Anyway, thanks for many things! ___ 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: [CFT] SMP/i386 suspend/resume
Hi, Thanks for your report. From: Peter Jeremy pe...@rulingia.com Subject: Re: [CFT] SMP/i386 suspend/resume Date: Fri, 11 May 2012 21:20:05 +1000 Message-ID: 2012052005.ga87...@server.rulingia.com On 2012-May-11 11:10:19 +0900, Mitsuru IWASAKI iwas...@jp.freebsd.org wrote: I've been working on suspend/resume for SMP/i386 for a week and created patches against CURRENT, RELENG_9 and RELENG_8 available at: Thank you for that. Since I was in the process of upgrading my netbook (Acer Aspire One AOA-110 - Atom N270), I rolled your RELENG_8 patch on top of r235229. Unfortunately, the result hasn't been a complete success. I can suspend to S3 with no problems (though that worked before). The resume is less successful. If X is running, I get a garbage screen. If I suspend at a VTY, the screen comes back correctly but there is no response from keyboard, touchpad or wired network (though it has the correct lights). Let me know if you have any suggestions for debugging. I think graphic driver (or pic?) has some problems on resume and they are out of scope of my patches. HEAD and RELENG_9 have better support on interrupt re-enabling than RELENG_8 I think. Could you try them? And for ps/2 mouse, kernel option PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND would be useful. Thanks -- Peter Jeremy ___ 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: [CFT] SMP/i386 suspend/resume
Hi, Thanks for you report. From: David Wolfskill d...@freebsd.org Subject: Re: [CFT] SMP/i386 suspend/resume Date: Fri, 11 May 2012 13:22:57 + Message-ID: 20120511132257.ga96...@freefall.freebsd.org On Fri, May 11, 2012 at 11:10:19AM +0900, Mitsuru IWASAKI wrote: Hi I've been working on suspend/resume for SMP/i386 for a week and created patches against CURRENT, RELENG_9 and RELENG_8 available at: http://people.freebsd.org/~iwasaki/acpi/i386-SMP-suspend-CURRENT-20120511.diff http://people.freebsd.org/~iwasaki/acpi/i386-SMP-suspend-RELENG_9-20120511.diff http://people.freebsd.org/~iwasaki/acpi/i386-SMP-suspend-RELENG_8-20120511.diff ... I'm sorry to report that while head stable/9 did work for me (see previous notes in this thread), stable/8 did not. Well, suspend seemed to, but on resume, the screen stayed dark and the machine was (as far as I could tell without trying to ping it from another machine) unresponsive. OK, we need some more investigation on RELENG_8 SMP. I think Core 2 Duo can run amd64, would like to confirm this problem can be reproduced only on i386 or not. Could you try same thing on amd64? Thanks This was on the same Dell Precision M4400 as before (Core(TM)2 Duo CPU T9600), running: FreeBSD localhost 8.3-STABLE FreeBSD 8.3-STABLE #382 235262M: Fri May 11 04:45:52 EDT 2012 root@localhost:/common/S1/obj/usr/src/sys/CANARY i386 Peace, david -- David H. Wolfskilld...@freebsd.org There is a use for spam: it helps identify spammers. I have no use for spammers. ___ 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: [CFT] SMP/i386 suspend/resume
Hi, Thanks for your report. From: Gustau Pérez i Querol gpe...@entel.upc.edu Subject: Re: [CFT] SMP/i386 suspend/resume Date: Sun, 13 May 2012 09:57:33 +0200 Message-ID: 4faf696d.3060...@entel.upc.edu Al 11/05/2012 04:10, En/na Mitsuru IWASAKI ha escrit: Hi I've been working on suspend/resume for SMP/i386 for a week and created patches against CURRENT, RELENG_9 and RELENG_8 available at: http://people.freebsd.org/~iwasaki/acpi/i386-SMP-suspend-CURRENT-20120511.diff http://people.freebsd.org/~iwasaki/acpi/i386-SMP-suspend-RELENG_9-20120511.diff http://people.freebsd.org/~iwasaki/acpi/i386-SMP-suspend-RELENG_8-20120511.diff A lot of portion of the patches was ported from amd64. Testing on Thinkpad X60 (Core Duo T2300), so far so good :) I'll commit them against CURRENT hopefully next week. Reporting from an Acer Centrino Duo, running CURRENT r235266. The machine has an nvidia card (Ge7300go). The acpi_video and nvidia modules are there. I did test it a few times with X running (plain twm) and worked just fine. Setting hw.acpi.lid_switch_state=S3 allowed me to use the close-the-lid-to-sleep functionality. The problem comes when I suspend the machine in the console. The machine resumes fine (I can ping and ssh it) but the screen remains black. I set hw.acpi.reset_video to 0 or 1 but no go. If I'm in a console but X is running, after the resume I can CTRL+ALT+F9 and get my video back; then I can return to the console. If I don't have X running, I don't know how to get my console back. I think this is graphic driver problem. nvidia's driver seems to have correct suspend/resume method. http://www.nvidia.com/object/freebsd_archive.html Have you try it? Thanks Thanks ___ 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: [CFT] SMP/i386 suspend/resume
Hi, From: David Wolfskill da...@catwhisker.org Subject: Re: [CFT] SMP/i386 suspend/resume Date: Sun, 13 May 2012 07:03:02 -0700 Message-ID: 20120513140302.gi13...@albert.catwhisker.org On Sun, May 13, 2012 at 10:59:17PM +0900, Mitsuru IWASAKI wrote: OK, we need some more investigation on RELENG_8 SMP. I think Core 2 Duo can run amd64, would like to confirm this problem can be reproduced only on i386 or not. Could you try same thing on amd64? Well, that will require a bit more work -- I'm pretty sure the hardware can run amd64, but I only have i386 inistalled presently. And I'm getting ready to head to the airport to fly back home now. Understood. I don't need to hurry on this. BTW, amd64 Live CD might be useful for this purpose. Thanks! Peace, david -- David H. Wolfskillda...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. ___ 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: [CFT] SMP/i386 suspend/resume
Hi, Reporting from an Acer Centrino Duo, running CURRENT r235266. The machine has an nvidia card (Ge7300go). The acpi_video and nvidia modules are there. I did test it a few times with X running (plain twm) and worked just fine. Setting hw.acpi.lid_switch_state=S3 allowed me to use the close-the-lid-to-sleep functionality. The problem comes when I suspend the machine in the console. The machine resumes fine (I can ping and ssh it) but the screen remains black. I set hw.acpi.reset_video to 0 or 1 but no go. If I'm in a console but X is running, after the resume I can CTRL+ALT+F9 and get my video back; then I can return to the console. If I don't have X running, I don't know how to get my console back. I think this is graphic driver problem. nvidia's driver seems to have correct suspend/resume method. http://www.nvidia.com/object/freebsd_archive.html Have you try it? Yes, it is running the propietary driver. Everything was done with it loaded. Do you want me to try without the nvidia binary driver? Yes, if it doesn't bother you. Hmmm, it doesn't seem related with my SMP/i386 sleep patches. Could you try also Uni-processer kernel (w/o SMP and apic from config file) without my patches? OTOH, IIRC the console only test (without X) without acpi_video lead to freeze. No crash dump. The machine has no serial or fwire ports :( We can improve video initialization on another opportunity. Linux have many video hacks while we have only hw.acpi.reset_video ;) http://www.kernel.org/doc/Documentation/power/video.txt I believe there are some solutions for you in this document, then we can implement them in our source if found. Thanks ___ 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
[CFT] SMP/i386 suspend/resume
Hi I've been working on suspend/resume for SMP/i386 for a week and created patches against CURRENT, RELENG_9 and RELENG_8 available at: http://people.freebsd.org/~iwasaki/acpi/i386-SMP-suspend-CURRENT-20120511.diff http://people.freebsd.org/~iwasaki/acpi/i386-SMP-suspend-RELENG_9-20120511.diff http://people.freebsd.org/~iwasaki/acpi/i386-SMP-suspend-RELENG_8-20120511.diff A lot of portion of the patches was ported from amd64. Testing on Thinkpad X60 (Core Duo T2300), so far so good :) I'll commit them against CURRENT hopefully next week. Thanks and have fun! ___ 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
