Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 30 Sep 2007 16:51:49 -0700
From:      Nate Lawson <nate@root.org>
To:        Abdullah Ibn Hamad Al-Marri <almarrie@gmail.com>
Cc:        freebsd-acpi@freebsd.org
Subject:   Re: INTEL D946GZIS acpi issues.
Message-ID:  <47003695.1090104@root.org>
In-Reply-To: <499c70c0709301620x6625a715t1247b70583c39619@mail.gmail.com>
References:  <499c70c0709271301g500d1d08gefe126bc65300d6c@mail.gmail.com>	 <46FC28DA.5090703@root.org>	 <499c70c0709271546i494a98au1a5d9dce4630a56c@mail.gmail.com>	 <46FC355A.1060807@root.org>	 <499c70c0709271559v515d1f7ev1a88acca94b68c4c@mail.gmail.com>	 <46FC3CB3.3060202@root.org> <46FFF493.3070800@root.org> <499c70c0709301620x6625a715t1247b70583c39619@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Abdullah Ibn Hamad Al-Marri wrote:
> On 9/30/07, Nate Lawson <nate@root.org> wrote:
>> Nate Lawson wrote:
>>>> devinfo -rv
>>>> nexus0
>>>>   acpi0
>>> ...
>>>>       I/O memory addresses:
>>>>           0xc0000-0xdffff
>>>>           0xe0000-0xfffff
>>>>           0xf0000000-0xf7ffffff
>>>>           0xfed13000-0xfed13fff
>>>>           0xfed14000-0xfed17fff
>>>>           0xfed18000-0xfed18fff
>>>>           0xfed19000-0xfed19fff
>>>>           0xfed1c000-0xfed1ffff
>>>>           0xfed20000-0xfed9ffff
>>>>     acpi_hpet0 pnpinfo unknown at unknown
>>>>         I/O memory addresses:
>>>>             0xfed00000-0xfed003ff
>>> Ok, that's one problem.  acpi_hpet is attaching before the system
>>> resource object.  So the resources are already allocated from nexus
>>> before acpi0 can get to them.
>>>
>>> To test, set this hint at the loader prompt and the message will go away
>>> (but you won't have the HPET timer):
>>>
>>> debug.acpi.disabled="hpet"
>> Please try the attached patch for 7-current.  You should not see the
>> message any more but will still have an acpi_hpet0 device.  Please send
>> me dmesg and devinfo -rv output after testing.
>
> Do I still need to apply the patch?

Yes, this won't fix cpufreq (need to figure out new Intel tables to make
that happen), but it will fix the "unable to allocate" error in dmesg
you first reported.

-- 
Nate



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47003695.1090104>