Re: ACPI programming under FreeBSD?
Hi, I am interested in retrieving power statistics type of information from a system running FreeBSD. I am interested in information such as: power consumed, temperature, percentage of battery available, etc. Is it possible to do this with ACPI, and if so, are there any examples of how to gather this information at the user-level? Yes, you can get them via sysctl, like % sysctl hw.acpi hw.acpi.power_button_state: S5 hw.acpi.sleep_button_state: S4 hw.acpi.lid_switch_state: NONE hw.acpi.standby_state: S4 hw.acpi.suspend_state: S4 hw.acpi.sleep_delay: 0 hw.acpi.s4bios: 1 hw.acpi.verbose: 0 hw.acpi.cpu.max_speed: 8 hw.acpi.cpu.current_speed: 8 hw.acpi.cpu.performance_speed: 8 hw.acpi.cpu.economy_speed: 8 hw.acpi.thermal.min_runtime: 300 hw.acpi.thermal.polling_rate: 30 hw.acpi.thermal.tz0.temperature: 3262 hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: -1 hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 3652 hw.acpi.thermal.tz0._ACx: 3372 -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.acline: 0 hw.acpi.battery.life: 99 hw.acpi.battery.time: 357 hw.acpi.battery.state: 1 hw.acpi.battery.units: 1 hw.acpi.battery.info_expire: 30 I think my fivamon (Monitor for ACPI and Crusoe Longrun info.) will be an example of application development. It's diff against wmmon Dock. http://people.freebsd.org/~iwasaki/acpi/fivamon-20011124.diff http://people.freebsd.org/~iwasaki/acpi/fivamon-1.gif http://people.freebsd.org/~iwasaki/acpi/fivamon-2.gif http://people.freebsd.org/~iwasaki/acpi/fivamon-3.gif How stable is ACPI support in -STABLE and -CURRENT for this kind of work? Currently ACPI support is available in only -CURRENT. But John Baldwin ([EMAIL PROTECTED]) has patches for -STABLE. The stability is depending on what machine you have, I think. If you have the same machine with ACPI developer, the machine is supported very well :-) Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: CFR: Generalized power-management interface
I've update the patch based on some comments so far and added wmpm (actually ACPI support for wmapm which is utility for WindowMaker) ports files as a example. http://people.freebsd.org/~iwasaki/acpi/power-20010113.tar.gz What about treating it as a part of ioctl in existing device, then make symbolic link to a generalzed name,instead of consuming new major number? Does `existing device' mean APM or ACPI? We don't know which power management system is enabled on the actual system, so it's impossible. We need one mandatory device for PM to be generalized. I think the opposite way is more reasonable. Or if your concern is shortage of major number, we could expand it in proper way. Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: CFR: Generalized power-management interface
Hi, If we're going to talk about 'health' for a machine and it's components, it should tie in with the SES/SAF-TE driver (for SCSI/FibreChannel). Yes, but my understanding on SES/SAF-TE is very poor unfortunately :-) I think number of hackers who can cover all areas with enough knowledge and experience is quite limited, so I prefer dividing it into sub-areas sharing upper level framework to make things simple. Any volunteers for the design? something like; health + power + apm | | | + acpi | + thermal --+ acpi | | : : Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: CFR: Generalized power-management interface
We don't know which power management system is enabled on the actual system, so it's impossible. We need one mandatory device for PM to be generalized. I think the opposite way is more reasonable. Why? Is it bad to check whether the device is available or not in rc? Ah, you mean we support the same ioctl interface directly in both apm and acpi for power management without passthru requests via generalized device, right? If ioctl is only the matter, I thinkg yes. But having own device file is still advantages when we start considering other cdevsw stuff such as open/close/read/write/poll/etc. I think the way you suggested may prevent generalized device interface improving and make existing-code to be more complicated. Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: CFR: Generalized power-management interface
Hi, I've update the patch based on some comments so far and added wmpm (actually ACPI support for wmapm which is utility for WindowMaker) ports files as a example. http://people.freebsd.org/~iwasaki/acpi/power-20010113.tar.gz http://people.freebsd.org/~iwasaki/acpi/wmpm-20010113.tar.gz Note that ioctl number for power device have been changed, so rebuilding your kernel and recompiling lib/libpower/ and usr.sbin/power/ are needed. Added API is; u_intpower_get_pm_type(void); I'll get device major number for /dev/power and commit them within a few days if no objection. Thanks I've created new common framework on generalized power-management interface for userland utilities. http://people.freebsd.org/~iwasaki/acpi/power-20001229.tar.gz This provides some PM APIs to APM applications, such as wmapm, so that these applications can be ported smoothly to use ACPI (power management portion). Currently following APIs are implemented; intpower_get_syspm_info(struct power_syspm_info *); intpower_get_batt_info(u_int, struct power_batt_info *); intpower_standby(void); intpower_suspend(void); intpower_hibernate(void); And PM event notification mechanism is suggested to be implemented so far. Sample application is included in usr.sbin/power/ which is very similar to apm(8) but supports ACPI as well. usr.sbin/acpi/acpibatt/ is for displaying acpi_cmbat (ACPI Control Method Battery), can be used to verify that generalized power-management interface is working correctly. Note that many ACPI BIOS give us unknown battery remaining time when ac-line is plugged in. MIB 'hw.battery.full_charge_time' can be used to specify the full charged remaining time of batteries in minutes, like sysctl -w hw.battery.full_charge_time=60,60 for multiple number of batteries, or sysctl -w hw.battery.full_charge_time=120 for a battery installed. To test them, /dev/power is required as a device control file. % ls -l /dev/power crw-r--r-- 1 root wheel 210, 0 12/19 04:51 /dev/power I'll commit them at sometime early in coming century. Any comments would be appreciated. Thanks! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: CFR: Generalized power-management interface
Hi, I'll get device major number for /dev/power and commit them within a few days if no objection. One thing that I was talking about with Mike Smith is that perhaps instead of having a /dev/power just for power management stuff we should be a bit more generic and have a /dev/health used for anything related to the machine's "health"? This could include power management, thermal zones, etc. BTW, the I'm not sure if /dev/health is better but I think having common API for the machine's health is good thing. How about having /dev/power, /dev/thermal or whatever related with machine's health as abstracted layers, and creating API libraries for each subsystems like libpower, then providing libhealth as full-set API for the applications? battery status doesn't work on my laptop unfortunately, but that is because I have to have the Super IO (and thus all GPIO) disabled to get ACPI to boot. :( Is that related with embedded controller too? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
CFR: Generalized power-management interface
Hi, I've created new common framework on generalized power-management interface for userland utilities. http://people.freebsd.org/~iwasaki/acpi/power-20001229.tar.gz This provides some PM APIs to APM applications, such as wmapm, so that these applications can be ported smoothly to use ACPI (power management portion). Currently following APIs are implemented; int power_get_syspm_info(struct power_syspm_info *); int power_get_batt_info(u_int, struct power_batt_info *); int power_standby(void); int power_suspend(void); int power_hibernate(void); And PM event notification mechanism is suggested to be implemented so far. Sample application is included in usr.sbin/power/ which is very similar to apm(8) but supports ACPI as well. usr.sbin/acpi/acpibatt/ is for displaying acpi_cmbat (ACPI Control Method Battery), can be used to verify that generalized power-management interface is working correctly. Note that many ACPI BIOS give us unknown battery remaining time when ac-line is plugged in. MIB 'hw.battery.full_charge_time' can be used to specify the full charged remaining time of batteries in minutes, like sysctl -w hw.battery.full_charge_time=60,60 for multiple number of batteries, or sysctl -w hw.battery.full_charge_time=120 for a battery installed. To test them, /dev/power is required as a device control file. % ls -l /dev/power crw-r--r-- 1 root wheel 210, 0 12/19 04:51 /dev/power I'll commit them at sometime early in coming century. Any comments would be appreciated. Thanks! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Merging ACPI related code is on the way.
I have committed orthognal part of ACPI driver. The rest part will be committed after a few days. I put the part at URL:http://people.freebsd.org/~takawata/sysdiff. This can be applied for HEAD. Please test and report about it if there is serious problem,such as breaking build. It seems OK for me. BTW, I've just added new file in CVS; sys/dev/acpi/acpi_powerres.c. You need to have the following line in sys/conf/files. dev/acpi/acpi_powerres.coptionalacpi Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ACPI project progress report (final?)
It is related with quite wide areas, not only for power management. # I'm interested in power management part personally for the first step # though. Do I understand correctly that things like monitoring cooling fans etc is also possible? I guess the people running (lots of) servers will be interested in those features too. Yes, of course :-) ACPI covers the thermal management also. I could imagine that there are quite big needs in this area for server computing. I think this is what you are interested in, from ACPI 1.0b spec. contents; 12. THERMAL MANAGEMENT 12.1 Thermal Control 12.1.1 Active, Passive, and Critical Policies 12.1.2 Dynamically Changing Cooling Temperatures 12.1.3 Hardware Thermal Events 12.1.4 Active Cooling Strength 12.1.5 Passive Cooling Equation 12.1.6 Critical Shutdown You can get ACPI spec. documents from http://www.teleport.com/~acpi/spec.htm # I haven't checked ACPI spec 2.0 yet though :-) Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
ACPI project progress report (final?)
Hi, here is the latest (and maybe final?) report on our ACPI project's
progress.
We are ready now to merge our work on ACPI into main source tree!
Our prototype development is going to finish. AML interpreter
development is almost completed, region access facility (SystemMemory,
SystemIO and PCI_Config) is almost completed, device major number is
officialy assigned, source code cleanup is finished. Also some of us
are committers of freefall to work on it.
Of cause we still have a lot of things should be done to complete this
project, but we think it's good enough as a prototype and want to work
together with you, many people who are interested in ACPI
implementation. Folks, there are a lot of exciting and cool things,
like Processor and Device Power State Control, Thermal Management,
Replacement PnP system, OS initiated hibernation and many :-)
I think now is the time to start open and development, not only in Japan,
for FreeBSD ACPI support!
At USENIX 2000, I luckily had a discussion with Mike Smith, John Baldwin,
Doug Rabson, Peter Wemm and some people. I very much appreciate very useful
suggestions from them (especially Mike, thanks a lot).
Once merge happened, we will stop maintaining our ACPI CVS repository
except for DSDT/ASL data collection. Discussions in Japanese
mailing-list will be continued but it will be just for some people who
want to get information in Japanese. Most of Japanese ACPI developers
will work based on CURRENT.
Recently we imported CURRENT sys tree as of 2000/8/4 into our ACPI
repository and prepared diffs against CURREN at;
http://people.FreeBSD.org/~iwasaki/acpi/acpi-sys-2804.diff.gz
and snapshot of userland tools is available at;
http://people.FreeBSD.org/~iwasaki/acpi/acpi-usr.sbin-2804.tar.gz
Please get and taste them, we are going to merge them into CURRENT
sometime around end of this month.
How to use:
# cd /usr/src
# gzip -dc /somewhere/acpi-sys-2804.diff.gz | patch
# tar xzpvf /somewhere/acpi-usr.sbin-2804.tar.gz
# cp sys/sys/acpi.h /usr/include/sys/
# cd /usr/src/usr.sbin/acpi
# make obj depend all install
# mknod /dev/acpi c 152 0
# cd /usr/src/sys/i386/conf
# echo 'device acpi' MYKERNEL
# echo 'options ACPI_DEBUG' MYKERNEL
# echo 'options AML_DEBUG' MYKERNEL
# config -r MYKERNEL
# cd ../../compile/MYKERNEL
# make depend; make all install
# shutdown -r now
(reboot...)
# acpiconf -s 5
(sleeping state 5, shutdown power off)
or press Power button to shutdown if supported.
Directory tour:
- kernel space side
src/sys/i386/i386/machdep.c
getmemsize() try to get ACPI related memory range from SMAP.
src/sys/i386/i386/bios.c
bios32_init() try to find RSD PTR signature (probe ACPI BIOS).
src/sys/sys/acpi.h
The acpi related structs and function declaration. This need
to be installed in /usr/include/sys/ to compile acpi userland
tools.
src/sys/dev/acpi/acpi.c
acpi device driver.
src/sys/dev/acpi/aml/
AML interpreter code.
aml_parse.c was originally developed based on dfr's AML
disassembler program. These files can be compiled and work in
both of kernel/userland side.
src/sys/i386/conf/NOTES
sample configration and possible options for acpi driver.
src/sys/i386/i386/acpi_machdep.c
i386 dependent implementations to be added here.
src/sys/i386/include/acpica_osd.h
ACPICA interface implementation (part of OS-dependent code).
src/sys/conf/{files|options}
src/sys/conf/files.i386
file and option configuration for ACPI.
- userland side
src/usr.sbin/acpi/acpiconf
enabler/disabler and sleeping state transition ioctl
requests generator.
src/usr.sbin/acpi/acpidump
ASL and AML dump tool (modified dfr's tool a bit).
src/usr.sbin/acpi/amldb
The debugger for AML interpreter.
- device file
/dev/acpi
major/minor should be 152, 0 (officially assigned).
You need to create this file like
# mknod /dev/acpi c 152 0
to use userland tools.
ACPI device driver:
This driver has
- ACPI memory range management
- The pmap stuff for ACPI
- ACPI registers manipulation stuff
- ACPI tables handlers *
- System sleeping state stuff
- AML interpreter callers for special control methods; _PTS and _WAK *
- Event handler (power/sleep button for now)
- Interrupt handler (for general purpose events maybe incomplete)
- Event enabler (PM1 only, GPE not yet)
- Device file manipulation stuff
- The new-bus dependent code
*: acpi_handle_dsdt() and acpi_execute_{pts|wak}() invoke AML interpreter.
AML interpreter source files:
- aml_amlmem.c memory manager instance for AML
Re: sources for null device!!!
Hi, pmk where can i find the sources corresponding to /dev/null?? /sys/dev/nulldev/nulldev.c in 5.0-CURRENT/RELENG_4, /sys/i386/i386/mem.c or /sys/alpha/alpha/mem.c in RELENG_3 IIRC. Good luck. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ACPI project progress report
Hi, From: Bjoern Fischer [EMAIL PROTECTED] Subject: Re: ACPI project progress report Date: Mon, 19 Jun 2000 07:01:44 +0200 Message-ID: [EMAIL PROTECTED] Just a moment. You talk about doing a `Save-to-Disk' (incl. system halt), turning power off, maybe adding some hardware or moving the machine to another location, then switching on again, restoring the system context, and the machine will proceed as if nothing had happened, do you? Yes, exactly. My rough idea is like this; - do preparation for sleeping state transition for each devices and _PTS (prepare to sleep) control method. - stop all of processes, other sub-system (eg filesystem, memory...) and write contents of memory to dedicated swap partition for "Save-to-Disk" and save system context. - turning power off by manipulating ACPI registers (or just halt the system and user will turning power off). - upon turning power on, BIOS built ACPI tables again if hardware configuration changed during sleeping. Any important device (eg disk controller) configuration changes will cause the restoring system context to fail. - after POST, BIOS passes control to the boot loader in normal case. - load will check whether S4 transition occurred, then restore system context and memory from swap partition. - do _WAK (wakeup) control method, wakeup processes for each devices and re-enable them. Maybe I'm wrong because of lack of my understanding on crush dump and loader. Please help us :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ACPI project progress report
imp In message [EMAIL PROTECTED] Mitsuru IWASAKI writes: imp : Hi, here is the latest report on our ACPI project's progress. imp imp As I told you on the Train in Tokyo: Cool! Way Cool! ACPI should imp enable us to properly put the chipsets in laptops to sleep and then imp wake them up again. Right now pccard insert/removal can be missed imp when you put a laptop to sleep... Yes, many of today's laptop BIOS are expecting that OS shouldn handle this kind of things by executing the AML. Good news, recently I wrote accessing ioport stuff (roughly :-) and experimental code for executing _PTS _WAK method in kernel space. On P2B based system, it seems working fine :-) Next step is implement accessing other bus spaces, physical memory will be the target (and PCI config, SMBus...). Can anybody help us on this? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
ACPI project progress report
Hi, here is the latest report on our ACPI project's progress. Current status: The aml interpreter development is going on and we've ported it to kernel simultaneously. Now that we can build ACPI namespace and search any named objects from there in kernel space. The aml interpreter code can be compiled and executed in both userland (using I/O simulator) and kernel space so that we can continue development even we ported the code in kernel. Next step would be implementation of the accessing facility for system memory, ioport and so on, then simple method (eg _PTS with 1 or 5 and _WAK) must be able to executed soon. This is our goal of prototype development. TODO: - combine sys/isa/pnpparse.c with interpreter. - support S2, S3, S4 (hibernation) sleeping transition. S4 sleep require some hack in boot loader needs help. - implement serialization and synchronization mechanism. - migrate to Intel ACPICA? (but that's too large to understand. I'm not sure whether this has licencing issue or welcome to import it into our repository in terms of licencing policy... ours? Yes, it's BSD Licence. No problem at all :-) - and many. Obtaining source code: To get ACPI project repository, please try CVSup with; --- *default host=cvsup.jp.FreeBSD.org *default base=/usr *default prefix=/home/cvs *default release=cvs *default delete use-rel-suffix jp-acpi --- cvsweb is also available at; URL:http://www.jp.freebsd.org/cgi/cvsweb.cgi/ACPI/?cvsroot=freebsd-jp. usr.sbin/acpi/amldb would be a good toy for you :-) % ./amldb ../../../util/takawata/acpi/3110CT.dsdt.dat Loading ../../../util/takawata/acpi/3110CT.dsdt.dat...done AMLr _PTS Method: Arg 1 From 0x280f36ce To 0x280f3775 Enter argument values (ex. number 1 / string foo). 'q' to quit. Arg0 ? n 1 Running _PTS. AMLh s Single step n Step program c Continue program being debugged q Quit method execution t Show local name space tree and variables i Toggle region input prompt o Toggle region output prompt m Show memory management statistics r Run specified method f Find named objects from namespace. h Show this messsage AML BTW, I (iwasaki) am going to USENIX 6/21 - 23, I'll happy to give a demonstration on ACPI device driver and AML interpreter debugger if anybody ask me to do it. Here's the dmesg output from kernel with AML interpreter on TOSHIBA PORTEGE 3110CT. It's not fake :-) There are 1735 times memory allocation here, but we couldn't find a lowering of performance because of own memory management system. 95% of memory allocation is covered by pre-allocated memory storage which is compiled in the interpreter module. Thanks! ACPI: Found ACPI BIOS data at 0xc00f0170 (TOSHIB, RSDT@3fe) acpi0: TOSHIB on motherboard acpi0: ADDR RANGE 3fe 1 (mapped 0xc5774000) acpi0: ADDR RANGE 100b6e00 200 (mapped 0xc5784e00) acpi0: RSDT have 1 entries acpi0: RSDT entry0 FACP acpi0: FACP found acpi0: DSDT found Size=17865 bytes \\ IRQS Method: Arg 2 From 0xc57783bf To 0xc5778691 IRQR Method: Arg 1 From 0xc57781de To 0xc57783b7 CRSL Method: Arg 1 From 0xc5778165 To 0xc57781d6 PRSL Method: Arg 1 From 0xc57780d3 To 0xc577815d STAL Method: Arg 1 From 0xc577808c To 0xc57780cb PSC_ Method: Arg 1 From 0xc5778054 To 0xc5778084 WPSX Method: Arg 4 From 0xc5777fd7 To 0xc577804d PS3_ Method: Arg 1 From 0xc5777f70 To 0xc5777fcf PS0_ Method: Arg 1 From 0xc5777f09 To 0xc5777f68 DIS_ Method: Arg 1 From 0xc5777e7c To 0xc5777f01 SRS_ Method: Arg 2 From 0xc5777dde To 0xc5777e74 PRS_ Method: Arg 1 From 0xc5777d07 To 0xc5777dd6 CRS_ Method: Arg 1 From 0xc5777c30 To 0xc5777cff STA_ Method: Arg 1 From 0xc5777b93 To 0xc5777c28 SMBR Method: Arg 5 From 0xc5777b2e To 0xc5777b8b TRAP Method: Arg 1 From 0xc5777b1d To 0xc5777b26 _WAK Method: Arg 1 From 0xc5777869 To 0xc5777b16 _PTS Method: Arg 1 From 0xc5ba To 0xc5777861 _GPE _L00 Method: Arg 0 From 0xc598 To 0xc5b2 _L1E Method: Arg 8 From 0xc581 To 0xc591 _L19 Method: Arg 8 From 0xc52f To 0xc57a _L18 Method: Arg 8 From 0xc577765b To 0xc527 _L0C Method: Arg 8 From 0xc5777608 To 0xc5777653 _L0B Method: Arg 8 From 0xc5777188 To 0xc5777600 _L08 Method: Arg 8 From 0xc5777139 To 0xc5777180 _TZ_ THRM Thermalzone _TSP Num:0x708 _TC2 Num:0x2 _TC1 Num:0x9 _CRT Method: Arg 0 From 0xc5777103 To 0xc5777113 _PSL Package:elements 1 _PSV Method: Arg 0 From 0xc57770da To 0xc57770ea _AL1 Package:elements 1 _AL0 Package:elements 1 _AC1 Method: Arg 0 From 0xc577709f To 0xc57770af _AC0 Method: Arg 0 From 0xc5777088 To 0xc5777098 _TMP Method: Arg 0 From 0xc5777023 To 0xc5777081 FAN_ Device _PR0 Package:elements 1 _HID Num:0xb0cd041 PFAN
Re: ACPI project progress report
Hi, "Daniel C. Sobral" wrote: Mitsuru IWASAKI wrote: - support S2, S3, S4 (hibernation) sleeping transition. S4 sleep require some hack in boot loader needs help. I thought hibernation was entirely controlled by kernel? What do you ^^ Err, BIOS. need? Yes, we need to consider both. In ACPI spec. 1.0b 9.1.4 S4 Sleeping State, this is described that S4 supports two entry mechanisms: OS initiated and BIOS initiated. From: Intel, Microsoft, Toshiba Subject: Advanced Configuration and Power Interface Specification 1.0b Date: Tue, 2 Feb 1999 07:55:24 +0900 In the OS-initiated S4 sleeping state, the OS is responsible for saving all system context. Before entering the S4 state, the OS will save context of all memory. Upon awakening, the OS will then restore the system context. When the OS re-enumerates buses coming out of the S4 sleeping state, it will discover any devices that have come and gone, and configure devices as they are turned on. I think OS-initiated S4 (hibernation) in FreeBSD has enough advantages because we can do `Save-to-Disk' anywhere even on non-laptop machines which BIOS doesn't support hibernation. FreeBSD supports crash dump facility here, so I'm expecting that `Save-to-Disk' by kernel would not be so difficult. We might need dedicated swap partition for OS-initiated S4 because used swap areas need to be protected for the system oprerations after awakening. The boot loader is the best place for restoring the system context in FreeBSD I think. Unfortunately I don't have enough knowledge on crash dump and boot loader to implement OS-initiated S4 transition (actually, this is not related with ACPI at all). I love to see someone say `hey! I'll take this one!' :-) Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Call for review: new pccard.conf scheme
Hi,
I'm working on new pccard.conf scheme, /etc/defaults/pccard.conf and
/etc/pccard.conf in the same manner as rc.conf.
Attached patch for pccardd(8) contains:
1. improved `include' keyword function for error handling.
2. changed available io, irq, mem pool so that they can be overridden.
3. default config file as /etc/defaults/pccard.conf instead of
/etc/pccard.conf.
Currently, /etc/pccard.conf.sample is provied as sample configuration
file for pccard, most of users modify this file based on his/her
laptop environment. However, on every upgrading, they have to merge
new sample config into own config file.
The pccard configuration can be separated into two parts; Default
pccard configuration database for general purpose, and user specific
configuration (further, available resource infomation and additional
pccard entries). By separating the file into two
(/etc/defaults/pccard.conf as default, /etc/pccard.conf as user
config), upgrading pccard.conf would be much easier.
Yes, just update /etc/defaults/pccard.conf!
To test this stuff, apply the patch and compile install
src/usr.sbin/pccard/pccardd, and;
# cp src/etc/pccard.conf.sample /etc/defaults/pccard.conf
# echo include /etc/pccard.conf /etc/defaults/pccard.conf
to make sample config to default config file.
Then, create your own pccard config, you can change config entries
here from default;
# vi /etc/pccard.conf # change or add or delete contents
or you can also do
# rm /etc/pccard.conf
Comments?
Index: file.c
===
RCS file: /home/ncvs/src/usr.sbin/pccard/pccardd/file.c,v
retrieving revision 1.24
diff -u -r1.24 file.c
--- file.c 2000/01/26 17:54:00 1.24
+++ file.c 2000/03/27 07:29:01
@@ -37,7 +37,12 @@
static FILE *in;
static int includes = 0;
-static FILE *files[MAXINCLUDES] = {NULL, };
+static struct {
+ FILE*filep;
+ char*filename;
+ int lineno;
+} configfiles[MAXINCLUDES] = {{NULL, NULL, 0}};
+
static int pushc, pusht;
static int lineno;
static char *filename;
@@ -114,12 +119,15 @@
die("readfile");
}
for (i = 0; i MAXINCLUDES; i++) {
- if (files[i]) {
- fclose(files[i]);
- files[i] = NULL;
+ if (configfiles[i].filep) {
+ fclose(configfiles[i].filep);
+ configfiles[i].filep = NULL;
}
}
- files[includes = 0] = in;
+ includes = 0;
+ configfiles[includes].filep = in;
+ filename = configfiles[includes].filename = name;
+
parsefile();
for (cp = cards; cp; cp = cp-next) {
if (cp-config == 0)
@@ -132,50 +140,54 @@
parsefile(void)
{
int i;
- int irq_init = 0;
- int io_init = 0;
- struct allocblk *bp;
+ struct allocblk *bp, *next;
char*incl;
pushc = 0;
lineno = 1;
- for (i = 0; i 16 ; i++)
- if (pool_irq[i]) {
- irq_init = 1;
- break;
- }
for (;;)
switch (keyword(next_tok())) {
case KWD_EOF:
/* EOF */
return;
case KWD_IO:
- /* reserved I/O blocks */
+ /* override reserved I/O blocks */
+ bzero(io_avail, sizeof(io_avail));
+ for (bp = pool_ioblks; bp; bp = next) {
+ next = bp-next;
+ free(bp);
+ }
+ pool_ioblks = NULL;
+
while ((bp = ioblk_tok(0)) != 0) {
- if (!io_init) {
- if (bp-size == 0 || bp-addr == 0) {
- free(bp);
- continue;
- }
- bit_nset(io_avail, bp-addr,
-bp-addr + bp-size - 1);
- bp-next = pool_ioblks;
- pool_ioblks = bp;
+ if (bp-size == 0 || bp-addr == 0) {
+ free(bp);
+ continue;
}
+ bit_nset(io_avail, bp-addr,
+bp-addr + bp-size - 1);
+ bp-next = pool_ioblks;
+ pool_ioblks = bp;
}
- io_init = 1;
pusht = 1;
break;
case KWD_IRQ:
- /* reserved irqs */
+
Re: more softpower/apm..
Hi, Bryan.
Does anyone know if its possible for FreeBSD to execute a halt from
the powerswitch?
From reading the apmd doco, this is what apmd is suppose to do, handle
events from the APM bios and execute according to apmd.conf
If an ATX powersupply/motherboard is setup to suspend on power button,
(i.e hold down for 5 seconds to turn off)
can FreeBSD pick up this button press and do clean shutdown?
I tried running apmd -dv, but I cant seem to see any events from the power
button pressing.
Apmd was developed for you :-)
You can reject suspend request on power button and execute shutdown -p
instead.
For example, My box was setup to suspend on power button and issues
USERSUSPENDREQ, so my apmd.conf is like this;
apm_event USERSUSPENDREQ {
reject;
exec "shutdown -p now";
}
Have fun!
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: New Joystick driver?
Hi, Well, I was going to try to roll my own for this, but it's always nice to know someone's already done it for me. :) I'm gone though for the next couple weeks though, so that'll be a nice thing to get back home to. Many thanks! Where will I be able to get it? -Joe Well, it's not ready yet. I'll be putting it in as a PR once I've finished. Probably it'll be released to the multimedia group first as a test. I made quick hack on Linux js compatible joystick driver just last month. Please refer the following URL if you are interested in. http://home.jp.FreeBSD.ORG/cgi-bin/showmail/raw/tech-jp/2385 (Sorry, it is in Japanese. I'll explain for you if you need.) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: New Joystick driver?
Hi, Well, I was going to try to roll my own for this, but it's always nice to know someone's already done it for me. :) I'm gone though for the next couple weeks though, so that'll be a nice thing to get back home to. Many thanks! Where will I be able to get it? -Joe Well, it's not ready yet. I'll be putting it in as a PR once I've finished. Probably it'll be released to the multimedia group first as a test. I made quick hack on Linux js compatible joystick driver just last month. Please refer the following URL if you are interested in. http://home.jp.FreeBSD.ORG/cgi-bin/showmail/raw/tech-jp/2385 (Sorry, it is in Japanese. I'll explain for you if you need.) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: [Call for review] apmd for FreeBSD
Hi, Documentation of apmd was updated by cooperation with Nick Hilliard [EMAIL PROTECTED]. # Thanks Nick! Updated README and apmd.8 are available at: http://home.jp.freebsd.org/~iwasaki/apm/19990630/apmd-doc.tar.gz http://home.jp.freebsd.org/~iwasaki/apm/19990630/apmd-doc.diff.gz Also, I'm going to import them on this (or next) weekend if nothing happened. # I'm not sure when because I'm in the hospital... :-( Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [Call for review] apmd for FreeBSD
Hi, Documentation of apmd was updated by cooperation with Nick Hilliard n...@foobar.org. # Thanks Nick! Updated README and apmd.8 are available at: http://home.jp.freebsd.org/~iwasaki/apm/19990630/apmd-doc.tar.gz http://home.jp.freebsd.org/~iwasaki/apm/19990630/apmd-doc.diff.gz Also, I'm going to import them on this (or next) weekend if nothing happened. # I'm not sure when because I'm in the hospital... :-( Thanks To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
[Call for review] apmd for FreeBSD
Hi, I'm ready to import apmd into freefall CVS repository. Now manpage (first version) and patch for CURRENT kernel were prepared :) Please review them before my commit. Any comments, suggestions, corrections are very appreciated. The latest (and final?) version of apmd package is available at: apmd(8): http://home.jp.freebsd.org/~iwasaki/apm/19990628/apmd-usr.sbin.tar.gz CURRENT kernel patch (as of 19990628): http://home.jp.freebsd.org/~iwasaki/apm/19990628/apmd-sys-CURRENT.diff.gz No changes were made for previous PAO3 and 3.2-RELEASE kernel patch: http://home.jp.freebsd.org/~iwasaki/apm/19990610/apmd-sys-PAO3.diff.gz http://home.jp.freebsd.org/~iwasaki/apm/19990610/apmd-sys-R320.diff.gz Thanks. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: apmd for FreeBSD
Thanks a lot for your testing. I'm preparing -current NotePC for testing this. imp I've applied the patches to my -current system. I had to apply two by imp hand, and then it just compiled and appeared to work with no ill imp effects on my desktop. It should :) I heard that 3.2-RELEASE kernel patch can be applied to -STABLE (even 2.2-STABLE) with no rejects because there are few differences between them. imp P.S. I've put my diffs vs -current at imphttp://www.freebsd.org/~imp/apmd-sys-current.diff.gz Thanks. Give my kind regards. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
apmd for FreeBSD
Hi, folks.
graham ooh apmd, cool.
graham I was wondering if someone had started somthing like this, I'm excited.
Sorry to late, now first version of apmd package for FreeBSD is available at
apmd(8):
http://home.jp.freebsd.org/~iwasaki/apm/19990610/apmd-usr.sbin.tar.gz
3.2-RELEASE kernel patch:
http://home.jp.freebsd.org/~iwasaki/apm/19990610/apmd-sys-R320.diff.gz
if you are using PAO3, kernel patch would be
PAO3 kernel patch:
http://home.jp.freebsd.org/~iwasaki/apm/19990610/apmd-sys-PAO3.diff.gz
The kernel patches for 2.2-STABLE and -CURRENT are not available for now.
Please make contact with me if you need them.
Any comments, suggestions, bug-reports, improvements are very much
appreciated.
I'm looking forward working with you :-)
---
FreeBSD apmd Package Release Notes (19990610 version)
1. What's apmd package
==
This apmd package provides a means of handling various APM events from
userland code. From apmd.conf, the apmd(8) configuration file, you
can select the APM events to be handled from userland and specify the
commands for a given event, allowing APM behaviour to be configured
flexibly.
2. How to install the apmd package
==
2.1 Making the apmd control device file
---
apmd(8) uses the new special device file /dev/apmctl. You should create
the device file before using apmd as follows:
# cd /dev
# mknod apmctl c 39 8
2.2 Applying the kernel patch and building a new kernel
---
The next step is to apply the patch against the sys source tree.
Go to the source directory (eg. /usr/src/ or /usr/PAO3/src/) and run
the patch command as follows:
# gzip -cd [somewhere]/apmd-sys-R320.diff | patch
For PAO3 users, the patch file name would be apmd-sys-PAO3.diff
instead of apmd-sys-R320.diff. After this step has completed
successfully, build and install a new kernel and reboot your system.
2.3 Making the apmd program
---
Go to src/usr.sbin/ and extract the apmd tarball as follows:
# tar xzpvf [somewhere]/apmd-usr.sbin.tar.gz
Before doing a make all, you need to copy apm_bios.h in the sys source
tree to /usr/include/machine/ first:
# cp /sys/i386/include/apm_bios.h /usr/include/machine/
Then do the build and install steps in the apmd directory:
# cd src/usr.sbin/apmd
# make depend all install
2.4 Setting up the configuration file and userland script
-
In src/usr.sbin/apm/etc/ there are example configuration and userland
script files which are invoked automatically when the APM BIOS informs
apmd of an event, such as suspend request. Copy these files to
/etc/apm as follows:
# mkdir /etc/apm
# cp src/usr.sbin/apm/etc/* /etc/apm/
3. Running the apmd daemon program
==
To run apmd(8) in background mode, simply type ``apmd''.
# apmd
To make a running apmd reload /etc/apm/apmd.conf, send a SIGHUP signal to
the apmd(8) process.
# kill -HUP [apmd pid]
or
# killall -HUP apmd
apmd has some command line options. For the detials, please
refer to the source code :-)
4. Configuration file
=
The structure of the apmd configuration file is quite simple. For
example:
apm_event SUSPENDREQ {
exec sync sync sync;
exec sleep 1;
exec zzz;
}
Will cause apmd to recieve the APM event SUSPENDREQ (which may be
posted by an LCD close), run the sync command 3 times and wait for a
while, then execute zzz (apm -z) to put the system in the suspend
state.
4.1 The apm_event keyword
-
`apm_event' is the keyword which indicates the start of configuration for
each events.
4.2 APM events
--
`SUSPENDREQ' is one of the APM event names. You can specify 2 or more
events delimited by a comma, executing the same commands for these
events. The following are available event names:
o Events ignored by the kernel if apmd is running:
STANDBYREQ
SUSPENDREQ
USERSUSPENDREQ
BATTERYLOW
o Events passed to apmd after kernel handling:
NORMRESUME
CRITRESUME
STANDBYRESUME
POWERSTATECHANGE
UPDATETIME
Other events will not be sent to apmd.
4.3 command line syntax
---
In our example, the next 3 lines begining with `exec' are commands for
the event. Each line should be terminated with a semicolon. The
command list for the event should be enclosed by `{' and `}'. apmd(8)
uses /bin/sh for double-quotation enclosed command execution, just as
with system(3). Each command is executed in order until the end of
the list is reached or a command finishes with a non-zero status code.
apmd(8) will report any failing command's status code via syslog(3).
4.4 Built-in functions
--
You can also specify apmd built-in functions instead of command lines.
A built-in function name should be terminated
