From owner-freebsd-acpi@FreeBSD.ORG Mon Oct 25 11:06:53 2010 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 DF73E1065672 for ; Mon, 25 Oct 2010 11:06:53 +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 B23518FC16 for ; Mon, 25 Oct 2010 11:06:53 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o9PB6rNP088680 for ; Mon, 25 Oct 2010 11:06:53 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o9PB6ruq088678 for freebsd-acpi@FreeBSD.org; Mon, 25 Oct 2010 11:06:53 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 25 Oct 2010 11:06:53 GMT Message-Id: <201010251106.o9PB6ruq088678@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, 25 Oct 2010 11:06:54 -0000 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 bin/151616 acpi [acpi]: FreeBSD 8 panic on boot. o i386/146715 acpi [acpi] Suspend works, resume not on a HP Probook 4510s o kern/145306 acpi [acpi]: Can't change brightness on HP ProBook 4510s o amd64/144551 acpi [acpi] ACPI issues on SuperMicro X7SPA-H o i386/144045 acpi [acpi] [panic] kernel trap with acpi enabled o i386/143798 acpi [acpi] shutdown problem with SiS K7S5A o kern/143420 acpi [acpi] ACPI issues with Toshiba o kern/142263 acpi [acpi] ACPI regression on Asus K8N7-E deluxe motherboa o kern/142009 acpi [acpi] [panic] Panic in AcpiNsGetAttachedObject o amd64/140751 acpi [acpi] BIOS resource allocation and FreeBSD ACPI in TO o kern/139088 acpi [acpi] ACPI Exception: AE_AML_INFINITE_LOOP error o amd64/138210 acpi [acpi] acer aspire 5536 ACPI problems (S3, brightness, o bin/137053 acpi [hang] FreeBSD 8.0 BETA2Compaq Mini 700 locks on boot o kern/137042 acpi [acpi] hp laptop's lcd not wakes up after suspend to r o i386/136008 acpi [acpi] Dell Vostro 1310 will not shutdown (Requires us o bin/135349 acpi [patch] teach acpidump(8) to disassemble arbitrary mem o kern/135070 acpi [acpi] [patch] BIOS resource allocation and FreeBSD AC 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 p kern/128634 acpi [patch] fix acpi_asus(4) in asus a6f laptop 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 o amd64/121439 acpi [boot] Installation of FreeBSD 7.0 fails: ACPI problem 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/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 o i386/83018 acpi [install] Installer will not boot on Asus P4S8X BIOS 1 o i386/79081 acpi ACPI suspend/resume not working on HP nx6110 o kern/76950 acpi ACPI wrongly blacklisted on Micron ClientPro 766Xi sys o 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 57 problems total. From owner-freebsd-acpi@FreeBSD.ORG Mon Oct 25 16:55:17 2010 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 18D08106564A; Mon, 25 Oct 2010 16:55:17 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Bernhard Froehlich Date: Mon, 25 Oct 2010 12:54:56 -0400 User-Agent: KMail/1.6.2 References: <201010191131.16732.jkim@FreeBSD.org> <23edca762eb8c4fb6306a607d5935564@bluelife.at> In-Reply-To: <23edca762eb8c4fb6306a607d5935564@bluelife.at> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201010251255.09604.jkim@FreeBSD.org> Cc: freebsd-acpi@FreeBSD.org, vbox@FreeBSD.org Subject: Re: VirtualBox: Compile problems with ACPICA 20101013 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, 25 Oct 2010 16:55:17 -0000 On Saturday 23 October 2010 03:28 am, Bernhard Froehlich wrote: > On Tue, 19 Oct 2010 11:31:00 -0400, Jung-uk Kim > > wrote: > > On Tuesday 19 October 2010 08:52 am, Bernhard Froehlich wrote: > >> On Mon, 18 Oct 2010 13:33:26 -0400, Jung-uk Kim > >> > >> > >> wrote: > >> > On Monday 18 October 2010 05:44 am, Bernhard Froehlich wrote: > >> >> Hi guys! > >> >> > >> >> VirtualBox has a compile problem with latest acpica. I've > >> >> talked to the VirtualBox developers and they think it's an > >> >> acpica problem which should be fixed upstream. Can we somehow > >> >> file a bugreport or create a patch to fix that in acpica? > >> > > >> > Excerpt rom ACPI 4.0a: > >> > > >> > --------------------------------------------------- > >> > Each Compatible Device ID must be either: > >> > > >> > o A valid HID value (a 32-bit compressed EISA type ID or a > >> > string such as "ACPI0004"). > >> > o A string that uses a bus-specific nomenclature. For > >> > example, _CID can be used to specify the PCI ID. > >> > --------------------------------------------------- > >> > > >> > Since it is not a valid HID value, you can only say it may be > >> > a bus-specific nomenclature at best. However, it looks like > >> > an ISA device to me and probably it is just a bogus ID. In > >> > fact, I googled a bit and it only exists on some Intel Mac > >> > models, it seems. You can just remove the entire _CID unless > >> > it is absolutely necessary, which is very unlikely. :-) > >> > >> It very much looks like a regression. Right beyond that > >> sentences they have a few examples in the ACPI 4.0a spec on page > >> 201 that won't pass that check. I haven't looked at all the code > >> so probably it's done somewhere completely different but if it > >> is checked with that code then it will complain. > >> > >> ACPI 4.0a spec on page 201: > >> --------------------------------------------------- > >> o A valid HID value (a 32-bit compressed EISA type ID or a > >> string such as "ACPI0004"). > >> o A string that uses a bus-specific nomenclature. For example, > >> _CID can be used to specify the PCI ID. > >> > >> "PCI\CC_ccss" > >> "PCI\CC_ccsspp" > >> "PCI\VEN_vvvv&DEV_dddd&SUBSYS_ssssssss&REV_rr" > >> .... > >> --------------------------------------------------- > >> > >> Now with a deeper look at the commit from acpica [1] especially > >> the second half. Before there was only an alphanumeric check for > >> _HID but with that change it was put into a new function > >> AnCheckId() that is called for both _HID and _CID and now wants > >> both to be alphanumeric. That looks correct for _HID but it's > >> too strict for _CID which is a string. Somewhere i've seen > >> string is defined as a null-terminated ASCII string and no word > >> about alphanumeric. > >> > >> [1] > >> http://git.moblin.org/cgit.cgi/acpica/commit/?id=b66fd716e0b9b53 > >>89e > > > > Yes, I am aware of the issue. My point was _CID may be pointless > > for *VirtualBox* and it can be removed. > > I am just trying to figure out who is wrong and try to fix it there > if possible. Understood. > So do you agree that this is a acpica regression? Yes, I do. I was told Intel would going to look into it. > Vbox guys say that removing it is not a good idea because it will > "break things" but I don't know what it is used for so I cannot test > it. It *may* break Mac OS X guest. However, I don't believe it would rely on _CID. On top of that, Mac OS X is not a supported guest OS and it is illegal, AFAIK. So, I don't think it would matter. ;-) Jung-uk Kim From owner-freebsd-acpi@FreeBSD.ORG Tue Oct 26 19:12:49 2010 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 2F90A1065696; Tue, 26 Oct 2010 19:12:49 +0000 (UTC) (envelope-from takawata@init-main.com) Received: from sana.init-main.com (unknown [IPv6:2001:240:28::1]) by mx1.freebsd.org (Postfix) with ESMTP id 869F18FC08; Tue, 26 Oct 2010 19:12:48 +0000 (UTC) Received: from ns.init-main.com (localhost [127.0.0.1]) by sana.init-main.com (8.14.3/8.14.3) with ESMTP id o9QJ4iwq089834; Wed, 27 Oct 2010 04:04:45 +0900 (JST) (envelope-from takawata@ns.init-main.com) Message-Id: <201010261904.o9QJ4iwq089834@sana.init-main.com> To: mav@freebsd.org Date: Wed, 27 Oct 2010 04:04:44 +0900 From: Takanori Watanabe Cc: acpi@freebsd.org, current@freebsd.org Subject: Event based scheduling and USB. 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, 26 Oct 2010 19:12:49 -0000 I updated my FreeBSD tree on laptop, to the current as of 18 Oct.2010, it works fine with CPU C3 state enabled, I think this is your achievement of event time scheduler, thanks! But when USB driver is enabled, the load average is considerablly high (0.6 to 1.0) if sysctl oid kern.eventtimer.periodic is set to 0. Then kern.eventtimer.periodic is set to 1, the load average goes to 0 quickly as before, but almost never transit to C3. Is this behavior expected, or something wrong? I noticed one of usb host controller device shares HPET irq. When I implement interrupt filter in uhci driver, the load average goes to 0 as before. ==== % vmstat -i interrupt total rate irq1: atkbd0 398 2 irq9: acpi0 408 2 irq12: psm0 3 0 irq19: ehci1 37 0 irq20: hpet0 uhci0 35970 230 irq22: ehci0 2 0 irq256: em0 4 0 irq257: ahci0 1692 10 Total 38514 246 === BTW, when USB port is enabled C3 transition rate gets lower. I think it is likely to occur. But how can I supress power consumption? It's time to implement powertop for freebsd, isn't it? From owner-freebsd-acpi@FreeBSD.ORG Tue Oct 26 20:24:24 2010 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 400851065672 for ; Tue, 26 Oct 2010 20:24:24 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id C0E178FC19 for ; Tue, 26 Oct 2010 20:24:23 +0000 (UTC) Received: by fxm17 with SMTP id 17so4526314fxm.13 for ; Tue, 26 Oct 2010 13:24:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=+39SDKZj+XBm00WDZdvwxRdB2EHvdKe1a04TzeKRPs0=; b=teOG24ZzLbj6XI1hp/g/L4Wh2EbU4Fi2MOqqjHaFt0PZWoNSREGThy8IoN/C2gmTgC DszP9KgGK3HNIxG1bB4dnadaI6mWAdKA5e657ZpbJpVuSQnBursRzm1lDy1SwNUEMKP0 jmhiJgbhxBzHy2HrEVDxuX3m/2gdyd49krSx8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=U7pmVW22pXiOjDpxfK4OXqOTjYWVuuYjqFGKcAk1Cz3kGQS7MsFGdhjeQm8DgpRK/r 7l830KLrfzRlg9vuOtThHBkpPt0AYLQ5wXpCU/FLk91gp/6ZY2T7/QQeLytWxMWzLfp+ Ps3jyVZeUUXtoGplw7Mt7jPAO6Ywl4LgJi0GY= Received: by 10.223.97.69 with SMTP id k5mr100873fan.67.1288123100051; Tue, 26 Oct 2010 12:58:20 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (95-109-148-112.dialup.umc.net.ua [95.109.148.112]) by mx.google.com with ESMTPS id l23sm546154fam.19.2010.10.26.12.58.12 (version=SSLv3 cipher=RC4-MD5); Tue, 26 Oct 2010 12:58:18 -0700 (PDT) Sender: Alexander Motin Message-ID: <4CC732C7.50409@FreeBSD.org> Date: Tue, 26 Oct 2010 22:57:59 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: Takanori Watanabe References: <201010261904.o9QJ4iwq089834@sana.init-main.com> In-Reply-To: <201010261904.o9QJ4iwq089834@sana.init-main.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: acpi@freebsd.org, current@freebsd.org Subject: Re: Event based scheduling and USB. 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, 26 Oct 2010 20:24:24 -0000 Takanori Watanabe wrote: > I updated my FreeBSD tree on laptop, to the current > as of 18 Oct.2010, it works fine with CPU C3 state enabled, > > I think this is your achievement of event time scheduler, > thanks! > > But when USB driver is enabled, the load average is considerablly > high (0.6 to 1.0) if sysctl oid kern.eventtimer.periodic is set to 0. > Then kern.eventtimer.periodic is set to 1, the load average goes > to 0 quickly as before, but almost never transit to C3. > > Is this behavior expected, or something wrong? > I noticed one of usb host controller device shares HPET irq. > When I implement interrupt filter in uhci driver, the load average > goes to 0 as before. > > > ==== > % vmstat -i > interrupt total rate > irq1: atkbd0 398 2 > irq9: acpi0 408 2 > irq12: psm0 3 0 > irq19: ehci1 37 0 > irq20: hpet0 uhci0 35970 230 > irq22: ehci0 2 0 > irq256: em0 4 0 > irq257: ahci0 1692 10 > Total 38514 246 > === I haven't noticed that issue and it is surely not expected for me. I will try to reproduce it. Most likely you should be able to avoid interrupt sharing using some additional HPET options, described at hpet(4). > BTW, when USB port is enabled C3 transition rate gets lower. > I think it is likely to occur. But how can I supress power > consumption? I can't say about USB, but you may try this patch to optimize some other subsystems: http://people.freebsd.org/~mav/tm6292_idle.patch > It's time to implement powertop for freebsd, isn't it? Surely it is. I was even thinking about possibility to port one from OpenSolaris, but other work distracted me. You may take it, it you wish. -- Alexander Motin From owner-freebsd-acpi@FreeBSD.ORG Tue Oct 26 22:59:47 2010 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 377B0106566B; Tue, 26 Oct 2010 22:59:47 +0000 (UTC) (envelope-from nate@root.org) Received: from mail.root.org (root.org [208.72.84.34]) by mx1.freebsd.org (Postfix) with ESMTP id 0E1AF8FC17; Tue, 26 Oct 2010 22:59:46 +0000 (UTC) Received: from [10.1.0.199] (dsl081-053-082.sfo1.dsl.speakeasy.net [64.81.53.82]) by mail.root.org (Postfix) with ESMTP id C67AD6A6E; Tue, 26 Oct 2010 22:44:35 +0000 (UTC) Message-ID: <4CC759D5.2020207@root.org> Date: Tue, 26 Oct 2010 15:44:37 -0700 From: Nate Lawson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: Alexander Motin References: <201010261904.o9QJ4iwq089834@sana.init-main.com> <4CC732C7.50409@FreeBSD.org> In-Reply-To: <4CC732C7.50409@FreeBSD.org> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: acpi@freebsd.org, current@freebsd.org Subject: Re: Event based scheduling and USB. 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, 26 Oct 2010 22:59:47 -0000 On 10/26/2010 12:57 PM, Alexander Motin wrote: > Takanori Watanabe wrote: >> I updated my FreeBSD tree on laptop, to the current >> as of 18 Oct.2010, it works fine with CPU C3 state enabled, >> >> I think this is your achievement of event time scheduler, >> thanks! Ah, so mav@ implemented a tickless-scheduler? That is nice. >> But when USB driver is enabled, the load average is considerablly >> high (0.6 to 1.0) if sysctl oid kern.eventtimer.periodic is set to 0. >> Then kern.eventtimer.periodic is set to 1, the load average goes >> to 0 quickly as before, but almost never transit to C3. >> >> Is this behavior expected, or something wrong? The USB controller often keeps the bus mastering bit set. This keeps the system out of C3. The way to fix this is to implement global suspend. Put a device in suspend mode and then turn off power to the USB port it is on. Then the USB controller will stop polling the bus. >> I noticed one of usb host controller device shares HPET irq. >> When I implement interrupt filter in uhci driver, the load average >> goes to 0 as before. >> >> >> ==== >> % vmstat -i >> interrupt total rate >> irq1: atkbd0 398 2 >> irq9: acpi0 408 2 >> irq12: psm0 3 0 >> irq19: ehci1 37 0 >> irq20: hpet0 uhci0 35970 230 >> irq22: ehci0 2 0 >> irq256: em0 4 0 >> irq257: ahci0 1692 10 >> Total 38514 246 >> === > > I haven't noticed that issue and it is surely not expected for me. I > will try to reproduce it. > > Most likely you should be able to avoid interrupt sharing using some > additional HPET options, described at hpet(4). This seems silly. The whole point of APIC is to avoid clustering on a single interrupt but the BIOS put the timer on the USB controller irq? >> It's time to implement powertop for freebsd, isn't it? > > Surely it is. I was even thinking about possibility to port one from > OpenSolaris, but other work distracted me. You may take it, it you wish. It seems worth doing the internals new, but maybe outputting information in a compatible format for reporting tools. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Wed Oct 27 07:23:10 2010 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 A1858106564A for ; Wed, 27 Oct 2010 07:23:10 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.swip.net [212.247.154.1]) by mx1.freebsd.org (Postfix) with ESMTP id 2814E8FC18 for ; Wed, 27 Oct 2010 07:23:09 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=omSrwDgyMf70S47Fr5SNr0rQzcmIOo0IafWlB/wSLLo= c=1 sm=1 a=gH2l33NO9zgA:10 a=NRVYDW02eVsA:10 a=Fdkxr_5KmFUA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=65oRmVqlVvY7-fWgNlEA:9 a=g1Tc6fMsMDpfRevSPQc1MQFbg9QA:4 a=pvA44qeTxYYA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe01.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 41325776; Wed, 27 Oct 2010 09:13:05 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Wed, 27 Oct 2010 09:14:16 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <201010261904.o9QJ4iwq089834@sana.init-main.com> <4CC732C7.50409@FreeBSD.org> <4CC759D5.2020207@root.org> In-Reply-To: <4CC759D5.2020207@root.org> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Message-Id: <201010270914.16781.hselasky@c2i.net> Cc: acpi@freebsd.org, Alexander Motin , current@freebsd.org Subject: Re: Event based scheduling and USB. 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: Wed, 27 Oct 2010 07:23:10 -0000 By default USB devices are not suspended. You can use "usbconfig power_save" to enable automatic power save for all devices. --HPS From owner-freebsd-acpi@FreeBSD.ORG Wed Oct 27 07:45:04 2010 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 4128D10656A8; Wed, 27 Oct 2010 07:45:04 +0000 (UTC) (envelope-from takawata@init-main.com) Received: from sana.init-main.com (unknown [IPv6:2001:240:28::1]) by mx1.freebsd.org (Postfix) with ESMTP id 93AE68FC2D; Wed, 27 Oct 2010 07:45:02 +0000 (UTC) Received: from ns.init-main.com (localhost [127.0.0.1]) by sana.init-main.com (8.14.3/8.14.3) with ESMTP id o9R7b2aj093646; Wed, 27 Oct 2010 16:37:03 +0900 (JST) (envelope-from takawata@ns.init-main.com) Message-Id: <201010270737.o9R7b2aj093646@sana.init-main.com> To: Alexander Motin In-reply-to: Your message of "Tue, 26 Oct 2010 22:57:59 +0300." <4CC732C7.50409@FreeBSD.org> Date: Wed, 27 Oct 2010 16:37:02 +0900 From: Takanori Watanabe Cc: freebsd-acpi@FreeBSD.org Subject: Re: Event based scheduling and USB. 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: Wed, 27 Oct 2010 07:45:04 -0000 In message <4CC732C7.50409@FreeBSD.org>, Alexander Motin wrote: >Takanori Watanabe wrote: >> Is this behavior expected, or something wrong? >> I noticed one of usb host controller device shares HPET irq. >> When I implement interrupt filter in uhci driver, the load average >> goes to 0 as before. >> >> >> ==== >> % vmstat -i >> interrupt total rate >> irq1: atkbd0 398 2 >> irq9: acpi0 408 2 >> irq12: psm0 3 0 >> irq19: ehci1 37 0 >> irq20: hpet0 uhci0 35970 230 >> irq22: ehci0 2 0 >> irq256: em0 4 0 >> irq257: ahci0 1692 10 >> Total 38514 246 >> === > >I haven't noticed that issue and it is surely not expected for me. I >will try to reproduce it. > >Most likely you should be able to avoid interrupt sharing using some >additional HPET options, described at hpet(4). Try to disable using shared IRQ with uhci, the IRQ used by HPET become cpu: interrupt and certainly load average goes quite low, but never transit to C3 state. Using legacy route, it works quite well. From owner-freebsd-acpi@FreeBSD.ORG Wed Oct 27 08:14:27 2010 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 0447E1065675; Wed, 27 Oct 2010 08:14:27 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 58C698FC15; Wed, 27 Oct 2010 08:14:25 +0000 (UTC) Received: by bwz3 with SMTP id 3so283940bwz.13 for ; Wed, 27 Oct 2010 01:14:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=GQZ/4iSm5oNKXM5G8WowQrlO3qUqjm6ZVWGBj6LUyQc=; b=c0loJM1+rMJ5YVog/ziD+nEM5+SiiK9qmIpoVjxad5dF2HrP+t6goD5UEal4oKh6ms tHDU57bM93SPkRPYgD7Zwzsh3Dqb4XdxsY0bKQZPbVX/+vCewwwvzOg7b8dNhF62C+5C hku3hlgMa0n506IM2IacVARn31DEU1Wk5fRAM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=iY8iq1LildKsVscNUG5/ULApGpqxvn4NkxBV3u5T3AG+rLuocT7zJS71djjg1TBhTz 3aiWm0noo6JYyPYrORVFs8IiL8ZnXNh1XVFzMzYXUV4rb7RX3KwidgGtguyERfDnXCcv Nz59eVxI9NOZL+n+WnOunyEJfP5A1l87nW3Uw= Received: by 10.204.118.209 with SMTP id w17mr6494844bkq.107.1288167265138; Wed, 27 Oct 2010 01:14:25 -0700 (PDT) Received: from mavbook.mavhome.dp.ua ([91.198.175.253]) by mx.google.com with ESMTPS id 4sm6731536bki.1.2010.10.27.01.14.20 (version=SSLv3 cipher=RC4-MD5); Wed, 27 Oct 2010 01:14:21 -0700 (PDT) Sender: Alexander Motin Message-ID: <4CC7DF5A.6070904@FreeBSD.org> Date: Wed, 27 Oct 2010 11:14:18 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: Nate Lawson References: <201010261904.o9QJ4iwq089834@sana.init-main.com> <4CC732C7.50409@FreeBSD.org> <4CC759D5.2020207@root.org> In-Reply-To: <4CC759D5.2020207@root.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: acpi@freebsd.org, current@freebsd.org Subject: Re: Event based scheduling and USB. 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: Wed, 27 Oct 2010 08:14:27 -0000 Nate Lawson wrote: > On 10/26/2010 12:57 PM, Alexander Motin wrote: >> Takanori Watanabe wrote: >>> I updated my FreeBSD tree on laptop, to the current >>> as of 18 Oct.2010, it works fine with CPU C3 state enabled, >>> >>> I think this is your achievement of event time scheduler, >>> thanks! > > Ah, so mav@ implemented a tickless-scheduler? That is nice. Not exactly. I've only made system to delay empty ticks when idle and execute them later on wakeup in a batch. Scheduler work is still wanted. >>> But when USB driver is enabled, the load average is considerablly >>> high (0.6 to 1.0) if sysctl oid kern.eventtimer.periodic is set to 0. >>> Then kern.eventtimer.periodic is set to 1, the load average goes >>> to 0 quickly as before, but almost never transit to C3. >>> >>> Is this behavior expected, or something wrong? > > The USB controller often keeps the bus mastering bit set. This keeps the > system out of C3. The way to fix this is to implement global suspend. > Put a device in suspend mode and then turn off power to the USB port it > is on. Then the USB controller will stop polling the bus. As I understand, if respective USB port is not used, USB stack should put it into power_save mode not poll so often to deny entering C3 state. >>> I noticed one of usb host controller device shares HPET irq. >>> When I implement interrupt filter in uhci driver, the load average >>> goes to 0 as before. >>> >>> >>> ==== >>> % vmstat -i >>> interrupt total rate >>> irq1: atkbd0 398 2 >>> irq9: acpi0 408 2 >>> irq12: psm0 3 0 >>> irq19: ehci1 37 0 >>> irq20: hpet0 uhci0 35970 230 >>> irq22: ehci0 2 0 >>> irq256: em0 4 0 >>> irq257: ahci0 1692 10 >>> Total 38514 246 >>> === >> I haven't noticed that issue and it is surely not expected for me. I >> will try to reproduce it. >> >> Most likely you should be able to avoid interrupt sharing using some >> additional HPET options, described at hpet(4). > > This seems silly. The whole point of APIC is to avoid clustering on a > single interrupt but the BIOS put the timer on the USB controller irq? HPET timer is not a regular ISA or PCI device. It allows several different interrupt configurations. In most cases I remember, BIOS setups interrupts 0 and 8, like for legacy_route mode. But this mode is not really suitable as default in our case ATM due to conflict with atrtc and attimer drivers. -- Alexander Motin From owner-freebsd-acpi@FreeBSD.ORG Wed Oct 27 08:18:28 2010 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 CEA7E10657F5 for ; Wed, 27 Oct 2010 08:18:28 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5921A8FC18 for ; Wed, 27 Oct 2010 08:18:27 +0000 (UTC) Received: by bwz3 with SMTP id 3so285474bwz.13 for ; Wed, 27 Oct 2010 01:18:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=yIBbxop7V6JlnwCUESC4lg+/ELHT4c6bN8FmTOfmuzc=; b=skW3xNmXgbqZtD3Nyvw86UN39cgJviSnry/lUZh4OSTSlG+eGG/BbZn53lOvXODLlL Z7S87aIQ0sRY5ivMJEm7KxZjbeQX17rH0PRS03WBdJX+8jHDBDl27Be9mVH6QiGLhdP0 BCOkWoBxcQmNZxAKHghJGHK+E8nhvUWPNV3cc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=jmayWWwL/eIY8ouDqpXnuIEWJLUAM6/3a1X4PT1/EdB9mLKWyWK3V/f1V5K6ewcAin tvQI0EJgb9nXQkaxS0evDNKtRfjet4Kyln4NyidS4EPqtAtk3RujEkOPK9U3QCsmjGnT bXb7FQosqJx7UgqZYxtiSi7ahWAGIa+2Fvuk4= Received: by 10.204.84.158 with SMTP id j30mr7013771bkl.127.1288166190172; Wed, 27 Oct 2010 00:56:30 -0700 (PDT) Received: from mavbook.mavhome.dp.ua ([91.198.175.253]) by mx.google.com with ESMTPS id d27sm6715800bkw.14.2010.10.27.00.56.27 (version=SSLv3 cipher=RC4-MD5); Wed, 27 Oct 2010 00:56:28 -0700 (PDT) Sender: Alexander Motin Message-ID: <4CC7DB2A.2090601@FreeBSD.org> Date: Wed, 27 Oct 2010 10:56:26 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: Takanori Watanabe References: <201010270737.o9R7b2aj093646@sana.init-main.com> In-Reply-To: <201010270737.o9R7b2aj093646@sana.init-main.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org Subject: Re: Event based scheduling and USB. 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: Wed, 27 Oct 2010 08:18:28 -0000 Takanori Watanabe wrote: > In message <4CC732C7.50409@FreeBSD.org>, Alexander Motin wrote: >> Most likely you should be able to avoid interrupt sharing using some >> additional HPET options, described at hpet(4). > > Try to disable using shared IRQ with uhci, the IRQ used by HPET become cpu: > interrupt and certainly load average goes quite low, If you mean "cpuX:timer" - then probably you did something wrong and system fallen back to LAPIC timer. > but never transit to C3 state. Using legacy route, it works quite well. C3 state is blocked when LAPIC timer used. -- Alexander Motin From owner-freebsd-acpi@FreeBSD.ORG Wed Oct 27 08:19:02 2010 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 82914106566C; Wed, 27 Oct 2010 08:19:02 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 3538F8FC18; Wed, 27 Oct 2010 08:19:01 +0000 (UTC) Received: from outgoing.leidinger.net (p57B3B9AF.dip.t-dialin.net [87.179.185.175]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 3CE8084400D; Wed, 27 Oct 2010 09:59:05 +0200 (CEST) Received: from webmail.leidinger.net (unknown [IPv6:fd73:10c7:2053:1::2:102]) by outgoing.leidinger.net (Postfix) with ESMTP id B24C11548; Wed, 27 Oct 2010 09:59:01 +0200 (CEST) Received: (from www@localhost) by webmail.leidinger.net (8.14.4/8.13.8/Submit) id o9R7wZ6v019807; Wed, 27 Oct 2010 09:58:35 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.ec.europa.eu (pslux.ec.europa.eu [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Wed, 27 Oct 2010 09:58:35 +0200 Message-ID: <20101027095835.673250yk09t4ei88@webmail.leidinger.net> Date: Wed, 27 Oct 2010 09:58:35 +0200 From: Alexander Leidinger To: Alexander Motin References: <201010261904.o9QJ4iwq089834@sana.init-main.com> <4CC732C7.50409@FreeBSD.org> In-Reply-To: <4CC732C7.50409@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.4) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 3CE8084400D.A65AE X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=1.351, required 6, autolearn=disabled, RDNS_NONE 1.27, TW_GT 0.08) X-EBL-MailScanner-SpamScore: s X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1288771146.13025@94jAf5AdpypSy1OWveLCcw X-EBL-Spam-Status: No Cc: acpi@FreeBSD.org, current@FreeBSD.org Subject: Re: Event based scheduling and USB. 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: Wed, 27 Oct 2010 08:19:02 -0000 Quoting Alexander Motin (from Tue, 26 Oct 2010 22:57:59 +0300): > Takanori Watanabe wrote: >> It's time to implement powertop for freebsd, isn't it? > > Surely it is. I was even thinking about possibility to port one from > OpenSolaris, but other work distracted me. You may take it, it you wish. For the benefit of the people which didn't see my message with the URL (I don't know if I was sending the URL to mav@ personally or if it appeared also in the lists): http://hub.opensolaris.org/bin/view/Project+tesla/Powertop is a DTrace-ified version of PowerTop (at the end of the page is a description how to get the source). And for those which like plots of the values: http://hub.opensolaris.org/bin/view/Project+tesla/ptop-gtk Bye, Alexander. -- A RACF protected dataset is inaccessible. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-acpi@FreeBSD.ORG Wed Oct 27 08:49:48 2010 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 C5BAE106566B; Wed, 27 Oct 2010 08:49:48 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe02.swip.net [212.247.154.33]) by mx1.freebsd.org (Postfix) with ESMTP id A8F5E8FC1F; Wed, 27 Oct 2010 08:49:47 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=yevn+QCjI6xy199BDvBOOiO14qYvyLq62he9tTtU3M8= c=1 sm=1 a=gH2l33NO9zgA:10 a=NRVYDW02eVsA:10 a=Fdkxr_5KmFUA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=6Vs0ZOnw7vyQ3EVZuIAA:9 a=tC6uNG36Ia20ZGDY8tayU9SAcywA:4 a=pvA44qeTxYYA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe02.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 40691372; Wed, 27 Oct 2010 10:49:45 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Wed, 27 Oct 2010 10:50:56 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <201010261904.o9QJ4iwq089834@sana.init-main.com> <4CC759D5.2020207@root.org> <4CC7DF5A.6070904@FreeBSD.org> In-Reply-To: <4CC7DF5A.6070904@FreeBSD.org> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Message-Id: <201010271050.56141.hselasky@c2i.net> Cc: acpi@freebsd.org, Alexander Motin , current@freebsd.org Subject: Re: Event based scheduling and USB. 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: Wed, 27 Oct 2010 08:49:48 -0000 On Wednesday 27 October 2010 10:14:18 Alexander Motin wrote: > As I understand, if respective USB port is not used, USB stack should > put it into power_save mode not poll so often to deny entering C3 state. USB will stop the hardware from polling RAM, but still a 4 second root HUB software timer/watchdog will be running. --HPS From owner-freebsd-acpi@FreeBSD.ORG Wed Oct 27 09:20:08 2010 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 A6B3C1065675 for ; Wed, 27 Oct 2010 09:20:08 +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 94A2A8FC13 for ; Wed, 27 Oct 2010 09:20:08 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o9R9K8E6034298 for ; Wed, 27 Oct 2010 09:20:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o9R9K86A034297; Wed, 27 Oct 2010 09:20:08 GMT (envelope-from gnats) Date: Wed, 27 Oct 2010 09:20:08 GMT Message-Id: <201010270920.o9R9K86A034297@freefall.freebsd.org> To: freebsd-acpi@FreeBSD.org From: =?ISO-8859-2?Q?Damian_S=2E_Ko=B3odziejczyk?= Cc: Subject: Re: bin/151616: [acpi]: FreeBSD 8 panic on boot. X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?ISO-8859-2?Q?Damian_S=2E_Ko=B3odziejczyk?= List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 09:20:08 -0000 The following reply was made to PR bin/151616; it has been noted by GNATS. From: =?ISO-8859-2?Q?Damian_S=2E_Ko=B3odziejczyk?= To: bug-followup@FreeBSD.org Cc: Subject: Re: bin/151616: [acpi]: FreeBSD 8 panic on boot. Date: Wed, 27 Oct 2010 10:51:36 +0200 2010/10/21 John Baldwin : > Can you get capture the messages before the panic, ideally from a verbose > boot? =A0If you can compile a kernel with DDB and get a stack trace that = would > also be very helpful. =A0You can use a digital camera if you can't hook u= p a > serial console (and don't want to write the messages down by hand). > Here is photo from 9-CURRENT (201010): http://img839.imageshack.us/i/zdjcie01h.jpg/ http://img301.imageshack.us/i/zdjcie02c.jpg/ http://img840.imageshack.us/i/zdjcie03.jpg/ --=20 Damian From owner-freebsd-acpi@FreeBSD.ORG Wed Oct 27 10:20:07 2010 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 8D0351065675 for ; Wed, 27 Oct 2010 10:20: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 6223F8FC13 for ; Wed, 27 Oct 2010 10:20:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o9RAK7KB096044 for ; Wed, 27 Oct 2010 10:20:07 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o9RAK79T096043; Wed, 27 Oct 2010 10:20:07 GMT (envelope-from gnats) Date: Wed, 27 Oct 2010 10:20:07 GMT Message-Id: <201010271020.o9RAK79T096043@freefall.freebsd.org> To: freebsd-acpi@FreeBSD.org From: Andriy Gapon Cc: Subject: Re: bin/151616: [acpi]: FreeBSD 8 panic on boot. X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andriy Gapon List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 10:20:07 -0000 The following reply was made to PR bin/151616; it has been noted by GNATS. From: Andriy Gapon To: =?UTF-8?B?IkRhbWlhbiBTLiBLb8WCb2R6aWVqY3p5ayI=?= Cc: bug-followup@FreeBSD.org Subject: Re: bin/151616: [acpi]: FreeBSD 8 panic on boot. Date: Wed, 27 Oct 2010 13:16:58 +0300 on 27/10/2010 12:20 Damian S. Kołodziejczyk said the following: > Here is photo from 9-CURRENT (201010): > > http://img839.imageshack.us/i/zdjcie01h.jpg/ Thanks a lot! But this wasn't a verbose boot, was it? -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Wed Oct 27 10:40:03 2010 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 E436D106566B for ; Wed, 27 Oct 2010 10:40: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 B280F8FC14 for ; Wed, 27 Oct 2010 10:40:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o9RAe35k015918 for ; Wed, 27 Oct 2010 10:40:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o9RAe3rp015917; Wed, 27 Oct 2010 10:40:03 GMT (envelope-from gnats) Date: Wed, 27 Oct 2010 10:40:03 GMT Message-Id: <201010271040.o9RAe3rp015917@freefall.freebsd.org> To: freebsd-acpi@FreeBSD.org From: =?ISO-8859-2?Q?Damian_S=2E_Ko=B3odziejczyk?= Cc: Subject: Re: bin/151616: [acpi]: FreeBSD 8 panic on boot. X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?ISO-8859-2?Q?Damian_S=2E_Ko=B3odziejczyk?= List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 10:40:04 -0000 The following reply was made to PR bin/151616; it has been noted by GNATS. From: =?ISO-8859-2?Q?Damian_S=2E_Ko=B3odziejczyk?= To: bug-followup@FreeBSD.org, damkol@gmail.com Cc: Subject: Re: bin/151616: [acpi]: FreeBSD 8 panic on boot. Date: Wed, 27 Oct 2010 12:38:13 +0200 W dniu 27 pa=BCdziernika 2010 12:16 u=BFytkownik Andriy Gapon napisa=B3: > Thanks a lot! > But this wasn't a verbose boot, was it? > Here is verbose boot: http://img43.imageshack.us/img43/225/zdjcie030g.jpg Sorry for the quality, this camera phone. --=20 Damian From owner-freebsd-acpi@FreeBSD.ORG Wed Oct 27 11:20:07 2010 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 898D2106566C for ; Wed, 27 Oct 2010 11:20: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 5CFFB8FC19 for ; Wed, 27 Oct 2010 11:20:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o9RBK71H059478 for ; Wed, 27 Oct 2010 11:20:07 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o9RBK7or059477; Wed, 27 Oct 2010 11:20:07 GMT (envelope-from gnats) Date: Wed, 27 Oct 2010 11:20:07 GMT Message-Id: <201010271120.o9RBK7or059477@freefall.freebsd.org> To: freebsd-acpi@FreeBSD.org From: Andriy Gapon Cc: Subject: Re: bin/151616: [acpi]: FreeBSD 8 panic on boot. X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andriy Gapon List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 11:20:07 -0000 The following reply was made to PR bin/151616; it has been noted by GNATS. From: Andriy Gapon To: =?UTF-8?B?IkRhbWlhbiBTLiBLb8WCb2R6aWVqY3p5ayI=?= Cc: bug-followup@FreeBSD.org Subject: Re: bin/151616: [acpi]: FreeBSD 8 panic on boot. Date: Wed, 27 Oct 2010 14:10:52 +0300 on 27/10/2010 13:40 Damian S. Kołodziejczyk said the following: > Here is verbose boot: > http://img43.imageshack.us/img43/225/zdjcie030g.jpg Would it be possible to scroll up and take the pictures of all the messages since the start of boot ? Thank you. > Sorry for the quality, this camera phone. It's actually OK. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Wed Oct 27 11:50:09 2010 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 9765A10656C2 for ; Wed, 27 Oct 2010 11:50:09 +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 85E268FC13 for ; Wed, 27 Oct 2010 11:50:09 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o9RBo9qB091393 for ; Wed, 27 Oct 2010 11:50:09 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o9RBo9x6091392; Wed, 27 Oct 2010 11:50:09 GMT (envelope-from gnats) Date: Wed, 27 Oct 2010 11:50:09 GMT Message-Id: <201010271150.o9RBo9x6091392@freefall.freebsd.org> To: freebsd-acpi@FreeBSD.org From: =?ISO-8859-2?Q?Damian_S=2E_Ko=B3odziejczyk?= Cc: Subject: Re: bin/151616: [acpi]: FreeBSD 8 panic on boot. X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?ISO-8859-2?Q?Damian_S=2E_Ko=B3odziejczyk?= List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 11:50:09 -0000 The following reply was made to PR bin/151616; it has been noted by GNATS. From: =?ISO-8859-2?Q?Damian_S=2E_Ko=B3odziejczyk?= To: bug-followup@FreeBSD.org, damkol@gmail.com Cc: Subject: Re: bin/151616: [acpi]: FreeBSD 8 panic on boot. Date: Wed, 27 Oct 2010 13:42:30 +0200 W dniu 27 pa=BCdziernika 2010 13:10 u=BFytkownik Andriy Gapon napisa=B3: > Would it be possible to scroll up and take the pictures of all the messag= es since > the start of boot ? No problem: http://img28.imageshack.us/i/zdjcie031i.jpg/ http://img839.imageshack.us/i/zdjcie032b.jpg/ http://img163.imageshack.us/i/zdjcie033e.jpg/ http://img185.imageshack.us/i/zdjcie034l.jpg/ Next one is http://img43.imageshack.us/img43/225/zdjcie030g.jpg --=20 Damian From owner-freebsd-acpi@FreeBSD.ORG Wed Oct 27 11:54:54 2010 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 3405E106566C for ; Wed, 27 Oct 2010 11:54:54 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 04B2E8FC1B for ; Wed, 27 Oct 2010 11:54:54 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id A852046B06; Wed, 27 Oct 2010 07:54:53 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 86B9C8A009; Wed, 27 Oct 2010 07:54:50 -0400 (EDT) From: John Baldwin To: freebsd-acpi@freebsd.org, Andriy Gapon Date: Wed, 27 Oct 2010 07:54:46 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <201010271120.o9RBK7or059477@freefall.freebsd.org> In-Reply-To: <201010271120.o9RBK7or059477@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Message-Id: <201010270754.46706.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 27 Oct 2010 07:54:50 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-0.3 required=4.2 tests=BAYES_00,URIBL_SBL autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Subject: Re: bin/151616: [acpi]: FreeBSD 8 panic on boot. 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: Wed, 27 Oct 2010 11:54:54 -0000 On Wednesday, October 27, 2010 7:20:07 am Andriy Gapon wrote: > The following reply was made to PR bin/151616; it has been noted by GNATS. >=20 > From: Andriy Gapon > To: =3D?UTF-8?B?IkRhbWlhbiBTLiBLb8WCb2R6aWVqY3p5ayI=3D?=3D > Cc: bug-followup@FreeBSD.org > Subject: Re: bin/151616: [acpi]: FreeBSD 8 panic on boot. > Date: Wed, 27 Oct 2010 14:10:52 +0300 >=20 > on 27/10/2010 13:40 Damian S. Ko=C5=82odziejczyk said the following: > > Here is verbose boot: > > http://img43.imageshack.us/img43/225/zdjcie030g.jpg > =20 > Would it be possible to scroll up and take the pictures of all the messa= ges since > the start of boot ? > Thank you. Actually, it seems that apic_alloc_vector() is what is failing. Can you do 'show apic' in DDB and capture that output via your camera? =2D-=20 John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Wed Oct 27 12:29:52 2010 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 5BCD1106566C for ; Wed, 27 Oct 2010 12:29:52 +0000 (UTC) (envelope-from takawata@init-main.com) Received: from sana.init-main.com (unknown [IPv6:2001:240:28::1]) by mx1.freebsd.org (Postfix) with ESMTP id B43278FC23 for ; Wed, 27 Oct 2010 12:29:51 +0000 (UTC) Received: from ns.init-main.com (localhost [127.0.0.1]) by sana.init-main.com (8.14.3/8.14.3) with ESMTP id o9RCLoWm095086 for ; Wed, 27 Oct 2010 21:21:50 +0900 (JST) (envelope-from takawata@ns.init-main.com) Message-Id: <201010271221.o9RCLoWm095086@sana.init-main.com> To: freebsd-acpi@FreeBSD.org In-reply-to: Your message of "Wed, 27 Oct 2010 10:56:26 +0300." <4CC7DB2A.2090601@FreeBSD.org> Date: Wed, 27 Oct 2010 21:21:50 +0900 From: Takanori Watanabe Cc: Subject: Re: Event based scheduling and USB. 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: Wed, 27 Oct 2010 12:29:52 -0000 In message <4CC7DB2A.2090601@FreeBSD.org>, Alexander Motin wrote: >Takanori Watanabe wrote: >> In message <4CC732C7.50409@FreeBSD.org>, Alexander Motin wrote: >>> Most likely you should be able to avoid interrupt sharing using some >>> additional HPET options, described at hpet(4). >> >> Try to disable using shared IRQ with uhci, the IRQ used by HPET become cpu: >> interrupt and certainly load average goes quite low, > >If you mean "cpuX:timer" - then probably you did something wrong and >system fallen back to LAPIC timer. Hmm, I restrict the HPET IRQ by setting hint.hpet.X.allowed_irqs kenv value to 0xff000000 to avoid using shared IRQ (IRQ20). From owner-freebsd-acpi@FreeBSD.ORG Wed Oct 27 14:58:59 2010 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 788D1106564A for ; Wed, 27 Oct 2010 14:58:59 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 489C68FC12 for ; Wed, 27 Oct 2010 14:58:59 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id E891E46B03; Wed, 27 Oct 2010 10:58:58 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 9E5D08A009; Wed, 27 Oct 2010 10:58:57 -0400 (EDT) From: John Baldwin To: freebsd-acpi@freebsd.org, "Damian S. =?utf-8?q?Ko=C5=82odziejczyk?=" Date: Wed, 27 Oct 2010 10:58:56 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <201010271150.o9RBo9x6091392@freefall.freebsd.org> In-Reply-To: <201010271150.o9RBo9x6091392@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201010271058.56771.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 27 Oct 2010 10:58:57 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-0.3 required=4.2 tests=BAYES_00,URIBL_SBL autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Subject: Re: bin/151616: [acpi]: FreeBSD 8 panic on boot. 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: Wed, 27 Oct 2010 14:58:59 -0000 On Wednesday, October 27, 2010 7:50:09 am Damian S. Ko=C5=82odziejczyk wrot= e: > The following reply was made to PR bin/151616; it has been noted by GNATS. >=20 > From: =3D?ISO-8859-2?Q?Damian_S=3D2E_Ko=3DB3odziejczyk?=3D > To: bug-followup@FreeBSD.org, damkol@gmail.com > Cc: =20 > Subject: Re: bin/151616: [acpi]: FreeBSD 8 panic on boot. > Date: Wed, 27 Oct 2010 13:42:30 +0200 >=20 > W dniu 27 pa=3DBCdziernika 2010 13:10 u=3DBFytkownik Andriy Gapon > napisa=3DB3: > > Would it be possible to scroll up and take the pictures of all the=20 messag=3D > es since > > the start of boot ? > =20 > No problem: > http://img28.imageshack.us/i/zdjcie031i.jpg/ > http://img839.imageshack.us/i/zdjcie032b.jpg/ > http://img163.imageshack.us/i/zdjcie033e.jpg/ > http://img185.imageshack.us/i/zdjcie034l.jpg/ > =20 > Next one is http://img43.imageshack.us/img43/225/zdjcie030g.jpg Can you try this patch: Index: amd64/amd64/intr_machdep.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =2D-- amd64/amd64/intr_machdep.c (revision 214386) +++ amd64/amd64/intr_machdep.c (working copy) @@ -458,7 +458,7 @@ =20 /* Leave all interrupts on the BSP during boot. */ if (!assign_cpu) =2D return (cpu_apic_ids[0]); + return (PCPU_GET(apic_id)); =20 mtx_lock_spin(&icu_lock); apic_id =3D cpu_apic_ids[current_cpu]; Index: i386/i386/intr_machdep.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =2D-- i386/i386/intr_machdep.c (revision 214386) +++ i386/i386/intr_machdep.c (working copy) @@ -424,7 +424,7 @@ =20 /* Leave all interrupts on the BSP during boot. */ if (!assign_cpu) =2D return (cpu_apic_ids[0]); + return (PCPU_GET(apic_id)); =20 mtx_lock_spin(&icu_lock); apic_id =3D cpu_apic_ids[current_cpu]; =2D-=20 John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Thu Oct 28 10:30:16 2010 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 00FE3106564A for ; Thu, 28 Oct 2010 10:30:16 +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 C7FA98FC08 for ; Thu, 28 Oct 2010 10:30:15 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o9SAUFlH029919 for ; Thu, 28 Oct 2010 10:30:15 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o9SAUFnm029911; Thu, 28 Oct 2010 10:30:15 GMT (envelope-from gnats) Date: Thu, 28 Oct 2010 10:30:15 GMT Message-Id: <201010281030.o9SAUFnm029911@freefall.freebsd.org> To: freebsd-acpi@FreeBSD.org From: =?ISO-8859-2?Q?Damian_S=2E_Ko=B3odziejczyk?= Cc: Subject: Re: bin/151616: [acpi]: FreeBSD 8 panic on boot. X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?ISO-8859-2?Q?Damian_S=2E_Ko=B3odziejczyk?= List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 10:30:16 -0000 The following reply was made to PR bin/151616; it has been noted by GNATS. From: =?ISO-8859-2?Q?Damian_S=2E_Ko=B3odziejczyk?= To: John Baldwin , damkol@gmail.com, bug-followup@FreeBSD.org, freebsd-acpi@FreeBSD.org Cc: Subject: Re: bin/151616: [acpi]: FreeBSD 8 panic on boot. Date: Thu, 28 Oct 2010 12:29:52 +0200 2010/10/27 John Baldwin : > Can you try this patch: > > Index: amd64/amd64/intr_machdep.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- amd64/amd64/intr_machdep.c =A0(revision 214386) > +++ amd64/amd64/intr_machdep.c =A0(working copy) > @@ -458,7 +458,7 @@ > > =A0 =A0 =A0 =A0/* Leave all interrupts on the BSP during boot. */ > =A0 =A0 =A0 =A0if (!assign_cpu) > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 return (cpu_apic_ids[0]); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return (PCPU_GET(apic_id)); > > =A0 =A0 =A0 =A0mtx_lock_spin(&icu_lock); > =A0 =A0 =A0 =A0apic_id =3D cpu_apic_ids[current_cpu]; > Index: i386/i386/intr_machdep.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- i386/i386/intr_machdep.c =A0 =A0(revision 214386) > +++ i386/i386/intr_machdep.c =A0 =A0(working copy) > @@ -424,7 +424,7 @@ > > =A0 =A0 =A0 =A0/* Leave all interrupts on the BSP during boot. */ > =A0 =A0 =A0 =A0if (!assign_cpu) > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 return (cpu_apic_ids[0]); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return (PCPU_GET(apic_id)); > > =A0 =A0 =A0 =A0mtx_lock_spin(&icu_lock); > =A0 =A0 =A0 =A0apic_id =3D cpu_apic_ids[current_cpu]; > Seems to works fine. Source tree is fresh (today): $FreeBSD: src/sys/i386/i386/intr_machdep.c,v 1.46 2010/07/02 17:22:15 mav E= xp $ Here is photos (i destroy GPT accidentally ;)): http://img232.imageshack.us/i/zdjcie035z.jpg/ http://img266.imageshack.us/i/zdjcie036o.jpg/ http://img214.imageshack.us/i/zdjcie037x.jpg/ http://img233.imageshack.us/i/zdjcie038io.jpg/ http://img169.imageshack.us/i/zdjcie039l.jpg/ http://img576.imageshack.us/i/zdjcie040.jpg/ http://img19.imageshack.us/i/zdjcie041qp.jpg/ http://img163.imageshack.us/i/zdjcie042f.jpg/ http://img713.imageshack.us/i/zdjcie043o.jpg/ http://img828.imageshack.us/i/zdjcie044q.jpg/ http://img153.imageshack.us/i/zdjcie045j.jpg/ http://img101.imageshack.us/i/zdjcie046r.jpg/ http://img641.imageshack.us/i/zdjcie047n.jpg/ http://img12.imageshack.us/i/zdjcie048h.jpg/ http://img233.imageshack.us/i/zdjcie049a.jpg/ http://img207.imageshack.us/i/zdjcie050n.jpg/ http://img824.imageshack.us/i/zdjcie051r.jpg/ http://img21.imageshack.us/i/zdjcie052ss.jpg/ http://img594.imageshack.us/i/zdjcie053.jpg/ Can i patch 8.1-R source tree? --=20 Damian From owner-freebsd-acpi@FreeBSD.ORG Thu Oct 28 10:52:20 2010 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 A86F9106566B for ; Thu, 28 Oct 2010 10:52:20 +0000 (UTC) (envelope-from damkol@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 624038FC13 for ; Thu, 28 Oct 2010 10:52:20 +0000 (UTC) Received: by qwe4 with SMTP id 4so1779780qwe.13 for ; Thu, 28 Oct 2010 03:52:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=P2NqObNtinv3I6oRuRYDKpT7OmlG+6fugAqWzJx5WYg=; b=m/POaHVQzyikp9Y35WLqFq3azcEoixtmnPue8GrMnv0cVA+5uaLt7VLQdH9omcfMLg h0R1eXefuckKrY95XMovdG4NfZffOtMjXM/XHNeq3OqyXiDzWvquAQLT7IaSVGslIk8z TsjPjyuTqc5XpVNII4WQsv27RpOhG7PTQ/xQ0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=haco6dt1vlqo3ynbHabFGxpUgLquujkCLitGPkrStinocdDmSIc27LP1phkNoTvQH5 biTMunizw4oBhhbizDZUD/bOcUqm3DuTFYcVq6UCp8DO1fpOXnFMhTrxk/aQTH8KFQO5 wxo4WfcFcztyrt75FmOgr5eN/X2FmU+NLYEtU= MIME-Version: 1.0 Received: by 10.229.95.212 with SMTP id e20mr4868321qcn.20.1288261792603; Thu, 28 Oct 2010 03:29:52 -0700 (PDT) Received: by 10.229.92.8 with HTTP; Thu, 28 Oct 2010 03:29:52 -0700 (PDT) In-Reply-To: <201010271058.56771.jhb@freebsd.org> References: <201010271150.o9RBo9x6091392@freefall.freebsd.org> <201010271058.56771.jhb@freebsd.org> Date: Thu, 28 Oct 2010 12:29:52 +0200 Message-ID: From: =?ISO-8859-2?Q?Damian_S=2E_Ko=B3odziejczyk?= To: John Baldwin , damkol@gmail.com, bug-followup@FreeBSD.org, freebsd-acpi@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: bin/151616: [acpi]: FreeBSD 8 panic on boot. 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, 28 Oct 2010 10:52:20 -0000 2010/10/27 John Baldwin : > Can you try this patch: > > Index: amd64/amd64/intr_machdep.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- amd64/amd64/intr_machdep.c =A0(revision 214386) > +++ amd64/amd64/intr_machdep.c =A0(working copy) > @@ -458,7 +458,7 @@ > > =A0 =A0 =A0 =A0/* Leave all interrupts on the BSP during boot. */ > =A0 =A0 =A0 =A0if (!assign_cpu) > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 return (cpu_apic_ids[0]); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return (PCPU_GET(apic_id)); > > =A0 =A0 =A0 =A0mtx_lock_spin(&icu_lock); > =A0 =A0 =A0 =A0apic_id =3D cpu_apic_ids[current_cpu]; > Index: i386/i386/intr_machdep.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- i386/i386/intr_machdep.c =A0 =A0(revision 214386) > +++ i386/i386/intr_machdep.c =A0 =A0(working copy) > @@ -424,7 +424,7 @@ > > =A0 =A0 =A0 =A0/* Leave all interrupts on the BSP during boot. */ > =A0 =A0 =A0 =A0if (!assign_cpu) > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 return (cpu_apic_ids[0]); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return (PCPU_GET(apic_id)); > > =A0 =A0 =A0 =A0mtx_lock_spin(&icu_lock); > =A0 =A0 =A0 =A0apic_id =3D cpu_apic_ids[current_cpu]; > Seems to works fine. Source tree is fresh (today): $FreeBSD: src/sys/i386/i386/intr_machdep.c,v 1.46 2010/07/02 17:22:15 mav E= xp $ Here is photos (i destroy GPT accidentally ;)): http://img232.imageshack.us/i/zdjcie035z.jpg/ http://img266.imageshack.us/i/zdjcie036o.jpg/ http://img214.imageshack.us/i/zdjcie037x.jpg/ http://img233.imageshack.us/i/zdjcie038io.jpg/ http://img169.imageshack.us/i/zdjcie039l.jpg/ http://img576.imageshack.us/i/zdjcie040.jpg/ http://img19.imageshack.us/i/zdjcie041qp.jpg/ http://img163.imageshack.us/i/zdjcie042f.jpg/ http://img713.imageshack.us/i/zdjcie043o.jpg/ http://img828.imageshack.us/i/zdjcie044q.jpg/ http://img153.imageshack.us/i/zdjcie045j.jpg/ http://img101.imageshack.us/i/zdjcie046r.jpg/ http://img641.imageshack.us/i/zdjcie047n.jpg/ http://img12.imageshack.us/i/zdjcie048h.jpg/ http://img233.imageshack.us/i/zdjcie049a.jpg/ http://img207.imageshack.us/i/zdjcie050n.jpg/ http://img824.imageshack.us/i/zdjcie051r.jpg/ http://img21.imageshack.us/i/zdjcie052ss.jpg/ http://img594.imageshack.us/i/zdjcie053.jpg/ Can i patch 8.1-R source tree? --=20 Damian From owner-freebsd-acpi@FreeBSD.ORG Thu Oct 28 12:00:27 2010 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 1DFD010656A3 for ; Thu, 28 Oct 2010 12:00:27 +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 E74538FC0A for ; Thu, 28 Oct 2010 12:00:26 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o9SC0QRE023649 for ; Thu, 28 Oct 2010 12:00:26 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o9SC0Qgb023627; Thu, 28 Oct 2010 12:00:26 GMT (envelope-from gnats) Date: Thu, 28 Oct 2010 12:00:26 GMT Message-Id: <201010281200.o9SC0Qgb023627@freefall.freebsd.org> To: freebsd-acpi@FreeBSD.org From: Andriy Gapon Cc: Subject: Re: bin/151616: [acpi]: FreeBSD 8 panic on boot. X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andriy Gapon List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 12:00:27 -0000 The following reply was made to PR bin/151616; it has been noted by GNATS. From: Andriy Gapon To: =?UTF-8?B?IkRhbWlhbiBTLiBLb8WCb2R6aWVqY3p5ayI=?= Cc: John Baldwin , bug-followup@freebsd.org Subject: Re: bin/151616: [acpi]: FreeBSD 8 panic on boot. Date: Thu, 28 Oct 2010 14:53:31 +0300 on 28/10/2010 13:29 Damian S. Kołodziejczyk said the following: > Seems to works fine. > Source tree is fresh (today): > $FreeBSD: src/sys/i386/i386/intr_machdep.c,v 1.46 2010/07/02 17:22:15 mav Exp $ > > Here is photos (i destroy GPT accidentally ;)): > http://img232.imageshack.us/i/zdjcie035z.jpg/ > http://img266.imageshack.us/i/zdjcie036o.jpg/ > http://img214.imageshack.us/i/zdjcie037x.jpg/ > http://img233.imageshack.us/i/zdjcie038io.jpg/ > http://img169.imageshack.us/i/zdjcie039l.jpg/ > http://img576.imageshack.us/i/zdjcie040.jpg/ > http://img19.imageshack.us/i/zdjcie041qp.jpg/ > http://img163.imageshack.us/i/zdjcie042f.jpg/ > http://img713.imageshack.us/i/zdjcie043o.jpg/ > http://img828.imageshack.us/i/zdjcie044q.jpg/ > http://img153.imageshack.us/i/zdjcie045j.jpg/ > http://img101.imageshack.us/i/zdjcie046r.jpg/ > http://img641.imageshack.us/i/zdjcie047n.jpg/ > http://img12.imageshack.us/i/zdjcie048h.jpg/ > http://img233.imageshack.us/i/zdjcie049a.jpg/ > http://img207.imageshack.us/i/zdjcie050n.jpg/ > http://img824.imageshack.us/i/zdjcie051r.jpg/ > http://img21.imageshack.us/i/zdjcie052ss.jpg/ > http://img594.imageshack.us/i/zdjcie053.jpg/ > > Can i patch 8.1-R source tree? Yes, the patch should apply. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Thu Oct 28 13:44:49 2010 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 A32EC1065674; Thu, 28 Oct 2010 13:44:49 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 79E4A8FC12; Thu, 28 Oct 2010 13:44:49 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o9SDinP6038445; Thu, 28 Oct 2010 13:44:49 GMT (envelope-from jhb@freefall.freebsd.org) Received: (from jhb@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o9SDindh038441; Thu, 28 Oct 2010 13:44:49 GMT (envelope-from jhb) Date: Thu, 28 Oct 2010 13:44:49 GMT Message-Id: <201010281344.o9SDindh038441@freefall.freebsd.org> To: damkol@gmail.com, jhb@FreeBSD.org, freebsd-acpi@FreeBSD.org, jhb@FreeBSD.org From: jhb@FreeBSD.org Cc: Subject: Re: bin/151616: [acpi]: FreeBSD 8 panic on boot. 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, 28 Oct 2010 13:44:49 -0000 Synopsis: [acpi]: FreeBSD 8 panic on boot. State-Changed-From-To: open->patched State-Changed-By: jhb State-Changed-When: Thu Oct 28 13:44:29 UTC 2010 State-Changed-Why: Fix committed to HEAD. Will merge to 8 in a week or so. Responsible-Changed-From-To: freebsd-acpi->jhb Responsible-Changed-By: jhb Responsible-Changed-When: Thu Oct 28 13:44:29 UTC 2010 Responsible-Changed-Why: Fix committed to HEAD. Will merge to 8 in a week or so. http://www.freebsd.org/cgi/query-pr.cgi?pr=151616 From owner-freebsd-acpi@FreeBSD.ORG Thu Oct 28 16:54:44 2010 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 9E43C106566C; Thu, 28 Oct 2010 16:54:44 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 70A2B8FC15; Thu, 28 Oct 2010 16:54:44 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 0948846B1A; Thu, 28 Oct 2010 12:54:44 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 114E68A01D; Thu, 28 Oct 2010 12:54:43 -0400 (EDT) From: John Baldwin To: arch@freebsd.org Date: Thu, 28 Oct 2010 12:54:39 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201010281254.39862.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 28 Oct 2010 12:54:43 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=0.7 required=4.2 tests=BAYES_00,TO_NO_BRKTS_DIRECT autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: acpi@freebsd.org Subject: Removing acpi.ko support 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, 28 Oct 2010 16:54:44 -0000 [ cc'ing acpi@ to be safe, but I think the topic warrants the wider audience of arch@ ] I think we should drop support for having acpi load as a module for i386. It adds extra complication and hacks to the i386 APIC and interrupt code that are gratuitously different from amd64 as a result. Originally it was made a module so that GENERIC on i386 did not include ACPI by default but would only use up memory to hold ACPI-related code if the machine supported ACPI. Now that acpi is part of GENERIC on i386 in 8.0 and later this argument is no longer relevant. I'd like to remove support for ACPI as a module to remove the various hacks on i386 and reduce differences with amd64. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Thu Oct 28 17:31:10 2010 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 8B1B21065693; Thu, 28 Oct 2010 17:31:10 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 4957A8FC1C; Thu, 28 Oct 2010 17:31:09 +0000 (UTC) Received: from [127.0.0.1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.4/8.14.4) with ESMTP id o9SH1OXC035490; Thu, 28 Oct 2010 11:01:24 -0600 (MDT) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Scott Long In-Reply-To: <201010281254.39862.jhb@freebsd.org> Date: Thu, 28 Oct 2010 11:01:24 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <8019DAB7-8276-451D-812D-2C5EAB8F6CB9@samsco.org> References: <201010281254.39862.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1081) X-Spam-Status: No, score=-50.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: acpi@freebsd.org, arch@freebsd.org Subject: Re: Removing acpi.ko support 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, 28 Oct 2010 17:31:10 -0000 On Oct 28, 2010, at 10:54 AM, John Baldwin wrote: > [ cc'ing acpi@ to be safe, but I think the topic warrants the wider = audience=20 > of arch@ ] >=20 > I think we should drop support for having acpi load as a module for = i386. It=20 > adds extra complication and hacks to the i386 APIC and interrupt code = that are=20 > gratuitously different from amd64 as a result. Originally it was made = a=20 > module so that GENERIC on i386 did not include ACPI by default but = would only=20 > use up memory to hold ACPI-related code if the machine supported ACPI. = Now=20 > that acpi is part of GENERIC on i386 in 8.0 and later this argument is = no=20 > longer relevant. I'd like to remove support for ACPI as a module to = remove=20 > the various hacks on i386 and reduce differences with amd64. >=20 Just to be clear, it'll still be an optional kernel device, it just = won't be a KLD anymore, right? If you do that, what will happen with = the evil bootloader code that gropes around for the AML tables and = auto-loads the module? Is there any reason to keep that around for = compatibility? If it goes away, don't forget to also update the = bootforth code that knows how to manipulate it. Scott From owner-freebsd-acpi@FreeBSD.ORG Thu Oct 28 17:48:59 2010 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 A88D01065672 for ; Thu, 28 Oct 2010 17:48:59 +0000 (UTC) (envelope-from nate@root.org) Received: from mail.root.org (root.org [208.72.84.34]) by mx1.freebsd.org (Postfix) with ESMTP id 310878FC15 for ; Thu, 28 Oct 2010 17:48:58 +0000 (UTC) Received: from [10.0.5.50] (ppp-71-139-7-59.dsl.snfc21.pacbell.net [71.139.7.59]) by mail.root.org (Postfix) with ESMTP id B0C276D5C; Thu, 28 Oct 2010 17:48:57 +0000 (UTC) Message-ID: <4CC9B788.3080704@root.org> Date: Thu, 28 Oct 2010 10:48:56 -0700 From: Nate Lawson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: John Baldwin References: <201010281254.39862.jhb@freebsd.org> In-Reply-To: <201010281254.39862.jhb@freebsd.org> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: acpi@freebsd.org, arch@freebsd.org Subject: Re: Removing acpi.ko support 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, 28 Oct 2010 17:48:59 -0000 On 10/28/2010 9:54 AM, John Baldwin wrote: > [ cc'ing acpi@ to be safe, but I think the topic warrants the wider audience > of arch@ ] > > I think we should drop support for having acpi load as a module for i386. It > adds extra complication and hacks to the i386 APIC and interrupt code that are > gratuitously different from amd64 as a result. Originally it was made a > module so that GENERIC on i386 did not include ACPI by default but would only > use up memory to hold ACPI-related code if the machine supported ACPI. Now > that acpi is part of GENERIC on i386 in 8.0 and later this argument is no > longer relevant. I'd like to remove support for ACPI as a module to remove > the various hacks on i386 and reduce differences with amd64. Fine with me. Users will still be able to disable ACPI if they want. And systems that don't have ACPI (pre-2001) can still compile it out with "nodevice" to save a few 100 KB of RAM. There's no reason to keep it as a kernel module. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Thu Oct 28 18:15:51 2010 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 1F6AA1065720; Thu, 28 Oct 2010 18:15:51 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id DF5688FC34; Thu, 28 Oct 2010 18:15:50 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 8056046B35; Thu, 28 Oct 2010 14:15:50 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 7A5C78A027; Thu, 28 Oct 2010 14:15:49 -0400 (EDT) From: John Baldwin To: Scott Long Date: Thu, 28 Oct 2010 14:02:48 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <201010281254.39862.jhb@freebsd.org> <8019DAB7-8276-451D-812D-2C5EAB8F6CB9@samsco.org> In-Reply-To: <8019DAB7-8276-451D-812D-2C5EAB8F6CB9@samsco.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201010281402.48848.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 28 Oct 2010 14:15:49 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: acpi@freebsd.org, arch@freebsd.org Subject: Re: Removing acpi.ko support 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, 28 Oct 2010 18:15:51 -0000 On Thursday, October 28, 2010 1:01:24 pm Scott Long wrote: > On Oct 28, 2010, at 10:54 AM, John Baldwin wrote: > > [ cc'ing acpi@ to be safe, but I think the topic warrants the wider audience > > of arch@ ] > > > > I think we should drop support for having acpi load as a module for i386. It > > adds extra complication and hacks to the i386 APIC and interrupt code that are > > gratuitously different from amd64 as a result. Originally it was made a > > module so that GENERIC on i386 did not include ACPI by default but would only > > use up memory to hold ACPI-related code if the machine supported ACPI. Now > > that acpi is part of GENERIC on i386 in 8.0 and later this argument is no > > longer relevant. I'd like to remove support for ACPI as a module to remove > > the various hacks on i386 and reduce differences with amd64. > > > > Just to be clear, it'll still be an optional kernel device, it just won't be a KLD anymore, right? If you do that, what will happen with the evil bootloader code that gropes around for the AML tables and auto-loads the module? Is there any reason to keep that around for compatibility? If it goes away, don't forget to also update the bootforth code that knows how to manipulate it. It already does the right thing in this case (it did regardless, but that was part of the testing before enabling 'device acpi' in GENERIC for 8.0). If we remove the KLD support then we can now remove that code from the loader and Forth scripts as they will no longer be needed. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Thu Oct 28 18:50:48 2010 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 622541065698; Thu, 28 Oct 2010 18:50:48 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 058B78FC18; Thu, 28 Oct 2010 18:50:47 +0000 (UTC) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by pooker.samsco.org (8.14.4/8.14.4) with ESMTP id o9SIogog036148; Thu, 28 Oct 2010 12:50:42 -0600 (MDT) (envelope-from scottl@samsco.org) Date: Thu, 28 Oct 2010 12:50:42 -0600 (MDT) From: Scott Long To: John Baldwin In-Reply-To: <201010281402.48848.jhb@freebsd.org> Message-ID: References: <201010281254.39862.jhb@freebsd.org> <8019DAB7-8276-451D-812D-2C5EAB8F6CB9@samsco.org> <201010281402.48848.jhb@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-50.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: acpi@freebsd.org, arch@freebsd.org Subject: Re: Removing acpi.ko support 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, 28 Oct 2010 18:50:48 -0000 On Thu, 28 Oct 2010, John Baldwin wrote: > On Thursday, October 28, 2010 1:01:24 pm Scott Long wrote: >> On Oct 28, 2010, at 10:54 AM, John Baldwin wrote: >>> [ cc'ing acpi@ to be safe, but I think the topic warrants the wider audience >>> of arch@ ] >>> >>> I think we should drop support for having acpi load as a module for i386. It >>> adds extra complication and hacks to the i386 APIC and interrupt code that are >>> gratuitously different from amd64 as a result. Originally it was made a >>> module so that GENERIC on i386 did not include ACPI by default but would only >>> use up memory to hold ACPI-related code if the machine supported ACPI. Now >>> that acpi is part of GENERIC on i386 in 8.0 and later this argument is no >>> longer relevant. I'd like to remove support for ACPI as a module to remove >>> the various hacks on i386 and reduce differences with amd64. >>> >> >> Just to be clear, it'll still be an optional kernel device, it just won't be a KLD anymore, right? If you do that, what will happen with the evil > bootloader code that gropes around for the AML tables and auto-loads the module? Is there any reason to keep that around for compatibility? If it > goes away, don't forget to also update the bootforth code that knows how to manipulate it. > > It already does the right thing in this case (it did regardless, but that was > part of the testing before enabling 'device acpi' in GENERIC for 8.0). If > we remove the KLD support then we can now remove that code from the loader > and Forth scripts as they will no longer be needed. > You lost me, what is "the right thing". What I'm asking is whether there will be any surprises to people upgrading from 8.0 to 8.x with regard to the bootloader no longer autoloading acpi.ko, and will there be any surprises to those who update their bootblocks but maybe switch back and forth between old and new kernels? Scott From owner-freebsd-acpi@FreeBSD.ORG Thu Oct 28 19:29:45 2010 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 815CB106566B; Thu, 28 Oct 2010 19:29:45 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 374F78FC14; Thu, 28 Oct 2010 19:29:45 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id B729446B09; Thu, 28 Oct 2010 15:29:44 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A9E678A009; Thu, 28 Oct 2010 15:29:43 -0400 (EDT) From: John Baldwin To: Scott Long Date: Thu, 28 Oct 2010 15:29:03 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <201010281254.39862.jhb@freebsd.org> <201010281402.48848.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201010281529.03379.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 28 Oct 2010 15:29:43 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: acpi@freebsd.org, arch@freebsd.org Subject: Re: Removing acpi.ko support 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, 28 Oct 2010 19:29:45 -0000 On Thursday, October 28, 2010 2:50:42 pm Scott Long wrote: > On Thu, 28 Oct 2010, John Baldwin wrote: > > On Thursday, October 28, 2010 1:01:24 pm Scott Long wrote: > >> On Oct 28, 2010, at 10:54 AM, John Baldwin wrote: > >>> [ cc'ing acpi@ to be safe, but I think the topic warrants the wider audience > >>> of arch@ ] > >>> > >>> I think we should drop support for having acpi load as a module for i386. It > >>> adds extra complication and hacks to the i386 APIC and interrupt code that are > >>> gratuitously different from amd64 as a result. Originally it was made a > >>> module so that GENERIC on i386 did not include ACPI by default but would only > >>> use up memory to hold ACPI-related code if the machine supported ACPI. Now > >>> that acpi is part of GENERIC on i386 in 8.0 and later this argument is no > >>> longer relevant. I'd like to remove support for ACPI as a module to remove > >>> the various hacks on i386 and reduce differences with amd64. > >>> > >> > >> Just to be clear, it'll still be an optional kernel device, it just won't be a KLD anymore, right? If you do that, what will happen with the evil > > bootloader code that gropes around for the AML tables and auto-loads the module? Is there any reason to keep that around for compatibility? If it > > goes away, don't forget to also update the bootforth code that knows how to manipulate it. > > > > It already does the right thing in this case (it did regardless, but that was > > part of the testing before enabling 'device acpi' in GENERIC for 8.0). If > > we remove the KLD support then we can now remove that code from the loader > > and Forth scripts as they will no longer be needed. > > > > You lost me, what is "the right thing". What I'm asking is whether there > will be any surprises to people upgrading from 8.0 to 8.x with regard to > the bootloader no longer autoloading acpi.ko, and will there be any > surprises to those who update their bootblocks but maybe switch back and > forth between old and new kernels? The loader code just sets 'acpi_load=YES'. If acpi is compiled into the kernel or it is not present it just silently fails. This was already considered and tested during the 8.0 release cycle. I am only proposing making this change for 9, FYI, not to MFC it. If we were to remove the code from the loader that sets acpi_load in 9 and someone booted an 8.x or 7.x kernel that did not include 'device acpi', then acpi.ko would not be autoloaded. We could easily leave the code in the loader around until 10.0 so there is one release branch worth of compatibility, though the fact that GENERIC i386 in 8 ships with acpi compiled in and not a module on i386 is probably already giving us a release branch of compatibility as it is. That is, a GENERIC 8.0 i386 kernel would work fine with a loader that removed the ACPI bits, only a 7.x GENERIC kernel would fail to autoload acpi.ko with a modified loader. Given that we don't generally support 7.x -> 9.0 upgrades, I really think it would be ok to remove the loader support from 9. However, what I really care about are the kernel changes, not the loader changes. The loader changes could wait until 10 if really necessary. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Thu Oct 28 19:44:49 2010 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 C1EC2106566C; Thu, 28 Oct 2010 19:44:49 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 785848FC14; Thu, 28 Oct 2010 19:44:49 +0000 (UTC) Received: from [10.70.143.238] (166-205-014-036.mobile.mymmode.com [166.205.14.36] (may be forged)) (authenticated bits=0) by pooker.samsco.org (8.14.4/8.14.4) with ESMTP id o9SJidYq036520; Thu, 28 Oct 2010 13:44:45 -0600 (MDT) (envelope-from scottl@samsco.org) References: <201010281254.39862.jhb@freebsd.org> <201010281402.48848.jhb@freebsd.org> <201010281529.03379.jhb@freebsd.org> In-Reply-To: <201010281529.03379.jhb@freebsd.org> Mime-Version: 1.0 (iPhone Mail 8B117) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (8B117) From: Scott Long Date: Thu, 28 Oct 2010 13:44:16 -0600 To: John Baldwin X-Spam-Status: No, score=1.9 required=3.8 tests=MAY_BE_FORGED, MIME_QP_LONG_LINE, RCVD_IN_RP_RNBL, RDNS_DYNAMIC autolearn=no version=3.3.0 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: "acpi@freebsd.org" , "arch@freebsd.org" Subject: Re: Removing acpi.ko support 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, 28 Oct 2010 19:44:49 -0000 On Oct 28, 2010, at 1:29 PM, John Baldwin wrote: > On Thursday, October 28, 2010 2:50:42 pm Scott Long wrote: >> On Thu, 28 Oct 2010, John Baldwin wrote: >>> On Thursday, October 28, 2010 1:01:24 pm Scott Long wrote: >>>> On Oct 28, 2010, at 10:54 AM, John Baldwin wrote: >>>>> [ cc'ing acpi@ to be safe, but I think the topic warrants the wider au= dience >>>>> of arch@ ] >>>>>=20 >>>>> I think we should drop support for having acpi load as a module for i3= 86. It >>>>> adds extra complication and hacks to the i386 APIC and interrupt code t= hat are >>>>> gratuitously different from amd64 as a result. Originally it was made= a >>>>> module so that GENERIC on i386 did not include ACPI by default but wou= ld only >>>>> use up memory to hold ACPI-related code if the machine supported ACPI.= Now >>>>> that acpi is part of GENERIC on i386 in 8.0 and later this argument is= no >>>>> longer relevant. I'd like to remove support for ACPI as a module to r= emove >>>>> the various hacks on i386 and reduce differences with amd64. >>>>>=20 >>>>=20 >>>> Just to be clear, it'll still be an optional kernel device, it just won= 't be a KLD anymore, right? If you do that, what will happen with the=20 > evil >>> bootloader code that gropes around for the AML tables and auto-loads the= module? Is there any reason to keep that around for compatibility? =20 > If it >>> goes away, don't forget to also update the bootforth code that knows how= to manipulate it. >>>=20 >>> It already does the right thing in this case (it did regardless, but tha= t was >>> part of the testing before enabling 'device acpi' in GENERIC for 8.0). I= f >>> we remove the KLD support then we can now remove that code from the load= er >>> and Forth scripts as they will no longer be needed. >>>=20 >>=20 >> You lost me, what is "the right thing". What I'm asking is whether there= =20 >> will be any surprises to people upgrading from 8.0 to 8.x with regard to=20= >> the bootloader no longer autoloading acpi.ko, and will there be any=20 >> surprises to those who update their bootblocks but maybe switch back and=20= >> forth between old and new kernels? >=20 > The loader code just sets 'acpi_load=3DYES'. If acpi is compiled into the= > kernel or it is not present it just silently fails. This was already > considered and tested during the 8.0 release cycle. >=20 > I am only proposing making this change for 9, FYI, not to MFC it. If we > were to remove the code from the loader that sets acpi_load in 9 and someo= ne > booted an 8.x or 7.x kernel that did not include 'device acpi', then acpi.= ko > would not be autoloaded. We could easily leave the code in the loader aro= und > until 10.0 so there is one release branch worth of compatibility, though t= he > fact that GENERIC i386 in 8 ships with acpi compiled in and not a module o= n > i386 is probably already giving us a release branch of compatibility as it= is. >=20 I agree. > That is, a GENERIC 8.0 i386 kernel would work fine with a loader that remo= ved > the ACPI bits, only a 7.x GENERIC kernel would fail to autoload acpi.ko wi= th a > modified loader. Given that we don't generally support 7.x -> 9.0 upgrade= s, I > really think it would be ok to remove the loader support from 9. >=20 > However, what I really care about are the kernel changes, not the loader c= hanges. > The loader changes could wait until 10 if really necessary. >=20 >=20 Sounds like a good plan. I don't think that's there any reason to wait for 1= 0.0 Scott= From owner-freebsd-acpi@FreeBSD.ORG Fri Oct 29 00:34:18 2010 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 432D0106566B for ; Fri, 29 Oct 2010 00:34:18 +0000 (UTC) (envelope-from ming.m.lin@intel.com) Received: from mga03.intel.com (mga03.intel.com [143.182.124.21]) by mx1.freebsd.org (Postfix) with ESMTP id EBC028FC12 for ; Fri, 29 Oct 2010 00:34:17 +0000 (UTC) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101.ch.intel.com with ESMTP; 28 Oct 2010 17:34:17 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.58,255,1286175600"; d="scan'208";a="341898498" Received: from minggr.sh.intel.com (HELO [10.239.13.26]) ([10.239.13.26]) by azsmga001.ch.intel.com with ESMTP; 28 Oct 2010 17:34:15 -0700 From: Lin Ming To: Hans Petter Selasky , Andriy Gapon , Jung-uk Kim In-Reply-To: <201010281810.23668.hselasky@c2i.net> References: <201010121209.06397.hselasky@c2i.net> <1288278300.2459.19.camel@localhost> <1288279472.2459.22.camel@localhost> <201010281810.23668.hselasky@c2i.net> Content-Type: multipart/mixed; boundary="=-sZDwWjjHlziOoEmF+86n" Date: Fri, 29 Oct 2010 08:34:36 +0800 Message-ID: <1288312476.13315.15.camel@minggr.sh.intel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.30.2 Cc: freebsd-acpi@freebsd.org, "Moore, Robert" Subject: Re: MacBookPro 5,1 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, 29 Oct 2010 00:34:18 -0000 --=-sZDwWjjHlziOoEmF+86n Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Fri, 2010-10-29 at 00:10 +0800, Hans Petter Selasky wrote: > On Thursday 28 October 2010 17:24:32 Lin Ming wrote: > > On Thu, 2010-10-28 at 23:05 +0800, Lin Ming wrote: > > > On Thu, 2010-10-28 at 22:55 +0800, Hans Petter Selasky wrote: > > > > On Thursday 28 October 2010 16:44:55 Lin Ming wrote: > > > > > On Thu, 2010-10-28 at 22:40 +0800, Hans Petter Selasky wrote: > > > > > > I make two kernel builds, one with the following patch, and one > > > > > > without. > > > > > > > > > > > > > > > > > > > > > Did you get the information you needed? Or do I need to send the > > > > > > complete dmesg? > > > > > > > > > > Yes, please send both dmesgs (with and without the patch) > > > > > > > > > > Thanks. > > > > > > > > > > > --HPS > > > > > > DEBUG: Aml=0xffffff00031f9000, EndAml=0xffffff00031f900d, > > > AmlSizeNeeded=13 DEBUG: Aml=0xffffff00031f9000, MinimumLength=9, > > > AmlResourceSource=0xffffff00031f9009 DEBUG: string length=16 > > > > > > AmlSizeNeeded=13, but string length=16, there is something pretty wrong. > > > > > > Thanks for the info. > > > I'm checking... > > > > I find the evil, the resource buffer passed in by driver is wrong. > > > > Would you please try below patch? > > Just apply below patch, no kernel boot acpi options and no other > > patches. > > > > diff --git a/source/components/resources/rscalc.c > > b/source/components/resources/rscalc.c index 3215c9e..e68b5af 100644 > > --- a/source/components/resources/rscalc.c > > +++ b/source/components/resources/rscalc.c > > @@ -203,7 +203,13 @@ AcpiRsStructOptionLength ( > > */ > > if (ResourceSource->StringPtr) > > { > > - return ((ACPI_RS_LENGTH) (ResourceSource->StringLength + 1)); > > + if (ACPI_STRLEN (ResourceSource->StringPtr) + 1 != > > ResourceSource->StringLength) + { > > + AcpiOsPrintf("Bug: the passed in resource buffer is wrong, > > ResourceSource->StringLength=%d, " + "but the real string > > length is %d\n", > > + ResourceSource->StringLength, ACPI_STRLEN > > (ResourceSource->StringPtr) + 1); + } > > + return ((ACPI_RS_LENGTH) ((ACPI_STRLEN (ResourceSource->StringPtr) > > + 1) + 1)); } > > > > return (0); > > > > > Lin Ming > > That seems to have done the trick! There are some additional debug prints from > some other sub-systems which you can ignore. > > 1) copied fresh ACPICA sources from kernel tree. > 2) compiled with your patch. > 3) Resulting dmesg is attached. Hi, guys Hans and I have found the root cause of this bug. The ResourceSource->StringLength set by up layer driver is wrong, see the patch below. Below patch fixes the bug and on Hans' machine it prints, Bug: the passed in resource buffer is wrong, Resource->StringLength=1, but the real string length is 10 Bug: the passed in resource buffer is wrong, Resource->StringLength=1, but the real string length is 10 Bug: the passed in resource buffer is wrong, Resource->StringLength=1, but the real string length is 10 Bug: the passed in resource buffer is wrong, Resource->StringLength=1, but the real string length is 8 Bug: the passed in resource buffer is wrong, Resource->StringLength=1, but the real string length is 10 Bug: the passed in resource buffer is wrong, Resource->StringLength=1, but the real string length is 10 Bug: the passed in resource buffer is wrong, Resource->StringLength=1, but the real string length is 10 Bug: the passed in resource buffer is wrong, Resource->StringLength=1, but the real string length is 10 Bug: the passed in resource buffer is wrong, Resource->StringLength=1, but the real string length is 10 The full dmesg also attached. Kim, Could you write a fix in up layer code(seems in acpi_pci_link_route_irqs)? Thanks. diff --git a/source/components/resources/rscalc.c b/source/components/resources/rscalc.c index 3215c9e..e68b5af 100644 --- a/source/components/resources/rscalc.c +++ b/source/components/resources/rscalc.c @@ -203,7 +203,13 @@ AcpiRsStructOptionLength ( */ if (ResourceSource->StringPtr) { - return ((ACPI_RS_LENGTH) (ResourceSource->StringLength + 1)); + if (ACPI_STRLEN (ResourceSource->StringPtr) + 1 != ResourceSource->StringLength) + { + AcpiOsPrintf("Bug: the passed in resource buffer is wrong, ResourceSource->StringLength=%d, " + "but the real string length is %d\n", + ResourceSource->StringLength, ACPI_STRLEN (ResourceSource->StringPtr) + 1); + } + return ((ACPI_RS_LENGTH) ((ACPI_STRLEN (ResourceSource->StringPtr) + 1) + 1)); } return (0); --=-sZDwWjjHlziOoEmF+86n Content-Disposition: attachment; filename="dmesg.freebsd" Content-Type: text/plain; name="dmesg.freebsd"; charset="UTF-8" Content-Transfer-Encoding: 7bit Copyright (c) 1992-2010 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 9.0-CURRENT #88: Thu Oct 28 18:05:11 CEST 2010 root@hpsbook:/usr/obj/usr/src/sys/GENERIC amd64 WARNING: WITNESS option enabled, expect reduced performance. MEMGUARD DEBUGGING ALLOCATOR INITIALIZED: MEMGUARD map base: 0xffffff8000200000 MEMGUARD map limit: 0xffffff8003a99000 MEMGUARD map size: 59346944 (Bytes) CPU: Intel(R) Core(TM)2 Duo CPU P7550 @ 2.26GHz (2255.39-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x1067a Family = 6 Model = 17 Stepping = 10 Features=0xbfebfbff Features2=0x408e3bd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant real memory = 2147483648 (2048 MB) avail memory = 1768013824 (1686 MB) Event timer "LAPIC" frequency 0 Hz quality 500 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 ioapic0: Changing APIC ID to 1 ioapic0 irqs 0-23 on motherboard Cuse4BSD v0.1.13 @ /dev/cuse kbd0 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi_ec0: port 0x62,0x66 on acpi0 acpi0: Power Button (fixed) unknown: I/O range not supported acpi_hpet0: iomem 0xfed00000-0xfed003ff irq 0,8 on acpi0 Timecounter "HPET" frequency 25000000 Hz quality 900 Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 cpu0: on acpi0 cpu1: on acpi0 acpi_acad0: on acpi0 acpi_lid0: on acpi0 acpi_lid0: enable wake failed acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: on acpi0 pci0: on pcib0 Bug: the passed in resource buffer is wrong, Resource->StringLength=1, but the real string length is 10 Bug: the passed in resource buffer is wrong, Resource->StringLength=1, but the real string length is 10 Bug: the passed in resource buffer is wrong, Resource->StringLength=1, but the real string length is 10 Bug: the passed in resource buffer is wrong, Resource->StringLength=1, but the real string length is 8 Bug: the passed in resource buffer is wrong, Resource->StringLength=1, but the real string length is 10 Bug: the passed in resource buffer is wrong, Resource->StringLength=1, but the real string length is 10 Bug: the passed in resource buffer is wrong, Resource->StringLength=1, but the real string length is 10 Bug: the passed in resource buffer is wrong, Resource->StringLength=1, but the real string length is 10 Bug: the passed in resource buffer is wrong, Resource->StringLength=1, but the real string length is 10 (null) from acpi0(null) from acpi0(null) from acpi0(null) from acpi0(null) from acpi0(null) from acpi0(null) from acpi0(null) from acpi0(null) from acpi0(null) from acpi0(null) from acpi0(null) from acpi0(null) from acpi0(null) from acpi0(null) from acpi0(null) from acpi0(null) from acpi0(null) from acpi0pci0: at device 0.1 (no driver attached) isab0: port 0x2000-0x20ff at device 3.0 on pci0 isa0: on isab0 pci0: at device 3.1 (no driver attached) pci0: at device 3.2 (no driver attached) pci0: at device 3.3 (no driver attached) pci0: at device 3.4 (no driver attached) pci0: at device 3.5 (no driver attached) ohci0: mem 0x93488000-0x93488fff irq 18 at device 4.0 on pci0 ohci0: [ITHREAD] usbus0: on ohci0 ehci0: mem 0x93489200-0x934892ff irq 19 at device 4.1 on pci0 ehci0: [ITHREAD] usbus1: EHCI version 1.0 usbus1: on ehci0 ohci1: mem 0x93487000-0x93487fff irq 20 at device 6.0 on pci0 ohci1: [ITHREAD] usbus2: on ohci1 ehci1: mem 0x93489100-0x934891ff irq 21 at device 6.1 on pci0 ehci1: [ITHREAD] usbus3: EHCI version 1.0 usbus3: on ehci1 hdac0: mem 0x93480000-0x93483fff irq 22 at device 8.0 on pci0 hdac0: HDA Driver Revision: 20100226_0142 hdac0: [ITHREAD] pcib1: at device 9.0 on pci0 pci1: on pcib1 nfe0: port 0x21e0-0x21e7 mem 0x93486000-0x93486fff,0x93489000-0x934890ff,0x93489300-0x9348930f irq 23 at device 10.0 on pci0 miibus0: on nfe0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto nfe0: Ethernet address: 00:25:4b:cd:5a:7e nfe0: [FILTER] atapci0: port 0x21d8-0x21df,0x21ec-0x21ef,0x21d0-0x21d7,0x21e8-0x21eb,0x21c0-0x21cf mem 0x93484000-0x93485fff irq 16 at device 11.0 on pci0 atapci0: [ITHREAD] atapci0: AHCI v1.20 controller with 6 3Gbps ports, PM supported ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] pcib2: at device 16.0 on pci0 pci2: on pcib2 Bug: the passed in resource buffer is wrong, Resource->StringLength=1, but the real string length is 8 (null) from acpi0vgapci0: port 0x1000-0x107f mem 0x92000000-0x92ffffff,0x80000000-0x8fffffff,0x90000000-0x91ffffff irq 17 at device 0.0 on pci2 pcib3: at device 21.0 on pci0 pci3: on pcib3 Bug: the passed in resource buffer is wrong, Resource->StringLength=1, but the real string length is 8 (null) from acpi0pci3: at device 0.0 (no driver attached) pcib4: at device 22.0 on pci0 pci4: on pcib4 Bug: the passed in resource buffer is wrong, Resource->StringLength=1, but the real string length is 10 (null) from acpi0fwohci0: <1394 Open Host Controller Interface> mem 0x93100000-0x93100fff irq 19 at device 0.0 on pci4 fwohci0: [ITHREAD] fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channels is 8. fwohci0: EUI64 00:25:4b:ff:fe:cd:5a:7e fwohci0: invalid speed 7 (fixed to 3). fwohci0: Phy 1394a available S800, 3 ports. fwohci0: Link S800, max_rec 4096 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:25:4b:cd:5a:7e fwe0: Ethernet address: 02:25:4b:cd:5a:7e fwip0: on firewire0 fwip0: Firewire address: 00:25:4b:ff:fe:cd:5a:7e @ 0xfffe00000000, S800, maxrec 4096 sbp0: on firewire0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x11f4000 fwohci0: Initiate bus reset fwohci0: fwohci_intr_core: BUS reset fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID Count=2, CYCLEMASTER mode battery0: on acpi0 atrtc0: port 0x70-0x77 on acpi0 RTC BIOS diagnostic error f3 atrtc0: [FILTER] Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 attimer0: [FILTER] Event timer "i8254" frequency 1193182 Hz quality 100 orm0: at iomem 0xc0000-0xce7ff 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 ppc0: cannot reserve I/O port range est0: on cpu0 p4tcc0: on cpu0 est1: on cpu1 p4tcc1: on cpu1 Starting kernel event timers: LAPIC @ 1000Hz, i8254 @ 128Hz Timecounters tick every 1.000 msec firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0) (me) firewire0: bus manager 0 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 480Mbps High Speed USB v2.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 ad4: 152627MB at ata2-master UDMA100 SATA 1.5Gb/s 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 acd0: DVDR at ata3-master UDMA66 SATA 1.5Gb/s hdac0: HDA Codec #0: Cirrus Logic CS4206 pcm0: at cad 0 nid 1 on hdac0 pcm1: at cad 0 nid 1 on hdac0 pcm2: at cad 0 nid 1 on hdac0 GEOM: ad4p3: geometry does not match label (255h,63s != 16h,63s). GEOM: ad4p3: media size does not match label. GEOM: gpt/Untitled: geometry does not match label (255h,63s != 16h,63s). GEOM: gpt/Untitled: media size does not match label. GEOM: gptid/2027da8d-8557-46dc-b0b2-9481d6ca9ef4: geometry does not match label (255h,63s != 16h,63s). GEOM: gptid/2027da8d-8557-46dc-b0b2-9481d6ca9ef4: media size does not match label. uhub2: 5 ports with 5 removable, self powered uhub0: 7 ports with 7 removable, self powered uhub3: 5 ports with 5 removable, self powered uhub1: 7 ports with 7 removable, self powered ugen2.2: at usbus2 uhub4: on usbus2 ugen3.2: at usbus3 umass0: on usbus3 umass0: SCSI over Bulk-Only; quirks = 0x0000 ugen1.2: at usbus1 (null) from uhub1uhub4: 3 ports with 0 removable, self powered umass0:1:0:-1: Attached to scbus1 (probe7:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe7:umass-sim0:0:0:0): CAM status: SCSI Status Error (probe7:umass-sim0:0:0:0): SCSI status: Check Condition (probe7:umass-sim0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) SMP: AP CPU #1 Launched! WARNING: WITNESS option enabled, expect reduced performance. da0 at umass-sim0 bus 0 scbus1 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: Attempt to query device size failed: NOT READY, Medium not present Root mount waiting for: usbus1 ugen2.3: at usbus2 (null) from uhub4Trying to mount root from ufs:/dev/ufs/hpsRoot ugen0.2: at usbus0 uhid0: on usbus0 ugen2.4: at usbus2 ukbd0: on usbus2 kbd1 at ukbd0 ugen0.3: at usbus0 ukbd1: on usbus0 kbd2 at ukbd1 uhid1: on usbus0 ums0: on usbus0 ums0: 3 buttons and [XY] coordinates ID=2 ugen2.5: at usbus2 ums1: on usbus2 ums1: 3 buttons and [XY] coordinates ID=2 GEOM: gpt/Untitled: geometry does not match label (255h,63s != 16h,63s). GEOM: gpt/Untitled: media size does not match label. GEOM: gptid/2027da8d-8557-46dc-b0b2-9481d6ca9ef4: geometry does not match label (255h,63s != 16h,63s). GEOM: gptid/2027da8d-8557-46dc-b0b2-9481d6ca9ef4: media size does not match label. (null) from uhub1 lock order reversal: 1st 0xffffff0002bce278 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2090 2nd 0xffffff80239d9f38 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_softdep.c:11357 3rd 0xffffff0002bce098 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2090 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e __lockmgr_args() at __lockmgr_args+0xd11 ffs_lock() at ffs_lock+0x8c VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x47 vget() at vget+0x7b vfs_hash_get() at vfs_hash_get+0xd5 ffs_vgetf() at ffs_vgetf+0x48 softdep_sync_metadata() at softdep_sync_metadata+0x41b ffs_syncvnode() at ffs_syncvnode+0x213 ffs_truncate() at ffs_truncate+0x18c ufs_direnter() at ufs_direnter+0x6f1 ufs_mkdir() at ufs_mkdir+0x41f VOP_MKDIR_APV() at VOP_MKDIR_APV+0x93 kern_mkdirat() at kern_mkdirat+0x270 syscallenter() at syscallenter+0xf0 syscall() at syscall+0x4c Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (136, FreeBSD ELF64, mkdir), rip = 0x800730aac, rsp = 0x7fffffffec38, rbp = 0x7fffffffef36 --- ugen3.3: at usbus3 umass1: on usbus3 umass1: SCSI over Bulk-Only; quirks = 0x0000 umass1:2:1:-1: Attached to scbus2 (probe0:umass-sim1:1:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:umass-sim1:1:0:0): CAM status: SCSI Status Error (probe0:umass-sim1:1:0:0): SCSI status: Check Condition (probe0:umass-sim1:1:0:0): SCSI sense: UNIT ATTENTION asc:28,0 (Not ready to ready change, medium may have changed) da1 at umass-sim1 bus 1 scbus2 target 0 lun 0 da1: Removable Direct Access SCSI-0 device da1: 40.000MB/s transfers da1: 3842MB (7868416 512 byte sectors: 255H 63S/T 489C) --=-sZDwWjjHlziOoEmF+86n-- From owner-freebsd-acpi@FreeBSD.ORG Fri Oct 29 02:26:41 2010 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 6E8C0106564A; Fri, 29 Oct 2010 02:26:41 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id DE52F8FC14; Fri, 29 Oct 2010 02:26:40 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id o9T1xQ4o054667; Fri, 29 Oct 2010 12:59:27 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Fri, 29 Oct 2010 12:59:26 +1100 (EST) From: Ian Smith To: John Baldwin In-Reply-To: <201010281254.39862.jhb@freebsd.org> Message-ID: <20101029124821.B33417@sola.nimnet.asn.au> References: <201010281254.39862.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: acpi@freebsd.org Subject: Re: Removing acpi.ko support 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, 29 Oct 2010 02:26:41 -0000 On Thu, 28 Oct 2010, John Baldwin wrote: > [ cc'ing acpi@ to be safe, but I think the topic warrants the wider audience > of arch@ ] Dropping arch@ for this probably dumb question .. > I think we should drop support for having acpi load as a module for i386. It > adds extra complication and hacks to the i386 APIC and interrupt code that are > gratuitously different from amd64 as a result. Originally it was made a > module so that GENERIC on i386 did not include ACPI by default but would only > use up memory to hold ACPI-related code if the machine supported ACPI. Now > that acpi is part of GENERIC on i386 in 8.0 and later this argument is no > longer relevant. I'd like to remove support for ACPI as a module to remove > the various hacks on i386 and reduce differences with amd64. Just checking: this wouldn't impede loading apm and not enabling acpi for older machines (esp. laptops) that work ok with APM but not ACPI? cheers, Ian From owner-freebsd-acpi@FreeBSD.ORG Fri Oct 29 05:19:20 2010 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 091CC1065670; Fri, 29 Oct 2010 05:19:20 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 0C1508FC14; Fri, 29 Oct 2010 05:19:18 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id IAA27789; Fri, 29 Oct 2010 08:19:10 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1PBhMr-000DjE-Nb; Fri, 29 Oct 2010 08:19:09 +0300 Message-ID: <4CCA594C.7050806@icyb.net.ua> Date: Fri, 29 Oct 2010 08:19:08 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: Lin Ming References: <201010121209.06397.hselasky@c2i.net> <1288278300.2459.19.camel@localhost> <1288279472.2459.22.camel@localhost> <201010281810.23668.hselasky@c2i.net> <1288312476.13315.15.camel@minggr.sh.intel.com> In-Reply-To: <1288312476.13315.15.camel@minggr.sh.intel.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, "Moore, Robert" , Jung-uk Kim Subject: Re: MacBookPro 5,1 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, 29 Oct 2010 05:19:20 -0000 on 29/10/2010 03:34 Lin Ming said the following: > Hi, guys > > Hans and I have found the root cause of this bug. I believe that there could be a root for a root :-) > The ResourceSource->StringLength set by up layer driver is wrong, see the patch below. > > Below patch fixes the bug and on Hans' machine it prints, > > Bug: the passed in resource buffer is wrong, Resource->StringLength=1, but the real string length is 10 > Bug: the passed in resource buffer is wrong, Resource->StringLength=1, but the real string length is 10 > Bug: the passed in resource buffer is wrong, Resource->StringLength=1, but the real string length is 10 > Bug: the passed in resource buffer is wrong, Resource->StringLength=1, but the real string length is 8 > Bug: the passed in resource buffer is wrong, Resource->StringLength=1, but the real string length is 10 > Bug: the passed in resource buffer is wrong, Resource->StringLength=1, but the real string length is 10 > Bug: the passed in resource buffer is wrong, Resource->StringLength=1, but the real string length is 10 > Bug: the passed in resource buffer is wrong, Resource->StringLength=1, but the real string length is 10 > Bug: the passed in resource buffer is wrong, Resource->StringLength=1, but the real string length is 10 > > The full dmesg also attached. > > Kim, > > Could you write a fix in up layer code(seems in acpi_pci_link_route_irqs)? > > Thanks. > > diff --git a/source/components/resources/rscalc.c b/source/components/resources/rscalc.c > index 3215c9e..e68b5af 100644 > --- a/source/components/resources/rscalc.c > +++ b/source/components/resources/rscalc.c > @@ -203,7 +203,13 @@ AcpiRsStructOptionLength ( > */ > if (ResourceSource->StringPtr) > { > - return ((ACPI_RS_LENGTH) (ResourceSource->StringLength + 1)); > + if (ACPI_STRLEN (ResourceSource->StringPtr) + 1 != ResourceSource->StringLength) > + { > + AcpiOsPrintf("Bug: the passed in resource buffer is wrong, ResourceSource->StringLength=%d, " > + "but the real string length is %d\n", > + ResourceSource->StringLength, ACPI_STRLEN (ResourceSource->StringPtr) + 1); > + } > + return ((ACPI_RS_LENGTH) ((ACPI_STRLEN (ResourceSource->StringPtr) + 1) + 1)); > } > > return (0); > As Hans has reported previously, it seems that resources for _SRS are prepared by acpi_pci_link_srs_from_crs() in his case. acpi_pci_link_srs_from_crs is a sufficiently small function that doesn't seem to manipulate strings in any resources: http://fxr.watson.org/fxr/source/dev/acpica/acpi_pci_link.c#L689 At this line http://fxr.watson.org/fxr/source/dev/acpica/acpi_pci_link.c#L746 you can see that a resource is assigned from l_prs_template. l_prs_template is populated in link_add_prs() function, which called to walk over resources returned by _PRS: http://fxr.watson.org/fxr/source/dev/acpica/acpi_pci_link.c#L499 http://fxr.watson.org/fxr/source/dev/acpica/acpi_pci_link.c#L269 http://fxr.watson.org/fxr/source/dev/acpica/acpi_pci_link.c#L324 So, it would seem that those incorrect lengths would come from evaluation of _PRS by ACPICA code. But that's probably a naive conclusion, it could be that we incorrectly manipulate a received resource. It seems that the source of the trouble is resource template in BUFF, judging from e.g. _PRS for LNK1 (in DSDT dump that Hans has provided). I guess that we probably need more help with tracking this down further. Could it be that we get or somehow insert/copy garbage as a content of a string that should be empty? -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Fri Oct 29 05:23:17 2010 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 33BF3106564A; Fri, 29 Oct 2010 05:23:17 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 4000F8FC12; Fri, 29 Oct 2010 05:23:15 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id IAA27825; Fri, 29 Oct 2010 08:23:08 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1PBhQh-000DjX-OX; Fri, 29 Oct 2010 08:23:07 +0300 Message-ID: <4CCA5A3B.9000101@icyb.net.ua> Date: Fri, 29 Oct 2010 08:23:07 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: Lin Ming , Hans Petter Selasky References: <201010121209.06397.hselasky@c2i.net> <1288278300.2459.19.camel@localhost> <1288279472.2459.22.camel@localhost> <201010281810.23668.hselasky@c2i.net> <1288312476.13315.15.camel@minggr.sh.intel.com> <4CCA594C.7050806@icyb.net.ua> In-Reply-To: <4CCA594C.7050806@icyb.net.ua> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, "Moore, Robert" , Jung-uk Kim Subject: Re: MacBookPro 5,1 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, 29 Oct 2010 05:23:17 -0000 on 29/10/2010 08:19 Andriy Gapon said the following: > on 29/10/2010 03:34 Lin Ming said the following: >> Hi, guys >> >> Hans and I have found the root cause of this bug. > > I believe that there could be a root for a root :-) > >> The ResourceSource->StringLength set by up layer driver is wrong, see the patch below. >> >> Below patch fixes the bug and on Hans' machine it prints, >> >> Bug: the passed in resource buffer is wrong, Resource->StringLength=1, but the real string length is 10 >> Bug: the passed in resource buffer is wrong, Resource->StringLength=1, but the real string length is 10 >> Bug: the passed in resource buffer is wrong, Resource->StringLength=1, but the real string length is 10 >> Bug: the passed in resource buffer is wrong, Resource->StringLength=1, but the real string length is 8 >> Bug: the passed in resource buffer is wrong, Resource->StringLength=1, but the real string length is 10 >> Bug: the passed in resource buffer is wrong, Resource->StringLength=1, but the real string length is 10 >> Bug: the passed in resource buffer is wrong, Resource->StringLength=1, but the real string length is 10 >> Bug: the passed in resource buffer is wrong, Resource->StringLength=1, but the real string length is 10 >> Bug: the passed in resource buffer is wrong, Resource->StringLength=1, but the real string length is 10 >> >> The full dmesg also attached. >> >> Kim, >> >> Could you write a fix in up layer code(seems in acpi_pci_link_route_irqs)? >> >> Thanks. >> >> diff --git a/source/components/resources/rscalc.c b/source/components/resources/rscalc.c >> index 3215c9e..e68b5af 100644 >> --- a/source/components/resources/rscalc.c >> +++ b/source/components/resources/rscalc.c >> @@ -203,7 +203,13 @@ AcpiRsStructOptionLength ( >> */ >> if (ResourceSource->StringPtr) >> { >> - return ((ACPI_RS_LENGTH) (ResourceSource->StringLength + 1)); >> + if (ACPI_STRLEN (ResourceSource->StringPtr) + 1 != ResourceSource->StringLength) >> + { >> + AcpiOsPrintf("Bug: the passed in resource buffer is wrong, ResourceSource->StringLength=%d, " >> + "but the real string length is %d\n", >> + ResourceSource->StringLength, ACPI_STRLEN (ResourceSource->StringPtr) + 1); >> + } >> + return ((ACPI_RS_LENGTH) ((ACPI_STRLEN (ResourceSource->StringPtr) + 1) + 1)); >> } >> >> return (0); >> > > As Hans has reported previously, it seems that resources for _SRS are prepared > by acpi_pci_link_srs_from_crs() in his case. > acpi_pci_link_srs_from_crs is a sufficiently small function that doesn't seem to > manipulate strings in any resources: > http://fxr.watson.org/fxr/source/dev/acpica/acpi_pci_link.c#L689 > > At this line > http://fxr.watson.org/fxr/source/dev/acpica/acpi_pci_link.c#L746 > you can see that a resource is assigned from l_prs_template. > > l_prs_template is populated in link_add_prs() function, which called to walk > over resources returned by _PRS: > http://fxr.watson.org/fxr/source/dev/acpica/acpi_pci_link.c#L499 > http://fxr.watson.org/fxr/source/dev/acpica/acpi_pci_link.c#L269 > http://fxr.watson.org/fxr/source/dev/acpica/acpi_pci_link.c#L324 > > So, it would seem that those incorrect lengths would come from evaluation of > _PRS by ACPICA code. But that's probably a naive conclusion, it could be that > we incorrectly manipulate a received resource. > > It seems that the source of the trouble is resource template in BUFF, judging > from e.g. _PRS for LNK1 (in DSDT dump that Hans has provided). > > I guess that we probably need more help with tracking this down further. > Could it be that we get or somehow insert/copy garbage as a content of a string > that should be empty? Now that I wrote this, could the bug be in the following FreeBSD function: http://fxr.watson.org/fxr/source/dev/acpica/acpi.c?im=10#L2150 I guess Hans could insert the same code for verifying string length in the strategic places mentioned above to catch the exact place where string length and string content get out of sync. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Fri Oct 29 05:51:15 2010 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 7A6E71065673; Fri, 29 Oct 2010 05:51:15 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 822838FC1D; Fri, 29 Oct 2010 05:51:14 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id IAA28154; Fri, 29 Oct 2010 08:51:06 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1PBhrm-000DlA-47; Fri, 29 Oct 2010 08:51:06 +0300 Message-ID: <4CCA60C9.7040600@icyb.net.ua> Date: Fri, 29 Oct 2010 08:51:05 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: Lin Ming References: <201010121209.06397.hselasky@c2i.net> <1288278300.2459.19.camel@localhost> <1288279472.2459.22.camel@localhost> <201010281810.23668.hselasky@c2i.net> <1288312476.13315.15.camel@minggr.sh.intel.com> <4CCA594C.7050806@icyb.net.ua> <4CCA5A3B.9000101@icyb.net.ua> In-Reply-To: <4CCA5A3B.9000101@icyb.net.ua> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, "Moore, Robert" , Jung-uk Kim Subject: Re: MacBookPro 5,1 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, 29 Oct 2010 05:51:15 -0000 on 29/10/2010 08:23 Andriy Gapon said the following: > on 29/10/2010 08:19 Andriy Gapon said the following: [snip] >> l_prs_template is populated in link_add_prs() function, which called to walk >> over resources returned by _PRS: >> http://fxr.watson.org/fxr/source/dev/acpica/acpi_pci_link.c#L499 >> http://fxr.watson.org/fxr/source/dev/acpica/acpi_pci_link.c#L269 >> http://fxr.watson.org/fxr/source/dev/acpica/acpi_pci_link.c#L324 >> >> So, it would seem that those incorrect lengths would come from evaluation of >> _PRS by ACPICA code. But that's probably a naive conclusion, it could be that >> we incorrectly manipulate a received resource. I guess that a general problem here is that it is incorrect to merely use memcpy/bcopy to create a copy of a resource if the resource has ACPI_RESOURCE_SOURCE field in it. Is there a helper function for making such a copy? -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Fri Oct 29 14:05:34 2010 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 D172E106566C for ; Fri, 29 Oct 2010 14:05:34 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 9FBD28FC1D for ; Fri, 29 Oct 2010 14:05:34 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 43F7B46B37; Fri, 29 Oct 2010 10:05:34 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E33C38A009; Fri, 29 Oct 2010 10:05:29 -0400 (EDT) From: John Baldwin To: Ian Smith Date: Fri, 29 Oct 2010 09:45:16 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <201010281254.39862.jhb@freebsd.org> <20101029124821.B33417@sola.nimnet.asn.au> In-Reply-To: <20101029124821.B33417@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201010290945.16281.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 29 Oct 2010 10:05:30 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: acpi@freebsd.org Subject: Re: Removing acpi.ko support 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, 29 Oct 2010 14:05:34 -0000 On Thursday, October 28, 2010 9:59:26 pm Ian Smith wrote: > On Thu, 28 Oct 2010, John Baldwin wrote: > > [ cc'ing acpi@ to be safe, but I think the topic warrants the wider audience > > of arch@ ] > > Dropping arch@ for this probably dumb question .. > > > I think we should drop support for having acpi load as a module for i386. It > > adds extra complication and hacks to the i386 APIC and interrupt code that are > > gratuitously different from amd64 as a result. Originally it was made a > > module so that GENERIC on i386 did not include ACPI by default but would only > > use up memory to hold ACPI-related code if the machine supported ACPI. Now > > that acpi is part of GENERIC on i386 in 8.0 and later this argument is no > > longer relevant. I'd like to remove support for ACPI as a module to remove > > the various hacks on i386 and reduce differences with amd64. > > Just checking: this wouldn't impede loading apm and not enabling acpi > for older machines (esp. laptops) that work ok with APM but not ACPI? Correct. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Fri Oct 29 15:50:51 2010 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 49452106564A; Fri, 29 Oct 2010 15:50:51 +0000 (UTC) (envelope-from ming.m.lin@intel.com) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by mx1.freebsd.org (Postfix) with ESMTP id 2A8198FC0A; Fri, 29 Oct 2010 15:50:46 +0000 (UTC) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP; 29 Oct 2010 08:50:46 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.58,260,1286175600"; d="scan'208";a="852283471" Received: from unknown (HELO [10.255.20.51]) ([10.255.20.51]) by fmsmga001.fm.intel.com with ESMTP; 29 Oct 2010 08:50:33 -0700 From: Lin Ming To: Andriy Gapon In-Reply-To: <4CCA594C.7050806@icyb.net.ua> References: <201010121209.06397.hselasky@c2i.net> <1288278300.2459.19.camel@localhost> <1288279472.2459.22.camel@localhost> <201010281810.23668.hselasky@c2i.net> <1288312476.13315.15.camel@minggr.sh.intel.com> <4CCA594C.7050806@icyb.net.ua> Content-Type: text/plain; charset="UTF-8" Date: Fri, 29 Oct 2010 23:50:34 +0800 Message-Id: <1288367434.4039.3.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.28.0 (2.28.0-2.fc12) Content-Transfer-Encoding: 7bit Cc: "freebsd-acpi@FreeBSD.org" , "Moore, Robert" , Jung-uk Kim Subject: Re: MacBookPro 5,1 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, 29 Oct 2010 15:50:51 -0000 On Fri, 2010-10-29 at 13:19 +0800, Andriy Gapon wrote: > on 29/10/2010 03:34 Lin Ming said the following: > > Hi, guys > > > > Hans and I have found the root cause of this bug. > > I believe that there could be a root for a root :-) I will continue to check this bug next Monday. Hope we can find the final root :) Thanks. From owner-freebsd-acpi@FreeBSD.ORG Fri Oct 29 20:44:19 2010 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 A37D9106564A; Fri, 29 Oct 2010 20:44:19 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id F2E6B8FC14; Fri, 29 Oct 2010 20:44:18 +0000 (UTC) Received: by bwz3 with SMTP id 3so2918484bwz.13 for ; Fri, 29 Oct 2010 13:44:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=Nw5iBWwZFXy0fO6iEsf7kIyMCDeRp1h4ya8A4WczQu0=; b=nO+jm9eSrLtdRSzlA7pjxzyAWLvPlHqIdZFXoP0zH3W6oV76nf1JtuHYq/1EXQWjwB nBfzAQmMOIHChq5Saw4JE9grwAMWu9FzA3oZv7aAoNMkv0fCvgmdd8c1fDwzBIUPAW8B hU2p2CxJmXNMCc9K8sThh1Oc6Jf+Zhz60NKWE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=jofGNBbw1byjJu39mK9pFM0GaXjQr7kRDiN1QnDr6IcmAk2I8RRMetRYE6Ufi4XnwJ BxXzPp7m04EKhahpW7jnZZKF+suviYtcu5NpV1s20obETdHUVR8pIv23J0x1Gfbu/JEx ZaKr+U8q1PU/ucpzOXDu5cTeKRlMWR+tLBGiY= Received: by 10.204.76.14 with SMTP id a14mr543436bkk.14.1288385057679; Fri, 29 Oct 2010 13:44:17 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id g8sm1161066bkg.11.2010.10.29.13.44.15 (version=SSLv3 cipher=RC4-MD5); Fri, 29 Oct 2010 13:44:16 -0700 (PDT) Sender: Alexander Motin Message-ID: <4CCB321D.1020502@FreeBSD.org> Date: Fri, 29 Oct 2010 23:44:13 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: Takanori Watanabe References: <201010261904.o9QJ4iwq089834@sana.init-main.com> <4CC732C7.50409@FreeBSD.org> In-Reply-To: <4CC732C7.50409@FreeBSD.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: acpi@freebsd.org, current@freebsd.org Subject: Re: Event based scheduling and USB. 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, 29 Oct 2010 20:44:19 -0000 Alexander Motin wrote: > Takanori Watanabe wrote: >> I updated my FreeBSD tree on laptop, to the current >> as of 18 Oct.2010, it works fine with CPU C3 state enabled, >> >> I think this is your achievement of event time scheduler, >> thanks! >> >> But when USB driver is enabled, the load average is considerablly >> high (0.6 to 1.0) if sysctl oid kern.eventtimer.periodic is set to 0. >> Then kern.eventtimer.periodic is set to 1, the load average goes >> to 0 quickly as before, but almost never transit to C3. >> >> Is this behavior expected, or something wrong? >> I noticed one of usb host controller device shares HPET irq. >> When I implement interrupt filter in uhci driver, the load average >> goes to 0 as before. >> >> ==== >> % vmstat -i >> interrupt total rate >> irq1: atkbd0 398 2 >> irq9: acpi0 408 2 >> irq12: psm0 3 0 >> irq19: ehci1 37 0 >> irq20: hpet0 uhci0 35970 230 >> irq22: ehci0 2 0 >> irq256: em0 4 0 >> irq257: ahci0 1692 10 >> Total 38514 246 >> === > > I haven't noticed that issue and it is surely not expected for me. I > will try to reproduce it. I've easily reproduced the problem. Scheduler tracing shows that problem is the result of aliasing between "swi4: clock" thread on one CPU (measuring load average) and "irq21: hpet0 uhci1" thread on another. Those two events are aliased by definition due to shared interrupt source. Not sure what to do with it. Either we should change algorithm of load average calculation or exclude timer's interrupt threads from load average accounting. Adding interrupt filter for USB also reasonably helps, but it is only a partial solution for this specific sharing case. -- Alexander Motin