Date: Tue, 14 Mar 2006 11:20:43 -0800 From: Nate Lawson <nate@root.org> To: John-Mark Gurney <gurney_j@resnet.uoregon.edu> Cc: current@FreeBSD.org, kris@obsecurity.org Subject: Re: defaults/rc.conf v1.272 Message-ID: <4417178B.1090906@root.org> In-Reply-To: <20060313225631.GP840@funkthat.com> References: <20060312235642.GM840@funkthat.com> <4415A56F.4080207@root.org> <20060313225631.GP840@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4417178B.1090906>