From owner-freebsd-acpi@FreeBSD.ORG Mon Sep 8 02:22:16 2008 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D4DB1065678 for ; Mon, 8 Sep 2008 02:22:16 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 1AF078FC12 for ; Mon, 8 Sep 2008 02:22:16 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m882MFPJ006588 for ; Mon, 8 Sep 2008 02:22:15 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m882MF0K006584 for freebsd-acpi@FreeBSD.org; Mon, 8 Sep 2008 02:22:15 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 8 Sep 2008 02:22:15 GMT Message-Id: <200809080222.m882MF0K006584@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-acpi@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-acpi@FreeBSD.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2008 02:22:16 -0000 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/124744 acpi [acpi] [patch] incorrect _BST result validation for To o kern/124412 acpi [acpi] power off error on Toshiba M40 laptop o kern/124223 acpi [acpi] [patch] acpi_battery.c -- Notify user-defined c 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/120953 acpi [acpi]: FreeBSD 6.3 Release: acpi_tz0: _TMP value is 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/108581 acpi [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argume 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 o 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 f kern/67309 acpi zzz reboot computer (ACPI S3) 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 42 problems total. Bugs can be in one of several states: o - open A problem report has been submitted, no sanity checking performed. a - analyzed The problem is understood and a solution is being sought. f - feedback Further work requires additional information from the originator or the community - possibly confirmation of the effectiveness of a proposed solution. p - patched A patch has been committed, but some issues (MFC and / or confirmation from originator) are still open. r - repocopy The resolution of the problem report is dependent on a repocopy operation within the CVS repository which is awaiting completion. s - suspended The problem is not being worked on, due to lack of information or resources. This is a prime candidate for somebody who is looking for a project to do. If the problem cannot be solved at all, it will be closed, rather than suspended. c - closed A problem report is closed when any changes have been integrated, documented, and tested -- or when fixing the problem is abandoned. From owner-freebsd-acpi@FreeBSD.ORG Mon Sep 8 20:12:04 2008 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A17D1065671 for ; Mon, 8 Sep 2008 20:12:04 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id D28E78FC16 for ; Mon, 8 Sep 2008 20:12:03 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from zion.baldwin.cx (zion.baldwin.cx [IPv6:2001:470:1f11:75:2a0:d2ff:fe18:8b38]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m88KBvuD095950; Mon, 8 Sep 2008 16:11:57 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-acpi@freebsd.org, lists@peter.de.com Date: Mon, 8 Sep 2008 11:08:49 -0400 User-Agent: KMail/1.9.7 References: <20080901141216.72601dfb@dilbert.office.centralnic.com> In-Reply-To: <20080901141216.72601dfb@dilbert.office.centralnic.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809081108.50135.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:2001:470:1f11:75::1]); Mon, 08 Sep 2008 16:11:57 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8162/Thu Sep 4 12:38:45 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.3 required=4.2 tests=AWL,BAYES_00, DATE_IN_PAST_03_06,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Subject: Re: kernel: interrupt storm detected on "irq22:"; throttling interrupt source [7.0-RELEASE] X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2008 20:12:04 -0000 On Monday 01 September 2008 09:12:16 am Oliver Peter wrote: > Hi, > > For about 6 weeks I'm suffering an interrupt storm on my production > machine which is running 7.0-RELEASE-p3/amd64. > > The kernel is flooding my syslog with the following messages[1]. > A full dmesg can be found here[2]. > > As discribed in "Using and Debugging FreeBSD ACPI" I already tried > to disable apic during boot time but that's a bad idea because it > seems that the SATA2 onboard controller has to have apic loaded - > please correct me if I'm wrong. > > /boot/loader.conf: > hint.apic.0.disabled="1" > > Doesn't work for me. > > Btw. I think it's worth it to have a little note in that part of > the documentation which says something about possible failures > during the boot time. > > Thanks for any suggestions. There are two possible causes of an interrupt storm: 1) some device is actually using IRQ 22 but FreeBSD thinks it is using something else. This doesn't happen very often as it is generally a bug in the BIOS and one of the tables it generates. This used to happen more often in older versions of FreeBSD that had bugs or limitations in the code that figured out which IRQ PCI devices used. 2) There is a bug in the driver for one of the devices on IRQ 22. In this case the only device you have on IRQ is atapci0, so it may be a bug in the ata(4) driver, possibly. You could check to see if the interrupt handler for the Linux driver for your chipset has extra logic (currently ata(4) doesn't have any chipset-specific logic for interrupt handlers AFAIK). Also, you could try examining the interrupt status register of your controller when you are getting storms to see if there is a condition set that isn't being cleared by ata's interrupt handler. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Mon Sep 8 21:44:00 2008 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA4C81065671; Mon, 8 Sep 2008 21:44:00 +0000 (UTC) (envelope-from gahr@FreeBSD.org) Received: from cpanel03.rubas-s03.net (cpanel03.rubas-s03.net [195.182.222.73]) by mx1.freebsd.org (Postfix) with ESMTP id 60DC58FC1A; Mon, 8 Sep 2008 21:44:00 +0000 (UTC) (envelope-from gahr@FreeBSD.org) Received: from [213.142.183.219] (helo=gahrtop.localhost) by cpanel03.rubas-s03.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1KcoWd-0005xa-EP; Mon, 08 Sep 2008 23:43:59 +0200 Message-ID: <48C59C98.5020408@FreeBSD.org> Date: Mon, 08 Sep 2008 23:43:52 +0200 From: Pietro Cerutti Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.16 (X11/20080807) MIME-Version: 1.0 To: Nate Lawson References: <48C14091.4060309@FreeBSD.org> <48C16810.2030003@root.org> In-Reply-To: <48C16810.2030003@root.org> X-Enigmail-Version: 0.95.6 OpenPGP: id=9571F78E; url=http://gahr.ch/pgp/ Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cpanel03.rubas-s03.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - FreeBSD.org X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-acpi@FreeBSD.org, bug-followup@FreeBSD.org Subject: Re: kern/124223: [acpi] [patch] acpi_battery.c -- Notify user-defined critical level via devd(8) X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2008 21:44:00 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Nate Lawson wrote: | There are a few problems with your approach. | | Critical status is already reported with a flag when usermode polls for | the battery status: |> if (sc->bst.state & ACPI_BATT_STAT_CRITICAL) { |> if ((sc->flags & ACPI_BATT_STAT_CRITICAL) == 0) { |> sc->flags |= ACPI_BATT_STAT_CRITICAL; |> device_printf(dev, "critically low charge!\n"); |> } |> } I agree. Critical level is already checked for in the cmbat module. However, reporting is not done in a "standardized" way. My patch would just like to add notification through devd. | Since usermode utilities already poll, they can handle that flag or | implement their own notion of critical battery level. Why introduce a | new kernel thread to do that same polling? Because you can't configure the notion of "critical level" via cmbat. | | Don't common battery status tools that poll (say, xbatt) have their own | way to set a critical level? xbatt uses APM and ioctl to get the status of the battery. I agree that userlevel utilities can e.g., retrieve the remaining percent and set the critical level arbitrarily, but I anyway think that a configurable level to be seen as critical by the OS could be a useful addition. I'm open to discussions about the best way to implement it (cmbat, battery, ...?), if we get to an agreement that this could be a useful feature :) Otherwise feel free to close the PR, as I can accept your arguments. | | -Nate | | Pietro Cerutti wrote: |> POKE! |> |> Anybody interested in reviewing it? | - -- Pietro Cerutti gahr@FreeBSD.org PGP Public Key: http://gahr.ch/pgp -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEAREKAAYFAkjFnJcACgkQwMJqmJVx946mtgCgivQVqG6nrctsffXFdm5HRQfX 1OUAoL9TXYwwiNfHvnUclKAhVzWcnw9S =3q5J -----END PGP SIGNATURE----- From owner-freebsd-acpi@FreeBSD.ORG Mon Sep 8 21:50:03 2008 Return-Path: Delivered-To: freebsd-acpi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D279C1065670 for ; Mon, 8 Sep 2008 21:50:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C35F98FC08 for ; Mon, 8 Sep 2008 21:50:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m88Lo3EI050948 for ; Mon, 8 Sep 2008 21:50:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m88Lo3Ma050947; Mon, 8 Sep 2008 21:50:03 GMT (envelope-from gnats) Date: Mon, 8 Sep 2008 21:50:03 GMT Message-Id: <200809082150.m88Lo3Ma050947@freefall.freebsd.org> To: freebsd-acpi@FreeBSD.org From: Pietro Cerutti Cc: Subject: Re: kern/124223: [acpi] [patch] acpi_battery.c -- Notify user-defined critical level via devd(8) X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Pietro Cerutti List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2008 21:50:03 -0000 The following reply was made to PR kern/124223; it has been noted by GNATS. From: Pietro Cerutti To: Nate Lawson Cc: bug-followup@FreeBSD.org, freebsd-acpi@FreeBSD.org Subject: Re: kern/124223: [acpi] [patch] acpi_battery.c -- Notify user-defined critical level via devd(8) Date: Mon, 08 Sep 2008 23:43:52 +0200 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Nate Lawson wrote: | There are a few problems with your approach. | | Critical status is already reported with a flag when usermode polls for | the battery status: |> if (sc->bst.state & ACPI_BATT_STAT_CRITICAL) { |> if ((sc->flags & ACPI_BATT_STAT_CRITICAL) == 0) { |> sc->flags |= ACPI_BATT_STAT_CRITICAL; |> device_printf(dev, "critically low charge!\n"); |> } |> } I agree. Critical level is already checked for in the cmbat module. However, reporting is not done in a "standardized" way. My patch would just like to add notification through devd. | Since usermode utilities already poll, they can handle that flag or | implement their own notion of critical battery level. Why introduce a | new kernel thread to do that same polling? Because you can't configure the notion of "critical level" via cmbat. | | Don't common battery status tools that poll (say, xbatt) have their own | way to set a critical level? xbatt uses APM and ioctl to get the status of the battery. I agree that userlevel utilities can e.g., retrieve the remaining percent and set the critical level arbitrarily, but I anyway think that a configurable level to be seen as critical by the OS could be a useful addition. I'm open to discussions about the best way to implement it (cmbat, battery, ...?), if we get to an agreement that this could be a useful feature :) Otherwise feel free to close the PR, as I can accept your arguments. | | -Nate | | Pietro Cerutti wrote: |> POKE! |> |> Anybody interested in reviewing it? | - -- Pietro Cerutti gahr@FreeBSD.org PGP Public Key: http://gahr.ch/pgp -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEAREKAAYFAkjFnJcACgkQwMJqmJVx946mtgCgivQVqG6nrctsffXFdm5HRQfX 1OUAoL9TXYwwiNfHvnUclKAhVzWcnw9S =3q5J -----END PGP SIGNATURE----- From owner-freebsd-acpi@FreeBSD.ORG Mon Sep 8 22:04:04 2008 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EFFA9106566B; Mon, 8 Sep 2008 22:04:04 +0000 (UTC) (envelope-from nate@root.org) Received: from nlpi087.prodigy.net (nlpi087.prodigy.net [207.115.36.103]) by mx1.freebsd.org (Postfix) with ESMTP id C382C8FC16; Mon, 8 Sep 2008 22:04:04 +0000 (UTC) (envelope-from nate@root.org) X-ORBL: [71.139.8.213] Received: from [10.0.5.18] (ppp-71-139-8-213.dsl.snfc21.pacbell.net [71.139.8.213]) by nlpi087.prodigy.net (8.13.8 out.dk.spool/8.13.8) with ESMTP id m88M42T0001757; Mon, 8 Sep 2008 17:04:03 -0500 Message-ID: <48C5A152.9020505@root.org> Date: Mon, 08 Sep 2008 15:04:02 -0700 From: Nate Lawson User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Pietro Cerutti References: <48C14091.4060309@FreeBSD.org> <48C16810.2030003@root.org> <48C59C98.5020408@FreeBSD.org> In-Reply-To: <48C59C98.5020408@FreeBSD.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, bug-followup@FreeBSD.org Subject: Re: kern/124223: [acpi] [patch] acpi_battery.c -- Notify user-defined critical level via devd(8) X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2008 22:04:05 -0000 Pietro Cerutti wrote: > Nate Lawson wrote: > | There are a few problems with your approach. > | > | Critical status is already reported with a flag when usermode polls for > | the battery status: > |> if (sc->bst.state & ACPI_BATT_STAT_CRITICAL) { > |> if ((sc->flags & ACPI_BATT_STAT_CRITICAL) == 0) { > |> sc->flags |= ACPI_BATT_STAT_CRITICAL; > |> device_printf(dev, "critically low charge!\n"); > |> } > |> } > > I agree. Critical level is already checked for in the cmbat module. > However, reporting is not done in a "standardized" way. My patch would > just like to add notification through devd. But it doesn't just add notification through devd. It adds a thread, that separately polls for battery state and sends a notify through devd. If the user is running any battery app, there's a double poll for the same info. I subscribe to the design approach that where it makes sense to do something in usermode, don't do it in kernel mode. In this case, the IO interface is poll-only, and any user app that is running can set its own policy for how to deal with the information it gets from polling. > I agree that userlevel utilities can e.g., retrieve the remaining > percent and set the critical level arbitrarily, but I anyway think that > a configurable level to be seen as critical by the OS could be a useful > addition. > > I'm open to discussions about the best way to implement it (cmbat, > battery, ...?), if we get to an agreement that this could be a useful > feature :) Otherwise feel free to close the PR, as I can accept your > arguments. I think it would be better to work with the third-party apps to support configurable levels. In xbatt: /* If battery life is short, ring a bell */ if ((life != APM_STAT_UNKNOWN) && (life < 5) && ((life % 5) == 0)) { ... and ... /* set gage color */ if (displayType == Color) { if (life < 3) { gage_color = "red"; } else if (life < 5) { gage_color = "yellow"; } } These thresholds could easily be a command-line var or X resource. Let's keep this in usermode, where policy belongs. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Mon Sep 8 22:10:07 2008 Return-Path: Delivered-To: freebsd-acpi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8ABD2106566B for ; Mon, 8 Sep 2008 22:10:07 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7B8F48FC08 for ; Mon, 8 Sep 2008 22:10:07 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m88MA7Fj051641 for ; Mon, 8 Sep 2008 22:10:07 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m88MA7DZ051637; Mon, 8 Sep 2008 22:10:07 GMT (envelope-from gnats) Date: Mon, 8 Sep 2008 22:10:07 GMT Message-Id: <200809082210.m88MA7DZ051637@freefall.freebsd.org> To: freebsd-acpi@FreeBSD.org From: Nate Lawson Cc: Subject: Re: kern/124223: [acpi] [patch] acpi_battery.c -- Notify user-defined critical level via devd(8) X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Nate Lawson List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2008 22:10:07 -0000 The following reply was made to PR kern/124223; it has been noted by GNATS. From: Nate Lawson To: Pietro Cerutti Cc: bug-followup@FreeBSD.org, freebsd-acpi@FreeBSD.org Subject: Re: kern/124223: [acpi] [patch] acpi_battery.c -- Notify user-defined critical level via devd(8) Date: Mon, 08 Sep 2008 15:04:02 -0700 Pietro Cerutti wrote: > Nate Lawson wrote: > | There are a few problems with your approach. > | > | Critical status is already reported with a flag when usermode polls for > | the battery status: > |> if (sc->bst.state & ACPI_BATT_STAT_CRITICAL) { > |> if ((sc->flags & ACPI_BATT_STAT_CRITICAL) == 0) { > |> sc->flags |= ACPI_BATT_STAT_CRITICAL; > |> device_printf(dev, "critically low charge!\n"); > |> } > |> } > > I agree. Critical level is already checked for in the cmbat module. > However, reporting is not done in a "standardized" way. My patch would > just like to add notification through devd. But it doesn't just add notification through devd. It adds a thread, that separately polls for battery state and sends a notify through devd. If the user is running any battery app, there's a double poll for the same info. I subscribe to the design approach that where it makes sense to do something in usermode, don't do it in kernel mode. In this case, the IO interface is poll-only, and any user app that is running can set its own policy for how to deal with the information it gets from polling. > I agree that userlevel utilities can e.g., retrieve the remaining > percent and set the critical level arbitrarily, but I anyway think that > a configurable level to be seen as critical by the OS could be a useful > addition. > > I'm open to discussions about the best way to implement it (cmbat, > battery, ...?), if we get to an agreement that this could be a useful > feature :) Otherwise feel free to close the PR, as I can accept your > arguments. I think it would be better to work with the third-party apps to support configurable levels. In xbatt: /* If battery life is short, ring a bell */ if ((life != APM_STAT_UNKNOWN) && (life < 5) && ((life % 5) == 0)) { ... and ... /* set gage color */ if (displayType == Color) { if (life < 3) { gage_color = "red"; } else if (life < 5) { gage_color = "yellow"; } } These thresholds could easily be a command-line var or X resource. Let's keep this in usermode, where policy belongs. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Mon Sep 8 22:14:23 2008 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9252D1065673; Mon, 8 Sep 2008 22:14:23 +0000 (UTC) (envelope-from gahr@FreeBSD.org) Received: from cpanel03.rubas-s03.net (cpanel03.rubas-s03.net [195.182.222.73]) by mx1.freebsd.org (Postfix) with ESMTP id 27AC88FC1C; Mon, 8 Sep 2008 22:14:22 +0000 (UTC) (envelope-from gahr@FreeBSD.org) Received: from [213.142.183.219] (helo=gahrtop.localhost) by cpanel03.rubas-s03.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Kcp01-0001oN-9a; Tue, 09 Sep 2008 00:14:21 +0200 Message-ID: <48C5A3B6.2070807@FreeBSD.org> Date: Tue, 09 Sep 2008 00:14:14 +0200 From: Pietro Cerutti Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.16 (X11/20080807) MIME-Version: 1.0 To: Nate Lawson References: <48C14091.4060309@FreeBSD.org> <48C16810.2030003@root.org> <48C59C98.5020408@FreeBSD.org> <48C5A152.9020505@root.org> In-Reply-To: <48C5A152.9020505@root.org> X-Enigmail-Version: 0.95.6 OpenPGP: id=9571F78E; url=http://gahr.ch/pgp/ Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cpanel03.rubas-s03.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - FreeBSD.org X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-acpi@FreeBSD.org, bug-followup@FreeBSD.org Subject: Re: kern/124223: [acpi] [patch] acpi_battery.c -- Notify user-defined critical level via devd(8) X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2008 22:14:23 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Nate Lawson wrote: | Pietro Cerutti wrote: |> Nate Lawson wrote: |> | There are a few problems with your approach. |> | |> | Critical status is already reported with a flag when usermode polls for |> | the battery status: |> |> if (sc->bst.state & ACPI_BATT_STAT_CRITICAL) { |> |> if ((sc->flags & ACPI_BATT_STAT_CRITICAL) == 0) { |> |> sc->flags |= ACPI_BATT_STAT_CRITICAL; |> |> device_printf(dev, "critically low charge!\n"); |> |> } |> |> } |> |> I agree. Critical level is already checked for in the cmbat module. |> However, reporting is not done in a "standardized" way. My patch would |> just like to add notification through devd. | | But it doesn't just add notification through devd. It adds a thread, | that separately polls for battery state and sends a notify through devd. | If the user is running any battery app, there's a double poll for the | same info. | | I subscribe to the design approach that where it makes sense to do | something in usermode, don't do it in kernel mode. In this case, the IO | interface is poll-only, and any user app that is running can set its own | policy for how to deal with the information it gets from polling. [snip xbatt-related stuff] | Let's keep this in usermode, where policy belongs. That's fine. Thanks for reviewing that! Best, - -- Pietro Cerutti gahr@FreeBSD.org PGP Public Key: http://gahr.ch/pgp -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEAREKAAYFAkjFo7UACgkQwMJqmJVx945TJQCfTRuG0ZiMSfyIaw0rb/5C1cXY E4oAoJdERo/AA7KwGRtYnVEQeUoPo9Az =UAwz -----END PGP SIGNATURE----- From owner-freebsd-acpi@FreeBSD.ORG Mon Sep 8 22:15:01 2008 Return-Path: Delivered-To: freebsd-acpi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44306106567A; Mon, 8 Sep 2008 22:15:01 +0000 (UTC) (envelope-from gahr@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 1D1568FC19; Mon, 8 Sep 2008 22:15:01 +0000 (UTC) (envelope-from gahr@FreeBSD.org) Received: from freefall.freebsd.org (gahr@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m88MF0R1053274; Mon, 8 Sep 2008 22:15:00 GMT (envelope-from gahr@freefall.freebsd.org) Received: (from gahr@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m88MF0AS053269; Mon, 8 Sep 2008 22:15:00 GMT (envelope-from gahr) Date: Mon, 8 Sep 2008 22:15:00 GMT Message-Id: <200809082215.m88MF0AS053269@freefall.freebsd.org> To: gahr@FreeBSD.org, gahr@FreeBSD.org, freebsd-acpi@FreeBSD.org From: gahr@FreeBSD.org Cc: Subject: Re: kern/124223: [acpi] [patch] acpi_battery.c -- Notify user-defined critical level via devd(8) X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2008 22:15:01 -0000 Synopsis: [acpi] [patch] acpi_battery.c -- Notify user-defined critical level via devd(8) State-Changed-From-To: open->closed State-Changed-By: gahr State-Changed-When: Mon Sep 8 22:15:00 UTC 2008 State-Changed-Why: Policy belongs to usermode. http://www.freebsd.org/cgi/query-pr.cgi?pr=124223 From owner-freebsd-acpi@FreeBSD.ORG Mon Sep 8 22:20:04 2008 Return-Path: Delivered-To: freebsd-acpi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA9C01065675 for ; Mon, 8 Sep 2008 22:20:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id DB4328FC17 for ; Mon, 8 Sep 2008 22:20:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m88MK4Ap053460 for ; Mon, 8 Sep 2008 22:20:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m88MK4TA053459; Mon, 8 Sep 2008 22:20:04 GMT (envelope-from gnats) Date: Mon, 8 Sep 2008 22:20:04 GMT Message-Id: <200809082220.m88MK4TA053459@freefall.freebsd.org> To: freebsd-acpi@FreeBSD.org From: Pietro Cerutti Cc: Subject: Re: kern/124223: [acpi] [patch] acpi_battery.c -- Notify user-defined critical level via devd(8) X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Pietro Cerutti List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2008 22:20:05 -0000 The following reply was made to PR kern/124223; it has been noted by GNATS. From: Pietro Cerutti To: Nate Lawson Cc: bug-followup@FreeBSD.org, freebsd-acpi@FreeBSD.org Subject: Re: kern/124223: [acpi] [patch] acpi_battery.c -- Notify user-defined critical level via devd(8) Date: Tue, 09 Sep 2008 00:14:14 +0200 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Nate Lawson wrote: | Pietro Cerutti wrote: |> Nate Lawson wrote: |> | There are a few problems with your approach. |> | |> | Critical status is already reported with a flag when usermode polls for |> | the battery status: |> |> if (sc->bst.state & ACPI_BATT_STAT_CRITICAL) { |> |> if ((sc->flags & ACPI_BATT_STAT_CRITICAL) == 0) { |> |> sc->flags |= ACPI_BATT_STAT_CRITICAL; |> |> device_printf(dev, "critically low charge!\n"); |> |> } |> |> } |> |> I agree. Critical level is already checked for in the cmbat module. |> However, reporting is not done in a "standardized" way. My patch would |> just like to add notification through devd. | | But it doesn't just add notification through devd. It adds a thread, | that separately polls for battery state and sends a notify through devd. | If the user is running any battery app, there's a double poll for the | same info. | | I subscribe to the design approach that where it makes sense to do | something in usermode, don't do it in kernel mode. In this case, the IO | interface is poll-only, and any user app that is running can set its own | policy for how to deal with the information it gets from polling. [snip xbatt-related stuff] | Let's keep this in usermode, where policy belongs. That's fine. Thanks for reviewing that! Best, - -- Pietro Cerutti gahr@FreeBSD.org PGP Public Key: http://gahr.ch/pgp -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEAREKAAYFAkjFo7UACgkQwMJqmJVx945TJQCfTRuG0ZiMSfyIaw0rb/5C1cXY E4oAoJdERo/AA7KwGRtYnVEQeUoPo9Az =UAwz -----END PGP SIGNATURE----- From owner-freebsd-acpi@FreeBSD.ORG Mon Sep 8 22:32:02 2008 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E2C61065674; Mon, 8 Sep 2008 22:32:02 +0000 (UTC) (envelope-from nate@root.org) Received: from nlpi101.prodigy.net (nlpi101.prodigy.net [207.115.36.117]) by mx1.freebsd.org (Postfix) with ESMTP id 38CB28FC14; Mon, 8 Sep 2008 22:32:02 +0000 (UTC) (envelope-from nate@root.org) X-ORBL: [71.139.8.213] Received: from [10.0.5.18] (ppp-71-139-8-213.dsl.snfc21.pacbell.net [71.139.8.213]) by nlpi101.prodigy.net (8.13.8 out.dk.spool/8.13.8) with ESMTP id m88MW0Ce011103; Mon, 8 Sep 2008 17:32:01 -0500 Message-ID: <48C5A7E0.3010308@root.org> Date: Mon, 08 Sep 2008 15:32:00 -0700 From: Nate Lawson User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Pietro Cerutti References: <48C14091.4060309@FreeBSD.org> <48C16810.2030003@root.org> <48C59C98.5020408@FreeBSD.org> <48C5A152.9020505@root.org> <48C5A3B6.2070807@FreeBSD.org> In-Reply-To: <48C5A3B6.2070807@FreeBSD.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org Subject: Re: kern/124223: [acpi] [patch] acpi_battery.c -- Notify user-defined critical level via devd(8) X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2008 22:32:02 -0000 Pietro Cerutti wrote: > Nate Lawson wrote: > | Pietro Cerutti wrote: > |> Nate Lawson wrote: > |> | There are a few problems with your approach. > |> | > |> | Critical status is already reported with a flag when usermode polls > for > |> | the battery status: > |> |> if (sc->bst.state & ACPI_BATT_STAT_CRITICAL) { > |> |> if ((sc->flags & ACPI_BATT_STAT_CRITICAL) == 0) { > |> |> sc->flags |= ACPI_BATT_STAT_CRITICAL; > |> |> device_printf(dev, "critically low charge!\n"); > |> |> } > |> |> } > |> > |> I agree. Critical level is already checked for in the cmbat module. > |> However, reporting is not done in a "standardized" way. My patch would > |> just like to add notification through devd. > | > | But it doesn't just add notification through devd. It adds a thread, > | that separately polls for battery state and sends a notify through devd. > | If the user is running any battery app, there's a double poll for the > | same info. > | > | I subscribe to the design approach that where it makes sense to do > | something in usermode, don't do it in kernel mode. In this case, the IO > | interface is poll-only, and any user app that is running can set its own > | policy for how to deal with the information it gets from polling. > > [snip xbatt-related stuff] > > | Let's keep this in usermode, where policy belongs. > > That's fine. Thanks for reviewing that! Thanks for helping with FreeBSD. Hope you'll work on other stuff in the future. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Mon Sep 8 22:34:04 2008 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31D66106568C for ; Mon, 8 Sep 2008 22:34:04 +0000 (UTC) (envelope-from gahr@FreeBSD.org) Received: from cpanel03.rubas-s03.net (cpanel03.rubas-s03.net [195.182.222.73]) by mx1.freebsd.org (Postfix) with ESMTP id BB8938FC16 for ; Mon, 8 Sep 2008 22:34:03 +0000 (UTC) (envelope-from gahr@FreeBSD.org) Received: from [213.142.183.219] (helo=gahrtop.localhost) by cpanel03.rubas-s03.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1KcpJ4-0004i6-2s; Tue, 09 Sep 2008 00:34:02 +0200 Message-ID: <48C5A852.4040909@FreeBSD.org> Date: Tue, 09 Sep 2008 00:33:54 +0200 From: Pietro Cerutti Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.16 (X11/20080807) MIME-Version: 1.0 To: Nate Lawson References: <48C14091.4060309@FreeBSD.org> <48C16810.2030003@root.org> <48C59C98.5020408@FreeBSD.org> <48C5A152.9020505@root.org> <48C5A3B6.2070807@FreeBSD.org> <48C5A7E0.3010308@root.org> In-Reply-To: <48C5A7E0.3010308@root.org> X-Enigmail-Version: 0.95.6 OpenPGP: id=9571F78E; url=http://gahr.ch/pgp/ Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cpanel03.rubas-s03.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - FreeBSD.org X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-acpi@FreeBSD.org Subject: Re: kern/124223: [acpi] [patch] acpi_battery.c -- Notify user-defined critical level via devd(8) X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2008 22:34:04 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Nate Lawson wrote: | Pietro Cerutti wrote: |> Nate Lawson wrote: |> | Pietro Cerutti wrote: |> |> Nate Lawson wrote: |> |> | There are a few problems with your approach. |> |> | |> |> | Critical status is already reported with a flag when usermode polls |> for |> |> | the battery status: |> |> |> if (sc->bst.state & ACPI_BATT_STAT_CRITICAL) { |> |> |> if ((sc->flags & ACPI_BATT_STAT_CRITICAL) == 0) { |> |> |> sc->flags |= ACPI_BATT_STAT_CRITICAL; |> |> |> device_printf(dev, "critically low charge!\n"); |> |> |> } |> |> |> } |> |> |> |> I agree. Critical level is already checked for in the cmbat module. |> |> However, reporting is not done in a "standardized" way. My patch would |> |> just like to add notification through devd. |> | |> | But it doesn't just add notification through devd. It adds a thread, |> | that separately polls for battery state and sends a notify through devd. |> | If the user is running any battery app, there's a double poll for the |> | same info. |> | |> | I subscribe to the design approach that where it makes sense to do |> | something in usermode, don't do it in kernel mode. In this case, the IO |> | interface is poll-only, and any user app that is running can set its own |> | policy for how to deal with the information it gets from polling. |> |> [snip xbatt-related stuff] |> |> | Let's keep this in usermode, where policy belongs. |> |> That's fine. Thanks for reviewing that! | | Thanks for helping with FreeBSD. Hope you'll work on other stuff in the | future. Stay assured :) - -- Pietro Cerutti gahr@FreeBSD.org PGP Public Key: http://gahr.ch/pgp -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEAREKAAYFAkjFqFEACgkQwMJqmJVx946SqgCgrmDAjzwZcRURJmspEu5178xt 4aAAoNi+PRH6adhJf3QpllLGXwfPEDzD =y/OG -----END PGP SIGNATURE----- From owner-freebsd-acpi@FreeBSD.ORG Mon Sep 8 23:08:19 2008 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E419C1065670 for ; Mon, 8 Sep 2008 23:08:19 +0000 (UTC) (envelope-from lists@peter.de.com) Received: from nemesis.charlie.mouhaha.de (nemesis.charlie.mouhaha.de [78.47.10.193]) by mx1.freebsd.org (Postfix) with ESMTP id 734F08FC12 for ; Mon, 8 Sep 2008 23:08:19 +0000 (UTC) (envelope-from lists@peter.de.com) Received: from localhost (nemesis.charlie.mouhaha.de [78.47.10.193]) by nemesis.charlie.mouhaha.de (Postfix) with ESMTP id 4FA4D46AE9 for ; Tue, 9 Sep 2008 00:08:18 +0100 (BST) X-Virus-Scanned: amavisd-new at mouhaha.de Received: from nemesis.charlie.mouhaha.de ([78.47.10.193]) by localhost (nemesis.charlie.mouhaha.de [78.47.10.193]) (amavisd-new, port 10024) with ESMTP id 0kI8oqEE580p for ; Tue, 9 Sep 2008 00:08:14 +0100 (BST) Received: from nemesis.charlie.mouhaha.de (nemesis.charlie.mouhaha.de [78.47.10.193]) by nemesis.charlie.mouhaha.de (Postfix) with SMTP id A9BDA46AA9 for ; Tue, 9 Sep 2008 00:08:14 +0100 (BST) Received: from delorean.geonosis.homeunix.org (host81-138-8-148.in-addr.btopenworld.com [81.138.8.148]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by nemesis.charlie.mouhaha.de (Postfix) with ESMTPSA id 8E5F346AA5; Tue, 9 Sep 2008 00:08:12 +0100 (BST) Date: Tue, 9 Sep 2008 00:08:05 +0100 From: Oliver Peter To: John Baldwin Message-ID: <20080909000805.5dc4407c@delorean.geonosis.homeunix.org> In-Reply-To: <200809081108.50135.jhb@freebsd.org> References: <20080901141216.72601dfb@dilbert.office.centralnic.com> <200809081108.50135.jhb@freebsd.org> Organization: mouhaha X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; amd64-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: kernel: interrupt storm detected on "irq22:"; throttling interrupt source [7.0-RELEASE] X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lists@peter.de.com List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2008 23:08:20 -0000 Hi John, Thanks for your reply. On Mon, 8 Sep 2008 11:08:49 -0400 John Baldwin wrote: > On Monday 01 September 2008 09:12:16 am Oliver Peter wrote: > > Hi, > > > > For about 6 weeks I'm suffering an interrupt storm on my production > > machine which is running 7.0-RELEASE-p3/amd64. > > > > The kernel is flooding my syslog with the following messages[1]. > > A full dmesg can be found here[2]. > > > > As discribed in "Using and Debugging FreeBSD ACPI" I already tried > > to disable apic during boot time but that's a bad idea because it > > seems that the SATA2 onboard controller has to have apic loaded - > > please correct me if I'm wrong. > > > > /boot/loader.conf: > > hint.apic.0.disabled="1" > > > > Doesn't work for me. > > > > Btw. I think it's worth it to have a little note in that part of > > the documentation which says something about possible failures > > during the boot time. > > > > Thanks for any suggestions. > > There are two possible causes of an interrupt storm: 1) some device > is actually using IRQ 22 but FreeBSD thinks it is using something > else. This doesn't happen very often as it is generally a bug in the > BIOS and one of the tables it generates. This used to happen more > often in older versions of FreeBSD that had bugs or limitations in > the code that figured out which IRQ PCI devices used. How can I find out exactly which device is using IRQ 22? Maybe I can disable it - i.e. USB is not needed at all. > 2) There is a > bug in the driver for one of the devices on IRQ 22. In this case the > only device you have on IRQ is atapci0, so it may be a bug in the > ata(4) driver, possibly. You could check to see if the interrupt > handler for the Linux driver for your chipset has extra logic > (currently ata(4) doesn't have any chipset-specific logic for > interrupt handlers AFAIK). Also, you could try examining the > interrupt status register of your controller when you are getting > storms to see if there is a condition set that isn't being cleared by > ata's interrupt handler. ... of course I could do that - but could you please be so kind and explain how to do that? :-) Cheers, O. -- Oliver PETER, email: oliver@peter.de.com, ICQ# 113969174 "If it feels good, you're doing something wrong." -- Coach McTavish From owner-freebsd-acpi@FreeBSD.ORG Tue Sep 9 07:54:22 2008 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A40531065684; Tue, 9 Sep 2008 07:54:22 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail12.syd.optusnet.com.au (mail12.syd.optusnet.com.au [211.29.132.193]) by mx1.freebsd.org (Postfix) with ESMTP id 1F0A18FC15; Tue, 9 Sep 2008 07:54:21 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c122-106-215-175.belrs3.nsw.optusnet.com.au [122.106.215.175]) by mail12.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m897sHF0011525 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Sep 2008 17:54:17 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.2/8.14.2) with ESMTP id m897sGwc060164; Tue, 9 Sep 2008 17:54:16 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.2/8.14.2/Submit) id m897sGdU060163; Tue, 9 Sep 2008 17:54:16 +1000 (EST) (envelope-from peter) Date: Tue, 9 Sep 2008 17:54:16 +1000 From: Peter Jeremy To: John Baldwin Message-ID: <20080909075416.GF15376@server.vk2pj.dyndns.org> References: <20080901141216.72601dfb@dilbert.office.centralnic.com> <200809081108.50135.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="I4g3zIzscEHdx6fd" Content-Disposition: inline In-Reply-To: <200809081108.50135.jhb@freebsd.org> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-acpi@freebsd.org Subject: Re: kernel: interrupt storm detected on "irq22:"; throttling interrupt source [7.0-RELEASE] X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2008 07:54:22 -0000 --I4g3zIzscEHdx6fd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2008-Sep-08 11:08:49 -0400, John Baldwin wrote: >There are two possible causes of an interrupt storm: There is a third possible option (I have cards that do this): The device is generating interrupts without being told to do so. --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --I4g3zIzscEHdx6fd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkjGK6gACgkQ/opHv/APuIfACQCeP+dvA83vg6s3ijLGHGzebLxd 4BIAoIogdSpRnOR/aj4BhR2tSgr4XK1b =HOLV -----END PGP SIGNATURE----- --I4g3zIzscEHdx6fd-- From owner-freebsd-acpi@FreeBSD.ORG Tue Sep 9 21:04:32 2008 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 554E81065670 for ; Tue, 9 Sep 2008 21:04:32 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id E09C48FC1A for ; Tue, 9 Sep 2008 21:04:31 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m89L4CIg008827; Tue, 9 Sep 2008 17:04:25 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: lists@peter.de.com Date: Tue, 9 Sep 2008 14:24:16 -0400 User-Agent: KMail/1.9.7 References: <20080901141216.72601dfb@dilbert.office.centralnic.com> <200809081108.50135.jhb@freebsd.org> <20080909000805.5dc4407c@delorean.geonosis.homeunix.org> In-Reply-To: <20080909000805.5dc4407c@delorean.geonosis.homeunix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809091424.16302.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Tue, 09 Sep 2008 17:04:25 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8162/Thu Sep 4 12:38:45 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-acpi@freebsd.org Subject: Re: kernel: interrupt storm detected on "irq22:"; throttling interrupt source [7.0-RELEASE] X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2008 21:04:32 -0000 On Monday 08 September 2008 07:08:05 pm Oliver Peter wrote: > Hi John, > > Thanks for your reply. > > On Mon, 8 Sep 2008 11:08:49 -0400 > John Baldwin wrote: > > > On Monday 01 September 2008 09:12:16 am Oliver Peter wrote: > > > Hi, > > > > > > For about 6 weeks I'm suffering an interrupt storm on my production > > > machine which is running 7.0-RELEASE-p3/amd64. > > > > > > The kernel is flooding my syslog with the following messages[1]. > > > A full dmesg can be found here[2]. > > > > > > As discribed in "Using and Debugging FreeBSD ACPI" I already tried > > > to disable apic during boot time but that's a bad idea because it > > > seems that the SATA2 onboard controller has to have apic loaded - > > > please correct me if I'm wrong. > > > > > > /boot/loader.conf: > > > hint.apic.0.disabled="1" > > > > > > Doesn't work for me. > > > > > > Btw. I think it's worth it to have a little note in that part of > > > the documentation which says something about possible failures > > > during the boot time. > > > > > > Thanks for any suggestions. > > > > There are two possible causes of an interrupt storm: 1) some device > > is actually using IRQ 22 but FreeBSD thinks it is using something > > else. This doesn't happen very often as it is generally a bug in the > > BIOS and one of the tables it generates. This used to happen more > > often in older versions of FreeBSD that had bugs or limitations in > > the code that figured out which IRQ PCI devices used. > > How can I find out exactly which device is using IRQ 22? > Maybe I can disable it - i.e. USB is not needed at all. > > > 2) There is a > > bug in the driver for one of the devices on IRQ 22. In this case the > > only device you have on IRQ is atapci0, so it may be a bug in the > > ata(4) driver, possibly. You could check to see if the interrupt > > handler for the Linux driver for your chipset has extra logic > > (currently ata(4) doesn't have any chipset-specific logic for > > interrupt handlers AFAIK). Also, you could try examining the > > interrupt status register of your controller when you are getting > > storms to see if there is a condition set that isn't being cleared by > > ata's interrupt handler. > > ... of course I could do that - but could you please be so kind and > explain how to do that? :-) Well, you could start by adding a printf to ata's interrupt handler, but that would result in a flood on your screen. You could maybe use a KTR instead, but only do it if the interrupt handler doesn't find any work to do (e.g. no pending request) perhaps. I think the ATA interrrupt handler already reads a status register of some sort, but I could be wrong. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Thu Sep 11 15:01:47 2008 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48F9D106567C for ; Thu, 11 Sep 2008 15:01:47 +0000 (UTC) (envelope-from dominique.goncalves@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.236]) by mx1.freebsd.org (Postfix) with ESMTP id 1E4D88FC1D for ; Thu, 11 Sep 2008 15:01:46 +0000 (UTC) (envelope-from dominique.goncalves@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so479450rvf.43 for ; Thu, 11 Sep 2008 08:01:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=npJ7PrDa3X20jWq9oaXWfEdXQ6MTPoEC/5yZlmlOXTc=; b=iZzVGKm4jUzhjK426bzlArPZExrr5H+J3jEU808WIURjz2YmOZBq61uscuixKuw4tA qZ2b8vvy3WsklgTM4kKiOGWFf3A6Z3FYeX7ETnivXwVLksZetzsQprIvs84s8rhkdKRy HxcDX8+2RgAJomtkRrOkETqIXXr/Vr5/j3E6Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=EE0T3EUsbsk/tAWMqXSKQLngUgMzycA28GtpTUslDQtbbtI3kqp+zqLs4VVgWeYb6L l/C8ldfUwA7kUhDhBhKq+2SrM0QsTr2Q4pXlTn6EKfRJIpHfjs+R8THeo6bGCDCfnR4h AAvF4p2RNEk3+hF7MZ8t5U3M3SxeqJ8o8/dI0= Received: by 10.141.168.7 with SMTP id v7mr1802333rvo.95.1221144031156; Thu, 11 Sep 2008 07:40:31 -0700 (PDT) Received: by 10.141.40.9 with HTTP; Thu, 11 Sep 2008 07:40:31 -0700 (PDT) Message-ID: <7daacbbe0809110740l766afd39wfedd8556136297a7@mail.gmail.com> Date: Thu, 11 Sep 2008 16:40:31 +0200 From: "Dominique Goncalves" To: freebsd-acpi@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: HDD USB still on after computer shutdown X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2008 15:01:47 -0000 Hi, I use FreeBSD 6.3-STABLE and an HDD USB (Maxtor, external PSU, 500GB). When I shutdown my computer (shutdown -p now ) the HDD USB is still on. In Windows XP it works, the HDD USB is off. I also searched in BIOS about an option to disable power for USB but wihout luck. Is there a way to resolve this issue? Let me know if you need more information. Thanks in advance, Regards %dmesg Copyright (c) 1992-2008 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 6.3-STABLE #0: Thu May 29 20:17:28 CEST 2008 root@lost:/usr/obj/usr/src/sys/LOST Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ (2209.90-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x40fb2 Stepping = 2 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x1f Cores per package: 2 real memory = 805240832 (767 MB) avail memory = 774422528 (738 MB) ACPI APIC Table: ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) hptrr: HPT RocketRAID controller driver v1.1 (May 29 2008 20:17:09) acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_hpet0: iomem 0xfeff0000-0xfeff03ff on acpi0 device_attach: acpi_hpet0 attach returned 12 cpu0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 0.0 (no driver attached) isab0: at device 1.0 on pci0 isa0: on isab0 pci0: at device 1.1 (no driver attached) pci0: at device 1.2 (no driver attached) ohci0: mem 0xfe02f000-0xfe02ffff irq 21 at device 2.0 on pci0 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: nVidia OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 8 ports with 8 removable, self powered ehci0: mem 0xfe02e000-0xfe02e0ff irq 22 at device 2.1 on pci0 ehci0: [GIANT-LOCKED] usb1: EHCI version 1.0 usb1: companion controller, 10 ports each: usb0 usb1: on ehci0 usb1: USB revision 2.0 uhub1: nVidia EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub1: 8 ports with 8 removable, self powered umass0: Maxtor Basics Desktop, rev 2.00/1.22, addr 2 pcib1: at device 4.0 on pci0 pci1: on pcib1 xl0: <3Com 3c905-TX Fast Etherlink XL> port 0xcc00-0xcc3f irq 16 at device 5.0 on pci1 miibus0: on xl0 nsphy0: on miibus0 nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: Ethernet address: 00:a0:24:f0:fc:71 fwohci0: mem 0xfd8ff000-0xfd8ff7ff,0xfd8f8000-0xfd8fbfff irq 19 at device 9.0 on pci1 fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:00:0a:e6:ff:69:86:6e fwohci0: Phy 1394a available S400, 3 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:00:0a:69:86:6e fwe0: Ethernet address: 02:00:0a:69:86:6e fwe0: if_start running deferred for Giant sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) pcm0: mem 0xfe028000-0xfe02bfff irq 23 at device 5.0 on pci0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf000-0xf00f at device 6.0 on pci0 ata0: on atapci0 ata1: on atapci0 atapci1: port 0x9f0-0x9f7,0xbf0-0xbf3,0x970-0x977,0xb70-0xb73,0xdc00-0xdc0f mem 0xfe02d000-0xfe02dfff irq 20 at device 8.0 on pci0 ata2: on atapci1 ata3: on atapci1 pcib2: at device 9.0 on pci0 pci2: on pcib2 pcib3: at device 11.0 on pci0 pci3: on pcib3 mskc0: port 0xac00-0xacff mem 0xfdcfc000-0xfdcfffff irq 16 at device 0.0 on pci3 msk0: on mskc0 msk0: Ethernet address: 00:19:21:47:fc:89 miibus1: on msk0 e1000phy0: on miibus1 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto mskc0: [FAST] pcib4: at device 12.0 on pci0 pci4: on pcib4 pci0: at device 13.0 (no driver attached) acpi_tz0: on acpi0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ppc0: port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] acpi_hpet0: iomem 0xfeff0000-0xfeff03ff on acpi0 device_attach: acpi_hpet0 attach returned 12 pmtimer0 on isa0 orm0: at iomem 0xd0000-0xd3fff 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 ums0: Logitech USB-PS/2 Optical Mouse, rev 2.00/20.00, addr 2, iclass 3/1 ums0: 3 buttons and Z dir. umass1: vendor 0x058f USB Reader, rev 1.10/1.00, addr 3 Timecounter "TSC" frequency 2209902318 Hz quality 800 Timecounters tick every 1.000 msec hptrr: no controller detected. acd0: DVDR at ata0-master UDMA66 ad4: 238475MB at ata2-master SATA300 pcm0: pcm0: acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 sks=0x40 0x00 0x01 acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 sks=0x40 0x00 0x01 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-4 device da0: 40.000MB/s transfers da0: 476940MB (976773168 512 byte sectors: 255H 63S/T 60801C) cd0 at ata0 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 66.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present da1 at umass-sim1 bus 1 target 0 lun 0 da1: Removable Direct Access SCSI-0 device da1: 1.000MB/s transfers da1: Attempt to query device size failed: NOT READY, Medium not present da2 at umass-sim1 bus 1 target 0 lun 1 da2: Removable Direct Access SCSI-0 device da2: 1.000MB/s transfers da2: Attempt to query device size failed: NOT READY, Medium not present da3 at umass-sim1 bus 1 target 0 lun 2 da3: Removable Direct Access SCSI-0 device da3: 1.000MB/s transfers da3: Attempt to query device size failed: NOT READY, Medium not present da4 at umass-sim1 bus 1 target 0 lun 3 da4: Removable Direct Access SCSI-0 device da4: 1.000MB/s transfers da4: Attempt to query device size failed: NOT READY, Medium not present Trying to mount root from ufs:/dev/ad4s3a %sysctl hw.acpi hw.acpi.supported_sleep_state: S3 S4 S5 hw.acpi.power_button_state: S5 hw.acpi.sleep_button_state: S3 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.reset_video: 0 hw.acpi.cpu.cx_lowest: C1 hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.user_override: 0 hw.acpi.thermal.tz0.temperature: 40,0C hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.passive_cooling: 1 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: 122,0C hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 124,0C hw.acpi.thermal.tz0._ACx: 122,0C -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz0._TC1: 4 hw.acpi.thermal.tz0._TC2: 3 hw.acpi.thermal.tz0._TSP: 60 -- There's this old saying: "Give a man a fish, feed him for a day. Teach a man to fish, feed him for life." From owner-freebsd-acpi@FreeBSD.ORG Fri Sep 12 13:50:19 2008 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F79F1065678 for ; Fri, 12 Sep 2008 13:50:19 +0000 (UTC) (envelope-from amistry@am-productions.biz) Received: from mail.united-ware.com (am-productions.biz [69.61.164.22]) by mx1.freebsd.org (Postfix) with ESMTP id B95D18FC16 for ; Fri, 12 Sep 2008 13:50:18 +0000 (UTC) (envelope-from amistry@am-productions.biz) Received: from [192.168.1.100] (adsl-68-252-43-110.dsl.wotnoh.ameritech.net [68.252.43.110]) (authenticated bits=0) by mail.united-ware.com (8.14.2/8.14.2) with ESMTP id m8CDc3uc067909 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Sep 2008 09:38:04 -0400 (EDT) (envelope-from amistry@am-productions.biz) From: Anish Mistry Organization: AM Productions To: freebsd-acpi@freebsd.org Date: Fri, 12 Sep 2008 09:37:29 -0400 User-Agent: KMail/1.9.7 References: <7daacbbe0809110740l766afd39wfedd8556136297a7@mail.gmail.com> In-Reply-To: <7daacbbe0809110740l766afd39wfedd8556136297a7@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart6641011.2HtQaibxOb"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200809120937.39041.amistry@am-productions.biz> Cc: Subject: Re: HDD USB still on after computer shutdown X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2008 13:50:19 -0000 --nextPart6641011.2HtQaibxOb Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 11 September 2008, Dominique Goncalves wrote: > Hi, > > I use FreeBSD 6.3-STABLE and an HDD USB (Maxtor, external PSU, > 500GB). When I shutdown my computer (shutdown -p now ) the HDD USB > is still on. In Windows XP it works, the HDD USB is off. > > I also searched in BIOS about an option to disable power for USB > but wihout luck. > > Is there a way to resolve this issue? > > Let me know if you need more information. You may need to send the suspend command to the device. http://freebsd.monkey.org/freebsd-usb/200803/msg00013.html =2D-=20 Anish Mistry amistry@am-productions.biz AM Productions http://am-productions.biz/ --nextPart6641011.2HtQaibxOb Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkjKcJkACgkQxqA5ziudZT2uEACgjLExODxG+YKOOXTeRNS+5B0z hrYAoNjjgG5j/BBldR1rd07fIi8PEbHI =V96i -----END PGP SIGNATURE----- --nextPart6641011.2HtQaibxOb-- From owner-freebsd-acpi@FreeBSD.ORG Fri Sep 12 23:29:07 2008 Return-Path: Delivered-To: acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30FF3106566B; Fri, 12 Sep 2008 23:29:07 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2001:41c8:1:548a::2]) by mx1.freebsd.org (Postfix) with ESMTP id B94AD8FC13; Fri, 12 Sep 2008 23:29:06 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id A386330126; Sat, 13 Sep 2008 00:29:01 +0100 (BST) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on muon.cran.org.uk X-Spam-Level: X-Spam-Status: No, score=-2.3 required=8.0 tests=BAYES_00 autolearn=ham version=3.2.3 Received: from tau.draftnet (tau.demon.co.uk [80.177.26.208]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTP; Sat, 13 Sep 2008 00:29:01 +0100 (BST) Date: Sat, 13 Sep 2008 00:28:50 +0100 From: Bruce Cran To: John Baldwin Message-ID: <20080913002850.26f322ab@tau.draftnet> In-Reply-To: <200807231116.02389.jhb@freebsd.org> References: <20080719100315.2td4dl2q5ck88wkw@webmail.opentransfer.com> <200807221514.55055.jhb@freebsd.org> <20080723140927.duc11agcg44ockw4@webmail.opentransfer.com> <200807231116.02389.jhb@freebsd.org> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; amd64-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: acpi@freebsd.org, freebsd-stable@freebsd.org, Chadwick , Jeremy, "Oleg V. Nauman" Subject: Re: ACPI regression on recent 7.0-STABLE: HPET stops working X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2008 23:29:07 -0000 On Wed, 23 Jul 2008 11:16:02 -0400 John Baldwin wrote: > I've committed the patch. However, I think this actually points out > a slightly bigger issue in that the HPET timer is probably > piggybacking on the ichsmb0 device's BAR, and they really should both > be able to attach somehow. > > A way to fix that would be to make the HPET device actually borrow > the PCI device's resource instead of allocating its own perhaps. I > think the HPET ACPI device and the table tell us the PCI deviec the > HPET lives in. > I just upgraded from 7.0-p3 to 7.1-PRERELEASE on my Dell I1501 laptop and hit this problem too. I noticed the patch was committed to HEAD - are there any plans to MFC it for 7.1? -- Bruce Cran