From jhb at freebsd.org Fri May 1 15:53:56 2009 From: jhb at freebsd.org (John Baldwin) Date: Fri May 1 15:54:03 2009 Subject: Fwd: Kernel panic on 7.2-RC1 when booting with ACPI enabled kernel. In-Reply-To: <11167f520904301526g3f0185a9m51e601cbfa04177a@mail.gmail.com> References: <43b1bb350904230622u4b7790f0p9f665b649c97a3b@mail.gmail.com> <200904300836.34238.jhb@freebsd.org> <11167f520904301526g3f0185a9m51e601cbfa04177a@mail.gmail.com> Message-ID: <200905010921.49712.jhb@freebsd.org> On Thursday 30 April 2009 6:26:10 pm Sam Fourman Jr. wrote: > On Thu, Apr 30, 2009 at 7:36 AM, John Baldwin wrote: > > On Saturday 25 April 2009 6:27:23 am Magnus Kling wrote: > >> 2009/4/24 John Baldwin > >> > Can you do 'frame 10' followed by 'p *(struct acpi_pci_devinfo > >> > *)child->ivars' > >> > > >> > -- > >> > John Baldwin > >> > >> (kgdb) frame 10 > >> #10 0xc0db4ca8 in acpi_pci_child_location_str_method (cbdev=0xc2212680, > >> ? ? child=0xc2243400, buf=0xc22c2400 "slot=0 function=0 handle=", > >> buflen=1024) > >> ? ? at /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/acpi_pci.c:150 > >> 150 ? ? ? ? ? ? strlcat(buf, acpi_name(dinfo->ap_handle), buflen); > >> > >> (kgdb) ?p *(struct acpi_pci_devinfo *)child->ivars > >> $1 = {ap_dinfo = {pci_links = {stqe_next = 0xc0b00f8c}, resources = { > >> ? ? ? stqh_first = 0xc0b00f8c, stqh_last = 0x1030000}, cfg = {dev = 0x0, > >> ? ? ? bar = {4, 0, 0, 3257136600, 0, 0}, bios = 0, subvendor = 0, > >> ? ? ? subdevice = 0, vendor = 0, device = 0, cmdreg = 0, statreg = 0, > >> ? ? ? baseclass = 0 '\0', subclass = 0 '\0', progif = 0 '\0', revid = 0 > > I also have a ACPI problem that may be related > > http://www.nabble.com/Asus-X83VB-X2-Notebook-ACPI-kernel-panic-td23290433.html There aren't any panic messages in your messages file. There is a LOR that is a false-positive, but I don't see any panic info. -- John Baldwin From klingfon at gmail.com Fri May 1 18:30:30 2009 From: klingfon at gmail.com (Magnus Kling) Date: Fri May 1 18:30:36 2009 Subject: Fwd: Kernel panic on 7.2-RC1 when booting with ACPI enabled kernel. In-Reply-To: <200904300836.34238.jhb@freebsd.org> References: <43b1bb350904230622u4b7790f0p9f665b649c97a3b@mail.gmail.com> <43b1bb350904250326o63cb3085vc6a7079fba7cd700@mail.gmail.com> <43b1bb350904250327n2bc0c651y7e725abda56538b0@mail.gmail.com> <200904300836.34238.jhb@freebsd.org> Message-ID: <43b1bb350905011130q4f58c018g66a9e4624c364b65@mail.gmail.com> 2009/4/30 John Baldwin > On Saturday 25 April 2009 6:27:23 am Magnus Kling wrote: > > 2009/4/24 John Baldwin > > > Can you do 'frame 10' followed by 'p *(struct acpi_pci_devinfo > > > *)child->ivars' > > > > > > -- > > > John Baldwin > > > > > > Sure, no problem. This is a none critical server so I can do alot of > > debugging and testing if that is needed. > > > > > > (kgdb) frame 10 > > #10 0xc0db4ca8 in acpi_pci_child_location_str_method (cbdev=0xc2212680, > > child=0xc2243400, buf=0xc22c2400 "slot=0 function=0 handle=", > > buflen=1024) > > at /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/acpi_pci.c:150 > > 150 strlcat(buf, acpi_name(dinfo->ap_handle), buflen); > > > > (kgdb) p *(struct acpi_pci_devinfo *)child->ivars > > $1 = {ap_dinfo = {pci_links = {stqe_next = 0xc0b00f8c}, resources = { > > stqh_first = 0xc0b00f8c, stqh_last = 0x1030000}, cfg = {dev = 0x0, > > bar = {4, 0, 0, 3257136600, 0, 0}, bios = 0, subvendor = 0, > > subdevice = 0, vendor = 0, device = 0, cmdreg = 0, statreg = 0, > > baseclass = 0 '\0', subclass = 0 '\0', progif = 0 '\0', revid = 0 > > Hmm, this is all completely wrong and trashed. What if you do 'p *child'? > > -- > John Baldwin > (kgdb) p *child $2 = {ops = 0xc2161800, link = {tqe_next = 0xc2243380, tqe_prev = 0xc2243484}, devlink = {tqe_next = 0xc2243380, tqe_prev = 0xc224348c}, parent = 0xc2212680, children = {tqh_first = 0xc2262880, tqh_last = 0xc2262704}, driver = 0xc0b7066c, devclass = 0xc211e240, unit = 0, nameunit = 0xc2241640 "atapci0", desc = 0xc223f900 "Promise PDC20621 UDMA100 controller", busy = 0, state = DS_ATTACHED, devflags = 0, flags = 13, order = 0 '\0', pad = 0 '\0', ivars = 0xc223f5c0, softc = 0xc2244800, sysctl_ctx = {tqh_first = 0xc2264380, tqh_last = 0xc2241594}, sysctl_tree = 0xc223f840} (kgdb) /Magnus From jhb at freebsd.org Fri May 1 19:08:36 2009 From: jhb at freebsd.org (John Baldwin) Date: Fri May 1 19:08:49 2009 Subject: Fwd: Kernel panic on 7.2-RC1 when booting with ACPI enabled kernel. In-Reply-To: <43b1bb350905011130q4f58c018g66a9e4624c364b65@mail.gmail.com> References: <43b1bb350904230622u4b7790f0p9f665b649c97a3b@mail.gmail.com> <200904300836.34238.jhb@freebsd.org> <43b1bb350905011130q4f58c018g66a9e4624c364b65@mail.gmail.com> Message-ID: <200905011450.13899.jhb@freebsd.org> On Friday 01 May 2009 2:30:28 pm Magnus Kling wrote: > 2009/4/30 John Baldwin > > > On Saturday 25 April 2009 6:27:23 am Magnus Kling wrote: > > > 2009/4/24 John Baldwin > > > > Can you do 'frame 10' followed by 'p *(struct acpi_pci_devinfo > > > > *)child->ivars' > > > > > > > > -- > > > > John Baldwin > > > > > > > > > Sure, no problem. This is a none critical server so I can do alot of > > > debugging and testing if that is needed. > > > > > > > > > (kgdb) frame 10 > > > #10 0xc0db4ca8 in acpi_pci_child_location_str_method (cbdev=0xc2212680, > > > child=0xc2243400, buf=0xc22c2400 "slot=0 function=0 handle=", > > > buflen=1024) > > > at /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/acpi_pci.c:150 > > > 150 strlcat(buf, acpi_name(dinfo->ap_handle), buflen); > > > > > > (kgdb) p *(struct acpi_pci_devinfo *)child->ivars > > > $1 = {ap_dinfo = {pci_links = {stqe_next = 0xc0b00f8c}, resources = { > > > stqh_first = 0xc0b00f8c, stqh_last = 0x1030000}, cfg = {dev = 0x0, > > > bar = {4, 0, 0, 3257136600, 0, 0}, bios = 0, subvendor = 0, > > > subdevice = 0, vendor = 0, device = 0, cmdreg = 0, statreg = 0, > > > baseclass = 0 '\0', subclass = 0 '\0', progif = 0 '\0', revid = 0 > > > > Hmm, this is all completely wrong and trashed. What if you do 'p *child'? > > > > -- > > John Baldwin > > > (kgdb) p *child > $2 = {ops = 0xc2161800, link = {tqe_next = 0xc2243380, tqe_prev = > 0xc2243484}, devlink = {tqe_next = 0xc2243380, tqe_prev = 0xc224348c}, > parent = 0xc2212680, children = {tqh_first = 0xc2262880, tqh_last = > 0xc2262704}, driver = 0xc0b7066c, devclass = 0xc211e240, unit = 0, > nameunit = 0xc2241640 "atapci0", desc = 0xc223f900 "Promise PDC20621 > UDMA100 controller", busy = 0, state = DS_ATTACHED, devflags = 0, > flags = 13, order = 0 '\0', pad = 0 '\0', ivars = 0xc223f5c0, softc = > 0xc2244800, sysctl_ctx = {tqh_first = 0xc2264380, tqh_last = 0xc2241594}, > sysctl_tree = 0xc223f840} > (kgdb) Maybe try adding KTR traces for all calls to device_set_ivars(). I wonder if something is trashing this device's ivars. Oh, dear. The ata(4) driver overwrites the ivars of some PCI devices it attaches to. This is very, very wrong. Which ATA controller do you have? -- John Baldwin From jhb at freebsd.org Fri May 1 19:08:38 2009 From: jhb at freebsd.org (John Baldwin) Date: Fri May 1 19:08:50 2009 Subject: Garbled output from kgdb? In-Reply-To: <49FB2847.406@umn.edu> References: <49F8B859.7060908@umn.edu> <200905010947.54855.jhb@freebsd.org> <49FB2847.406@umn.edu> Message-ID: <200905011501.40083.jhb@freebsd.org> On Friday 01 May 2009 12:50:15 pm Alan Amesbury wrote: > John Baldwin wrote: > > > Drop the '0x8:' from this and it will work better. Also, 'bt' output would be > > good. > > Thanks for the pointer (no pun intended). > > > (kgdb) list *0xffffffff80424561 > 0xffffffff80424561 is in turnstile_wait > (/usr/src/sys/kern/subr_turnstile.c:727). > 722 else > 723 > TAILQ_INSERT_TAIL(&ts->ts_blocked[queue], td, td_lockq); > 724 MPASS(owner == ts->ts_owner); > 725 mtx_unlock_spin(&td_contested_lock); > 726 MPASS(td->td_turnstile != NULL); > 727 LIST_INSERT_HEAD(&ts->ts_free, td->td_turnstile, > ts_hash); > 728 } > 729 thread_lock(td); > 730 thread_lock_set(td, &ts->ts_lock); > 731 td->td_turnstile = NULL; This is odd. > The backtrace looked odd (lots of stuff apparently missing), which is > why I didn't include it before. Here it is with repeated lines > collapsed for brevity: > > > (kgdb) backtrace > #0 doadump () at pcpu.h:195 > #1 0x0000000000000000 in ?? () > #2 0xffffffff803ee713 in boot (howto=260) at > /usr/src/sys/kern/kern_shutdown.c:418 > #3 0xffffffff803ee9c5 in panic (fmt=Variable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:574 > #4 0xffffffff8062478e in trap_fatal (frame=0xffffffffac057a40, eva=96) > at /usr/src/sys/amd64/amd64/trap.c:764 > #5 0xffffffff806251c6 in trap (frame=0xffffffffac057a40) at > /usr/src/sys/amd64/amd64/trap.c:290 > #6 0xffffffff8060aafe in calltrap () at > /usr/src/sys/amd64/amd64/exception.S:209 > #7 0xffffffff80424561 in turnstile_wait (ts=0xffffff000105dd20, > owner=Variable "owner" is not available. > ) at /usr/src/sys/kern/subr_turnstile.c:727 > #8 0xffffffff803e0915 in _mtx_lock_sleep (m=0xffffff00011ff600, > tid=18446742974215718624, opts=Variable "opts" is not available. > ) at /usr/src/sys/kern/kern_mutex.c:420 > #9 0xffffffff801ee1e9 in AcpiOsAcquireLock (Handle=0xffffff000105dd20) > at /usr/src/sys/dev/acpica/Osd/OsdSynch.c:377 > #10 0xffffffff801aaf9c in AcpiSetRegister (RegisterId=1, Value=1) at > /usr/src/sys/contrib/dev/acpica/hwregs.c:444 > #11 0xffffffff801f5f6e in acpi_cpu_idle () at > /usr/src/sys/dev/acpica/acpi_cpu.c:928 > #12 0xffffffff806119a9 in cpu_idle () at > /usr/src/sys/amd64/amd64/machdep.c:581 > #13 0xffffffff8040f0e4 in sched_idletd (dummy=Variable "dummy" is not > available. > ) at /usr/src/sys/kern/sched_ule.c:2676 > #14 0xffffffff803caa30 in fork_exit (callout=0xffffffff8040ee00 > , arg=0x0, frame=0xffffffffac057c80) at > /usr/src/sys/kern/kern_fork.c:804 > #15 0xffffffff8060aece in fork_trampoline () at > /usr/src/sys/amd64/amd64/exception.S:455 The trace actually ends here. There is nothing super bad here but there is a big problem actually in that the idle threads cannot block on a lock, so it is a problem for the ACPI code to be acquiring a mutex here. Perhaps the locks protecting the idle registers need to use spin locks instead. The problem with blocking in the idle thread is that the scheduler assumes (even requires) that the idle thread is _always_ runnable. -- John Baldwin From klingfon at gmail.com Fri May 1 19:30:31 2009 From: klingfon at gmail.com (Magnus Kling) Date: Fri May 1 19:30:40 2009 Subject: Fwd: Kernel panic on 7.2-RC1 when booting with ACPI enabled kernel. In-Reply-To: <200905011450.13899.jhb@freebsd.org> References: <43b1bb350904230622u4b7790f0p9f665b649c97a3b@mail.gmail.com> <200904300836.34238.jhb@freebsd.org> <43b1bb350905011130q4f58c018g66a9e4624c364b65@mail.gmail.com> <200905011450.13899.jhb@freebsd.org> Message-ID: <43b1bb350905011230p1372e1ffw5ab61985e7672e19@mail.gmail.com> 2009/5/1 John Baldwin > On Friday 01 May 2009 2:30:28 pm Magnus Kling wrote: > > 2009/4/30 John Baldwin > > > > > On Saturday 25 April 2009 6:27:23 am Magnus Kling wrote: > > > > 2009/4/24 John Baldwin > > > > > Can you do 'frame 10' followed by 'p *(struct acpi_pci_devinfo > > > > > *)child->ivars' > > > > > > > > > > -- > > > > > John Baldwin > > > > > > > > > > > > Sure, no problem. This is a none critical server so I can do alot of > > > > debugging and testing if that is needed. > > > > > > > > > > > > (kgdb) frame 10 > > > > #10 0xc0db4ca8 in acpi_pci_child_location_str_method > (cbdev=0xc2212680, > > > > child=0xc2243400, buf=0xc22c2400 "slot=0 function=0 handle=", > > > > buflen=1024) > > > > at > /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/acpi_pci.c:150 > > > > 150 strlcat(buf, acpi_name(dinfo->ap_handle), buflen); > > > > > > > > (kgdb) p *(struct acpi_pci_devinfo *)child->ivars > > > > $1 = {ap_dinfo = {pci_links = {stqe_next = 0xc0b00f8c}, resources = { > > > > stqh_first = 0xc0b00f8c, stqh_last = 0x1030000}, cfg = {dev = > 0x0, > > > > bar = {4, 0, 0, 3257136600, 0, 0}, bios = 0, subvendor = 0, > > > > subdevice = 0, vendor = 0, device = 0, cmdreg = 0, statreg = 0, > > > > baseclass = 0 '\0', subclass = 0 '\0', progif = 0 '\0', revid = > 0 > > > > > > Hmm, this is all completely wrong and trashed. What if you do 'p > *child'? > > > > > > -- > > > John Baldwin > > > > > (kgdb) p *child > > $2 = {ops = 0xc2161800, link = {tqe_next = 0xc2243380, tqe_prev = > > 0xc2243484}, devlink = {tqe_next = 0xc2243380, tqe_prev = 0xc224348c}, > > parent = 0xc2212680, children = {tqh_first = 0xc2262880, tqh_last = > > 0xc2262704}, driver = 0xc0b7066c, devclass = 0xc211e240, unit = 0, > > nameunit = 0xc2241640 "atapci0", desc = 0xc223f900 "Promise PDC20621 > > UDMA100 controller", busy = 0, state = DS_ATTACHED, devflags = 0, > > flags = 13, order = 0 '\0', pad = 0 '\0', ivars = 0xc223f5c0, softc = > > 0xc2244800, sysctl_ctx = {tqh_first = 0xc2264380, tqh_last = 0xc2241594}, > > sysctl_tree = 0xc223f840} > > (kgdb) > > Maybe try adding KTR traces for all calls to device_set_ivars(). I wonder > if > something is trashing this device's ivars. > > Oh, dear. The ata(4) driver overwrites the ivars of some PCI devices it > attaches to. This is very, very wrong. Which ATA controller do you have? > > -- > John Baldwin > Aha, I?m using a Promise Fasttrack SX4000 for a RAID1 setup. And the one included on the motherboard for the OS. And yes, I can confirm that without the Fasttrack SX4000 the system boots up correctly. (Pulled out the card and edited fstab.) So you are right regarding that the ata driver messes something up. Do you contact someone that is responsible for ata driver? Thank you for taking the time to "correct" this, Magnus From mav at FreeBSD.org Sun May 3 23:18:26 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Sun May 3 23:18:32 2009 Subject: Fighting for the power. Message-ID: <49FE1826.4060000@FreeBSD.org> I would like to summarize some of my knowledge on reducing FreeBSD power consumption and describe some new things I have recently implemented in 8-CURRENT. The main character of this story is my 12" Acer TravelMate 6292 laptop with C2D T7700 2.4GHz CPU, 965GM chipset and SATA HDD, under amd64 8-CURRENT. Modern systems, especially laptops, are implementing big number of power-saving technologies. Some of them are working automatically, other have significant requirements and need special system tuning or trade-offs to be effectively used. So here is the steps: 1. CPU CPU is the most consuming part of the system. Under the full load it alone may consume more then 40W of power, but for real laptop usage the most important is idle consumption. Core2Duo T7700 CPU has 2 cores, runs on 2.4GHz frequency, supports EIST technology with P-states at 2400, 2000, 1600, 1200 and 800MHz levels, supports C1, C2 and C3 idle C-states, plus throttling. So how can we use it: P-states and throttling Enabling powerd allows to effectively control CPU frequency/voltage depending on CPU load. powerd on recent system can handle it quite transparently. By default, frequency controlled via mix of EIST and throttling technologies. First one controls both core frequency and voltage, second - only core frequency. Both technologies give positive power-saving effect. But effect of throttling is small and can be completely hidden by using C2 state, that's why I recommend to disable throttling control by adding to /boot/loader.conf: hint.p4tcc.0.disabled=1 hint.acpi_throttle.0.disabled=1 In my case frequency/voltage control saves about 5W of idle power. C-states - C1 stops clock on some parts of CPU core during inactivity. It is safe, cheap and supported by CPUs for ages. System uses C1 state by default. - C2 state allows CPU to turn off all core clocks on idle. It is also cheap, but requires correct ACPI-chipset-CPU interoperation to be used. Use of C2 state can be enabled by adding to /etc/rc.conf: performance_cx_lowest="C2" economy_cx_lowest="C2" Effect from this state is not so big when powerd is used, but still noticeable, - C3 state allows CPU completely stop all internal clocks, reduce voltage and disconnect from system bus. This state gives additional power saving effect, but it is not cheap and require trade-offs. As soon as CPU is completely stopped in C3 state, local APIC timers in each CPU core, used by FreeBSD as event sources on SMP, are not functioning. It stops system time, breaks scheduling that makes system close to dead. The only solution for this problem is to use some external timers. Originally, before SMP era, FreeBSD used i8254 (for HZ) and RTC (for stats) chipset timers. I have made changes to 8-CURRENT to resurrect them for SMP systems. To use them, you can disable local APIC timers by adding to /boot/loader.conf: hint.apic.0.clock=0 Also, to drop/rise voltage on C3, CPU needs time (57us for my system). It means that C3 state can't be effectively used when system is waking up often. To increase inactivity periods we should reduce interrupt rate as much as possible by adding to loader.conf: kern.hz=100 It may increase system response time a bit, but it is not significant for laptop. Also we may avoid additional 128 interrupts per second per core, by the cost of scheduling precision, with using i8254 timer also for statistic collection purposes instead of RTC clock, by using another newly added option: hint.atrtc.0.clock=0 As result, system has only 100 interrupts per core and CPUs are using C3 with high efficiency: %sysctl dev.cpu |grep cx dev.cpu.0.cx_supported: C1/1 C2/1 C3/57 dev.cpu.0.cx_lowest: C3 dev.cpu.0.cx_usage: 0.00% 0.00% 100.00% last 7150us dev.cpu.1.cx_supported: C1/1 C2/1 C3/57 dev.cpu.1.cx_lowest: C3 dev.cpu.1.cx_usage: 0.00% 0.00% 100.00% last 2235us Result of effective C3 state usage, comparing to C2+powerd, is about 2W. 2. PCI devices PCI bus provides method to control device power. For example, I have completely no use for my FireWire controller and most of time - EHCI USB controller. Disabling them allows me to save about 3W of power. To disable all unneeded PCI devices you should build kernel without their drivers and add to loader.conf: hw.pci.do_power_nodriver=3 To enable devices back all you need to do is just load their drivers as modules. 3. Radios WiFi and Bluetooth adapters can consume significant power when used (up to 2W when my iwn WiFi is connected) or just enabled (0.5W). Disabling them with mechanical switch on laptop case saves energy even when they are not connected. 4. HDA modem I was surprised, but integrated HDA modem consumed about 1W of power even when not used. I have used the most radical solution - removed it mechanically from socket. Case surface in that area become much cooler. 5. HDA sound To reduce number of sound generated interrupts I have added to the loader.conf: hint.pcm.0.buffersize=65536 hint.pcm.1.buffersize=65536 hw.snd.feeder_buffersize=65536 hw.snd.latency=7 6. HDD First common recommendation is use tmpfs for temporary files. RAM is cheap, fast and anyway with you. Also you may try to setup automatic idle drive spin-down, but if it is the only system drive you should be careful, as every spin-up reduces drive's life time. For several months (until I have bought SATA SSD) I have successfully used SDHC card in built-in PCI sdhci card reader as main filesystem. On random read requests it is much faster then HDD, but it is very slow on random write. Same time it consumes almost nothing. USB drives could also be used, but effect is much less as EHCI USB controller consumes much power. Spinning-down my 2.5" Hitachi SATA HDD saves about 1W of power. Removing it completely saves 2W. 7. SATA Comparing to PATA, SATA interface uses differential signaling for data transfer. To work properly it has to transmit pseudo-random scrambled sequence even when idle. As you understand, that requires power. But SATA implements two power saving modes: PARTIAL and SLUMBER. These modes could be activated by either host or device if both sides support them. PARTIAL mode just stops scrambling, but keeps neutral link state, resume time is 50-100us. SLUMBER mode powers down interface completely, but respective resume time is 3-10ms. I have added minimal SATA power management to AHCI driver. There are hint.ata.X.pm_level loader tunables can be used to control it now. Setting it to 1 allows drive itself to initiate power saving, when it wish. Values 2 and 3 make AHCI controller to initiate PARTIAL and SLUMBER transitions after every command completion. Note that SATA power saving is not compatible with drive hot-swap, as controller unable to detect drive presence when link is powered-down. In my case PARTIAL mode saves 0.5W and SLUMBER - 0.8W of power. So what have I got? To monitor real system power consumption I am using information provided by ACPI battery via `acpiconf -i0` command: Original system: Design capacity: 4800 mAh Last full capacity: 4190 mAh Technology: secondary (rechargeable) Design voltage: 11100 mV Capacity (warn): 300 mAh Capacity (low): 167 mAh Low/warn granularity: 32 mAh Warn/full granularity: 32 mAh Model number: Victoria Serial number: 292 Type: LION OEM info: SIMPLO State: discharging Remaining capacity: 93% Remaining time: 2:24 Present rate: 1621 mA Voltage: 12033 mV Tuned system: %acpiconf -i0 Design capacity: 4800 mAh Last full capacity: 4190 mAh Technology: secondary (rechargeable) Design voltage: 11100 mV Capacity (warn): 300 mAh Capacity (low): 167 mAh Low/warn granularity: 32 mAh Warn/full granularity: 32 mAh Model number: Victoria Serial number: 292 Type: LION OEM info: SIMPLO State: discharging Remaining capacity: 94% Remaining time: 4:47 Present rate: 826 mA Voltage: 12231 mV So I have really doubled my on-battery time by this tuning - 4:47 hours instead of 2:24 with default settings. Preinstalled vendor-tuned Windows XP on the same system, provides maximum 3:20 hours. -- Alexander Motin From nate at root.org Sun May 3 23:28:46 2009 From: nate at root.org (Nate Lawson) Date: Sun May 3 23:28:52 2009 Subject: [Fwd: kern/134192: [patch] [acpi] don't probe acpi(4) children that are aliases of other nodes] Message-ID: <49FE2452.4000401@root.org> Wonder what you thought of this patch to avoid Aliases in AcpiWalkNamespace()? -------- Original Message -------- Subject: kern/134192: [patch] [acpi] don't probe acpi(4) children that are aliases of other nodes Resent-Date: Sun, 3 May 2009 19:50:01 GMT Resent-From: FreeBSD-gnats-submit@freebsd.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-CC: jkim@freebsd.org, njl@freebsd.org Date: Sun, 3 May 2009 23:41:28 +0400 (MSD) From: Eygene Ryabinkin Reply-To: Eygene Ryabinkin To: FreeBSD-gnats-submit@freebsd.org >Number: 134192 >Category: kern >Synopsis: [patch] [acpi] don't probe acpi(4) children that are aliases of other nodes >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun May 03 19:50:00 UTC 2009 >Closed-Date: >Last-Modified: >Originator: Eygene Ryabinkin >Release: FreeBSD 7.1-STABLE amd64 >Organization: Code Labs >Environment: System: FreeBSD 7.1-STABLE amd64 >Description: Some vendors (in my case, Asus) like to create aliases for node names in the DSDT table: ----- Scope (_PR) { Processor (P001, 0x01, 0x00000810, 0x06) {} Alias (P001, CPU1) Processor (P002, 0x02, 0x00000000, 0x00) {} Alias (P002, CPU2) Processor (P003, 0x03, 0x00000000, 0x00) {} Alias (P003, CPU3) Processor (P004, 0x04, 0x00000000, 0x00) {} Alias (P004, CPU4) } ----- Another example (from Asus system too) is presented in the patch below. Since AcpiWalkNamespace treats CPUX as the real Processor objects, the probe order for acpi(4) bus children will be P001, CPU1, P002, CPU2, P003, CPU3, P004, CPU4. This is very bad, because half of processors are attached twice and half -- aren't attached at all. Moreover, est (Enhanced SpeedStep cpufreq driver) isn't able to get _PSS for CPUX, so P-states will be missing for half of processors. >How-To-Repeat: Insert Alias() instruction to your custom DSDT and try to use it, enabling debug that will show what ACPI nodes are attached to cpuX device nodes. >Fix: The following patch adds ACPI namespace walking procedure that skips nodes that are results of the Alias() operator invocation. This new method is used for probing of acpi(4) bus members. The patch works on two machines of mine that have these annoying Alias() calls in the _PR namespace. I had tried this patch both on 7.x and 8-CURRENT. --- ACPI-attach-children-without-aliases.diff begins here --- >From f70d0d754f381735a67a42be91fa7253b19a5c8c Mon Sep 17 00:00:00 2001 From: Eygene Ryabinkin Date: Sun, 3 May 2009 22:00:20 +0400 ...and use this function to probe acpi(4) children. The rationale is very simple: some BIOS vendors, in my case it was Asus, like to create aliased nodes in the namespaces that will be walked by the acpi bus method that attaches children to the bus. In my particular case, the problem lied in the Processor objects: ----- Scope (_PR) { Processor (P001, 0x01, 0x00000810, 0x06) {} Alias (P001, CPU1) } Scope (_PR) { Processor (P002, 0x02, 0x00000810, 0x06) {} Alias (P002, CPU2) } ----- The thing is that the simple walk routine treated CPU1 and CPU2 as real processors and order of attachment was P001, CPU1, P002, CPU2. Thus, the second CPU was never attached, first was attached twice and est (Enhanced SpeedStep cpufreq(4) driver) was failing to get _PSS (processor P-states) from the CPU1. I greatly doubt that some real devices will be ever created as aliases, since they should be real objects and not modified copies of other device instances. And since ASL Alias() semantics is to provide pseudonym, this modification should be "The Good Thing (tm)". Signed-off-by: Eygene Ryabinkin --- sys/contrib/dev/acpica/aclocal.h | 1 + sys/contrib/dev/acpica/acnamesp.h | 1 + sys/contrib/dev/acpica/acpixf.h | 9 +++++ sys/contrib/dev/acpica/excreate.c | 3 ++ sys/contrib/dev/acpica/nswalk.c | 10 ++++- sys/contrib/dev/acpica/nsxfeval.c | 69 ++++++++++++++++++++++++++++++++++--- sys/dev/acpica/acpi.c | 18 +++++---- 7 files changed, 96 insertions(+), 15 deletions(-) diff --git a/sys/contrib/dev/acpica/aclocal.h b/sys/contrib/dev/acpica/aclocal.h index ba1145e..73e1568 100644 --- a/sys/contrib/dev/acpica/aclocal.h +++ b/sys/contrib/dev/acpica/aclocal.h @@ -301,6 +301,7 @@ typedef struct acpi_namespace_node #define ANOBJ_METHOD_ARG 0x04 /* Node is a method argument */ #define ANOBJ_METHOD_LOCAL 0x08 /* Node is a method local */ #define ANOBJ_SUBTREE_HAS_INI 0x10 /* Used to optimize device initialization */ +#define ANOBJ_IS_ALIAS 0x20 /* Node is an alias to another one */ #define ANOBJ_IS_EXTERNAL 0x08 /* iASL only: This object created via External() */ #define ANOBJ_METHOD_NO_RETVAL 0x10 /* iASL only: Method has no return value */ diff --git a/sys/contrib/dev/acpica/acnamesp.h b/sys/contrib/dev/acpica/acnamesp.h index 8d07fb3..52a50bb 100644 --- a/sys/contrib/dev/acpica/acnamesp.h +++ b/sys/contrib/dev/acpica/acnamesp.h @@ -146,6 +146,7 @@ #define ACPI_NS_WALK_NO_UNLOCK 0 #define ACPI_NS_WALK_UNLOCK 0x01 #define ACPI_NS_WALK_TEMP_NODES 0x02 +#define ACPI_NS_WALK_SKIP_ALIASES 0x04 /* diff --git a/sys/contrib/dev/acpica/acpixf.h b/sys/contrib/dev/acpica/acpixf.h index f85fd67..3757ad0 100644 --- a/sys/contrib/dev/acpica/acpixf.h +++ b/sys/contrib/dev/acpica/acpixf.h @@ -238,6 +238,15 @@ AcpiWalkNamespace ( void **ReturnValue); ACPI_STATUS +AcpiWalkNamespaceNoAliases ( + ACPI_OBJECT_TYPE Type, + ACPI_HANDLE StartObject, + UINT32 MaxDepth, + ACPI_WALK_CALLBACK UserFunction, + void *Context, + void **ReturnValue); + +ACPI_STATUS AcpiGetDevices ( char *HID, ACPI_WALK_CALLBACK UserFunction, diff --git a/sys/contrib/dev/acpica/excreate.c b/sys/contrib/dev/acpica/excreate.c index d237dab..dba8312 100644 --- a/sys/contrib/dev/acpica/excreate.c +++ b/sys/contrib/dev/acpica/excreate.c @@ -221,6 +221,9 @@ AcpiExCreateAlias ( break; } + /* Mark object as alias, so alias creation could be detected */ + AliasNode->Flags |= ANOBJ_IS_ALIAS; + /* Since both operands are Nodes, we don't need to delete them */ return_ACPI_STATUS (Status); diff --git a/sys/contrib/dev/acpica/nswalk.c b/sys/contrib/dev/acpica/nswalk.c index a3ac86c..9cbc56d 100644 --- a/sys/contrib/dev/acpica/nswalk.c +++ b/sys/contrib/dev/acpica/nswalk.c @@ -208,8 +208,7 @@ AcpiNsGetNextNode ( * PARAMETERS: Type - ACPI_OBJECT_TYPE to search for * StartNode - Handle in namespace where search begins * MaxDepth - Depth to which search is to reach - * Flags - Whether to unlock the NS before invoking - * the callback routine + * Flags - Flags that modify walk parameters * UserFunction - Called when an object of "Type" is found * Context - Passed to user function * ReturnValue - from the UserFunction if terminated early. @@ -300,6 +299,13 @@ AcpiNsWalkNamespace ( Status = AE_CTRL_DEPTH; } + /* Skip nodes created by Alias() routines if it was requested */ + else if ((ChildNode->Flags & ANOBJ_IS_ALIAS) && + (Flags & ACPI_NS_WALK_SKIP_ALIASES)) + { + Status = AE_CTRL_DEPTH; + } + /* Type must match requested type */ else if (ChildType == Type) diff --git a/sys/contrib/dev/acpica/nsxfeval.c b/sys/contrib/dev/acpica/nsxfeval.c index 617002c..662a9df 100644 --- a/sys/contrib/dev/acpica/nsxfeval.c +++ b/sys/contrib/dev/acpica/nsxfeval.c @@ -122,6 +122,16 @@ #include #include +static ACPI_STATUS +_AcpiWalkNamespace ( + ACPI_OBJECT_TYPE Type, + ACPI_HANDLE StartObject, + UINT32 MaxDepth, + ACPI_WALK_CALLBACK UserFunction, + void *Context, + void **ReturnValue, + UINT32 AddFlags); + #define _COMPONENT ACPI_NAMESPACE ACPI_MODULE_NAME ("nsxfeval") @@ -491,11 +501,62 @@ AcpiWalkNamespace ( void *Context, void **ReturnValue) { - ACPI_STATUS Status; + ACPI_FUNCTION_TRACE (AcpiWalkNamespace); + return _AcpiWalkNamespace(Type, StartObject, MaxDepth, + UserFunction, Context, ReturnValue, 0); +} - ACPI_FUNCTION_TRACE (AcpiWalkNamespace); +ACPI_EXPORT_SYMBOL (AcpiWalkNamespace) +/******************************************************************************* + * + * FUNCTION: AcpiWalkNamespaceNoAliases + * + * DESCRIPTION: The same as AcpiWalkNamespace, but skips nodes that were + * created as the result of an Alias function. + * + * NOTE: for parameters/semantics see AcpiWalkNamespace. + * + ******************************************************************************/ + +ACPI_STATUS +AcpiWalkNamespaceNoAliases ( + ACPI_OBJECT_TYPE Type, + ACPI_HANDLE StartObject, + UINT32 MaxDepth, + ACPI_WALK_CALLBACK UserFunction, + void *Context, + void **ReturnValue) +{ + ACPI_FUNCTION_TRACE (AcpiWalkNamespaceNoAliases); + + return _AcpiWalkNamespace(Type, StartObject, MaxDepth, + UserFunction, Context, ReturnValue, ACPI_NS_WALK_SKIP_ALIASES); +} + +ACPI_EXPORT_SYMBOL (AcpiWalkNamespaceNoAliases) + +/******************************************************************************* + * + * FUNCTION: _AcpiWalkNamespace + * + * DESCRIPTION: Internal helper for AcpiWalkNamespace and + * AcpiWalkNamespaceNoAliases. + * + ******************************************************************************/ + +static ACPI_STATUS +_AcpiWalkNamespace ( + ACPI_OBJECT_TYPE Type, + ACPI_HANDLE StartObject, + UINT32 MaxDepth, + ACPI_WALK_CALLBACK UserFunction, + void *Context, + void **ReturnValue, + UINT32 AddFlags) +{ + ACPI_STATUS Status; /* Parameter validation */ @@ -519,15 +580,13 @@ AcpiWalkNamespace ( } Status = AcpiNsWalkNamespace (Type, StartObject, MaxDepth, - ACPI_NS_WALK_UNLOCK, + AddFlags | ACPI_NS_WALK_UNLOCK, UserFunction, Context, ReturnValue); (void) AcpiUtReleaseMutex (ACPI_MTX_NAMESPACE); return_ACPI_STATUS (Status); } -ACPI_EXPORT_SYMBOL (AcpiWalkNamespace) - /******************************************************************************* * diff --git a/sys/dev/acpica/acpi.c b/sys/dev/acpica/acpi.c index d79b413..18a9800 100644 --- a/sys/dev/acpica/acpi.c +++ b/sys/dev/acpica/acpi.c @@ -1528,7 +1528,7 @@ acpi_device_scan_children(device_t bus, device_t dev, int max_depth, ctx.user_fn = user_fn; ctx.arg = arg; ctx.parent = h; - return (AcpiWalkNamespace(ACPI_TYPE_ANY, h, max_depth, + return (AcpiWalkNamespaceNoAliases(ACPI_TYPE_ANY, h, max_depth, acpi_device_scan_cb, &ctx, NULL)); } @@ -1648,14 +1648,16 @@ acpi_probe_children(device_t bus) * Scan the namespace and insert placeholders for all the devices that * we find. We also probe/attach any early devices. * - * Note that we use AcpiWalkNamespace rather than AcpiGetDevices because - * we want to create nodes for all devices, not just those that are - * currently present. (This assumes that we don't want to create/remove - * devices as they appear, which might be smarter.) + * Note that we use AcpiWalkNamespaceNoAliases rather than + * AcpiGetDevices because we want to create nodes for all devices, + * not just those that are currently present. (This assumes that we + * don't want to create/remove devices as they appear, which might + * be smarter.) We avoid counting aliased nodes, because we generally + * want to attach only to a "genuine" devices. */ ACPI_DEBUG_PRINT((ACPI_DB_OBJECTS, "namespace scan\n")); - AcpiWalkNamespace(ACPI_TYPE_ANY, ACPI_ROOT_OBJECT, 100, acpi_probe_child, - bus, NULL); + AcpiWalkNamespaceNoAliases(ACPI_TYPE_ANY, ACPI_ROOT_OBJECT, 100, + acpi_probe_child, bus, NULL); /* Pre-allocate resources for our rman from any sysresource devices. */ acpi_sysres_alloc(bus); @@ -2794,7 +2796,7 @@ acpi_wake_prep_walk(int sstate) ACPI_HANDLE sb_handle; if (ACPI_SUCCESS(AcpiGetHandle(ACPI_ROOT_OBJECT, "\\_SB_", &sb_handle))) - AcpiWalkNamespace(ACPI_TYPE_DEVICE, sb_handle, 100, + AcpiWalkNamespaceNoAliases(ACPI_TYPE_DEVICE, sb_handle, 100, acpi_wake_prep, &sstate, NULL); return (0); } -- 1.6.2.4 --- ACPI-attach-children-without-aliases.diff ends here --- >Release-Note: >Audit-Trail: >Unformatted: -- Nate From nate at root.org Sun May 3 23:32:54 2009 From: nate at root.org (Nate Lawson) Date: Sun May 3 23:33:01 2009 Subject: Fighting for the power. In-Reply-To: <49FE1826.4060000@FreeBSD.org> References: <49FE1826.4060000@FreeBSD.org> Message-ID: <49FE29A4.30507@root.org> Alexander Motin wrote: > I would like to summarize some of my knowledge on reducing FreeBSD power > consumption and describe some new things I have recently implemented in > 8-CURRENT. The main character of this story is my 12" Acer TravelMate > 6292 laptop with C2D T7700 2.4GHz CPU, 965GM chipset and SATA HDD, under > amd64 8-CURRENT. Very nice summary. Thanks for doing the research. > P-states and throttling > Enabling powerd allows to effectively control CPU frequency/voltage > depending on CPU load. powerd on recent system can handle it quite > transparently. By default, frequency controlled via mix of EIST and > throttling technologies. First one controls both core frequency and > voltage, second - only core frequency. Both technologies give positive > power-saving effect. But effect of throttling is small and can be > completely hidden by using C2 state, that's why I recommend to disable > throttling control by adding to /boot/loader.conf: > hint.p4tcc.0.disabled=1 > hint.acpi_throttle.0.disabled=1 When I first wrote cpufreq, there was some question if vendors (even non-Intel) might use throttling for more than just cutting the duty cycle. It turns out they haven't, and have focused more on dropping the voltage with P-state transitions (EIST, PowerNow) and are treating throttling as a legacy feature. The time may have come to disable p4tcc and throttling by default, as long as it's easy for a user to enable them again. Perhaps just a change to boot/default/device.hints? > In my case frequency/voltage control saves about 5W of idle power. > C-states > - C1 stops clock on some parts of CPU core during inactivity. It is > safe, cheap and supported by CPUs for ages. System uses C1 state by > default. > - C2 state allows CPU to turn off all core clocks on idle. It is also > cheap, but requires correct ACPI-chipset-CPU interoperation to be used. > Use of C2 state can be enabled by adding to /etc/rc.conf: > performance_cx_lowest="C2" > economy_cx_lowest="C2" The default settings in rc.conf should allow the lowest Cx setting available to be used. Perhaps that changed? Really, we want C3+ to be enabled by default without the user doing anything. > - C3 state allows CPU completely stop all internal clocks, reduce > voltage and disconnect from system bus. This state gives additional > power saving effect, but it is not cheap and require trade-offs. > As soon as CPU is completely stopped in C3 state, local APIC timers in > each CPU core, used by FreeBSD as event sources on SMP, are not > functioning. It stops system time, breaks scheduling that makes system > close to dead. The only solution for this problem is to use some > external timers. Originally, before SMP era, FreeBSD used i8254 (for HZ) > and RTC (for stats) chipset timers. I have made changes to 8-CURRENT to > resurrect them for SMP systems. To use them, you can disable local APIC > timers by adding to /boot/loader.conf: > hint.apic.0.clock=0 > Also, to drop/rise voltage on C3, CPU needs time (57us for my system). > It means that C3 state can't be effectively used when system is waking > up often. To increase inactivity periods we should reduce interrupt rate > as much as possible by adding to loader.conf: > kern.hz=100 Yeah, hz=1000 doesn't make sense for laptops and I use hz=100 everywhere. > It may increase system response time a bit, but it is not significant > for laptop. Also we may avoid additional 128 interrupts per second per > core, by the cost of scheduling precision, with using i8254 timer also > for statistic collection purposes instead of RTC clock, by using another > newly added option: > hint.atrtc.0.clock=0 The real solution for C3 (and C4, etc.) is to implement tickless scheduling and to fix the current dependence on LAPIC for timer interrupts. Hopefully someone will do that soon. With that change, this change isn't needed. > 4. HDA modem > I was surprised, but integrated HDA modem consumed about 1W of power > even when not used. I have used the most radical solution - removed it > mechanically from socket. Case surface in that area become much cooler. Most modems support the ACPI Dx states, where D3 = device powered off. I'd think the PCI "power no driver option" would disable the soft modem since it's unlikely you have a driver for it. > 6. HDD > First common recommendation is use tmpfs for temporary files. RAM is > cheap, fast and anyway with you. > Also you may try to setup automatic idle drive spin-down, but if it is > the only system drive you should be careful, as every spin-up reduces > drive's life time. Did you increase the fsflush delay also? > So I have really doubled my on-battery time by this tuning - 4:47 hours > instead of 2:24 with default settings. Preinstalled vendor-tuned Windows > XP on the same system, provides maximum 3:20 hours. Very nice. I think tickless scheduling is the single largest win for power mgmt we could get. Second best would be S4 (suspend to disk). -- Nate From mcdouga9 at egr.msu.edu Mon May 4 01:30:56 2009 From: mcdouga9 at egr.msu.edu (Adam McDougall) Date: Mon May 4 01:31:03 2009 Subject: Fighting for the power. In-Reply-To: <49FE1826.4060000@FreeBSD.org> References: <49FE1826.4060000@FreeBSD.org> Message-ID: <20090504011421.GI6901@egr.msu.edu> On Mon, May 04, 2009 at 01:18:14AM +0300, Alexander Motin wrote: I would like to summarize some of my knowledge on reducing FreeBSD power consumption and describe some new things I have recently implemented in 8-CURRENT. The main character of this story is my 12" Acer TravelMate 6292 laptop with C2D T7700 2.4GHz CPU, 965GM chipset and SATA HDD, under amd64 8-CURRENT. Great list! May I suggest screen brightness and DPMS as another tool to save power, I've measured a 5W difference from the screen draw. Keeping the brightness as low as tolerable helps considerably, but also using 'xset dpms 120 120 120' (modify to taste) in .xinitrc to turn off the screen after 2 minutes helps when the laptop isn't being used every second. May need this in xorg.conf: Option "dpms" From mav at FreeBSD.org Mon May 4 03:19:42 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Mon May 4 03:19:48 2009 Subject: Fighting for the power. In-Reply-To: <49FE29A4.30507@root.org> References: <49FE1826.4060000@FreeBSD.org> <49FE29A4.30507@root.org> Message-ID: <49FE5EC8.3040205@FreeBSD.org> Nate Lawson wrote: > The time may have come to disable p4tcc and throttling by default, as > long as it's easy for a user to enable them again. Perhaps just a change > to boot/default/device.hints? They still could be effective for old P4 series which had no C1E/C2 idle states support yet. But probably their power consumption is not so interesting area now. > The default settings in rc.conf should allow the lowest Cx setting > available to be used. Perhaps that changed? Really, we want C3+ to be > enabled by default without the user doing anything. Present defaults are to use C1. Probably we can allow C2 use more or less safely. Due to default LAPIC timer problems, enabling C3+ by default will make system dead by default. > Yeah, hz=1000 doesn't make sense for laptops and I use hz=100 everywhere. Without using C3+ it is not so important. I haven't seen any power difference. C1/C2 have practically zero exit latency, while power consumed by interrupt handler itself is miserable. > The real solution for C3 (and C4, etc.) is to implement tickless > scheduling and to fix the current dependence on LAPIC for timer > interrupts. Hopefully someone will do that soon. With that change, this > change isn't needed. System will always have tons of waiting callouts and timeouts to be handled. So timer will be always needed. Working timer. >> 4. HDA modem >> I was surprised, but integrated HDA modem consumed about 1W of power >> even when not used. I have used the most radical solution - removed it >> mechanically from socket. Case surface in that area become much cooler. > > Most modems support the ACPI Dx states, where D3 = device powered off. > I'd think the PCI "power no driver option" would disable the soft modem > since it's unlikely you have a driver for it. Modem share HDA bus/controller with sound. So PCI D3 will kill sound also, that is not an option. snd_hda driver itself puts all non-audio codecs into the HDA D3 state, but in my case it was not effective. >> 6. HDD >> First common recommendation is use tmpfs for temporary files. RAM is >> cheap, fast and anyway with you. >> Also you may try to setup automatic idle drive spin-down, but if it is >> the only system drive you should be careful, as every spin-up reduces >> drive's life time. > > Did you increase the fsflush delay also? I don't, but how long can it delay requests? Several minutes? Hour? Then there is high probability of data loss. Actually I have tried to reduce number of idle disk write activity, but I haven't very succeeded. Even in my quite simple icewm X environment something was persistently writing something every several minutes. I have found and disabled some activity sources, but it was not enough. What would happen in some complicated KDE/Gnome environment I am just afraid to think. -- Alexander Motin From mav at FreeBSD.org Mon May 4 03:45:15 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Mon May 4 03:45:26 2009 Subject: Fighting for the power. In-Reply-To: <20090504011421.GI6901@egr.msu.edu> References: <49FE1826.4060000@FreeBSD.org> <20090504011421.GI6901@egr.msu.edu> Message-ID: <49FE64C5.2020507@FreeBSD.org> Adam McDougall wrote: > On Mon, May 04, 2009 at 01:18:14AM +0300, Alexander Motin wrote: > > I would like to summarize some of my knowledge on reducing FreeBSD power > consumption and describe some new things I have recently implemented in > 8-CURRENT. The main character of this story is my 12" Acer TravelMate > 6292 laptop with C2D T7700 2.4GHz CPU, 965GM chipset and SATA HDD, under > amd64 8-CURRENT. > > Great list! May I suggest screen brightness and DPMS as another tool > to save power, I've measured a 5W difference from the screen draw. > Keeping the brightness as low as tolerable helps considerably, but > also using 'xset dpms 120 120 120' (modify to taste) in .xinitrc to > turn off the screen after 2 minutes helps when the laptop isn't being > used every second. May need this in xorg.conf: > Option "dpms" Yes, backlight is also important. But there is not so much things could be done. When I am leaving system for some time, I can just close the lid, if not put system into S3 state, which require very small power (at least I was unable to really measure it without all-day-long testing). Thanks to jkim@ we have more or less working S3 state for amd64 now. -- Alexander Motin From mav at FreeBSD.org Mon May 4 07:50:25 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Mon May 4 07:50:42 2009 Subject: Fighting for the power. In-Reply-To: <200905040926.38337.hselasky@c2i.net> References: <49FE1826.4060000@FreeBSD.org> <200905040926.38337.hselasky@c2i.net> Message-ID: <49FE9E3B.1050509@FreeBSD.org> Hans Petter Selasky wrote: >> 2. PCI devices >> PCI bus provides method to control device power. For example, I have >> completely no use for my FireWire controller and most of time - EHCI USB >> controller. Disabling them allows me to save about 3W of power. To >> disable all unneeded PCI devices you should build kernel without their >> drivers and add to loader.conf: >> hw.pci.do_power_nodriver=3 >> To enable devices back all you need to do is just load their drivers as >> modules. > > The new USB stack should turn off USB HC's automatically when not in use. At > least the schedules will get disabled. Did you do any research on this? Sorry, I really was testing it only with previous USB stack. Now I can acknowledge, that new ehci module loading adds only 0.2W for me by default and almost nothing if I power down built-in USB2 web cam connected to it using `usbconfig -u 5 -a 2 power_off`. Great! Thanks! -- Alexander Motin From hselasky at c2i.net Mon May 4 08:24:07 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Mon May 4 08:24:19 2009 Subject: Fighting for the power. In-Reply-To: <49FE1826.4060000@FreeBSD.org> References: <49FE1826.4060000@FreeBSD.org> Message-ID: <200905040926.38337.hselasky@c2i.net> > 2. PCI devices > PCI bus provides method to control device power. For example, I have > completely no use for my FireWire controller and most of time - EHCI USB > controller. Disabling them allows me to save about 3W of power. To > disable all unneeded PCI devices you should build kernel without their > drivers and add to loader.conf: > hw.pci.do_power_nodriver=3 > To enable devices back all you need to do is just load their drivers as > modules. The new USB stack should turn off USB HC's automatically when not in use. At least the schedules will get disabled. Did you do any research on this? --HPS From mav at FreeBSD.org Mon May 4 09:51:11 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Mon May 4 09:51:23 2009 Subject: Fighting for the power. In-Reply-To: <3a142e750905040240g58152e69p6fcb797a5e026426@mail.gmail.com> References: <49FE1826.4060000@FreeBSD.org> <3a142e750905040240g58152e69p6fcb797a5e026426@mail.gmail.com> Message-ID: <49FEBA89.4040609@FreeBSD.org> Paul B. Mahol wrote: > On 5/4/09, Alexander Motin wrote: >> 2. PCI devices >> PCI bus provides method to control device power. For example, I have >> completely no use for my FireWire controller and most of time - EHCI USB >> controller. Disabling them allows me to save about 3W of power. To >> disable all unneeded PCI devices you should build kernel without their >> drivers and add to loader.conf: >> hw.pci.do_power_nodriver=3 >> To enable devices back all you need to do is just load their drivers as >> modules. > > Unloading modules doesnt put them back into into D3 state. > You are forced to load some another module again to put wanted device > into D3 state. Yes. Resume also does not powers down unowned devices. Would be good to fix that also. -- Alexander Motin From onemda at gmail.com Mon May 4 10:04:53 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Mon May 4 10:04:59 2009 Subject: Fighting for the power. In-Reply-To: <49FE1826.4060000@FreeBSD.org> References: <49FE1826.4060000@FreeBSD.org> Message-ID: <3a142e750905040240g58152e69p6fcb797a5e026426@mail.gmail.com> On 5/4/09, Alexander Motin wrote: > 2. PCI devices > PCI bus provides method to control device power. For example, I have > completely no use for my FireWire controller and most of time - EHCI USB > controller. Disabling them allows me to save about 3W of power. To > disable all unneeded PCI devices you should build kernel without their > drivers and add to loader.conf: > hw.pci.do_power_nodriver=3 > To enable devices back all you need to do is just load their drivers as > modules. Unloading modules doesnt put them back into into D3 state. You are forced to load some another module again to put wanted device into D3 state. -- Paul From bugmaster at FreeBSD.org Mon May 4 11:07:38 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon May 4 11:07:44 2009 Subject: Current problem reports assigned to freebsd-acpi@FreeBSD.org Message-ID: <200905041107.n44B7aVG098315@freefall.freebsd.org> 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/132602 acpi [acpi] ACPI Problem with Intel SS4200: System does not o kern/130683 acpi [ACPI] shutdown hangs after syncing disks - ACPI race? o i386/129953 acpi [acpi] ACPI timeout (CDROM) with Shuttle X27D o kern/129618 acpi [acpi] Problem with ACPI on HP Pavilion DV2899 laptop o kern/129563 acpi [acpi] sleep broken on IBM/Lenovo T61 in amd64 mode o kern/128639 acpi [patch] [acpi_asus] acpi for ASUS A6F,A3E,A3F,A3N not f kern/128634 acpi [patch] fix acpi_asus(4) in asus a6f laptop o kern/127581 acpi [patch] [acpi_sony] Add support for more Sony features o kern/124744 acpi [acpi] [patch] incorrect _BST result validation for To o kern/124412 acpi [acpi] power off error on Toshiba M40 laptop o kern/123039 acpi [acpi] ACPI AML_BUFFER_LIMIT errors during boot o kern/121504 acpi [patch] Correctly set hw.acpi.osname on certain machin f kern/121454 acpi [pst] Promise SuperTrak SX6000 does not load during bo o kern/121102 acpi [acpi_fujitsu] [patch] update acpi_fujitsu for the P80 o kern/120515 acpi [acpi] [patch] acpi_alloc_wakeup_handler: can't alloc o kern/119356 acpi [acpi]: i386 ACPI wakeup not work due resource exhaust o kern/119200 acpi [acpi] Lid close switch suspends CPU for 1 second on H o kern/118973 acpi [acpi]: Kernel panic with acpi boot o kern/117605 acpi [acpi] [request] add debug.cpufreq.highest o kern/116939 acpi [acpi] PCI-to-PCI misconfigured for bus three and can o i386/114562 acpi [acpi] cardbus is dead after s3 on Thinkpad T43 with a o kern/114165 acpi [acpi] Dell C810 - ACPI problem s kern/112544 acpi [acpi] [patch] Add High Precision Event Timer Driver f o kern/108954 acpi [acpi] 'sleep(1)' sleeps >1 seconds when speedstep (Cx o kern/108695 acpi [acpi]: Fatal trap 9: general protection fault when in o kern/108488 acpi [acpi] ACPI-1304: *** Error: Method execution failed o kern/108017 acpi [acpi]: Acer Aspire 5600 o kern/106924 acpi [acpi] ACPI resume returns g_vfs_done() errors and ker o kern/105537 acpi [acpi] problems in acpi on HP Compaq nc6320 o kern/104625 acpi ACPI on ASUS A8N-32 SLI/ASUS P4P800 does not show ther o kern/102252 acpi acpi thermal does not work on Abit AW8D (intel 975) o kern/97383 acpi Volume buttons on IBM Thinkpad crash system with ACPI s i386/91748 acpi acpi problem on Acer TravelMare 4652LMi (nvidia panic, s kern/91038 acpi [panic] [ata] [acpi] 6.0-RELEASE on Fujitsu Siemens Am s kern/90243 acpi Laptop fan doesn't turn off (ACPI enabled) (Packard Be f kern/89411 acpi [acpi] acpiconf bug o i386/83018 acpi [install] Installer will not boot on Asus P4S8X BIOS 1 o kern/81000 acpi [apic] Via 8235 sound card worked great with FreeBSD 5 o i386/79081 acpi ACPI suspend/resume not working on HP nx6110 o kern/76950 acpi ACPI wrongly blacklisted on Micron ClientPro 766Xi sys s kern/73823 acpi [request] acpi / power-on by timer support o i386/72566 acpi ACPI, FreeBSD disables fan on Compaq Armada 1750 o i386/69750 acpi Boot without ACPI failed on ASUS L5 o kern/56024 acpi ACPI suspend drains battery while in S3 o i386/55661 acpi ACPI suspend/resume problem on ARMADA M700 o i386/54756 acpi ACPI suspend/resume problem on CF-W2 laptop 46 problems total. From mav at FreeBSD.org Mon May 4 12:24:33 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Mon May 4 12:24:44 2009 Subject: Fighting for the power. In-Reply-To: <1241438990.1280.6.camel@RabbitsDen> References: <49FE1826.4060000@FreeBSD.org> <1241438990.1280.6.camel@RabbitsDen> Message-ID: <49FEDE7B.30804@FreeBSD.org> Alexandre "Sunny" Kovalenko wrote: > On Mon, 2009-05-04 at 01:18 +0300, Alexander Motin wrote: >> - C3 state allows CPU completely stop all internal clocks, reduce >> voltage and disconnect from system bus. This state gives additional >> power saving effect, but it is not cheap and require trade-offs. >> As soon as CPU is completely stopped in C3 state, local APIC timers in >> each CPU core, used by FreeBSD as event sources on SMP, are not >> functioning. It stops system time, breaks scheduling that makes system >> close to dead. > Did you try to see whether putting one of the cores in C3 state by doing > something like > > dev.cpu.1.cx_lowest=C3 > > makes any difference? > > # sysctl dev.cpu | grep cx_usage > dev.cpu.0.cx_usage: 0.00% 100.00% 0.00% > dev.cpu.1.cx_usage: 0.00% 5.18% 94.81% I did. As soon as first CPU core is not in C3 state, second core unable to enter C3 completely and disconnect from the bus, as cores are sharing common resources. Such technique allows to avoid LAPIC timer problems, but I haven't noticed any effect from this on CPU idle power. The only difference I have noticed was in the case, when first core is busy. C3 on second idle core then somehow reduces summary consumption a bit. In other words, C3 state should be active on both cores simultaneously to give real effect. -- Alexander Motin From gaijin.k at gmail.com Mon May 4 13:12:27 2009 From: gaijin.k at gmail.com (Alexandre "Sunny" Kovalenko) Date: Mon May 4 13:12:45 2009 Subject: Fighting for the power. In-Reply-To: <49FE1826.4060000@FreeBSD.org> References: <49FE1826.4060000@FreeBSD.org> Message-ID: <1241438990.1280.6.camel@RabbitsDen> On Mon, 2009-05-04 at 01:18 +0300, Alexander Motin wrote: > I would like to summarize some of my knowledge on reducing FreeBSD power > consumption and describe some new things I have recently implemented in > 8-CURRENT. The main character of this story is my 12" Acer TravelMate > 6292 laptop with C2D T7700 2.4GHz CPU, 965GM chipset and SATA HDD, under > amd64 8-CURRENT. > > Modern systems, especially laptops, are implementing big number of > power-saving technologies. Some of them are working automatically, other > have significant requirements and need special system tuning or > trade-offs to be effectively used. > > So here is the steps: > > 1. CPU > CPU is the most consuming part of the system. Under the full load it > alone may consume more then 40W of power, but for real laptop usage the > most important is idle consumption. > Core2Duo T7700 CPU has 2 cores, runs on 2.4GHz frequency, supports EIST > technology with P-states at 2400, 2000, 1600, 1200 and 800MHz levels, > supports C1, C2 and C3 idle C-states, plus throttling. So how can we use it: > P-states and throttling > Enabling powerd allows to effectively control CPU frequency/voltage > depending on CPU load. powerd on recent system can handle it quite > transparently. By default, frequency controlled via mix of EIST and > throttling technologies. First one controls both core frequency and > voltage, second - only core frequency. Both technologies give positive > power-saving effect. But effect of throttling is small and can be > completely hidden by using C2 state, that's why I recommend to disable > throttling control by adding to /boot/loader.conf: > hint.p4tcc.0.disabled=1 > hint.acpi_throttle.0.disabled=1 > In my case frequency/voltage control saves about 5W of idle power. > C-states > - C1 stops clock on some parts of CPU core during inactivity. It is > safe, cheap and supported by CPUs for ages. System uses C1 state by default. > - C2 state allows CPU to turn off all core clocks on idle. It is also > cheap, but requires correct ACPI-chipset-CPU interoperation to be used. > Use of C2 state can be enabled by adding to /etc/rc.conf: > performance_cx_lowest="C2" > economy_cx_lowest="C2" > Effect from this state is not so big when powerd is used, but still > noticeable, > - C3 state allows CPU completely stop all internal clocks, reduce > voltage and disconnect from system bus. This state gives additional > power saving effect, but it is not cheap and require trade-offs. > As soon as CPU is completely stopped in C3 state, local APIC timers in > each CPU core, used by FreeBSD as event sources on SMP, are not > functioning. It stops system time, breaks scheduling that makes system > close to dead. Did you try to see whether putting one of the cores in C3 state by doing something like dev.cpu.1.cx_lowest=C3 makes any difference? # sysctl dev.cpu | grep cx_usage dev.cpu.0.cx_usage: 0.00% 100.00% 0.00% dev.cpu.1.cx_usage: 0.00% 5.18% 94.81% -- Alexandre Kovalenko (????????? ?????????) From patttern at gmail.com Mon May 4 13:21:04 2009 From: patttern at gmail.com (Pattern) Date: Mon May 4 13:21:10 2009 Subject: ACPI on Toshiba A210 Message-ID: <107cc88f0905040621m215f877ak77a49e5b60e236a6@mail.gmail.com> Hi! I have a problem with ACPI on notebook Toshiba Sattelite A210-16f. At loading FreeBSD by default, the system does not detect hard disks. Through acpidump i have received a dsl-file. (dsdt_SB600.dsl) After considerable editing of a file, i have received a file without errors. (dsdt_SB600.diff) Result of operation iasl: [2:36 pattern@toshiba /root/acpica]# iasl dsdt_SB600_edit.dsl Intel ACPI Component Architecture ASL Optimizing Compiler version 20070320 [Mar 31 2009] Copyright (C) 2000 - 2007 Intel Corporation Supports ACPI Specification Revision 3.0a ASL Input: dsdt_SB600_edit.dsl - 7596 lines, 283835 bytes, 3271 keywords AML Output: /root/acpica/dsdt_SB600_edit.aml - 29374 bytes 873 named objects 2398 executable opcodes Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 9 Optimizations I have placed the aml-file received as a result of operation in /boot and have registered it in loader.conf. [2:36 pattern@toshiba /root/acpica]# less /boot/loader.conf acpi_dsdt_load="YES" acpi_dsdt_name="/boot/dsdt_SB600_edit.aml" After system reboot, hard disks as have not found out. In the console following errors are output. acpi0: om motherboard ACPI Error (evregion-0427): No handler for Region [ERAM] (0xc69cde80) [EmbeddedControl] [20070320] ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler [20070320] ACPI Error (psparse-0626): Method parse/execution failed [\_SB_.HTEV] (Node 0xc6897b60), AE_NOT_EXIST ACPI Error (psparse-0626): Method parse/execution failed [\_SB_.PCI0.LPC0.EC0_._REG] (Node 0xc69d6260), AE_NOT_EXIST acpi0: Could not initialise SystemIO handler: AE_NOT_EXIST ... unknown: can't assign resources (memory) unknown: can't assign resources (memory) unknown: can't assign resources (irq) unknown: can't assign resources (port) unknown: can't assign resources (memory) unknown: can't assign resources (memory) unknown: can't assign resources (memory) unknown: can't assign resources (irq) That the system has successfully booted it is required to apply the following file. (dsdt_SB600_addon.diff) (dsdt_SB600.dsl -> dsdt_SB600.diff -> dsdt_SB600_edit.dsl dsdt_SB600_edit.dsl -> dsdt_SB600_addon.diff -> dsdt_SB600_addon.dsl) BIOS of notebook is up-to-date Why it occurs and how it to fix? http://pma.8855.ru/files/dsdt_SB600.dsl http://pma.8855.ru/files/dsdt_SB600.diff http://pma.8855.ru/files/dsdt_SB600_addon.diff From oberman at es.net Mon May 4 15:10:02 2009 From: oberman at es.net (Kevin Oberman) Date: Mon May 4 15:10:08 2009 Subject: Fighting for the power. In-Reply-To: Your message of "Mon, 04 May 2009 15:24:27 +0300." <49FEDE7B.30804@FreeBSD.org> Message-ID: <20090504150959.67BE91CC50@ptavv.es.net> > Date: Mon, 04 May 2009 15:24:27 +0300 > From: Alexander Motin > Sender: owner-freebsd-mobile@freebsd.org > > Alexandre "Sunny" Kovalenko wrote: > > On Mon, 2009-05-04 at 01:18 +0300, Alexander Motin wrote: > >> - C3 state allows CPU completely stop all internal clocks, reduce > >> voltage and disconnect from system bus. This state gives additional > >> power saving effect, but it is not cheap and require trade-offs. > >> As soon as CPU is completely stopped in C3 state, local APIC timers in > >> each CPU core, used by FreeBSD as event sources on SMP, are not > >> functioning. It stops system time, breaks scheduling that makes system > >> close to dead. > > Did you try to see whether putting one of the cores in C3 state by doing > > something like > > > > dev.cpu.1.cx_lowest=C3 > > > > makes any difference? > > > > # sysctl dev.cpu | grep cx_usage > > dev.cpu.0.cx_usage: 0.00% 100.00% 0.00% > > dev.cpu.1.cx_usage: 0.00% 5.18% 94.81% > > I did. As soon as first CPU core is not in C3 state, second core unable > to enter C3 completely and disconnect from the bus, as cores are sharing > common resources. Such technique allows to avoid LAPIC timer problems, > but I haven't noticed any effect from this on CPU idle power. The only > difference I have noticed was in the case, when first core is busy. C3 > on second idle core then somehow reduces summary consumption a bit. > > In other words, C3 state should be active on both cores simultaneously > to give real effect. It is important to be aware that the presence of USB will keep a system from entering C3. Either build a kernel without USB and load it only whan needed or run 8-CURRENT with the USB2 stack which is purported to fix this problem. (I have no systems running CURRENT, so I can't confirm that USB2 fixes the problem.) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From jkim at FreeBSD.org Mon May 4 19:33:05 2009 From: jkim at FreeBSD.org (Jung-uk Kim) Date: Mon May 4 19:33:12 2009 Subject: ACPI on Toshiba A210 In-Reply-To: <107cc88f0905040621m215f877ak77a49e5b60e236a6@mail.gmail.com> References: <107cc88f0905040621m215f877ak77a49e5b60e236a6@mail.gmail.com> Message-ID: <200905041532.52001.jkim@FreeBSD.org> On Monday 04 May 2009 09:21 am, Pattern wrote: > Hi! > I have a problem with ACPI on notebook Toshiba Sattelite A210-16f. > At loading FreeBSD by default, the system does not detect hard > disks. Through acpidump i have received a dsl-file. > (dsdt_SB600.dsl) After considerable editing of a file, i have > received a file without errors. (dsdt_SB600.diff) > Result of operation iasl: > > [2:36 pattern@toshiba /root/acpica]# iasl dsdt_SB600_edit.dsl > Intel ACPI Component Architecture > ASL Optimizing Compiler version 20070320 [Mar 31 2009] > Copyright (C) 2000 - 2007 Intel Corporation > Supports ACPI Specification Revision 3.0a > ASL Input: dsdt_SB600_edit.dsl - 7596 lines, 283835 bytes, 3271 > keywords AML Output: /root/acpica/dsdt_SB600_edit.aml - 29374 bytes > 873 named objects 2398 executable opcodes > Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 9 > Optimizations > > I have placed the aml-file received as a result of operation in > /boot and have registered it in loader.conf. > > [2:36 pattern@toshiba /root/acpica]# less /boot/loader.conf > acpi_dsdt_load="YES" > acpi_dsdt_name="/boot/dsdt_SB600_edit.aml" > > After system reboot, hard disks as have not found out. In the > console following errors are output. > > acpi0: om motherboard > ACPI Error (evregion-0427): No handler for Region [ERAM] > (0xc69cde80) [EmbeddedControl] [20070320] > ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler > [20070320] > ACPI Error (psparse-0626): Method parse/execution failed > [\_SB_.HTEV] (Node 0xc6897b60), AE_NOT_EXIST > ACPI Error (psparse-0626): Method parse/execution failed > [\_SB_.PCI0.LPC0.EC0_._REG] (Node 0xc69d6260), AE_NOT_EXIST > acpi0: Could not initialise SystemIO handler: AE_NOT_EXIST > ... > unknown: can't assign resources (memory) > unknown: can't assign resources (memory) > unknown: can't assign resources (irq) > unknown: can't assign resources (port) > unknown: can't assign resources (memory) > unknown: can't assign resources (memory) > unknown: can't assign resources (memory) > unknown: can't assign resources (irq) > > That the system has successfully booted it is required to apply the > following file. (dsdt_SB600_addon.diff) > (dsdt_SB600.dsl -> dsdt_SB600.diff -> dsdt_SB600_edit.dsl > dsdt_SB600_edit.dsl -> dsdt_SB600_addon.diff -> > dsdt_SB600_addon.dsl) BIOS of notebook is up-to-date > Why it occurs and how it to fix? > > http://pma.8855.ru/files/dsdt_SB600.dsl > http://pma.8855.ru/files/dsdt_SB600.diff > http://pma.8855.ru/files/dsdt_SB600_addon.diff I think you commented out too much. ;-) Please try the attached patch for DSDT instead. Jung-uk Kim -------------- next part -------------- --- dsdt_SB600.dsl.orig 2009-05-04 15:04:08.000000000 -0400 +++ dsdt_SB600.dsl 2009-05-04 15:10:56.000000000 -0400 @@ -278,6 +278,11 @@ Notify (\_SB.PCI0, 0x00) \_SB.HSWK (Arg0) + Return (Package (0x02) + { + Zero, + Zero + }) } Scope (\_SB) @@ -1773,6 +1778,7 @@ Store (ATIB, \_SB.PCI0.LPC0.INFO) Store (Zero, \_SB.PCI0.LPC0.SMIC) Release (\_SB.PCI0.LPC0.PSMX) + Return (ATIB) } Method (AF07, 0, NotSerialized) @@ -1806,6 +1812,7 @@ Store (ATIB, \_SB.PCI0.LPC0.INFO) Store (Zero, \_SB.PCI0.LPC0.SMIC) Release (\_SB.PCI0.LPC0.PSMX) + Return (ATIB) } Method (AFN1, 1, Serialized) @@ -5810,7 +5817,7 @@ } OperationRegion (ECRM, EmbeddedControl, 0x00, 0xFF) - Field (ECRM, AnyAcc, Lock, Preserve) + Field (ECRM, ByteAcc, Lock, Preserve) { Offset (0x94), ERIB, 16, @@ -6906,6 +6913,7 @@ Store (ATIB, \_SB.PCI0.LPC0.INFO) Store (Zero, \_SB.PCI0.LPC0.SMIC) Release (\_SB.PCI0.LPC0.PSMX) + Return (ATIB) } Method (AF07, 0, NotSerialized) @@ -6939,6 +6947,7 @@ Store (ATIB, \_SB.PCI0.LPC0.INFO) Store (Zero, \_SB.PCI0.LPC0.SMIC) Release (\_SB.PCI0.LPC0.PSMX) + Return (ATIB) } Method (AFN1, 1, Serialized) From jkim at FreeBSD.org Mon May 4 19:51:33 2009 From: jkim at FreeBSD.org (Jung-uk Kim) Date: Mon May 4 19:51:40 2009 Subject: [Fwd: kern/134192: [patch] [acpi] don't probe acpi(4) children that are aliases of other nodes] In-Reply-To: <49FE2452.4000401@root.org> References: <49FE2452.4000401@root.org> Message-ID: <200905041551.19904.jkim@FreeBSD.org> On Sunday 03 May 2009 07:10 pm, Nate Lawson wrote: > Wonder what you thought of this patch to avoid Aliases in > AcpiWalkNamespace()? I believe it was fixed in the vendor source differently since ACPI-CA 20071019 if I am not mistaken: http://git.moblin.org/cgit.cgi/acpica/commit/?id=1e8f03866122dc06146879c9d4d4ad8bb408b60e Jung-uk Kim > -------- Original Message -------- > Subject: kern/134192: [patch] [acpi] don't probe acpi(4) children > that are aliases of other nodes > Resent-Date: Sun, 3 May 2009 19:50:01 GMT > Resent-From: FreeBSD-gnats-submit@freebsd.org (GNATS Filer) > Resent-To: freebsd-bugs@FreeBSD.org > Resent-CC: jkim@freebsd.org, njl@freebsd.org > Date: Sun, 3 May 2009 23:41:28 +0400 (MSD) > From: Eygene Ryabinkin > Reply-To: Eygene Ryabinkin > To: FreeBSD-gnats-submit@freebsd.org > > >Number: 134192 > >Category: kern > >Synopsis: [patch] [acpi] don't probe acpi(4) children that > > are aliases of other nodes Confidential: no > >Severity: serious > >Priority: medium > >Responsible: freebsd-bugs > >State: open > >Quarter: > >Keywords: > >Date-Required: > >Class: sw-bug > >Submitter-Id: current-users > >Arrival-Date: Sun May 03 19:50:00 UTC 2009 > >Closed-Date: > >Last-Modified: > >Originator: Eygene Ryabinkin > >Release: FreeBSD 7.1-STABLE amd64 > >Organization: > > Code Labs > > >Environment: > > System: FreeBSD 7.1-STABLE amd64 > > >Description: > > Some vendors (in my case, Asus) like to create aliases for node > names in the DSDT table: > ----- > Scope (_PR) > { > Processor (P001, 0x01, 0x00000810, 0x06) {} > Alias (P001, CPU1) > Processor (P002, 0x02, 0x00000000, 0x00) {} > Alias (P002, CPU2) > Processor (P003, 0x03, 0x00000000, 0x00) {} > Alias (P003, CPU3) > Processor (P004, 0x04, 0x00000000, 0x00) {} > Alias (P004, CPU4) > } > ----- > Another example (from Asus system too) is presented in the patch > below. > > Since AcpiWalkNamespace treats CPUX as the real Processor objects, > the probe order for acpi(4) bus children will be P001, CPU1, P002, > CPU2, P003, CPU3, P004, CPU4. This is very bad, because half of > processors are attached twice and half -- aren't attached at all. > Moreover, est (Enhanced SpeedStep cpufreq driver) isn't able to get > _PSS for CPUX, so P-states will be missing for half of processors. > > >How-To-Repeat: > > Insert Alias() instruction to your custom DSDT and try to use it, > enabling debug that will show what ACPI nodes are attached to cpuX > device nodes. > > >Fix: > > The following patch adds ACPI namespace walking procedure that > skips nodes that are results of the Alias() operator invocation. > This new method is used for probing of acpi(4) bus members. > > The patch works on two machines of mine that have these annoying > Alias() calls in the _PR namespace. > > I had tried this patch both on 7.x and 8-CURRENT. > > --- ACPI-attach-children-without-aliases.diff begins here --- > > >From f70d0d754f381735a67a42be91fa7253b19a5c8c Mon Sep 17 00:00:00 > > 2001 > > From: Eygene Ryabinkin > Date: Sun, 3 May 2009 22:00:20 +0400 > > ...and use this function to probe acpi(4) children. > > The rationale is very simple: some BIOS vendors, in my case it was > Asus, like to create aliased nodes in the namespaces that will be > walked by the acpi bus method that attaches children to the bus. > > In my particular case, the problem lied in the Processor objects: > ----- > Scope (_PR) > { > Processor (P001, 0x01, 0x00000810, 0x06) {} > Alias (P001, CPU1) > } > > Scope (_PR) > { > Processor (P002, 0x02, 0x00000810, 0x06) {} > Alias (P002, CPU2) > } > ----- > The thing is that the simple walk routine treated CPU1 and CPU2 as > real processors and order of attachment was P001, CPU1, P002, CPU2. > Thus, the second CPU was never attached, first was attached twice > and est (Enhanced SpeedStep cpufreq(4) driver) was failing to get > _PSS (processor P-states) from the CPU1. > > I greatly doubt that some real devices will be ever created as > aliases, since they should be real objects and not modified copies > of other device instances. And since ASL Alias() semantics is to > provide pseudonym, this modification should be "The Good Thing > (tm)". > > Signed-off-by: Eygene Ryabinkin > --- > sys/contrib/dev/acpica/aclocal.h | 1 + > sys/contrib/dev/acpica/acnamesp.h | 1 + > sys/contrib/dev/acpica/acpixf.h | 9 +++++ > sys/contrib/dev/acpica/excreate.c | 3 ++ > sys/contrib/dev/acpica/nswalk.c | 10 ++++- > sys/contrib/dev/acpica/nsxfeval.c | 69 > ++++++++++++++++++++++++++++++++++--- > sys/dev/acpica/acpi.c | 18 +++++---- > 7 files changed, 96 insertions(+), 15 deletions(-) > > diff --git a/sys/contrib/dev/acpica/aclocal.h > b/sys/contrib/dev/acpica/aclocal.h > index ba1145e..73e1568 100644 > --- a/sys/contrib/dev/acpica/aclocal.h > +++ b/sys/contrib/dev/acpica/aclocal.h > @@ -301,6 +301,7 @@ typedef struct acpi_namespace_node > #define ANOBJ_METHOD_ARG 0x04 /* Node is a > method argument */ > #define ANOBJ_METHOD_LOCAL 0x08 /* Node is a > method local */ > #define ANOBJ_SUBTREE_HAS_INI 0x10 /* Used to > optimize device initialization */ > +#define ANOBJ_IS_ALIAS 0x20 /* Node is an > alias to another one */ > > #define ANOBJ_IS_EXTERNAL 0x08 /* iASL only: This > object created via External() */ > #define ANOBJ_METHOD_NO_RETVAL 0x10 /* iASL only: > Method has no return value */ > diff --git a/sys/contrib/dev/acpica/acnamesp.h > b/sys/contrib/dev/acpica/acnamesp.h > index 8d07fb3..52a50bb 100644 > --- a/sys/contrib/dev/acpica/acnamesp.h > +++ b/sys/contrib/dev/acpica/acnamesp.h > @@ -146,6 +146,7 @@ > #define ACPI_NS_WALK_NO_UNLOCK 0 > #define ACPI_NS_WALK_UNLOCK 0x01 > #define ACPI_NS_WALK_TEMP_NODES 0x02 > +#define ACPI_NS_WALK_SKIP_ALIASES 0x04 > > > /* > diff --git a/sys/contrib/dev/acpica/acpixf.h > b/sys/contrib/dev/acpica/acpixf.h > index f85fd67..3757ad0 100644 > --- a/sys/contrib/dev/acpica/acpixf.h > +++ b/sys/contrib/dev/acpica/acpixf.h > @@ -238,6 +238,15 @@ AcpiWalkNamespace ( > void **ReturnValue); > > ACPI_STATUS > +AcpiWalkNamespaceNoAliases ( > + ACPI_OBJECT_TYPE Type, > + ACPI_HANDLE StartObject, > + UINT32 MaxDepth, > + ACPI_WALK_CALLBACK UserFunction, > + void *Context, > + void **ReturnValue); > + > +ACPI_STATUS > AcpiGetDevices ( > char *HID, > ACPI_WALK_CALLBACK UserFunction, > diff --git a/sys/contrib/dev/acpica/excreate.c > b/sys/contrib/dev/acpica/excreate.c > index d237dab..dba8312 100644 > --- a/sys/contrib/dev/acpica/excreate.c > +++ b/sys/contrib/dev/acpica/excreate.c > @@ -221,6 +221,9 @@ AcpiExCreateAlias ( > break; > } > > + /* Mark object as alias, so alias creation could be detected > */ + AliasNode->Flags |= ANOBJ_IS_ALIAS; > + > /* Since both operands are Nodes, we don't need to delete them > */ > > return_ACPI_STATUS (Status); > diff --git a/sys/contrib/dev/acpica/nswalk.c > b/sys/contrib/dev/acpica/nswalk.c > index a3ac86c..9cbc56d 100644 > --- a/sys/contrib/dev/acpica/nswalk.c > +++ b/sys/contrib/dev/acpica/nswalk.c > @@ -208,8 +208,7 @@ AcpiNsGetNextNode ( > * PARAMETERS: Type - ACPI_OBJECT_TYPE to search > for * StartNode - Handle in namespace where > search begins > * MaxDepth - Depth to which search is to > reach - * Flags - Whether to unlock the > NS before invoking > - * the callback routine > + * Flags - Flags that modify walk > parameters * UserFunction - Called when an > object of "Type" is found > * Context - Passed to user function > * ReturnValue - from the UserFunction if > terminated early. > @@ -300,6 +299,13 @@ AcpiNsWalkNamespace ( > Status = AE_CTRL_DEPTH; > } > > + /* Skip nodes created by Alias() routines if it was > requested */ > + else if ((ChildNode->Flags & ANOBJ_IS_ALIAS) && > + (Flags & ACPI_NS_WALK_SKIP_ALIASES)) > + { > + Status = AE_CTRL_DEPTH; > + } > + > /* Type must match requested type */ > > else if (ChildType == Type) > diff --git a/sys/contrib/dev/acpica/nsxfeval.c > b/sys/contrib/dev/acpica/nsxfeval.c > index 617002c..662a9df 100644 > --- a/sys/contrib/dev/acpica/nsxfeval.c > +++ b/sys/contrib/dev/acpica/nsxfeval.c > @@ -122,6 +122,16 @@ > #include > #include > > +static ACPI_STATUS > +_AcpiWalkNamespace ( > + ACPI_OBJECT_TYPE Type, > + ACPI_HANDLE StartObject, > + UINT32 MaxDepth, > + ACPI_WALK_CALLBACK UserFunction, > + void *Context, > + void **ReturnValue, > + UINT32 AddFlags); > + > > #define _COMPONENT ACPI_NAMESPACE > ACPI_MODULE_NAME ("nsxfeval") > @@ -491,11 +501,62 @@ AcpiWalkNamespace ( > void *Context, > void **ReturnValue) > { > - ACPI_STATUS Status; > + ACPI_FUNCTION_TRACE (AcpiWalkNamespace); > > + return _AcpiWalkNamespace(Type, StartObject, MaxDepth, > + UserFunction, Context, ReturnValue, 0); > +} > > - ACPI_FUNCTION_TRACE (AcpiWalkNamespace); > +ACPI_EXPORT_SYMBOL (AcpiWalkNamespace) > > +/***************************************************************** >************** + * > + * FUNCTION: AcpiWalkNamespaceNoAliases > + * > + * DESCRIPTION: The same as AcpiWalkNamespace, but skips nodes > that were + * created as the result of an Alias > function. + * > + * NOTE: for parameters/semantics see AcpiWalkNamespace. > + * > + > ******************************************************************* >***********/ + > +ACPI_STATUS > +AcpiWalkNamespaceNoAliases ( > + ACPI_OBJECT_TYPE Type, > + ACPI_HANDLE StartObject, > + UINT32 MaxDepth, > + ACPI_WALK_CALLBACK UserFunction, > + void *Context, > + void **ReturnValue) > +{ > + ACPI_FUNCTION_TRACE (AcpiWalkNamespaceNoAliases); > + > + return _AcpiWalkNamespace(Type, StartObject, MaxDepth, > + UserFunction, Context, ReturnValue, > ACPI_NS_WALK_SKIP_ALIASES); +} > + > +ACPI_EXPORT_SYMBOL (AcpiWalkNamespaceNoAliases) > + > +/***************************************************************** >************** + * > + * FUNCTION: _AcpiWalkNamespace > + * > + * DESCRIPTION: Internal helper for AcpiWalkNamespace and > + * AcpiWalkNamespaceNoAliases. > + * > + > ******************************************************************* >***********/ + > +static ACPI_STATUS > +_AcpiWalkNamespace ( > + ACPI_OBJECT_TYPE Type, > + ACPI_HANDLE StartObject, > + UINT32 MaxDepth, > + ACPI_WALK_CALLBACK UserFunction, > + void *Context, > + void **ReturnValue, > + UINT32 AddFlags) > +{ > + ACPI_STATUS Status; > > /* Parameter validation */ > > @@ -519,15 +580,13 @@ AcpiWalkNamespace ( > } > > Status = AcpiNsWalkNamespace (Type, StartObject, MaxDepth, > - ACPI_NS_WALK_UNLOCK, > + AddFlags | ACPI_NS_WALK_UNLOCK, > UserFunction, Context, ReturnValue); > > (void) AcpiUtReleaseMutex (ACPI_MTX_NAMESPACE); > return_ACPI_STATUS (Status); > } > > -ACPI_EXPORT_SYMBOL (AcpiWalkNamespace) > - > > > /****************************************************************** >************* * > diff --git a/sys/dev/acpica/acpi.c b/sys/dev/acpica/acpi.c > index d79b413..18a9800 100644 > --- a/sys/dev/acpica/acpi.c > +++ b/sys/dev/acpica/acpi.c > @@ -1528,7 +1528,7 @@ acpi_device_scan_children(device_t bus, > device_t dev, int max_depth, > ctx.user_fn = user_fn; > ctx.arg = arg; > ctx.parent = h; > - return (AcpiWalkNamespace(ACPI_TYPE_ANY, h, max_depth, > + return (AcpiWalkNamespaceNoAliases(ACPI_TYPE_ANY, h, > max_depth, acpi_device_scan_cb, &ctx, NULL)); > } > > @@ -1648,14 +1648,16 @@ acpi_probe_children(device_t bus) > * Scan the namespace and insert placeholders for all the > devices that * we find. We also probe/attach any early devices. > * > - * Note that we use AcpiWalkNamespace rather than > AcpiGetDevices because > - * we want to create nodes for all devices, not just those > that are - * currently present. (This assumes that we don't > want to create/remove - * devices as they appear, which might > be smarter.) > + * Note that we use AcpiWalkNamespaceNoAliases rather than > + * AcpiGetDevices because we want to create nodes for all > devices, + * not just those that are currently present. (This > assumes that we + * don't want to create/remove devices as they > appear, which might + * be smarter.) We avoid counting aliased > nodes, because we generally + * want to attach only to a > "genuine" devices. > */ > ACPI_DEBUG_PRINT((ACPI_DB_OBJECTS, "namespace scan\n")); > - AcpiWalkNamespace(ACPI_TYPE_ANY, ACPI_ROOT_OBJECT, 100, > acpi_probe_child, > - bus, NULL); > + AcpiWalkNamespaceNoAliases(ACPI_TYPE_ANY, ACPI_ROOT_OBJECT, > 100, + acpi_probe_child, bus, NULL); > > /* Pre-allocate resources for our rman from any sysresource > devices. */ acpi_sysres_alloc(bus); > @@ -2794,7 +2796,7 @@ acpi_wake_prep_walk(int sstate) > ACPI_HANDLE sb_handle; > > if (ACPI_SUCCESS(AcpiGetHandle(ACPI_ROOT_OBJECT, "\\_SB_", > &sb_handle))) > - AcpiWalkNamespace(ACPI_TYPE_DEVICE, sb_handle, 100, > + AcpiWalkNamespaceNoAliases(ACPI_TYPE_DEVICE, sb_handle, 100, > acpi_wake_prep, &sstate, NULL); > return (0); > } > -- > 1.6.2.4 > --- ACPI-attach-children-without-aliases.diff ends here --- > > >Release-Note: > >Audit-Trail: > >Unformatted: From ivakras1 at gmail.com Mon May 4 21:26:12 2009 From: ivakras1 at gmail.com (Dmitry Kolosov) Date: Mon May 4 21:26:18 2009 Subject: Fighting for the power. In-Reply-To: <49FE64C5.2020507@FreeBSD.org> References: <49FE1826.4060000@FreeBSD.org> <20090504011421.GI6901@egr.msu.edu> <49FE64C5.2020507@FreeBSD.org> Message-ID: <200905050100.00739.ivakras1@gmail.com> On ??????????? 04 ??? 2009 07:45:09 Alexander Motin wrote: > Adam McDougall wrote: > > On Mon, May 04, 2009 at 01:18:14AM +0300, Alexander Motin wrote: > > > > I would like to summarize some of my knowledge on reducing FreeBSD power > > consumption and describe some new things I have recently implemented in > > 8-CURRENT. The main character of this story is my 12" Acer TravelMate > > 6292 laptop with C2D T7700 2.4GHz CPU, 965GM chipset and SATA HDD, under > > amd64 8-CURRENT. > > > > Great list! May I suggest screen brightness and DPMS as another tool > > to save power, I've measured a 5W difference from the screen draw. > > Keeping the brightness as low as tolerable helps considerably, but > > also using 'xset dpms 120 120 120' (modify to taste) in .xinitrc to > > turn off the screen after 2 minutes helps when the laptop isn't being > > used every second. May need this in xorg.conf: > > Option "dpms" > > Yes, backlight is also important. But there is not so much things could > be done. > > When I am leaving system for some time, I can just close the lid, if not > put system into S3 state, which require very small power (at least I was > unable to really measure it without all-day-long testing). Thanks to > jkim@ we have more or less working S3 state for amd64 now. > I'm using sysctl to controll brightness of my lcd (wrongly marked as crt by sysctl, but it works fine): hw.acpi.video.crt1.brightness: 95 - current brightness of lcd (crt) hw.acpi.video.crt1.fullpower: 95 - top level of brightness set by acpi_video if AC plugged hw.acpi.video.crt1.economy: 43 - bottom level of brightness set by acpi_video if AC unplugged hw.acpi.video.crt1.levels: 95 43 20 24 28 32 37 43 50 59 69 81 95 - various brightness levels can be set manual by sysctl It works fine for me, and it's easy to write a script to react on different events during a day. From patttern at gmail.com Tue May 5 07:27:23 2009 From: patttern at gmail.com (Pattern) Date: Tue May 5 07:27:30 2009 Subject: ACPI on Toshiba A210 In-Reply-To: <200905041532.52001.jkim@FreeBSD.org> References: <107cc88f0905040621m215f877ak77a49e5b60e236a6@mail.gmail.com> <200905041532.52001.jkim@FreeBSD.org> Message-ID: <107cc88f0905050027t32a1d1fegf94882b0e0d5e9b1@mail.gmail.com> 2009/5/4 Jung-uk Kim > On Monday 04 May 2009 09:21 am, Pattern wrote: > > Hi! > > I have a problem with ACPI on notebook Toshiba Sattelite A210-16f. > > At loading FreeBSD by default, the system does not detect hard > > disks. Through acpidump i have received a dsl-file. > > (dsdt_SB600.dsl) After considerable editing of a file, i have > > received a file without errors. (dsdt_SB600.diff) > > Result of operation iasl: > > > > [2:36 pattern@toshiba /root/acpica]# iasl dsdt_SB600_edit.dsl > > Intel ACPI Component Architecture > > ASL Optimizing Compiler version 20070320 [Mar 31 2009] > > Copyright (C) 2000 - 2007 Intel Corporation > > Supports ACPI Specification Revision 3.0a > > ASL Input: dsdt_SB600_edit.dsl - 7596 lines, 283835 bytes, 3271 > > keywords AML Output: /root/acpica/dsdt_SB600_edit.aml - 29374 bytes > > 873 named objects 2398 executable opcodes > > Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 9 > > Optimizations > > > > I have placed the aml-file received as a result of operation in > > /boot and have registered it in loader.conf. > > > > [2:36 pattern@toshiba /root/acpica]# less /boot/loader.conf > > acpi_dsdt_load="YES" > > acpi_dsdt_name="/boot/dsdt_SB600_edit.aml" > > > > After system reboot, hard disks as have not found out. In the > > console following errors are output. > > > > acpi0: om motherboard > > ACPI Error (evregion-0427): No handler for Region [ERAM] > > (0xc69cde80) [EmbeddedControl] [20070320] > > ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler > > [20070320] > > ACPI Error (psparse-0626): Method parse/execution failed > > [\_SB_.HTEV] (Node 0xc6897b60), AE_NOT_EXIST > > ACPI Error (psparse-0626): Method parse/execution failed > > [\_SB_.PCI0.LPC0.EC0_._REG] (Node 0xc69d6260), AE_NOT_EXIST > > acpi0: Could not initialise SystemIO handler: AE_NOT_EXIST > > ... > > unknown: can't assign resources (memory) > > unknown: can't assign resources (memory) > > unknown: can't assign resources (irq) > > unknown: can't assign resources (port) > > unknown: can't assign resources (memory) > > unknown: can't assign resources (memory) > > unknown: can't assign resources (memory) > > unknown: can't assign resources (irq) > > > > That the system has successfully booted it is required to apply the > > following file. (dsdt_SB600_addon.diff) > > (dsdt_SB600.dsl -> dsdt_SB600.diff -> dsdt_SB600_edit.dsl > > dsdt_SB600_edit.dsl -> dsdt_SB600_addon.diff -> > > dsdt_SB600_addon.dsl) BIOS of notebook is up-to-date > > Why it occurs and how it to fix? > > > > http://pma.8855.ru/files/dsdt_SB600.dsl > > http://pma.8855.ru/files/dsdt_SB600.diff > > http://pma.8855.ru/files/dsdt_SB600_addon.diff > > I think you commented out too much. ;-) Please try the attached patch > for DSDT instead. > > Jung-uk Kim > Thanks for your answer. Patch (dsdt_SB600.diff ) is corrected with optimisation and in it changes which you have specified already contain. But these minimum changes don't troubleshoot ACPI, but only allow to load system with ACPI. It was possible to load system in a mode "ACPI disabled" and not to do any changes. But i wish to make working support ACPI on a notebook. In fact, the first patch after compilation does not contain any error (!!!), but nevertheless the system does not boot. And if to apply patch dsdt_SB600_addon.diff or comment a code below, only after that the system boots. Method (_REG, 2, NotSerialized) { If (LEqual (Arg0, 0x03)) { Store (Arg1, Z00B) } \_SB.HTEV (0x02) } This code as that influences initialization EmbeddedControl. However, even without this code, sometimes in the console the error on EmbeddedControl drops out, but the system successfully boots. What such problem can be linked? From peterjeremy at optushome.com.au Tue May 5 09:30:36 2009 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Tue May 5 09:30:48 2009 Subject: Fighting for the power. In-Reply-To: <49FE5EC8.3040205@FreeBSD.org> References: <49FE1826.4060000@FreeBSD.org> <49FE29A4.30507@root.org> <49FE5EC8.3040205@FreeBSD.org> Message-ID: <20090505091914.GA94521@server.vk2pj.dyndns.org> On 2009-May-04 06:19:36 +0300, Alexander Motin wrote: >System will always have tons of waiting callouts and timeouts to be >handled. So timer will be always needed. Working timer. Yes, but a tickless kernel will let the CPU stay asleep for longer since it doesn't need to wake up just to discover there's nothing to do. >number of idle disk write activity, but I haven't very succeeded. Even >in my quite simple icewm X environment something was persistently >writing something every several minutes. I have found and disabled some >activity sources, but it was not enough. I've recently (in the last few days) worked through minimising the write activity on the SSD in my laptop (I wrote a tool that monitors write transfers via devstat(3) and it would be possible to track down the actual modified files via kqueue(2) if necessary). I'm now down to about two chunks of about 13 transfers each per hour (due to entopy saving and ntp.drift updating). The changes I made were: 1) Mount the SSD filesystems as noatime 2) Turn off all local syslogging (syslog is directed to another system when my laptop is at home, lost otherwise). 3) Change maillog rotation to size instead of daily 4) Run save-entropy once per hour instead of every 11 minutes. 5) Patch the save-entropy script to reduce the write load when it's run (see PR bin/134225). 6) Use a swap-back /tmp By default, ntpd updates ntp.drift every hour. I might do some monitoring and see if the drift changes significantly over time. If it doesn't, hard-wiring the ntp.drift file will save some writes. (The other option would be to tweak the relevant timecounter until the actual drift is 0 and then stop ntpd and just run something like ntpdate regularly to compensate for the remaining drift). Experimentation shows that firefox3 generates a fairly heavy write load - continuously updating several internal databases whilst it is in use. Turning off the "Block reported attack sites" and "Block reported web forgeries" options under 'Security' stops it updating urlclassifier3.sqlite. Note that when you update a file, you implicitly update the associated inode and the filesystem superbock. > What would happen in some >complicated KDE/Gnome environment I am just afraid to think. I'd recommend avoiding a heavyweight window manager and using something like fwvm or vtwm. -- Peter Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-acpi/attachments/20090505/6bdcadd5/attachment.pgp From avg at icyb.net.ua Tue May 5 16:45:48 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Tue May 5 16:46:01 2009 Subject: Garbled output from kgdb? In-Reply-To: <200905011501.40083.jhb@freebsd.org> References: <49F8B859.7060908@umn.edu> <200905010947.54855.jhb@freebsd.org> <49FB2847.406@umn.edu> <200905011501.40083.jhb@freebsd.org> Message-ID: <4A006D38.50901@icyb.net.ua> on 01/05/2009 22:01 John Baldwin said the following: > The trace actually ends here. There is nothing super bad here but there is a > big problem actually in that the idle threads cannot block on a lock, so it is > a problem for the ACPI code to be acquiring a mutex here. Perhaps the locks > protecting the idle registers need to use spin locks instead. The problem with > blocking in the idle thread is that the scheduler assumes (even requires) that > the idle thread is _always_ runnable. Very interesting! So it seems that we are not having more of such crashes by a pure luck (low probability)? Looking at the method's signature: ACPI_NATIVE_UINT AcpiOsAcquireLock (ACPI_SPINLOCK Handle) I think that the name of the parameter type is a big hint. Further, looking into ACPICA reference document: > Wait for and acquire a spin lock. May be called from interrupt handlers, GPE > handlers, and Fixed event handlers. Single threaded OSL implementations should > always return AE_OK for this interface. P.S. the comment before AcpiOsAcquireLock function (in stable/7 code) seems to be outdated/bogus too - first of all there is no Flags parameter (it's actualy a return value "to be used when lock is released") and, second, having ithreads is no excuse to not care about type of blocking, and the term 'blocking' is used incorrectly too: /* * The Flags parameter seems to state whether or not caller is an ISR * (and thus can't block) but since we have ithreads, we don't worry * about potentially blocking. */ -- Andriy Gapon From avg at icyb.net.ua Tue May 5 16:51:43 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Tue May 5 16:51:49 2009 Subject: Garbled output from kgdb? In-Reply-To: <4A006D38.50901@icyb.net.ua> References: <49F8B859.7060908@umn.edu> <200905010947.54855.jhb@freebsd.org> <49FB2847.406@umn.edu> <200905011501.40083.jhb@freebsd.org> <4A006D38.50901@icyb.net.ua> Message-ID: <4A006E9A.7060806@icyb.net.ua> BTW, this issue seems to be fixed in Jung-uk's acpi patches for newer acpica imports, but it is not fixed both in stable/7 and head. on 05/05/2009 19:45 Andriy Gapon said the following: > on 01/05/2009 22:01 John Baldwin said the following: >> The trace actually ends here. There is nothing super bad here but there is a >> big problem actually in that the idle threads cannot block on a lock, so it is >> a problem for the ACPI code to be acquiring a mutex here. Perhaps the locks >> protecting the idle registers need to use spin locks instead. The problem with >> blocking in the idle thread is that the scheduler assumes (even requires) that >> the idle thread is _always_ runnable. > > > Very interesting! So it seems that we are not having more of such crashes by a > pure luck (low probability)? > > Looking at the method's signature: > ACPI_NATIVE_UINT AcpiOsAcquireLock (ACPI_SPINLOCK Handle) > I think that the name of the parameter type is a big hint. > > Further, looking into ACPICA reference document: >> Wait for and acquire a spin lock. May be called from interrupt handlers, GPE >> handlers, and Fixed event handlers. Single threaded OSL implementations should >> always return AE_OK for this interface. > > P.S. the comment before AcpiOsAcquireLock function (in stable/7 code) seems to be > outdated/bogus too - first of all there is no Flags parameter (it's actualy a > return value "to be used when lock is released") and, second, having ithreads is > no excuse to not care about type of blocking, and the term 'blocking' is used > incorrectly too: > /* > * The Flags parameter seems to state whether or not caller is an ISR > * (and thus can't block) but since we have ithreads, we don't worry > * about potentially blocking. > */ > > -- Andriy Gapon From jkim at FreeBSD.org Tue May 5 20:09:47 2009 From: jkim at FreeBSD.org (Jung-uk Kim) Date: Tue May 5 20:09:53 2009 Subject: Garbled output from kgdb? In-Reply-To: <4A006E9A.7060806@icyb.net.ua> References: <49F8B859.7060908@umn.edu> <4A006D38.50901@icyb.net.ua> <4A006E9A.7060806@icyb.net.ua> Message-ID: <200905051609.38689.jkim@FreeBSD.org> On Tuesday 05 May 2009 12:51 pm, Andriy Gapon wrote: > BTW, this issue seems to be fixed in Jung-uk's acpi patches for > newer acpica imports, but it is not fixed both in stable/7 and > head. Yes, it was fixed in my patchsets long ago, which uses spin lock for AcpiOsAcquireLock(). :-) Jung-uk Kim > on 05/05/2009 19:45 Andriy Gapon said the following: > > on 01/05/2009 22:01 John Baldwin said the following: > >> The trace actually ends here. There is nothing super bad here > >> but there is a big problem actually in that the idle threads > >> cannot block on a lock, so it is a problem for the ACPI code to > >> be acquiring a mutex here. Perhaps the locks protecting the > >> idle registers need to use spin locks instead. The problem with > >> blocking in the idle thread is that the scheduler assumes (even > >> requires) that the idle thread is _always_ runnable. > > > > Very interesting! So it seems that we are not having more of such > > crashes by a pure luck (low probability)? > > > > Looking at the method's signature: > > ACPI_NATIVE_UINT AcpiOsAcquireLock (ACPI_SPINLOCK Handle) > > I think that the name of the parameter type is a big hint. > > > > Further, looking into ACPICA reference document: > >> Wait for and acquire a spin lock. May be called from interrupt > >> handlers, GPE handlers, and Fixed event handlers. Single > >> threaded OSL implementations should always return AE_OK for this > >> interface. > > > > P.S. the comment before AcpiOsAcquireLock function (in stable/7 > > code) seems to be outdated/bogus too - first of all there is no > > Flags parameter (it's actualy a return value "to be used when > > lock is released") and, second, having ithreads is no excuse to > > not care about type of blocking, and the term 'blocking' is used > > incorrectly too: > > /* > > * The Flags parameter seems to state whether or not caller is an > > ISR * (and thus can't block) but since we have ithreads, we don't > > worry * about potentially blocking. > > */ From jhb at FreeBSD.org Tue May 5 20:23:31 2009 From: jhb at FreeBSD.org (John Baldwin) Date: Tue May 5 20:24:15 2009 Subject: Garbled output from kgdb? In-Reply-To: <200905051609.38689.jkim@FreeBSD.org> References: <49F8B859.7060908@umn.edu> <4A006D38.50901@icyb.net.ua> <4A006E9A.7060806@icyb.net.ua> <200905051609.38689.jkim@FreeBSD.org> Message-ID: <4A00A042.20806@FreeBSD.org> Jung-uk Kim wrote: > On Tuesday 05 May 2009 12:51 pm, Andriy Gapon wrote: >> BTW, this issue seems to be fixed in Jung-uk's acpi patches for >> newer acpica imports, but it is not fixed both in stable/7 and >> head. > > Yes, it was fixed in my patchsets long ago, which uses spin lock for > AcpiOsAcquireLock(). :-) I'm not sure all ACPI locks need to be spin locks, but any locks used by the idle code must be spin locks. Regardless, are you going to import a newer ACPI-CA and commit your patches soon? It sounds like several things are fixed in the outstanding patches by now including both this and the problem with the Alias() operator. > Jung-uk Kim > >> on 05/05/2009 19:45 Andriy Gapon said the following: >>> on 01/05/2009 22:01 John Baldwin said the following: >>>> The trace actually ends here. There is nothing super bad here >>>> but there is a big problem actually in that the idle threads >>>> cannot block on a lock, so it is a problem for the ACPI code to >>>> be acquiring a mutex here. Perhaps the locks protecting the >>>> idle registers need to use spin locks instead. The problem with >>>> blocking in the idle thread is that the scheduler assumes (even >>>> requires) that the idle thread is _always_ runnable. >>> Very interesting! So it seems that we are not having more of such >>> crashes by a pure luck (low probability)? >>> >>> Looking at the method's signature: >>> ACPI_NATIVE_UINT AcpiOsAcquireLock (ACPI_SPINLOCK Handle) >>> I think that the name of the parameter type is a big hint. >>> >>> Further, looking into ACPICA reference document: >>>> Wait for and acquire a spin lock. May be called from interrupt >>>> handlers, GPE handlers, and Fixed event handlers. Single >>>> threaded OSL implementations should always return AE_OK for this >>>> interface. >>> P.S. the comment before AcpiOsAcquireLock function (in stable/7 >>> code) seems to be outdated/bogus too - first of all there is no >>> Flags parameter (it's actualy a return value "to be used when >>> lock is released") and, second, having ithreads is no excuse to >>> not care about type of blocking, and the term 'blocking' is used >>> incorrectly too: >>> /* >>> * The Flags parameter seems to state whether or not caller is an >>> ISR * (and thus can't block) but since we have ithreads, we don't >>> worry * about potentially blocking. >>> */ -- John Baldwin From jkim at FreeBSD.org Tue May 5 20:56:35 2009 From: jkim at FreeBSD.org (Jung-uk Kim) Date: Tue May 5 20:56:42 2009 Subject: Garbled output from kgdb? In-Reply-To: <4A00A042.20806@FreeBSD.org> References: <49F8B859.7060908@umn.edu> <200905051609.38689.jkim@FreeBSD.org> <4A00A042.20806@FreeBSD.org> Message-ID: <200905051656.27439.jkim@FreeBSD.org> On Tuesday 05 May 2009 04:23 pm, John Baldwin wrote: > Jung-uk Kim wrote: > > On Tuesday 05 May 2009 12:51 pm, Andriy Gapon wrote: > >> BTW, this issue seems to be fixed in Jung-uk's acpi patches for > >> newer acpica imports, but it is not fixed both in stable/7 and > >> head. > > > > Yes, it was fixed in my patchsets long ago, which uses spin lock > > for AcpiOsAcquireLock(). :-) > > I'm not sure all ACPI locks need to be spin locks, but any locks > used by the idle code must be spin locks. There are several types of ACPI locks internally and externally. The AcpiOs{Create,Acquire,Release}Lock() is just one of them, which is a spin lock and it is mostly used for interrupt handlers, e.g., GPE and HW. I have to say there were a lot of confusions between ACPI developers because it was not well-documented. In fact, I personally had to exchange lengthy e-mails with Intel engineers to understand the meaning of these myself. Now Intel has documented everything you need to know about ACPI-CA for OS developers: http://git.moblin.org/cgit.cgi/acpica/tree/documents > Regardless, are you going to import a newer ACPI-CA and commit your > patches soon? It sounds like several things are fixed in the > outstanding patches by now including both this and the problem with > the Alias() operator. Unfortunately, I don't have much time to work on it recently. Couple of developers volunteered to do the actual import work although I haven't heard from them in a while. :-( Jung-uk Kim From jkim at FreeBSD.org Tue May 5 21:43:12 2009 From: jkim at FreeBSD.org (Jung-uk Kim) Date: Tue May 5 21:43:25 2009 Subject: Garbled output from kgdb? In-Reply-To: <200905051609.38689.jkim@FreeBSD.org> References: <49F8B859.7060908@umn.edu> <4A006E9A.7060806@icyb.net.ua> <200905051609.38689.jkim@FreeBSD.org> Message-ID: <200905051743.03520.jkim@FreeBSD.org> On Tuesday 05 May 2009 04:09 pm, Jung-uk Kim wrote: > On Tuesday 05 May 2009 12:51 pm, Andriy Gapon wrote: > > BTW, this issue seems to be fixed in Jung-uk's acpi patches for > > newer acpica imports, but it is not fixed both in stable/7 and > > head. > > Yes, it was fixed in my patchsets long ago, which uses spin lock > for AcpiOsAcquireLock(). :-) The attached patch is for -STABLE. Note that it is only compile tested on amd64. Jung-uk Kim -------------- next part -------------- --- sys/dev/acpica/Osd/OsdSynch.c (revision 191834) +++ sys/dev/acpica/Osd/OsdSynch.c (working copy) @@ -1,6 +1,7 @@ /*- * Copyright (c) 2000 Michael Smith * Copyright (c) 2000 BSDi + * Copyright (c) 2007-2009 Jung-uk Kim * All rights reserved. * * Redistribution and use in source and binary forms, with or without @@ -35,365 +36,313 @@ #include #include "opt_acpi.h" +#include #include -#include -#include #include +#include #include +#include -#define _COMPONENT ACPI_OS_SERVICES +#define _COMPONENT ACPI_OS_SERVICES ACPI_MODULE_NAME("SYNCH") MALLOC_DEFINE(M_ACPISEM, "acpisem", "ACPI semaphore"); -#define AS_LOCK(as) mtx_lock(&(as)->as_mtx) -#define AS_UNLOCK(as) mtx_unlock(&(as)->as_mtx) +/* Convert microseconds to hz. */ +static int +timeout2hz(long timo) +{ + struct timeval tv; + tv.tv_sec = timo / 1000000; + tv.tv_usec = timo % 1000000; + + return (tvtohz(&tv)); +} + +/* Adjust timeout from the previous uptime. */ +static long +adjust_timeout(long *tmop, struct timeval *tvp) +{ + struct timeval now, slept; + + getmicrouptime(&now); + slept = now; + timevalsub(&slept, tvp); + *tmop -= slept.tv_sec * 1000000 + slept.tv_usec; + *tvp = now; + + return (*tmop); +} + /* - * Simple counting semaphore implemented using a mutex. (Subsequently used - * in the OSI code to implement a mutex. Go figure.) + * ACPI_SEMAPHORE: a sleepable counting semaphore */ struct acpi_semaphore { - struct mtx as_mtx; - UINT32 as_units; - UINT32 as_maxunits; - UINT32 as_pendings; - UINT32 as_resetting; - UINT32 as_timeouts; + struct sx as_lock; + char as_name[32]; + struct cv as_cv; + UINT32 as_units; + UINT32 as_maxunits; }; -/* Default number of maximum pending threads. */ -#ifndef ACPI_NO_SEMAPHORES -#ifndef ACPI_SEMAPHORES_MAX_PENDING -#define ACPI_SEMAPHORES_MAX_PENDING 4 -#endif - -static int acpi_semaphore_debug = 0; -TUNABLE_INT("debug.acpi_semaphore_debug", &acpi_semaphore_debug); -SYSCTL_DECL(_debug_acpi); -SYSCTL_INT(_debug_acpi, OID_AUTO, semaphore_debug, CTLFLAG_RW, - &acpi_semaphore_debug, 0, "Enable ACPI semaphore debug messages"); -#endif /* !ACPI_NO_SEMAPHORES */ - ACPI_STATUS AcpiOsCreateSemaphore(UINT32 MaxUnits, UINT32 InitialUnits, ACPI_SEMAPHORE *OutHandle) { -#ifndef ACPI_NO_SEMAPHORES - struct acpi_semaphore *as; + struct acpi_semaphore *as; - ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); + ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); - if (OutHandle == NULL) - return_ACPI_STATUS (AE_BAD_PARAMETER); - if (InitialUnits > MaxUnits) - return_ACPI_STATUS (AE_BAD_PARAMETER); + if (OutHandle == NULL || InitialUnits > MaxUnits) + return_ACPI_STATUS (AE_BAD_PARAMETER); - if ((as = malloc(sizeof(*as), M_ACPISEM, M_NOWAIT | M_ZERO)) == NULL) - return_ACPI_STATUS (AE_NO_MEMORY); + if ((as = malloc(sizeof(*as), M_ACPISEM, M_NOWAIT | M_ZERO)) == NULL) + return_ACPI_STATUS (AE_NO_MEMORY); - mtx_init(&as->as_mtx, "ACPI semaphore", NULL, MTX_DEF); - as->as_units = InitialUnits; - as->as_maxunits = MaxUnits; - as->as_pendings = as->as_resetting = as->as_timeouts = 0; + snprintf(as->as_name, sizeof(as->as_name), "ACPI sema (%p)", as); + sx_init(&as->as_lock, as->as_name); + cv_init(&as->as_cv, as->as_name); + as->as_units = InitialUnits; + as->as_maxunits = MaxUnits; - ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, - "created semaphore %p max %d, initial %d\n", - as, InitialUnits, MaxUnits)); + ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, + "created semaphore %p, max %u, initial %u\n", + as, InitialUnits, MaxUnits)); - *OutHandle = (ACPI_HANDLE)as; -#else - *OutHandle = (ACPI_HANDLE)OutHandle; -#endif /* !ACPI_NO_SEMAPHORES */ + *OutHandle = (ACPI_SEMAPHORE)as; - return_ACPI_STATUS (AE_OK); + return_ACPI_STATUS (AE_OK); } ACPI_STATUS AcpiOsDeleteSemaphore(ACPI_SEMAPHORE Handle) { -#ifndef ACPI_NO_SEMAPHORES - struct acpi_semaphore *as = (struct acpi_semaphore *)Handle; + struct acpi_semaphore *as = (struct acpi_semaphore *)Handle; - ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); + ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); - ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, "destroyed semaphore %p\n", as)); - mtx_destroy(&as->as_mtx); - free(Handle, M_ACPISEM); -#endif /* !ACPI_NO_SEMAPHORES */ + ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, "delete semaphore %p\n", as)); - return_ACPI_STATUS (AE_OK); + if (as != NULL) { + sx_destroy(&as->as_lock); + cv_destroy(&as->as_cv); + free(as, M_ACPISEM); + return_ACPI_STATUS (AE_OK); + } else + ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, + "cannot delete null semaphore\n")); + + return_ACPI_STATUS (AE_BAD_PARAMETER); } -/* - * This implementation has a bug, in that it has to stall for the entire - * timeout before it will return AE_TIME. A better implementation would - * use getmicrotime() to correctly adjust the timeout after being woken up. - */ ACPI_STATUS AcpiOsWaitSemaphore(ACPI_SEMAPHORE Handle, UINT32 Units, UINT16 Timeout) { -#ifndef ACPI_NO_SEMAPHORES - ACPI_STATUS result; - struct acpi_semaphore *as = (struct acpi_semaphore *)Handle; - int rv, tmo; - struct timeval timeouttv, currenttv, timelefttv; + struct acpi_semaphore *as = (struct acpi_semaphore *)Handle; + struct timeval tv; + long tmo; - ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); + ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); - if (as == NULL) - return_ACPI_STATUS (AE_BAD_PARAMETER); + if (as == NULL || Units == 0) + return_ACPI_STATUS (AE_BAD_PARAMETER); - if (cold) - return_ACPI_STATUS (AE_OK); + sx_xlock(&as->as_lock); + ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, + "get %u units from semaphore %p (has %u), timeout %u\n", + Units, as, as->as_units, Timeout)); -#if 0 - if (as->as_units < Units && as->as_timeouts > 10) { - printf("%s: semaphore %p too many timeouts, resetting\n", __func__, as); - AS_LOCK(as); - as->as_units = as->as_maxunits; - if (as->as_pendings) - as->as_resetting = 1; - as->as_timeouts = 0; - wakeup(as); - AS_UNLOCK(as); - return_ACPI_STATUS (AE_TIME); - } - - if (as->as_resetting) - return_ACPI_STATUS (AE_TIME); -#endif - - /* a timeout of ACPI_WAIT_FOREVER means "forever" */ - if (Timeout == ACPI_WAIT_FOREVER) { - tmo = 0; - timeouttv.tv_sec = ((0xffff/1000) + 1); /* cf. ACPI spec */ - timeouttv.tv_usec = 0; - } else { - /* compute timeout using microseconds per tick */ - tmo = (Timeout * 1000) / (1000000 / hz); - if (tmo <= 0) - tmo = 1; - timeouttv.tv_sec = Timeout / 1000; - timeouttv.tv_usec = (Timeout % 1000) * 1000; - } - - /* calculate timeout value in timeval */ - getmicrotime(¤ttv); - timevaladd(&timeouttv, ¤ttv); - - AS_LOCK(as); - ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, - "get %d units from semaphore %p (has %d), timeout %d\n", - Units, as, as->as_units, Timeout)); - for (;;) { if (as->as_maxunits == ACPI_NO_UNIT_LIMIT) { - result = AE_OK; - break; + sx_xunlock(&as->as_lock); + return_ACPI_STATUS (AE_OK); } - if (as->as_units >= Units) { - as->as_units -= Units; - result = AE_OK; - break; + if (as->as_maxunits < Units) { + ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, "exceeded max units %u\n", + as->as_maxunits)); + sx_xunlock(&as->as_lock); + return_ACPI_STATUS (AE_LIMIT); } - /* limit number of pending threads */ - if (as->as_pendings >= ACPI_SEMAPHORES_MAX_PENDING) { - result = AE_TIME; - break; + switch (Timeout) { + case ACPI_DO_NOT_WAIT: + if (as->as_units >= Units) { + as->as_units -= Units; + sx_xunlock(&as->as_lock); + return_ACPI_STATUS (AE_OK); + } + break; + case ACPI_WAIT_FOREVER: + while (as->as_units < Units) + cv_wait(&as->as_cv, &as->as_lock); + as->as_units -= Units; + sx_xunlock(&as->as_lock); + return_ACPI_STATUS (AE_OK); + default: + tmo = (long)Timeout * 1000; + getmicrouptime(&tv); + do { + if (as->as_units >= Units) { + as->as_units -= Units; + sx_xunlock(&as->as_lock); + return_ACPI_STATUS (AE_OK); + } + if (cv_timedwait(&as->as_cv, &as->as_lock, + timeout2hz(tmo)) == EWOULDBLOCK) + break; + } while (adjust_timeout(&tmo, &tv) > 0); } + sx_xunlock(&as->as_lock); - /* if timeout values of zero is specified, return immediately */ - if (Timeout == 0) { - result = AE_TIME; - break; - } + return_ACPI_STATUS (AE_TIME); +} - ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, - "semaphore blocked, calling msleep(%p, %p, %d, \"acsem\", %d)\n", - as, &as->as_mtx, PCATCH, tmo)); +ACPI_STATUS +AcpiOsSignalSemaphore(ACPI_SEMAPHORE Handle, UINT32 Units) +{ + struct acpi_semaphore *as = (struct acpi_semaphore *)Handle; - as->as_pendings++; + ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); - if (acpi_semaphore_debug) { - printf("%s: Sleep %d, pending %d, semaphore %p, thread %d\n", - __func__, Timeout, as->as_pendings, as, AcpiOsGetThreadId()); - } + if (as == NULL || Units == 0) + return_ACPI_STATUS (AE_BAD_PARAMETER); - rv = msleep(as, &as->as_mtx, PCATCH, "acsem", tmo); + sx_xlock(&as->as_lock); + ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, + "return %u units to semaphore %p (has %u)\n", + Units, as, as->as_units)); - as->as_pendings--; - -#if 0 - if (as->as_resetting) { - /* semaphore reset, return immediately */ - if (as->as_pendings == 0) { - as->as_resetting = 0; - } - result = AE_TIME; - break; + if (as->as_maxunits == ACPI_NO_UNIT_LIMIT) { + sx_xunlock(&as->as_lock); + return_ACPI_STATUS (AE_OK); } -#endif - - ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, "msleep(%d) returned %d\n", tmo, rv)); - if (rv == EWOULDBLOCK) { - result = AE_TIME; - break; + if (as->as_maxunits < Units || + as->as_maxunits - Units < as->as_units) { + ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, "exceeded max units %u\n", + as->as_maxunits)); + sx_xunlock(&as->as_lock); + return_ACPI_STATUS (AE_LIMIT); } - /* check if we already awaited enough */ - timelefttv = timeouttv; - getmicrotime(¤ttv); - timevalsub(&timelefttv, ¤ttv); - if (timelefttv.tv_sec < 0) { - ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, "await semaphore %p timeout\n", - as)); - result = AE_TIME; - break; - } + as->as_units += Units; + cv_broadcast(&as->as_cv); + sx_xunlock(&as->as_lock); - /* adjust timeout for the next sleep */ - tmo = (timelefttv.tv_sec * 1000000 + timelefttv.tv_usec) / - (1000000 / hz); - if (tmo <= 0) - tmo = 1; - - if (acpi_semaphore_debug) { - printf("%s: Wakeup timeleft(%jd, %lu), tmo %u, sem %p, thread %d\n", - __func__, (intmax_t)timelefttv.tv_sec, timelefttv.tv_usec, tmo, as, - AcpiOsGetThreadId()); - } - } - - if (acpi_semaphore_debug) { - if (result == AE_TIME && Timeout > 0) { - printf("%s: Timeout %d, pending %d, semaphore %p\n", - __func__, Timeout, as->as_pendings, as); - } - if (result == AE_OK && (as->as_timeouts > 0 || as->as_pendings > 0)) { - printf("%s: Acquire %d, units %d, pending %d, sem %p, thread %d\n", - __func__, Units, as->as_units, as->as_pendings, as, - AcpiOsGetThreadId()); - } - } - - if (result == AE_TIME) - as->as_timeouts++; - else - as->as_timeouts = 0; - - AS_UNLOCK(as); - return_ACPI_STATUS (result); -#else - return_ACPI_STATUS (AE_OK); -#endif /* !ACPI_NO_SEMAPHORES */ + return_ACPI_STATUS (AE_OK); } +/* + * ACPI_SPINLOCK: a non-sleepable spinlock + */ +struct acpi_spinlock { + struct mtx al_lock; + char al_name[32]; + int al_nested; +}; + ACPI_STATUS -AcpiOsSignalSemaphore(ACPI_SEMAPHORE Handle, UINT32 Units) +AcpiOsCreateLock(ACPI_SPINLOCK *OutHandle) { -#ifndef ACPI_NO_SEMAPHORES - struct acpi_semaphore *as = (struct acpi_semaphore *)Handle; + struct acpi_spinlock *al; - ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); + ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); - if (as == NULL) - return_ACPI_STATUS(AE_BAD_PARAMETER); + if (OutHandle == NULL) + return_ACPI_STATUS (AE_BAD_PARAMETER); + al = malloc(sizeof(*al), M_ACPISEM, M_NOWAIT | M_ZERO); + if (al == NULL) + return_ACPI_STATUS (AE_NO_MEMORY); - AS_LOCK(as); - ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, - "return %d units to semaphore %p (has %d)\n", - Units, as, as->as_units)); - if (as->as_maxunits != ACPI_NO_UNIT_LIMIT) { - as->as_units += Units; - if (as->as_units > as->as_maxunits) - as->as_units = as->as_maxunits; - } + /* Build a unique name based on the address of the handle. */ + if (OutHandle == &AcpiGbl_GpeLock) + snprintf(al->al_name, sizeof(al->al_name), "ACPI lock (GPE)"); + else if (OutHandle == &AcpiGbl_HardwareLock) + snprintf(al->al_name, sizeof(al->al_name), "ACPI lock (HW)"); + else + snprintf(al->al_name, sizeof(al->al_name), "ACPI lock (%p)", + OutHandle); + mtx_init(&al->al_lock, al->al_name, NULL, MTX_SPIN); - if (acpi_semaphore_debug && (as->as_timeouts > 0 || as->as_pendings > 0)) { - printf("%s: Release %d, units %d, pending %d, semaphore %p, thread %d\n", - __func__, Units, as->as_units, as->as_pendings, as, AcpiOsGetThreadId()); - } + ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, "created %s\n", al->al_name)); - wakeup(as); - AS_UNLOCK(as); -#endif /* !ACPI_NO_SEMAPHORES */ + *OutHandle = (ACPI_SPINLOCK)al; - return_ACPI_STATUS (AE_OK); + return_ACPI_STATUS (AE_OK); } -/* Combined mutex + mutex name storage since the latter must persist. */ -struct acpi_spinlock { - struct mtx lock; - char name[32]; -}; - -ACPI_STATUS -AcpiOsCreateLock (ACPI_SPINLOCK *OutHandle) +void +AcpiOsDeleteLock(ACPI_SPINLOCK Handle) { - struct acpi_spinlock *h; + struct acpi_spinlock *al = (struct acpi_spinlock *)Handle; - if (OutHandle == NULL) - return (AE_BAD_PARAMETER); - h = malloc(sizeof(*h), M_ACPISEM, M_NOWAIT | M_ZERO); - if (h == NULL) - return (AE_NO_MEMORY); + ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); - /* Build a unique name based on the address of the handle. */ - if (OutHandle == &AcpiGbl_GpeLock) - snprintf(h->name, sizeof(h->name), "acpi subsystem GPE lock"); - else if (OutHandle == &AcpiGbl_HardwareLock) - snprintf(h->name, sizeof(h->name), "acpi subsystem HW lock"); - else - snprintf(h->name, sizeof(h->name), "acpi subsys %p", OutHandle); - mtx_init(&h->lock, h->name, NULL, MTX_DEF); - *OutHandle = (ACPI_SPINLOCK)h; - return (AE_OK); + ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, "delete %s\n", al->al_name)); + + if (al != NULL) { + mtx_destroy(&al->al_lock); + free(al, M_ACPISEM); + } else + ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, + "cannot delete null spinlock\n")); } -void -AcpiOsDeleteLock (ACPI_SPINLOCK Handle) +ACPI_CPU_FLAGS +AcpiOsAcquireLock(ACPI_SPINLOCK Handle) { - struct acpi_spinlock *h = (struct acpi_spinlock *)Handle; + struct acpi_spinlock *al = (struct acpi_spinlock *)Handle; - if (Handle == NULL) - return; - mtx_destroy(&h->lock); - free(h, M_ACPISEM); -} + ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); -/* - * The Flags parameter seems to state whether or not caller is an ISR - * (and thus can't block) but since we have ithreads, we don't worry - * about potentially blocking. - */ -ACPI_NATIVE_UINT -AcpiOsAcquireLock (ACPI_SPINLOCK Handle) -{ - struct acpi_spinlock *h = (struct acpi_spinlock *)Handle; + ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, "acquire %s\n", al->al_name)); - if (Handle == NULL) + if (al != NULL) { + if (mtx_owned(&al->al_lock)) { + al->al_nested++; + ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, + "acquire nested %s, depth %d\n", + al->al_name, al->al_nested)); + } else + mtx_lock_spin(&al->al_lock); + } else + ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, + "cannot acquire null spinlock\n")); + return (0); - mtx_lock(&h->lock); - return (0); } void -AcpiOsReleaseLock (ACPI_SPINLOCK Handle, ACPI_CPU_FLAGS Flags) +AcpiOsReleaseLock(ACPI_SPINLOCK Handle, ACPI_CPU_FLAGS Flags) { - struct acpi_spinlock *h = (struct acpi_spinlock *)Handle; + struct acpi_spinlock *al = (struct acpi_spinlock *)Handle; - if (Handle == NULL) - return; - mtx_unlock(&h->lock); + ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); + + ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, "release %s\n", al->al_name)); + + if (al != NULL) { + if (mtx_owned(&al->al_lock)) { + if (al->al_nested > 0) { + ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, + "release nested %s, depth %d\n", + al->al_name, al->al_nested)); + al->al_nested--; + } else + mtx_unlock_spin(&al->al_lock); + } else + ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, + "cannot release unowned %s\n", al->al_name)); + } else + ACPI_DEBUG_PRINT((ACPI_DB_MUTEX, + "cannot release null spinlock\n")); } -/* Section 5.2.9.1: global lock acquire/release functions */ -#define GL_ACQUIRED (-1) -#define GL_BUSY 0 -#define GL_BIT_PENDING 0x1 -#define GL_BIT_OWNED 0x2 -#define GL_BIT_MASK (GL_BIT_PENDING | GL_BIT_OWNED) +/* Section 5.2.10.1: global lock acquire/release functions */ +#define GL_ACQUIRED (-1) +#define GL_BUSY 0 +#define GL_BIT_PENDING 0x01 +#define GL_BIT_OWNED 0x02 +#define GL_BIT_MASK (GL_BIT_PENDING | GL_BIT_OWNED) /* * Acquire the global lock. If busy, set the pending bit. The caller @@ -403,7 +352,7 @@ int acpi_acquire_global_lock(uint32_t *lock) { - uint32_t new, old; + uint32_t new, old; do { old = *lock; @@ -422,7 +371,7 @@ int acpi_release_global_lock(uint32_t *lock) { - uint32_t new, old; + uint32_t new, old; do { old = *lock; From eitanadlerlist at gmail.com Tue May 5 21:55:56 2009 From: eitanadlerlist at gmail.com (Eitan Adler) Date: Tue May 5 21:56:08 2009 Subject: Fighting for the power. In-Reply-To: <20090504011421.GI6901@egr.msu.edu> References: <49FE1826.4060000@FreeBSD.org> <20090504011421.GI6901@egr.msu.edu> Message-ID: <4A00AFEB.7010001@gmail.com> Adam McDougall wrote: > On Mon, May 04, 2009 at 01:18:14AM +0300, Alexander Motin wrote: > > I would like to summarize some of my knowledge on reducing FreeBSD power > consumption and describe some new things I have recently implemented in > 8-CURRENT. The main character of this story is my 12" Acer TravelMate > 6292 laptop with C2D T7700 2.4GHz CPU, 965GM chipset and SATA HDD, under > amd64 8-CURRENT. > Could some of these tips get added to 11.15 Power and Resource Management? I'm sure many people who don't regularly read the mailing lists would like to use these tips. -- Eitan Adler "Security is increased by designing for the way humans actually behave." -Jakob Nielsen From alex.wilkinson at dsto.defence.gov.au Tue May 5 22:44:11 2009 From: alex.wilkinson at dsto.defence.gov.au (Wilkinson, Alex) Date: Tue May 5 22:44:17 2009 Subject: Fighting for the power. In-Reply-To: <4A00AFEB.7010001@gmail.com> References: <49FE1826.4060000@FreeBSD.org> <20090504011421.GI6901@egr.msu.edu> <4A00AFEB.7010001@gmail.com> Message-ID: <20090505222958.GK12123@stlux503.dsto.defence.gov.au> 0n Tue, May 05, 2009 at 05:30:19PM -0400, Eitan Adler wrote: >Adam McDougall wrote: >> On Mon, May 04, 2009 at 01:18:14AM +0300, Alexander Motin wrote: >> >> I would like to summarize some of my knowledge on reducing FreeBSD power >> consumption and describe some new things I have recently implemented in >> 8-CURRENT. The main character of this story is my 12" Acer TravelMate >> 6292 laptop with C2D T7700 2.4GHz CPU, 965GM chipset and SATA HDD, under >> amd64 8-CURRENT. >> >Could some of these tips get added to 11.15 Power and Resource >Management? I'm sure many people who don't regularly read the mailing >lists would like to use these tips. I agree. This was an extremely useful and informative thread of discussion to read. (Now how to remember it all ?) -aW IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From amesbury at umn.edu Tue May 5 23:53:01 2009 From: amesbury at umn.edu (Alan Amesbury) Date: Tue May 5 23:53:07 2009 Subject: Garbled output from kgdb? In-Reply-To: <200905051743.03520.jkim@FreeBSD.org> References: <49F8B859.7060908@umn.edu> <4A006E9A.7060806@icyb.net.ua> <200905051609.38689.jkim@FreeBSD.org> <200905051743.03520.jkim@FreeBSD.org> Message-ID: <4A00CDD6.4080303@umn.edu> Jung-uk Kim wrote: > The attached patch is for -STABLE. Note that it is only compile > tested on amd64. The platform in question is 7.1-RELEASE-p5/amd64, and the patch you supplied looks like it applies cleanly to it. While I am unable to pin down the specific trigger of this flaw (the host simply panicked a couple times while under moderate-to-heavy use), I'm willing to apply the patch to the host's current source tree, provided you and John Baldwin are in agreement that it's safe to do so. Note that's not meant to imply I don't trust your coding skills; I'm just not ready to modify production assets without a second look. ;-) Thanks again for your help on this. I appreciate it! -- Alan Amesbury OIT Security and Assurance University of Minnesota From imp at bsdimp.com Thu May 7 06:14:20 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Thu May 7 06:14:26 2009 Subject: Fighting for the power. In-Reply-To: <3a142e750905040240g58152e69p6fcb797a5e026426@mail.gmail.com> References: <49FE1826.4060000@FreeBSD.org> <3a142e750905040240g58152e69p6fcb797a5e026426@mail.gmail.com> Message-ID: <20090507.001059.-1558772981.imp@bsdimp.com> In message: <3a142e750905040240g58152e69p6fcb797a5e026426@mail.gmail.com> "Paul B. Mahol" writes: : On 5/4/09, Alexander Motin wrote: : > 2. PCI devices : > PCI bus provides method to control device power. For example, I have : > completely no use for my FireWire controller and most of time - EHCI USB : > controller. Disabling them allows me to save about 3W of power. To : > disable all unneeded PCI devices you should build kernel without their : > drivers and add to loader.conf: : > hw.pci.do_power_nodriver=3 : > To enable devices back all you need to do is just load their drivers as : > modules. : : Unloading modules doesnt put them back into into D3 state. : You are forced to load some another module again to put wanted device : into D3 state. It should. If it isn't, that's a bug. Warner From received at postcard.org Thu May 7 22:40:49 2009 From: received at postcard.org (received@postcard.org) Date: Thu May 7 22:40:55 2009 Subject: You have just received a virtual postcard from a friend ! Message-ID: <20090507221914.666B321973C6@rhodamine.com.au> You have just received a virtual postcard from a friend ! . You can pick up your postcard at the following web address: . [1]http:.exe . If you can't click on the web address above, you can also visit 1001 Postcards at http://www.postcards.org/postcards/ and enter your pickup code, which is: d21-sea-sunset . (Your postcard will be available for 60 days.) . Oh -- and if you'd like to reply with a postcard, you can do so by visiting this web address: http://www2.postcards.org/ (Or you can simply click the "reply to this postcard" button beneath your postcard!) . We hope you enjoy your postcard, and if you do, please take a moment to send a few yourself! . Regards, 1001 Postcards http://www.postcards.org/postcards/ References 1. http://85.17.150.185/~paco/postcard.gif.exe From dsewnr.buffer at gmail.com Fri May 8 02:53:23 2009 From: dsewnr.buffer at gmail.com (Dsewnr Lu) Date: Fri May 8 02:53:31 2009 Subject: acpi problem ? Message-ID: <4A0397B2.5000303@gmail.com> Hi all, My command "shutdown -p now" can not poweroff automatically, it halt on the last screen with uptime and my keyboard is hang, too. And "reboot" or "shutdown -h now" work fine. Is it an acpi problem ? There're my kernel config, dmesg and sysctl message. Any idea ? Thanks, Dsewnr Lu -------------- next part -------------- # # GENERIC -- Generic kernel configuration file for FreeBSD/amd64 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: src/sys/amd64/conf/GENERIC,v 1.484.2.19.2.1 2009/04/15 03:14:26 kensmith Exp $ cpu HAMMER ident kernel # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols options SCTP # Stream Control Transmission Protocol options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options UFS_GJOURNAL # Enable gjournal-based UFS journaling options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFSLOCKD # Network Lock Manager options NFS_ROOT # NFS usable as /, requires NFSCLIENT options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization options COMPAT_43TTY # BSD 4.3 TTY compat [KEEP THIS!] options COMPAT_IA32 # Compatible with i386 binaries options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options STACK # stack(9) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev options ADAPTIVE_GIANT # Giant mutex is adaptive. options STOP_NMI # Stop CPUS using NMI instead of IPI options AUDIT # Security event auditing options KDTRACE_FRAME # Ensure frames are compiled in options KDTRACE_HOOKS # Kernel DTrace hooks # Make an SMP-capable kernel by default options SMP # Symmetric MultiProcessor Kernel # Add by me device drm device radeondrm device ichwd device cpuctl device coretemp options ENABLE_ALART options COMPAT_LINUX32 options LINPROCFS options LINSYSFS options ACPI_DEBUG options ALTQ options ALTQ_CBQ options ALTQ_RED options ALTQ_RIO options ALTQ_HFSC options ALTQ_CDNR options ALTQ_PRIQ options ALTQ_NOPCC options ALTQ_DEBUG # CPU frequency control device cpufreq # Bus support. device acpi device pci # Floppy drives #device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives #device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives #device atapifd # ATAPI floppy drives #device atapist # ATAPI tape drives options ATA_STATIC_ID # Static device numbering # SCSI Controllers #device ahc # AHA2940 and onboard AIC7xxx devices #options AHC_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~128k to driver. #device ahd # AHA39320/29320 and onboard AIC79xx devices #options AHD_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~215k to driver. #device amd # AMD 53C974 (Tekram DC-390(T)) #device hptiop # Highpoint RocketRaid 3xxx series #device isp # Qlogic family #device ispfw # Firmware for QLogic HBAs- normally a module device mpt # LSI-Logic MPT-Fusion #device ncr # NCR/Symbios Logic #device sym # NCR/Symbios Logic (newer chipsets + those of `ncr') #device trm # Tekram DC395U/UW/F DC315U adapters #device adv # Advansys SCSI adapters #device adw # Advansys wide SCSI adapters #device aic # Adaptec 15[012]x SCSI adapters, AIC-6[23]60. #device bt # Buslogic/Mylex MultiMaster SCSI adapters # SCSI peripherals device scbus # SCSI bus (required for SCSI) #device ch # SCSI media changers device da # Direct Access (disks) #device sa # Sequential Access (tape etc) #device cd # CD device pass # Passthrough device (direct SCSI access) #device ses # SCSI Environmental Services (and SAF-TE) # RAID controllers interfaced to the SCSI subsystem #device amr # AMI MegaRAID #device arcmsr # Areca SATA II RAID #device ciss # Compaq Smart RAID 5* #device dpt # DPT Smartcache III, IV - See NOTES for options #device hptmv # Highpoint RocketRAID 182x #device hptrr # Highpoint RocketRAID 17xx, 22xx, 23xx, 25xx #device iir # Intel Integrated RAID #device ips # IBM (Adaptec) ServeRAID #device mly # Mylex AcceleRAID/eXtremeRAID #device twa # 3ware 9000 series PATA/SATA RAID # RAID controllers #device aac # Adaptec FSA RAID #device aacp # SCSI passthrough for aac (requires CAM) #device ida # Compaq Smart RAID #device mfi # LSI MegaRAID SAS #device mlx # Mylex DAC960 family #XXX pointer/int warnings #device pst # Promise Supertrak SX6000 #device twe # 3ware ATA RAID # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device kbdmux # keyboard multiplexer device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc device agp # support several AGP chipsets # PCCARD (PCMCIA) support # PCMCIA and cardbus bridge support #device cbb # cardbus (yenta) bridge #device pccard # PC Card (16-bit) bus #device cardbus # CardBus (32-bit) bus # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports device uart # Generic UART driver # Parallel port device ppc device ppbus # Parallel port bus (required) device lpt # Printer device plip # TCP/IP over parallel device ppi # Parallel port interface device device vpo # Requires scbus and da # If you've got a "dumb" serial or parallel PCI card that is # supported by the puc(4) glue driver, uncomment the following # line to enable it (connects to sio, uart and/or ppc drivers): #device puc # PCI Ethernet NICs. #device de # DEC/Intel DC21x4x (``Tulip'') #device em # Intel PRO/1000 Gigabit Ethernet Family #device igb # Intel PRO/1000 PCIE Server Gigabit Family #device ixgbe # Intel PRO/10GbE PCIE Ethernet Family #device le # AMD Am7900 LANCE and Am79C9xx PCnet #device txp # 3Com 3cR990 (``Typhoon'') #device vx # 3Com 3c590, 3c595 (``Vortex'') # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support #device age # Attansic/Atheros L1 Gigabit Ethernet #device ale # Atheros AR8121/AR8113/AR8114 Ethernet #device bce # Broadcom BCM5706/BCM5708 Gigabit Ethernet #device bfe # Broadcom BCM440x 10/100 Ethernet #device bge # Broadcom BCM570xx Gigabit Ethernet #device dc # DEC/Intel 21143 and various workalikes #device et # Agere ET1310 10/100/Gigabit Ethernet #device fxp # Intel EtherExpress PRO/100B (82557, 82558) #device jme # JMicron JMC250 Gigabit/JMC260 Fast Ethernet #device lge # Level 1 LXT1001 gigabit Ethernet #device msk # Marvell/SysKonnect Yukon II Gigabit Ethernet #device nfe # nVidia nForce MCP on-board Ethernet #device nge # NatSemi DP83820 gigabit Ethernet #device nve # nVidia nForce MCP on-board Ethernet Networking #device pcn # AMD Am79C97x PCI 10/100 (precedence over 'le') device re # RealTek 8139C+/8169/8169S/8110S #device rl # RealTek 8129/8139 #device sf # Adaptec AIC-6915 (``Starfire'') #device sis # Silicon Integrated Systems SiS 900/SiS 7016 #device sk # SysKonnect SK-984x & SK-982x gigabit Ethernet #device ste # Sundance ST201 (D-Link DFE-550TX) #device ti # Alteon Networks Tigon I/II gigabit Ethernet #device tl # Texas Instruments ThunderLAN #device tx # SMC EtherPower II (83c170 ``EPIC'') #device vge # VIA VT612x gigabit Ethernet #device vr # VIA Rhine, Rhine II #device wb # Winbond W89C840F #device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # ISA Ethernet NICs. pccard NICs included. #device cs # Crystal Semiconductor CS89x0 NIC # 'device ed' requires 'device miibus' #device ed # NE[12]000, SMC Ultra, 3c503, DS8390 cards #device ex # Intel EtherExpress Pro/10 and Pro/10+ #device ep # Etherlink III based cards #device fe # Fujitsu MB8696x based cards #device sn # SMC's 9000 series of Ethernet chips #device xe # Xircom pccard Ethernet # Wireless NIC cards #device wlan # 802.11 support #device wlan_wep # 802.11 WEP support #device wlan_ccmp # 802.11 CCMP support #device wlan_tkip # 802.11 TKIP support #device wlan_amrr # AMRR transmit rate control algorithm #device wlan_scan_ap # 802.11 AP mode scanning #device wlan_scan_sta # 802.11 STA mode scanning #device an # Aironet 4500/4800 802.11 wireless NICs. #device ath # Atheros pci/cardbus NIC's #device ath_hal # Atheros HAL (Hardware Access Layer) #options AH_SUPPORT_AR5416 # enable AR5416 tx/rx descriptors #device ath_rate_sample # SampleRate tx rate control for ath #device awi # BayStack 660 and others #device ral # Ralink Technology RT2500 wireless NICs. #device wi # WaveLAN/Intersil/Symbol 802.11 wireless NICs. # Pseudo devices. device loop # Network loopback device random # Entropy device device ether # Ethernet support device sl # Kernel SLIP device ppp # Kernel PPP device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) device firmware # firmware assist module # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # USB support device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device usb # USB Bus (required) #device udbp # USB Double Bulk Pipe devices device ugen # Generic device uhid # "Human Interface Devices" device ukbd # Keyboard #device ulpt # Printer device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse #device ural # Ralink Technology RT2500USB wireless NICs #device urio # Diamond Rio 500 MP3 player #device uscanner # Scanners # USB Serial devices device ucom # Generic com ttys #device uark # Technologies ARK3116 based serial adapters #device ubsa # Belkin F5U103 and compatible serial adapters #device ubser # BWCT console serial adapters #device uftdi # For FTDI usb serial adapters #device uipaq # Some WinCE based devices #device uplcom # Prolific PL-2303 serial adapters #device uslcom # SI Labs CP2101/CP2102 serial adapters #device uvisor # Visor and Palm devices #device uvscom # USB serial support for DDI pocket's PHS # USB Ethernet, requires miibus #device aue # ADMtek USB Ethernet #device axe # ASIX Electronics USB Ethernet #device cdce # Generic USB over Ethernet #device cue # CATC USB Ethernet #device kue # Kawasaki LSI USB Ethernet #device rue # RealTek RTL8150 USB Ethernet # FireWire support #device firewire # FireWire bus code #device sbp # SCSI over FireWire (Requires scbus and da) #device fwe # Ethernet over FireWire (non-standard!) #device fwip # IP over FireWire (RFC 2734,3146) #device dcons # Dumb console driver #device dcons_crom # Configuration ROM for dcons -------------- next part -------------- Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.2-RELEASE #3: Mon May 4 23:59:09 CST 2009 root@localhost:/usr/obj/usr/src/sys/kernel Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Pentium(R) Dual-Core CPU E5200 @ 2.50GHz (2493.76-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x10676 Stepping = 6 Features=0xbfebfbff Features2=0xe39d AMD Features=0x20000800 AMD Features2=0x1 Cores per package: 2 usable memory = 4284555264 (4086 MB) avail memory = 4112035840 (3921 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ichwd module loaded acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xa000-0xa0ff mem 0xd0000000-0xdfffffff,0xff820000-0xff82ffff irq 16 at device 0.0 on pci1 drm0: on vgapci0 vgapci0: child drm0 requested pci_enable_busmaster info: [drm] Initialized radeon 1.29.0 20080528 pci1: at device 0.1 (no driver attached) uhci0: port 0xb0c0-0xb0df irq 16 at device 26.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xb0a0-0xb0bf irq 21 at device 26.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xb080-0xb09f irq 18 at device 26.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xff904400-0xff9047ff irq 18 at device 26.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: on usb3 uhub3: 6 ports with 6 removable, self powered pci0: at device 27.0 (no driver attached) pcib2: irq 17 at device 28.0 on pci0 pci2: on pcib2 pcib3: irq 17 at device 28.4 on pci0 pci3: on pcib3 atapci0: port 0x9040-0x9047,0x9030-0x9033,0x9020-0x9027,0x9010-0x9013,0x9000-0x900f mem 0xff700000-0xff701fff irq 16 at device 0.0 on pci3 atapci0: [ITHREAD] atapci0: AHCI called from vendor specific driver atapci0: AHCI Version 01.00 controller with 2 ports detected ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] ata4: on atapci0 ata4: [ITHREAD] pcib4: irq 16 at device 28.5 on pci0 pci4: on pcib4 re0: port 0x8000-0x80ff mem 0xff620000-0xff620fff irq 17 at device 0.0 on pci4 re0: Using 1 MSI messages re0: Chip rev. 0x38000000 re0: MAC rev. 0x00000000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: Ethernet address: 00:21:85:39:d3:b9 re0: [FILTER] uhci3: port 0xb060-0xb07f irq 23 at device 29.0 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb4: on uhci3 usb4: USB revision 1.0 uhub4: on usb4 uhub4: 2 ports with 2 removable, self powered uhci4: port 0xb040-0xb05f irq 19 at device 29.1 on pci0 uhci4: [GIANT-LOCKED] uhci4: [ITHREAD] usb5: on uhci4 usb5: USB revision 1.0 uhub5: on usb5 uhub5: 2 ports with 2 removable, self powered uhci5: port 0xb020-0xb03f irq 18 at device 29.2 on pci0 uhci5: [GIANT-LOCKED] uhci5: [ITHREAD] usb6: on uhci5 usb6: USB revision 1.0 uhub6: on usb6 uhub6: 2 ports with 2 removable, self powered ehci1: mem 0xff904000-0xff9043ff irq 23 at device 29.7 on pci0 ehci1: [GIANT-LOCKED] ehci1: [ITHREAD] usb7: EHCI version 1.0 usb7: companion controllers, 2 ports each: usb4 usb5 usb6 usb7: on ehci1 usb7: USB revision 2.0 uhub7: on usb7 uhub7: 6 ports with 6 removable, self powered pcib5: at device 30.0 on pci0 pci5: on pcib5 isab0: at device 31.0 on pci0 isa0: on isab0 atapci1: port 0xb190-0xb197,0xb180-0xb183,0xb170-0xb177,0xb160-0xb163,0xb150-0xb15f,0xb140-0xb14f irq 19 at device 31.2 on pci0 atapci1: [ITHREAD] ata5: on atapci1 ata5: [ITHREAD] ata6: on atapci1 ata6: [ITHREAD] pci0: at device 31.3 (no driver attached) atapci2: port 0xb130-0xb137,0xb120-0xb123,0xb110-0xb117,0xb100-0xb103,0xb0f0-0xb0ff,0xb0e0-0xb0ef irq 19 at device 31.5 on pci0 atapci2: [ITHREAD] ata7: on atapci2 ata7: [ITHREAD] ata8: on atapci2 ata8: [ITHREAD] acpi_button0: on acpi0 acpi_button1: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model MouseMan+, device ID 0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] sio1: configured irq 5 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: configured irq 5 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 5 on acpi0 sio1: type 16550A sio1: [FILTER] ppc0: port 0x378-0x37f irq 3 drq 3 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 ppbus0: [ITHREAD] plip0: on ppbus0 plip0: WARNING: using obsoleted IFF_NEEDSGIANT flag lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] cpu0: on acpi0 coretemp0: on cpu0 est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 61a4c2106004c21 device_attach: est0 attach returned 6 p4tcc0: on cpu0 cpu1: on acpi0 coretemp1: on cpu1 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 61a4c2106004c21 device_attach: est1 attach returned 6 p4tcc1: on cpu1 ichwd0: on isa0 ichwd0: Intel ICH9 watchdog timer (ICH9 or equivalent) orm0: at iomem 0xd0000-0xd0fff,0xd1000-0xdb7ff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec acd0: DVDR at ata4-slave UDMA66 ad10: 610480MB at ata5-master SATA300 SMP: AP CPU #1 Launched! GEOM_LABEL: Label for provider ad10s2a is ufsid/49f785a6b063a8e7. GEOM_LABEL: Label for provider ad10s2d is ufsid/49f785a8c197de2f. GEOM_LABEL: Label for provider ad10s2e is ufsid/49f785a6e7c7c315. GEOM_LABEL: Label for provider ad10s2f is ufsid/49f785a6b778d176. Trying to mount root from ufs:/dev/ad10s2a GEOM_LABEL: Label ufsid/49f785a6b063a8e7 removed. GEOM_LABEL: Label for provider ad10s2a is ufsid/49f785a6b063a8e7. GEOM_LABEL: Label ufsid/49f785a6e7c7c315 removed. GEOM_LABEL: Label for provider ad10s2e is ufsid/49f785a6e7c7c315. GEOM_LABEL: Label ufsid/49f785a6b778d176 removed. GEOM_LABEL: Label for provider ad10s2f is ufsid/49f785a6b778d176. GEOM_LABEL: Label ufsid/49f785a8c197de2f removed. GEOM_LABEL: Label for provider ad10s2d is ufsid/49f785a8c197de2f. GEOM_LABEL: Label ufsid/49f785a6b063a8e7 removed. GEOM_LABEL: Label ufsid/49f785a6e7c7c315 removed. GEOM_LABEL: Label ufsid/49f785a6b778d176 removed. GEOM_LABEL: Label ufsid/49f785a8c197de2f removed. WARNING: attempt to net_add_domain(netgraph) after domainfinalize() fuse4bsd: version 0.3.9-pre1, FUSE ABI 7.8 re0: link state changed to UP hdac0: mem 0xff900000-0xff903fff irq 22 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20090329_0131 hdac0: [ITHREAD] hdac0: HDA Codec #0: Realtek ALC888 hdac1: mem 0xff830000-0xff833fff irq 17 at device 0.1 on pci1 hdac1: HDA Driver Revision: 20090329_0131 hdac1: [ITHREAD] hdac1: HDA Codec #0: ATI R6xx HDMI pcm0: at cad 0 nid 1 on hdac0 pcm1: at cad 0 nid 1 on hdac0 pcm2: at cad 0 nid 1 on hdac0 pcm3: at cad 0 nid 1 on hdac1 pid 1116 (notification-daemon), uid 1001: exited on signal 6 -------------- next part -------------- kern.ostype: FreeBSD kern.osrelease: 7.2-RELEASE kern.osrevision: 199506 kern.version: FreeBSD 7.2-RELEASE #3: Mon May 4 23:59:09 CST 2009 root@localhost:/usr/obj/usr/src/sys/kernel kern.maxvnodes: 100000 kern.maxproc: 6164 kern.maxfiles: 12328 kern.argmax: 262144 kern.securelevel: -1 kern.hostname: localhost kern.hostid: 2945091116 kern.clockrate: { hz = 1000, tick = 1000, profhz = 2000, stathz = 133 } kern.posix1version: 200112 kern.ngroups: 16 kern.job_control: 1 kern.saved_ids: 0 kern.boottime: { sec = 1241746336, usec = 758957 } Fri May 8 09:32:16 2009 kern.domainname: kern.osreldate: 702000 kern.bootfile: /boot/kernel/kernel kern.maxfilesperproc: 11095 kern.maxprocperuid: 5547 kern.ipc.maxsockbuf: 262144 kern.ipc.sockbuf_waste_factor: 8 kern.ipc.somaxconn: 128 kern.ipc.max_linkhdr: 16 kern.ipc.max_protohdr: 60 kern.ipc.max_hdr: 76 kern.ipc.max_datalen: 100 kern.ipc.nmbjumbo16: 3200 kern.ipc.nmbjumbo9: 6400 kern.ipc.nmbjumbop: 12800 kern.ipc.nmbclusters: 25600 kern.ipc.piperesizeallowed: 1 kern.ipc.piperesizefail: 0 kern.ipc.pipeallocfail: 0 kern.ipc.pipefragretry: 0 kern.ipc.pipekva: 720896 kern.ipc.maxpipekva: 68907008 kern.ipc.msgseg: 2048 kern.ipc.msgssz: 8 kern.ipc.msgtql: 40 kern.ipc.msgmnb: 2048 kern.ipc.msgmni: 40 kern.ipc.msgmax: 16384 kern.ipc.semaem: 16384 kern.ipc.semvmx: 32767 kern.ipc.semusz: 152 kern.ipc.semume: 10 kern.ipc.semopm: 100 kern.ipc.semmsl: 60 kern.ipc.semmnu: 30 kern.ipc.semmns: 60 kern.ipc.semmni: 10 kern.ipc.semmap: 30 kern.ipc.shm_allow_removed: 0 kern.ipc.shm_use_phys: 0 kern.ipc.shmall: 8192 kern.ipc.shmseg: 128 kern.ipc.shmmni: 192 kern.ipc.shmmin: 1 kern.ipc.shmmax: 33554432 kern.ipc.maxsockets: 25600 kern.ipc.numopensockets: 215 kern.ipc.nsfbufsused: 0 kern.ipc.nsfbufspeak: 0 kern.ipc.nsfbufs: 0 kern.dummy: 0 kern.ps_strings: 140737488355296 kern.usrstack: 140737488355328 kern.logsigexit: 1 kern.iov_max: 1024 kern.hostuuid: 00000000-0000-0000-0000-00218539d3b9 kern.cam.cam_srch_hi: 0 kern.cam.scsi_delay: 5000 kern.cam.da.da_send_ordered: 1 kern.cam.da.default_timeout: 60 kern.cam.da.retry_count: 4 kern.disks: ad10 kern.geom.collectstats: 1 kern.geom.debugflags: 0 kern.geom.label.debug: 0 kern.elf64.fallback_brand: -1 kern.init_shutdown_timeout: 120 kern.init_path: /sbin/init:/sbin/oinit:/sbin/init.bak:/rescue/init:/stand/sysinstall kern.acct_suspended: 0 kern.acct_configured: 0 kern.acct_chkfreq: 15 kern.acct_resume: 4 kern.acct_suspend: 2 kern.cp_times: 19461 0 2707 768 128704 19564 0 2832 339 128902 kern.cp_time: 39025 0 5539 1107 257606 kern.openfiles: 559 kern.kq_calloutmax: 4096 kern.ps_arg_cache_limit: 256 kern.stackprot: 7 kern.randompid: 0 kern.lastpid: 1183 kern.ktrace.request_pool: 100 kern.ktrace.genio_size: 4096 kern.module_path: /boot/kernel;/boot/modules kern.malloc_count: 251 kern.fallback_elf_brand: -1 kern.features.compat_freebsd6: 1 kern.features.compat_freebsd5: 1 kern.features.compat_freebsd4: 1 kern.maxusers: 384 kern.ident: kernel kern.kstack_pages: 4 kern.shutdown.kproc_shutdown_wait: 60 kern.shutdown.poweroff_delay: 5000 kern.sync_on_panic: 0 kern.corefile: %N.core kern.nodump_coredump: 0 kern.coredump: 1 kern.sugid_coredump: 0 kern.sigqueue.alloc_fail: 0 kern.sigqueue.overflow: 0 kern.sigqueue.preallocate: 1024 kern.sigqueue.max_pending_per_proc: 128 kern.forcesigexit: 1 kern.fscale: 2048 kern.timecounter.tick: 1 kern.timecounter.choice: TSC(-100) HPET(900) ACPI-fast(1000) i8254(0) dummy(-1000000) kern.timecounter.hardware: ACPI-fast kern.timecounter.stepwarnings: 0 kern.timecounter.tc.i8254.mask: 65535 kern.timecounter.tc.i8254.counter: 60594 kern.timecounter.tc.i8254.frequency: 1193182 kern.timecounter.tc.i8254.quality: 0 kern.timecounter.tc.ACPI-fast.mask: 16777215 kern.timecounter.tc.ACPI-fast.counter: 1971695 kern.timecounter.tc.ACPI-fast.frequency: 3579545 kern.timecounter.tc.ACPI-fast.quality: 1000 kern.timecounter.tc.HPET.mask: 4294967295 kern.timecounter.tc.HPET.counter: 3849169539 kern.timecounter.tc.HPET.frequency: 14318180 kern.timecounter.tc.HPET.quality: 900 kern.timecounter.tc.TSC.mask: 4294967295 kern.timecounter.tc.TSC.counter: 2329995051 kern.timecounter.tc.TSC.frequency: 2493761312 kern.timecounter.tc.TSC.quality: -100 kern.timecounter.smp_tsc: 0 kern.timecounter.invariant_tsc: 0 kern.threads.virtual_cpu: 2 kern.threads.max_threads_hits: 0 kern.threads.max_threads_per_proc: 1500 kern.ccpu: 0 kern.sched.preemption: 1 kern.sched.topology: 0 kern.sched.steal_thresh: 1 kern.sched.steal_idle: 1 kern.sched.steal_htt: 1 kern.sched.balance_interval: 133 kern.sched.balance: 1 kern.sched.tryself: 1 kern.sched.affinity: 3 kern.sched.pick_pri: 1 kern.sched.preempt_thresh: 64 kern.sched.interact: 30 kern.sched.slice: 13 kern.sched.name: ULE kern.devstat.version: 6 kern.devstat.generation: 233 kern.devstat.numdevs: 1 kern.kobj_methodcount: 153 kern.log_wakeups_per_second: 5 kern.sgrowsiz: 131072 kern.maxssiz: 536870912 kern.dflssiz: 8388608 kern.maxdsiz: 34359738368 kern.dfldsiz: 134217728 kern.maxtsiz: 134217728 kern.maxbcache: 419430400 kern.maxswzone: 33554432 kern.nswbuf: 256 kern.nbuf: 25600 kern.ncallout: 18508 kern.hz: 1000 kern.msgbuf_clear: 0 kern.msgbuf: kern.always_console_output: 0 kern.log_console_output: 1 kern.smp.forward_roundrobin_enabled: 1 kern.smp.forward_signal_enabled: 1 kern.smp.cpus: 2 kern.smp.disabled: 0 kern.smp.active: 1 kern.smp.maxcpus: 16 kern.smp.maxid: 1 kern.nselcoll: 0 kern.tty_nout: 140369 kern.tty_nin: 3857 kern.drainwait: 300 kern.constty_wakeups_per_second: 5 kern.consmsgbuf_size: 8192 kern.consmute: 0 kern.console: consolectl,/consolectl,ttyd0, kern.minvnodes: 25000 kern.metadelay: 28 kern.dirdelay: 29 kern.filedelay: 30 kern.chroot_allow_open_directories: 1 kern.rpc.invalid: 0 kern.rpc.unexpected: 0 kern.rpc.timeouts: 0 kern.rpc.request: 0 kern.rpc.retries: 0 kern.elf32.fallback_brand: -1 kern.random.yarrow.gengateinterval: 10 kern.random.yarrow.bins: 10 kern.random.yarrow.fastthresh: 192 kern.random.yarrow.slowthresh: 256 kern.random.yarrow.slowoverthresh: 2 kern.random.sys.seeded: 1 kern.random.sys.harvest.ethernet: 1 kern.random.sys.harvest.point_to_point: 1 kern.random.sys.harvest.interrupt: 1 kern.random.sys.harvest.swi: 0 vm.vmtotal: System wide totals computed every five seconds: (values in kilobytes) =============================================== Processes: (RUNQ: 1 Disk Wait: 3 Page Wait: 0 Sleep: 79) Virtual Memory: (Total: 13591376K, Active 944696K) Real Memory: (Total: 515676K Active 445224K) Shared Virtual Memory: (Total: 115764K Active: 113912K) Shared Real Memory: (Total: 67080K Active: 66812K) Free Memory Pages: 3393596K vm.loadavg: { 0.26 0.26 0.20 } vm.v_free_min: 6409 vm.v_free_target: 27000 vm.v_free_reserved: 1364 vm.v_inactive_target: 40500 vm.v_cache_min: 27000 vm.v_cache_max: 54000 vm.v_pageout_free_min: 34 vm.pageout_algorithm: 0 vm.swap_enabled: 1 vm.kmem_size_scale: 3 vm.kmem_size_max: 3865468109 vm.kmem_size_min: 0 vm.kmem_size: 1378185216 vm.nswapdev: 1 vm.dmmax: 32 vm.swap_async_max: 4 vm.zone_count: 102 vm.swap_idle_threshold2: 10 vm.swap_idle_threshold1: 2 vm.exec_map_entries: 16 vm.stats.misc.zero_page_count: 266 vm.stats.misc.cnt_prezero: 0 vm.stats.vm.v_kthreadpages: 0 vm.stats.vm.v_rforkpages: 0 vm.stats.vm.v_vforkpages: 11655 vm.stats.vm.v_forkpages: 280361 vm.stats.vm.v_kthreads: 54 vm.stats.vm.v_rforks: 0 vm.stats.vm.v_vforks: 48 vm.stats.vm.v_forks: 1081 vm.stats.vm.v_interrupt_free_min: 2 vm.stats.vm.v_pageout_free_min: 34 vm.stats.vm.v_cache_max: 54000 vm.stats.vm.v_cache_min: 27000 vm.stats.vm.v_cache_count: 1634 vm.stats.vm.v_inactive_count: 37498 vm.stats.vm.v_inactive_target: 40500 vm.stats.vm.v_active_count: 71792 vm.stats.vm.v_wire_count: 51546 vm.stats.vm.v_free_count: 846765 vm.stats.vm.v_free_min: 6409 vm.stats.vm.v_free_target: 27000 vm.stats.vm.v_free_reserved: 1364 vm.stats.vm.v_page_count: 1009414 vm.stats.vm.v_page_size: 4096 vm.stats.vm.v_tfree: 1744477 vm.stats.vm.v_pfree: 478478 vm.stats.vm.v_dfree: 0 vm.stats.vm.v_tcached: 3118 vm.stats.vm.v_pdpages: 0 vm.stats.vm.v_pdwakeups: 0 vm.stats.vm.v_reactivated: 1383 vm.stats.vm.v_intrans: 286 vm.stats.vm.v_vnodepgsout: 0 vm.stats.vm.v_vnodepgsin: 25483 vm.stats.vm.v_vnodeout: 0 vm.stats.vm.v_vnodein: 2715 vm.stats.vm.v_swappgsout: 0 vm.stats.vm.v_swappgsin: 0 vm.stats.vm.v_swapout: 0 vm.stats.vm.v_swapin: 0 vm.stats.vm.v_ozfod: 0 vm.stats.vm.v_zfod: 1721091 vm.stats.vm.v_cow_optim: 360 vm.stats.vm.v_cow_faults: 58487 vm.stats.vm.v_vm_faults: 1876617 vm.stats.sys.v_soft: 338443 vm.stats.sys.v_intr: 149867 vm.stats.sys.v_syscall: 22399500 vm.stats.sys.v_trap: 2677424 vm.stats.sys.v_swtch: 9743597 vm.stats.object.bypasses: 717 vm.stats.object.collapses: 4729 vm.v_free_severe: 3886 vm.max_proc_mmap: 123052 vm.old_msync: 0 vm.msync_flush_flags: 3 vm.boot_pages: 48 vm.max_wired: 330509 vm.pageout_lock_miss: 0 vm.disable_swapspace_pageouts: 0 vm.defer_swapspace_pageouts: 0 vm.swap_idle_enabled: 0 vm.pageout_stats_interval: 5 vm.pageout_full_stats_interval: 20 vm.pageout_stats_max: 27000 vm.max_launder: 32 vm.phys_segs: SEGMENT 0: start: 0x1000 end: 0x9c000 free list: 0xffffffff807d0cc8 SEGMENT 1: start: 0x90b000 end: 0x1000000 free list: 0xffffffff807d0cc8 SEGMENT 2: start: 0x1000000 end: 0xc6e1c000 free list: 0xffffffff807d0920 SEGMENT 3: start: 0xcfd96000 end: 0xcff00000 free list: 0xffffffff807d0920 SEGMENT 4: start: 0x100000000 end: 0x12fff0000 free list: 0xffffffff807d0920 vm.phys_free: FREE LIST 0: ORDER (SIZE) | NUMBER | POOL 0 | POOL 1 | POOL 2 -- -- -- -- -- -- -- -- 12 ( 16384K) | 184 | 0 | 0 11 ( 8192K) | 1 | 0 | 0 10 ( 4096K) | 8 | 1 | 0 9 ( 2048K) | 9 | 0 | 1 8 ( 1024K) | 1 | 1 | 0 7 ( 512K) | 0 | 0 | 0 6 ( 256K) | 12 | 1 | 0 5 ( 128K) | 16 | 1 | 1 4 ( 64K) | 44 | 5 | 4 3 ( 32K) | 63 | 14 | 24 2 ( 16K) | 167 | 23 | 32 1 ( 8K) | 69 | 37 | 39 0 ( 4K) | 0 | 27 | 46 FREE LIST 1: ORDER (SIZE) | NUMBER | POOL 0 | POOL 1 | POOL 2 -- -- -- -- -- -- -- -- 12 ( 16384K) | 0 | 0 | 0 11 ( 8192K) | 0 | 0 | 0 10 ( 4096K) | 1 | 0 | 0 9 ( 2048K) | 1 | 0 | 0 8 ( 1024K) | 0 | 0 | 0 7 ( 512K) | 1 | 0 | 0 6 ( 256K) | 2 | 0 | 0 5 ( 128K) | 2 | 0 | 0 4 ( 64K) | 3 | 0 | 0 3 ( 32K) | 2 | 0 | 0 2 ( 16K) | 3 | 0 | 0 1 ( 8K) | 1 | 0 | 0 0 ( 4K) | 2 | 0 | 0 vm.reserv.reclaimed: 0 vm.reserv.partpopq: LEVEL SIZE NUMBER -1: 286348K, 229 vm.reserv.freed: 4811 vm.reserv.broken: 0 vm.idlezero_enable: 0 vm.kvm_free: 4414500864 vm.kvm_size: 6442446848 vm.pmap.pmap_collect_active: 0 vm.pmap.pmap_collect_inactive: 0 vm.pmap.pv_entry_spare: 7504 vm.pmap.pv_entry_allocs: 2978073 vm.pmap.pv_entry_frees: 2794897 vm.pmap.pc_chunk_tryfail: 0 vm.pmap.pc_chunk_frees: 10442 vm.pmap.pc_chunk_allocs: 11577 vm.pmap.pc_chunk_count: 1135 vm.pmap.pv_entry_count: 183176 vm.pmap.pde.promotions: 0 vm.pmap.pde.p_failures: 0 vm.pmap.pde.mappings: 0 vm.pmap.pde.demotions: 0 vm.pmap.shpgperproc: 200 vm.pmap.pv_entry_max: 2242214 vm.pmap.pg_ps_enabled: 0 vfs.nfs.downdelayinitial: 12 vfs.nfs.downdelayinterval: 30 vfs.nfs.skip_wcc_data_onerr: 1 vfs.nfs.nfs3_jukebox_delay: 10 vfs.nfs.reconnects: 0 vfs.nfs.bufpackets: 4 vfs.nfs.realign_count: 0 vfs.nfs.realign_test: 0 vfs.nfs.defect: 0 vfs.nfs.iodmax: 20 vfs.nfs.iodmin: 0 vfs.nfs.iodmaxidle: 120 vfs.nfs.diskless_rootpath: vfs.nfs.diskless_valid: 0 vfs.nfs.nfs_ip_paranoia: 1 vfs.nfs.nfs_directio_allow_mmap: 1 vfs.nfs.nfs_directio_enable: 0 vfs.nfs.clean_pages_on_close: 1 vfs.nfs.nfsv3_commit_on_close: 0 vfs.nfs.prime_access_cache: 1 vfs.nfs.access_cache_timeout: 60 vfs.ufs.dirhash_docheck: 0 vfs.ufs.dirhash_mem: 266770 vfs.ufs.dirhash_maxmem: 2097152 vfs.ufs.dirhash_minsize: 2560 vfs.devfs.rule_depth: 1 vfs.devfs.generation: 139 vfs.nfs4.access_cache_timeout: 60 vfs.pfs.trace: 0 vfs.pfs.vncache.misses: 0 vfs.pfs.vncache.hits: 0 vfs.pfs.vncache.maxentries: 0 vfs.pfs.vncache.entries: 0 vfs.flushwithdeps: 0 vfs.getnewbufrestarts: 0 vfs.getnewbufcalls: 9448 vfs.hifreebuffers: 2854 vfs.lofreebuffers: 1427 vfs.numfreebuffers: 25529 vfs.dirtybufthresh: 5778 vfs.hidirtybuffers: 6420 vfs.lodirtybuffers: 3210 vfs.numdirtybuffers: 71 vfs.recursiveflushes: 1931 vfs.altbufferflushes: 0 vfs.bdwriteskip: 0 vfs.dirtybufferflushes: 0 vfs.hirunningspace: 1048576 vfs.lorunningspace: 524288 vfs.bufdefragcnt: 0 vfs.buffreekvacnt: 0 vfs.bufreusecnt: 7972 vfs.hibufspace: 418775040 vfs.lobufspace: 418709504 vfs.maxmallocbufspace: 20938752 vfs.bufmallocspace: 10240 vfs.maxbufspace: 419430400 vfs.bufspace: 130613248 vfs.runningbufspace: 0 vfs.vmiodirenable: 1 vfs.cache.numfullpathfound: 150 vfs.cache.numfullpathfail4: 0 vfs.cache.numfullpathfail2: 0 vfs.cache.numfullpathfail1: 0 vfs.cache.numfullpathcalls: 150 vfs.cache.nchstats: 242182 19248 383 0 9552 0 285 1245 vfs.cache.numneghits: 19248 vfs.cache.numnegzaps: 185 vfs.cache.numposhits: 242200 vfs.cache.numposzaps: 198 vfs.cache.nummisszap: 283 vfs.cache.nummiss: 9269 vfs.cache.numchecks: 262370 vfs.cache.dotdothits: 1296 vfs.cache.dothits: 273 vfs.cache.numcalls: 272976 vfs.cache.numcache: 3611 vfs.cache.numneg: 224 vfs.read_max: 8 vfs.write_behind: 1 vfs.lookup_shared: 0 vfs.usermount: 0 vfs.worklist_len: 12 vfs.timestamp_precision: 0 vfs.reassignbufcalls: 15637 vfs.freevnodes: 689 vfs.wantfreevnodes: 25000 vfs.numvnodes: 3536 vfs.nfsrv.nfs_privport: 0 vfs.nfsrv.commit_miss: 0 vfs.nfsrv.commit_blks: 0 vfs.nfsrv.async: 0 vfs.nfsrv.realign_count: 0 vfs.nfsrv.realign_test: 0 vfs.nfsrv.gatherdelay_v3: 0 vfs.nfsrv.gatherdelay: 10000 vfs.ffs.doreallocblks: 1 vfs.ffs.doasyncfree: 1 vfs.ffs.compute_summary_at_mount: 0 vfs.fuse.kernelabi_minor: 8 vfs.fuse.kernelabi_major: 7 vfs.fuse.maxtickets: 0 vfs.fuse.iov_credit: 16 vfs.fuse.iov_permanent_bufsize: 524288 vfs.fuse.maxfreetickets: 1024 vfs.fuse.fuse4bsd_version: 0.3.9-pre1 vfs.fuse.sync_unmount: 1 vfs.fuse.enforce_dev_perms: 0 vfs.fuse.init_backgrounded: 1 net.local.stream.recvspace: 8192 net.local.stream.sendspace: 8192 net.local.dgram.recvspace: 4096 net.local.dgram.maxdgram: 2048 net.local.recycled: 0 net.local.taskcount: 0 net.local.inflight: 0 net.inet.ip.portrange.randomtime: 45 net.inet.ip.portrange.randomcps: 10 net.inet.ip.portrange.randomized: 1 net.inet.ip.portrange.reservedlow: 0 net.inet.ip.portrange.reservedhigh: 1023 net.inet.ip.portrange.hilast: 65535 net.inet.ip.portrange.hifirst: 49152 net.inet.ip.portrange.last: 65535 net.inet.ip.portrange.first: 49152 net.inet.ip.portrange.lowlast: 600 net.inet.ip.portrange.lowfirst: 1023 net.inet.ip.forwarding: 0 net.inet.ip.redirect: 1 net.inet.ip.ttl: 64 net.inet.ip.rtexpire: 3600 net.inet.ip.rtminexpire: 10 net.inet.ip.rtmaxcache: 128 net.inet.ip.sourceroute: 0 net.inet.ip.intr_queue_maxlen: 50 net.inet.ip.intr_queue_drops: 0 net.inet.ip.accept_sourceroute: 0 net.inet.ip.keepfaith: 0 net.inet.ip.gifttl: 30 net.inet.ip.same_prefix_carp_only: 0 net.inet.ip.subnets_are_local: 0 net.inet.ip.fastforwarding: 0 net.inet.ip.maxfragpackets: 800 net.inet.ip.maxfragsperpacket: 16 net.inet.ip.fragpackets: 0 net.inet.ip.check_interface: 0 net.inet.ip.random_id: 0 net.inet.ip.sendsourcequench: 0 net.inet.ip.process_options: 1 net.inet.icmp.maskrepl: 0 net.inet.icmp.icmplim: 200 net.inet.icmp.bmcastecho: 0 net.inet.icmp.quotelen: 8 net.inet.icmp.reply_from_interface: 0 net.inet.icmp.reply_src: net.inet.icmp.icmplim_output: 1 net.inet.icmp.log_redirect: 0 net.inet.icmp.drop_redirect: 0 net.inet.icmp.maskfake: 0 net.inet.tcp.rfc1323: 1 net.inet.tcp.mssdflt: 512 net.inet.tcp.keepidle: 7200000 net.inet.tcp.keepintvl: 75000 net.inet.tcp.sendspace: 32768 net.inet.tcp.recvspace: 65536 net.inet.tcp.keepinit: 75000 net.inet.tcp.delacktime: 100 net.inet.tcp.v6mssdflt: 1024 net.inet.tcp.hostcache.purge: 0 net.inet.tcp.hostcache.prune: 300 net.inet.tcp.hostcache.expire: 3600 net.inet.tcp.hostcache.count: 32 net.inet.tcp.hostcache.bucketlimit: 30 net.inet.tcp.hostcache.hashsize: 512 net.inet.tcp.hostcache.cachelimit: 15360 net.inet.tcp.recvbuf_max: 262144 net.inet.tcp.recvbuf_inc: 16384 net.inet.tcp.recvbuf_auto: 1 net.inet.tcp.insecure_rst: 0 net.inet.tcp.rfc3390: 1 net.inet.tcp.rfc3042: 1 net.inet.tcp.drop_synfin: 0 net.inet.tcp.delayed_ack: 1 net.inet.tcp.blackhole: 0 net.inet.tcp.log_in_vain: 0 net.inet.tcp.sendbuf_max: 262144 net.inet.tcp.sendbuf_inc: 8192 net.inet.tcp.sendbuf_auto: 1 net.inet.tcp.tso: 1 net.inet.tcp.newreno: 1 net.inet.tcp.local_slowstart_flightsize: 4 net.inet.tcp.slowstart_flightsize: 1 net.inet.tcp.path_mtu_discovery: 1 net.inet.tcp.reass.overflows: 0 net.inet.tcp.reass.maxqlen: 48 net.inet.tcp.reass.cursegments: 0 net.inet.tcp.reass.maxsegments: 1600 net.inet.tcp.sack.globalholes: 0 net.inet.tcp.sack.globalmaxholes: 65536 net.inet.tcp.sack.maxholes: 128 net.inet.tcp.sack.enable: 1 net.inet.tcp.inflight.stab: 20 net.inet.tcp.inflight.max: 1073725440 net.inet.tcp.inflight.min: 6144 net.inet.tcp.inflight.rttthresh: 10 net.inet.tcp.inflight.debug: 0 net.inet.tcp.inflight.enable: 1 net.inet.tcp.isn_reseed_interval: 0 net.inet.tcp.icmp_may_rst: 1 net.inet.tcp.pcbcount: 11 net.inet.tcp.do_tcpdrain: 1 net.inet.tcp.tcbhashsize: 512 net.inet.tcp.log_debug: 0 net.inet.tcp.minmss: 216 net.inet.tcp.syncache.rst_on_sock_fail: 1 net.inet.tcp.syncache.rexmtlimit: 3 net.inet.tcp.syncache.hashsize: 512 net.inet.tcp.syncache.count: 0 net.inet.tcp.syncache.cachelimit: 15360 net.inet.tcp.syncache.bucketlimit: 30 net.inet.tcp.syncookies_only: 0 net.inet.tcp.syncookies: 1 net.inet.tcp.timer_race: 0 net.inet.tcp.finwait2_timeout: 60000 net.inet.tcp.fast_finwait2_recycle: 0 net.inet.tcp.always_keepalive: 1 net.inet.tcp.rexmit_slop: 200 net.inet.tcp.rexmit_min: 30 net.inet.tcp.msl: 30000 net.inet.tcp.nolocaltimewait: 0 net.inet.tcp.maxtcptw: 5120 net.inet.udp.checksum: 1 net.inet.udp.maxdgram: 9216 net.inet.udp.recvspace: 42080 net.inet.udp.soreceive_dgram_enabled: 1 net.inet.udp.blackhole: 0 net.inet.udp.log_in_vain: 0 net.inet.sctp.nat_friendly_init: 1 net.inet.sctp.enable_sack_immediately: 0 net.inet.sctp.udp_tunneling_port: 0 net.inet.sctp.udp_tunneling_for_client_enable: 0 net.inet.sctp.mobility_fasthandoff: 0 net.inet.sctp.mobility_base: 0 net.inet.sctp.default_frag_interleave: 1 net.inet.sctp.default_cc_module: 0 net.inet.sctp.log_level: 0 net.inet.sctp.max_retran_chunk: 30 net.inet.sctp.min_residual: 1452 net.inet.sctp.strict_data_order: 0 net.inet.sctp.abort_at_limit: 0 net.inet.sctp.hb_max_burst: 4 net.inet.sctp.do_sctp_drain: 1 net.inet.sctp.max_chained_mbufs: 5 net.inet.sctp.abc_l_var: 1 net.inet.sctp.nat_friendly: 1 net.inet.sctp.auth_disable: 0 net.inet.sctp.asconf_auth_nochk: 0 net.inet.sctp.early_fast_retran_msec: 250 net.inet.sctp.early_fast_retran: 0 net.inet.sctp.cwnd_maxburst: 1 net.inet.sctp.cmt_pf: 0 net.inet.sctp.cmt_use_dac: 0 net.inet.sctp.nr_sack_on_off: 0 net.inet.sctp.cmt_on_off: 0 net.inet.sctp.outgoing_streams: 10 net.inet.sctp.add_more_on_output: 1452 net.inet.sctp.path_rtx_max: 5 net.inet.sctp.assoc_rtx_max: 10 net.inet.sctp.init_rtx_max: 8 net.inet.sctp.valid_cookie_life: 60000 net.inet.sctp.init_rto_max: 60000 net.inet.sctp.rto_initial: 3000 net.inet.sctp.rto_min: 1000 net.inet.sctp.rto_max: 60000 net.inet.sctp.secret_lifetime: 3600 net.inet.sctp.shutdown_guard_time: 180 net.inet.sctp.pmtu_raise_time: 600 net.inet.sctp.heartbeat_interval: 30000 net.inet.sctp.asoc_resource: 10 net.inet.sctp.sys_resource: 1000 net.inet.sctp.sack_freq: 2 net.inet.sctp.delayed_sack_time: 200 net.inet.sctp.chunkscale: 10 net.inet.sctp.min_split_point: 2904 net.inet.sctp.pcbhashsize: 256 net.inet.sctp.tcbhashsize: 1024 net.inet.sctp.maxchunks: 3200 net.inet.sctp.maxburst: 4 net.inet.sctp.peer_chkoh: 256 net.inet.sctp.strict_init: 1 net.inet.sctp.loopback_nocsum: 1 net.inet.sctp.strict_sacks: 1 net.inet.sctp.ecn_nonce: 0 net.inet.sctp.ecn_enable: 1 net.inet.sctp.auto_asconf: 1 net.inet.sctp.recvspace: 233016 net.inet.sctp.sendspace: 233016 net.inet.raw.recvspace: 9216 net.inet.raw.maxdgram: 9216 net.inet.accf.unloadable: 0 net.link.generic.system.ifcount: 5 net.link.ether.inet.log_arp_permanent_modify: 1 net.link.ether.inet.log_arp_movements: 1 net.link.ether.inet.log_arp_wrong_iface: 1 net.link.ether.inet.proxyall: 0 net.link.ether.inet.useloopback: 1 net.link.ether.inet.maxtries: 5 net.link.ether.inet.max_age: 1200 net.link.ether.ipfw: 0 net.link.gif.parallel_tunnels: 0 net.link.gif.max_nesting: 1 net.link.log_link_state_change: 1 net.link.tun.devfs_cloning: 1 net.inet6.ip6.forwarding: 0 net.inet6.ip6.redirect: 1 net.inet6.ip6.hlim: 64 net.inet6.ip6.maxfragpackets: 6400 net.inet6.ip6.accept_rtadv: 0 net.inet6.ip6.keepfaith: 0 net.inet6.ip6.log_interval: 5 net.inet6.ip6.hdrnestlimit: 15 net.inet6.ip6.dad_count: 1 net.inet6.ip6.auto_flowlabel: 1 net.inet6.ip6.defmcasthlim: 1 net.inet6.ip6.gifhlim: 30 net.inet6.ip6.kame_version: FreeBSD net.inet6.ip6.use_deprecated: 1 net.inet6.ip6.rr_prune: 5 net.inet6.ip6.v6only: 1 net.inet6.ip6.rtexpire: 3600 net.inet6.ip6.rtminexpire: 10 net.inet6.ip6.rtmaxcache: 128 net.inet6.ip6.use_tempaddr: 0 net.inet6.ip6.temppltime: 86400 net.inet6.ip6.tempvltime: 604800 net.inet6.ip6.auto_linklocal: 0 net.inet6.ip6.prefer_tempaddr: 0 net.inet6.ip6.use_defaultzone: 0 net.inet6.ip6.maxfrags: 6400 net.inet6.ip6.mcast_pmtu: 0 net.inet6.icmp6.rediraccept: 1 net.inet6.icmp6.redirtimeout: 600 net.inet6.icmp6.nd6_prune: 1 net.inet6.icmp6.nd6_delay: 5 net.inet6.icmp6.nd6_umaxtries: 3 net.inet6.icmp6.nd6_mmaxtries: 3 net.inet6.icmp6.nd6_useloopback: 1 net.inet6.icmp6.nodeinfo: 3 net.inet6.icmp6.errppslimit: 100 net.inet6.icmp6.nd6_maxnudhint: 0 net.inet6.icmp6.nd6_debug: 0 net.inet6.icmp6.nd6_maxqueuelen: 1 net.inet6.icmp6.nd6_onlink_ns_rfc4861: 0 net.bpf.maxinsns: 512 net.bpf.maxbufsize: 524288 net.bpf.bufsize: 4096 net.isr.swi_count: 7 net.isr.drop: 0 net.isr.queued: 7 net.isr.deferred: 0 net.isr.directed: 6442 net.isr.count: 6442 net.isr.direct: 1 net.raw.recvspace: 8192 net.raw.sendspace: 8192 net.my_fibnum: 0 net.add_addr_allfibs: 1 net.fibs: 1 net.route.netisr_maxqlen: 256 net.graph.msg_version: 8 net.graph.abi_version: 11 net.graph.maxdata: 512 net.graph.maxalloc: 4096 net.graph.threads: 2 net.graph.control.proto: 2 net.graph.data.proto: 1 net.graph.family: 32 net.graph.recvspace: 20480 net.graph.maxdgram: 20480 debug.acpi.semaphore_debug: 0 debug.acpi.level: NONE debug.acpi.layer: NONE debug.acpi.suspend_bounce: 0 debug.acpi.do_powerstate: 1 debug.acpi.acpi_ca_version: 20070320 debug.acpi.ec.timeout: 750 debug.acpi.ec.polled: 0 debug.acpi.ec.burst: 0 debug.acpi.batt.batt_sleep_ms: 0 debug.mddebug: 0 debug.elf64_legacy_coredump: 0 debug.elf64_trace: 0 debug.bootverbose: 0 debug.boothowto: 0 debug.cpufreq.verbose: 0 debug.cpufreq.lowest: 0 debug.sizeof.cdev_priv: 376 debug.sizeof.cdev: 288 debug.sizeof.g_bioq: 72 debug.sizeof.g_consumer: 96 debug.sizeof.g_provider: 136 debug.sizeof.g_geom: 136 debug.sizeof.g_class: 136 debug.sizeof.kinfo_proc: 1088 debug.sizeof.buf: 640 debug.sizeof.bio: 216 debug.sizeof.proc: 1144 debug.sizeof.vnode: 504 debug.sizeof.devstat: 288 debug.sizeof.namecache: 72 debug.to_avg_mpcalls: 1480 debug.to_avg_mtxcalls: 0 debug.to_avg_gcalls: 16 debug.to_avg_depth: 1710 debug.umtx.umtx_pi_allocated: 0 debug.kdb.stop_cpus: 1 debug.kdb.trap_code: 0 debug.kdb.trap: 0 debug.kdb.panic: 0 debug.kdb.enter: 0 debug.kdb.current: debug.kdb.available: debug.rman_debug: 0 debug.ttydebug: 0 debug.disablefullpath: 0 debug.disablecwd: 0 debug.vfscache: 1 debug.numcachehv: 493 debug.numcache: 3611 debug.numneg: 224 debug.ncnegfactor: 16 debug.nchash: 131071 debug.vnlru_nowhere: 0 debug.rush_requests: 0 debug.mpsafevfs: 1 debug.if_tun_debug: 0 debug.nlm_debug: 0 debug.collectsnapstats: 0 debug.snapdebug: 0 debug.dopersistence: 0 debug.dir_entry: 65 debug.direct_blk_ptrs: 48 debug.inode_bitmap: 51 debug.indir_blk_ptrs: 39 debug.sync_limit_hit: 0 debug.ino_limit_hit: 0 debug.blk_limit_hit: 0 debug.ino_limit_push: 0 debug.blk_limit_push: 0 debug.worklist_push: 0 debug.maxindirdeps: 50 debug.tickdelay: 2 debug.max_softdeps: 400000 debug.dobkgrdwrite: 1 debug.bigcgs: 0 debug.dircheck: 0 debug.minidump: 1 debug.stop_cpus_with_nmi: 1 debug.psm.pkterrthresh: 2 debug.psm.usecs: 500000 debug.psm.secs: 0 debug.psm.errusecs: 0 debug.psm.errsecs: 2 debug.psm.hz: 20 debug.psm.loglevel: 0 debug.elf32_legacy_coredump: 0 debug.elf32_trace: 0 debug.pfugidhack: 0 hw.machine: amd64 hw.model: Pentium(R) Dual-Core CPU E5200 @ 2.50GHz hw.ncpu: 2 hw.byteorder: 1234 hw.physmem: 4284555264 hw.usermem: 4073398272 hw.pagesize: 4096 hw.floatingpoint: 1 hw.machine_arch: amd64 hw.realmem: 5100273664 hw.ata.wc: 1 hw.ata.atapi_dma: 1 hw.ata.ata_dma_check_80pin: 1 hw.ata.ata_dma: 1 hw.pci.honor_msi_blacklist: 1 hw.pci.enable_msix: 1 hw.pci.enable_msi: 1 hw.pci.do_power_resume: 1 hw.pci.do_power_nodriver: 0 hw.pci.enable_io_modes: 1 hw.pci.host_mem_start: 2147483648 hw.syscons.kbd_debug: 1 hw.syscons.kbd_reboot: 1 hw.syscons.bell: 1 hw.syscons.saver.keybonly: 1 hw.syscons.sc_no_suspend_vtswitch: 0 hw.intr_storm_threshold: 1000 hw.availpages: 1046034 hw.bus.devctl_disable: 0 hw.busdma.total_bpages: 10585 hw.busdma.zone0.total_bpages: 8200 hw.busdma.zone0.free_bpages: 8200 hw.busdma.zone0.reserved_bpages: 0 hw.busdma.zone0.active_bpages: 0 hw.busdma.zone0.total_bounced: 0 hw.busdma.zone0.total_deferred: 0 hw.busdma.zone0.lowaddr: 0xffffffff hw.busdma.zone0.alignment: 1 hw.busdma.zone0.boundary: 0 hw.busdma.zone1.total_bpages: 2048 hw.busdma.zone1.free_bpages: 2048 hw.busdma.zone1.reserved_bpages: 0 hw.busdma.zone1.active_bpages: 0 hw.busdma.zone1.total_bounced: 0 hw.busdma.zone1.total_deferred: 0 hw.busdma.zone1.lowaddr: 0xfffffffffffffff hw.busdma.zone1.alignment: 2 hw.busdma.zone1.boundary: 65536 hw.busdma.zone2.total_bpages: 80 hw.busdma.zone2.free_bpages: 80 hw.busdma.zone2.reserved_bpages: 0 hw.busdma.zone2.active_bpages: 0 hw.busdma.zone2.total_bounced: 462 hw.busdma.zone2.total_deferred: 0 hw.busdma.zone2.lowaddr: 0xffffffff hw.busdma.zone2.alignment: 2 hw.busdma.zone2.boundary: 65536 hw.busdma.zone3.total_bpages: 257 hw.busdma.zone3.free_bpages: 257 hw.busdma.zone3.reserved_bpages: 0 hw.busdma.zone3.active_bpages: 0 hw.busdma.zone3.total_bounced: 0 hw.busdma.zone3.total_deferred: 0 hw.busdma.zone3.lowaddr: 0xffffffff hw.busdma.zone3.alignment: 8 hw.busdma.zone3.boundary: 0 hw.clockrate: 2493 hw.instruction_sse: 1 hw.apic.enable_extint: 0 hw.psm.tap_timeout: 125000 hw.psm.tap_threshold: 25 hw.kbd.keymap_restrict_change: 0 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: 0 hw.acpi.disable_on_reboot: 0 hw.acpi.handle_reboot: 0 hw.acpi.cpu.cx_lowest: C1 hw.dri.0.name: radeon 0x21 hw.dri.0.vm: slot offset size type flags address mtrr 0 0x00000000ff820000 0x00010000 REG 0x82 0xfffffffe80085000 no hw.dri.0.clients: a dev pid uid magic ioctls hw.dri.0.debug: 0 hw.snd.latency_profile: 1 hw.snd.latency: 5 hw.snd.report_soft_formats: 1 hw.snd.compat_linux_mmap: 0 hw.snd.feeder_buffersize: 16384 hw.snd.feeder_rate_round: 25 hw.snd.feeder_rate_max: 2016000 hw.snd.feeder_rate_min: 1 hw.snd.verbose: 1 hw.snd.maxautovchans: 16 hw.snd.default_unit: 0 hw.snd.version: 2007061600/amd64 hw.snd.default_auto: 0 hw.midi.instroff: 0 hw.midi.dumpraw: 0 hw.midi.debug: 0 hw.midi.stat.verbose: 0 hw.midi.seq.debug: 0 machdep.acpi_timer_freq: 3579545 machdep.enable_panic_key: 0 machdep.adjkerntz: -28800 machdep.wall_cmos_clock: 1 machdep.disable_rtc_set: 0 machdep.acpi_root: 984000 machdep.disable_mtrrs: 0 machdep.cpu_idle_hlt: 1 machdep.hlt_cpus: 0 machdep.prot_fault_translation: 0 machdep.panic_on_nmi: 1 machdep.tsc_freq: 2493761312 machdep.i8254_freq: 1193182 machdep.conspeed: 9600 machdep.gdbspeed: 9600 machdep.conrclk: 1843200 machdep.hlt_logical_cpus: 0 machdep.logical_cpus_mask: 2 user.cs_path: /usr/bin:/bin:/usr/sbin:/sbin: user.bc_base_max: 99 user.bc_dim_max: 2048 user.bc_scale_max: 99 user.bc_string_max: 1000 user.coll_weights_max: 0 user.expr_nest_max: 32 user.line_max: 2048 user.re_dup_max: 255 user.posix2_version: 199212 user.posix2_c_bind: 0 user.posix2_c_dev: 0 user.posix2_char_term: 0 user.posix2_fort_dev: 0 user.posix2_fort_run: 0 user.posix2_localedef: 0 user.posix2_sw_dev: 0 user.posix2_upe: 0 user.stream_max: 20 user.tzname_max: 255 p1003_1b.asynchronous_io: 0 p1003_1b.mapped_files: 1 p1003_1b.memlock: 0 p1003_1b.memlock_range: 0 p1003_1b.memory_protection: 0 p1003_1b.message_passing: 0 p1003_1b.prioritized_io: 0 p1003_1b.priority_scheduling: 1 p1003_1b.realtime_signals: 200112 p1003_1b.semaphores: 0 p1003_1b.fsync: 0 p1003_1b.shared_memory_objects: 1 p1003_1b.synchronized_io: 0 p1003_1b.timers: 200112 p1003_1b.aio_listio_max: -1 p1003_1b.aio_max: -1 p1003_1b.aio_prio_delta_max: -1 p1003_1b.delaytimer_max: 2147483647 p1003_1b.mq_open_max: 0 p1003_1b.pagesize: 4096 p1003_1b.rtsig_max: 62 p1003_1b.sem_nsems_max: 0 p1003_1b.sem_value_max: 0 p1003_1b.sigqueue_max: 128 p1003_1b.timer_max: 32 security.jail.jailed: 0 security.jail.jail_max_af_ips: 255 security.jail.mount_allowed: 0 security.jail.chflags_allowed: 0 security.jail.allow_raw_sockets: 0 security.jail.enforce_statfs: 2 security.jail.sysvipc_allowed: 0 security.jail.socket_unixiproute_only: 1 security.jail.set_hostname_allowed: 1 security.bsd.suser_enabled: 1 security.bsd.unprivileged_proc_debug: 1 security.bsd.conservative_signals: 1 security.bsd.see_other_gids: 1 security.bsd.see_other_uids: 1 security.bsd.unprivileged_read_msgbuf: 1 security.bsd.hardlink_check_gid: 0 security.bsd.hardlink_check_uid: 0 security.bsd.unprivileged_get_quota: 0 compat.ia32.maxvmem: 0 compat.ia32.maxssiz: 67108864 compat.ia32.maxdsiz: 536870912 compat.linux32.maxvmem: 0 compat.linux32.maxssiz: 67108864 compat.linux32.maxdsiz: 536870912 compat.linux.oss_version: 198144 compat.linux.osrelease: 2.4.2 compat.linux.osname: Linux dev.nexus.0.%driver: nexus dev.nexus.0.%parent: root0 dev.ram.0.%desc: System RAM dev.ram.0.%driver: ram dev.ram.0.%parent: nexus0 dev.acpi.0.%desc: ALASKA A M I dev.acpi.0.%driver: acpi dev.acpi.0.%parent: nexus0 dev.acpi_sysresource.0.%desc: System Resource dev.acpi_sysresource.0.%driver: acpi_sysresource dev.acpi_sysresource.0.%location: handle=\_SB_.PCI0.MCH_ dev.acpi_sysresource.0.%pnpinfo: _HID=PNP0C01 _UID=10 dev.acpi_sysresource.0.%parent: acpi0 dev.acpi_sysresource.1.%desc: System Resource dev.acpi_sysresource.1.%driver: acpi_sysresource dev.acpi_sysresource.1.%location: handle=\_SB_.PCI0.SBRG.SIO1 dev.acpi_sysresource.1.%pnpinfo: _HID=PNP0C02 _UID=78 dev.acpi_sysresource.1.%parent: acpi0 dev.acpi_sysresource.2.%desc: System Resource dev.acpi_sysresource.2.%driver: acpi_sysresource dev.acpi_sysresource.2.%location: handle=\_SB_.PCI0.SBRG.RMSC dev.acpi_sysresource.2.%pnpinfo: _HID=PNP0C02 _UID=16 dev.acpi_sysresource.2.%parent: acpi0 dev.acpi_sysresource.3.%desc: System Resource dev.acpi_sysresource.3.%driver: acpi_sysresource dev.acpi_sysresource.3.%location: handle=\_SB_.PCI0.ICH9 dev.acpi_sysresource.3.%pnpinfo: _HID=PNP0C01 _UID=455 dev.acpi_sysresource.3.%parent: acpi0 dev.acpi_sysresource.4.%desc: System Resource dev.acpi_sysresource.4.%driver: acpi_sysresource dev.acpi_sysresource.4.%location: handle=\_SB_.RMEM dev.acpi_sysresource.4.%pnpinfo: _HID=PNP0C01 _UID=1 dev.acpi_sysresource.4.%parent: acpi0 dev.acpi_sysresource.5.%desc: System Resource dev.acpi_sysresource.5.%driver: acpi_sysresource dev.acpi_sysresource.5.%location: handle=\OMSC dev.acpi_sysresource.5.%pnpinfo: _HID=PNP0C02 _UID=3601 dev.acpi_sysresource.5.%parent: acpi0 dev.acpi_timer.0.%desc: 24-bit timer at 3.579545MHz dev.acpi_timer.0.%driver: acpi_timer dev.acpi_timer.0.%location: unknown dev.acpi_timer.0.%pnpinfo: unknown dev.acpi_timer.0.%parent: acpi0 dev.pci_link.0.%desc: ACPI PCI Link LNKA dev.pci_link.0.%driver: pci_link dev.pci_link.0.%location: handle=\_SB_.LNKA dev.pci_link.0.%pnpinfo: _HID=PNP0C0F _UID=1 dev.pci_link.0.%parent: acpi0 dev.pci_link.1.%desc: ACPI PCI Link LNKB dev.pci_link.1.%driver: pci_link dev.pci_link.1.%location: handle=\_SB_.LNKB dev.pci_link.1.%pnpinfo: _HID=PNP0C0F _UID=2 dev.pci_link.1.%parent: acpi0 dev.pci_link.2.%desc: ACPI PCI Link LNKC dev.pci_link.2.%driver: pci_link dev.pci_link.2.%location: handle=\_SB_.LNKC dev.pci_link.2.%pnpinfo: _HID=PNP0C0F _UID=3 dev.pci_link.2.%parent: acpi0 dev.pci_link.3.%desc: ACPI PCI Link LNKD dev.pci_link.3.%driver: pci_link dev.pci_link.3.%location: handle=\_SB_.LNKD dev.pci_link.3.%pnpinfo: _HID=PNP0C0F _UID=4 dev.pci_link.3.%parent: acpi0 dev.pci_link.4.%desc: ACPI PCI Link LNKE dev.pci_link.4.%driver: pci_link dev.pci_link.4.%location: handle=\_SB_.LNKE dev.pci_link.4.%pnpinfo: _HID=PNP0C0F _UID=5 dev.pci_link.4.%parent: acpi0 dev.pci_link.5.%desc: ACPI PCI Link LNKF dev.pci_link.5.%driver: pci_link dev.pci_link.5.%location: handle=\_SB_.LNKF dev.pci_link.5.%pnpinfo: _HID=PNP0C0F _UID=6 dev.pci_link.5.%parent: acpi0 dev.pci_link.6.%desc: ACPI PCI Link LNKG dev.pci_link.6.%driver: pci_link dev.pci_link.6.%location: handle=\_SB_.LNKG dev.pci_link.6.%pnpinfo: _HID=PNP0C0F _UID=7 dev.pci_link.6.%parent: acpi0 dev.pci_link.7.%desc: ACPI PCI Link LNKH dev.pci_link.7.%driver: pci_link dev.pci_link.7.%location: handle=\_SB_.LNKH dev.pci_link.7.%pnpinfo: _HID=PNP0C0F _UID=8 dev.pci_link.7.%parent: acpi0 dev.acpi_hpet.0.%desc: High Precision Event Timer dev.acpi_hpet.0.%driver: acpi_hpet dev.acpi_hpet.0.%location: unknown dev.acpi_hpet.0.%pnpinfo: unknown dev.acpi_hpet.0.%parent: acpi0 dev.pcib.0.%desc: ACPI Host-PCI bridge dev.pcib.0.%driver: pcib dev.pcib.0.%location: handle=\_SB_.PCI0 dev.pcib.0.%pnpinfo: _HID=PNP0A08 _UID=0 dev.pcib.0.%parent: acpi0 dev.pcib.1.%desc: ACPI PCI-PCI bridge dev.pcib.1.%driver: pcib dev.pcib.1.%location: slot=1 function=0 handle=\_SB_.PCI0.P0P2 dev.pcib.1.%pnpinfo: vendor=0x8086 device=0x29c1 subvendor=0x1462 subdevice=0x7395 class=0x060400 dev.pcib.1.%parent: pci0 dev.pcib.1.wake: 0 dev.pcib.2.%desc: ACPI PCI-PCI bridge dev.pcib.2.%driver: pcib dev.pcib.2.%location: slot=28 function=0 handle=\_SB_.PCI0.PEX0 dev.pcib.2.%pnpinfo: vendor=0x8086 device=0x2940 subvendor=0x0000 subdevice=0x0000 class=0x060400 dev.pcib.2.%parent: pci0 dev.pcib.2.wake: 0 dev.pcib.3.%desc: ACPI PCI-PCI bridge dev.pcib.3.%driver: pcib dev.pcib.3.%location: slot=28 function=4 handle=\_SB_.PCI0.PEX4 dev.pcib.3.%pnpinfo: vendor=0x8086 device=0x2948 subvendor=0x0000 subdevice=0x0000 class=0x060400 dev.pcib.3.%parent: pci0 dev.pcib.3.wake: 0 dev.pcib.4.%desc: ACPI PCI-PCI bridge dev.pcib.4.%driver: pcib dev.pcib.4.%location: slot=28 function=5 handle=\_SB_.PCI0.PEX5 dev.pcib.4.%pnpinfo: vendor=0x8086 device=0x294a subvendor=0x0000 subdevice=0x0000 class=0x060400 dev.pcib.4.%parent: pci0 dev.pcib.4.wake: 0 dev.pcib.5.%desc: ACPI PCI-PCI bridge dev.pcib.5.%driver: pcib dev.pcib.5.%location: slot=30 function=0 handle=\_SB_.PCI0.P0P1 dev.pcib.5.%pnpinfo: vendor=0x8086 device=0x244e subvendor=0x0000 subdevice=0x0000 class=0x060401 dev.pcib.5.%parent: pci0 dev.pcib.5.wake: 0 dev.pci.0.%desc: ACPI PCI bus dev.pci.0.%driver: pci dev.pci.0.%parent: pcib0 dev.pci.1.%desc: ACPI PCI bus dev.pci.1.%driver: pci dev.pci.1.%parent: pcib1 dev.pci.1.wake: 0 dev.pci.2.%desc: ACPI PCI bus dev.pci.2.%driver: pci dev.pci.2.%parent: pcib2 dev.pci.2.wake: 0 dev.pci.3.%desc: ACPI PCI bus dev.pci.3.%driver: pci dev.pci.3.%parent: pcib3 dev.pci.3.wake: 0 dev.pci.4.%desc: ACPI PCI bus dev.pci.4.%driver: pci dev.pci.4.%parent: pcib4 dev.pci.4.wake: 0 dev.pci.5.%desc: ACPI PCI bus dev.pci.5.%driver: pci dev.pci.5.%parent: pcib5 dev.pci.5.wake: 0 dev.hostb.0.%desc: Host to PCI bridge dev.hostb.0.%driver: hostb dev.hostb.0.%location: slot=0 function=0 dev.hostb.0.%pnpinfo: vendor=0x8086 device=0x29c0 subvendor=0x0000 subdevice=0x0000 class=0x060000 dev.hostb.0.%parent: pci0 dev.vgapci.0.%desc: VGA-compatible display dev.vgapci.0.%driver: vgapci dev.vgapci.0.%location: slot=0 function=0 dev.vgapci.0.%pnpinfo: vendor=0x1002 device=0x95c5 subvendor=0x1043 subdevice=0x01d4 class=0x030000 dev.vgapci.0.%parent: pci1 dev.drm.0.%desc: ATI Radeon HD 3450 dev.drm.0.%driver: drm dev.drm.0.%parent: vgapci0 dev.uhci.0.%desc: UHCI (generic) USB controller dev.uhci.0.%driver: uhci dev.uhci.0.%location: slot=26 function=0 handle=\_SB_.PCI0.USB3 dev.uhci.0.%pnpinfo: vendor=0x8086 device=0x2937 subvendor=0x1462 subdevice=0x7395 class=0x0c0300 dev.uhci.0.%parent: pci0 dev.uhci.0.wake: 0 dev.uhci.1.%desc: UHCI (generic) USB controller dev.uhci.1.%driver: uhci dev.uhci.1.%location: slot=26 function=1 handle=\_SB_.PCI0.USB4 dev.uhci.1.%pnpinfo: vendor=0x8086 device=0x2938 subvendor=0x1462 subdevice=0x7395 class=0x0c0300 dev.uhci.1.%parent: pci0 dev.uhci.1.wake: 0 dev.uhci.2.%desc: UHCI (generic) USB controller dev.uhci.2.%driver: uhci dev.uhci.2.%location: slot=26 function=2 dev.uhci.2.%pnpinfo: vendor=0x8086 device=0x2939 subvendor=0x0000 subdevice=0x0000 class=0x0c0300 dev.uhci.2.%parent: pci0 dev.uhci.3.%desc: UHCI (generic) USB controller dev.uhci.3.%driver: uhci dev.uhci.3.%location: slot=29 function=0 handle=\_SB_.PCI0.USB0 dev.uhci.3.%pnpinfo: vendor=0x8086 device=0x2934 subvendor=0x1462 subdevice=0x7395 class=0x0c0300 dev.uhci.3.%parent: pci0 dev.uhci.3.wake: 0 dev.uhci.4.%desc: UHCI (generic) USB controller dev.uhci.4.%driver: uhci dev.uhci.4.%location: slot=29 function=1 handle=\_SB_.PCI0.USB1 dev.uhci.4.%pnpinfo: vendor=0x8086 device=0x2935 subvendor=0x1462 subdevice=0x7395 class=0x0c0300 dev.uhci.4.%parent: pci0 dev.uhci.4.wake: 0 dev.uhci.5.%desc: UHCI (generic) USB controller dev.uhci.5.%driver: uhci dev.uhci.5.%location: slot=29 function=2 handle=\_SB_.PCI0.USB2 dev.uhci.5.%pnpinfo: vendor=0x8086 device=0x2936 subvendor=0x1462 subdevice=0x7395 class=0x0c0300 dev.uhci.5.%parent: pci0 dev.uhci.5.wake: 0 dev.usb.0.%desc: UHCI (generic) USB controller dev.usb.0.%driver: usb dev.usb.0.%parent: uhci0 dev.usb.1.%desc: UHCI (generic) USB controller dev.usb.1.%driver: usb dev.usb.1.%parent: uhci1 dev.usb.2.%desc: UHCI (generic) USB controller dev.usb.2.%driver: usb dev.usb.2.%parent: uhci2 dev.usb.3.%desc: EHCI (generic) USB 2.0 controller dev.usb.3.%driver: usb dev.usb.3.%parent: ehci0 dev.usb.4.%desc: UHCI (generic) USB controller dev.usb.4.%driver: usb dev.usb.4.%parent: uhci3 dev.usb.5.%desc: UHCI (generic) USB controller dev.usb.5.%driver: usb dev.usb.5.%parent: uhci4 dev.usb.6.%desc: UHCI (generic) USB controller dev.usb.6.%driver: usb dev.usb.6.%parent: uhci5 dev.usb.7.%desc: EHCI (generic) USB 2.0 controller dev.usb.7.%driver: usb dev.usb.7.%parent: ehci1 dev.uhub.0.%desc: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 dev.uhub.0.%driver: uhub dev.uhub.0.%parent: usb0 dev.uhub.1.%desc: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 dev.uhub.1.%driver: uhub dev.uhub.1.%parent: usb1 dev.uhub.2.%desc: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 dev.uhub.2.%driver: uhub dev.uhub.2.%parent: usb2 dev.uhub.3.%desc: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 dev.uhub.3.%driver: uhub dev.uhub.3.%parent: usb3 dev.uhub.4.%desc: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 dev.uhub.4.%driver: uhub dev.uhub.4.%parent: usb4 dev.uhub.5.%desc: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 dev.uhub.5.%driver: uhub dev.uhub.5.%parent: usb5 dev.uhub.6.%desc: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 dev.uhub.6.%driver: uhub dev.uhub.6.%parent: usb6 dev.uhub.7.%desc: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 dev.uhub.7.%driver: uhub dev.uhub.7.%parent: usb7 dev.ehci.0.%desc: EHCI (generic) USB 2.0 controller dev.ehci.0.%driver: ehci dev.ehci.0.%location: slot=26 function=7 handle=\_SB_.PCI0.USBE dev.ehci.0.%pnpinfo: vendor=0x8086 device=0x293c subvendor=0x1462 subdevice=0x7395 class=0x0c0320 dev.ehci.0.%parent: pci0 dev.ehci.0.wake: 0 dev.ehci.1.%desc: EHCI (generic) USB 2.0 controller dev.ehci.1.%driver: ehci dev.ehci.1.%location: slot=29 function=7 handle=\_SB_.PCI0.EUSB dev.ehci.1.%pnpinfo: vendor=0x8086 device=0x293a subvendor=0x1462 subdevice=0x7395 class=0x0c0320 dev.ehci.1.%parent: pci0 dev.ehci.1.wake: 0 dev.atapci.0.%desc: JMicron JMB363 SATA300 controller dev.atapci.0.%driver: atapci dev.atapci.0.%location: slot=0 function=0 handle=\_SB_.PCI0.PEX4.JMB0 dev.atapci.0.%pnpinfo: vendor=0x197b device=0x2363 subvendor=0x197b subdevice=0x2380 class=0x010185 dev.atapci.0.%parent: pci3 dev.atapci.1.%desc: Intel ICH9 SATA300 controller dev.atapci.1.%driver: atapci dev.atapci.1.%location: slot=31 function=2 handle=\_SB_.PCI0.SAT0 dev.atapci.1.%pnpinfo: vendor=0x8086 device=0x2921 subvendor=0x1462 subdevice=0x7395 class=0x01018f dev.atapci.1.%parent: pci0 dev.atapci.2.%desc: Intel ICH9 SATA300 controller dev.atapci.2.%driver: atapci dev.atapci.2.%location: slot=31 function=5 handle=\_SB_.PCI0.SAT1 dev.atapci.2.%pnpinfo: vendor=0x8086 device=0x2926 subvendor=0x1462 subdevice=0x7395 class=0x010185 dev.atapci.2.%parent: pci0 dev.ata.2.%desc: ATA channel 0 dev.ata.2.%driver: ata dev.ata.2.%parent: atapci0 dev.ata.3.%desc: ATA channel 1 dev.ata.3.%driver: ata dev.ata.3.%parent: atapci0 dev.ata.4.%desc: ATA channel 2 dev.ata.4.%driver: ata dev.ata.4.%parent: atapci0 dev.ata.5.%desc: ATA channel 0 dev.ata.5.%driver: ata dev.ata.5.%parent: atapci1 dev.ata.6.%desc: ATA channel 1 dev.ata.6.%driver: ata dev.ata.6.%parent: atapci1 dev.ata.7.%desc: ATA channel 0 dev.ata.7.%driver: ata dev.ata.7.%parent: atapci2 dev.ata.8.%desc: ATA channel 1 dev.ata.8.%driver: ata dev.ata.8.%parent: atapci2 dev.re.0.%desc: RealTek 8168/8168B/8168C/8168CP/8168D/8111B/8111C/8111CP PCIe Gigabit Ethernet dev.re.0.%driver: re dev.re.0.%location: slot=0 function=0 dev.re.0.%pnpinfo: vendor=0x10ec device=0x8168 subvendor=0x1462 subdevice=0x395c class=0x020000 dev.re.0.%parent: pci4 dev.miibus.0.%desc: MII bus dev.miibus.0.%driver: miibus dev.miibus.0.%parent: re0 dev.rgephy.0.%desc: RTL8169S/8110S/8211B media interface dev.rgephy.0.%driver: rgephy dev.rgephy.0.%location: phyno=1 dev.rgephy.0.%pnpinfo: oui=0x732 model=0x11 rev=0x2 dev.rgephy.0.%parent: miibus0 dev.isab.0.%desc: PCI-ISA bridge dev.isab.0.%driver: isab dev.isab.0.%location: slot=31 function=0 handle=\_SB_.PCI0.SBRG dev.isab.0.%pnpinfo: vendor=0x8086 device=0x2918 subvendor=0x0000 subdevice=0x0000 class=0x060100 dev.isab.0.%parent: pci0 dev.isa.0.%desc: ISA bus dev.isa.0.%driver: isa dev.isa.0.%parent: isab0 dev.acpi_button.0.%desc: Sleep Button dev.acpi_button.0.%driver: acpi_button dev.acpi_button.0.%location: handle=\_SB_.SLPB dev.acpi_button.0.%pnpinfo: _HID=PNP0C0E _UID=0 dev.acpi_button.0.%parent: acpi0 dev.acpi_button.0.wake: 1 dev.acpi_button.1.%desc: Power Button dev.acpi_button.1.%driver: acpi_button dev.acpi_button.1.%location: handle=\_SB_.PWRB dev.acpi_button.1.%pnpinfo: _HID=PNP0C0C _UID=170 dev.acpi_button.1.%parent: acpi0 dev.acpi_button.1.wake: 1 dev.atkbdc.0.%desc: Keyboard controller (i8042) dev.atkbdc.0.%driver: atkbdc dev.atkbdc.0.%location: handle=\_SB_.PCI0.SBRG.PS2K dev.atkbdc.0.%pnpinfo: _HID=PNP0303 _UID=0 dev.atkbdc.0.%parent: acpi0 dev.atkbdc.0.wake: 0 dev.atkbd.0.%desc: AT Keyboard dev.atkbd.0.%driver: atkbd dev.atkbd.0.%parent: atkbdc0 dev.psmcpnp.0.%desc: PS/2 mouse port dev.psmcpnp.0.%driver: psmcpnp dev.psmcpnp.0.%location: handle=\_SB_.PCI0.SBRG.PS2M dev.psmcpnp.0.%pnpinfo: _HID=PNP0F03 _UID=0 dev.psmcpnp.0.%parent: acpi0 dev.psmcpnp.0.wake: 0 dev.psm.0.%desc: PS/2 Mouse dev.psm.0.%driver: psm dev.psm.0.%parent: atkbdc0 dev.sio.0.%desc: 16550A-compatible COM port dev.sio.0.%driver: sio dev.sio.0.%location: handle=\_SB_.PCI0.SBRG.UAR1 dev.sio.0.%pnpinfo: _HID=PNP0501 _UID=1 dev.sio.0.%parent: acpi0 dev.sio.1.%desc: 16550A-compatible COM port dev.sio.1.%driver: sio dev.sio.1.%location: handle=\_SB_.PCI0.SBRG.UAR2 dev.sio.1.%pnpinfo: _HID=PNP0501 _UID=2 dev.sio.1.%parent: acpi0 dev.ppc.0.%desc: Parallel port dev.ppc.0.%driver: ppc dev.ppc.0.%location: handle=\_SB_.PCI0.SBRG.LPTE dev.ppc.0.%pnpinfo: _HID=PNP0400 _UID=0 dev.ppc.0.%parent: acpi0 dev.ppbus.0.%desc: Parallel port bus dev.ppbus.0.%driver: ppbus dev.ppbus.0.%parent: ppc0 dev.plip.0.%desc: PLIP network interface dev.plip.0.%driver: plip dev.plip.0.%parent: ppbus0 dev.lpt.0.%desc: Printer dev.lpt.0.%driver: lpt dev.lpt.0.%parent: ppbus0 dev.ppi.0.%desc: Parallel I/O dev.ppi.0.%driver: ppi dev.ppi.0.%parent: ppbus0 dev.atdma.0.%desc: AT DMA controller dev.atdma.0.%driver: atdma dev.atdma.0.%location: handle=\_SB_.PCI0.SBRG.DMAD dev.atdma.0.%pnpinfo: _HID=PNP0200 _UID=0 dev.atdma.0.%parent: acpi0 dev.attimer.0.%desc: AT timer dev.attimer.0.%driver: attimer dev.attimer.0.%location: handle=\_SB_.PCI0.SBRG.TMR_ dev.attimer.0.%pnpinfo: _HID=PNP0100 _UID=0 dev.attimer.0.%parent: acpi0 dev.attimer.1.%desc: AT realtime clock dev.attimer.1.%driver: attimer dev.attimer.1.%location: handle=\_SB_.PCI0.SBRG.RTC0 dev.attimer.1.%pnpinfo: _HID=PNP0B00 _UID=0 dev.attimer.1.%parent: acpi0 dev.fpupnp.0.%desc: Legacy ISA coprocessor support dev.fpupnp.0.%driver: fpupnp dev.fpupnp.0.%location: handle=\_SB_.PCI0.SBRG.COPR dev.fpupnp.0.%pnpinfo: _HID=PNP0C04 _UID=0 dev.fpupnp.0.%parent: acpi0 dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU1 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.temperature: 44 dev.cpu.0.freq: 2493 dev.cpu.0.freq_levels: 2493/-1 2181/-1 1869/-1 1558/-1 1246/-1 934/-1 623/-1 311/-1 dev.cpu.0.cx_supported: C1/0 dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_usage: 100.00% dev.cpu.1.%desc: ACPI CPU dev.cpu.1.%driver: cpu dev.cpu.1.%location: handle=\_PR_.CPU2 dev.cpu.1.%pnpinfo: _HID=none _UID=0 dev.cpu.1.%parent: acpi0 dev.cpu.1.temperature: 46 dev.cpu.1.cx_supported: C1/0 dev.cpu.1.cx_lowest: C1 dev.cpu.1.cx_usage: 100.00% dev.coretemp.0.%desc: CPU On-Die Thermal Sensors dev.coretemp.0.%driver: coretemp dev.coretemp.0.%parent: cpu0 dev.coretemp.1.%desc: CPU On-Die Thermal Sensors dev.coretemp.1.%driver: coretemp dev.coretemp.1.%parent: cpu1 dev.p4tcc.0.%desc: CPU Frequency Thermal Control dev.p4tcc.0.%driver: p4tcc dev.p4tcc.0.%parent: cpu0 dev.p4tcc.0.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1 dev.p4tcc.1.%desc: CPU Frequency Thermal Control dev.p4tcc.1.%driver: p4tcc dev.p4tcc.1.%parent: cpu1 dev.p4tcc.1.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1 dev.cpufreq.0.%driver: cpufreq dev.cpufreq.0.%parent: cpu0 dev.cpufreq.1.%driver: cpufreq dev.cpufreq.1.%parent: cpu1 dev.apic.0.%desc: APIC resources dev.apic.0.%driver: apic dev.apic.0.%parent: nexus0 dev.ichwd.0.%desc: Intel ICH9 watchdog timer dev.ichwd.0.%driver: ichwd dev.ichwd.0.%parent: isa0 dev.orm.0.%desc: ISA Option ROMs dev.orm.0.%driver: orm dev.orm.0.%parent: isa0 dev.sc.0.%desc: System console dev.sc.0.%driver: sc dev.sc.0.%parent: isa0 dev.vga.0.%desc: Generic ISA VGA dev.vga.0.%driver: vga dev.vga.0.%parent: isa0 dev.acd.0.%desc: ATAPI DVD A DH20A4P/9P59 dev.acd.0.%driver: acd dev.acd.0.%parent: ata4 dev.ad.10.%desc: WDC WD6400AAKS-00A7B2/01.03B01 dev.ad.10.%driver: ad dev.ad.10.%parent: ata5 dev.hdac.0.%desc: Intel 82801I High Definition Audio Controller dev.hdac.0.%driver: hdac dev.hdac.0.%location: slot=27 function=0 dev.hdac.0.%pnpinfo: vendor=0x8086 device=0x293e subvendor=0x1462 subdevice=0x7395 class=0x040300 dev.hdac.0.%parent: pci0 dev.hdac.0.polling: 0 dev.hdac.0.polling_interval: 250 dev.hdac.0.pindump: 0 dev.hdac.1.%desc: ATI RV620 High Definition Audio Controller dev.hdac.1.%driver: hdac dev.hdac.1.%location: slot=0 function=1 dev.hdac.1.%pnpinfo: vendor=0x1002 device=0xaa28 subvendor=0x1043 subdevice=0xaa28 class=0x040300 dev.hdac.1.%parent: pci1 dev.hdac.1.polling: 0 dev.hdac.1.polling_interval: 250 dev.hdac.1.pindump: 0 dev.pcm.0.%desc: HDA Realtek ALC888 PCM #0 Analog dev.pcm.0.%driver: pcm dev.pcm.0.%parent: hdac0 dev.pcm.0.play.vchans: 1 dev.pcm.0.play.vchanrate: 48000 dev.pcm.0.play.vchanformat: s16le dev.pcm.0.rec.vchans: 1 dev.pcm.0.rec.vchanrate: 48000 dev.pcm.0.rec.vchanformat: s16le dev.pcm.0.buffersize: 16384 dev.pcm.1.%desc: HDA Realtek ALC888 PCM #1 Analog dev.pcm.1.%driver: pcm dev.pcm.1.%parent: hdac0 dev.pcm.1.play.vchans: 1 dev.pcm.1.play.vchanrate: 48000 dev.pcm.1.play.vchanformat: s16le dev.pcm.1.rec.vchans: 1 dev.pcm.1.rec.vchanrate: 48000 dev.pcm.1.rec.vchanformat: s16le dev.pcm.1.buffersize: 16384 dev.pcm.2.%desc: HDA Realtek ALC888 PCM #2 Digital dev.pcm.2.%driver: pcm dev.pcm.2.%parent: hdac0 dev.pcm.2.play.vchans: 1 dev.pcm.2.play.vchanrate: 48000 dev.pcm.2.play.vchanformat: s16le dev.pcm.2.buffersize: 16384 dev.pcm.3.%desc: HDA ATI R6xx HDMI PCM #0 Digital dev.pcm.3.%driver: pcm dev.pcm.3.%parent: hdac1 dev.pcm.3.play.vchans: 1 dev.pcm.3.play.vchanrate: 48000 dev.pcm.3.play.vchanformat: s16le dev.pcm.3.buffersize: 16384 From onemda at gmail.com Fri May 8 10:34:55 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Fri May 8 10:35:01 2009 Subject: Fighting for the power. In-Reply-To: <20090507.001059.-1558772981.imp@bsdimp.com> References: <49FE1826.4060000@FreeBSD.org> <3a142e750905040240g58152e69p6fcb797a5e026426@mail.gmail.com> <20090507.001059.-1558772981.imp@bsdimp.com> Message-ID: <3a142e750905080334qb62dcb5hcd07ce028a4ff035@mail.gmail.com> On 5/7/09, M. Warner Losh wrote: > In message: <3a142e750905040240g58152e69p6fcb797a5e026426@mail.gmail.com> > "Paul B. Mahol" writes: > : On 5/4/09, Alexander Motin wrote: > : > 2. PCI devices > : > PCI bus provides method to control device power. For example, I have > : > completely no use for my FireWire controller and most of time - EHCI USB > : > controller. Disabling them allows me to save about 3W of power. To > : > disable all unneeded PCI devices you should build kernel without their > : > drivers and add to loader.conf: > : > hw.pci.do_power_nodriver=3 > : > To enable devices back all you need to do is just load their drivers as > : > modules. > : > : Unloading modules doesnt put them back into into D3 state. > : You are forced to load some another module again to put wanted device > : into D3 state. > > It should. If it isn't, that's a bug. It's a bug. On machine resume(pci_resume), pci_cfg_restore() is called causing D3 -> D0 for all devices(including not attached ones). Unloading module/detaching device doesn't call pci_cfg_save. Should device_detach routine be used or new one like pci_driver_removed() implemented? -- Paul From imp at bsdimp.com Fri May 8 13:10:39 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Fri May 8 13:10:46 2009 Subject: Fighting for the power. In-Reply-To: <3a142e750905080334qb62dcb5hcd07ce028a4ff035@mail.gmail.com> References: <3a142e750905040240g58152e69p6fcb797a5e026426@mail.gmail.com> <20090507.001059.-1558772981.imp@bsdimp.com> <3a142e750905080334qb62dcb5hcd07ce028a4ff035@mail.gmail.com> Message-ID: <20090508.070659.1622573996.imp@bsdimp.com> In message: <3a142e750905080334qb62dcb5hcd07ce028a4ff035@mail.gmail.com> "Paul B. Mahol" writes: : On 5/7/09, M. Warner Losh wrote: : > In message: <3a142e750905040240g58152e69p6fcb797a5e026426@mail.gmail.com> : > "Paul B. Mahol" writes: : > : On 5/4/09, Alexander Motin wrote: : > : > 2. PCI devices : > : > PCI bus provides method to control device power. For example, I have : > : > completely no use for my FireWire controller and most of time - EHCI USB : > : > controller. Disabling them allows me to save about 3W of power. To : > : > disable all unneeded PCI devices you should build kernel without their : > : > drivers and add to loader.conf: : > : > hw.pci.do_power_nodriver=3 : > : > To enable devices back all you need to do is just load their drivers as : > : > modules. : > : : > : Unloading modules doesnt put them back into into D3 state. : > : You are forced to load some another module again to put wanted device : > : into D3 state. : > : > It should. If it isn't, that's a bug. : : It's a bug. : : On machine resume(pci_resume), pci_cfg_restore() is called causing D3 -> D0 for : all devices(including not attached ones). : Unloading module/detaching device doesn't call pci_cfg_save. : : Should device_detach routine be used or new one like : pci_driver_removed() implemented? No. device_detach shouldn't be used for this. This should happen all in the PCI bus code when do_power_nodriver is > 0. Warner From avg at icyb.net.ua Fri May 8 13:44:25 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Fri May 8 13:44:30 2009 Subject: acpi problem ? In-Reply-To: <4A0397B2.5000303@gmail.com> References: <4A0397B2.5000303@gmail.com> Message-ID: <4A043734.7080700@icyb.net.ua> on 08/05/2009 05:23 Dsewnr Lu said the following: > Hi all, > > My command "shutdown -p now" can not poweroff automatically, it halt on > the last screen with uptime and my keyboard is hang, too. > And "reboot" or "shutdown -h now" work fine. Is it an acpi problem ? > There're my kernel config, dmesg and sysctl message. Any idea ? > > Thanks, It might very well be. Some older BIOSes included ACPI tables with incorrect information. I don't think that this happens often on modern system, but it's still possible. Please share your acpidump -dt output. -- Andriy Gapon From avg at icyb.net.ua Fri May 8 16:10:47 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Fri May 8 16:10:56 2009 Subject: acpi problem ? In-Reply-To: <4A045715.3030503@gmail.com> References: <4A0397B2.5000303@gmail.com> <4A043734.7080700@icyb.net.ua> <4A045715.3030503@gmail.com> Message-ID: <4A045983.9060600@icyb.net.ua> on 08/05/2009 19:00 Dsewnr Lu said the following: > This is my acpidump -dt output. I couldn't find anything obviously wrong, sorry. Maybe somebody else could spot something. -- Andriy Gapon From dsewnr.buffer at gmail.com Fri May 8 16:13:18 2009 From: dsewnr.buffer at gmail.com (Dsewnr Lu) Date: Fri May 8 16:13:24 2009 Subject: acpi problem ? In-Reply-To: <4A045983.9060600@icyb.net.ua> References: <4A0397B2.5000303@gmail.com> <4A043734.7080700@icyb.net.ua> <4A045715.3030503@gmail.com> <4A045983.9060600@icyb.net.ua> Message-ID: <4A045A18.90807@gmail.com> Andriy Gapon wrote: > on 08/05/2009 19:00 Dsewnr Lu said the following: > >> This is my acpidump -dt output. >> > > I couldn't find anything obviously wrong, sorry. Maybe somebody else could spot > something. > > Thanks a lot. :) Dsewnr Lu From rmgls at free.fr Sat May 9 16:06:59 2009 From: rmgls at free.fr (rmgls@free.fr) Date: Sat May 9 16:07:06 2009 Subject: Temperature problem Message-ID: <20090509155059.6D10481808E@smtp3-g21.free.fr> Hello everyone, i encounter a temperature problem on my laptop a SONY VAIO S5, running current. This problem occurs since perhaps five months only. when compiling some big programs, say src and even, only libc, i see on a distant console (dconschat): acpi_tz0 temperature 93.9C decreasing clock speed from 2133MHZ to 1867MHZ. and the machine freeze. this happen without any modification of the clock hz in rc.loader. Please, can you help to solve this problem? many thanks. Raoul rmgls@free.fr P.S. please cc: rmgls@free.fr, i am not subscribed. From ghostp at mcss.hu Sat May 9 20:53:15 2009 From: ghostp at mcss.hu (=?ISO-8859-1?Q?Sz=E9kv=F6lgyi_P=E9ter?=) Date: Sat May 9 20:53:23 2009 Subject: FreeBSD no brightness control on Acer laptop Message-ID: <4A05E6F6.8000309@mcss.hu> Hi everyone, I have a Acer Extensa 5620 laptop and i didn't change the brightness with keys or sysctl value. I loaded asus, ibm and other laptop acpi modul, but nothing change. Anyone has an idea how can i change the brightness fater the system booted? ( Without ACPI i can change, the brightness. ) I send a PR too: http://www.freebsd.org/cgi/query-pr.cgi?pr=132535 Now my system is: FreeBSD dzsy-note.dzsy.org 7.2-STABLE FreeBSD 7.2-STABLE #0: Thu May 7 23:13:54 CEST 2009 ... i386 Thanks, Peter From ghostp at dzsy.org Sat May 9 21:09:55 2009 From: ghostp at dzsy.org (=?ISO-8859-1?Q?Sz=E9kv=F6lgyi_P=E9ter?=) Date: Sat May 9 21:10:02 2009 Subject: No brightness control on Acer laptop Message-ID: <4A05EA96.4090908@dzsy.org> Hi everyone, I have a Acer Extensa 5620 laptop and i didn't change the brightness with keys or sysctl value. I loaded asus, ibm and other laptop acpi modul, but nothing change. Anyone has an idea how can i change the brightness fater the system booted? ( Without ACPI i can change, the brightness. ) I send a PR too: http://www.freebsd.org/cgi/query-pr.cgi?pr=132535 Now my system is: FreeBSD dzsy-note.dzsy.org 7.2-STABLE FreeBSD 7.2-STABLE #0: Thu May 7 23:13:54 CEST 2009 ... i386 Thanks, Peter From kientzle at freebsd.org Mon May 11 06:14:00 2009 From: kientzle at freebsd.org (Tim Kientzle) Date: Mon May 11 06:14:11 2009 Subject: Fighting for the power. In-Reply-To: <49FE1826.4060000@FreeBSD.org> References: <49FE1826.4060000@FreeBSD.org> Message-ID: <4A07BC4D.7080604@freebsd.org> Alexander Motin wrote: > I would like to summarize some of my knowledge on reducing FreeBSD power > consumption and describe some new things I have recently implemented in > 8-CURRENT. ... This is great work! > - C3 state allows CPU completely stop all internal clocks, reduce > voltage and disconnect from system bus. This state gives additional > power saving effect, but .... local APIC timers in > each CPU core, used by FreeBSD as event sources on SMP, are not > functioning. ... Originally, before SMP era, FreeBSD used i8254 (for HZ) > and RTC (for stats) chipset timers. I have made changes to 8-CURRENT to > resurrect them for SMP systems. To use them, you can disable local APIC > timers by adding to /boot/loader.conf: > hint.apic.0.clock=0 I experimented a little bit with this and had a few odd experiences: sysctl hw.acpi.cpu.cx_lowest=C3 did drop power consumption significantly but made the system pretty unresponsive. In particular, the system completely hung at shutdown. I presume the hang was the APIC timer problem you mentioned. I started to try the "hint.apic.0.clock", but noticed in your commit r191720: > Add hint.apic.0.clock tunable. Setting it 0 disables using > LAPIC timers as hard-/stat-/profclock sources falling back > to using i8254 and rtc timers. > ... > This technique is not working for SMP yet, as only one CPU > receives timer interrupts. But I think that problem could > be fixed by forwarding interrupts to other CPUs with IPI. Is anyone looking at this yet? Tim From bugmaster at FreeBSD.org Mon May 11 11:06:48 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon May 11 11:07:08 2009 Subject: Current problem reports assigned to freebsd-acpi@FreeBSD.org Message-ID: <200905111106.n4BB6lH9085838@freefall.freebsd.org> 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/132602 acpi [acpi] ACPI Problem with Intel SS4200: System does not o kern/130683 acpi [ACPI] shutdown hangs after syncing disks - ACPI race? o i386/129953 acpi [acpi] ACPI timeout (CDROM) with Shuttle X27D o kern/129618 acpi [acpi] Problem with ACPI on HP Pavilion DV2899 laptop o kern/129563 acpi [acpi] sleep broken on IBM/Lenovo T61 in amd64 mode o kern/128639 acpi [patch] [acpi_asus] acpi for ASUS A6F,A3E,A3F,A3N not f kern/128634 acpi [patch] fix acpi_asus(4) in asus a6f laptop o kern/127581 acpi [patch] [acpi_sony] Add support for more Sony features o kern/124744 acpi [acpi] [patch] incorrect _BST result validation for To o kern/124412 acpi [acpi] power off error on Toshiba M40 laptop o kern/123039 acpi [acpi] ACPI AML_BUFFER_LIMIT errors during boot o kern/121504 acpi [patch] Correctly set hw.acpi.osname on certain machin f kern/121454 acpi [pst] Promise SuperTrak SX6000 does not load during bo o kern/121102 acpi [acpi_fujitsu] [patch] update acpi_fujitsu for the P80 o kern/120515 acpi [acpi] [patch] acpi_alloc_wakeup_handler: can't alloc o kern/119356 acpi [acpi]: i386 ACPI wakeup not work due resource exhaust o kern/119200 acpi [acpi] Lid close switch suspends CPU for 1 second on H o kern/118973 acpi [acpi]: Kernel panic with acpi boot o kern/117605 acpi [acpi] [request] add debug.cpufreq.highest o kern/116939 acpi [acpi] PCI-to-PCI misconfigured for bus three and can o i386/114562 acpi [acpi] cardbus is dead after s3 on Thinkpad T43 with a o kern/114165 acpi [acpi] Dell C810 - ACPI problem s kern/112544 acpi [acpi] [patch] Add High Precision Event Timer Driver f o kern/108954 acpi [acpi] 'sleep(1)' sleeps >1 seconds when speedstep (Cx o kern/108695 acpi [acpi]: Fatal trap 9: general protection fault when in o kern/108488 acpi [acpi] ACPI-1304: *** Error: Method execution failed o kern/108017 acpi [acpi]: Acer Aspire 5600 o kern/106924 acpi [acpi] ACPI resume returns g_vfs_done() errors and ker o kern/105537 acpi [acpi] problems in acpi on HP Compaq nc6320 o kern/104625 acpi ACPI on ASUS A8N-32 SLI/ASUS P4P800 does not show ther o kern/102252 acpi acpi thermal does not work on Abit AW8D (intel 975) o kern/97383 acpi Volume buttons on IBM Thinkpad crash system with ACPI s i386/91748 acpi acpi problem on Acer TravelMare 4652LMi (nvidia panic, s kern/91038 acpi [panic] [ata] [acpi] 6.0-RELEASE on Fujitsu Siemens Am s kern/90243 acpi Laptop fan doesn't turn off (ACPI enabled) (Packard Be f kern/89411 acpi [acpi] acpiconf bug o i386/83018 acpi [install] Installer will not boot on Asus P4S8X BIOS 1 o kern/81000 acpi [apic] Via 8235 sound card worked great with FreeBSD 5 o i386/79081 acpi ACPI suspend/resume not working on HP nx6110 o kern/76950 acpi ACPI wrongly blacklisted on Micron ClientPro 766Xi sys s kern/73823 acpi [request] acpi / power-on by timer support o i386/72566 acpi ACPI, FreeBSD disables fan on Compaq Armada 1750 o i386/69750 acpi Boot without ACPI failed on ASUS L5 o kern/56024 acpi ACPI suspend drains battery while in S3 o i386/55661 acpi ACPI suspend/resume problem on ARMADA M700 o i386/54756 acpi ACPI suspend/resume problem on CF-W2 laptop 46 problems total. From mav at FreeBSD.org Mon May 11 12:22:11 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Mon May 11 12:22:29 2009 Subject: Fighting for the power. In-Reply-To: <4A07BC4D.7080604@freebsd.org> References: <49FE1826.4060000@FreeBSD.org> <4A07BC4D.7080604@freebsd.org> Message-ID: <4A081868.6010906@FreeBSD.org> Tim Kientzle wrote: > I started to try the "hint.apic.0.clock", but noticed > in your commit r191720: > Alexander Motin wrote: >> Add hint.apic.0.clock tunable. Setting it 0 disables using >> LAPIC timers as hard-/stat-/profclock sources falling back >> to using i8254 and rtc timers. >> ... >> This technique is not working for SMP yet, as only one CPU >> receives timer interrupts. But I think that problem could >> be fixed by forwarding interrupts to other CPUs with IPI. > > Is anyone looking at this yet? I have implemented SMP support for i386 and amd64 in some of my later commits. -- Alexander Motin From jhb at freebsd.org Mon May 11 16:49:39 2009 From: jhb at freebsd.org (John Baldwin) Date: Mon May 11 16:50:36 2009 Subject: Garbled output from kgdb? In-Reply-To: <200905051743.03520.jkim@FreeBSD.org> References: <49F8B859.7060908@umn.edu> <200905051609.38689.jkim@FreeBSD.org> <200905051743.03520.jkim@FreeBSD.org> Message-ID: <200905110952.01736.jhb@freebsd.org> On Tuesday 05 May 2009 5:43:01 pm Jung-uk Kim wrote: > On Tuesday 05 May 2009 04:09 pm, Jung-uk Kim wrote: > > On Tuesday 05 May 2009 12:51 pm, Andriy Gapon wrote: > > > BTW, this issue seems to be fixed in Jung-uk's acpi patches for > > > newer acpica imports, but it is not fixed both in stable/7 and > > > head. > > > > Yes, it was fixed in my patchsets long ago, which uses spin lock > > for AcpiOsAcquireLock(). :-) > > The attached patch is for -STABLE. Note that it is only compile > tested on amd64. This looks fine to test. The patch has gratuitous style changes I wouldn't include in a commit though. -- John Baldwin From jkim at FreeBSD.org Mon May 11 17:45:42 2009 From: jkim at FreeBSD.org (Jung-uk Kim) Date: Mon May 11 17:45:54 2009 Subject: Garbled output from kgdb? In-Reply-To: <200905110952.01736.jhb@freebsd.org> References: <49F8B859.7060908@umn.edu> <200905051743.03520.jkim@FreeBSD.org> <200905110952.01736.jhb@freebsd.org> Message-ID: <200905111345.29761.jkim@FreeBSD.org> On Monday 11 May 2009 09:52 am, John Baldwin wrote: > On Tuesday 05 May 2009 5:43:01 pm Jung-uk Kim wrote: > > On Tuesday 05 May 2009 04:09 pm, Jung-uk Kim wrote: > > > On Tuesday 05 May 2009 12:51 pm, Andriy Gapon wrote: > > > > BTW, this issue seems to be fixed in Jung-uk's acpi patches > > > > for newer acpica imports, but it is not fixed both in > > > > stable/7 and head. > > > > > > Yes, it was fixed in my patchsets long ago, which uses spin > > > lock for AcpiOsAcquireLock(). :-) > > > > The attached patch is for -STABLE. Note that it is only compile > > tested on amd64. > > This looks fine to test. The patch has gratuitous style changes I > wouldn't include in a commit though. It should work but I don't plan to commit it any time soon. :-) In fact, the patch was meant to be a rewrite for new ACPI-CA, which actually has a real mutex. Currently, mutex is emulated with semaphore. The problem is semaphore has no concept of ownership while mutex does, i.e., any thread can acquire/release it without checking its ownership or order. FYI, the OSL API (ACPI_MUTEX_TYPE) is finalized in ACPI-CA 20081204. Jung-uk Kim From jhb at freebsd.org Mon May 11 18:25:13 2009 From: jhb at freebsd.org (John Baldwin) Date: Mon May 11 18:25:25 2009 Subject: Fwd: Kernel panic on 7.2-RC1 when booting with ACPI enabled kernel. In-Reply-To: <43b1bb350905011230p1372e1ffw5ab61985e7672e19@mail.gmail.com> References: <43b1bb350904230622u4b7790f0p9f665b649c97a3b@mail.gmail.com> <200905011450.13899.jhb@freebsd.org> <43b1bb350905011230p1372e1ffw5ab61985e7672e19@mail.gmail.com> Message-ID: <200905111425.01887.jhb@freebsd.org> On Friday 01 May 2009 3:30:28 pm Magnus Kling wrote: > 2009/5/1 John Baldwin > > > On Friday 01 May 2009 2:30:28 pm Magnus Kling wrote: > > > 2009/4/30 John Baldwin > > > > > > > On Saturday 25 April 2009 6:27:23 am Magnus Kling wrote: > > > > > 2009/4/24 John Baldwin > > > > > > Can you do 'frame 10' followed by 'p *(struct acpi_pci_devinfo > > > > > > *)child->ivars' > > > > > > > > > > > > -- > > > > > > John Baldwin > > > > > > > > > > > > > > > Sure, no problem. This is a none critical server so I can do alot of > > > > > debugging and testing if that is needed. > > > > > > > > > > > > > > > (kgdb) frame 10 > > > > > #10 0xc0db4ca8 in acpi_pci_child_location_str_method > > (cbdev=0xc2212680, > > > > > child=0xc2243400, buf=0xc22c2400 "slot=0 function=0 handle=", > > > > > buflen=1024) > > > > > at > > /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/acpi_pci.c:150 > > > > > 150 strlcat(buf, acpi_name(dinfo->ap_handle), buflen); > > > > > > > > > > (kgdb) p *(struct acpi_pci_devinfo *)child->ivars > > > > > $1 = {ap_dinfo = {pci_links = {stqe_next = 0xc0b00f8c}, resources = { > > > > > stqh_first = 0xc0b00f8c, stqh_last = 0x1030000}, cfg = {dev = > > 0x0, > > > > > bar = {4, 0, 0, 3257136600, 0, 0}, bios = 0, subvendor = 0, > > > > > subdevice = 0, vendor = 0, device = 0, cmdreg = 0, statreg = 0, > > > > > baseclass = 0 '\0', subclass = 0 '\0', progif = 0 '\0', revid = > > 0 > > > > > > > > Hmm, this is all completely wrong and trashed. What if you do 'p > > *child'? > > > > > > > > -- > > > > John Baldwin > > > > > > > (kgdb) p *child > > > $2 = {ops = 0xc2161800, link = {tqe_next = 0xc2243380, tqe_prev = > > > 0xc2243484}, devlink = {tqe_next = 0xc2243380, tqe_prev = 0xc224348c}, > > > parent = 0xc2212680, children = {tqh_first = 0xc2262880, tqh_last = > > > 0xc2262704}, driver = 0xc0b7066c, devclass = 0xc211e240, unit = 0, > > > nameunit = 0xc2241640 "atapci0", desc = 0xc223f900 "Promise PDC20621 > > > UDMA100 controller", busy = 0, state = DS_ATTACHED, devflags = 0, > > > flags = 13, order = 0 '\0', pad = 0 '\0', ivars = 0xc223f5c0, softc = > > > 0xc2244800, sysctl_ctx = {tqh_first = 0xc2264380, tqh_last = 0xc2241594}, > > > sysctl_tree = 0xc223f840} > > > (kgdb) > > > > Maybe try adding KTR traces for all calls to device_set_ivars(). I wonder > > if > > something is trashing this device's ivars. > > > > Oh, dear. The ata(4) driver overwrites the ivars of some PCI devices it > > attaches to. This is very, very wrong. Which ATA controller do you have? > > > > -- > > John Baldwin > > > > Aha, I?m using a Promise Fasttrack SX4000 for a RAID1 setup. And the one > included on the motherboard for the OS. > And yes, I can confirm that without the Fasttrack SX4000 the system boots up > correctly. (Pulled out the card and edited fstab.) > So you are right regarding that the ata driver messes something up. Do you > contact someone that is responsible for ata driver? > > Thank you for taking the time to "correct" this, Can you please try this patch? --- //depot/vendor/freebsd/src/sys/dev/ata/ata-pci.h 2009/03/30 22:20:14 +++ //depot/user/jhb/acpipci/dev/ata/ata-pci.h 2009/05/08 20:27:43 @@ -66,6 +66,7 @@ void (*function)(void *); void *argument; } interrupt[8]; /* XXX SOS max ch# for now */ + void *chipset_data; }; /* defines for known chipset PCI id's */ --- //depot/vendor/freebsd/src/sys/dev/ata/chipsets/ata-acard.c 2009/02/19 00:35:16 +++ //depot/user/jhb/acpipci/dev/ata/chipsets/ata-acard.c 2009/05/08 20:27:43 @@ -51,6 +51,12 @@ #include #include +struct ata_serialize { + struct mtx locked_mtx; + int locked_ch; + int restart_ch; +}; + /* local prototypes */ static int ata_acard_chipinit(device_t dev); static int ata_acard_ch_attach(device_t dev); @@ -58,6 +64,7 @@ static void ata_acard_850_setmode(device_t dev, int mode); static void ata_acard_86X_setmode(device_t dev, int mode); static int ata_serialize(device_t dev, int flags); +static void ata_serialize_init(struct ata_serialize *serial); /* misc defines */ #define ATP_OLD 1 @@ -93,6 +100,7 @@ ata_acard_chipinit(device_t dev) { struct ata_pci_controller *ctlr = device_get_softc(dev); + struct ata_serialize *serial; if (ata_setup_interrupt(dev, ata_generic_intr)) return ENXIO; @@ -100,8 +108,12 @@ ctlr->ch_attach = ata_acard_ch_attach; ctlr->ch_detach = ata_pci_ch_detach; if (ctlr->chip->cfg1 == ATP_OLD) { - ctlr->setmode = ata_acard_850_setmode; + ctlr->setmode = ata_acard_850_setmode; ctlr->locking = ata_serialize; + serial = malloc(sizeof(struct ata_serialize), + M_TEMP, M_WAITOK | M_ZERO); + ata_serialize_init(serial); + ctlr->chipset_data = serial; } else ctlr->setmode = ata_acard_86X_setmode; @@ -225,11 +237,14 @@ /* we could set PIO mode timings, but we assume the BIOS did that */ } -struct ata_serialize { - struct mtx locked_mtx; - int locked_ch; - int restart_ch; -}; +static void +ata_serialize_init(struct ata_serialize *serial) +{ + + mtx_init(&serial->locked_mtx, "ATA serialize lock", NULL, MTX_DEF); + serial->locked_ch = -1; + serial->restart_ch = -1; +} static int ata_serialize(device_t dev, int flags) @@ -237,20 +252,9 @@ struct ata_pci_controller *ctlr = device_get_softc(device_get_parent(dev)); struct ata_channel *ch = device_get_softc(dev); struct ata_serialize *serial; - static int inited = 0; int res; - if (!inited) { - serial = malloc(sizeof(struct ata_serialize), - M_TEMP, M_NOWAIT | M_ZERO); - mtx_init(&serial->locked_mtx, "ATA serialize lock", NULL, MTX_DEF); - serial->locked_ch = -1; - serial->restart_ch = -1; - device_set_ivars(ctlr->dev, serial); - inited = 1; - } - else - serial = device_get_ivars(ctlr->dev); + serial = ctlr->chipset_data; mtx_lock(&serial->locked_mtx); switch (flags) { --- //depot/vendor/freebsd/src/sys/dev/ata/chipsets/ata-promise.c 2009/03/30 22:20:14 +++ //depot/user/jhb/acpipci/dev/ata/chipsets/ata-promise.c 2009/05/08 20:27:43 @@ -283,7 +283,7 @@ mtx_init(&hpkt->mtx, "ATA promise HPKT lock", NULL, MTX_DEF); TAILQ_INIT(&hpkt->queue); hpkt->busy = 0; - device_set_ivars(dev, hpkt); + ctlr->chipset_data = hpkt; ctlr->ch_attach = ata_promise_mio_ch_attach; ctlr->ch_detach = ata_promise_mio_ch_detach; ctlr->reset = ata_promise_mio_reset; @@ -730,7 +730,7 @@ case PR_SX4X: /* softreset channel ATA module */ - hpktp = device_get_ivars(ctlr->dev); + hpktp = ctlr->chipset_data; ATA_OUTL(ctlr->r_res2, 0xc0260 + (ch->unit << 7), ch->unit + 1); ata_udelay(1000); ATA_OUTL(ctlr->r_res2, 0xc0260 + (ch->unit << 7), @@ -1208,7 +1208,7 @@ static void ata_promise_queue_hpkt(struct ata_pci_controller *ctlr, u_int32_t hpkt) { - struct ata_promise_sx4 *hpktp = device_get_ivars(ctlr->dev); + struct ata_promise_sx4 *hpktp = ctlr->chipset_data; mtx_lock(&hpktp->mtx); if (hpktp->busy) { @@ -1227,7 +1227,7 @@ static void ata_promise_next_hpkt(struct ata_pci_controller *ctlr) { - struct ata_promise_sx4 *hpktp = device_get_ivars(ctlr->dev); + struct ata_promise_sx4 *hpktp = ctlr->chipset_data; struct host_packet *hp; mtx_lock(&hpktp->mtx); -- John Baldwin From ivakras1 at gmail.com Mon May 11 19:01:44 2009 From: ivakras1 at gmail.com (Dmitry Kolosov) Date: Mon May 11 19:01:51 2009 Subject: Fighting for the power. In-Reply-To: <49FE1826.4060000@FreeBSD.org> References: <49FE1826.4060000@FreeBSD.org> Message-ID: <200905112259.14233.ivakras1@gmail.com> ??????????? 04 ??? 2009 02:18:14 Alexander Motin ??????: > I would like to summarize some of my knowledge on reducing FreeBSD power > consumption and describe some new things I have recently implemented in > 8-CURRENT. The main character of this story is my 12" Acer TravelMate > 6292 laptop with C2D T7700 2.4GHz CPU, 965GM chipset and SATA HDD, under > amd64 8-CURRENT. > > Modern systems, especially laptops, are implementing big number of > power-saving technologies. Some of them are working automatically, other > have significant requirements and need special system tuning or > trade-offs to be effectively used. > > So here is the steps: > > 1. CPU > CPU is the most consuming part of the system. Under the full load it > alone may consume more then 40W of power, but for real laptop usage the > most important is idle consumption. > Core2Duo T7700 CPU has 2 cores, runs on 2.4GHz frequency, supports EIST > technology with P-states at 2400, 2000, 1600, 1200 and 800MHz levels, > supports C1, C2 and C3 idle C-states, plus throttling. So how can we use it: > P-states and throttling > Enabling powerd allows to effectively control CPU frequency/voltage > depending on CPU load. powerd on recent system can handle it quite > transparently. By default, frequency controlled via mix of EIST and > throttling technologies. First one controls both core frequency and > voltage, second - only core frequency. Both technologies give positive > power-saving effect. But effect of throttling is small and can be > completely hidden by using C2 state, that's why I recommend to disable > throttling control by adding to /boot/loader.conf: > hint.p4tcc.0.disabled=1 > hint.acpi_throttle.0.disabled=1 > In my case frequency/voltage control saves about 5W of idle power. > C-states > - C1 stops clock on some parts of CPU core during inactivity. It is > safe, cheap and supported by CPUs for ages. System uses C1 state by default. > - C2 state allows CPU to turn off all core clocks on idle. It is also > cheap, but requires correct ACPI-chipset-CPU interoperation to be used. > Use of C2 state can be enabled by adding to /etc/rc.conf: > performance_cx_lowest="C2" > economy_cx_lowest="C2" > Effect from this state is not so big when powerd is used, but still > noticeable, > - C3 state allows CPU completely stop all internal clocks, reduce > voltage and disconnect from system bus. This state gives additional > power saving effect, but it is not cheap and require trade-offs. > As soon as CPU is completely stopped in C3 state, local APIC timers in > each CPU core, used by FreeBSD as event sources on SMP, are not > functioning. It stops system time, breaks scheduling that makes system > close to dead. The only solution for this problem is to use some > external timers. Originally, before SMP era, FreeBSD used i8254 (for HZ) > and RTC (for stats) chipset timers. I have made changes to 8-CURRENT to > resurrect them for SMP systems. To use them, you can disable local APIC > timers by adding to /boot/loader.conf: > hint.apic.0.clock=0 > Also, to drop/rise voltage on C3, CPU needs time (57us for my system). > It means that C3 state can't be effectively used when system is waking > up often. To increase inactivity periods we should reduce interrupt rate > as much as possible by adding to loader.conf: > kern.hz=100 > It may increase system response time a bit, but it is not significant > for laptop. Also we may avoid additional 128 interrupts per second per > core, by the cost of scheduling precision, with using i8254 timer also > for statistic collection purposes instead of RTC clock, by using another > newly added option: > hint.atrtc.0.clock=0 > As result, system has only 100 interrupts per core and CPUs are using C3 > with high efficiency: > %sysctl dev.cpu |grep cx > dev.cpu.0.cx_supported: C1/1 C2/1 C3/57 > dev.cpu.0.cx_lowest: C3 > dev.cpu.0.cx_usage: 0.00% 0.00% 100.00% last 7150us > dev.cpu.1.cx_supported: C1/1 C2/1 C3/57 > dev.cpu.1.cx_lowest: C3 > dev.cpu.1.cx_usage: 0.00% 0.00% 100.00% last 2235us > Result of effective C3 state usage, comparing to C2+powerd, is about 2W. > > 2. PCI devices > PCI bus provides method to control device power. For example, I have > completely no use for my FireWire controller and most of time - EHCI USB > controller. Disabling them allows me to save about 3W of power. To > disable all unneeded PCI devices you should build kernel without their > drivers and add to loader.conf: > hw.pci.do_power_nodriver=3 > To enable devices back all you need to do is just load their drivers as > modules. > > 3. Radios > WiFi and Bluetooth adapters can consume significant power when used (up > to 2W when my iwn WiFi is connected) or just enabled (0.5W). Disabling > them with mechanical switch on laptop case saves energy even when they > are not connected. > > 4. HDA modem > I was surprised, but integrated HDA modem consumed about 1W of power > even when not used. I have used the most radical solution - removed it > mechanically from socket. Case surface in that area become much cooler. > > 5. HDA sound > To reduce number of sound generated interrupts I have added to the > loader.conf: > hint.pcm.0.buffersize=65536 > hint.pcm.1.buffersize=65536 > hw.snd.feeder_buffersize=65536 > hw.snd.latency=7 > > 6. HDD > First common recommendation is use tmpfs for temporary files. RAM is > cheap, fast and anyway with you. > Also you may try to setup automatic idle drive spin-down, but if it is > the only system drive you should be careful, as every spin-up reduces > drive's life time. > For several months (until I have bought SATA SSD) I have successfully > used SDHC card in built-in PCI sdhci card reader as main filesystem. On > random read requests it is much faster then HDD, but it is very slow on > random write. Same time it consumes almost nothing. USB drives could > also be used, but effect is much less as EHCI USB controller consumes > much power. > Spinning-down my 2.5" Hitachi SATA HDD saves about 1W of power. Removing > it completely saves 2W. > > 7. SATA > Comparing to PATA, SATA interface uses differential signaling for data > transfer. To work properly it has to transmit pseudo-random scrambled > sequence even when idle. As you understand, that requires power. But > SATA implements two power saving modes: PARTIAL and SLUMBER. These modes > could be activated by either host or device if both sides support them. > PARTIAL mode just stops scrambling, but keeps neutral link state, resume > time is 50-100us. SLUMBER mode powers down interface completely, but > respective resume time is 3-10ms. > I have added minimal SATA power management to AHCI driver. There are > hint.ata.X.pm_level loader tunables can be used to control it now. > Setting it to 1 allows drive itself to initiate power saving, when it > wish. Values 2 and 3 make AHCI controller to initiate PARTIAL and > SLUMBER transitions after every command completion. > Note that SATA power saving is not compatible with drive hot-swap, as > controller unable to detect drive presence when link is powered-down. > In my case PARTIAL mode saves 0.5W and SLUMBER - 0.8W of power. > > So what have I got? To monitor real system power consumption I am using > information provided by ACPI battery via `acpiconf -i0` command: > > Original system: > Design capacity: 4800 mAh > Last full capacity: 4190 mAh > Technology: secondary (rechargeable) > Design voltage: 11100 mV > Capacity (warn): 300 mAh > Capacity (low): 167 mAh > Low/warn granularity: 32 mAh > Warn/full granularity: 32 mAh > Model number: Victoria > Serial number: 292 > Type: LION > OEM info: SIMPLO > State: discharging > Remaining capacity: 93% > Remaining time: 2:24 > Present rate: 1621 mA > Voltage: 12033 mV > > Tuned system: > %acpiconf -i0 > Design capacity: 4800 mAh > Last full capacity: 4190 mAh > Technology: secondary (rechargeable) > Design voltage: 11100 mV > Capacity (warn): 300 mAh > Capacity (low): 167 mAh > Low/warn granularity: 32 mAh > Warn/full granularity: 32 mAh > Model number: Victoria > Serial number: 292 > Type: LION > OEM info: SIMPLO > State: discharging > Remaining capacity: 94% > Remaining time: 4:47 > Present rate: 826 mA > Voltage: 12231 mV > > So I have really doubled my on-battery time by this tuning - 4:47 hours > instead of 2:24 with default settings. Preinstalled vendor-tuned Windows > XP on the same system, provides maximum 3:20 hours. > My EC does not present rate and time info: 10:49pm][/home/onyx# acpiconf -i0 Design capacity: 6000 mAh Last full capacity: 3328 mAh Technology: secondary (rechargeable) Design voltage: 14800 mV Capacity (warn): 172 mAh Capacity (low): 104 mAh Low/warn granularity: 10 mAh Warn/full granularity: 25 mAh Model number: Primary Serial number: Type: LION OEM info: Hewlett-Packard State: high Remaining capacity: 100% Remaining time: unknown Present rate: unknown Voltage: 12522 mV Where to dig? I'm realy need at least 'present rate' to fight for the power.. Also it is an error in capacity detection, i think. Any ideas? From oberman at es.net Mon May 11 19:13:11 2009 From: oberman at es.net (Kevin Oberman) Date: Mon May 11 19:13:18 2009 Subject: Fighting for the power. In-Reply-To: Your message of "Mon, 11 May 2009 22:59:13 +0400." <200905112259.14233.ivakras1@gmail.com> Message-ID: <20090511191309.79F0E1CC0B@ptavv.es.net> > From: Dmitry Kolosov > Date: Mon, 11 May 2009 22:59:13 +0400 > Sender: owner-freebsd-acpi@freebsd.org > > ðÏÎÅÄÅÌØÎÉË 04 ÍÁÑ 2009 02:18:14 Alexander Motin ÐÉÓÁÌÉ: > > I would like to summarize some of my knowledge on reducing FreeBSD power > > consumption and describe some new things I have recently implemented in > > 8-CURRENT. The main character of this story is my 12" Acer TravelMate > > 6292 laptop with C2D T7700 2.4GHz CPU, 965GM chipset and SATA HDD, under > > amd64 8-CURRENT. > > > > Modern systems, especially laptops, are implementing big number of > > power-saving technologies. Some of them are working automatically, other > > have significant requirements and need special system tuning or > > trade-offs to be effectively used. > > > > So here is the steps: > > > > 1. CPU > > CPU is the most consuming part of the system. Under the full load it > > alone may consume more then 40W of power, but for real laptop usage the > > most important is idle consumption. > > Core2Duo T7700 CPU has 2 cores, runs on 2.4GHz frequency, supports EIST > > technology with P-states at 2400, 2000, 1600, 1200 and 800MHz levels, > > supports C1, C2 and C3 idle C-states, plus throttling. So how can we use it: > > P-states and throttling > > Enabling powerd allows to effectively control CPU frequency/voltage > > depending on CPU load. powerd on recent system can handle it quite > > transparently. By default, frequency controlled via mix of EIST and > > throttling technologies. First one controls both core frequency and > > voltage, second - only core frequency. Both technologies give positive > > power-saving effect. But effect of throttling is small and can be > > completely hidden by using C2 state, that's why I recommend to disable > > throttling control by adding to /boot/loader.conf: > > hint.p4tcc.0.disabled=1 > > hint.acpi_throttle.0.disabled=1 > > In my case frequency/voltage control saves about 5W of idle power. > > C-states > > - C1 stops clock on some parts of CPU core during inactivity. It is > > safe, cheap and supported by CPUs for ages. System uses C1 state by default. > > - C2 state allows CPU to turn off all core clocks on idle. It is also > > cheap, but requires correct ACPI-chipset-CPU interoperation to be used. > > Use of C2 state can be enabled by adding to /etc/rc.conf: > > performance_cx_lowest="C2" > > economy_cx_lowest="C2" > > Effect from this state is not so big when powerd is used, but still > > noticeable, > > - C3 state allows CPU completely stop all internal clocks, reduce > > voltage and disconnect from system bus. This state gives additional > > power saving effect, but it is not cheap and require trade-offs. > > As soon as CPU is completely stopped in C3 state, local APIC timers in > > each CPU core, used by FreeBSD as event sources on SMP, are not > > functioning. It stops system time, breaks scheduling that makes system > > close to dead. The only solution for this problem is to use some > > external timers. Originally, before SMP era, FreeBSD used i8254 (for HZ) > > and RTC (for stats) chipset timers. I have made changes to 8-CURRENT to > > resurrect them for SMP systems. To use them, you can disable local APIC > > timers by adding to /boot/loader.conf: > > hint.apic.0.clock=0 > > Also, to drop/rise voltage on C3, CPU needs time (57us for my system). > > It means that C3 state can't be effectively used when system is waking > > up often. To increase inactivity periods we should reduce interrupt rate > > as much as possible by adding to loader.conf: > > kern.hz=100 > > It may increase system response time a bit, but it is not significant > > for laptop. Also we may avoid additional 128 interrupts per second per > > core, by the cost of scheduling precision, with using i8254 timer also > > for statistic collection purposes instead of RTC clock, by using another > > newly added option: > > hint.atrtc.0.clock=0 > > As result, system has only 100 interrupts per core and CPUs are using C3 > > with high efficiency: > > %sysctl dev.cpu |grep cx > > dev.cpu.0.cx_supported: C1/1 C2/1 C3/57 > > dev.cpu.0.cx_lowest: C3 > > dev.cpu.0.cx_usage: 0.00% 0.00% 100.00% last 7150us > > dev.cpu.1.cx_supported: C1/1 C2/1 C3/57 > > dev.cpu.1.cx_lowest: C3 > > dev.cpu.1.cx_usage: 0.00% 0.00% 100.00% last 2235us > > Result of effective C3 state usage, comparing to C2+powerd, is about 2W. > > > > 2. PCI devices > > PCI bus provides method to control device power. For example, I have > > completely no use for my FireWire controller and most of time - EHCI USB > > controller. Disabling them allows me to save about 3W of power. To > > disable all unneeded PCI devices you should build kernel without their > > drivers and add to loader.conf: > > hw.pci.do_power_nodriver=3 > > To enable devices back all you need to do is just load their drivers as > > modules. > > > > 3. Radios > > WiFi and Bluetooth adapters can consume significant power when used (up > > to 2W when my iwn WiFi is connected) or just enabled (0.5W). Disabling > > them with mechanical switch on laptop case saves energy even when they > > are not connected. > > > > 4. HDA modem > > I was surprised, but integrated HDA modem consumed about 1W of power > > even when not used. I have used the most radical solution - removed it > > mechanically from socket. Case surface in that area become much cooler. > > > > 5. HDA sound > > To reduce number of sound generated interrupts I have added to the > > loader.conf: > > hint.pcm.0.buffersize=65536 > > hint.pcm.1.buffersize=65536 > > hw.snd.feeder_buffersize=65536 > > hw.snd.latency=7 > > > > 6. HDD > > First common recommendation is use tmpfs for temporary files. RAM is > > cheap, fast and anyway with you. > > Also you may try to setup automatic idle drive spin-down, but if it is > > the only system drive you should be careful, as every spin-up reduces > > drive's life time. > > For several months (until I have bought SATA SSD) I have successfully > > used SDHC card in built-in PCI sdhci card reader as main filesystem. On > > random read requests it is much faster then HDD, but it is very slow on > > random write. Same time it consumes almost nothing. USB drives could > > also be used, but effect is much less as EHCI USB controller consumes > > much power. > > Spinning-down my 2.5" Hitachi SATA HDD saves about 1W of power. Removing > > it completely saves 2W. > > > > 7. SATA > > Comparing to PATA, SATA interface uses differential signaling for data > > transfer. To work properly it has to transmit pseudo-random scrambled > > sequence even when idle. As you understand, that requires power. But > > SATA implements two power saving modes: PARTIAL and SLUMBER. These modes > > could be activated by either host or device if both sides support them. > > PARTIAL mode just stops scrambling, but keeps neutral link state, resume > > time is 50-100us. SLUMBER mode powers down interface completely, but > > respective resume time is 3-10ms. > > I have added minimal SATA power management to AHCI driver. There are > > hint.ata.X.pm_level loader tunables can be used to control it now. > > Setting it to 1 allows drive itself to initiate power saving, when it > > wish. Values 2 and 3 make AHCI controller to initiate PARTIAL and > > SLUMBER transitions after every command completion. > > Note that SATA power saving is not compatible with drive hot-swap, as > > controller unable to detect drive presence when link is powered-down. > > In my case PARTIAL mode saves 0.5W and SLUMBER - 0.8W of power. > > > > So what have I got? To monitor real system power consumption I am using > > information provided by ACPI battery via `acpiconf -i0` command: > > > > Original system: > > Design capacity: 4800 mAh > > Last full capacity: 4190 mAh > > Technology: secondary (rechargeable) > > Design voltage: 11100 mV > > Capacity (warn): 300 mAh > > Capacity (low): 167 mAh > > Low/warn granularity: 32 mAh > > Warn/full granularity: 32 mAh > > Model number: Victoria > > Serial number: 292 > > Type: LION > > OEM info: SIMPLO > > State: discharging > > Remaining capacity: 93% > > Remaining time: 2:24 > > Present rate: 1621 mA > > Voltage: 12033 mV > > > > Tuned system: > > %acpiconf -i0 > > Design capacity: 4800 mAh > > Last full capacity: 4190 mAh > > Technology: secondary (rechargeable) > > Design voltage: 11100 mV > > Capacity (warn): 300 mAh > > Capacity (low): 167 mAh > > Low/warn granularity: 32 mAh > > Warn/full granularity: 32 mAh > > Model number: Victoria > > Serial number: 292 > > Type: LION > > OEM info: SIMPLO > > State: discharging > > Remaining capacity: 94% > > Remaining time: 4:47 > > Present rate: 826 mA > > Voltage: 12231 mV > > > > So I have really doubled my on-battery time by this tuning - 4:47 hours > > instead of 2:24 with default settings. Preinstalled vendor-tuned Windows > > XP on the same system, provides maximum 3:20 hours. > > > > My EC does not present rate and time info: > 10:49pm][/home/onyx# acpiconf -i0 > Design capacity: 6000 mAh > Last full capacity: 3328 mAh > Technology: secondary (rechargeable) > Design voltage: 14800 mV > Capacity (warn): 172 mAh > Capacity (low): 104 mAh > Low/warn granularity: 10 mAh > Warn/full granularity: 25 mAh > Model number: Primary > Serial number: > Type: LION > OEM info: Hewlett-Packard > State: high > Remaining capacity: 100% > Remaining time: unknown > Present rate: unknown > Voltage: 12522 mV > > Where to dig? I'm realy need at least 'present rate' to fight for the > power.. Also it is an error in capacity detection, i think. Any ideas? Is the system connected to AC power when you issue the command? Many systems do not provide this information unless they are no battery power. Thy may also need to have been on battery for at least a minute or two to calculate drain rate. (Also, that battery is getting fairly old. It has only 55% of it's designed capacity.) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From onemda at gmail.com Mon May 11 20:08:51 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Mon May 11 20:09:03 2009 Subject: Fighting for the power. In-Reply-To: <4A081868.6010906@FreeBSD.org> References: <49FE1826.4060000@FreeBSD.org> <4A07BC4D.7080604@freebsd.org> <4A081868.6010906@FreeBSD.org> Message-ID: <3a142e750905111308o62a11c8em5465ea9aa1cfaebc@mail.gmail.com> On 5/11/09, Alexander Motin wrote: > Tim Kientzle wrote: >> I started to try the "hint.apic.0.clock", but noticed >> in your commit r191720: >> Alexander Motin wrote: >>> Add hint.apic.0.clock tunable. Setting it 0 disables using >>> LAPIC timers as hard-/stat-/profclock sources falling back >>> to using i8254 and rtc timers. >>> ... >>> This technique is not working for SMP yet, as only one CPU >>> receives timer interrupts. But I think that problem could >>> be fixed by forwarding interrupts to other CPUs with IPI. >> >> Is anyone looking at this yet? > > I have implemented SMP support for i386 and amd64 in some of my later > commits. And all those hacks helps verry little in my case, most gain I get when laptop monitor is switched off. Even switching hard disk off improves battery life very little. interrupt total rate irq1: atkbd0 5206 3 irq0: clk 156008 99 irq9: acpi0 1152 0 irq12: psm0 16092 10 irq14: ata0 6587 4 irq15: ata1 1 0 irq17: ndis0 28646 18 irq256: hdac0 18 0 Total 213710 136 -- Paul From ivakras1 at gmail.com Mon May 11 20:24:19 2009 From: ivakras1 at gmail.com (Dmitry Kolosov) Date: Mon May 11 20:24:25 2009 Subject: Fighting for the power. In-Reply-To: <20090511191309.79F0E1CC0B@ptavv.es.net> References: <20090511191309.79F0E1CC0B@ptavv.es.net> Message-ID: <200905120021.23223.ivakras1@gmail.com> ??????????? 11 ??? 2009 23:13:09 Kevin Oberman ??????: > > From: Dmitry Kolosov > > Date: Mon, 11 May 2009 22:59:13 +0400 > > Sender: owner-freebsd-acpi@freebsd.org > > > > ??????????? 04 ??? 2009 02:18:14 Alexander Motin ??????: > > > I would like to summarize some of my knowledge on reducing FreeBSD power > > > consumption and describe some new things I have recently implemented in > > > 8-CURRENT. The main character of this story is my 12" Acer TravelMate > > > 6292 laptop with C2D T7700 2.4GHz CPU, 965GM chipset and SATA HDD, under > > > amd64 8-CURRENT. > > > > > > Modern systems, especially laptops, are implementing big number of > > > power-saving technologies. Some of them are working automatically, other > > > have significant requirements and need special system tuning or > > > trade-offs to be effectively used. > > > > > > So here is the steps: > > > > > > 1. CPU > > > CPU is the most consuming part of the system. Under the full load it > > > alone may consume more then 40W of power, but for real laptop usage the > > > most important is idle consumption. > > > Core2Duo T7700 CPU has 2 cores, runs on 2.4GHz frequency, supports EIST > > > technology with P-states at 2400, 2000, 1600, 1200 and 800MHz levels, > > > supports C1, C2 and C3 idle C-states, plus throttling. So how can we use it: > > > P-states and throttling > > > Enabling powerd allows to effectively control CPU frequency/voltage > > > depending on CPU load. powerd on recent system can handle it quite > > > transparently. By default, frequency controlled via mix of EIST and > > > throttling technologies. First one controls both core frequency and > > > voltage, second - only core frequency. Both technologies give positive > > > power-saving effect. But effect of throttling is small and can be > > > completely hidden by using C2 state, that's why I recommend to disable > > > throttling control by adding to /boot/loader.conf: > > > hint.p4tcc.0.disabled=1 > > > hint.acpi_throttle.0.disabled=1 > > > In my case frequency/voltage control saves about 5W of idle power. > > > C-states > > > - C1 stops clock on some parts of CPU core during inactivity. It is > > > safe, cheap and supported by CPUs for ages. System uses C1 state by default. > > > - C2 state allows CPU to turn off all core clocks on idle. It is also > > > cheap, but requires correct ACPI-chipset-CPU interoperation to be used. > > > Use of C2 state can be enabled by adding to /etc/rc.conf: > > > performance_cx_lowest="C2" > > > economy_cx_lowest="C2" > > > Effect from this state is not so big when powerd is used, but still > > > noticeable, > > > - C3 state allows CPU completely stop all internal clocks, reduce > > > voltage and disconnect from system bus. This state gives additional > > > power saving effect, but it is not cheap and require trade-offs. > > > As soon as CPU is completely stopped in C3 state, local APIC timers in > > > each CPU core, used by FreeBSD as event sources on SMP, are not > > > functioning. It stops system time, breaks scheduling that makes system > > > close to dead. The only solution for this problem is to use some > > > external timers. Originally, before SMP era, FreeBSD used i8254 (for HZ) > > > and RTC (for stats) chipset timers. I have made changes to 8-CURRENT to > > > resurrect them for SMP systems. To use them, you can disable local APIC > > > timers by adding to /boot/loader.conf: > > > hint.apic.0.clock=0 > > > Also, to drop/rise voltage on C3, CPU needs time (57us for my system). > > > It means that C3 state can't be effectively used when system is waking > > > up often. To increase inactivity periods we should reduce interrupt rate > > > as much as possible by adding to loader.conf: > > > kern.hz=100 > > > It may increase system response time a bit, but it is not significant > > > for laptop. Also we may avoid additional 128 interrupts per second per > > > core, by the cost of scheduling precision, with using i8254 timer also > > > for statistic collection purposes instead of RTC clock, by using another > > > newly added option: > > > hint.atrtc.0.clock=0 > > > As result, system has only 100 interrupts per core and CPUs are using C3 > > > with high efficiency: > > > %sysctl dev.cpu |grep cx > > > dev.cpu.0.cx_supported: C1/1 C2/1 C3/57 > > > dev.cpu.0.cx_lowest: C3 > > > dev.cpu.0.cx_usage: 0.00% 0.00% 100.00% last 7150us > > > dev.cpu.1.cx_supported: C1/1 C2/1 C3/57 > > > dev.cpu.1.cx_lowest: C3 > > > dev.cpu.1.cx_usage: 0.00% 0.00% 100.00% last 2235us > > > Result of effective C3 state usage, comparing to C2+powerd, is about 2W. > > > > > > 2. PCI devices > > > PCI bus provides method to control device power. For example, I have > > > completely no use for my FireWire controller and most of time - EHCI USB > > > controller. Disabling them allows me to save about 3W of power. To > > > disable all unneeded PCI devices you should build kernel without their > > > drivers and add to loader.conf: > > > hw.pci.do_power_nodriver=3 > > > To enable devices back all you need to do is just load their drivers as > > > modules. > > > > > > 3. Radios > > > WiFi and Bluetooth adapters can consume significant power when used (up > > > to 2W when my iwn WiFi is connected) or just enabled (0.5W). Disabling > > > them with mechanical switch on laptop case saves energy even when they > > > are not connected. > > > > > > 4. HDA modem > > > I was surprised, but integrated HDA modem consumed about 1W of power > > > even when not used. I have used the most radical solution - removed it > > > mechanically from socket. Case surface in that area become much cooler. > > > > > > 5. HDA sound > > > To reduce number of sound generated interrupts I have added to the > > > loader.conf: > > > hint.pcm.0.buffersize=65536 > > > hint.pcm.1.buffersize=65536 > > > hw.snd.feeder_buffersize=65536 > > > hw.snd.latency=7 > > > > > > 6. HDD > > > First common recommendation is use tmpfs for temporary files. RAM is > > > cheap, fast and anyway with you. > > > Also you may try to setup automatic idle drive spin-down, but if it is > > > the only system drive you should be careful, as every spin-up reduces > > > drive's life time. > > > For several months (until I have bought SATA SSD) I have successfully > > > used SDHC card in built-in PCI sdhci card reader as main filesystem. On > > > random read requests it is much faster then HDD, but it is very slow on > > > random write. Same time it consumes almost nothing. USB drives could > > > also be used, but effect is much less as EHCI USB controller consumes > > > much power. > > > Spinning-down my 2.5" Hitachi SATA HDD saves about 1W of power. Removing > > > it completely saves 2W. > > > > > > 7. SATA > > > Comparing to PATA, SATA interface uses differential signaling for data > > > transfer. To work properly it has to transmit pseudo-random scrambled > > > sequence even when idle. As you understand, that requires power. But > > > SATA implements two power saving modes: PARTIAL and SLUMBER. These modes > > > could be activated by either host or device if both sides support them. > > > PARTIAL mode just stops scrambling, but keeps neutral link state, resume > > > time is 50-100us. SLUMBER mode powers down interface completely, but > > > respective resume time is 3-10ms. > > > I have added minimal SATA power management to AHCI driver. There are > > > hint.ata.X.pm_level loader tunables can be used to control it now. > > > Setting it to 1 allows drive itself to initiate power saving, when it > > > wish. Values 2 and 3 make AHCI controller to initiate PARTIAL and > > > SLUMBER transitions after every command completion. > > > Note that SATA power saving is not compatible with drive hot-swap, as > > > controller unable to detect drive presence when link is powered-down. > > > In my case PARTIAL mode saves 0.5W and SLUMBER - 0.8W of power. > > > > > > So what have I got? To monitor real system power consumption I am using > > > information provided by ACPI battery via `acpiconf -i0` command: > > > > > > Original system: > > > Design capacity: 4800 mAh > > > Last full capacity: 4190 mAh > > > Technology: secondary (rechargeable) > > > Design voltage: 11100 mV > > > Capacity (warn): 300 mAh > > > Capacity (low): 167 mAh > > > Low/warn granularity: 32 mAh > > > Warn/full granularity: 32 mAh > > > Model number: Victoria > > > Serial number: 292 > > > Type: LION > > > OEM info: SIMPLO > > > State: discharging > > > Remaining capacity: 93% > > > Remaining time: 2:24 > > > Present rate: 1621 mA > > > Voltage: 12033 mV > > > > > > Tuned system: > > > %acpiconf -i0 > > > Design capacity: 4800 mAh > > > Last full capacity: 4190 mAh > > > Technology: secondary (rechargeable) > > > Design voltage: 11100 mV > > > Capacity (warn): 300 mAh > > > Capacity (low): 167 mAh > > > Low/warn granularity: 32 mAh > > > Warn/full granularity: 32 mAh > > > Model number: Victoria > > > Serial number: 292 > > > Type: LION > > > OEM info: SIMPLO > > > State: discharging > > > Remaining capacity: 94% > > > Remaining time: 4:47 > > > Present rate: 826 mA > > > Voltage: 12231 mV > > > > > > So I have really doubled my on-battery time by this tuning - 4:47 hours > > > instead of 2:24 with default settings. Preinstalled vendor-tuned Windows > > > XP on the same system, provides maximum 3:20 hours. > > > > > > > My EC does not present rate and time info: > > 10:49pm][/home/onyx# acpiconf -i0 > > Design capacity: 6000 mAh > > Last full capacity: 3328 mAh > > Technology: secondary (rechargeable) > > Design voltage: 14800 mV > > Capacity (warn): 172 mAh > > Capacity (low): 104 mAh > > Low/warn granularity: 10 mAh > > Warn/full granularity: 25 mAh > > Model number: Primary > > Serial number: > > Type: LION > > OEM info: Hewlett-Packard > > State: high > > Remaining capacity: 100% > > Remaining time: unknown > > Present rate: unknown > > Voltage: 12522 mV > > > > Where to dig? I'm realy need at least 'present rate' to fight for the > > power.. Also it is an error in capacity detection, i think. Any ideas? > > Is the system connected to AC power when you issue the command? Many > systems do not provide this information unless they are no battery > power. Thy may also need to have been on battery for at least a minute > or two to calculate drain rate. (Also, that battery is getting fairly > old. It has only 55% of it's designed capacity.) 20 minutes on battery. Still no 'Remaining time' nor 'Present rate'. It drains 1% in a minute, while economy profile is C3 state for processor and 500MHz of speed. Anyway, laptop runs less than a hour on battery on economy profile. That laptop (HP Pavilion dv6840er) is less than 1 year old. It's C4 state available in BIOS settings, i'll try it. From oberman at es.net Mon May 11 20:38:27 2009 From: oberman at es.net (Kevin Oberman) Date: Mon May 11 20:38:35 2009 Subject: Fighting for the power. In-Reply-To: Your message of "Tue, 12 May 2009 00:21:22 +0400." <200905120021.23223.ivakras1@gmail.com> Message-ID: <20090511203825.BDC351CC0B@ptavv.es.net> > From: Dmitry Kolosov > Date: Tue, 12 May 2009 00:21:22 +0400 > Sender: owner-freebsd-acpi@freebsd.org > > ðÏÎÅÄÅÌØÎÉË 11 ÍÁÑ 2009 23:13:09 Kevin Oberman ÐÉÓÁÌÉ: > > > From: Dmitry Kolosov > > > Date: Mon, 11 May 2009 22:59:13 +0400 > > > Sender: owner-freebsd-acpi@freebsd.org > > > > > > ðÏÎÅÄÅÌØÎÉË 04 ÍÁÑ 2009 02:18:14 Alexander Motin ÐÉÓÁÌÉ: > > > > I would like to summarize some of my knowledge on reducing FreeBSD power > > > > consumption and describe some new things I have recently implemented in > > > > 8-CURRENT. The main character of this story is my 12" Acer TravelMate > > > > 6292 laptop with C2D T7700 2.4GHz CPU, 965GM chipset and SATA HDD, under > > > > amd64 8-CURRENT. > > > > > > > > Modern systems, especially laptops, are implementing big number of > > > > power-saving technologies. Some of them are working automatically, other > > > > have significant requirements and need special system tuning or > > > > trade-offs to be effectively used. > > > > > > > > So here is the steps: > > > > > > > > 1. CPU > > > > CPU is the most consuming part of the system. Under the full load it > > > > alone may consume more then 40W of power, but for real laptop usage the > > > > most important is idle consumption. > > > > Core2Duo T7700 CPU has 2 cores, runs on 2.4GHz frequency, supports EIST > > > > technology with P-states at 2400, 2000, 1600, 1200 and 800MHz levels, > > > > supports C1, C2 and C3 idle C-states, plus throttling. So how can we use it: > > > > P-states and throttling > > > > Enabling powerd allows to effectively control CPU frequency/voltage > > > > depending on CPU load. powerd on recent system can handle it quite > > > > transparently. By default, frequency controlled via mix of EIST and > > > > throttling technologies. First one controls both core frequency and > > > > voltage, second - only core frequency. Both technologies give positive > > > > power-saving effect. But effect of throttling is small and can be > > > > completely hidden by using C2 state, that's why I recommend to disable > > > > throttling control by adding to /boot/loader.conf: > > > > hint.p4tcc.0.disabled=1 > > > > hint.acpi_throttle.0.disabled=1 > > > > In my case frequency/voltage control saves about 5W of idle power. > > > > C-states > > > > - C1 stops clock on some parts of CPU core during inactivity. It is > > > > safe, cheap and supported by CPUs for ages. System uses C1 state by default. > > > > - C2 state allows CPU to turn off all core clocks on idle. It is also > > > > cheap, but requires correct ACPI-chipset-CPU interoperation to be used. > > > > Use of C2 state can be enabled by adding to /etc/rc.conf: > > > > performance_cx_lowest="C2" > > > > economy_cx_lowest="C2" > > > > Effect from this state is not so big when powerd is used, but still > > > > noticeable, > > > > - C3 state allows CPU completely stop all internal clocks, reduce > > > > voltage and disconnect from system bus. This state gives additional > > > > power saving effect, but it is not cheap and require trade-offs. > > > > As soon as CPU is completely stopped in C3 state, local APIC timers in > > > > each CPU core, used by FreeBSD as event sources on SMP, are not > > > > functioning. It stops system time, breaks scheduling that makes system > > > > close to dead. The only solution for this problem is to use some > > > > external timers. Originally, before SMP era, FreeBSD used i8254 (for HZ) > > > > and RTC (for stats) chipset timers. I have made changes to 8-CURRENT to > > > > resurrect them for SMP systems. To use them, you can disable local APIC > > > > timers by adding to /boot/loader.conf: > > > > hint.apic.0.clock=0 > > > > Also, to drop/rise voltage on C3, CPU needs time (57us for my system). > > > > It means that C3 state can't be effectively used when system is waking > > > > up often. To increase inactivity periods we should reduce interrupt rate > > > > as much as possible by adding to loader.conf: > > > > kern.hz=100 > > > > It may increase system response time a bit, but it is not significant > > > > for laptop. Also we may avoid additional 128 interrupts per second per > > > > core, by the cost of scheduling precision, with using i8254 timer also > > > > for statistic collection purposes instead of RTC clock, by using another > > > > newly added option: > > > > hint.atrtc.0.clock=0 > > > > As result, system has only 100 interrupts per core and CPUs are using C3 > > > > with high efficiency: > > > > %sysctl dev.cpu |grep cx > > > > dev.cpu.0.cx_supported: C1/1 C2/1 C3/57 > > > > dev.cpu.0.cx_lowest: C3 > > > > dev.cpu.0.cx_usage: 0.00% 0.00% 100.00% last 7150us > > > > dev.cpu.1.cx_supported: C1/1 C2/1 C3/57 > > > > dev.cpu.1.cx_lowest: C3 > > > > dev.cpu.1.cx_usage: 0.00% 0.00% 100.00% last 2235us > > > > Result of effective C3 state usage, comparing to C2+powerd, is about 2W. > > > > > > > > 2. PCI devices > > > > PCI bus provides method to control device power. For example, I have > > > > completely no use for my FireWire controller and most of time - EHCI USB > > > > controller. Disabling them allows me to save about 3W of power. To > > > > disable all unneeded PCI devices you should build kernel without their > > > > drivers and add to loader.conf: > > > > hw.pci.do_power_nodriver=3 > > > > To enable devices back all you need to do is just load their drivers as > > > > modules. > > > > > > > > 3. Radios > > > > WiFi and Bluetooth adapters can consume significant power when used (up > > > > to 2W when my iwn WiFi is connected) or just enabled (0.5W). Disabling > > > > them with mechanical switch on laptop case saves energy even when they > > > > are not connected. > > > > > > > > 4. HDA modem > > > > I was surprised, but integrated HDA modem consumed about 1W of power > > > > even when not used. I have used the most radical solution - removed it > > > > mechanically from socket. Case surface in that area become much cooler. > > > > > > > > 5. HDA sound > > > > To reduce number of sound generated interrupts I have added to the > > > > loader.conf: > > > > hint.pcm.0.buffersize=65536 > > > > hint.pcm.1.buffersize=65536 > > > > hw.snd.feeder_buffersize=65536 > > > > hw.snd.latency=7 > > > > > > > > 6. HDD > > > > First common recommendation is use tmpfs for temporary files. RAM is > > > > cheap, fast and anyway with you. > > > > Also you may try to setup automatic idle drive spin-down, but if it is > > > > the only system drive you should be careful, as every spin-up reduces > > > > drive's life time. > > > > For several months (until I have bought SATA SSD) I have successfully > > > > used SDHC card in built-in PCI sdhci card reader as main filesystem. On > > > > random read requests it is much faster then HDD, but it is very slow on > > > > random write. Same time it consumes almost nothing. USB drives could > > > > also be used, but effect is much less as EHCI USB controller consumes > > > > much power. > > > > Spinning-down my 2.5" Hitachi SATA HDD saves about 1W of power. Removing > > > > it completely saves 2W. > > > > > > > > 7. SATA > > > > Comparing to PATA, SATA interface uses differential signaling for data > > > > transfer. To work properly it has to transmit pseudo-random scrambled > > > > sequence even when idle. As you understand, that requires power. But > > > > SATA implements two power saving modes: PARTIAL and SLUMBER. These modes > > > > could be activated by either host or device if both sides support them. > > > > PARTIAL mode just stops scrambling, but keeps neutral link state, resume > > > > time is 50-100us. SLUMBER mode powers down interface completely, but > > > > respective resume time is 3-10ms. > > > > I have added minimal SATA power management to AHCI driver. There are > > > > hint.ata.X.pm_level loader tunables can be used to control it now. > > > > Setting it to 1 allows drive itself to initiate power saving, when it > > > > wish. Values 2 and 3 make AHCI controller to initiate PARTIAL and > > > > SLUMBER transitions after every command completion. > > > > Note that SATA power saving is not compatible with drive hot-swap, as > > > > controller unable to detect drive presence when link is powered-down. > > > > In my case PARTIAL mode saves 0.5W and SLUMBER - 0.8W of power. > > > > > > > > So what have I got? To monitor real system power consumption I am using > > > > information provided by ACPI battery via `acpiconf -i0` command: > > > > > > > > Original system: > > > > Design capacity: 4800 mAh > > > > Last full capacity: 4190 mAh > > > > Technology: secondary (rechargeable) > > > > Design voltage: 11100 mV > > > > Capacity (warn): 300 mAh > > > > Capacity (low): 167 mAh > > > > Low/warn granularity: 32 mAh > > > > Warn/full granularity: 32 mAh > > > > Model number: Victoria > > > > Serial number: 292 > > > > Type: LION > > > > OEM info: SIMPLO > > > > State: discharging > > > > Remaining capacity: 93% > > > > Remaining time: 2:24 > > > > Present rate: 1621 mA > > > > Voltage: 12033 mV > > > > > > > > Tuned system: > > > > %acpiconf -i0 > > > > Design capacity: 4800 mAh > > > > Last full capacity: 4190 mAh > > > > Technology: secondary (rechargeable) > > > > Design voltage: 11100 mV > > > > Capacity (warn): 300 mAh > > > > Capacity (low): 167 mAh > > > > Low/warn granularity: 32 mAh > > > > Warn/full granularity: 32 mAh > > > > Model number: Victoria > > > > Serial number: 292 > > > > Type: LION > > > > OEM info: SIMPLO > > > > State: discharging > > > > Remaining capacity: 94% > > > > Remaining time: 4:47 > > > > Present rate: 826 mA > > > > Voltage: 12231 mV > > > > > > > > So I have really doubled my on-battery time by this tuning - 4:47 hours > > > > instead of 2:24 with default settings. Preinstalled vendor-tuned Windows > > > > XP on the same system, provides maximum 3:20 hours. > > > > > > > > > > My EC does not present rate and time info: > > > 10:49pm][/home/onyx# acpiconf -i0 > > > Design capacity: 6000 mAh > > > Last full capacity: 3328 mAh > > > Technology: secondary (rechargeable) > > > Design voltage: 14800 mV > > > Capacity (warn): 172 mAh > > > Capacity (low): 104 mAh > > > Low/warn granularity: 10 mAh > > > Warn/full granularity: 25 mAh > > > Model number: Primary > > > Serial number: > > > Type: LION > > > OEM info: Hewlett-Packard > > > State: high > > > Remaining capacity: 100% > > > Remaining time: unknown > > > Present rate: unknown > > > Voltage: 12522 mV > > > > > > Where to dig? I'm realy need at least 'present rate' to fight for the > > > power.. Also it is an error in capacity detection, i think. Any ideas? > > > > Is the system connected to AC power when you issue the command? Many > > systems do not provide this information unless they are no battery > > power. Thy may also need to have been on battery for at least a minute > > or two to calculate drain rate. (Also, that battery is getting fairly > > old. It has only 55% of it's designed capacity.) > 20 minutes on battery. Still no 'Remaining time' nor 'Present rate'. It drains 1% in a minute, while economy profile is C3 state for processor and 500MHz of speed. Anyway, laptop runs less than a hour on battery on economy profile. That laptop (HP Pavilion dv6840er) is less than 1 year old. > It's C4 state available in BIOS settings, i'll try it. If the battery is in that bad a shape after a year, either it is a crappy battery (not likely) or it is being abused by being kept at full charge almost all of the time. LI-Ion batteries will deteriorate if not fully discharged periodically and even more if almost always on AC power and fully charged. IBM/Lenovo recommend a full discharge of LI-Ion batteries on a monthly basis and, if always on AC power, keeping them at no more than 80% charge. IBM/Lenovo power management software can be set to keep the power at a reduced level. FreeBSD does not have this capability, though it could be folded into the IBM ACPI module with a command to set the charge point. "Full discharge" means disabling automatic suspend on low battery in power management and letting them run down as far as possible. I try to discharge my battery monthly and to keep spare batteries at about 50% charge when they will be in storage for more than a week or two and it seems to have helped a great deal. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From mav at FreeBSD.org Mon May 11 23:13:39 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Mon May 11 23:13:57 2009 Subject: Fighting for the power. In-Reply-To: <3a142e750905111308o62a11c8em5465ea9aa1cfaebc@mail.gmail.com> References: <49FE1826.4060000@FreeBSD.org> <4A07BC4D.7080604@freebsd.org> <4A081868.6010906@FreeBSD.org> <3a142e750905111308o62a11c8em5465ea9aa1cfaebc@mail.gmail.com> Message-ID: <4A08B10E.4040702@FreeBSD.org> Paul B. Mahol wrote: > On 5/11/09, Alexander Motin wrote: >> Tim Kientzle wrote: >>> I started to try the "hint.apic.0.clock", but noticed >>> in your commit r191720: >>> Alexander Motin wrote: >>>> Add hint.apic.0.clock tunable. Setting it 0 disables using >>>> LAPIC timers as hard-/stat-/profclock sources falling back >>>> to using i8254 and rtc timers. >>>> ... >>>> This technique is not working for SMP yet, as only one CPU >>>> receives timer interrupts. But I think that problem could >>>> be fixed by forwarding interrupts to other CPUs with IPI. >>> Is anyone looking at this yet? >> I have implemented SMP support for i386 and amd64 in some of my later >> commits. > > And all those hacks helps verry little in my case, most gain I get when > laptop monitor is switched off. Even switching hard disk off improves battery > life very little. Monitor is surely one of major power consumers, but there are not so much things which you can do about it, as without power there will be no backlight. All you can do is tune backlight to minimum level required in every specific situation. What's about general effect, the main idea here is the same as in audio processing: result mostly depends on quality of the worst component. Your system may just have some other consumers which I don't have. For example, desktop CPU instead of mobile, desktop chipset instead of mobile, powerful external video instead of (or even in addition to) built-in, and so on. -- Alexander Motin From dsewnr.buffer at gmail.com Tue May 12 03:24:37 2009 From: dsewnr.buffer at gmail.com (Dsewnr Lu) Date: Tue May 12 03:24:43 2009 Subject: acpi problem ? In-Reply-To: <4A045A18.90807@gmail.com> References: <4A0397B2.5000303@gmail.com> <4A043734.7080700@icyb.net.ua> <4A045715.3030503@gmail.com> <4A045983.9060600@icyb.net.ua> <4A045A18.90807@gmail.com> Message-ID: <4A08EBE5.5000507@gmail.com> Dsewnr Lu wrote: > Andriy Gapon wrote: >> on 08/05/2009 19:00 Dsewnr Lu said the following: >> >>> This is my acpidump -dt output. >>> >> >> I couldn't find anything obviously wrong, sorry. Maybe somebody else >> could spot >> something. >> >> > Thanks a lot. :) > > Dsewnr Lu > I've upgraded to 8.0-CURRENT-amd64 and it works fine now. I tried 7.2-RELEASE-i386 and 8.0-CURRENT-i386 with the same kernel config and similar enviromnent, all work fine. I guess the problem may occur only on 7.2-RELEASE-amd64.... Regards, Dsewnr Lu. From knowtree at aloha.com Tue May 12 07:38:15 2009 From: knowtree at aloha.com (Gary Dunn) Date: Tue May 12 07:38:33 2009 Subject: Fighting for the power. In-Reply-To: <4A08B10E.4040702@FreeBSD.org> References: <49FE1826.4060000@FreeBSD.org> <4A07BC4D.7080604@freebsd.org> <4A081868.6010906@FreeBSD.org> <3a142e750905111308o62a11c8em5465ea9aa1cfaebc@mail.gmail.com> <4A08B10E.4040702@FreeBSD.org> Message-ID: <1242110455.2664.9.camel@slate01> On Tue, 2009-05-12 at 02:13 +0300, Alexander Motin wrote: ... > > What's about general effect, the main idea here is the same as in audio > processing: result mostly depends on quality of the worst component. > Your system may just have some other consumers which I don't have. For > example, desktop CPU instead of mobile, desktop chipset instead of > mobile, powerful external video instead of (or even in addition to) > built-in, and so on. > Interesting point. Is there a power consumption benchmark for evaluating hardware for use with FreeBSD? -- Gary Dunn, Honolulu osp@aloha.com http://openslate.net/ http://e9erust.blogspot.com/ Sent from Slate001 From smithi at nimnet.asn.au Tue May 12 10:25:37 2009 From: smithi at nimnet.asn.au (Ian Smith) Date: Tue May 12 10:25:43 2009 Subject: Fighting for the power. In-Reply-To: <1242110455.2664.9.camel@slate01> References: <49FE1826.4060000@FreeBSD.org> <4A07BC4D.7080604@freebsd.org> <4A081868.6010906@FreeBSD.org> <3a142e750905111308o62a11c8em5465ea9aa1cfaebc@mail.gmail.com> <4A08B10E.4040702@FreeBSD.org> <1242110455.2664.9.camel@slate01> Message-ID: <20090512182420.K46325@sola.nimnet.asn.au> On Mon, 11 May 2009, Gary Dunn wrote: > On Tue, 2009-05-12 at 02:13 +0300, Alexander Motin wrote: > ... > > > > What's about general effect, the main idea here is the same as in audio > > processing: result mostly depends on quality of the worst component. > > Your system may just have some other consumers which I don't have. For > > example, desktop CPU instead of mobile, desktop chipset instead of > > mobile, powerful external video instead of (or even in addition to) > > built-in, and so on. > > > > Interesting point. Is there a power consumption benchmark for evaluating > hardware for use with FreeBSD? make buildworld, running on battery? :-) More seriously: thanks to Nate's earlier niggling, I've been thinking towards a richer set of power profiles than our {performance,economy} dichotomy for a while, both in terms of various different work/play and AC/battery scenarious, and re specific settings that may be more or less optimal for particular hardware, that could be distributed or advised as more of a basic working set rather than as a series of 'try this' hints. Many of the useful points Alexander makes apply to lots of recent kit, but perhaps not as applicably to some older machines - just one example being whether using C3 is likely to help or hinder, eg with the C3 quirks for (some) PIIX4 chipset variants that got some work last? year. I'm not a C programmer, so I've been thinking more towards inclusion as a deeper level of rc.conf variables and parsing of these by sh script, tweaking sysctls after the fashion of the present power_profile and its triggering by devd events. Some features of individual machine / scenario profiles could include min/max cpu freq settings, whether or not to use p4tcc/acpi_throttle, highest C-state, powerd high/low load shift up/down percentages, and perhaps whether or not to power-down (D3) various devices/subsystems .. Recent exposure to (debian etch) cpufreqd profiles provides a few more ideas, eg here are a few examples from its default cpufreqd.conf, noting that cpufreqd and friends are add-ons, not system components, in debian. # stay in performance mode for the first minutes [Rule] name=AC Off - High Power ac=off # (on/off) battery_interval=70-100 #exec_post=echo 5 > /proc/acpi/sony/brightness profile=Performance Low [/Rule] # conservative mode when not AC [Rule] name=AC Off - Medium Battery ac=off # (on/off) battery_interval=30-70 #exec_post=echo 3 > /proc/acpi/sony/brightness profile=Powersave High [/Rule] # conservative mode when not AC [Rule] name=AC Off - Low Battery ac=off # (on/off) battery_interval=0-30 #exec_post=echo 3 > /proc/acpi/sony/brightness profile=Powersave Low [/Rule] ## # Special Rules ## # CPU Too hot! [Rule] name=CPU Too Hot acpi_temperature=55-100 cpu_interval=50-100 profile=Performance Low [/Rule] # use performance mode if I'm watching a movie # I don't care for batteries! # But don't heat too much. [Rule] name=Movie Watcher programs=xine,mplayer,gmplayer battery_interval=0-100 acpi_temperature=0-60 cpu_interval=0-100 profile=Performance High [/Rule] cheers, Ian From peterjeremy at optushome.com.au Tue May 12 10:43:44 2009 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Tue May 12 10:43:50 2009 Subject: Fighting for the power. In-Reply-To: <20090511203825.BDC351CC0B@ptavv.es.net> References: <200905120021.23223.ivakras1@gmail.com> <20090511203825.BDC351CC0B@ptavv.es.net> Message-ID: <20090512104333.GD41857@server.vk2pj.dyndns.org> On 2009-May-11 13:38:25 -0700, Kevin Oberman wrote: >LI-Ion batteries will deteriorate if not fully discharged periodically >and even more if almost always on AC power and fully charged. Li-ION batteries deterioriate under virtually any conditions. My reading suggests storing them partially charged in a fridge is best. >charge point. "Full discharge" means disabling automatic suspend on low >battery in power management and letting them run down as far as >possible. A friend & I both have HP nx6125 laptops. We have both accidently run our batteries to cutoff on a number of occasions and every time we do, acpiconf reports the battery capacity drops by about 5%. -- Peter Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-acpi/attachments/20090512/667188bd/attachment.pgp From smithi at nimnet.asn.au Tue May 12 10:51:59 2009 From: smithi at nimnet.asn.au (Ian Smith) Date: Tue May 12 10:52:06 2009 Subject: Fighting for the power. In-Reply-To: <20090512104333.GD41857@server.vk2pj.dyndns.org> References: <200905120021.23223.ivakras1@gmail.com> <20090511203825.BDC351CC0B@ptavv.es.net> <20090512104333.GD41857@server.vk2pj.dyndns.org> Message-ID: <20090512204716.W46325@sola.nimnet.asn.au> On Tue, 12 May 2009, Peter Jeremy wrote: > On 2009-May-11 13:38:25 -0700, Kevin Oberman wrote: > >LI-Ion batteries will deteriorate if not fully discharged periodically > >and even more if almost always on AC power and fully charged. > > Li-ION batteries deterioriate under virtually any conditions. My > reading suggests storing them partially charged in a fridge is best. My reading also. I've got a spare virtually-new Li-Ion battery for my old Compaq Armada (my main server :) in the fridge at the moment, its present battery looking like it might last another year at best. > >charge point. "Full discharge" means disabling automatic suspend on low > >battery in power management and letting them run down as far as > >possible. > > A friend & I both have HP nx6125 laptops. We have both accidently run > our batteries to cutoff on a number of occasions and every time we do, > acpiconf reports the battery capacity drops by about 5%. Might that be because the battery only adjusts its capacity data on full discharge, though? cheers, Ian From mav at FreeBSD.org Tue May 12 11:45:14 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Tue May 12 11:45:26 2009 Subject: Fighting for the power. In-Reply-To: <1242110455.2664.9.camel@slate01> References: <49FE1826.4060000@FreeBSD.org> <4A07BC4D.7080604@freebsd.org> <4A081868.6010906@FreeBSD.org> <3a142e750905111308o62a11c8em5465ea9aa1cfaebc@mail.gmail.com> <4A08B10E.4040702@FreeBSD.org> <1242110455.2664.9.camel@slate01> Message-ID: <4A096131.4040405@FreeBSD.org> Gary Dunn wrote: > On Tue, 2009-05-12 at 02:13 +0300, Alexander Motin wrote: > ... >> What's about general effect, the main idea here is the same as in audio >> processing: result mostly depends on quality of the worst component. >> Your system may just have some other consumers which I don't have. For >> example, desktop CPU instead of mobile, desktop chipset instead of >> mobile, powerful external video instead of (or even in addition to) >> built-in, and so on. > > Interesting point. Is there a power consumption benchmark for evaluating > hardware for use with FreeBSD? It is difficult to speak about benchmark, as soon as we are talking about idle power. I think the first step evaluation could be made with vendor provided data, as it mostly depends on hardware. If vendor speaks about 2 hours on battery, then there is quite small probability to get much out of that system, as it looks mostly positioned as desktop and may have many desktop components. And opposite, system declaring 9 hours must support a lot of different power-saving technologies to reach it. -- Alexander Motin From mav at FreeBSD.org Tue May 12 15:32:15 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Tue May 12 15:32:27 2009 Subject: Fwd: Kernel panic on 7.2-RC1 when booting with ACPI enabled kernel. In-Reply-To: <200905111425.01887.jhb@freebsd.org> References: <43b1bb350904230622u4b7790f0p9f665b649c97a3b@mail.gmail.com> <200905011450.13899.jhb@freebsd.org> <43b1bb350905011230p1372e1ffw5ab61985e7672e19@mail.gmail.com> <200905111425.01887.jhb@freebsd.org> Message-ID: <4A099661.7080404@FreeBSD.org> John Baldwin wrote: > On Friday 01 May 2009 3:30:28 pm Magnus Kling wrote: >> 2009/5/1 John Baldwin >>> Maybe try adding KTR traces for all calls to device_set_ivars(). I wonder >>> if >>> something is trashing this device's ivars. >>> >>> Oh, dear. The ata(4) driver overwrites the ivars of some PCI devices it >>> attaches to. This is very, very wrong. Which ATA controller do you have? >>> >> Aha, I?m using a Promise Fasttrack SX4000 for a RAID1 setup. And the one >> included on the motherboard for the OS. >> And yes, I can confirm that without the Fasttrack SX4000 the system boots up >> correctly. (Pulled out the card and edited fstab.) >> So you are right regarding that the ata driver messes something up. Do you >> contact someone that is responsible for ata driver? >> >> Thank you for taking the time to "correct" this, > > Can you please try this patch? Current behavior is definitely broken. Luckily it done so only for two types of controllers. As for me, this patch looks fine. Thanks. -- Alexander Motin From scjamorim at bsd.com.br Wed May 13 18:55:39 2009 From: scjamorim at bsd.com.br (=?ISO-8859-1?Q?Sylvio_C=E9sar_Teixeira_Amorim?=) Date: Wed May 13 18:55:47 2009 Subject: Hi Guys Message-ID: <5859850b0905131133l32a43cd2k8eecc695dc175a3a@mail.gmail.com> I have one laptop Dell Latitude E4300 with FreeBSD-8-Current, The temperature of the processor is very high when I'm compiling the kernel, I get to stay with 88 Celsius, how do I force a download this temperature? Att, Sylvio Cesar. -- -=-=-=-=-=-=-=- Live free or die - UNIX* -=-=-=-=-=-=-= From glen.j.barber at gmail.com Wed May 13 19:54:46 2009 From: glen.j.barber at gmail.com (Glen Barber) Date: Wed May 13 19:54:58 2009 Subject: Hi Guys In-Reply-To: <5859850b0905131133l32a43cd2k8eecc695dc175a3a@mail.gmail.com> References: <5859850b0905131133l32a43cd2k8eecc695dc175a3a@mail.gmail.com> Message-ID: <4ad871310905131225q488736e3s292d3e4e63bf00c9@mail.gmail.com> 2009/5/13 Sylvio C?sar Teixeira Amorim : > I have one laptop Dell Latitude E4300 with FreeBSD-8-Current, The > temperature of the processor is very high when I'm compiling the kernel, I > get to stay with 88 Celsius, how do I force a download this temperature? > You could try throttling the CPU during the build, however this will make the build take longer. man powerd(8) -- Glen Barber From saifi.khan at twincling.org Wed May 13 20:06:41 2009 From: saifi.khan at twincling.org (Saifi Khan) Date: Wed May 13 20:06:48 2009 Subject: Hi Guys In-Reply-To: <5859850b0905131133l32a43cd2k8eecc695dc175a3a@mail.gmail.com> References: <5859850b0905131133l32a43cd2k8eecc695dc175a3a@mail.gmail.com> Message-ID: On Wed, 13 May 2009, Sylvio César Teixeira Amorim wrote: > I have one laptop Dell Latitude E4300 with FreeBSD-8-Current, The > temperature of the processor is very high when I'm compiling the kernel, I > get to stay with 88 Celsius, how do I force a download this temperature? > > Att, > Sylvio Cesar. > It seems many people have experienced this issue. http://forum.notebookreview.com/showthread.php?p=4805607 Can an additional external fan/blower be of some help ? It's a sleek device and this points to heat dissipation system. thanks Saifi. From oberman at es.net Wed May 13 20:08:30 2009 From: oberman at es.net (Kevin Oberman) Date: Wed May 13 20:08:36 2009 Subject: Hi Guys In-Reply-To: Your message of "Wed, 13 May 2009 15:33:42 -0300." <5859850b0905131133l32a43cd2k8eecc695dc175a3a@mail.gmail.com> Message-ID: <20090513200823.ECB7F1CC0B@ptavv.es.net> > Date: Wed, 13 May 2009 15:33:42 -0300 > From: =?ISO-8859-1?Q?Sylvio_C=E9sar_Teixeira_Amorim?= > Sender: owner-freebsd-acpi@freebsd.org > > I have one laptop Dell Latitude E4300 with FreeBSD-8-Current, The > temperature of the processor is very high when I'm compiling the kernel, I > get to stay with 88 Celsius, how do I force a download this temperature? Probably the first place to start is to clean the heat sink on your laptop. Simply opening the unit and blowing it out with compressed air can drop CPU temperature by over 10 degrees Celsius. This is probably something that should be done at least annually and more often if the laptop is run in dusty locations, such as sitting on a bed or table covered with a table cloth. It is also possible that the heatsink is not properly attached to the CPU. Several people have reported that cleaning and re-applying heatsink grease greatly improved the temperature. Next, take a look at the values of _PSV and _CRT. (sysctl hw.acpi). If PSV is higher than 88, your system is still within normal operating temperatures. For example, Pentium-M chips are speced to run at a steady temperature of 100C. _PSV on my laptop is 94.5C and _CRT is 99.0C. This means that the system does not start doing anything beyond normal fan cooling until the CPU reaches 94.5C and will reach 99C before starting to shutdown. (This is different from the emergency crowbar shutdown which is for thermal spikes of about 130-150C which might occur when a heatsink becomes dislodged.) When _PSV is reached, the system should simply slow down until the temperature drops. There is hysteresis to keep it from continually cycling. I don't recall numbers, though. If you want to lower the temperature "manually", you can kill powerd (/etc/rc.d/powerd stop) and set the CPU frequency lower. (sysctl dev.cpu.?.freq) where '?' is the CPU number. The available frequencies may be found in sysctl dev.cpu.0.freq_levels. If you are doing the manually, be sure to adjust all CPUs to the same frequency. Finally, placing the system on a surface that leaves an air gap under the system will help, too. Running it on a soft surface inhibits convection cooling and most soft surfaces are pretty goods thermal insulators. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From scjamorim at bsd.com.br Wed May 13 20:11:59 2009 From: scjamorim at bsd.com.br (=?ISO-8859-1?Q?Sylvio_C=E9sar_Teixeira_Amorim?=) Date: Wed May 13 20:12:10 2009 Subject: Hi Guys In-Reply-To: References: <5859850b0905131133l32a43cd2k8eecc695dc175a3a@mail.gmail.com> Message-ID: <5859850b0905131311qb49622evf49fb4b2f50aefce@mail.gmail.com> 2009/5/13 Saifi Khan > On Wed, 13 May 2009, Sylvio C?sar Teixeira Amorim wrote: > > > I have one laptop Dell Latitude E4300 with FreeBSD-8-Current, The > > temperature of the processor is very high when I'm compiling the kernel, > I > > get to stay with 88 Celsius, how do I force a download this temperature? > > > > Att, > > Sylvio Cesar. > > > > It seems many people have experienced this issue. > http://forum.notebookreview.com/showthread.php?p=4805607 > > Can an additional external fan/blower be of some help ? > It's a sleek device and this points to heat dissipation system. > No, I can't. > > > thanks > Saifi. -- -=-=-=-=-=-=-=- Live free or die - UNIX* -=-=-=-=-=-=-= From scjamorim at bsd.com.br Wed May 13 20:17:04 2009 From: scjamorim at bsd.com.br (=?ISO-8859-1?Q?Sylvio_C=E9sar_Teixeira_Amorim?=) Date: Wed May 13 20:17:10 2009 Subject: Hi Guys In-Reply-To: <20090513200823.ECB7F1CC0B@ptavv.es.net> References: <5859850b0905131133l32a43cd2k8eecc695dc175a3a@mail.gmail.com> <20090513200823.ECB7F1CC0B@ptavv.es.net> Message-ID: <5859850b0905131317i49342181n64773b0e8ff37022@mail.gmail.com> Kevin, my laptop is Intel Core 2 duo 2.26, FSB 1066Mhz, DDR3. my sysctl hw.acipi.thermal.tz0._PSV: -1 hw.acipi.thermal.tz0._CRT: 107.0C 2009/5/13 Kevin Oberman > > Date: Wed, 13 May 2009 15:33:42 -0300 > > From: =?ISO-8859-1?Q?Sylvio_C=E9sar_Teixeira_Amorim?= < > scjamorim@bsd.com.br> > > Sender: owner-freebsd-acpi@freebsd.org > > > > I have one laptop Dell Latitude E4300 with FreeBSD-8-Current, The > > temperature of the processor is very high when I'm compiling the kernel, > I > > get to stay with 88 Celsius, how do I force a download this temperature? > > Probably the first place to start is to clean the heat sink on your > laptop. Simply opening the unit and blowing it out with compressed air > can drop CPU temperature by over 10 degrees Celsius. This is probably > something that should be done at least annually and more often if the > laptop is run in dusty locations, such as sitting on a bed or table > covered with a table cloth. > > It is also possible that the heatsink is not properly attached to the > CPU. Several people have reported that cleaning and re-applying heatsink > grease greatly improved the temperature. > > Next, take a look at the values of _PSV and _CRT. (sysctl hw.acpi). If > PSV is higher than 88, your system is still within normal operating > temperatures. For example, Pentium-M chips are speced to run at a steady > temperature of 100C. _PSV on my laptop is 94.5C and _CRT is 99.0C. This > means that the system does not start doing anything beyond normal fan > cooling until the CPU reaches 94.5C and will reach 99C before starting > to shutdown. (This is different from the emergency crowbar shutdown > which is for thermal spikes of about 130-150C which might occur when a > heatsink becomes dislodged.) > > When _PSV is reached, the system should simply slow down until the > temperature drops. There is hysteresis to keep it from continually > cycling. I don't recall numbers, though. > > If you want to lower the temperature "manually", you can kill powerd > (/etc/rc.d/powerd stop) and set the CPU frequency lower. (sysctl > dev.cpu.?.freq) where '?' is the CPU number. The available frequencies > may be found in sysctl dev.cpu.0.freq_levels. If you are doing the > manually, be sure to adjust all CPUs to the same frequency. > > Finally, placing the system on a surface that leaves an air gap under > the system will help, too. Running it on a soft surface inhibits > convection cooling and most soft surfaces are pretty goods thermal > insulators. > -- > R. Kevin Oberman, Network Engineer > Energy Sciences Network (ESnet) > Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) > E-mail: oberman@es.net Phone: +1 510 486-8634 > Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 > -- -=-=-=-=-=-=-=- Live free or die - UNIX* -=-=-=-=-=-=-= From spawk at acm.poly.edu Wed May 13 20:44:05 2009 From: spawk at acm.poly.edu (Boris Kochergin) Date: Wed May 13 20:44:11 2009 Subject: Hi Guys In-Reply-To: <5859850b0905131133l32a43cd2k8eecc695dc175a3a@mail.gmail.com> References: <5859850b0905131133l32a43cd2k8eecc695dc175a3a@mail.gmail.com> Message-ID: <4A0B2A84.9030809@acm.poly.edu> Sylvio C?sar Teixeira Amorim wrote: > I have one laptop Dell Latitude E4300 with FreeBSD-8-Current, The > temperature of the processor is very high when I'm compiling the kernel, I > get to stay with 88 Celsius, how do I force a download this temperature? > > Att, > > Sylvio Cesar. > > > > The short thread at http://lists.freebsd.org/pipermail/freebsd-current/2008-November/000299.html might be useful, both for the patch to introduce a debug.cpufreq.highest sysctl, which you can use in conjunction with powerd(8) to prevent the system from being clocked higher than a particular frequency, and for the instructions on how to override the passive cooling threshold. -Boris From nate at root.org Wed May 13 23:39:58 2009 From: nate at root.org (Nate Lawson) Date: Wed May 13 23:40:16 2009 Subject: Fighting for the power. In-Reply-To: <20090512182420.K46325@sola.nimnet.asn.au> References: <49FE1826.4060000@FreeBSD.org> <4A07BC4D.7080604@freebsd.org> <4A081868.6010906@FreeBSD.org> <3a142e750905111308o62a11c8em5465ea9aa1cfaebc@mail.gmail.com> <4A08B10E.4040702@FreeBSD.org> <1242110455.2664.9.camel@slate01> <20090512182420.K46325@sola.nimnet.asn.au> Message-ID: <4A0B43DC.9060708@root.org> Ian Smith wrote: > On Mon, 11 May 2009, Gary Dunn wrote: > > On Tue, 2009-05-12 at 02:13 +0300, Alexander Motin wrote: > > ... > > > > > > What's about general effect, the main idea here is the same as in audio > > > processing: result mostly depends on quality of the worst component. > > > Your system may just have some other consumers which I don't have. For > > > example, desktop CPU instead of mobile, desktop chipset instead of > > > mobile, powerful external video instead of (or even in addition to) > > > built-in, and so on. > > > > > > > Interesting point. Is there a power consumption benchmark for evaluating > > hardware for use with FreeBSD? > > make buildworld, running on battery? :-) > > More seriously: thanks to Nate's earlier niggling, I've been thinking > towards a richer set of power profiles than our {performance,economy} > dichotomy for a while, both in terms of various different work/play and > AC/battery scenarious, and re specific settings that may be more or less > optimal for particular hardware, that could be distributed or advised as > more of a basic working set rather than as a series of 'try this' hints. > FYI, Cyrille Szymanski has implemented a patch to add this kind of power profile support to powerd(8). I'd like to see it finished and committed. -- Nate From gaijin.k at gmail.com Thu May 14 00:36:35 2009 From: gaijin.k at gmail.com (Alexandre "Sunny" Kovalenko) Date: Thu May 14 00:36:41 2009 Subject: Hi Guys In-Reply-To: <5859850b0905131317i49342181n64773b0e8ff37022@mail.gmail.com> References: <5859850b0905131133l32a43cd2k8eecc695dc175a3a@mail.gmail.com> <20090513200823.ECB7F1CC0B@ptavv.es.net> <5859850b0905131317i49342181n64773b0e8ff37022@mail.gmail.com> Message-ID: <1242261370.1192.10.camel@RabbitsDen> On Wed, 2009-05-13 at 17:17 -0300, Sylvio C?sar Teixeira Amorim wrote: > Kevin, > > my laptop is Intel Core 2 duo 2.26, FSB 1066Mhz, DDR3. > my sysctl > > hw.acipi.thermal.tz0._PSV: -1 > hw.acipi.thermal.tz0._CRT: 107.0C Please, do not top-post -- it makes it harder to follow the thread. Do you by any chance have message to the tune of "acpi_tz0: _PSV value is absurd, ignored..." in you boot log? "grep absurd /var/log/messages" should give you the answer to this question. If answer is "yes" and you are willing to override your ASL, dump it according to the "Handbook" instructions and put it somewhere, I can get to it. As an alternative, you can add hw.acpi.thermal.tz0.passive_cooling=1 hw.acpi.thermal.user_override=1 hw.acpi.thermal.tz0._PSV=75C to /etc/sysctl.conf. This might or might not work as BIOS might tell OS to reevaluate _PSV and restore absurd value. You should replace 75C with the value you have in mind for your system. HTH, > > > > 2009/5/13 Kevin Oberman > > > > Date: Wed, 13 May 2009 15:33:42 -0300 > > > From: =?ISO-8859-1?Q?Sylvio_C=E9sar_Teixeira_Amorim?= < > > scjamorim@bsd.com.br> > > > Sender: owner-freebsd-acpi@freebsd.org > > > > > > I have one laptop Dell Latitude E4300 with FreeBSD-8-Current, The > > > temperature of the processor is very high when I'm compiling the kernel, > > I > > > get to stay with 88 Celsius, how do I force a download this temperature? > > > > Probably the first place to start is to clean the heat sink on your > > laptop. Simply opening the unit and blowing it out with compressed air > > can drop CPU temperature by over 10 degrees Celsius. This is probably > > something that should be done at least annually and more often if the > > laptop is run in dusty locations, such as sitting on a bed or table > > covered with a table cloth. > > > > It is also possible that the heatsink is not properly attached to the > > CPU. Several people have reported that cleaning and re-applying heatsink > > grease greatly improved the temperature. > > > > Next, take a look at the values of _PSV and _CRT. (sysctl hw.acpi). If > > PSV is higher than 88, your system is still within normal operating > > temperatures. For example, Pentium-M chips are speced to run at a steady > > temperature of 100C. _PSV on my laptop is 94.5C and _CRT is 99.0C. This > > means that the system does not start doing anything beyond normal fan > > cooling until the CPU reaches 94.5C and will reach 99C before starting > > to shutdown. (This is different from the emergency crowbar shutdown > > which is for thermal spikes of about 130-150C which might occur when a > > heatsink becomes dislodged.) > > > > When _PSV is reached, the system should simply slow down until the > > temperature drops. There is hysteresis to keep it from continually > > cycling. I don't recall numbers, though. > > > > If you want to lower the temperature "manually", you can kill powerd > > (/etc/rc.d/powerd stop) and set the CPU frequency lower. (sysctl > > dev.cpu.?.freq) where '?' is the CPU number. The available frequencies > > may be found in sysctl dev.cpu.0.freq_levels. If you are doing the > > manually, be sure to adjust all CPUs to the same frequency. > > > > Finally, placing the system on a surface that leaves an air gap under > > the system will help, too. Running it on a soft surface inhibits > > convection cooling and most soft surfaces are pretty goods thermal > > insulators. > > -- > > R. Kevin Oberman, Network Engineer > > Energy Sciences Network (ESnet) > > Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) > > E-mail: oberman@es.net Phone: +1 510 486-8634 > > Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 > > > > > -- Alexandre Kovalenko (????????? ?????????) From oberman at es.net Thu May 14 04:04:58 2009 From: oberman at es.net (Kevin Oberman) Date: Thu May 14 04:05:05 2009 Subject: Hi Guys In-Reply-To: Your message of "Wed, 13 May 2009 20:36:10 EDT." <1242261370.1192.10.camel@RabbitsDen> Message-ID: <20090514040454.52AFA1CC0B@ptavv.es.net> > From: "Alexandre \"Sunny\" Kovalenko" > Date: Wed, 13 May 2009 20:36:10 -0400 > > On Wed, 2009-05-13 at 17:17 -0300, Sylvio César Teixeira Amorim wrote: > > Kevin, > > > > my laptop is Intel Core 2 duo 2.26, FSB 1066Mhz, DDR3. > > my sysctl > > > > hw.acipi.thermal.tz0._PSV: -1 > > hw.acipi.thermal.tz0._CRT: 107.0C > > Please, do not top-post -- it makes it harder to follow the thread. > > Do you by any chance have message to the tune of > > "acpi_tz0: _PSV value is absurd, ignored..." > > in you boot log? "grep absurd /var/log/messages" should give you the > answer to this question. > > If answer is "yes" and you are willing to override your ASL, dump it > according to the "Handbook" instructions and put it somewhere, I can get > to it. > > As an alternative, you can add > > hw.acpi.thermal.tz0.passive_cooling=1 > hw.acpi.thermal.user_override=1 > hw.acpi.thermal.tz0._PSV=75C > > to /etc/sysctl.conf. This might or might not work as BIOS might tell OS > to reevaluate _PSV and restore absurd value. You should replace 75C with > the value you have in mind for your system. A Core2 Duo system can run VERY hot without a problem. You may note that _CRT is 107. That is possibly correct. Three 2.26 GHz chips, all P8400s, are speced at 105C. There is no thermal spec listed for the SP9300, though. In any case, 88C is certainly well within normal operating parameters for this processor, but you can certainly force _PSV to whatever you like. Just remember that it will slow the system by at least 12.5% and maybe more. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From smithi at nimnet.asn.au Thu May 14 05:12:06 2009 From: smithi at nimnet.asn.au (Ian Smith) Date: Thu May 14 05:12:14 2009 Subject: Fighting for the power. In-Reply-To: <4A0B43DC.9060708@root.org> References: <49FE1826.4060000@FreeBSD.org> <4A07BC4D.7080604@freebsd.org> <4A081868.6010906@FreeBSD.org> <3a142e750905111308o62a11c8em5465ea9aa1cfaebc@mail.gmail.com> <4A08B10E.4040702@FreeBSD.org> <1242110455.2664.9.camel@slate01> <20090512182420.K46325@sola.nimnet.asn.au> <4A0B43DC.9060708@root.org> Message-ID: <20090514145235.T46325@sola.nimnet.asn.au> On Wed, 13 May 2009, Nate Lawson wrote: > Ian Smith wrote: > > On Mon, 11 May 2009, Gary Dunn wrote: > > > On Tue, 2009-05-12 at 02:13 +0300, Alexander Motin wrote: > > > ... > > > > > > > > What's about general effect, the main idea here is the same as in audio > > > > processing: result mostly depends on quality of the worst component. > > > > Your system may just have some other consumers which I don't have. For > > > > example, desktop CPU instead of mobile, desktop chipset instead of > > > > mobile, powerful external video instead of (or even in addition to) > > > > built-in, and so on. > > > > > > > > > > Interesting point. Is there a power consumption benchmark for evaluating > > > hardware for use with FreeBSD? > > > > make buildworld, running on battery? :-) > > > > More seriously: thanks to Nate's earlier niggling, I've been thinking > > towards a richer set of power profiles than our {performance,economy} > > dichotomy for a while, both in terms of various different work/play and > > AC/battery scenarious, and re specific settings that may be more or less > > optimal for particular hardware, that could be distributed or advised as > > more of a basic working set rather than as a series of 'try this' hints. > > > > FYI, Cyrille Szymanski has implemented a patch to add this kind of power > profile support to powerd(8). I'd like to see it finished and committed. Good to hear, thanks. I'd like to see where it's up to. PR? cheers, Ian [removed current@ cc as I'm not subscribed - add it back if relevant] From mogunus at gmail.com Fri May 15 01:33:38 2009 From: mogunus at gmail.com (Marco Carmosino) Date: Fri May 15 01:33:45 2009 Subject: suspend/resume, amd64, FreeBSD 7.2 Message-ID: <24a7fa6d0905141803x2205621s5f99642ce61ae56b@mail.gmail.com> Hello, I have been attempting to use suspend/resume on my desktop computer. I think it probably should work, since S3 suspend works fine under linux. This is the output of sysctl hw.acpi: 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: 0 hw.acpi.disable_on_reboot: 0 hw.acpi.handle_reboot: 0 hw.acpi.cpu.cx_lowest: C1 this is my problem: [root@hydra /usr/home/mog]# acpiconf -s 1 acpiconf: request sleep type (1) failed: Operation not supported [root@hydra /usr/home/mog]# acpiconf -s 2 acpiconf: request sleep type (2) failed: Operation not supported [root@hydra /usr/home/mog]# acpiconf -s 3 acpiconf: request sleep type (3) failed: Operation not supported [root@hydra /usr/home/mog]# acpiconf -s 4 acpiconf: request sleep type (4) failed: Operation not supported [root@hydra /usr/home/mog]# acpiconf -s 5 acpiconf: invalid sleep type (5) There seem to be no other error messages, just "Operation not supported." This is confusing, because S3 is listed as supported, and I found http://lists.freebsd.org/pipermail/freebsd-amd64/2009-March/011982.html this thread from back in march saying that amd64 suspend code has been committed. Here is my ASL file: http://mogunate.org/mogunus-desktop.asl I built the system myself from parts on newegg. My motherboard is an asus p5n32-SLI SE deluxe, I am running a core 2 duo processor. This is my first time running FreeBSD. If there is any way I can help getting suspend to work, please let me know. Thanks, Mog From klingfon at gmail.com Fri May 15 06:48:05 2009 From: klingfon at gmail.com (Magnus Kling) Date: Fri May 15 06:48:16 2009 Subject: Fwd: Kernel panic on 7.2-RC1 when booting with ACPI enabled kernel. In-Reply-To: <200905111425.01887.jhb@freebsd.org> References: <43b1bb350904230622u4b7790f0p9f665b649c97a3b@mail.gmail.com> <200905011450.13899.jhb@freebsd.org> <43b1bb350905011230p1372e1ffw5ab61985e7672e19@mail.gmail.com> <200905111425.01887.jhb@freebsd.org> Message-ID: <43b1bb350905142348u7b8385acjd2ff4ca1ac4da9d5@mail.gmail.com> 2009/5/11 John Baldwin > On Friday 01 May 2009 3:30:28 pm Magnus Kling wrote: > > 2009/5/1 John Baldwin > > > > > On Friday 01 May 2009 2:30:28 pm Magnus Kling wrote: > > > > 2009/4/30 John Baldwin > > > > > > > > > On Saturday 25 April 2009 6:27:23 am Magnus Kling wrote: > > > > > > 2009/4/24 John Baldwin > > > > > > > Can you do 'frame 10' followed by 'p *(struct acpi_pci_devinfo > > > > > > > *)child->ivars' > > > > > > > > > > > > > > -- > > > > > > > John Baldwin > > > > > > > > > > > > > > > > > > Sure, no problem. This is a none critical server so I can do alot > of > > > > > > debugging and testing if that is needed. > > > > > > > > > > > > > > > > > > (kgdb) frame 10 > > > > > > #10 0xc0db4ca8 in acpi_pci_child_location_str_method > > > (cbdev=0xc2212680, > > > > > > child=0xc2243400, buf=0xc22c2400 "slot=0 function=0 handle=", > > > > > > buflen=1024) > > > > > > at > > > /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/acpi_pci.c:150 > > > > > > 150 strlcat(buf, acpi_name(dinfo->ap_handle), > buflen); > > > > > > > > > > > > (kgdb) p *(struct acpi_pci_devinfo *)child->ivars > > > > > > $1 = {ap_dinfo = {pci_links = {stqe_next = 0xc0b00f8c}, resources > = { > > > > > > stqh_first = 0xc0b00f8c, stqh_last = 0x1030000}, cfg = {dev > = > > > 0x0, > > > > > > bar = {4, 0, 0, 3257136600, 0, 0}, bios = 0, subvendor = 0, > > > > > > subdevice = 0, vendor = 0, device = 0, cmdreg = 0, statreg > = 0, > > > > > > baseclass = 0 '\0', subclass = 0 '\0', progif = 0 '\0', > revid = > > > 0 > > > > > > > > > > Hmm, this is all completely wrong and trashed. What if you do 'p > > > *child'? > > > > > > > > > > -- > > > > > John Baldwin > > > > > > > > > (kgdb) p *child > > > > $2 = {ops = 0xc2161800, link = {tqe_next = 0xc2243380, tqe_prev = > > > > 0xc2243484}, devlink = {tqe_next = 0xc2243380, tqe_prev = > 0xc224348c}, > > > > parent = 0xc2212680, children = {tqh_first = 0xc2262880, tqh_last = > > > > 0xc2262704}, driver = 0xc0b7066c, devclass = 0xc211e240, unit = 0, > > > > nameunit = 0xc2241640 "atapci0", desc = 0xc223f900 "Promise > PDC20621 > > > > UDMA100 controller", busy = 0, state = DS_ATTACHED, devflags = 0, > > > > flags = 13, order = 0 '\0', pad = 0 '\0', ivars = 0xc223f5c0, softc > = > > > > 0xc2244800, sysctl_ctx = {tqh_first = 0xc2264380, tqh_last = > 0xc2241594}, > > > > sysctl_tree = 0xc223f840} > > > > (kgdb) > > > > > > Maybe try adding KTR traces for all calls to device_set_ivars(). I > wonder > > > if > > > something is trashing this device's ivars. > > > > > > Oh, dear. The ata(4) driver overwrites the ivars of some PCI devices > it > > > attaches to. This is very, very wrong. Which ATA controller do you > have? > > > > > > -- > > > John Baldwin > > > > > > > Aha, I?m using a Promise Fasttrack SX4000 for a RAID1 setup. And the one > > included on the motherboard for the OS. > > And yes, I can confirm that without the Fasttrack SX4000 the system boots > up > > correctly. (Pulled out the card and edited fstab.) > > So you are right regarding that the ata driver messes something up. Do > you > > contact someone that is responsible for ata driver? > > > > Thank you for taking the time to "correct" this, > > Can you please try this patch? > > --- //depot/vendor/freebsd/src/sys/dev/ata/ata-pci.h 2009/03/30 22:20:14 > +++ //depot/user/jhb/acpipci/dev/ata/ata-pci.h 2009/05/08 20:27:43 > @@ -66,6 +66,7 @@ > void (*function)(void *); > void *argument; > } interrupt[8]; /* XXX SOS max ch# for now */ > + void *chipset_data; > }; > > /* defines for known chipset PCI id's */ > --- //depot/vendor/freebsd/src/sys/dev/ata/chipsets/ata-acard.c 2009/02/19 > 00:35:16 > +++ //depot/user/jhb/acpipci/dev/ata/chipsets/ata-acard.c 2009/05/08 > 20:27:43 > @@ -51,6 +51,12 @@ > #include > #include > > +struct ata_serialize { > + struct mtx locked_mtx; > + int locked_ch; > + int restart_ch; > +}; > + > /* local prototypes */ > static int ata_acard_chipinit(device_t dev); > static int ata_acard_ch_attach(device_t dev); > @@ -58,6 +64,7 @@ > static void ata_acard_850_setmode(device_t dev, int mode); > static void ata_acard_86X_setmode(device_t dev, int mode); > static int ata_serialize(device_t dev, int flags); > +static void ata_serialize_init(struct ata_serialize *serial); > > /* misc defines */ > #define ATP_OLD 1 > @@ -93,6 +100,7 @@ > ata_acard_chipinit(device_t dev) > { > struct ata_pci_controller *ctlr = device_get_softc(dev); > + struct ata_serialize *serial; > > if (ata_setup_interrupt(dev, ata_generic_intr)) > return ENXIO; > @@ -100,8 +108,12 @@ > ctlr->ch_attach = ata_acard_ch_attach; > ctlr->ch_detach = ata_pci_ch_detach; > if (ctlr->chip->cfg1 == ATP_OLD) { > - ctlr->setmode = ata_acard_850_setmode; > + ctlr->setmode = ata_acard_850_setmode; > ctlr->locking = ata_serialize; > + serial = malloc(sizeof(struct ata_serialize), > + M_TEMP, M_WAITOK | M_ZERO); > + ata_serialize_init(serial); > + ctlr->chipset_data = serial; > } > else > ctlr->setmode = ata_acard_86X_setmode; > @@ -225,11 +237,14 @@ > /* we could set PIO mode timings, but we assume the BIOS did that */ > } > > -struct ata_serialize { > - struct mtx locked_mtx; > - int locked_ch; > - int restart_ch; > -}; > +static void > +ata_serialize_init(struct ata_serialize *serial) > +{ > + > + mtx_init(&serial->locked_mtx, "ATA serialize lock", NULL, MTX_DEF); > + serial->locked_ch = -1; > + serial->restart_ch = -1; > +} > > static int > ata_serialize(device_t dev, int flags) > @@ -237,20 +252,9 @@ > struct ata_pci_controller *ctlr = > device_get_softc(device_get_parent(dev)); > struct ata_channel *ch = device_get_softc(dev); > struct ata_serialize *serial; > - static int inited = 0; > int res; > > - if (!inited) { > - serial = malloc(sizeof(struct ata_serialize), > - M_TEMP, M_NOWAIT | M_ZERO); > - mtx_init(&serial->locked_mtx, "ATA serialize lock", NULL, MTX_DEF); > - serial->locked_ch = -1; > - serial->restart_ch = -1; > - device_set_ivars(ctlr->dev, serial); > - inited = 1; > - } > - else > - serial = device_get_ivars(ctlr->dev); > + serial = ctlr->chipset_data; > > mtx_lock(&serial->locked_mtx); > switch (flags) { > --- //depot/vendor/freebsd/src/sys/dev/ata/chipsets/ata-promise.c > 2009/03/30 22:20:14 > +++ //depot/user/jhb/acpipci/dev/ata/chipsets/ata-promise.c 2009/05/08 > 20:27:43 > @@ -283,7 +283,7 @@ > mtx_init(&hpkt->mtx, "ATA promise HPKT lock", NULL, MTX_DEF); > TAILQ_INIT(&hpkt->queue); > hpkt->busy = 0; > - device_set_ivars(dev, hpkt); > + ctlr->chipset_data = hpkt; > ctlr->ch_attach = ata_promise_mio_ch_attach; > ctlr->ch_detach = ata_promise_mio_ch_detach; > ctlr->reset = ata_promise_mio_reset; > @@ -730,7 +730,7 @@ > case PR_SX4X: > > /* softreset channel ATA module */ > - hpktp = device_get_ivars(ctlr->dev); > + hpktp = ctlr->chipset_data; > ATA_OUTL(ctlr->r_res2, 0xc0260 + (ch->unit << 7), ch->unit + 1); > ata_udelay(1000); > ATA_OUTL(ctlr->r_res2, 0xc0260 + (ch->unit << 7), > @@ -1208,7 +1208,7 @@ > static void > ata_promise_queue_hpkt(struct ata_pci_controller *ctlr, u_int32_t hpkt) > { > - struct ata_promise_sx4 *hpktp = device_get_ivars(ctlr->dev); > + struct ata_promise_sx4 *hpktp = ctlr->chipset_data; > > mtx_lock(&hpktp->mtx); > if (hpktp->busy) { > @@ -1227,7 +1227,7 @@ > static void > ata_promise_next_hpkt(struct ata_pci_controller *ctlr) > { > - struct ata_promise_sx4 *hpktp = device_get_ivars(ctlr->dev); > + struct ata_promise_sx4 *hpktp = ctlr->chipset_data; > struct host_packet *hp; > > mtx_lock(&hpktp->mtx); > > -- > John Baldwin > This is only a response to everyone that is following this thread and have had the same errors as I have... and are looking for a solution. The patch will NOT work for FreeBSD 7.0 or 7.1. This patch www.freebsd.org/~jhb/patches/ata_ivars_7.patch. will WORK for FreeBSD 7. I have tried it with 7.1-RC2 and it works. John Baldwin will commit the bits to source at a later stage. (Said in an non-list email). /Magnus From ghostp at dzsy.org Fri May 15 09:04:54 2009 From: ghostp at dzsy.org (=?ISO-8859-1?Q?Sz=E9kv=F6lgyi_P=E9ter?=) Date: Fri May 15 09:05:02 2009 Subject: No brightness control on Acer laptop In-Reply-To: <4A05EA96.4090908@dzsy.org> References: <4A05EA96.4090908@dzsy.org> Message-ID: <4A0D3032.7060106@dzsy.org> Hi everyone, If i upgrade my system to CURRENT may be the brightness control working? I don't known better the ACPI support on CURRENT? Peter Sz?kv?lgyi P?ter wrote: > Hi everyone, > > I have a Acer Extensa 5620 laptop and i didn't change the brightness > with keys or sysctl value. > I loaded asus, ibm and other laptop acpi modul, but nothing change. > Anyone has an idea how > can i change the brightness fater the system booted? ( Without ACPI i > can change, the brightness. ) > > I send a PR too: > http://www.freebsd.org/cgi/query-pr.cgi?pr=132535 > > Now my system is: > FreeBSD dzsy-note.dzsy.org 7.2-STABLE FreeBSD 7.2-STABLE #0: Thu May 7 > 23:13:54 CEST 2009 ... i386 > > Thanks, > Peter > > > _______________________________________________ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" From mickey242 at gmx.net Fri May 15 13:01:56 2009 From: mickey242 at gmx.net (Andreas Wetzel) Date: Fri May 15 13:02:03 2009 Subject: ThinkPad T30, 7.2-RELEASE, wrong CPU speed detected? Message-ID: <4A0D617D.5070008@gmx.net> After an upgrade from 7.1-RELEASE-p3 to 7.2-RELEASE, on an IBM ThinkPad T30: CPU: Mobile Intel(R) Pentium(R) 4 - M CPU 2.00GHz (1196.13-MHz 686-class CPU) ^^^^^^^ ^^^^^^^^ This seems not right. Additionally sysctl shows these: dev.cpu.0.freq: 1200 dev.cpu.0.freq_levels: 1200/0 1050/0 900/0 750/0 600/0 450/0 300/0 I know there has been some discussion going on a while ago, which suggested to not compile cpufreq into the kernel, which i will try in a few moments. Anyway, this does not seem right. -- Keep it icy man. I don't want to end up a corpse before my time because you were daydreaming. From jhb at freebsd.org Fri May 15 13:11:05 2009 From: jhb at freebsd.org (John Baldwin) Date: Fri May 15 13:11:12 2009 Subject: suspend/resume, amd64, FreeBSD 7.2 In-Reply-To: <24a7fa6d0905141803x2205621s5f99642ce61ae56b@mail.gmail.com> References: <24a7fa6d0905141803x2205621s5f99642ce61ae56b@mail.gmail.com> Message-ID: <200905150802.56267.jhb@freebsd.org> On Thursday 14 May 2009 9:03:10 pm Marco Carmosino wrote: > There seem to be no other error messages, just "Operation not > supported." This is confusing, because S3 is listed as supported, and > I found http://lists.freebsd.org/pipermail/freebsd-amd64/2009-March/011982.html > this thread from back in march saying that amd64 suspend code has been > committed. It has only been committed to HEAD (aka 8.0). It is not present in 7.x. -- John Baldwin From jhb at freebsd.org Fri May 15 21:07:00 2009 From: jhb at freebsd.org (John Baldwin) Date: Fri May 15 21:07:05 2009 Subject: ThinkPad T30, 7.2-RELEASE, wrong CPU speed detected? In-Reply-To: <4A0D617D.5070008@gmx.net> References: <4A0D617D.5070008@gmx.net> Message-ID: <200905151602.36747.jhb@freebsd.org> On Friday 15 May 2009 8:35:09 am Andreas Wetzel wrote: > After an upgrade from 7.1-RELEASE-p3 to 7.2-RELEASE, on an IBM ThinkPad T30: > > > CPU: Mobile Intel(R) Pentium(R) 4 - M CPU 2.00GHz (1196.13-MHz 686-class CPU) > ^^^^^^^ ^^^^^^^^ > > This seems not right. > > Additionally sysctl shows these: > > dev.cpu.0.freq: 1200 > dev.cpu.0.freq_levels: 1200/0 1050/0 900/0 750/0 600/0 450/0 300/0 > > I know there has been some discussion going on a while ago, which suggested to > not compile cpufreq into the kernel, which i will try in a few moments. > Anyway, this does not seem right. Are you on battery? -- John Baldwin From bugmaster at FreeBSD.org Mon May 18 11:06:46 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon May 18 11:07:09 2009 Subject: Current problem reports assigned to freebsd-acpi@FreeBSD.org Message-ID: <200905181106.n4IB6jID075538@freefall.freebsd.org> 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/132602 acpi [acpi] ACPI Problem with Intel SS4200: System does not o kern/130683 acpi [ACPI] shutdown hangs after syncing disks - ACPI race? o i386/129953 acpi [acpi] ACPI timeout (CDROM) with Shuttle X27D o kern/129618 acpi [acpi] Problem with ACPI on HP Pavilion DV2899 laptop o kern/129563 acpi [acpi] sleep broken on IBM/Lenovo T61 in amd64 mode o kern/128639 acpi [patch] [acpi_asus] acpi for ASUS A6F,A3E,A3F,A3N not f kern/128634 acpi [patch] fix acpi_asus(4) in asus a6f laptop o kern/127581 acpi [patch] [acpi_sony] Add support for more Sony features o kern/124744 acpi [acpi] [patch] incorrect _BST result validation for To o kern/124412 acpi [acpi] power off error on Toshiba M40 laptop o kern/123039 acpi [acpi] ACPI AML_BUFFER_LIMIT errors during boot o kern/121504 acpi [patch] Correctly set hw.acpi.osname on certain machin f kern/121454 acpi [pst] Promise SuperTrak SX6000 does not load during bo o kern/121102 acpi [acpi_fujitsu] [patch] update acpi_fujitsu for the P80 o kern/120515 acpi [acpi] [patch] acpi_alloc_wakeup_handler: can't alloc o kern/119356 acpi [acpi]: i386 ACPI wakeup not work due resource exhaust o kern/119200 acpi [acpi] Lid close switch suspends CPU for 1 second on H o kern/118973 acpi [acpi]: Kernel panic with acpi boot o kern/117605 acpi [acpi] [request] add debug.cpufreq.highest o kern/116939 acpi [acpi] PCI-to-PCI misconfigured for bus three and can o i386/114562 acpi [acpi] cardbus is dead after s3 on Thinkpad T43 with a o kern/114165 acpi [acpi] Dell C810 - ACPI problem s kern/112544 acpi [acpi] [patch] Add High Precision Event Timer Driver f o kern/108954 acpi [acpi] 'sleep(1)' sleeps >1 seconds when speedstep (Cx o kern/108695 acpi [acpi]: Fatal trap 9: general protection fault when in o kern/108488 acpi [acpi] ACPI-1304: *** Error: Method execution failed o kern/108017 acpi [acpi]: Acer Aspire 5600 o kern/106924 acpi [acpi] ACPI resume returns g_vfs_done() errors and ker o kern/105537 acpi [acpi] problems in acpi on HP Compaq nc6320 o kern/104625 acpi ACPI on ASUS A8N-32 SLI/ASUS P4P800 does not show ther o kern/102252 acpi acpi thermal does not work on Abit AW8D (intel 975) o kern/97383 acpi Volume buttons on IBM Thinkpad crash system with ACPI s i386/91748 acpi acpi problem on Acer TravelMare 4652LMi (nvidia panic, s kern/91038 acpi [panic] [ata] [acpi] 6.0-RELEASE on Fujitsu Siemens Am s kern/90243 acpi Laptop fan doesn't turn off (ACPI enabled) (Packard Be f kern/89411 acpi [acpi] acpiconf bug o i386/83018 acpi [install] Installer will not boot on Asus P4S8X BIOS 1 o kern/81000 acpi [apic] Via 8235 sound card worked great with FreeBSD 5 o i386/79081 acpi ACPI suspend/resume not working on HP nx6110 o kern/76950 acpi ACPI wrongly blacklisted on Micron ClientPro 766Xi sys s kern/73823 acpi [request] acpi / power-on by timer support o i386/72566 acpi ACPI, FreeBSD disables fan on Compaq Armada 1750 o i386/69750 acpi Boot without ACPI failed on ASUS L5 o kern/56024 acpi ACPI suspend drains battery while in S3 o i386/55661 acpi ACPI suspend/resume problem on ARMADA M700 o i386/54756 acpi ACPI suspend/resume problem on CF-W2 laptop 46 problems total. From avg at freebsd.org Mon May 18 16:04:54 2009 From: avg at freebsd.org (Andriy Gapon) Date: Mon May 18 16:05:00 2009 Subject: 6.x acpi powerbutton In-Reply-To: <49EF15B0.10402@icyb.net.ua> References: <49DE1F8B.2080400@earthlink.net> <49DE2E6D.5050001@icyb.net.ua> <49DE596E.2050406@earthlink.net> <49DEFF53.1040306@icyb.net.ua> <49DF7A1C.90009@root.org> <20090418043432.O34434@sola.nimnet.asn.au> <49E8D824.1000001@root.org> <20090417200726.GG3014@deviant.kiev.zoral.com.ua> <49E8E6E3.40304@root.org> <49EDFAED.4030606@icyb.net.ua> <49EE1863.1000306@root.org> <49EF15B0.10402@icyb.net.ua> Message-ID: <4A11870D.1030805@freebsd.org> on 22/04/2009 16:03 Andriy Gapon said the following: > on 21/04/2009 22:02 Nate Lawson said the following: >> They are interested in the initiator of the event, the button itself. So >> you'd be adding a printf to the power button handler, "power button >> pressed". Then the normal shutdown messages would be logged but they >> would know the reason. Remember that with sysctl, you can configure >> different events to button mappings. So the power button could be used >> to initiate a suspend, for example. > > Yes, I agree. > Which place do you think is the best for this log - acpi sleep event handler > (acpi_system_eventhandler_sleep) or individual sleep event triggers (power button > sleep button, lid)? Following up on this - maybe we can just change ACPI_VPRINT to device_printf in acpi_button_notify_sleep? -- Andriy Gapon From avg at freebsd.org Mon May 18 16:29:08 2009 From: avg at freebsd.org (Andriy Gapon) Date: Mon May 18 16:29:14 2009 Subject: 6.x acpi powerbutton In-Reply-To: <4A11870D.1030805@freebsd.org> References: <49DE1F8B.2080400@earthlink.net> <49DE2E6D.5050001@icyb.net.ua> <49DE596E.2050406@earthlink.net> <49DEFF53.1040306@icyb.net.ua> <49DF7A1C.90009@root.org> <20090418043432.O34434@sola.nimnet.asn.au> <49E8D824.1000001@root.org> <20090417200726.GG3014@deviant.kiev.zoral.com.ua> <49E8E6E3.40304@root.org> <49EDFAED.4030606@icyb.net.ua> <49EE1863.1000306@root.org> <49EF15B0.10402@icyb.net.ua> <4A11870D.1030805@freebsd.org> Message-ID: <4A118CC1.7060507@freebsd.org> on 18/05/2009 19:04 Andriy Gapon said the following: > Following up on this - maybe we can just change ACPI_VPRINT to device_printf in > acpi_button_notify_sleep? Oh, nonsense, this would work only for "control method" button case. So printf needs to be in acpi_event_power_button_sleep and acpi_event_sleep_button_sleep... -- Andriy Gapon From avg at freebsd.org Mon May 18 17:03:24 2009 From: avg at freebsd.org (Andriy Gapon) Date: Mon May 18 17:03:29 2009 Subject: 6.x acpi powerbutton In-Reply-To: <4A118CC1.7060507@freebsd.org> References: <49DE1F8B.2080400@earthlink.net> <49DE2E6D.5050001@icyb.net.ua> <49DE596E.2050406@earthlink.net> <49DEFF53.1040306@icyb.net.ua> <49DF7A1C.90009@root.org> <20090418043432.O34434@sola.nimnet.asn.au> <49E8D824.1000001@root.org> <20090417200726.GG3014@deviant.kiev.zoral.com.ua> <49E8E6E3.40304@root.org> <49EDFAED.4030606@icyb.net.ua> <49EE1863.1000306@root.org> <49EF15B0.10402@icyb.net.ua> <4A11870D.1030805@freebsd.org> <4A118CC1.7060507@freebsd.org> Message-ID: <4A1194D6.5020307@freebsd.org> on 18/05/2009 19:28 Andriy Gapon said the following: > on 18/05/2009 19:04 Andriy Gapon said the following: >> Following up on this - maybe we can just change ACPI_VPRINT to device_printf in >> acpi_button_notify_sleep? > > Oh, nonsense, this would work only for "control method" button case. > So printf needs to be in acpi_event_power_button_sleep and > acpi_event_sleep_button_sleep... > BTW, from the code in acpi_button ("ACPI_FPB", "ACPI_FSB") it seems that the original intention was to use that driver for both fixed and "control method" buttons, but in fact the fixed case is handled directly in acpi.c code. -- Andriy Gapon From robert.moore at intel.com Thu May 21 15:57:09 2009 From: robert.moore at intel.com (Moore, Robert) Date: Thu May 21 16:06:41 2009 Subject: ACPICA version 20090521 released Message-ID: <4911F71203A09E4D9981D27F9D8308582E0E5016@orsmsx503.amr.corp.intel.com> 21 May 2009. Summary of changes for version 20090521: This release is available at www.acpica.org/downloads 1) ACPI CA Core Subsystem: Disabled the preservation of the SCI enable bit in the PM1 control register. The SCI enable bit (bit 0, SCI_EN) is defined by the ACPI specification to be a "preserved" bit - "OSPM always preserves this bit position", section 4.7.3.2.1. However, some machines fail if this bit is in fact preserved because the bit needs to be explicitly set by the OS as a workaround. No machines fail if the bit is not preserved. Therefore, ACPICA no longer attempts to preserve this bit. Fixed a problem in AcpiRsGetPciRoutingTableLength where an invalid or incorrectly formed _PRT package could cause a fault. Added validation to ensure that each package element is actually a sub-package. Implemented a new interface to install or override a single control method, AcpiInstallMethod. This interface is useful when debugging in order to repair an existing method or to install a missing method without having to override the entire ACPI table. See the ACPICA Programmer Reference for use and examples. Lin Ming, Bob Moore. Fixed several reference count issues with the DdbHandle object that is created from a Load or LoadTable operator. Prevent premature deletion of the object. Also, mark the object as invalid once the table has been unloaded. This is needed because the handle itself may not be deleted after the table unload, depending on whether it has been stored in a named object by the caller. Lin Ming. Fixed a problem with Mutex Sync Levels. Fixed a problem where if multiple mutexes of the same sync level are acquired but then not released in strict opposite order, the internally maintained Current Sync Level becomes confused and can cause subsequent execution errors. ACPICA BZ 471. Changed the allowable release order for ASL mutex objects. The ACPI 4.0 specification has been changed to make the SyncLevel for mutex objects more useful. When releasing a mutex, the SyncLevel of the mutex must now be the same as the current sync level. This makes more sense than the previous rule (SyncLevel less than or equal). This change updates the code to match the specification. Fixed a problem with the local version of the AcpiOsPurgeCache function. The (local) cache must be locked during all cache object deletions. Andrew Baumann. Updated the Load operator to use operation region interfaces. This replaces direct memory mapping with region access calls. Now, all region accesses go through the installed region handler as they should. Simplified and optimized the NsGetNextNode function. Reduced parameter count and reduced code for this frequently used function. Example Code and Data Size: These are the sizes for the OS-independent acpica.lib produced by the Microsoft Visual C++ 6.0 32-bit compiler. The debug version of the code includes the debug output trace mechanism and has a much larger code and data size. Previous Release: Non-Debug Version: 82.8K Code, 17.5K Data, 100.3K Total Debug Version: 158.0K Code, 49.9K Data, 207.9K Total Current Release: Non-Debug Version: 83.4K Code, 17.5K Data, 100.9K Total Debug Version: 158.9K Code, 50.0K Data, 208.9K Total 2) iASL Compiler/Disassembler and Tools: Disassembler: Fixed some issues with DMAR, HEST, MADT tables. Some problems with sub-table disassembly and handling invalid sub-tables. Attempt recovery after an invalid sub-table ID. From jkim at FreeBSD.org Thu May 21 22:34:52 2009 From: jkim at FreeBSD.org (Jung-uk Kim) Date: Thu May 21 22:34:58 2009 Subject: ACPICA version 20090521 released In-Reply-To: <4911F71203A09E4D9981D27F9D8308582E0E5016@orsmsx503.amr.corp.intel.com> References: <4911F71203A09E4D9981D27F9D8308582E0E5016@orsmsx503.amr.corp.intel.com> Message-ID: <200905211834.43324.jkim@FreeBSD.org> On Thursday 21 May 2009 11:56 am, Moore, Robert wrote: > 21 May 2009. Summary of changes for version 20090521: > > This release is available at www.acpica.org/downloads > > 1) ACPI CA Core Subsystem: > > Disabled the preservation of the SCI enable bit in the PM1 control > register. The SCI enable bit (bit 0, SCI_EN) is defined by the ACPI > specification to be a "preserved" bit - "OSPM always preserves this > bit position", section 4.7.3.2.1. However, some machines fail if > this bit is in fact preserved because the bit needs to be > explicitly set by the OS as a workaround. No machines fail if the > bit is not preserved. Therefore, ACPICA no longer attempts to > preserve this bit. > > Fixed a problem in AcpiRsGetPciRoutingTableLength where an invalid > or incorrectly formed _PRT package could cause a fault. Added > validation to ensure that each package element is actually a > sub-package. > > Implemented a new interface to install or override a single control > method, AcpiInstallMethod. This interface is useful when debugging > in order to repair an existing method or to install a missing > method without having to override the entire ACPI table. See the > ACPICA Programmer Reference for use and examples. Lin Ming, Bob > Moore. > > Fixed several reference count issues with the DdbHandle object that > is created from a Load or LoadTable operator. Prevent premature > deletion of the object. Also, mark the object as invalid once the > table has been unloaded. This is needed because the handle itself > may not be deleted after the table unload, depending on whether it > has been stored in a named object by the caller. Lin Ming. > > Fixed a problem with Mutex Sync Levels. Fixed a problem where if > multiple mutexes of the same sync level are acquired but then not > released in strict opposite order, the internally maintained > Current Sync Level becomes confused and can cause subsequent > execution errors. ACPICA BZ 471. > > Changed the allowable release order for ASL mutex objects. The ACPI > 4.0 specification has been changed to make the SyncLevel for mutex > objects more useful. When releasing a mutex, the SyncLevel of the > mutex must now be the same as the current sync level. This makes > more sense than the previous rule (SyncLevel less than or equal). > This change updates the code to match the specification. > > Fixed a problem with the local version of the AcpiOsPurgeCache > function. The (local) cache must be locked during all cache object > deletions. Andrew Baumann. > > Updated the Load operator to use operation region interfaces. This > replaces direct memory mapping with region access calls. Now, all > region accesses go through the installed region handler as they > should. > > Simplified and optimized the NsGetNextNode function. Reduced > parameter count and reduced code for this frequently used function. > > Example Code and Data Size: These are the sizes for the > OS-independent acpica.lib produced by the Microsoft Visual C++ 6.0 > 32-bit compiler. The debug version of the code includes the debug > output trace mechanism and has a much larger code and data size. > > Previous Release: > Non-Debug Version: 82.8K Code, 17.5K Data, 100.3K Total > Debug Version: 158.0K Code, 49.9K Data, 207.9K Total > Current Release: > Non-Debug Version: 83.4K Code, 17.5K Data, 100.9K Total > Debug Version: 158.9K Code, 50.0K Data, 208.9K Total > > 2) iASL Compiler/Disassembler and Tools: > > Disassembler: Fixed some issues with DMAR, HEST, MADT tables. Some > problems with sub-table disassembly and handling invalid > sub-tables. Attempt recovery after an invalid sub-table ID. I just uploaded a new patchset against -CURRENT: http://people.freebsd.org/~jkim/acpica-import-20090521.diff.gz Please note that I am planning on merging it before 8.0 release. Therefore, it needs more regression tests and serious code reviews now. Thanks, Jung-uk Kim From Sales at Tijanre.ae Fri May 22 17:48:11 2009 From: Sales at Tijanre.ae (Tijan) Date: Fri May 22 17:48:19 2009 Subject: Distressed Freehold Properties 4 Sale @ OP Message-ID: <124296075303e0d98064800f8796170671996c6168@Tijanre.ae> Distressed Freehold Properties 4 Sale @ Original Price (Direct From the Owner) Half Floor Offices - Full Floor Offices - Showroom -Shops - Villa Call: Eng. Khaldoun: 050 4629302 Half Floor Offices @ Dubai Silicon Oasis -Freehold & Free zone Tower: Palace Towers, Developer: Tameer holdings Floor: 9 th Floor (3 offices, 3 Bath, 3 Kitchen, 6 basement Parking ) Total Area: 7,277 Sq. ft Delivery: Ready on April 2009 Location:: Corner, Prime Location on the entrance of DSO Corner, Amazing direct View to Main / RA & Academy City, Facilities: 25 floors luxurious building, 6 lifts, Retails, swimming Pool, Mini Golf, Equipped Gymnasium, Shopping Arcade Payment Plan: 80% Paid, 20% on Delivery Original Price: AED 5,424,764 (745 /Sq. ft) Selling Price: AED 5,424,764 (745 /Sq. ft) Net Full Floor Offices @ Dubai Silicon Oasis -Freehold & Free zone Tower: Palace Towers, Developer: Tameer holdings Floor: 16 Floor (6 offices, 6 Bath, 6 Kitchen,13 basement Parking) Total Area: 13,534 Sq. ft Delivery: Ready on April 2009 Location:: Corner, Prime Location on the entrance of DSO Corner, Amazing direct View to Main / RA & Academy City, Facilities: 25 floors luxurious building, 6 lifts, Retails, swimming Pool, Mini Golf, Equipped Gymnasium, Shopping Arcade Payment Plan: 80% Paid, 20% on Delivery Original Price: AED 10,367,724 (767 /Sq. ft) Selling Price: AED 10,367,724 (767 /Sq. ft) Net Freehold Villa 4 Sale @ Jumeirah Park (Phase 1) Type: 3B/R + Maids Legacy Small - Big Plot Villa No.: JP-H3VS-040 View: Full Water Canal from Front & Full Park from Rear Details: 2 Story Duplex Detached Villa, 3 B/R+ Maids + 4 Bath R, Living, Dining, 3 Balcony, Garage Plot Area: 7,320 Sq. Ft, (Big Plot) Built up: 3,612 Sq Ft. (Net 3,063 Sq. Ft) Delivery: September 2009 Original Price: AED 2,467,600 Selling Price: AED 2,467,600 Net Payment Plan: 75% Paid, 15% on May 2009,10% on Completion Showroom / Shops @ International City CBD- Freehold Shop Nos.: 1-2-3-4, with 4 Bath, 4 Kitchen, 4 Parking in basement Building: G+10 Al Dana 2 ? Developer: Tameer holdings Cluster: CBD (Central Businesses District) Details: 4 Shops each has bath and buffet, it can open to get huge Showroom, Suitable for: Bank, Exchange, Restaurant, Coffee Shop View: Corner direct view to Main Round about & Forbidden City Total Area: 4,500 Sq. Ft (2,063 Sq. Ft + Huge Terrace 2,500 Sq. Ft Delivery: Ready to Move in, Brand New Original Price: AED 2,476,000 Selling Price: AED 2,476,000 Net From ghostp at mcss.hu Sun May 24 09:28:04 2009 From: ghostp at mcss.hu (=?ISO-8859-1?Q?Sz=E9kv=F6lgyi_P=E9ter?=) Date: Sun May 24 09:28:11 2009 Subject: No brightness control on Acer laptop In-Reply-To: <4A05EA96.4090908@dzsy.org> References: <4A05EA96.4090908@dzsy.org> Message-ID: <4A19131D.3050705@mcss.hu> Sz?kv?lgyi P?ter wrote: > I have a Acer Extensa 5620 laptop and i didn't change the brightness > with keys or sysctl value. > I loaded asus, ibm and other laptop acpi modul, but nothing change. > Anyone has an idea how > can i change the brightness fater the system booted? ( Without ACPI i > can change, the brightness. ) Hi everyone! A boot-ed with verbose mode, and if i want to change the brightness i saw on dmesg: ( brightness down with key ): acpi: bad write to port 0x080 (32), val 0x1d or ( brightness up with key ) acpi: bad write to port 0x080 (32), val 0x1c I tested with other dsdt file from google acer acpi, nothing changed: http://aceracpi.googlecode.com/svn/trunk/dsdt/acer/extensa/ I installed FreeBSD-Current to an usb key and booted. The error is the same with brightness control. Anyone has an idea wath wrong? Thanks ours help! Peter From niktychina at gmail.com Sun May 24 13:26:28 2009 From: niktychina at gmail.com (Nikolay Tychina) Date: Sun May 24 13:26:35 2009 Subject: No brightness control on Acer laptop In-Reply-To: References: <4A05EA96.4090908@dzsy.org> <4A19131D.3050705@mcss.hu> Message-ID: Did you try to fix your dsdt (it has only one error, mine has 7 :-) )? Also you can download original & fixed dsdt from http://acpi.sourceforge.net/dsdt/view.php?manufacturer=ACER and fix yours by analogy. Did you try http://code.google.com/p/acpi-amilo/ Author writes it can be useful with Acers (it didn't help me though) Best, Nikolay From niktychina at gmail.com Sun May 24 13:43:29 2009 From: niktychina at gmail.com (Nikolay Tychina) Date: Sun May 24 13:43:35 2009 Subject: No brightness control on Acer laptop In-Reply-To: <4A19131D.3050705@mcss.hu> References: <4A05EA96.4090908@dzsy.org> <4A19131D.3050705@mcss.hu> Message-ID: I tried aceracpi project's dstd too for my Aspire 5520, but that dsdts are not fixed. :-( 2009/5/24 Sz?kv?lgyi P?ter > Sz?kv?lgyi P?ter wrote: > >> I have a Acer Extensa 5620 laptop and i didn't change the brightness >> with keys or sysctl value. >> I loaded asus, ibm and other laptop acpi modul, but nothing change. >> Anyone has an idea how >> can i change the brightness fater the system booted? ( Without ACPI i >> can change, the brightness. ) >> > > Hi everyone! > > A boot-ed with verbose mode, and if i want to change the brightness i saw > on dmesg: ( brightness down with key ): > acpi: bad write to port 0x080 (32), val 0x1d > or ( brightness up with key ) > acpi: bad write to port 0x080 (32), val 0x1c > > I tested with other dsdt file from google acer acpi, nothing changed: > http://aceracpi.googlecode.com/svn/trunk/dsdt/acer/extensa/ > > I installed FreeBSD-Current to an usb key and booted. The error is the > same with brightness control. > > Anyone has an idea wath wrong? > > Thanks ours help! > Peter > > _______________________________________________ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" > From rea-fbsd at codelabs.ru Sun May 24 17:07:40 2009 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Sun May 24 17:08:12 2009 Subject: [rea-fbsd@codelabs.ru: Patch for "device_attach: estX attach returned 6" on half of the cores] Message-ID: Sorry for cross-posting (this mail was originally posted to -current), but may be not all persons who are interested in ACPI are reading -current. Original thread can be tracked at http://lists.freebsd.org/pipermail/freebsd-current/2009-May/006444.html and there is FreeBSD PR, http://www.freebsd.org/cgi/query-pr.cgi?pr=134192 If someone have ACPI tables with processor aliases -- the patch can help to attach est instances. I'd appreciate any testing and may be some knowledgeable person can review this and help to commit the patch. Thanks! -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # -------------- next part -------------- An embedded message was scrubbed... From: Eygene Ryabinkin Subject: Patch for "device_attach: estX attach returned 6" on half of the cores Date: Mon, 4 May 2009 09:22:32 +0400 Size: 4125 Url: http://lists.freebsd.org/pipermail/freebsd-acpi/attachments/20090524/9490b4af/attachment.eml From ghostp at mcss.hu Sun May 24 19:31:41 2009 From: ghostp at mcss.hu (=?ISO-8859-1?Q?Sz=E9kv=F6lgyi_P=E9ter?=) Date: Sun May 24 19:31:53 2009 Subject: No brightness control on Acer laptop In-Reply-To: References: <4A05EA96.4090908@dzsy.org> <4A19131D.3050705@mcss.hu> Message-ID: <4A19A095.5060802@mcss.hu> Nikolay Tychina wrote: > Did you try to fix your dsdt (it has only one error, mine has 7 :-) )? > Also you can download original & fixed dsdt from > http://acpi.sourceforge.net/dsdt/view.php?manufacturer=ACER > and fix yours by analogy. > > Did you try http://code.google.com/p/acpi-amilo/ > I tested it, only change my wireless radio switch is default to off. From http://acpi.sourceforge.net/dsdt/view.php?manufacturer=ACER i downloaded ACER Extensa 4002 and 4001 dsdt, i compile it and reboot the brightness control works corectly, but i haven't battery monitor, thermal control, etc. I saw the original dsdt from "acpidump" and it has an error, like the dsdt from google source. I see the source, but this time i never programming in this language, so i didn't know what is wrong. Anyone has a link or anything how can i learn? Thanks, Peter From bugmaster at FreeBSD.org Mon May 25 11:06:46 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon May 25 11:07:09 2009 Subject: Current problem reports assigned to freebsd-acpi@FreeBSD.org Message-ID: <200905251106.n4PB6jbC092673@freefall.freebsd.org> 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/132602 acpi [acpi] ACPI Problem with Intel SS4200: System does not o kern/130683 acpi [ACPI] shutdown hangs after syncing disks - ACPI race? o i386/129953 acpi [acpi] ACPI timeout (CDROM) with Shuttle X27D o kern/129618 acpi [acpi] Problem with ACPI on HP Pavilion DV2899 laptop o kern/129563 acpi [acpi] sleep broken on IBM/Lenovo T61 in amd64 mode o kern/128639 acpi [patch] [acpi_asus] acpi for ASUS A6F,A3E,A3F,A3N not f kern/128634 acpi [patch] fix acpi_asus(4) in asus a6f laptop o kern/127581 acpi [patch] [acpi_sony] Add support for more Sony features o kern/124744 acpi [acpi] [patch] incorrect _BST result validation for To o kern/124412 acpi [acpi] power off error on Toshiba M40 laptop o kern/123039 acpi [acpi] ACPI AML_BUFFER_LIMIT errors during boot o kern/121504 acpi [patch] Correctly set hw.acpi.osname on certain machin f kern/121454 acpi [pst] Promise SuperTrak SX6000 does not load during bo o kern/121102 acpi [acpi_fujitsu] [patch] update acpi_fujitsu for the P80 o kern/120515 acpi [acpi] [patch] acpi_alloc_wakeup_handler: can't alloc o kern/119356 acpi [acpi]: i386 ACPI wakeup not work due resource exhaust o kern/119200 acpi [acpi] Lid close switch suspends CPU for 1 second on H o kern/118973 acpi [acpi]: Kernel panic with acpi boot o kern/117605 acpi [acpi] [request] add debug.cpufreq.highest o kern/116939 acpi [acpi] PCI-to-PCI misconfigured for bus three and can o i386/114562 acpi [acpi] cardbus is dead after s3 on Thinkpad T43 with a o kern/114165 acpi [acpi] Dell C810 - ACPI problem s kern/112544 acpi [acpi] [patch] Add High Precision Event Timer Driver f o kern/108954 acpi [acpi] 'sleep(1)' sleeps >1 seconds when speedstep (Cx o kern/108695 acpi [acpi]: Fatal trap 9: general protection fault when in o kern/108488 acpi [acpi] ACPI-1304: *** Error: Method execution failed o kern/108017 acpi [acpi]: Acer Aspire 5600 o kern/106924 acpi [acpi] ACPI resume returns g_vfs_done() errors and ker o kern/105537 acpi [acpi] problems in acpi on HP Compaq nc6320 o kern/104625 acpi ACPI on ASUS A8N-32 SLI/ASUS P4P800 does not show ther o kern/102252 acpi acpi thermal does not work on Abit AW8D (intel 975) o kern/97383 acpi Volume buttons on IBM Thinkpad crash system with ACPI s i386/91748 acpi acpi problem on Acer TravelMare 4652LMi (nvidia panic, s kern/91038 acpi [panic] [ata] [acpi] 6.0-RELEASE on Fujitsu Siemens Am s kern/90243 acpi Laptop fan doesn't turn off (ACPI enabled) (Packard Be f kern/89411 acpi [acpi] acpiconf bug o i386/83018 acpi [install] Installer will not boot on Asus P4S8X BIOS 1 o kern/81000 acpi [apic] Via 8235 sound card worked great with FreeBSD 5 o i386/79081 acpi ACPI suspend/resume not working on HP nx6110 o kern/76950 acpi ACPI wrongly blacklisted on Micron ClientPro 766Xi sys s kern/73823 acpi [request] acpi / power-on by timer support o i386/72566 acpi ACPI, FreeBSD disables fan on Compaq Armada 1750 o i386/69750 acpi Boot without ACPI failed on ASUS L5 o kern/56024 acpi ACPI suspend drains battery while in S3 o i386/55661 acpi ACPI suspend/resume problem on ARMADA M700 o i386/54756 acpi ACPI suspend/resume problem on CF-W2 laptop 46 problems total. From rpaulo at gmail.com Tue May 26 00:44:06 2009 From: rpaulo at gmail.com (Rui Paulo) Date: Tue May 26 00:44:12 2009 Subject: [rea-fbsd@codelabs.ru: Patch for "device_attach: estX attach returned 6" on half of the cores] In-Reply-To: References: Message-ID: Hi, On 24 May 2009, at 17:57, Eygene Ryabinkin wrote: > Sorry for cross-posting (this mail was originally posted to -current), > but may be not all persons who are interested in ACPI are reading > -current. Original thread can be tracked at > http://lists.freebsd.org/pipermail/freebsd-current/2009-May/006444.html > and there is FreeBSD PR, > http://www.freebsd.org/cgi/query-pr.cgi?pr=134192 > > If someone have ACPI tables with processor aliases -- the patch can > help > to attach est instances. I'd appreciate any testing and may be some > knowledgeable person can review this and help to commit the patch. Regarding to the code in the patch, is this your code or something from a more recent ACPI-CA? If it is your code, could you please try to submit this upstream? In any case the patch looks good. Thanks, -- Rui Paulo -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-acpi/attachments/20090526/3ed8e569/PGP.pgp From gnemmi at gmail.com Tue May 26 01:42:44 2009 From: gnemmi at gmail.com (Gonzalo Nemmi) Date: Tue May 26 01:42:52 2009 Subject: Fatal trap 9 on boot without ACPI in 7.2-RELEASE Message-ID: <200905252212.20796.gnemmi@gmail.com> Hi guys ! First mail to this list .. so please forgive me if this turns out to be the wrong list .. but since the problem relates to ACPI I thought I would rather send the mail to this list than to cross post. The thing is that I get a "Fatal trap 9" everytime I try to boot my notebook "without ACPI enable" in 7.2-RELEASE. Said notebook is a Dell Inspiron 1318 ( hw. details can be found on the link to my "boot -v") Here's what I get when I boot without ACPI: Fatal trap 9: general protection fault while in kernel mode cpuid = 0; acpic id = 00 instruction pointer = 0x70:0xbfe4 stack pointer = 0x28:0xfa4 frame pointer = 0x28:0xfd4 code segment = base 0xc00f0000, limit 0xffff, type 0x1b = DPL 0, pres 1, def32 0, gran 0 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 0 (swapper) trap number = 9 panic: general protection fault cpuid = 0 Uptime: 1s Automatic reboot in 15 sedconds - press a key on the console to abort As you can figure out, getting a "boot -v" without ACPI enabled is impossible :s You'll find my "boot -v" (ACPI enabled) in here: http://pastebin.com/f3a1c204a "sysctl -a | grep hw.acpi | sort" in here: http://pastebin.com/fcfc0035 I have no place to wich upload my gonzalo-Dell1318.asl file but this is the output from "iasl gonzalo-Dell1318.asl": http://pastebin.com/f3f7f4178 If you need more info, please let me know. Best Regards -- Blessings Gonzalo Nemmi From rea-fbsd at codelabs.ru Tue May 26 09:54:26 2009 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Tue May 26 09:54:33 2009 Subject: [rea-fbsd@codelabs.ru: Patch for "device_attach: estX attach returned 6" on half of the cores] In-Reply-To: References: Message-ID: Rui, good day. Tue, May 26, 2009 at 01:16:37AM +0100, Rui Paulo wrote: > > If someone have ACPI tables with processor aliases -- the patch can > > help > > to attach est instances. I'd appreciate any testing and may be some > > knowledgeable person can review this and help to commit the patch. > > Regarding to the code in the patch, is this your code or something > from a more recent ACPI-CA? It's mine ;)) Though I hadn't looked at the newer ACPI-CA yet. > If it is your code, could you please try to submit this upstream? Will try. I had tried to subscribe to the mailing list at http://lists.acpica.org/mailman/listinfo/devel but their host certificate is revoked(!). Moreover, list archives end at February 2009. May be there are some other points of discuission about ACPI-CA? Bugzilla seems to work and I had applied for the account. Will see... > In any case the patch looks good. Thanks! So, I think that I will split the diff into ACPI-CA part and to the FreeBSD-specific part. I'll try to push the first one to the upstream and the second will wait for its inclusion and import. I foresee that this will last for some months. Perhaps once the patch will be accepted upstream it can be also integrated to the FreeBSD sources (and dropped with the next ACPI-CA import)? -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From swehack at gmail.com Tue May 26 14:14:11 2009 From: swehack at gmail.com (nocturnal) Date: Tue May 26 14:14:19 2009 Subject: MacBook, acpiconf sleep state shuts machine down Message-ID: <9aed80930905260648h41633265p1f69f4368a2c9b44@mail.gmail.com> I'm trying to get my MacBook with FreeBSD 7.2-RELEASE to at least suspend to RAM, even though hw.acpi.supported_sleep_state lists S3, S4 and S5. Though it doesn't matter which one i use, it will not wake back up from the sleep state. So far i've created a devd notify which runs a script that in turn runs acpiconf when the Lid is closed and sets state S3. When the script receives 0x01 it sets S1. I've tried with S3, S4 and S5 at 0x00 and it never wakes up, should i use something other than S1 for 0x01? It goes into some sort of sleep state, the apple light goes off and i hear a noise similar from my other macbooks with Darwin that indicates the HDD has turned off(I BELIEVE), it's basically the macbook-is-sleeping-sound again. ;D But when i then open the lid, it either shuts down and i have to turn it back on, or it gets stuck in sleep state and i have to do a cold shutdown and reboot it to get back into the system. How can i have acpi recognize the Lid is opened and do what it's being told even in sleep state? Is ACPI being disabled in sleep state? I've also set hw.acpi.disable_on_reboot="1" in loader.conf to hopefully make it stop this behaviour but it did not help. Also something i find weird or confusing is that sysctl has a value hw.acpi.power_button_state that is set to S5 and one hw.acpi.sleep_button_state set to S3. Also a hw.acpi.lid_switch_state set to NONE. hw.acpi.standby_state: S1 hw.acpi.suspend_state: S3 hw.acpi.s4bios: 0 hw.acpi.handle_reboot: 0 I would appreciate any other hints & tips from people who have experience with CPU states and ACPI on macbooks. -- Med v?nliga h?lsningar Stefan Midjich aka nocturnal [SWEHACK] http://swehack.se From vova at fbsd.ru Tue May 26 14:27:45 2009 From: vova at fbsd.ru (Vladimir Grebenschikov) Date: Tue May 26 14:27:57 2009 Subject: Any success with Lenovo T60 Message-ID: <1243346852.2384.62.camel@localhost> Hi Does anybody managed to make FreeBSD successfully suspend and resume on Lenovo T60 ? FreeBSD 8.0-CURRENT #0: Fri May 22 15:30:36 MSD 2009 root@vbook:/usr/obj/usr/src/sys/VBOOK Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz (1995.02-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6f6 Stepping = 6 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x20100000 AMD Features2=0x1 TSC: P-state invariant real memory = 2147483648 (2048 MB) avail memory = 2097184768 (2000 MB) ACPI APIC Table: ACPI Warning (tbfadt-0505): Optional field "Gpe1Block" has zero address or length: 0 102C/0 [20070320] ioapic0: Changing APIC ID to 1 ioapic0 irqs 0-23 on motherboard netsmb_dev: loaded kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi_ec0: port 0x62,0x66 on acpi0 acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 7ff00000 (3) failed I've tried but it does not resumes after sleep, so looking for hints. -- Vladimir B. Grebenschikov vova@fbsd.ru From avg at freebsd.org Tue May 26 16:07:29 2009 From: avg at freebsd.org (Andriy Gapon) Date: Tue May 26 16:07:34 2009 Subject: ACPICA version 20090521 released In-Reply-To: <200905211834.43324.jkim@FreeBSD.org> References: <4911F71203A09E4D9981D27F9D8308582E0E5016@orsmsx503.amr.corp.intel.com> <200905211834.43324.jkim@FreeBSD.org> Message-ID: <4A1C13BA.9040508@freebsd.org> on 22/05/2009 01:34 Jung-uk Kim said the following: > I just uploaded a new patchset against -CURRENT: > > http://people.freebsd.org/~jkim/acpica-import-20090521.diff.gz > > Please note that I am planning on merging it before 8.0 release. > Therefore, it needs more regression tests and serious code reviews > now. Just in case, here is an incremental diff from previous JK's import. Gonna start testing tomorrow. P.S. yes, git did it :-) -- Andriy Gapon From jkim at FreeBSD.org Tue May 26 16:35:00 2009 From: jkim at FreeBSD.org (Jung-uk Kim) Date: Tue May 26 16:35:07 2009 Subject: [rea-fbsd@codelabs.ru: Patch for "device_attach: estX attach returned 6" on half of the cores] In-Reply-To: References: Message-ID: <200905261234.42869.jkim@FreeBSD.org> On Tuesday 26 May 2009 05:54 am, Eygene Ryabinkin wrote: > Rui, good day. > > Tue, May 26, 2009 at 01:16:37AM +0100, Rui Paulo wrote: > > > If someone have ACPI tables with processor aliases -- the patch > > > can help > > > to attach est instances. I'd appreciate any testing and may be > > > some knowledgeable person can review this and help to commit > > > the patch. > > > > Regarding to the code in the patch, is this your code or > > something from a more recent ACPI-CA? > > It's mine ;)) Though I hadn't looked at the newer ACPI-CA yet. --- >8 --- SNIP!!! --- >8 --- As I posted earlier, it should be fixed in the newer ACPI-CA: http://docs.freebsd.org/cgi/mid.cgi?200905041551.19904.jkim Sorry, if you missed it. Jung-uk Kim From niktychina at gmail.com Tue May 26 20:43:54 2009 From: niktychina at gmail.com (Nikolay Tychina) Date: Tue May 26 20:44:01 2009 Subject: No brightness control on Acer laptop In-Reply-To: <4A19A095.5060802@mcss.hu> References: <4A05EA96.4090908@dzsy.org> <4A19131D.3050705@mcss.hu> <4A19A095.5060802@mcss.hu> Message-ID: There were few "Fixing your DSDT" threads on ubuntu forums and somewhere else. Unfortunately I don't understand this aml language too :-) You could try ACPI Specifications on http://acpi.info 2009/5/24 Sz?kv?lgyi P?ter > Nikolay Tychina wrote: > >> Did you try to fix your dsdt (it has only one error, mine has 7 :-) )? >> Also you can download original & fixed dsdt from >> http://acpi.sourceforge.net/dsdt/view.php?manufacturer=ACER >> and fix yours by analogy. >> >> Did you try http://code.google.com/p/acpi-amilo/ >> >> > I tested it, only change my wireless radio switch is default to off. > > From http://acpi.sourceforge.net/dsdt/view.php?manufacturer=ACER > i downloaded ACER Extensa 4002 and 4001 dsdt, i compile it and reboot > the brightness control works corectly, but i haven't battery monitor, > thermal > control, etc. I saw the original dsdt from "acpidump" and it has an error, > like > the dsdt from google source. > > I see the source, but this time i never programming in this language, so i > didn't know what is wrong. Anyone has a link or anything how can i learn? > > Thanks, > Peter > > From chuckop at gmail.com Tue May 26 21:00:21 2009 From: chuckop at gmail.com (Charles Oppermann) Date: Tue May 26 21:00:27 2009 Subject: Any success with Lenovo T60 In-Reply-To: <1243346852.2384.62.camel@localhost> References: <1243346852.2384.62.camel@localhost> Message-ID: <004601c9de41$81107630$83316290$@com> > Does anybody managed to make FreeBSD successfully suspend and resume on > Lenovo T60 ? Funny, because I was about to ask the same question regarding the T61p. I have heard that SMP prevents suspending entirely, but turning off the second CPU via BIOS doesn't help. I have been using acpiconf -s3 to test. Each time I get a console message saying that suspend event failed. Never does it suspend, nor does it seem to bother the current state. I can continue working normally. > ACPI APIC Table: > ACPI Warning (tbfadt-0505): Optional field "Gpe1Block" has zero address or > length: 0 102C/0 [20070320] > ioapic0: Changing APIC ID to 1 > ioapic0 irqs 0-23 on motherboard > netsmb_dev: loaded > kbd1 at kbdmux0 > acpi0: on motherboard > acpi0: [ITHREAD] > acpi_ec0: port 0x62,0x66 on acpi0 > acpi0: Power Button (fixed) > acpi0: reservation of 0, a0000 (3) failed > acpi0: reservation of 100000, 7ff00000 (3) failed I get the same ACPI warnings and "failed" as you. My acpi0 has though. I'd be happy to provide more information or do some spelunking if need be. From rea-fbsd at codelabs.ru Wed May 27 10:17:17 2009 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Wed May 27 10:17:24 2009 Subject: [rea-fbsd@codelabs.ru: Patch for "device_attach: estX attach returned 6" on half of the cores] In-Reply-To: <200905261234.42869.jkim@FreeBSD.org> References: <200905261234.42869.jkim@FreeBSD.org> Message-ID: <1Rc2f/mn4q/bRzg8uAsl4ZMkCeY@XX1fo6zQUfC4h0jjRC6IBz3oNH4> Jung-uk, good day. Tue, May 26, 2009 at 12:34:33PM -0400, Jung-uk Kim wrote: > On Tuesday 26 May 2009 05:54 am, Eygene Ryabinkin wrote: > > It's mine ;)) Though I hadn't looked at the newer ACPI-CA yet. > > --- >8 --- SNIP!!! --- >8 --- > > As I posted earlier, it should be fixed in the newer ACPI-CA: > > http://docs.freebsd.org/cgi/mid.cgi?200905041551.19904.jkim > > Sorry, if you missed it. Yes, missed it, thanks for the link! Having looked at the patch itself I have an impression that it will not solve the original problem: while ACPI-CA now correctly dereferences aliases found in the path (currently I am interested only Processor objects), but still, full walk will return both real nodes and their aliases. So for my case of dual-way machine with aliases to both processors, all four objects seem to be inserted to the ACPI namespace, so again, acpi_cpu will be attached twice to the first processor. But I want to be mistaken and will try your patch that imports the latest ACPI-CA for the -CURRENT. Will report on my findings. Thanks! -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From rpaulo at freebsd.org Wed May 27 11:24:16 2009 From: rpaulo at freebsd.org (Rui Paulo) Date: Wed May 27 11:24:22 2009 Subject: MacBook, acpiconf sleep state shuts machine down In-Reply-To: <9aed80930905260648h41633265p1f69f4368a2c9b44@mail.gmail.com> References: <9aed80930905260648h41633265p1f69f4368a2c9b44@mail.gmail.com> Message-ID: On 26 May 2009, at 14:48, nocturnal wrote: > I'm trying to get my MacBook with FreeBSD 7.2-RELEASE to at least > suspend to > RAM, even though hw.acpi.supported_sleep_state lists S3, S4 and S5. > > Though it doesn't matter which one i use, it will not wake back up > from the > sleep state. > > So far i've created a devd notify which runs a script that in turn > runs > acpiconf when the Lid is closed and sets state S3. When the script > receives > 0x01 it sets S1. > > I've tried with S3, S4 and S5 at 0x00 and it never wakes up, should > i use > something other than S1 for 0x01? > > It goes into some sort of sleep state, the apple light goes off and > i hear a > noise similar from my other macbooks with Darwin that indicates the > HDD has > turned off(I BELIEVE), it's basically the macbook-is-sleeping-sound > again. > ;D > > But when i then open the lid, it either shuts down and i have to > turn it > back on, or it gets stuck in sleep state and i have to do a cold > shutdown > and reboot it to get back into the system. > > How can i have acpi recognize the Lid is opened and do what it's > being told > even in sleep state? Is ACPI being disabled in sleep state? > > I've also set hw.acpi.disable_on_reboot="1" in loader.conf to > hopefully make > it stop this behaviour but it did not help. > > Also something i find weird or confusing is that sysctl has a value > hw.acpi.power_button_state that is set to S5 and one > hw.acpi.sleep_button_state set to S3. Also a > hw.acpi.lid_switch_state set to > NONE. > > hw.acpi.standby_state: S1 > hw.acpi.suspend_state: S3 > hw.acpi.s4bios: 0 > hw.acpi.handle_reboot: 0 > > I would appreciate any other hints & tips from people who have > experience > with CPU states and ACPI on macbooks. You may want to try a newer FreeBSD version that supports SMP suspend. Otherwise you need to disable SMP in loader.conf, 'kern.smp.disabled=1'. Either way, I haven't tested this for a long time so I don't know if it will work. -- Rui Paulo -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-acpi/attachments/20090527/88b24e9e/PGP.pgp From avg at icyb.net.ua Wed May 27 12:43:10 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Wed May 27 12:43:16 2009 Subject: ACPI Panic on Current, AMD64 In-Reply-To: References: <49159824-57EB-4628-9F1C-CE9243465D02@mukaibo.com> <7344382E-A415-463D-9138-D01E8499EDE8@mukaibo.com> Message-ID: <4A1D3484.9040201@icyb.net.ua> on 27/05/2009 14:11 Timothy Mukaibo said the following: > Hello Eygene, > > I know the patch won't fix anything :( > > Here's the updated dmesg: > > acpi0: on motherboard > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > acpi0: reservation of 0, a000 (3) failed > acpi0: reservation of 100000, bfdf0000 (3) failed > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 > acip_button0: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pci_link26: Index IRQ Rtd Ref IRQs > MPASS 0 20 N 1 20 21 22 23 > link type is 15 > panic: Assertion link->l_prs_template.Type == ACPI_RESOURCE_TYPE_IRQ > failed at /usr/src/sys/dev/acpica/acpi_pci_link.c:746 So resource type is ACPI_RESOURCE_TYPE_IRQ, but link type is ACPI_RESOURCE_TYPE_EXTENDED_IRQ. Interesting. -- Andriy Gapon From jhb at freebsd.org Wed May 27 21:25:58 2009 From: jhb at freebsd.org (John Baldwin) Date: Wed May 27 21:26:10 2009 Subject: ACPI Panic on Current, AMD64 In-Reply-To: <4A1D3484.9040201@icyb.net.ua> References: <49159824-57EB-4628-9F1C-CE9243465D02@mukaibo.com> <4A1D3484.9040201@icyb.net.ua> Message-ID: <200905271725.44235.jhb@freebsd.org> On Wednesday 27 May 2009 8:39:32 am Andriy Gapon wrote: > on 27/05/2009 14:11 Timothy Mukaibo said the following: > > Hello Eygene, > > > > I know the patch won't fix anything :( > > > > Here's the updated dmesg: > > > > acpi0: on motherboard > > acpi0: [ITHREAD] > > acpi0: Power Button (fixed) > > acpi0: reservation of 0, a000 (3) failed > > acpi0: reservation of 100000, bfdf0000 (3) failed > > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 > > acip_button0: on acpi0 > > pcib0: port 0xcf8-0xcff on acpi0 > > pci0: on pcib0 > > pci_link26: Index IRQ Rtd Ref IRQs > > MPASS 0 20 N 1 20 21 22 23 > > link type is 15 > > panic: Assertion link->l_prs_template.Type == ACPI_RESOURCE_TYPE_IRQ > > failed at /usr/src/sys/dev/acpica/acpi_pci_link.c:746 > > So resource type is ACPI_RESOURCE_TYPE_IRQ, but link type is > ACPI_RESOURCE_TYPE_EXTENDED_IRQ. Interesting. I think the _PRS returned one type and _CRS is returning another (or some such). I'm not sure what the "right" thing to do is in that case. Presumably this is while building the buffer for _SRS? Hmm, I guess you could just make it able to read the IRQ out of the _PRS no matter what format it is. But we might should be copying the resource that is in _PRS instead and building a new resource list instead of overwriting the fields in _CRS. That is a bit more involved. -- John Baldwin From tinkysama at mukaibo.com Thu May 28 07:26:11 2009 From: tinkysama at mukaibo.com (Timothy Mukaibo) Date: Thu May 28 07:26:17 2009 Subject: ACPI Panic on Current, AMD64 In-Reply-To: <200905271725.44235.jhb@freebsd.org> References: <49159824-57EB-4628-9F1C-CE9243465D02@mukaibo.com> <4A1D3484.9040201@icyb.net.ua> <200905271725.44235.jhb@freebsd.org> Message-ID: <849F0899-7AD9-4D7A-B849-D7FB36CE73AE@mukaibo.com> Hello guys, I'm not sure if I made this clear, but the board boots with 7.2- Stable. Have there been lots of ACPI changes between 7.2 and 8.0 that might have caused this regression? Kind regards, Timothy. On 28/05/2009, at 7:25 AM, John Baldwin wrote: > On Wednesday 27 May 2009 8:39:32 am Andriy Gapon wrote: >> on 27/05/2009 14:11 Timothy Mukaibo said the following: >>> Hello Eygene, >>> >>> I know the patch won't fix anything :( >>> >>> Here's the updated dmesg: >>> >>> acpi0: on motherboard >>> acpi0: [ITHREAD] >>> acpi0: Power Button (fixed) >>> acpi0: reservation of 0, a000 (3) failed >>> acpi0: reservation of 100000, bfdf0000 (3) failed >>> Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 >>> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on >>> acpi0 >>> acip_button0: on acpi0 >>> pcib0: port 0xcf8-0xcff on acpi0 >>> pci0: on pcib0 >>> pci_link26: Index IRQ Rtd Ref IRQs >>> MPASS 0 20 N 1 20 21 22 23 >>> link type is 15 >>> panic: Assertion link->l_prs_template.Type == ACPI_RESOURCE_TYPE_IRQ >>> failed at /usr/src/sys/dev/acpica/acpi_pci_link.c:746 >> >> So resource type is ACPI_RESOURCE_TYPE_IRQ, but link type is >> ACPI_RESOURCE_TYPE_EXTENDED_IRQ. Interesting. > > I think the _PRS returned one type and _CRS is returning another (or > some > such). I'm not sure what the "right" thing to do is in that case. > Presumably this is while building the buffer for _SRS? Hmm, I guess > you > could just make it able to read the IRQ out of the _PRS no matter > what format > it is. But we might should be copying the resource that is in _PRS > instead > and building a new resource list instead of overwriting the fields > in _CRS. > That is a bit more involved. > > -- > John Baldwin > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org > " From taku at tackymt.homeip.net Thu May 28 09:45:56 2009 From: taku at tackymt.homeip.net (YAMAMOTO, Taku) Date: Thu May 28 09:46:08 2009 Subject: Any success with Lenovo T60 In-Reply-To: <1243346852.2384.62.camel@localhost> References: <1243346852.2384.62.camel@localhost> Message-ID: <20090528184537.b2ac4798.taku@tackymt.homeip.net> Hi Vladimir, I have an X60 running 8.0-current/i386 as of Apr. 29, 2009 which can successfully suspend and resume, though things may be a bit different from your case. There were a couple of pitfalls which I ran into: 0. Pristine kernels for i386 SMP don't support the resume yet. We can either use amd64 ones, stick on i386 UP kernels or apply unofficial patch floating around. 1. DO NOT DISABLE the built-in modem! (It took almost 2 weeks to identify!) Disabling it ends up with hanging machine on resume. 2. Disable the USB while suspending; otherwise NMI parity error occurs on resume. (usb2 stack only; the old USB stack didn't have this problem) In rc.suspend (the magic to turn the root hubs off): usbconfig -a 1 set_config 255 In rc.resume (the magic to turn the root hubs on again): usbconfig -a 1 set_config 0 Cheers, -- -|-__ YAMAMOTO, Taku | __ < - A chicken is an egg's way of producing more eggs. - -------------- next part -------------- Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-CURRENT #181: Thu May 7 08:46:45 JST 2009 yamamoto@biotite:/home/yamamoto/work/build/biotite/usr/src/sys/BIOTITE Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz (1995.02-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6f6 Stepping = 6 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x20100000 AMD Features2=0x1 TSC: P-state invariant real memory = 1073741824 (1024 MB) avail memory = 1032323072 (984 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ACPI Warning (tbfadt-0505): Optional field "Gpe1Block" has zero address or length: 0 102C/0 [20070320] ioapic0: Changing APIC ID to 1 ioapic0 irqs 0-23 on motherboard no match for ZwOpenKey no match for IoOpenDeviceRegistryKey no match for ZwCreateKey no match for ZwDeleteKey acpi0: on motherboard acpi0: [ITHREAD] acpi_ec0: port 0x62,0x66 on acpi0 acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 3ff00000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 1100 acpi_lid0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0x1800-0x1807 mem 0xee100000-0xee17ffff,0xd0000000-0xdfffffff,0xee200000-0xee23ffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: detected 7932k stolen memory agp0: aperture size is 256M drm0: on vgapci0 vgapci0: child drm0 requested pci_enable_busmaster info: [drm] AGP at 0xd0000000 256MB info: [drm] Initialized i915 1.6.0 20080730 vgapci1: mem 0xee180000-0xee1fffff at device 2.1 on pci0 hdac0: mem 0xee240000-0xee243fff irq 17 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20090401_0132 hdac0: [ITHREAD] pcib1: irq 20 at device 28.0 on pci0 pci2: on pcib1 em0: port 0x2000-0x201f mem 0xee000000-0xee01ffff irq 16 at device 0.0 on pci2 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:16:d3:2f:f4:65 pcib2: irq 21 at device 28.1 on pci0 pci3: on pcib2 ndis0: <11a/b/g/n Wireless LAN Mini-PCI Express Adapter> mem 0xedf00000-0xedf0ffff irq 17 at device 0.0 on pci3 ndis0: [ITHREAD] ndis0: NDIS API version: 5.1 pcib3: irq 22 at device 28.2 on pci0 pci4: on pcib3 pcib4: irq 23 at device 28.3 on pci0 pci12: on pcib4 uhci0: port 0x1820-0x183f irq 16 at device 29.0 on pci0 uhci0: [ITHREAD] usbus0: on uhci0 uhci1: port 0x1840-0x185f irq 17 at device 29.1 on pci0 uhci1: [ITHREAD] usbus1: on uhci1 uhci2: port 0x1860-0x187f irq 18 at device 29.2 on pci0 uhci2: [ITHREAD] usbus2: on uhci2 uhci3: port 0x1880-0x189f irq 19 at device 29.3 on pci0 uhci3: [ITHREAD] usbus3: on uhci3 ehci0: mem 0xee444000-0xee4443ff irq 19 at device 29.7 on pci0 ehci0: [ITHREAD] usbus4: EHCI version 1.0 usbus4: on ehci0 pcib5: at device 30.0 on pci0 pci21: on pcib5 cbb0: mem 0xe4300000-0xe4300fff irq 16 at device 0.0 on pci21 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb0: [FILTER] pci21: at device 0.1 (no driver attached) sdhci0: mem 0xe4301800-0xe43018ff irq 18 at device 0.2 on pci21 sdhci0: 1 slot(s) allocated sdhci0: [ITHREAD] isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1810-0x181f at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] atapci1: port 0x18d0-0x18d7,0x18c4-0x18c7,0x18c8-0x18cf,0x18c0-0x18c3,0x18b0-0x18bf mem 0xee444400-0xee4447ff irq 16 at device 31.2 on pci0 atapci1: [ITHREAD] atapci1: AHCI called from vendor specific driver atapci1: AHCI Version 01.10 controller with 4 ports PM not supported ata2: on atapci1 ata2: [ITHREAD] ichsmb0: port 0x18e0-0x18ff irq 23 at device 31.3 on pci0 ichsmb0: [ITHREAD] smbus0: on ichsmb0 smb0: on smbus0 acpi_dock0: on acpi0 acpi_tz0: on acpi0 acpi_tz1: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model Generic PS/2 mouse, device ID 0 battery0: on acpi0 acpi_acad0: on acpi0 acpi_ibm0: on acpi0 cpu0: on acpi0 coretemp0: on cpu0 est0: on cpu0 cpu1: on acpi0 coretemp1: on cpu1 est1: on cpu1 pmtimer0 on isa0 orm0: at iomem 0xcf000-0xcffff,0xd0000-0xd0fff,0xdc000-0xdffff,0xe0000-0xeffff pnpid ORM0000 on isa0 sc0: on isa0 sc0: VGA <12 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 fb0 at vga0 Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 480Mbps High Speed USB v2.0 ad0: 114473MB at ata2-master SATA150 hdac0: HDA Codec #0: Analog Devices AD1981HD hdac0: HDA Codec #1: Conexant (Unknown) pcm0: at cad 0 nid 1 on hdac0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 SMP: AP CPU #1 Launched! Root mount waiting for: usbus4 usbus3 usbus2 usbus1 usbus0 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered Root mount waiting for: usbus4 Root mount waiting for: usbus4 Root mount waiting for: usbus4 uhub4: 8 ports with 8 removable, self powered Trying to mount root from ufs:/dev/ad0s1a ugen3.2: at usbus3 WARNING: TMPFS is considered to be a highly experimental feature in FreeBSD. From takawata at init-main.com Thu May 28 09:56:47 2009 From: takawata at init-main.com (Takanori Watanabe) Date: Thu May 28 09:56:54 2009 Subject: Any success with Lenovo T60 In-Reply-To: Your message of "Thu, 28 May 2009 18:45:37 JST." <20090528184537.b2ac4798.taku@tackymt.homeip.net> Message-ID: <200905280952.n4S9q8bS065093@sana.init-main.com> In message <20090528184537.b2ac4798.taku@tackymt.homeip.net>, "YAMAMOTO, Taku" wrote: >Hi Vladimir, > >I have an X60 running 8.0-current/i386 as of Apr. 29, 2009 >which can successfully suspend and resume, though things may be a bit >different from your case. > >There were a couple of pitfalls which I ran into: > > 0. Pristine kernels for i386 SMP don't support the resume yet. > We can either use amd64 ones, stick on i386 UP kernels or apply > unofficial patch floating around. > > 1. DO NOT DISABLE the built-in modem! (It took almost 2 weeks to identify!) > Disabling it ends up with hanging machine on resume. > > 2. Disable the USB while suspending; otherwise NMI parity error occurs > on resume. (usb2 stack only; the old USB stack didn't have this problem) > In rc.suspend (the magic to turn the root hubs off): > usbconfig -a 1 set_config 255 > In rc.resume (the magic to turn the root hubs on again): > usbconfig -a 1 set_config 0 > Is the SMP/i386 patch applied cleanly? Lazy author does not tried that since then. From taku at tackymt.homeip.net Thu May 28 10:13:17 2009 From: taku at tackymt.homeip.net (YAMAMOTO, Taku) Date: Thu May 28 10:13:32 2009 Subject: Any success with Lenovo T60 In-Reply-To: <200905280952.n4S9q8bS065093@sana.init-main.com> References: <20090528184537.b2ac4798.taku@tackymt.homeip.net> <200905280952.n4S9q8bS065093@sana.init-main.com> Message-ID: <20090528191311.b68ab3b7.taku@tackymt.homeip.net> On Thu, 28 May 2009 18:52:08 +0900 Takanori Watanabe wrote: > In message <20090528184537.b2ac4798.taku@tackymt.homeip.net>, "YAMAMOTO, Taku" > wrote: > >Hi Vladimir, > > > >I have an X60 running 8.0-current/i386 as of Apr. 29, 2009 > >which can successfully suspend and resume, though things may be a bit > >different from your case. > > > >There were a couple of pitfalls which I ran into: > > > > 0. Pristine kernels for i386 SMP don't support the resume yet. > > We can either use amd64 ones, stick on i386 UP kernels or apply > > unofficial patch floating around. > > > > 1. DO NOT DISABLE the built-in modem! (It took almost 2 weeks to identify!) > > Disabling it ends up with hanging machine on resume. > > > > 2. Disable the USB while suspending; otherwise NMI parity error occurs > > on resume. (usb2 stack only; the old USB stack didn't have this problem) > > In rc.suspend (the magic to turn the root hubs off): > > usbconfig -a 1 set_config 255 > > In rc.resume (the magic to turn the root hubs on again): > > usbconfig -a 1 set_config 0 > > > > Is the SMP/i386 patch applied cleanly? > Lazy author does not tried that since then. No, it requires slight modifications to apply, but that's it. Would it be worth to have it available somewhere? -- -|-__ YAMAMOTO, Taku | __ < - A chicken is an egg's way of producing more eggs. - From takawata at init-main.com Thu May 28 10:27:18 2009 From: takawata at init-main.com (Takanori Watanabe) Date: Thu May 28 10:27:25 2009 Subject: Any success with Lenovo T60 In-Reply-To: Your message of "Thu, 28 May 2009 19:13:11 JST." <20090528191311.b68ab3b7.taku@tackymt.homeip.net> Message-ID: <200905281022.n4SAMdxr065296@sana.init-main.com> In message <20090528191311.b68ab3b7.taku@tackymt.homeip.net>, "YAMAMOTO, Taku" wrote: >On Thu, 28 May 2009 18:52:08 +0900 >Takanori Watanabe wrote: > >> In message <20090528184537.b2ac4798.taku@tackymt.homeip.net>, "YAMAMOTO, Tak >u" >> wrote: >> >Hi Vladimir, >> > >> >I have an X60 running 8.0-current/i386 as of Apr. 29, 2009 >> >which can successfully suspend and resume, though things may be a bit >> >different from your case. >> > >> >There were a couple of pitfalls which I ran into: >> > >> > 0. Pristine kernels for i386 SMP don't support the resume yet. >> > We can either use amd64 ones, stick on i386 UP kernels or apply >> > unofficial patch floating around. >> > >> > 1. DO NOT DISABLE the built-in modem! (It took almost 2 weeks to identify! >) >> > Disabling it ends up with hanging machine on resume. >> > >> > 2. Disable the USB while suspending; otherwise NMI parity error occurs >> > on resume. (usb2 stack only; the old USB stack didn't have this problem >) >> > In rc.suspend (the magic to turn the root hubs off): >> > usbconfig -a 1 set_config 255 >> > In rc.resume (the magic to turn the root hubs on again): >> > usbconfig -a 1 set_config 0 >> > >> >> Is the SMP/i386 patch applied cleanly? >> Lazy author does not tried that since then. > >No, it requires slight modifications to apply, but that's it. >Would it be worth to have it available somewhere? Yes, please. I want to review it. From taku at tackymt.homeip.net Thu May 28 11:18:53 2009 From: taku at tackymt.homeip.net (YAMAMOTO, Taku) Date: Thu May 28 11:19:05 2009 Subject: Any success with Lenovo T60 In-Reply-To: <200905281022.n4SAMdxr065296@sana.init-main.com> References: <20090528191311.b68ab3b7.taku@tackymt.homeip.net> <200905281022.n4SAMdxr065296@sana.init-main.com> Message-ID: <20090528201844.7df2e164.taku@tackymt.homeip.net> I'll attach the patch in a Triaez fashion :) though I don't think this is the way to go. # We need to implement suspend_cpus() for i386 and utilize it. On Thu, 28 May 2009 19:22:39 +0900 Takanori Watanabe wrote: > In message <20090528191311.b68ab3b7.taku@tackymt.homeip.net>, "YAMAMOTO, Taku" > wrote: > >On Thu, 28 May 2009 18:52:08 +0900 > >Takanori Watanabe wrote: > > > >> In message <20090528184537.b2ac4798.taku@tackymt.homeip.net>, "YAMAMOTO, Tak > >u" > >> wrote: > >> >Hi Vladimir, > >> > > >> >I have an X60 running 8.0-current/i386 as of Apr. 29, 2009 > >> >which can successfully suspend and resume, though things may be a bit > >> >different from your case. > >> > > >> >There were a couple of pitfalls which I ran into: > >> > > >> > 0. Pristine kernels for i386 SMP don't support the resume yet. > >> > We can either use amd64 ones, stick on i386 UP kernels or apply > >> > unofficial patch floating around. > >> > > >> > 1. DO NOT DISABLE the built-in modem! (It took almost 2 weeks to identify! > >) > >> > Disabling it ends up with hanging machine on resume. > >> > > >> > 2. Disable the USB while suspending; otherwise NMI parity error occurs > >> > on resume. (usb2 stack only; the old USB stack didn't have this problem > >) > >> > In rc.suspend (the magic to turn the root hubs off): > >> > usbconfig -a 1 set_config 255 > >> > In rc.resume (the magic to turn the root hubs on again): > >> > usbconfig -a 1 set_config 0 > >> > > >> > >> Is the SMP/i386 patch applied cleanly? > >> Lazy author does not tried that since then. > > > >No, it requires slight modifications to apply, but that's it. > >Would it be worth to have it available somewhere? > > Yes, please. I want to review it. -- -|-__ YAMAMOTO, Taku | __ < - A chicken is an egg's way of producing more eggs. - From jhb at freebsd.org Thu May 28 13:53:06 2009 From: jhb at freebsd.org (John Baldwin) Date: Thu May 28 13:53:18 2009 Subject: ACPI Panic on Current, AMD64 In-Reply-To: <849F0899-7AD9-4D7A-B849-D7FB36CE73AE@mukaibo.com> References: <49159824-57EB-4628-9F1C-CE9243465D02@mukaibo.com> <200905271725.44235.jhb@freebsd.org> <849F0899-7AD9-4D7A-B849-D7FB36CE73AE@mukaibo.com> Message-ID: <200905280800.24867.jhb@freebsd.org> On Thursday 28 May 2009 2:59:16 am Timothy Mukaibo wrote: > Hello guys, > > I'm not sure if I made this clear, but the board boots with 7.2- > Stable. Have there been lots of ACPI changes between 7.2 and 8.0 that > might have caused this regression? No, and the ACPI pci_link code has in fact not changed since 7.0 aside from a few minor fixes for suspend/resume that do not affect boot (and those were merged into 7.1). I do wonder if perhaps there have been any changes in the ACPI-CA code. Hmm, ACPI-CA is identical in the two versions. All of the resource code is identical as well. -- John Baldwin From avg at icyb.net.ua Thu May 28 14:10:02 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Thu May 28 14:10:17 2009 Subject: ACPI Panic on Current, AMD64 In-Reply-To: <200905280800.24867.jhb@freebsd.org> References: <49159824-57EB-4628-9F1C-CE9243465D02@mukaibo.com> <200905271725.44235.jhb@freebsd.org> <849F0899-7AD9-4D7A-B849-D7FB36CE73AE@mukaibo.com> <200905280800.24867.jhb@freebsd.org> Message-ID: <4A1E9B34.3040202@icyb.net.ua> on 28/05/2009 15:00 John Baldwin said the following: > On Thursday 28 May 2009 2:59:16 am Timothy Mukaibo wrote: >> Hello guys, >> >> I'm not sure if I made this clear, but the board boots with 7.2- >> Stable. Have there been lots of ACPI changes between 7.2 and 8.0 that >> might have caused this regression? > > No, and the ACPI pci_link code has in fact not changed since 7.0 aside from a > few minor fixes for suspend/resume that do not affect boot (and those were > merged into 7.1). I do wonder if perhaps there have been any changes in the > ACPI-CA code. Hmm, ACPI-CA is identical in the two versions. All of the > resource code is identical as well. Timothy, could you please check if you have any possibly related hints/tweaks in device.hints or loader.conf in both environments? Could you please provide 7.2 verbose dmesg? (Sorry, if you already did and I missed that) -- Andriy Gapon From avg at icyb.net.ua Thu May 28 14:57:45 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Thu May 28 14:58:12 2009 Subject: ACPI Panic on Current, AMD64 In-Reply-To: <4911F71203A09E4D9981D27F9D8308582E3194B4@orsmsx503.amr.corp.intel.com> References: <49159824-57EB-4628-9F1C-CE9243465D02@mukaibo.com> <200905271725.44235.jhb@freebsd.org> <849F0899-7AD9-4D7A-B849-D7FB36CE73AE@mukaibo.com> <200905280800.24867.jhb@freebsd.org> <4911F71203A09E4D9981D27F9D8308582E3194B4@orsmsx503.amr.corp.intel.com> Message-ID: <4A1EA65C.1020307@icyb.net.ua> on 28/05/2009 17:47 Moore, Robert said the following: > This problem sounds familiar. In ACPICA, we found an issue where the _CRS > returns an extended IRQ descriptor, but it gets optimized to an IRQNoFlags > descriptor before the template is sent to _SRS. This causes problems on some > machines. We fixed this and actually made a clarification to the ACPI > specification that the _SRS template buffer must contain identical descriptors > as returned from the _CRS template. This change was made in ACPICA version > 20080213. BZ 9487 is the Linux sighting. FreeBSD head and stable/7 seem to be still at 20070320. Timothy, you might want to try Jung-uk's patch: http://people.freebsd.org/~jkim/acpica-import-20090521.diff.gz > 13 February 2008. Summary of changes for version 20080213: > > Fixed a problem where resource descriptor size optimization could cause a > problem when a _CRS resource template is passed to a _SRS method. The _SRS > resource template must use the same descriptors (with the same size) as > returned from _CRS. This change affects the following resource descriptors: IRQ > / IRQNoFlags and StartDependendentFn / StartDependentFnNoPri. (BZ 9487) > > >> -----Original Message----- From: owner-freebsd-acpi@freebsd.org >> [mailto:owner-freebsd- acpi@freebsd.org] On Behalf Of John Baldwin Sent: >> Thursday, May 28, 2009 5:00 AM To: Timothy Mukaibo Cc: >> freebsd-acpi@freebsd.org; freebsd-current@freebsd.org; Andriy Gapon Subject: >> Re: ACPI Panic on Current, AMD64 >> >> On Thursday 28 May 2009 2:59:16 am Timothy Mukaibo wrote: >>> Hello guys, >>> >>> I'm not sure if I made this clear, but the board boots with 7.2- Stable. >>> Have there been lots of ACPI changes between 7.2 and 8.0 that might have >>> caused this regression? >> No, and the ACPI pci_link code has in fact not changed since 7.0 aside from a >> few minor fixes for suspend/resume that do not affect boot (and those were >> merged into 7.1). I do wonder if perhaps there have been any changes in the >> ACPI-CA code. Hmm, ACPI-CA is identical in the two versions. All of the >> resource code is identical as well. >> >> -- John Baldwin _______________________________________________ >> freebsd-acpi@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send >> any mail to "freebsd-acpi-unsubscribe@freebsd.org" -- Andriy Gapon From robert.moore at intel.com Thu May 28 14:58:05 2009 From: robert.moore at intel.com (Moore, Robert) Date: Thu May 28 14:58:12 2009 Subject: ACPI Panic on Current, AMD64 In-Reply-To: <200905280800.24867.jhb@freebsd.org> References: <49159824-57EB-4628-9F1C-CE9243465D02@mukaibo.com> <200905271725.44235.jhb@freebsd.org> <849F0899-7AD9-4D7A-B849-D7FB36CE73AE@mukaibo.com> <200905280800.24867.jhb@freebsd.org> Message-ID: <4911F71203A09E4D9981D27F9D8308582E3194B4@orsmsx503.amr.corp.intel.com> This problem sounds familiar. In ACPICA, we found an issue where the _CRS returns an extended IRQ descriptor, but it gets optimized to an IRQNoFlags descriptor before the template is sent to _SRS. This causes problems on some machines. We fixed this and actually made a clarification to the ACPI specification that the _SRS template buffer must contain identical descriptors as returned from the _CRS template. This change was made in ACPICA version 20080213. BZ 9487 is the Linux sighting. 13 February 2008. Summary of changes for version 20080213: Fixed a problem where resource descriptor size optimization could cause a problem when a _CRS resource template is passed to a _SRS method. The _SRS resource template must use the same descriptors (with the same size) as returned from _CRS. This change affects the following resource descriptors: IRQ / IRQNoFlags and StartDependendentFn / StartDependentFnNoPri. (BZ 9487) >-----Original Message----- >From: owner-freebsd-acpi@freebsd.org [mailto:owner-freebsd- >acpi@freebsd.org] On Behalf Of John Baldwin >Sent: Thursday, May 28, 2009 5:00 AM >To: Timothy Mukaibo >Cc: freebsd-acpi@freebsd.org; freebsd-current@freebsd.org; Andriy Gapon >Subject: Re: ACPI Panic on Current, AMD64 > >On Thursday 28 May 2009 2:59:16 am Timothy Mukaibo wrote: >> Hello guys, >> >> I'm not sure if I made this clear, but the board boots with 7.2- >> Stable. Have there been lots of ACPI changes between 7.2 and 8.0 that >> might have caused this regression? > >No, and the ACPI pci_link code has in fact not changed since 7.0 aside from >a >few minor fixes for suspend/resume that do not affect boot (and those were >merged into 7.1). I do wonder if perhaps there have been any changes in >the >ACPI-CA code. Hmm, ACPI-CA is identical in the two versions. All of the >resource code is identical as well. > >-- >John Baldwin >_______________________________________________ >freebsd-acpi@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-acpi >To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" From oberman at es.net Fri May 29 03:42:06 2009 From: oberman at es.net (Kevin Oberman) Date: Fri May 29 03:42:12 2009 Subject: Any success with Lenovo T60 In-Reply-To: Your message of "Thu, 28 May 2009 18:45:37 +0900." <20090528184537.b2ac4798.taku@tackymt.homeip.net> Message-ID: <20090529034156.BBDA51CC09@ptavv.es.net> > Date: Thu, 28 May 2009 18:45:37 +0900 > From: "YAMAMOTO, Taku" > Sender: owner-freebsd-mobile@freebsd.org > > Hi Vladimir, > > I have an X60 running 8.0-current/i386 as of Apr. 29, 2009 > which can successfully suspend and resume, though things may be a bit > different from your case. > > There were a couple of pitfalls which I ran into: > > 0. Pristine kernels for i386 SMP don't support the resume yet. > We can either use amd64 ones, stick on i386 UP kernels or apply > unofficial patch floating around. > > 1. DO NOT DISABLE the built-in modem! (It took almost 2 weeks to identify!) > Disabling it ends up with hanging machine on resume. Do you mean in BIOS? I've been fighting with resume issues on my T43 and I suspect that this may be at least a part of the problem. Thanks! -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From Juergen.Dankoweit at t-online.de Fri May 29 05:23:31 2009 From: Juergen.Dankoweit at t-online.de (=?ISO-8859-15?Q?J=FCrgen_Dankoweit?=) Date: Fri May 29 05:23:38 2009 Subject: Any success with Lenovo T60 In-Reply-To: <20090529034156.BBDA51CC09@ptavv.es.net> References: <20090529034156.BBDA51CC09@ptavv.es.net> Message-ID: <4A1F6DAF.1080108@FreeBSD-Onkel.de> Hello Kevin, Kevin Oberman schrieb: >> Date: Thu, 28 May 2009 18:45:37 +0900 >> From: "YAMAMOTO, Taku" >> Sender: owner-freebsd-mobile@freebsd.org >> >> Hi Vladimir, >> >> I have an X60 running 8.0-current/i386 as of Apr. 29, 2009 >> which can successfully suspend and resume, though things may be a bit >> different from your case. >> >> There were a couple of pitfalls which I ran into: >> >> 0. Pristine kernels for i386 SMP don't support the resume yet. >> We can either use amd64 ones, stick on i386 UP kernels or apply >> unofficial patch floating around. >> >> 1. DO NOT DISABLE the built-in modem! (It took almost 2 weeks to identify!) >> Disabling it ends up with hanging machine on resume. > > Do you mean in BIOS? > > I've been fighting with resume issues on my T43 and I suspect that this > may be at least a part of the problem. > > Thanks! with my T43 I had similar problems. After disabling APIC (not ACPI!) everything works perfect. Also look here: http://www.thinkwiki.org/wiki/Installing_FreeBSD_7_on_a_ThinkPad_T43 Best regards Juergen From avg at freebsd.org Fri May 29 12:51:31 2009 From: avg at freebsd.org (Andriy Gapon) Date: Fri May 29 12:51:37 2009 Subject: ACPICA version 20090521 released In-Reply-To: <4A1C13BA.9040508@freebsd.org> References: <4911F71203A09E4D9981D27F9D8308582E0E5016@orsmsx503.amr.corp.intel.com> <200905211834.43324.jkim@FreeBSD.org> <4A1C13BA.9040508@freebsd.org> Message-ID: <4A1FDA4E.6030506@freebsd.org> on 26/05/2009 19:07 Andriy Gapon said the following: > on 22/05/2009 01:34 Jung-uk Kim said the following: >> I just uploaded a new patchset against -CURRENT: >> >> http://people.freebsd.org/~jkim/acpica-import-20090521.diff.gz >> >> Please note that I am planning on merging it before 8.0 release. >> Therefore, it needs more regression tests and serious code reviews >> now. > > Just in case, here is an incremental diff from previous JK's import. > Gonna start testing tomorrow. Testing on two systems hasn't shown any regressions - one is based 440BX/PIIX4, the other is amd64 based on ICH9R. -- Andriy Gapon From tinkysama at mukaibo.com Sat May 30 00:44:30 2009 From: tinkysama at mukaibo.com (Timothy Mukaibo) Date: Sat May 30 00:44:37 2009 Subject: ACPI Panic on Current, AMD64 In-Reply-To: <4A1E9B34.3040202@icyb.net.ua> References: <49159824-57EB-4628-9F1C-CE9243465D02@mukaibo.com> <200905271725.44235.jhb@freebsd.org> <849F0899-7AD9-4D7A-B849-D7FB36CE73AE@mukaibo.com> <200905280800.24867.jhb@freebsd.org> <4A1E9B34.3040202@icyb.net.ua> Message-ID: <2492E55D-5C36-4A93-BB69-B1539AAB0087@mukaibo.com> Hello Andriy, timothy@tinkysama:~$ cat /boot/loader.conf snd_hda_load="YES" uscanner_load="YES" Here's the dmesg: Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.2-STABLE #1: Fri May 15 13:03:42 EST 2009 root@tinkysama.local:/usr/obj/usr/src/sys/GENERIC module_register: module uhub/uscanner already exists! Module uhub/uscanner failed to register: 17 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4600+ (2410.99-MHz K8- class CPU) Origin = "AuthenticAMD" Id = 0x40fb2 Stepping = 2 Features = 0x178bfbff < FPU ,VME ,DE ,PSE ,TSC ,MSR ,PAE ,MCE ,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT> Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x1f Cores per package: 2 usable memory = 3206512640 (3057 MB) avail memory = 3093467136 (2950 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, bfdf0000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 0.0 (no driver attached) pci0: at device 0.1 (no driver attached) pci0: at device 0.2 (no driver attached) pci0: at device 0.3 (no driver attached) pci0: at device 0.4 (no driver attached) pci0: at device 0.5 (no driver attached) pci0: at device 0.6 (no driver attached) pci0: at device 0.7 (no driver attached) pcib1: at device 4.0 on pci0 pci1: on pcib1 vgapci0: mem 0xdc000000-0xdcffffff, 0xc0000000-0xcfffffff,0xdd000000-0xddffffff irq 16 at device 0.0 on pci1 pci0: at device 8.0 (no driver attached) isab0: port 0xfc00-0xfc7f at device 9.0 on pci0 isa0: on isab0 pci0: at device 9.1 (no driver attached) pci0: at device 9.2 (no driver attached) ohci0: mem 0xdffff000-0xdfffffff irq 20 at device 10.0 on pci0 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 10 ports with 10 removable, self powered ehci0: mem 0xdfffe000-0xdfffe0ff irq 21 at device 10.1 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb1: EHCI version 1.0 usb1: companion controller, 10 ports each: usb0 usb1: on ehci0 usb1: USB revision 2.0 uhub1: on usb1 uhub1: 10 ports with 10 removable, self powered atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf000-0xf00f at device 12.0 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] atapci1: port 0x9f0-0x9f7,0xbf0-0xbf3,0x970-0x977,0xb70-0xb73,0xdc00-0xdc0f mem 0xdfffd000-0xdfffdfff irq 22 at device 13.0 on pci0 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] atapci2: port 0x9e0-0x9e7,0xbe0-0xbe3,0x960-0x967,0xb60-0xb63,0xc800-0xc80f mem 0xdfffc000-0xdfffcfff irq 23 at device 13.1 on pci0 atapci2: [ITHREAD] ata4: on atapci2 ata4: [ITHREAD] ata5: on atapci2 ata5: [ITHREAD] atapci3: port 0xc400-0xc407,0xc000-0xc003,0xbc00-0xbc07,0xb800-0xb803,0xb400-0xb40f mem 0xdfffb000-0xdfffbfff irq 20 at device 13.2 on pci0 atapci3: [ITHREAD] ata6: on atapci3 ata6: [ITHREAD] ata7: on atapci3 ata7: [ITHREAD] pcib2: at device 14.0 on pci0 pci2: on pcib2 fwohci0: mem 0xdfeff000-0xdfeff7ff, 0xdfef8000-0xdfefbfff irq 16 at device 8.0 on pci2 fwohci0: [FILTER] fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:27:c3:2f:00:01:6c:20 fwohci0: invalid speed 7 (fixed to 3). fwohci0: Phy 1394a available S800, 3 ports. fwohci0: Link S800, max_rec 4096 bytes. firewire0: on fwohci0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x1378000 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:27:c3:01:6c:20 fwe0: Ethernet address: 02:27:c3:01:6c:20 fwip0: on firewire0 fwip0: Firewire address: 00:27:c3:2f:00:01:6c:20 @ 0xfffe00000000, S800, maxrec 4096 sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode nfe0: port 0xb000-0xb007 mem 0xdfffa000-0xdfffafff,0xdfff9000-0xdfff90ff,0xdfff8000-0xdfff800f irq 21 at device 16.0 on pci0 miibus0: on nfe0 e1000phy0: PHY 2 on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX- FDX, auto nfe0: Ethernet address: 00:15:58:a3:c8:af nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe1: port 0xac00-0xac07 mem 0xdfff7000-0xdfff7fff,0xdfff6000-0xdfff60ff,0xdfff5000-0xdfff500f irq 22 at device 17.0 on pci0 miibus1: on nfe1 e1000phy1: PHY 3 on miibus1 e1000phy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX- FDX, auto nfe1: Ethernet address: 00:15:58:a3:c8:ae nfe1: [FILTER] nfe1: [FILTER] nfe1: [FILTER] nfe1: [FILTER] nfe1: [FILTER] nfe1: [FILTER] nfe1: [FILTER] nfe1: [FILTER] pcib3: at device 18.0 on pci0 pci3: on pcib3 pcib4: at device 22.0 on pci0 pci4: on pcib4 pcib5: at device 23.0 on pci0 pci5: on pcib5 acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] cpu0: on acpi0 powernow0: on cpu0 cpu1: on acpi0 powernow1: on cpu1 orm0: at iomem 0xd0000-0xd17ff on isa0 ppc0: cannot reserve I/O port range sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 or not responding sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) fwohci0: phy int acd0: DMA limited to UDMA33, device found non-ATA66 cable acd0: DVDR at ata0-master UDMA33 ad12: 76318MB at ata6-master SATA300 SMP: AP CPU #1 Launched! GEOM_LABEL: Label for provider ad12s1a is ufsid/49de0d6bb6139848. GEOM_LABEL: Label for provider ad12s1d is ufsid/49de0d6ccdde671f. GEOM_LABEL: Label for provider ad12s1e is ufsid/49de0d6c2bc3b43f. GEOM_LABEL: Label for provider ad12s1f is ufsid/49de0d6c47a9b5cc. Trying to mount root from ufs:/dev/ad12s1a GEOM_LABEL: Label ufsid/49de0d6bb6139848 removed. GEOM_LABEL: Label for provider ad12s1a is ufsid/49de0d6bb6139848. GEOM_LABEL: Label ufsid/49de0d6c2bc3b43f removed. GEOM_LABEL: Label for provider ad12s1e is ufsid/49de0d6c2bc3b43f. GEOM_LABEL: Label ufsid/49de0d6c47a9b5cc removed. GEOM_LABEL: Label for provider ad12s1f is ufsid/49de0d6c47a9b5cc. GEOM_LABEL: Label ufsid/49de0d6ccdde671f removed. GEOM_LABEL: Label for provider ad12s1d is ufsid/49de0d6ccdde671f. GEOM_LABEL: Label ufsid/49de0d6bb6139848 removed. GEOM_LABEL: Label ufsid/49de0d6c2bc3b43f removed. GEOM_LABEL: Label ufsid/49de0d6c47a9b5cc removed. GEOM_LABEL: Label ufsid/49de0d6ccdde671f removed. This module (opensolaris) contains code covered by the Common Development and Distribution License (CDDL) see http://opensolaris.org/os/licensing/opensolaris_license/ WARNING: ZFS is considered to be an experimental feature in FreeBSD. ZFS filesystem version 6 ZFS storage pool version 6 nfe0: link state changed to UP fuse4bsd: version 0.3.9-pre1, FUSE ABI 7.8 On 29/05/2009, at 12:09 AM, Andriy Gapon wrote: > on 28/05/2009 15:00 John Baldwin said the following: >> On Thursday 28 May 2009 2:59:16 am Timothy Mukaibo wrote: >>> Hello guys, >>> >>> I'm not sure if I made this clear, but the board boots with 7.2- >>> Stable. Have there been lots of ACPI changes between 7.2 and 8.0 >>> that >>> might have caused this regression? >> >> No, and the ACPI pci_link code has in fact not changed since 7.0 >> aside from a >> few minor fixes for suspend/resume that do not affect boot (and >> those were >> merged into 7.1). I do wonder if perhaps there have been any >> changes in the >> ACPI-CA code. Hmm, ACPI-CA is identical in the two versions. All >> of the >> resource code is identical as well. > > > Timothy, > > could you please check if you have any possibly related hints/tweaks > in > device.hints or loader.conf in both environments? > Could you please provide 7.2 verbose dmesg? (Sorry, if you already > did and I > missed that) > > -- > Andriy Gapon > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org > " From linimon at FreeBSD.org Sat May 30 10:38:01 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sat May 30 10:38:07 2009 Subject: kern/135070: [acpi] [patch] BIOS resource allocation and FreeBSD ACPI Message-ID: <200905301038.n4UAc0Gt007223@freefall.freebsd.org> Old Synopsis: [acpi] BIOS resource allocation and FreeBSD ACPI New Synopsis: [acpi] [patch] BIOS resource allocation and FreeBSD ACPI Responsible-Changed-From-To: freebsd-bugs->freebsd-acpi Responsible-Changed-By: linimon Responsible-Changed-When: Sat May 30 10:37:36 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=135070