From owner-freebsd-current@FreeBSD.ORG Tue Mar 14 19:21:13 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 20FDD16A422 for ; Tue, 14 Mar 2006 19:21:13 +0000 (UTC) (envelope-from nate@root.org) Received: from ylpvm29.prodigy.net (ylpvm29-ext.prodigy.net [207.115.57.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id E9AFA43D48 for ; Tue, 14 Mar 2006 19:21:11 +0000 (GMT) (envelope-from nate@root.org) Received: from pimout5-ext.prodigy.net (pimout5-int.prodigy.net [207.115.4.21]) by ylpvm29.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id k2EJKebi024824 for ; Tue, 14 Mar 2006 14:20:41 -0500 X-ORBL: [67.119.74.222] Received: from [10.0.0.53] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222]) by pimout5-ext.prodigy.net (8.13.4 outbound domainkey aix/8.13.4) with ESMTP id k2EJL5pt240452; Tue, 14 Mar 2006 14:21:08 -0500 Message-ID: <4417178B.1090906@root.org> Date: Tue, 14 Mar 2006 11:20:43 -0800 From: Nate Lawson User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: John-Mark Gurney References: <20060312235642.GM840@funkthat.com> <4415A56F.4080207@root.org> <20060313225631.GP840@funkthat.com> In-Reply-To: <20060313225631.GP840@funkthat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@FreeBSD.org, kris@obsecurity.org Subject: Re: defaults/rc.conf v1.272 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2006 19:21:13 -0000 John-Mark Gurney wrote: > Nate Lawson wrote this message on Mon, Mar 13, 2006 at 09:01 -0800: >> The linux code disables C2-C3 for this system: >> "IBM ThinkPad R40e", >> DMI_BIOS_VENDOR, "IBM"), >> DMI_BIOS_VERSION, "1SET60WW")}, >> >> It disables just C3 for these: >> "Medion 41700" >> DMI_MATCH(DMI_BIOS_VENDOR, "Phoenix Technologies LTD"), >> DMI_MATCH(DMI_BIOS_VERSION, "R01-A1J") >> >> "Clevo 5600D" >> DMI_MATCH(DMI_BIOS_VENDOR, "Phoenix Technologies LTD"), >> DMI_MATCH(DMI_BIOS_VERSION, "SHE845M0.86C.0013.D.0302131307")}, >> >> I don't think any of those are your system. And they seem to be total >> hangs anyway, not heavy kernel cpu usage. > > Well, I never booted, so mine is a hang too... well, I never did leave > it for more than a couple minutes... Yeah, it's not likely to make progress unless you trigger system activity (i.e. interrupts) >> If we can't identify and isolate the problem enough to fix it, the >> commit to rc.conf can be reverted. However, I'd really like to find out >> more about which systems have this problem so we can fix it, not just >> paper over it. > > Oh, I understand.. :) and agree... I was lucky that I payed attention > to what happened durning mergemaster, and decided that this change was > the likely culprit.. otherwise I could of spent a long while tracking > this down... > > ------------------------------------------------------------------------ > > /* > RSD PTR: OEM=SOYO, ACPI_Rev=1.0x (0) > RSDT=0x177f3000, cksum=145 > */ > /* > RSDT: Length=40, Revision=1, Checksum=192, > OEMID=SOYO, OEM Table ID=AWRDACPI, OEM Revision=0x42302e31, > Creator ID=AWRD, Creator Revision=0x0 > Entries={ 0x177f3040 } > */ > /* > FACP: Length=116, Revision=1, Checksum=110, > OEMID=SOYO, OEM Table ID=AWRDACPI, OEM Revision=0x42302e31, > Creator ID=AWRD, Creator Revision=0x0 > FACS=0x177f0000, DSDT=0x177f30c0 > INT_MODEL=PIC > Preferred_PM_Profile=Unspecified (0) > SCI_INT=9 > SMI_CMD=0x402f, ACPI_ENABLE=0xa1, ACPI_DISABLE=0xa0, S4BIOS_REQ=0x0 > PSTATE_CNT=0x0 > PM1a_EVT_BLK=0x4000-0x4003 > PM1a_CNT_BLK=0x40f0-0x40f1 > PM_TMR_BLK=0x4008-0x400b > GPE0_BLK=0x4020-0x4023 > P_LVL2_LAT=90 us, P_LVL3_LAT=900 us ^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^ > FLUSH_SIZE=0, FLUSH_STRIDE=0 > DUTY_OFFSET=0, DUTY_WIDTH=1 > DAY_ALRM=125, MON_ALRM=126, CENTURY=50 > IAPC_BOOT_ARCH= > Flags={WBINVD,PROC_C1,SLP_BUTTON} > */ The acpi standard says values of 100 us and 1000 us (respectively) indicate the Cx state should not be used. Since these appear to be close, perhaps we can reject anything >= 90 and >= 900 instead. This may disable useful Cx states on some systems but it's likely to catch the bad ones also. As far as Kris's problem, I think C2 had a latency of 1 us so we couldn't catch it with this change. Perhaps there is something specific to his northbridge that I can identify. Getting the ASL from his system and others that have this issue would help. acpidump -t -d > my.asl -- Nate