From smithi at nimnet.asn.au  Tue Jul  1 05:08:13 2008
From: smithi at nimnet.asn.au (Ian Smith)
Date: Tue Jul  1 05:08:16 2008
Subject: How/why would dev.cpu.0.freq_levels change??!?
In-Reply-To: <20080630163845.GL13924@bunrab.catwhisker.org>
Message-ID: <Pine.BSF.3.96.1080701140342.23993A-100000@gaia.nimnet.asn.au>

On Mon, 30 Jun 2008, David Wolfskill wrote:
 > On Mon, Jun 30, 2008 at 03:24:11PM +1000, Ian Smith wrote:
 > > ...
 > >  > * As you can see, this can lead to the "interesting" situation that the
 > >  >   current CPU frequency is higher than the maximum "available."
 > > 
 > > Perhaps just morbid curiousity, but I'm wondering which cpufreq drivers
 > > this machine winds up using (acpi_perf or est/p4tcc or .. ?)
 > > 
 > >   grep -i acpi /var/run/dmesg.boot ?
 > >   sysctl hw.acpi ?
 > 
 > I've placed copies of the dmesg.boot from each of RELENG_6, RELENG_7,
 > and HEAD in www.catwhisker.org:~david/public_html/FreeBSD, as well
 > as copies of the kernel configs (joining the ASL/DSDT stuff).  I
 > just added output from "sysctl hw.acpi" from each, as well:
 > 
 > bunrab(4.11-S)[3] ls -l laptop.i8200.*
 > -rw-r--r--  1 david  staff  91343 Jun 29 17:22 laptop.i8200.asl
 > -rw-r--r--  1 david  staff  28033 Jun 30 06:51 laptop.i8200.dmesg.boot.6
 > -rw-r--r--  1 david  staff  30401 Jun 30 06:54 laptop.i8200.dmesg.boot.7
 > -rw-r--r--  1 david  staff  34133 Jun 30 07:41 laptop.i8200.dmesg.boot.8
 > -rw-r--r--  1 david  staff  12622 Jun 29 17:22 laptop.i8200.dsdt
 > -rw-r--r--  1 david  staff    975 Jun 30 08:55 laptop.i8200.hw.acpi.6
 > -rw-r--r--  1 david  staff    974 Jun 30 08:57 laptop.i8200.hw.acpi.7
 > -rw-r--r--  1 david  staff    976 Jun 30 09:08 laptop.i8200.hw.acpi.8
 > -rw-r--r--  1 david  staff   9502 May  7 15:05 laptop.i8200.kernel.6
 > -rw-r--r--  1 david  staff   9154 Jun  8  2007 laptop.i8200.kernel.7
 > -rw-r--r--  1 david  staff   9399 Jan 12 17:26 laptop.i8200.kernel.8

Nothing if not thorough :)  As I vaguely suspected from those freq/0
reports, the cpufreq driver attachment seems a little unusual, though
I'm hoping someone who knows a lot more about this may say something.

On other P4 boxes' dmesg, I often notice est+p4tcc cpufreq drivers
attaching, but on yours, on 6.3-STABLE: 

acpi_perf0: <ACPI CPU Frequency Control> on cpu0
acpi_throttle0: <ACPI CPU Throttling> on cpu0
acpi_throttle0: P_CNT from P_BLK 0x8e0

but on 7.0-STABLE and 8-CURRENT:

acpi_perf0: <ACPI CPU Frequency Control> on cpu0
p4tcc0: <CPU Frequency Thermal Control> on cpu0

I'm really unsure what this means, but thought it perhaps noteworthy
that a) it wasn't using est? and b) I don't understand why on 6.3 it
would attach acpi_throttle when p4tcc seems available - but my hours of
digging through the drivers code has left me only a little the wiser,
and I'm still referring to old (5.5) sources; I've just installed 7.0 on
my T23 but I haven't yet setup and copied my working environment to it.

I also notice that there's only a _CRT temp. value, no _PSV, and (so?)
hw.acpi.thermal.tz0.passive_cooling=0 if that's relevant to this?

 > >   . are you running the latest BIOS/ACPI upgrade available from Dell?
 > >         "Project: DELL Mojave",
 > >         "Date: 01/28/1998",
 > >         "Ver: 1.00.04"
 > 
 > Errr... hmmm?  The machine shows "BIOS Version: A11".

The above is from your .asl, dunno if it's relevant?

 > >   . might you have any BIOS settings re performance/economy/cooling set?
 > 
 > My settings under "Power Management" (in the BIOS config/setup menus):
 > 
 >                     BATTERY       AC
 >                     _______       __
 >       Brightness: [XXXXX   ]  [XXXXXXX ]
 > Power Management:   Enabled     Enabled
 > Display Time-Out:  4 Minutes   Disabled
 >    Disk Time-Out:  3 Minutes   Disabled
 > Suspend Time-Out:  Disabled    Disabled
 >     22D Time-Out:  Disabled    Disabled
 >   Smart CPU Mode:   Enabled     Enabled
 >    Display Close:   Active      Active 
 > 
 > 
 >   Ring/Event Resume:         Enabled
 >        Alarm Resume:         Enabled
 >       Wakeup On LAN:        Disabled
 > Intel SpeedStep(tm):         Enabled
 >           CPU on AC:        Automatic
 >      CPU on Battery:        Automatic
 >        Auto On Mode:        Disabled
 >        Auto On Time:          00:00
 > 
 > 
 > Most of the above are defaults; I disabled Suspend & S2D on battery,
 > as well as told it to remain active on battery if I shut the lid.
 > Everything else should be a default setting.

I'm really quite unsure about whether the BIOS settings do or don't
affect ACPI operation under FreeBSD, or to what extent.  Ie what does
'Smart CPU Mode' do here?  Perhaps someone could comment on whether
such BIOS settings are reflected in ACPI method invocation at all?

 > >   . not running it in a dock are you?
 > 
 > I am not running it in a docking station or port replicator.
 > 
 > > From what you've described, it almost sounds like a hardware temperature
 > > sensor may have failed, or be reporting wrong, or something .. as this
 > > has only appeared recently, either something's broken, or perhaps you've
 > > inadvertantly changed something?  You did mention having been inside ..
 > > did that go as far as re-pasting the CPU or other heatsinks?
 > 
 > I did not see how to get the CPU heat sink off, so I didn't mess with
 > that.
 > 
 > I did remove the keyboard, and it appears that the keyboard acts as a
 > secondary heat sink for the video card; I did clean both surfaces (the
 > chip & the underside of the keyboard) and place a thin layer of thermal
 > compound on the chip before re-seating the keyboard.  That does not
 > appear to have had a noticable effect either way.
 > 
 > Thanks for the help so far.

Questions only help if they might lead to some answers .. not so far :)

 > I'm getting the distinct impression that it's likely that some of the
 > hardware is failing, and that I either need to have the machine repaired
 > by someone competent to do so (as opposed to me) or I need to consider
 > replacing it.  (There are, after all, significant parts of the machine
 > that are over 5 years old.  And I've been tracking various FreeBSD
 > branches on it just about daily as long as I've had it and it's been
 > working.)

I saw your later message to jhb about sending it off to the shop, so
hopefully something good will come of that.

cheers, Ian

From gaijin.k at gmail.com  Tue Jul  1 12:20:09 2008
From: gaijin.k at gmail.com (Alexandre "Sunny" Kovalenko)
Date: Tue Jul  1 12:20:14 2008
Subject: How/why would dev.cpu.0.freq_levels change??!?
In-Reply-To: <20080630004549.GI13924@bunrab.catwhisker.org>
References: <200806281738.40672.jhb@freebsd.org>
	<20080629003216.3AA074500E@ptavv.es.net>
	<20080629185738.GG13924@bunrab.catwhisker.org>
	<1214779416.925.17.camel@RabbitsDen>
	<20080630004549.GI13924@bunrab.catwhisker.org>
Message-ID: <1214914799.1064.12.camel@RabbitsDen>

On Sun, 2008-06-29 at 17:45 -0700, David Wolfskill wrote:
> On Sun, Jun 29, 2008 at 06:43:36PM -0400, Alexandre Sunny Kovalenko wrote:
> > I am coming in late in the thread, so if I have misunderstood your
> > problem, I do apologize.
> 
> Not at all; thank you for your suggestions!
> 
> > ...
> > > * As you can see, this can lead to the "interesting" situation that the
> > >   current CPU frequency is higher than the maximum "available."
> > >From my (somewhat limited) understanding of the ACPI spec, BIOS can
> > change _PSS object (one containing available clock frequencies) and
> > issue notification to the OS to reevaluate said object. There is no
> > requirement that BIOS change current CPU frequency while doing that.
> 
> OK; I confess ignorance on that score: I'm posting to -acpi because I
> rather suspect that ACPI is (at least) profoundly implicated in what's
> going on, if not responsible for it.
> 
> > You can try to dump your ASL and see if anything there messes up with
> > _PSS and then issues Notify (xxx.CPU0, 0x80) on the same breath. Killing
> > that piece of ASL dead should ensure constant CPU frequencies set. ???You
> > can post your ASL someplace where I can get to it, I just could not
> > promise that I'll understand it much better than you.
> 
> I ran
> 
> 	sudo acpidump -dt -o >laptop.i8200.dsdt >laptop.i8200.asl
> 
> and placed the results in www.catwhisker.org:~david/public_html/FreeBSD/,
> so <http://www.catwhisker.org/~david/FreeBSD/laptop.i8200.asl> and
> <http://www.catwhisker.org/~david/FreeBSD/laptop.i8200.dsdt> should
> work.  I just tried it from my laptop (sick as it is), and the MD5
> hashes matched.  They are:
> 
> g1-60(6.3-S)[6] md5 laptop.i8200.*
> MD5 (laptop.i8200.asl) = 7c83c27ad30bbd0957f10a5a3ffc90e5
> MD5 (laptop.i8200.dsdt) = c290ab9be7c97eb7ae98523a5f5a4ddc
> g1-60(6.3-S)[7] 
There is definitely some logic to figure out set of frequencies to
return:

            Method (_PSS, 0, NotSerialized)
            {
                SX10 ()
                SX30 (0x0B)
                SX11 ()
                Index (PSSX, 0x00, Local0)
                Store (SX42 (), Index (DerefOf (Local0), 0x00))
                Store (SX42 (), Index (DerefOf (Local0), 0x01))
                Store (SX42 (), Index (DerefOf (Local0), 0x02))
                Store (SX42 (), Index (DerefOf (Local0), 0x03))
                Store (SX40 (), Index (DerefOf (Local0), 0x04))
                Store (SX40 (), Index (DerefOf (Local0), 0x05))
                Index (PSSX, 0x01, Local1)
                Store (SX42 (), Index (DerefOf (Local1), 0x00))
                Store (SX42 (), Index (DerefOf (Local1), 0x01))
                Store (SX42 (), Index (DerefOf (Local1), 0x02))
                Store (SX42 (), Index (DerefOf (Local1), 0x03))
                Store (SX40 (), Index (DerefOf (Local1), 0x04))
                Store (SX40 (), Index (DerefOf (Local1), 0x05))
                SX12 ()
                Return (PSSX)
            }


and there is definitely a condition when OS is asked to reevaluate the
list:

    Method (SMIE, 0, NotSerialized)
    {
        Store (SMI (0x96, 0x00), Local0)
        If (And (Local0, 0x01))
        {
            Notify (\_TZ.THM, 0x80)
        }

        If (And (Local0, 0x02))
        {
            Notify (\_SB.PCI0.AGP.VID, 0x80)
        }

        If (And (Local0, 0x04))
        {
            Notify (\_SB.BAT0, 0x81)
            Notify (\_SB.BAT1, 0x81)
        }

        If (And (Local0, 0x08))
        {
            Notify (\_PR.CPU0, 0x80)   <=============================
        }
    }

What is somewhat puzzling, is that _PSS above seems to return two
frequencies only, and your freq_levels output show more than that. Once
you get it back from the repair shop, and, provided you still feel
adventurous, we can try to sprinkle some prints around _PSS read and see
what gives. Let me know if and when you are interested.

However, given what I am looking at, I am inclined to guess that a)
there is the reason behind the _PSS change. b) the cpufreq driver you
are using disagrees with it.

-- 
Alexandre "Sunny" Kovalenko (????????? ?????????)

From smithi at nimnet.asn.au  Tue Jul  1 14:24:18 2008
From: smithi at nimnet.asn.au (Ian Smith)
Date: Tue Jul  1 14:24:22 2008
Subject: How/why would dev.cpu.0.freq_levels change??!?
In-Reply-To: <1214914799.1064.12.camel@RabbitsDen>
Message-ID: <Pine.BSF.3.96.1080701225233.23993B-100000@gaia.nimnet.asn.au>

On Tue, 1 Jul 2008, Alexandre "Sunny" Kovalenko wrote:
 > On Sun, 2008-06-29 at 17:45 -0700, David Wolfskill wrote:
 > > On Sun, Jun 29, 2008 at 06:43:36PM -0400, Alexandre Sunny Kovalenko wrote:
 > > > I am coming in late in the thread, so if I have misunderstood your
 > > > problem, I do apologize.
 > > 
 > > Not at all; thank you for your suggestions!
 > > 
 > > > ...
 > > > > * As you can see, this can lead to the "interesting" situation that the
 > > > >   current CPU frequency is higher than the maximum "available."
 > > > >From my (somewhat limited) understanding of the ACPI spec, BIOS can
 > > > change _PSS object (one containing available clock frequencies) and
 > > > issue notification to the OS to reevaluate said object. There is no
 > > > requirement that BIOS change current CPU frequency while doing that.
 > > 
 > > OK; I confess ignorance on that score: I'm posting to -acpi because I
 > > rather suspect that ACPI is (at least) profoundly implicated in what's
 > > going on, if not responsible for it.
 > > 
 > > > You can try to dump your ASL and see if anything there messes up with
 > > > _PSS and then issues Notify (xxx.CPU0, 0x80) on the same breath. Killing
 > > > that piece of ASL dead should ensure constant CPU frequencies set. ???You
 > > > can post your ASL someplace where I can get to it, I just could not
 > > > promise that I'll understand it much better than you.
 > > 
 > > I ran
 > > 
 > > 	sudo acpidump -dt -o >laptop.i8200.dsdt >laptop.i8200.asl
 > > 
 > > and placed the results in www.catwhisker.org:~david/public_html/FreeBSD/,
 > > so <http://www.catwhisker.org/~david/FreeBSD/laptop.i8200.asl> and
 > > <http://www.catwhisker.org/~david/FreeBSD/laptop.i8200.dsdt> should
 > > work.  I just tried it from my laptop (sick as it is), and the MD5
 > > hashes matched.  They are:
 > > 
 > > g1-60(6.3-S)[6] md5 laptop.i8200.*
 > > MD5 (laptop.i8200.asl) = 7c83c27ad30bbd0957f10a5a3ffc90e5
 > > MD5 (laptop.i8200.dsdt) = c290ab9be7c97eb7ae98523a5f5a4ddc
 > > g1-60(6.3-S)[7] 

 > There is definitely some logic to figure out set of frequencies to
 > return:
 > 
 >             Method (_PSS, 0, NotSerialized)
 >             {
 >                 SX10 ()
 >                 SX30 (0x0B)
 >                 SX11 ()
 >                 Index (PSSX, 0x00, Local0)
 >                 Store (SX42 (), Index (DerefOf (Local0), 0x00))
 >                 Store (SX42 (), Index (DerefOf (Local0), 0x01))
 >                 Store (SX42 (), Index (DerefOf (Local0), 0x02))
 >                 Store (SX42 (), Index (DerefOf (Local0), 0x03))
 >                 Store (SX40 (), Index (DerefOf (Local0), 0x04))
 >                 Store (SX40 (), Index (DerefOf (Local0), 0x05))
 >                 Index (PSSX, 0x01, Local1)
 >                 Store (SX42 (), Index (DerefOf (Local1), 0x00))
 >                 Store (SX42 (), Index (DerefOf (Local1), 0x01))
 >                 Store (SX42 (), Index (DerefOf (Local1), 0x02))
 >                 Store (SX42 (), Index (DerefOf (Local1), 0x03))
 >                 Store (SX40 (), Index (DerefOf (Local1), 0x04))
 >                 Store (SX40 (), Index (DerefOf (Local1), 0x05))
 >                 SX12 ()
 >                 Return (PSSX)
 >             }
 > 
 > 
 > and there is definitely a condition when OS is asked to reevaluate the
 > list:
 > 
 >     Method (SMIE, 0, NotSerialized)
 >     {
 >         Store (SMI (0x96, 0x00), Local0)
 >         If (And (Local0, 0x01))
 >         {
 >             Notify (\_TZ.THM, 0x80)
 >         }
 > 
 >         If (And (Local0, 0x02))
 >         {
 >             Notify (\_SB.PCI0.AGP.VID, 0x80)
 >         }
 > 
 >         If (And (Local0, 0x04))
 >         {
 >             Notify (\_SB.BAT0, 0x81)
 >             Notify (\_SB.BAT1, 0x81)
 >         }
 > 
 >         If (And (Local0, 0x08))
 >         {
 >             Notify (\_PR.CPU0, 0x80)   <=============================
 >         }
 >     }

And that's the only place it (and \_TZ.THM) notifies seem to occur.

 > What is somewhat puzzling, is that _PSS above seems to return two
 > frequencies only, and your freq_levels output show more than that. Once
 > you get it back from the repair shop, and, provided you still feel
 > adventurous, we can try to sprinkle some prints around _PSS read and see
 > what gives. Let me know if and when you are interested.

I should shutup till having a proper look at more recent sources :) but
that may be the relative frequency control drivers, acpi_throttle0 on
6.3-S and p4tcc0 on 7-S and 8 as seen earlier in the dmesgs, returning
throttled frequencies of 7/8 downto 1/8th of each, with any duplicates
removed, to populate the available freq.levels I expect?

So the fact that the levels topped out at 1200 rather than 2400 might
indicate that at the time only the lower base frequency was available,
whether by the BIOS intervening somehow, or by cpufreq 'freqing out' :)

 > However, given what I am looking at, I am inclined to guess that a)
 > there is the reason behind the _PSS change. b) the cpufreq driver you
 > are using disagrees with it.

Only strange that it worked before for ages, up to 85C as David noted.
Hopefully just a busted temperature sensor or something else fixable ..

cheers, Ian

From oberman at es.net  Tue Jul  1 16:17:19 2008
From: oberman at es.net (Kevin Oberman)
Date: Tue Jul  1 16:17:24 2008
Subject: How/why would dev.cpu.0.freq_levels change??!? 
In-Reply-To: Your message of "Tue, 01 Jul 2008 08:19:58 EDT."
	<1214914799.1064.12.camel@RabbitsDen> 
Message-ID: <20080701161718.CB0B745047@ptavv.es.net>

> From: "Alexandre \"Sunny\" Kovalenko" <gaijin.k@gmail.com>
> Date: Tue, 01 Jul 2008 08:19:58 -0400
> Sender: owner-freebsd-acpi@freebsd.org
> 
> On Sun, 2008-06-29 at 17:45 -0700, David Wolfskill wrote:
> > On Sun, Jun 29, 2008 at 06:43:36PM -0400, Alexandre Sunny Kovalenko wrote:
> > > I am coming in late in the thread, so if I have misunderstood your
> > > problem, I do apologize.
> > 
> > Not at all; thank you for your suggestions!
> > 
> > > ...
> > > > * As you can see, this can lead to the "interesting" situation that the
> > > >   current CPU frequency is higher than the maximum "available."
> > > >From my (somewhat limited) understanding of the ACPI spec, BIOS can
> > > change _PSS object (one containing available clock frequencies) and
> > > issue notification to the OS to reevaluate said object. There is no
> > > requirement that BIOS change current CPU frequency while doing that.
> > 
> > OK; I confess ignorance on that score: I'm posting to -acpi because I
> > rather suspect that ACPI is (at least) profoundly implicated in what's
> > going on, if not responsible for it.
> > 
> > > You can try to dump your ASL and see if anything there messes up with
> > > _PSS and then issues Notify (xxx.CPU0, 0x80) on the same breath. Killing
> > > that piece of ASL dead should ensure constant CPU frequencies set. ???You
> > > can post your ASL someplace where I can get to it, I just could not
> > > promise that I'll understand it much better than you.
> > 
> > I ran
> > 
> > 	sudo acpidump -dt -o >laptop.i8200.dsdt >laptop.i8200.asl
> > 
> > and placed the results in www.catwhisker.org:~david/public_html/FreeBSD/,
> > so <http://www.catwhisker.org/~david/FreeBSD/laptop.i8200.asl> and
> > <http://www.catwhisker.org/~david/FreeBSD/laptop.i8200.dsdt> should
> > work.  I just tried it from my laptop (sick as it is), and the MD5
> > hashes matched.  They are:
> > 
> > g1-60(6.3-S)[6] md5 laptop.i8200.*
> > MD5 (laptop.i8200.asl) = 7c83c27ad30bbd0957f10a5a3ffc90e5
> > MD5 (laptop.i8200.dsdt) = c290ab9be7c97eb7ae98523a5f5a4ddc
> > g1-60(6.3-S)[7] 
> There is definitely some logic to figure out set of frequencies to
> return:
> 
>             Method (_PSS, 0, NotSerialized)
>             {
>                 SX10 ()
>                 SX30 (0x0B)
>                 SX11 ()
>                 Index (PSSX, 0x00, Local0)
>                 Store (SX42 (), Index (DerefOf (Local0), 0x00))
>                 Store (SX42 (), Index (DerefOf (Local0), 0x01))
>                 Store (SX42 (), Index (DerefOf (Local0), 0x02))
>                 Store (SX42 (), Index (DerefOf (Local0), 0x03))
>                 Store (SX40 (), Index (DerefOf (Local0), 0x04))
>                 Store (SX40 (), Index (DerefOf (Local0), 0x05))
>                 Index (PSSX, 0x01, Local1)
>                 Store (SX42 (), Index (DerefOf (Local1), 0x00))
>                 Store (SX42 (), Index (DerefOf (Local1), 0x01))
>                 Store (SX42 (), Index (DerefOf (Local1), 0x02))
>                 Store (SX42 (), Index (DerefOf (Local1), 0x03))
>                 Store (SX40 (), Index (DerefOf (Local1), 0x04))
>                 Store (SX40 (), Index (DerefOf (Local1), 0x05))
>                 SX12 ()
>                 Return (PSSX)
>             }
> 
> 
> and there is definitely a condition when OS is asked to reevaluate the
> list:
> 
>     Method (SMIE, 0, NotSerialized)
>     {
>         Store (SMI (0x96, 0x00), Local0)
>         If (And (Local0, 0x01))
>         {
>             Notify (\_TZ.THM, 0x80)
>         }
> 
>         If (And (Local0, 0x02))
>         {
>             Notify (\_SB.PCI0.AGP.VID, 0x80)
>         }
> 
>         If (And (Local0, 0x04))
>         {
>             Notify (\_SB.BAT0, 0x81)
>             Notify (\_SB.BAT1, 0x81)
>         }
> 
>         If (And (Local0, 0x08))
>         {
>             Notify (\_PR.CPU0, 0x80)   <=============================
>         }
>     }
> 
> What is somewhat puzzling, is that _PSS above seems to return two
> frequencies only, and your freq_levels output show more than that. Once
> you get it back from the repair shop, and, provided you still feel
> adventurous, we can try to sprinkle some prints around _PSS read and see
> what gives. Let me know if and when you are interested.
> 
> However, given what I am looking at, I am inclined to guess that a)
> there is the reason behind the _PSS change. b) the cpufreq driver you
> are using disagrees with it.

There are only two "real" frequencies on this CPU. Looks like a P4
without EST. In any case, the other "frequencies" are created by P4TCC
which performs the same function as throttling, but in a different
way. P4TCC works a bit better than throttling, but neither is a big
win. The Speedstep one is the big winner, here.

P4TCC will create 8 freq values for each "Real" frequency for a total of
16 frequencies. If the BIOS disabled the faster speed, there should only
be 8 available.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman@es.net			Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 224 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-acpi/attachments/20080701/52886ee6/attachment.pgp
From robert.moore at intel.com  Tue Jul  1 19:49:43 2008
From: robert.moore at intel.com (Moore, Robert)
Date: Tue Jul  1 19:53:26 2008
Subject: ACPICA version 20080701 released
Message-ID: <9D39833986E69849A2A8E74C1078B6B3986B2D@orsmsx415.amr.corp.intel.com>

01 July 2008. Summary of changes for version 20080701:

This release is available at http://acpica.org/downloads
Direct git access via http://www.acpica.org/repos/acpica.git

0) Git source tree / acpica.org

Fixed a problem where a git-clone from http would not transfer the
entire source tree.

1) ACPI CA Core Subsystem:

Implemented a "careful" GPE disable in AcpiEvDisableGpe, only modify one
enable bit. Now performs a read-change-write of the enable register
instead of simply writing out the cached enable mask. This will prevent
inadvertent enabling of GPEs if a rogue GPE is received during
initialization (before GPE handlers are installed.)

Implemented a copy for dynamically loaded tables. Previously,
dynamically loaded tables were simply mapped - but on some machines this
memory is corrupted after suspend. Now copy the table to a local buffer.
For the OpRegion case, added checksum verify. Use the table length from
the table header, not the region length. For the Buffer case, use the
table length also. Dennis Noordsij, Bob Moore. BZ 10734

Fixed a problem where the same ACPI table could not be dynamically
loaded and unloaded more than once. Without this change, a table cannot
be loaded again once it has been loaded/unloaded one time. The current
mechanism does not unregister a table upon an unload. During a load, if
the same table is found, this no longer returns an exception. BZ 722

Fixed a problem where the wrong descriptor length was calculated for the
EndTag descriptor in 64-bit mode. The "minimal" descriptors such as
EndTag are calculated as 12 bytes long, but the actual length in the
internal descriptor is 16 because of the round-up to 8 on the 64-bit
build. Reported by Linn Crosetto. BZ 728

Fixed a possible memory leak in the Unload operator. The DdbHandle
returned by Load() did not have its reference count decremented during
unload, leading to a memory leak. Lin Ming. BZ 727

Fixed a possible memory leak when deleting thermal/processor objects.
Any associated notify handlers (and objects) were not being deleted.
Fiodor Suietov. BZ 506

Fixed the ordering of the ASCII names in the global mutex table to match
the actual mutex IDs. Used by AcpiUtGetMutexName, a function used for
debug only. Vegard Nossum. BZ 726

Enhanced the AcpiGetObjectInfo interface to return the number of
required arguments if the object is a control method. Added this call to
the debugger so the proper number of default arguments are passed to a
method. This prevents a warning when executing methods from AcpiExec.

Added a check for an invalid handle in AcpiGetObjectInfo. Return
AE_BAD_PARAMETER if input handle is invalid. BZ 474

Fixed an extraneous warning from exconfig.c on the 64-bit build.

Example Code and Data Size: These are the sizes for the OS-independent
acpica.lib produced by the Microsoft Visual C++ 6.0 32-bit compiler. The
debug version of the code includes the debug output trace mechanism and
has a much larger code and data size.

  Previous Release:
    Non-Debug Version:  79.3K Code, 16.2K Data,  95.5K Total
    Debug Version:     153.0K Code, 48.2K Data, 201.2K Total
  Current Release:
    Non-Debug Version:  79.6K Code, 16.2K Data,  95.8K Total
    Debug Version:     153.5K Code, 48.2K Data, 201.7K Total

2) iASL Compiler/Disassembler and Tools:

iASL: Added two missing ACPI reserved names. Added _MTP and _ASZ, both
resource descriptor names.

iASL: Detect invalid ASCII characters in input (windows version).
Removed the "-CF" flag from the flex compile, enables correct detection
of non-ASCII characters in the input. BZ 441

iASL: Eliminate warning when result of LoadTable is not used. Eliminate
the "result of operation not used" warning when the DDB handle returned
from LoadTable is not used. The warning is not needed. BZ 590

AcpiExec: Add support for dynamic table load/unload. Now calls _CFG
method to pass address of table to the AML. Added option to disable
OpRegion simulation to allow creation of an OpRegion with a real address
that was passed to _CFG. All of this allows testing of the Load and
Unload operators from AcpiExec.

Debugger: update tables command for unloaded tables. Handle unloaded
tables and use the standard table header output routine.

From jkim at FreeBSD.org  Tue Jul  1 21:02:48 2008
From: jkim at FreeBSD.org (Jung-uk Kim)
Date: Tue Jul  1 21:02:50 2008
Subject: ACPICA version 20080701 released
In-Reply-To: <9D39833986E69849A2A8E74C1078B6B3986B2D@orsmsx415.amr.corp.intel.com>
References: <9D39833986E69849A2A8E74C1078B6B3986B2D@orsmsx415.amr.corp.intel.com>
Message-ID: <200807011702.29351.jkim@FreeBSD.org>

On Tuesday 01 July 2008 03:20 pm, Moore, Robert wrote:
> 01 July 2008. Summary of changes for version 20080701:
>
> This release is available at http://acpica.org/downloads
> Direct git access via http://www.acpica.org/repos/acpica.git
>
> 0) Git source tree / acpica.org
>
> Fixed a problem where a git-clone from http would not transfer the
> entire source tree.
>
> 1) ACPI CA Core Subsystem:
>
> Implemented a "careful" GPE disable in AcpiEvDisableGpe, only
> modify one enable bit. Now performs a read-change-write of the
> enable register instead of simply writing out the cached enable
> mask. This will prevent inadvertent enabling of GPEs if a rogue GPE
> is received during initialization (before GPE handlers are
> installed.)
>
> Implemented a copy for dynamically loaded tables. Previously,
> dynamically loaded tables were simply mapped - but on some machines
> this memory is corrupted after suspend. Now copy the table to a
> local buffer. For the OpRegion case, added checksum verify. Use the
> table length from the table header, not the region length. For the
> Buffer case, use the table length also. Dennis Noordsij, Bob Moore.
> BZ 10734
>
> Fixed a problem where the same ACPI table could not be dynamically
> loaded and unloaded more than once. Without this change, a table
> cannot be loaded again once it has been loaded/unloaded one time.
> The current mechanism does not unregister a table upon an unload.
> During a load, if the same table is found, this no longer returns
> an exception. BZ 722
>
> Fixed a problem where the wrong descriptor length was calculated
> for the EndTag descriptor in 64-bit mode. The "minimal" descriptors
> such as EndTag are calculated as 12 bytes long, but the actual
> length in the internal descriptor is 16 because of the round-up to
> 8 on the 64-bit build. Reported by Linn Crosetto. BZ 728
>
> Fixed a possible memory leak in the Unload operator. The DdbHandle
> returned by Load() did not have its reference count decremented
> during unload, leading to a memory leak. Lin Ming. BZ 727
>
> Fixed a possible memory leak when deleting thermal/processor
> objects. Any associated notify handlers (and objects) were not
> being deleted. Fiodor Suietov. BZ 506
>
> Fixed the ordering of the ASCII names in the global mutex table to
> match the actual mutex IDs. Used by AcpiUtGetMutexName, a function
> used for debug only. Vegard Nossum. BZ 726
>
> Enhanced the AcpiGetObjectInfo interface to return the number of
> required arguments if the object is a control method. Added this
> call to the debugger so the proper number of default arguments are
> passed to a method. This prevents a warning when executing methods
> from AcpiExec.
>
> Added a check for an invalid handle in AcpiGetObjectInfo. Return
> AE_BAD_PARAMETER if input handle is invalid. BZ 474
>
> Fixed an extraneous warning from exconfig.c on the 64-bit build.
>
> Example Code and Data Size: These are the sizes for the
> OS-independent acpica.lib produced by the Microsoft Visual C++ 6.0
> 32-bit compiler. The debug version of the code includes the debug
> output trace mechanism and has a much larger code and data size.
>
>   Previous Release:
>     Non-Debug Version:  79.3K Code, 16.2K Data,  95.5K Total
>     Debug Version:     153.0K Code, 48.2K Data, 201.2K Total
>   Current Release:
>     Non-Debug Version:  79.6K Code, 16.2K Data,  95.8K Total
>     Debug Version:     153.5K Code, 48.2K Data, 201.7K Total
>
> 2) iASL Compiler/Disassembler and Tools:
>
> iASL: Added two missing ACPI reserved names. Added _MTP and _ASZ,
> both resource descriptor names.
>
> iASL: Detect invalid ASCII characters in input (windows version).
> Removed the "-CF" flag from the flex compile, enables correct
> detection of non-ASCII characters in the input. BZ 441
>
> iASL: Eliminate warning when result of LoadTable is not used.
> Eliminate the "result of operation not used" warning when the DDB
> handle returned from LoadTable is not used. The warning is not
> needed. BZ 590
>
> AcpiExec: Add support for dynamic table load/unload. Now calls _CFG
> method to pass address of table to the AML. Added option to disable
> OpRegion simulation to allow creation of an OpRegion with a real
> address that was passed to _CFG. All of this allows testing of the
> Load and Unload operators from AcpiExec.
>
> Debugger: update tables command for unloaded tables. Handle
> unloaded tables and use the standard table header output routine.

As usual, ACPI-CA patches against FreeBSD -CURRENT is here:

http://people.freebsd.org/~jkim/acpica-import-20080701.diff.gz

Jung-uk Kim
From robert.moore at intel.com  Tue Jul  1 21:33:43 2008
From: robert.moore at intel.com (Moore, Robert)
Date: Tue Jul  1 21:33:46 2008
Subject: ACPICA version 20080701 released
In-Reply-To: <200807011702.29351.jkim@FreeBSD.org>
References: <9D39833986E69849A2A8E74C1078B6B3986B2D@orsmsx415.amr.corp.intel.com>
	<200807011702.29351.jkim@FreeBSD.org>
Message-ID: <9D39833986E69849A2A8E74C1078B6B3986C05@orsmsx415.amr.corp.intel.com>

I hope it is getting smaller.


>-----Original Message-----
>From: Jung-uk Kim [mailto:jkim@FreeBSD.org]
>Sent: Tuesday, July 01, 2008 2:02 PM
>To: freebsd-acpi@FreeBSD.org
>Cc: Moore, Robert
>Subject: Re: ACPICA version 20080701 released
>

From olivier at aixmarseille.com  Wed Jul  2 15:45:47 2008
From: olivier at aixmarseille.com (Olivier Fauchon)
Date: Wed Jul  2 15:45:51 2008
Subject: Dell ACPI & S3 resume problems.
Message-ID: <486B9B56.3050609@aixmarseille.com>


Hi,

When I try to resume from S3 on my DELL Latitude D430 by pressing power 
button, the laptop reboots.

I tried the same test with a Knoppix Live CD, and It passes (Laptop 
revives although LCD is buggy).
But I could type "shutdown -r now" blindly, to confirm it wakes up properly.

Now I need help to find out the differences between FREEBSD and LINUX 
which makes resume fail.

You'll find here all collected informations:

* Verbose Booting with FreeBSD7  
http://www.aixmarseille.com/pub/acpi_fb7_casino/boot_verbose_d430_FB7.log
* Booting with Knoppix dmesg  
http://www.aixmarseille.com/pub/acpi_fb7_casino/dmesg_knoppix_d430.log
* Dell LAtitude D430 original ASL: 
http://www.aixmarseille.com/pub/acpi_fb7_casino/dell-d430.orig.asl
* Patched ASL (which only correct a LID and warning problems) 
http://www.aixmarseille.com/pub/acpi_fb7_casino/dell-d430.patched.asl
* Kernel configuration : 
http://www.aixmarseille.com/pub/acpi_fb7_casino/kern_conf_CASINO.txt
* lspci : http://www.aixmarseille.com/pub/acpi_fb7_casino/lpsci.txt

Can someone explains me what are the main steps of a resume, so I can 
try to troubleshoot further.


Thanks.







From j at uriah.heep.sax.de  Wed Jul  2 19:50:55 2008
From: j at uriah.heep.sax.de (Joerg Wunsch)
Date: Wed Jul  2 19:50:58 2008
Subject: HP/Compaq nx6325 clock "jumping around"
Message-ID: <20080702191827.GK1469@uriah.heep.sax.de>

On a nx6325 running 6-stable (because I couldn't get 7.x to work with
ACPI at all so far), the main clock is frequently "jumping", up to a
level where ntpd eventually gives up:

Jul  2 10:44:44 remi ntpd[50885]: time reset +11.885037 s
Jul  2 10:44:44 remi ntpd[50885]: kernel time sync disabled 6041
Jul  2 10:54:24 remi ntpd[50885]: kernel time sync disabled 2041
Jul  2 11:07:13 remi ntpd[50885]: kernel time sync enabled 2001
Jul  2 11:45:44 remi ntpd[50885]: time reset +1.874996 s
Jul  2 11:45:44 remi ntpd[50885]: kernel time sync enabled 6001
Jul  2 11:55:25 remi ntpd[50885]: kernel time sync enabled 2001
Jul  2 12:06:07 remi ntpd[50885]: time reset -0.539515 s
Jul  2 13:47:45 remi ntpd[50885]: time reset +901.759394 s
Jul  2 13:47:45 remi ntpd[50885]: kernel time sync enabled 6001
Jul  2 13:57:25 remi ntpd[50885]: kernel time sync enabled 2001
Jul  2 14:05:58 remi ntpd[50885]: time reset +0.159707 s
Jul  2 14:24:08 remi ntpd[50885]: time reset +0.451464 s
Jul  2 14:42:15 remi ntpd[50885]: time reset +0.323177 s
Jul  2 15:00:25 remi ntpd[50885]: time reset -0.525669 s
Jul  2 15:45:34 remi ntpd[50885]: time reset -0.197339 s
Jul  2 18:10:59 remi ntpd[50885]: time reset +894.125104 s
Jul  2 18:10:59 remi ntpd[50885]: kernel time sync enabled 6001
Jul  2 19:03:17 remi ntpd[50885]: time correction of 1785 seconds exceeds sanity limit (1000); set clock manually to the correct UTC time.

Notice the huge time resets of about 900 seconds between.  Could this
be related to CPU frequency changes caused by whomever might control
that (ACPI BIOS?  powerd is not running, should I?)?  The CPU
frequencies listed are:

dev.cpu.0.freq: 1393
dev.cpu.0.freq_levels: 1990/100000 1791/81822 1592/65808 1393/57582 1194/49356 995/41130 796/22152 696/19383 597/16614 497/13845 398/11076 298/8307 199/5538 99/2769

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
From rpaulo at FreeBSD.org  Wed Jul  2 21:54:02 2008
From: rpaulo at FreeBSD.org (Rui Paulo)
Date: Wed Jul  2 21:54:30 2008
Subject: Dell ACPI & S3 resume problems.
In-Reply-To: <486B9B56.3050609@aixmarseille.com>
References: <486B9B56.3050609@aixmarseille.com>
Message-ID: <20080702215234.GB1790@phi.local>

On Wed, Jul 02, 2008 at 05:14:30PM +0200, Olivier Fauchon wrote:
> 
> Hi,
> 
> When I try to resume from S3 on my DELL Latitude D430 by pressing power 
> button, the laptop reboots.
> 
> I tried the same test with a Knoppix Live CD, and It passes (Laptop 
> revives although LCD is buggy).
> But I could type "shutdown -r now" blindly, to confirm it wakes up properly.
> 
> Now I need help to find out the differences between FREEBSD and LINUX 
> which makes resume fail.
> 
> You'll find here all collected informations:
> 
> * Verbose Booting with FreeBSD7  
> http://www.aixmarseille.com/pub/acpi_fb7_casino/boot_verbose_d430_FB7.log
> * Booting with Knoppix dmesg  
> http://www.aixmarseille.com/pub/acpi_fb7_casino/dmesg_knoppix_d430.log
> * Dell LAtitude D430 original ASL: 
> http://www.aixmarseille.com/pub/acpi_fb7_casino/dell-d430.orig.asl
> * Patched ASL (which only correct a LID and warning problems) 
> http://www.aixmarseille.com/pub/acpi_fb7_casino/dell-d430.patched.asl
> * Kernel configuration : 
> http://www.aixmarseille.com/pub/acpi_fb7_casino/kern_conf_CASINO.txt
> * lspci : http://www.aixmarseille.com/pub/acpi_fb7_casino/lpsci.txt
> 
> Can someone explains me what are the main steps of a resume, so I can 
> try to troubleshoot further.

Well, your best bet is to disable every driver and make them modules. Boot
with the bare minimum necessary for input/output and in single user mode.
Try suspend and resume in single user mode. If that works, the problem, 
most likely lies in the drivers.

Try enabling one driver at a time, and retest suspend/resume. This way
you can find the problematic driver, if any.

Also, try changing the hw.acpi sysctls, namely reset_video.

HTH,
-- 
Rui Paulo
From rpaulo at FreeBSD.org  Wed Jul  2 21:56:00 2008
From: rpaulo at FreeBSD.org (Rui Paulo)
Date: Wed Jul  2 21:56:04 2008
Subject: HP/Compaq nx6325 clock "jumping around"
In-Reply-To: <20080702191827.GK1469@uriah.heep.sax.de>
References: <20080702191827.GK1469@uriah.heep.sax.de>
Message-ID: <20080702215431.GC1790@phi.local>

On Wed, Jul 02, 2008 at 09:18:27PM +0200, Joerg Wunsch wrote:
> On a nx6325 running 6-stable (because I couldn't get 7.x to work with
> ACPI at all so far), the main clock is frequently "jumping", up to a
> level where ntpd eventually gives up:
> 
> Jul  2 10:44:44 remi ntpd[50885]: time reset +11.885037 s
> Jul  2 10:44:44 remi ntpd[50885]: kernel time sync disabled 6041
> Jul  2 10:54:24 remi ntpd[50885]: kernel time sync disabled 2041
> Jul  2 11:07:13 remi ntpd[50885]: kernel time sync enabled 2001
> Jul  2 11:45:44 remi ntpd[50885]: time reset +1.874996 s
> Jul  2 11:45:44 remi ntpd[50885]: kernel time sync enabled 6001
> Jul  2 11:55:25 remi ntpd[50885]: kernel time sync enabled 2001
> Jul  2 12:06:07 remi ntpd[50885]: time reset -0.539515 s
> Jul  2 13:47:45 remi ntpd[50885]: time reset +901.759394 s
> Jul  2 13:47:45 remi ntpd[50885]: kernel time sync enabled 6001
> Jul  2 13:57:25 remi ntpd[50885]: kernel time sync enabled 2001
> Jul  2 14:05:58 remi ntpd[50885]: time reset +0.159707 s
> Jul  2 14:24:08 remi ntpd[50885]: time reset +0.451464 s
> Jul  2 14:42:15 remi ntpd[50885]: time reset +0.323177 s
> Jul  2 15:00:25 remi ntpd[50885]: time reset -0.525669 s
> Jul  2 15:45:34 remi ntpd[50885]: time reset -0.197339 s
> Jul  2 18:10:59 remi ntpd[50885]: time reset +894.125104 s
> Jul  2 18:10:59 remi ntpd[50885]: kernel time sync enabled 6001
> Jul  2 19:03:17 remi ntpd[50885]: time correction of 1785 seconds exceeds sanity limit (1000); set clock manually to the correct UTC time.
> 
> Notice the huge time resets of about 900 seconds between.  Could this
> be related to CPU frequency changes caused by whomever might control
> that (ACPI BIOS?  powerd is not running, should I?)?  The CPU
> frequencies listed are:
> 
> dev.cpu.0.freq: 1393
> dev.cpu.0.freq_levels: 1990/100000 1791/81822 1592/65808 1393/57582 1194/49356 995/41130 796/22152 696/19383 597/16614 497/13845 398/11076 298/8307 199/5538 99/2769

Maybe, or maybe not.
Try also change kern.timecounter.hardware.

HTH,
-- 
Rui Paulo
From j at uriah.heep.sax.de  Wed Jul  2 22:01:37 2008
From: j at uriah.heep.sax.de (Joerg Wunsch)
Date: Wed Jul  2 22:01:40 2008
Subject: HP/Compaq nx6325 clock "jumping around"
In-Reply-To: <20080702215431.GC1790@phi.local>
References: <20080702191827.GK1469@uriah.heep.sax.de>
	<20080702215431.GC1790@phi.local>
Message-ID: <20080702220135.GM1469@uriah.heep.sax.de>

As Rui Paulo wrote:

> Try also change kern.timecounter.hardware.

Thanks for the hint.  The current value is:

remi# sysctl kern.timecounter.hardware
kern.timecounter.hardware: ACPI-fast

Curious, what are the possible options?
-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
From rpaulo at FreeBSD.org  Wed Jul  2 22:04:20 2008
From: rpaulo at FreeBSD.org (Rui Paulo)
Date: Wed Jul  2 22:04:25 2008
Subject: HP/Compaq nx6325 clock "jumping around"
In-Reply-To: <20080702220135.GM1469@uriah.heep.sax.de>
References: <20080702191827.GK1469@uriah.heep.sax.de>
	<20080702215431.GC1790@phi.local>
	<20080702220135.GM1469@uriah.heep.sax.de>
Message-ID: <20080702220254.GD1790@phi.local>

On Thu, Jul 03, 2008 at 12:01:35AM +0200, Joerg Wunsch wrote:
> As Rui Paulo wrote:
> 
> > Try also change kern.timecounter.hardware.
> 
> Thanks for the hint.  The current value is:
> 
> remi# sysctl kern.timecounter.hardware
> kern.timecounter.hardware: ACPI-fast
> 
> Curious, what are the possible options?

See kern.timecounter.choice :-)

I wonder how you have ACPI-fast selected if you disabled ACPI.

Regards,
-- 
Rui Paulo
From olivier at aixmarseille.com  Thu Jul  3 08:22:37 2008
From: olivier at aixmarseille.com (Olivier Fauchon)
Date: Thu Jul  3 08:22:41 2008
Subject: Dell ACPI & S3 resume problems.
In-Reply-To: <20080702215234.GB1790@phi.local>
References: <486B9B56.3050609@aixmarseille.com>
	<20080702215234.GB1790@phi.local>
Message-ID: <486C8CCA.9040101@aixmarseille.com>

Rui Paulo wrote:
> On Wed, Jul 02, 2008 at 05:14:30PM +0200, Olivier Fauchon wrote:
>   
>> Hi,
>>
>> When I try to resume from S3 on my DELL Latitude D430 by pressing power 
>> button, the laptop reboots.
>>
>> I tried the same test with a Knoppix Live CD, and It passes (Laptop 
>> revives although LCD is buggy).
>> But I could type "shutdown -r now" blindly, to confirm it wakes up properly.
>>
>> Now I need help to find out the differences between FREEBSD and LINUX 
>> which makes resume fail.
>>
>> You'll find here all collected informations:
>>
>> * Verbose Booting with FreeBSD7  
>> http://www.aixmarseille.com/pub/acpi_fb7_casino/boot_verbose_d430_FB7.log
>> * Booting with Knoppix dmesg  
>> http://www.aixmarseille.com/pub/acpi_fb7_casino/dmesg_knoppix_d430.log
>> * Dell LAtitude D430 original ASL: 
>> http://www.aixmarseille.com/pub/acpi_fb7_casino/dell-d430.orig.asl
>> * Patched ASL (which only correct a LID and warning problems) 
>> http://www.aixmarseille.com/pub/acpi_fb7_casino/dell-d430.patched.asl
>> * Kernel configuration : 
>> http://www.aixmarseille.com/pub/acpi_fb7_casino/kern_conf_CASINO.txt
>> * lspci : http://www.aixmarseille.com/pub/acpi_fb7_casino/lpsci.txt
>>
>> Can someone explains me what are the main steps of a resume, so I can 
>> try to troubleshoot further.
>>     
>
> Well, your best bet is to disable every driver and make them modules. Boot
> with the bare minimum necessary for input/output and in single user mode.
> Try suspend and resume in single user mode. If that works, the problem, 
> most likely lies in the drivers.
>
> Try enabling one driver at a time, and retest suspend/resume. This way
> you can find the problematic driver, if any.
>
> Also, try changing the hw.acpi sysctls, namely reset_video.
>
>   
> HTH,
>   

I already try a modular kernel, in single mode, and the laptop stills 
reboot on S3 wakeup.
 
What happens if  I set debug.acpi.resume_beep=1?
Should buzzer beep at the early begining of wake up code ? Never heard 
that sound.

At the moment, I'd like to troubleshoot the moment ACPI give the hand to 
FreeBSD, any idea how to do that ?

Thx

From markir at paradise.net.nz  Thu Jul  3 10:12:41 2008
From: markir at paradise.net.nz (Mark Kirkwood)
Date: Thu Jul  3 10:12:45 2008
Subject: Dell ACPI & S3 resume problems.
In-Reply-To: <20080702215234.GB1790@phi.local>
References: <486B9B56.3050609@aixmarseille.com>
	<20080702215234.GB1790@phi.local>
Message-ID: <486CA5C9.8030401@paradise.net.nz>

Rui Paulo wrote:
> On Wed, Jul 02, 2008 at 05:14:30PM +0200, Olivier Fauchon wrote:
>   
>> Hi,
>>
>> When I try to resume from S3 on my DELL Latitude D430 by pressing power 
>> button, the laptop reboots.
>>
>> I tried the same test with a Knoppix Live CD, and It passes (Laptop 
>> revives although LCD is buggy).
>> But I could type "shutdown -r now" blindly, to confirm it wakes up properly.
>>
>> Now I need help to find out the differences between FREEBSD and LINUX 
>> which makes resume fail.
>>
>> You'll find here all collected informations:
>>
>> * Verbose Booting with FreeBSD7  
>> http://www.aixmarseille.com/pub/acpi_fb7_casino/boot_verbose_d430_FB7.log
>> * Booting with Knoppix dmesg  
>> http://www.aixmarseille.com/pub/acpi_fb7_casino/dmesg_knoppix_d430.log
>> * Dell LAtitude D430 original ASL: 
>> http://www.aixmarseille.com/pub/acpi_fb7_casino/dell-d430.orig.asl
>> * Patched ASL (which only correct a LID and warning problems) 
>> http://www.aixmarseille.com/pub/acpi_fb7_casino/dell-d430.patched.asl
>> * Kernel configuration : 
>> http://www.aixmarseille.com/pub/acpi_fb7_casino/kern_conf_CASINO.txt
>> * lspci : http://www.aixmarseille.com/pub/acpi_fb7_casino/lpsci.txt
>>
>> Can someone explains me what are the main steps of a resume, so I can 
>> try to troubleshoot further.
>>     
>
> Well, your best bet is to disable every driver and make them modules. Boot
> with the bare minimum necessary for input/output and in single user mode.
> Try suspend and resume in single user mode. If that works, the problem, 
> most likely lies in the drivers.
>
> Try enabling one driver at a time, and retest suspend/resume. This way
> you can find the problematic driver, if any.
>
> Also, try changing the hw.acpi sysctls, namely reset_video.
>
> HTH,
>   

 From your dmesg it looks like you are running both cores (i.e smp 
kernel). Try disabling one core via kern.smp.disabled=1 in loader.conf 
(some laptops will not suspend properly with both cores running).

Cheers

Mark
From olivier at aixmarseille.com  Thu Jul  3 15:46:37 2008
From: olivier at aixmarseille.com (Olivier Fauchon)
Date: Thu Jul  3 15:46:41 2008
Subject: Dell ACPI & S3 resume problems.
In-Reply-To: <486CA5C9.8030401@paradise.net.nz>
References: <486B9B56.3050609@aixmarseille.com>
	<20080702215234.GB1790@phi.local>
	<486CA5C9.8030401@paradise.net.nz>
Message-ID: <486CF4D3.8020706@aixmarseille.com>

Mark Kirkwood wrote:
> Rui Paulo wrote:
>> On Wed, Jul 02, 2008 at 05:14:30PM +0200, Olivier Fauchon wrote:
>>  
>>> Hi,
>>>
>>> When I try to resume from S3 on my DELL Latitude D430 by pressing 
>>> power button, the laptop reboots.
>>>
>>> I tried the same test with a Knoppix Live CD, and It passes (Laptop 
>>> revives although LCD is buggy).
>>> But I could type "shutdown -r now" blindly, to confirm it wakes up 
>>> properly.
>>>
>>> Now I need help to find out the differences between FREEBSD and 
>>> LINUX which makes resume fail.
>>>
>>> You'll find here all collected informations:
>>>
>>> * Verbose Booting with FreeBSD7  
>>> http://www.aixmarseille.com/pub/acpi_fb7_casino/boot_verbose_d430_FB7.log 
>>>
>>> * Booting with Knoppix dmesg  
>>> http://www.aixmarseille.com/pub/acpi_fb7_casino/dmesg_knoppix_d430.log
>>> * Dell LAtitude D430 original ASL: 
>>> http://www.aixmarseille.com/pub/acpi_fb7_casino/dell-d430.orig.asl
>>> * Patched ASL (which only correct a LID and warning problems) 
>>> http://www.aixmarseille.com/pub/acpi_fb7_casino/dell-d430.patched.asl
>>> * Kernel configuration : 
>>> http://www.aixmarseille.com/pub/acpi_fb7_casino/kern_conf_CASINO.txt
>>> * lspci : http://www.aixmarseille.com/pub/acpi_fb7_casino/lpsci.txt
>>>
>>> Can someone explains me what are the main steps of a resume, so I 
>>> can try to troubleshoot further.
>>>     
>>
>> Well, your best bet is to disable every driver and make them modules. 
>> Boot
>> with the bare minimum necessary for input/output and in single user 
>> mode.
>> Try suspend and resume in single user mode. If that works, the 
>> problem, most likely lies in the drivers.
>>
>> Try enabling one driver at a time, and retest suspend/resume. This way
>> you can find the problematic driver, if any.
>>
>> Also, try changing the hw.acpi sysctls, namely reset_video.
>>
>> HTH,
>>   
>
> From your dmesg it looks like you are running both cores (i.e smp 
> kernel). Try disabling one core via kern.smp.disabled=1 in loader.conf 
> (some laptops will not suspend properly with both cores running).
>
> Cheers
>
> Mark

Perfect.... That works !

I 'm actualy running a SMP kernel (CoreDuo CPU) with one disabled core 
(with BIOS). This was not enough.

"kern.smp.disabled=1" corrects the problem.

I'm now able to resume under Xorg, in multiuser mode. I'm lucky.
 

THX !

From nate at root.org  Thu Jul  3 15:54:27 2008
From: nate at root.org (Nate Lawson)
Date: Thu Jul  3 15:54:31 2008
Subject: How/why would dev.cpu.0.freq_levels change??!?
In-Reply-To: <20080627235319.GP70792@bunrab.catwhisker.org>
References: <20080627235319.GP70792@bunrab.catwhisker.org>
Message-ID: <486CEFEC.2070107@root.org>

David Wolfskill wrote:
> My laptop is a Dell Inspiron 8200; I (ab)use it moderately heavily:
> this includes tracking RELENG_6, RELENG_7, & HEAD on it, daily.
> 
> Lately there have been some times when "make buildworld" for RELENG_6
> has taken a lot longer than it used to ... and I noticed that the
> fans were on, even though it was running fairly cool (around 50C;
> during a "make buildworld, around 85C is more common) -- and that
> the machine was typically "topping out" at half speed (1200 MHz).
> 
> During these times, querying dev.cpu.0.freq_levels would yield a list
> that did, ini fact, max out at 1200 MHz, when I know that it has gone up
> to 2400 MHz in the past.

The ACPI spec describes how the _PSS levels can change dynamically at 
runtime.  For instance, if you go off AC, the system might offer a lower 
power state.  I'm guessing you're using the acpi_perf driver.

Usually the system generates a notify when that happens though so I was 
surprised there was no dmesg.  I'm not sure how well we support changing 
levels yet.

-- 
Nate
From markir at paradise.net.nz  Fri Jul  4 03:10:59 2008
From: markir at paradise.net.nz (Mark Kirkwood)
Date: Fri Jul  4 03:11:05 2008
Subject: Dell ACPI & S3 resume problems.
In-Reply-To: <486CF4D3.8020706@aixmarseille.com>
References: <486B9B56.3050609@aixmarseille.com>
	<20080702215234.GB1790@phi.local> <486CA5C9.8030401@paradise.net.nz>
	<486CF4D3.8020706@aixmarseille.com>
Message-ID: <486D94AB.7090003@paradise.net.nz>

Olivier Fauchon wrote:
>
> Perfect.... That works !
>
> I 'm actualy running a SMP kernel (CoreDuo CPU) with one disabled core 
> (with BIOS). This was not enough.
>
> "kern.smp.disabled=1" corrects the problem.
>
> I'm now able to resume under Xorg, in multiuser mode. I'm lucky.
>
>
>

No worries - pleased it works... my Asus Pro31j does not :-(

Cheers

Mark

From alex.wilkinson at dsto.defence.gov.au  Fri Jul  4 07:40:14 2008
From: alex.wilkinson at dsto.defence.gov.au (Wilkinson, Alex)
Date: Fri Jul  4 07:40:25 2008
Subject: Dell ACPI & S3 resume problems.
In-Reply-To: <486CF4D3.8020706@aixmarseille.com>
References: <486B9B56.3050609@aixmarseille.com> 
	<20080702215234.GB1790@phi.local> <486CA5C9.8030401@paradise.net.nz> 
	<486CF4D3.8020706@aixmarseille.com>
Message-ID: <20080704071950.GE90732@stlux503.dsto.defence.gov.au>

    0n Thu, Jul 03, 2008 at 05:48:35PM +0200, Olivier Fauchon wrote: 

    >Perfect.... That works !
    >I 'm actualy running a SMP kernel (CoreDuo CPU) with one disabled core 
    >(with BIOS). This was not enough.
    >"kern.smp.disabled=1" corrects the problem.
    >I'm now able to resume under Xorg, in multiuser mode. I'm lucky.

How are you lucky if you loose one of your cores ?

 -aW

IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914.  If you have received this email in error, you are requested to contact the sender and delete the email.


From olivier at aixmarseille.com  Fri Jul  4 07:51:40 2008
From: olivier at aixmarseille.com (Olivier Fauchon)
Date: Fri Jul  4 07:51:47 2008
Subject: Dell ACPI & S3 resume problems.
In-Reply-To: <20080704071950.GE90732@stlux503.dsto.defence.gov.au>
References: <486B9B56.3050609@aixmarseille.com>
	<20080702215234.GB1790@phi.local>
	<486CA5C9.8030401@paradise.net.nz>
	<486CF4D3.8020706@aixmarseille.com>
	<20080704071950.GE90732@stlux503.dsto.defence.gov.au>
Message-ID: <486DD706.5070305@aixmarseille.com>

Wilkinson, Alex wrote:
>     0n Thu, Jul 03, 2008 at 05:48:35PM +0200, Olivier Fauchon wrote: 
>
>     >Perfect.... That works !
>     >I 'm actualy running a SMP kernel (CoreDuo CPU) with one disabled core 
>     >(with BIOS). This was not enough.
>     >"kern.smp.disabled=1" corrects the problem.
>     >I'm now able to resume under Xorg, in multiuser mode. I'm lucky.
>
> How are you lucky if you loose one of your cores ?
>
>   
In fact, I don't care about the dual-core feature for the moment (laptop 
only used for office & developement, not much CPU required) .
But I care about suspending my laptop, which is really confortable.

So, yes I'm lucky to have my needs achieved :-)


>  -aW
>
> IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914.  If you have received this email in error, you are requested to contact the sender and delete the email.
>
>
> _______________________________________________
> freebsd-acpi@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
> To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org"
>   

From brde at optusnet.com.au  Fri Jul  4 14:27:30 2008
From: brde at optusnet.com.au (Bruce Evans)
Date: Fri Jul  4 14:27:36 2008
Subject: HP/Compaq nx6325 clock "jumping around"
In-Reply-To: <20080702191827.GK1469@uriah.heep.sax.de>
References: <20080702191827.GK1469@uriah.heep.sax.de>
Message-ID: <20080703145049.S6189@delplex.bde.org>

On Wed, 2 Jul 2008, Joerg Wunsch wrote:

> On a nx6325 running 6-stable (because I couldn't get 7.x to work with
> ACPI at all so far), the main clock is frequently "jumping", up to a
> level where ntpd eventually gives up:

Try 7.x.  6.x never worked right for me on this machine, due to lapic
timer bugs which might be fixed now, while 7-CURRENT started working
right except for suspend and lid switch once the lapic timer bugs and
minor battery bugs were fixed, and 7-CURRENT and 8-CURRENT haven't
regressed in compatibility since then.  I didn't try amd64 mode until
after the bugs were fixed, and it worked immediately with late
7-CURRENT after rcp'ing ~5.2 userland and updating the kernel.

> Jul  2 10:44:44 remi ntpd[50885]: time reset +11.885037 s
> Jul  2 10:44:44 remi ntpd[50885]: kernel time sync disabled 6041
> Jul  2 10:54:24 remi ntpd[50885]: kernel time sync disabled 2041
> Jul  2 11:07:13 remi ntpd[50885]: kernel time sync enabled 2001
> ...
> Jul  2 19:03:17 remi ntpd[50885]: time correction of 1785 seconds exceeds sanity limit (1000); set clock manually to the correct UTC time.

I know of the following bugs in time on nx6325:
- pressing the lid switch to turn the screen off makes the time jump by
   almost precisely 1 second using any timecounter.  The system appears
   to spend the 1 second in something like SMM mode with all interrupts
   and all timecounters stopped.  More precisely, the jump is:
   ACPI-fast and TSC: -1.000000 +- 10 uS
   i8254:             -1.043000 +- 1 mS
- pressing the lid switch to turn the screen on makes the time jump by
   55 +- 1 mS with the i8254 timecounter.  The magic 55 is 1 i8254 timer
   maximum count (65536 / 1193182 = 0.054925.  (65536 is with acpi_timer;
   otherwise at least FreeBSD's max count would be ~11920 giving a magic
   10).  Apparently, SMM restarts and/or reloads all the timercounter's
   hardware, but makes a larger mess of it for the i8254.  Not making
   a mess of it is harder than for the other timecounter hardware, since
   the others have a granularity of 1 cycle while the i8254 has a
   granularity of 65536 or 11920 cycles unless it is carefully synced
   with the OS software which SMM can't do.  The magic 43 for screen
   off is presumably the magic 55 reduced a bit by other bugs.
- dynamic recalibration of cpu_tick_frequency has never worked.  This
   is a MI bug, and only affects process times.  cpu_tick_frequency is
   never adjusted downwards (except for a full recalibration).  Thus
   any glitches in the cpu_tick clock (TSC on nx6325), e.g., from the
   SMM bug or entering ddb) cause cpu_tick_frequency to creep or jump
   upwards and never come down.

Maybe you have a dynamic cause of events like the lid switch.  I don't
see any problems except with time except the above.

> Notice the huge time resets of about 900 seconds between.  Could this
> be related to CPU frequency changes caused by whomever might control
> that (ACPI BIOS?  powerd is not running, should I?)?  The CPU
> frequencies listed are:
>
> dev.cpu.0.freq: 1393
> dev.cpu.0.freq_levels: 1990/100000 1791/81822 1592/65808 1393/57582 1194/49356 995/41130 796/22152 696/19383 597/16614 497/13845 398/11076 298/8307 199/5538 99/2769

I don't use powerd and rarely use batteries.  Suspsend stuff doesn't
work in FreeBSD, perhaps because I have no acpi support newer than
~5.2 in userland (powerd doesn't exist), and battery life at max CPU
is about 30 minutes.  makeworld of ~5.2 over nfs takes 13 minutes 40
seconds.  nx6325 doesn't run ~5.2 kernels (problems in video, ata and
acpi) or early (?) 6.x kernels with lapic timer.

dev.cpu.0.freq: 1985
dev.cpu.0.freq_levels: 1985/-1 1736/-1 1488/-1 1240/-1 992/-1 744/-1 496/-1 248/-1

Once I used some performance/power-reduction config and got a list like yours.

1985 actually gives 1995 MHz.

Bruce
From rpaulo at FreeBSD.org  Fri Jul  4 14:51:27 2008
From: rpaulo at FreeBSD.org (Rui Paulo)
Date: Fri Jul  4 14:51:32 2008
Subject: Dell ACPI & S3 resume problems.
In-Reply-To: <486DD706.5070305@aixmarseille.com>
References: <486B9B56.3050609@aixmarseille.com>
	<20080702215234.GB1790@phi.local>
	<486CA5C9.8030401@paradise.net.nz>
	<486CF4D3.8020706@aixmarseille.com>
	<20080704071950.GE90732@stlux503.dsto.defence.gov.au>
	<486DD706.5070305@aixmarseille.com>
Message-ID: <20080704145005.GA3560@phi.local>

On Fri, Jul 04, 2008 at 09:53:42AM +0200, Olivier Fauchon wrote:
> Wilkinson, Alex wrote:
> >     0n Thu, Jul 03, 2008 at 05:48:35PM +0200, Olivier Fauchon wrote: 
> >
> >     >Perfect.... That works !
> >     >I 'm actualy running a SMP kernel (CoreDuo CPU) with one disabled core 
> >     >(with BIOS). This was not enough.
> >     >"kern.smp.disabled=1" corrects the problem.
> >     >I'm now able to resume under Xorg, in multiuser mode. I'm lucky.
> >
> > How are you lucky if you loose one of your cores ?
> >
> >   
> In fact, I don't care about the dual-core feature for the moment (laptop 
> only used for office & developement, not much CPU required) .
> But I care about suspending my laptop, which is really confortable.
> 
> So, yes I'm lucky to have my needs achieved :-)

You can try the ACPI SMP suspend/resume patch:
http://lists.freebsd.org/pipermail/freebsd-acpi/2008-May/004879.html

Regards,
-- 
Rui Paulo
From nate at root.org  Fri Jul  4 16:47:45 2008
From: nate at root.org (Nate Lawson)
Date: Fri Jul  4 16:47:51 2008
Subject: HP/Compaq nx6325 clock "jumping around"
In-Reply-To: <20080703145049.S6189@delplex.bde.org>
References: <20080702191827.GK1469@uriah.heep.sax.de>
	<20080703145049.S6189@delplex.bde.org>
Message-ID: <486E4DE7.60807@root.org>

Bruce Evans wrote:
> On Wed, 2 Jul 2008, Joerg Wunsch wrote:
> 
>> On a nx6325 running 6-stable (because I couldn't get 7.x to work with
>> ACPI at all so far), the main clock is frequently "jumping", up to a
>> level where ntpd eventually gives up:
> 
> I know of the following bugs in time on nx6325:
> - pressing the lid switch to turn the screen off makes the time jump by
>   almost precisely 1 second using any timecounter.  The system appears
>   to spend the 1 second in something like SMM mode with all interrupts
>   and all timecounters stopped.  More precisely, the jump is:
>   ACPI-fast and TSC: -1.000000 +- 10 uS
>   i8254:             -1.043000 +- 1 mS

I'm not sure how to do anything about this.  Sounds like a BIOS bug.

> - dynamic recalibration of cpu_tick_frequency has never worked.  This
>   is a MI bug, and only affects process times.  cpu_tick_frequency is
>   never adjusted downwards (except for a full recalibration).  Thus
>   any glitches in the cpu_tick clock (TSC on nx6325), e.g., from the
>   SMM bug or entering ddb) cause cpu_tick_frequency to creep or jump
>   upwards and never come down.

This reminds me -- the algorithm for estimating the cpu frequency needs 
improvement.  You had a patch you sent me that reduced its error by a 
lot.  Would you commit it?

> dev.cpu.0.freq: 1985
> dev.cpu.0.freq_levels: 1985/-1 1736/-1 1488/-1 1240/-1 992/-1 744/-1 
> 496/-1 248/-1
> 
> Once I used some performance/power-reduction config and got a list like 
> yours.
> 
> 1985 actually gives 1995 MHz.

Your freq estimation patch does better than this.

-- 
Nate
From brde at optusnet.com.au  Sat Jul  5 02:12:15 2008
From: brde at optusnet.com.au (Bruce Evans)
Date: Sat Jul  5 02:12:21 2008
Subject: HP/Compaq nx6325 clock "jumping around"
In-Reply-To: <486E4DE7.60807@root.org>
References: <20080702191827.GK1469@uriah.heep.sax.de>
	<20080703145049.S6189@delplex.bde.org> <486E4DE7.60807@root.org>
Message-ID: <20080705120027.G12725@delplex.bde.org>

On Fri, 4 Jul 2008, Nate Lawson wrote:

>> On Wed, 2 Jul 2008, Joerg Wunsch wrote:
>> ...
> Bruce Evans wrote:
>> I know of the following bugs in time on nx6325:
> ...
>
> This reminds me -- the algorithm for estimating the cpu frequency needs 
> improvement.  You had a patch you sent me that reduced its error by a lot. 
> Would you commit it?

I'm further than ever from committing this, since I'm not set up for svn.

I never merged this to the kernel.  Running it in userland on more SMP
machines shows the expected problems from the CPU not being pinnable in
userland.

>> dev.cpu.0.freq: 1985
>> dev.cpu.0.freq_levels: 1985/-1 1736/-1 1488/-1 1240/-1 992/-1 744/-1 496/-1 
>> 248/-1
>> 
>> Once I used some performance/power-reduction config and got a list like 
>> yours.
>> 
>> 1985 actually gives 1995 MHz.
>
> Your freq estimation patch does better than this.

Aren't the above frequencies just read from acpi read-only data?

I forgot to mention another MI problem with cpu_ticker frequency
recalibration: its sanity checks don't detect even the enormous transient
garbage caused by stopping clocks.  Apparently all the clocks used in
the sanity checks are stopped too synchronously.  Otherwise, the
recalibration is very accurate.

Bruce
From brde at optusnet.com.au  Sat Jul  5 07:57:53 2008
From: brde at optusnet.com.au (Bruce Evans)
Date: Sat Jul  5 07:57:59 2008
Subject: HP/Compaq nx6325 clock "jumping around"
In-Reply-To: <20080705000712.GF29380@server.vk2pj.dyndns.org>
References: <20080702191827.GK1469@uriah.heep.sax.de>
	<20080703145049.S6189@delplex.bde.org>
	<20080705000712.GF29380@server.vk2pj.dyndns.org>
Message-ID: <20080705175001.C7509@besplex.bde.org>

On Sat, 5 Jul 2008, Peter Jeremy wrote:

> On 2008-Jul-03 15:55:28 +1000, Bruce Evans <brde@optusnet.com.au> wrote:
>> - pressing the lid switch to turn the screen off makes the time jump by
>>   almost precisely 1 second using any timecounter.  The system appears
>>   to spend the 1 second in something like SMM mode with all interrupts
>>   and all timecounters stopped.  More precisely, the jump is:
>>   ACPI-fast and TSC: -1.000000 +- 10 uS
>>   i8254:             -1.043000 +- 1 mS
>
> My nx6125 with F.11 BIOS does something very similar but only in VTY
> mode - I don't see the time jump when running X (and I haven't tried
> measuring the jump to that accuracy).  Sometimes I see a time jump
> when switching between VTY and X.  Other than that, ntpd is quite
> happy with ACPI-fast.

You mentioned this a while ago.  I just tested it (again?).  The 1 second
jump was still there in X mode (old X).  There seemed to be a jump starting
X the first time, but not for restarts.  The 1 second jump sometimes caused
"calcru: runtime went backwards" messages.  I use "ntpdate -q <ntp-server>"
in a loop to measure jumps accurately (if they are isolated).  (This is
more accurate than ntptrace.)

Bruce
From nate at root.org  Sat Jul  5 17:26:26 2008
From: nate at root.org (Nate Lawson)
Date: Sat Jul  5 17:26:33 2008
Subject: HP/Compaq nx6325 clock "jumping around"
In-Reply-To: <20080705120027.G12725@delplex.bde.org>
References: <20080702191827.GK1469@uriah.heep.sax.de>
	<20080703145049.S6189@delplex.bde.org> <486E4DE7.60807@root.org>
	<20080705120027.G12725@delplex.bde.org>
Message-ID: <486FAEBB.7080505@root.org>

Bruce Evans wrote:
> On Fri, 4 Jul 2008, Nate Lawson wrote:
> 
>>> On Wed, 2 Jul 2008, Joerg Wunsch wrote:
>>> ...
>> Bruce Evans wrote:
>>> I know of the following bugs in time on nx6325:
>> ...
>>
>> This reminds me -- the algorithm for estimating the cpu frequency 
>> needs improvement.  You had a patch you sent me that reduced its error 
>> by a lot. Would you commit it?
> 
> I'm further than ever from committing this, since I'm not set up for svn.
> 
> I never merged this to the kernel.  Running it in userland on more SMP
> machines shows the expected problems from the CPU not being pinnable in
> userland.

I used it from the kernel and it worked fine but I was scared off by 
some questions you had regarding the edge cases where calibration might 
never complete.

>>> dev.cpu.0.freq: 1985
>>> dev.cpu.0.freq_levels: 1985/-1 1736/-1 1488/-1 1240/-1 992/-1 744/-1 
>>> 496/-1 248/-1
>>>
>>> Once I used some performance/power-reduction config and got a list 
>>> like yours.
>>>
>>> 1985 actually gives 1995 MHz.
>>
>> Your freq estimation patch does better than this.
> 
> Aren't the above frequencies just read from acpi read-only data?

Depends on the back-end driver being used.  dmesg | grep cpu will reveal 
it.  Some drivers like acpi_perf and est do have their own table. 
Others like p4tcc and acpi_throttle have to estimate it.

-- 
Nate
From peterjeremy at optushome.com.au  Mon Jul  7 00:00:24 2008
From: peterjeremy at optushome.com.au (Peter Jeremy)
Date: Mon Jul  7 00:00:31 2008
Subject: HP/Compaq nx6325 clock "jumping around"
In-Reply-To: <20080703145049.S6189@delplex.bde.org>
References: <20080702191827.GK1469@uriah.heep.sax.de>
	<20080703145049.S6189@delplex.bde.org>
Message-ID: <20080705000712.GF29380@server.vk2pj.dyndns.org>

On 2008-Jul-03 15:55:28 +1000, Bruce Evans <brde@optusnet.com.au> wrote:
>- pressing the lid switch to turn the screen off makes the time jump by
>   almost precisely 1 second using any timecounter.  The system appears
>   to spend the 1 second in something like SMM mode with all interrupts
>   and all timecounters stopped.  More precisely, the jump is:
>   ACPI-fast and TSC: -1.000000 +- 10 uS
>   i8254:             -1.043000 +- 1 mS

My nx6125 with F.11 BIOS does something very similar but only in VTY
mode - I don't see the time jump when running X (and I haven't tried
measuring the jump to that accuracy).  Sometimes I see a time jump
when switching between VTY and X.  Other than that, ntpd is quite
happy with ACPI-fast.

-- 
Peter Jeremy
Please excuse any delays as the result of my ISP's inability to implement
an MTA that is either RFC2821-compliant or matches their claimed behaviour.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-acpi/attachments/20080707/cee1d001/attachment.pgp
From bugmaster at FreeBSD.org  Mon Jul  7 11:06:54 2008
From: bugmaster at FreeBSD.org (FreeBSD bugmaster)
Date: Mon Jul  7 11:07:19 2008
Subject: Current problem reports assigned to freebsd-acpi@FreeBSD.org
Message-ID: <200807071106.m67B6r3n061874@freefall.freebsd.org>

Current FreeBSD problem reports
Critical problems
Serious problems

S Tracker      Resp.      Description
--------------------------------------------------------------------------------
o i386/54756   acpi       ACPI suspend/resume problem on CF-W2 laptop
o i386/55661   acpi       ACPI suspend/resume problem on ARMADA M700
o kern/56024   acpi       ACPI suspend drains battery while in S3
o i386/72566   acpi       ACPI, FreeBSD disables fan on Compaq Armada 1750
o i386/79081   acpi       ACPI suspend/resume not working on HP nx6110
o kern/81000   acpi       [apic] Via 8235 sound card worked great with FreeBSD 5
s kern/91038   acpi       [panic] [ata] [acpi] 6.0-RELEASE on Fujitsu Siemens Am
s i386/91748   acpi       acpi problem on Acer TravelMare 4652LMi (nvidia panic,
o kern/102252  acpi       acpi thermal does not work on Abit AW8D (intel 975)
o kern/104625  acpi       ACPI on ASUS A8N-32 SLI/ASUS P4P800 does not show ther
o kern/106924  acpi       [acpi] ACPI resume returns g_vfs_done() errors and ker
o kern/108954  acpi       [acpi] 'sleep(1)' sleeps >1 seconds when speedstep (Cx
o i386/114562  acpi       [acpi] cardbus is dead after s3 on Thinkpad T43 with a
o kern/116939  acpi       [acpi] PCI-to-PCI misconfigured for bus three and can 
o kern/118973  acpi       [acpi]: Kernel panic with acpi boot
o kern/119200  acpi       [acpi] Lid close switch suspends CPU for 1 second on H
o kern/119356  acpi       [acpi]: i386 ACPI wakeup not work due resource exhaust
o kern/120953  acpi       [acpi]: FreeBSD 6.3 Release:  acpi_tz0: _TMP value is 
f kern/121454  acpi       [pst] Promise SuperTrak SX6000 does not load during bo

19 problems total.

Non-critical problems

S Tracker      Resp.      Description
--------------------------------------------------------------------------------
f kern/67309   acpi       zzz reboot computer (ACPI S3)
o i386/69750   acpi       Boot without ACPI failed on ASUS L5
s kern/73823   acpi       [request] acpi / power-on by timer support
o kern/76950   acpi       ACPI wrongly blacklisted on Micron ClientPro 766Xi sys
o i386/83018   acpi       [install] Installer will not boot on Asus P4S8X BIOS 1
o kern/89411   acpi       [acpi] acpiconf bug
s kern/90243   acpi       Laptop fan doesn't turn off (ACPI enabled) (Packard Be
o kern/97383   acpi       Volume buttons on IBM Thinkpad crash system with ACPI
o kern/105537  acpi       [acpi] problems in acpi on HP Compaq nc6320
o kern/108017  acpi       [acpi]: Acer Aspire 5600
o kern/108488  acpi       [acpi] ACPI-1304: *** Error: Method execution failed
o kern/108581  acpi       [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argume
o kern/108695  acpi       [acpi]: Fatal trap 9: general protection fault when in
s kern/112544  acpi       [acpi] [patch] Add High Precision Event Timer Driver f
o kern/114165  acpi       [acpi] Dell C810 - ACPI problem
o kern/117605  acpi       [acpi] [request] add debug.cpufreq.highest
o kern/120515  acpi       [acpi] [patch] acpi_alloc_wakeup_handler: can't alloc 
o kern/121102  acpi       [acpi_fujitsu] [patch] update acpi_fujitsu for the P80
o kern/121504  acpi       [patch] Correctly set hw.acpi.osname on certain machin
f amd64/122521 acpi       ACPI Error after upgrade to 7.0
o kern/123039  acpi       [acpi] ACPI AML_BUFFER_LIMIT errors during boot
o kern/124223  acpi       [acpi] [patch] acpi_battery.c -- Notify user-defined c
o kern/124412  acpi       [acpi] power off error on Toshiba M40 laptop
o kern/124744  acpi       [acpi] [patch] incorrect _BST result validation for To

24 problems total.

From p.pisati at oltrelinux.com  Mon Jul  7 20:25:55 2008
From: p.pisati at oltrelinux.com (Paolo Pisati)
Date: Mon Jul  7 20:26:05 2008
Subject: ACPI woes on HP 2133 Mininote
Message-ID: <20080707195557.GA36048@tin.it>

Dear guys,

i've some problems with ACPI in FreeBSD and my HP 2133 Mininote.

Basically, when i try to query the ACPI about the laptop's temperature i get this:

piso@nanobook:~ >sysctl -a | grep temp
net.inet6.ip6.use_tempaddr: 0
net.inet6.ip6.temppltime: 86400
net.inet6.ip6.tempvltime: 604800
net.inet6.ip6.prefer_tempaddr: 0
hw.acpi.thermal.tz0.temperature: 58.0C
^C^C^C^C^C^C^C^C^C^C^C             <---- here the console is stuck
ACPI Exception (exutils-0382): AE_TIME, Could not acquire
Global Lock [20070320]
ACPI Exception (exutils-0382): AE_TIME, Could not acquire Global Lock [20070320]

Moreover after a bit of usage my laptop become so hot that it's impossible to hold.
Here is the a dmesg snippet about an ACPI error i get at boot time:

ACPI Error (exmutex-0479): Cannot release Mutex [_GL_], not acquired [20070320]
ACPI Error (psparse-0626): Method parse/execution failed [\\_SB_.PCI0.SBRG.SMAB] (Node 0xc48f2800), AE_AML_MUTEX_NOT_ACQUIRED
ACPI Error (psparse-0626): Method parse/execution failed [\\_SB_.PCI0.ACEL.AJAL] (Node 0xc48e8560), AE_AML_MUTEX_NOT_ACQUIRED
ACPI Error (psparse-0626): Method parse/execution failed [\\_SB_.PCI0.AC0_._PSR] (Node 0xc48f04c0), AE_AML_MUTEX_NOT_ACQUIRED

For full verbose dmesg see here: http://people.freebsd.org/~piso/hp2133-dmesg-verbose.txt
and for more info about my laptop see here: http://gentoo-wiki.com/HARDWARE_HP_2133_Mini-Note_PC 
-- 
bye,
P.
From patttern at gmail.com  Sat Jul 12 23:09:03 2008
From: patttern at gmail.com (=?ISO-8859-1?Q?Pattern=AE?=)
Date: Sat Jul 12 23:09:09 2008
Subject: Trouble with ACPI on Toshiba Satellite A210
Message-ID: <107cc88f0807121541y6f1f9385s600d32bc98c0b40b@mail.gmail.com>

Hi!
I have notebook Toshiba Satellite A210-16F with configuration^
CPU: AMD Turion 64 x2 Mobile Technology TL-58 1,9GHz
RAM: 2GB
HDD: Hitachi HTS542516K9SA00
DVD: HL-DT-ST DVDRAM GSA-T20N/WT03
I trying install FreeBSD 7.0 versions AMD64 (
ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/ISO-IMAGES/7.0/) and i386 (
ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/ISO-IMAGES/7.0/) (bootonly
and disk1 for both). After booting with ACPI, sysinstall don't find HDD. I
can install FreeBSD only without ACPI with distributive of i386.
After install in normal booting with ACPI (point 1 in beasty-boot console),
system don't find HDD too.
This link on dmesg with acpi (http://www.8855.ru/acpi/dmesg-with_acpi.log)
(10kb). Kernel build with option ACPI_DEBUG=1.
But if booting without ACPI (point 2 in beasty-boot console), HDD avaible.
This link on dmesg without acpi (
http://www.8855.ru/acpi/dmesg-without_acpi.log) (9kb)
I can't sending "sysctl hw.acpi", because with ACPI system don't loading,
but without ACPI sysctl haven't information about it.
This link on dump ASL without acpi (
http://www.8855.ru/acpi/patttern-toshiba_a210_16f-without_acpi.asl) (287kb)
Please, help me correct this trouble.
Sorry for my english (i'm russian)
Thanks.
From bugmaster at FreeBSD.org  Mon Jul 14 11:06:54 2008
From: bugmaster at FreeBSD.org (FreeBSD bugmaster)
Date: Mon Jul 14 11:07:03 2008
Subject: Current problem reports assigned to freebsd-acpi@FreeBSD.org
Message-ID: <200807141106.m6EB6rJt014325@freefall.freebsd.org>

Current FreeBSD problem reports
Critical problems
Serious problems

S Tracker      Resp.      Description
--------------------------------------------------------------------------------
o i386/54756   acpi       ACPI suspend/resume problem on CF-W2 laptop
o i386/55661   acpi       ACPI suspend/resume problem on ARMADA M700
o kern/56024   acpi       ACPI suspend drains battery while in S3
o i386/72566   acpi       ACPI, FreeBSD disables fan on Compaq Armada 1750
o i386/79081   acpi       ACPI suspend/resume not working on HP nx6110
o kern/81000   acpi       [apic] Via 8235 sound card worked great with FreeBSD 5
s kern/91038   acpi       [panic] [ata] [acpi] 6.0-RELEASE on Fujitsu Siemens Am
s i386/91748   acpi       acpi problem on Acer TravelMare 4652LMi (nvidia panic,
o kern/102252  acpi       acpi thermal does not work on Abit AW8D (intel 975)
o kern/104625  acpi       ACPI on ASUS A8N-32 SLI/ASUS P4P800 does not show ther
o kern/106924  acpi       [acpi] ACPI resume returns g_vfs_done() errors and ker
o kern/108954  acpi       [acpi] 'sleep(1)' sleeps >1 seconds when speedstep (Cx
o i386/114562  acpi       [acpi] cardbus is dead after s3 on Thinkpad T43 with a
o kern/116939  acpi       [acpi] PCI-to-PCI misconfigured for bus three and can 
o kern/118973  acpi       [acpi]: Kernel panic with acpi boot
o kern/119200  acpi       [acpi] Lid close switch suspends CPU for 1 second on H
o kern/119356  acpi       [acpi]: i386 ACPI wakeup not work due resource exhaust
o kern/120953  acpi       [acpi]: FreeBSD 6.3 Release:  acpi_tz0: _TMP value is 
f kern/121454  acpi       [pst] Promise SuperTrak SX6000 does not load during bo

19 problems total.

Non-critical problems

S Tracker      Resp.      Description
--------------------------------------------------------------------------------
f kern/67309   acpi       zzz reboot computer (ACPI S3)
o i386/69750   acpi       Boot without ACPI failed on ASUS L5
s kern/73823   acpi       [request] acpi / power-on by timer support
o kern/76950   acpi       ACPI wrongly blacklisted on Micron ClientPro 766Xi sys
o i386/83018   acpi       [install] Installer will not boot on Asus P4S8X BIOS 1
o kern/89411   acpi       [acpi] acpiconf bug
s kern/90243   acpi       Laptop fan doesn't turn off (ACPI enabled) (Packard Be
o kern/97383   acpi       Volume buttons on IBM Thinkpad crash system with ACPI
o kern/105537  acpi       [acpi] problems in acpi on HP Compaq nc6320
o kern/108017  acpi       [acpi]: Acer Aspire 5600
o kern/108488  acpi       [acpi] ACPI-1304: *** Error: Method execution failed
o kern/108581  acpi       [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argume
o kern/108695  acpi       [acpi]: Fatal trap 9: general protection fault when in
s kern/112544  acpi       [acpi] [patch] Add High Precision Event Timer Driver f
o kern/114165  acpi       [acpi] Dell C810 - ACPI problem
o kern/117605  acpi       [acpi] [request] add debug.cpufreq.highest
o kern/120515  acpi       [acpi] [patch] acpi_alloc_wakeup_handler: can't alloc 
o kern/121102  acpi       [acpi_fujitsu] [patch] update acpi_fujitsu for the P80
o kern/121504  acpi       [patch] Correctly set hw.acpi.osname on certain machin
f amd64/122521 acpi       ACPI Error after upgrade to 7.0
o kern/123039  acpi       [acpi] ACPI AML_BUFFER_LIMIT errors during boot
o kern/124223  acpi       [acpi] [patch] acpi_battery.c -- Notify user-defined c
o kern/124412  acpi       [acpi] power off error on Toshiba M40 laptop
o kern/124744  acpi       [acpi] [patch] incorrect _BST result validation for To

24 problems total.

From sgk at troutmask.apl.washington.edu  Tue Jul 15 22:24:50 2008
From: sgk at troutmask.apl.washington.edu (Steve Kargl)
Date: Tue Jul 15 22:24:56 2008
Subject: What version of acpi is supported?
Message-ID: <20080715222449.GA82931@troutmask.apl.washington.edu>

I have several ASUS KFSN4-DRE motherboards.  The BIOS
allows one to select acpi version 1, 2, or 3 where 3
is the defaults.  Under heavy load and acpi v3, these
motherboards shut themselves off.  The boards appear
to be stable if I select v1.  So what, version of 
acpi does FreeBSD support?

-- 
Steve
From sgk at troutmask.apl.washington.edu  Tue Jul 15 22:36:38 2008
From: sgk at troutmask.apl.washington.edu (Steve Kargl)
Date: Tue Jul 15 22:36:45 2008
Subject: What version of acpi is supported?
In-Reply-To: <487D24EC.30900@root.org>
References: <20080715222449.GA82931@troutmask.apl.washington.edu>
	<487D24EC.30900@root.org>
Message-ID: <20080715223638.GB82931@troutmask.apl.washington.edu>

On Tue, Jul 15, 2008 at 03:30:04PM -0700, Nate Lawson wrote:
> Steve Kargl wrote:
> >I have several ASUS KFSN4-DRE motherboards.  The BIOS
> >allows one to select acpi version 1, 2, or 3 where 3
> >is the defaults.  Under heavy load and acpi v3, these
> >motherboards shut themselves off.  The boards appear
> >to be stable if I select v1.  So what, version of 
> >acpi does FreeBSD support?
> >
>
> Most of 1, a lot of 2, a little of 3.

So does v2 or 3 must have a (low?) thermal protection
mechanism that shuts down a system?  And, can the
threshold be tweaked?
 
-- 
Steve
From nate at root.org  Tue Jul 15 22:48:18 2008
From: nate at root.org (Nate Lawson)
Date: Tue Jul 15 22:48:25 2008
Subject: What version of acpi is supported?
In-Reply-To: <20080715222449.GA82931@troutmask.apl.washington.edu>
References: <20080715222449.GA82931@troutmask.apl.washington.edu>
Message-ID: <487D24EC.30900@root.org>

Most of 1, a lot of 2, a little of 3.

Steve Kargl wrote:
> I have several ASUS KFSN4-DRE motherboards.  The BIOS
> allows one to select acpi version 1, 2, or 3 where 3
> is the defaults.  Under heavy load and acpi v3, these
> motherboards shut themselves off.  The boards appear
> to be stable if I select v1.  So what, version of 
> acpi does FreeBSD support?
> 

-- 
Nate
From nate at root.org  Tue Jul 15 23:02:31 2008
From: nate at root.org (Nate Lawson)
Date: Tue Jul 15 23:02:38 2008
Subject: What version of acpi is supported?
In-Reply-To: <20080715223638.GB82931@troutmask.apl.washington.edu>
References: <20080715222449.GA82931@troutmask.apl.washington.edu>
	<487D24EC.30900@root.org>
	<20080715223638.GB82931@troutmask.apl.washington.edu>
Message-ID: <487D2C87.3020209@root.org>

Steve Kargl wrote:
> On Tue, Jul 15, 2008 at 03:30:04PM -0700, Nate Lawson wrote:
>> Steve Kargl wrote:
>>> I have several ASUS KFSN4-DRE motherboards.  The BIOS
>>> allows one to select acpi version 1, 2, or 3 where 3
>>> is the defaults.  Under heavy load and acpi v3, these
>>> motherboards shut themselves off.  The boards appear
>>> to be stable if I select v1.  So what, version of 
>>> acpi does FreeBSD support?
>>>
>> Most of 1, a lot of 2, a little of 3.
> 
> So does v2 or 3 must have a (low?) thermal protection
> mechanism that shuts down a system?  And, can the
> threshold be tweaked?

It doesn't work that way.  When you specify a version to the BIOS, it 
changes the AML (byte code) that it exports to the OS.  Depending on 
what we do (or don't do) with it, the BIOS is deciding at some point it 
doesn't like the OS behavior and shuts down.  It could be anything. 
You'd have to look at the AML to figure out what we're poking or not 
poking that the BIOS isn't happy with.

Are you loading cpufreq?

-- 
Nate
From sgk at troutmask.apl.washington.edu  Tue Jul 15 23:14:02 2008
From: sgk at troutmask.apl.washington.edu (Steve Kargl)
Date: Tue Jul 15 23:14:08 2008
Subject: What version of acpi is supported?
In-Reply-To: <487D2C87.3020209@root.org>
References: <20080715222449.GA82931@troutmask.apl.washington.edu>
	<487D24EC.30900@root.org>
	<20080715223638.GB82931@troutmask.apl.washington.edu>
	<487D2C87.3020209@root.org>
Message-ID: <20080715231401.GA83158@troutmask.apl.washington.edu>

On Tue, Jul 15, 2008 at 04:02:31PM -0700, Nate Lawson wrote:
> Steve Kargl wrote:
> >On Tue, Jul 15, 2008 at 03:30:04PM -0700, Nate Lawson wrote:
> >>Steve Kargl wrote:
> >>>I have several ASUS KFSN4-DRE motherboards.  The BIOS
> >>>allows one to select acpi version 1, 2, or 3 where 3
> >>>is the defaults.  Under heavy load and acpi v3, these
> >>>motherboards shut themselves off.  The boards appear
> >>>to be stable if I select v1.  So what, version of 
> >>>acpi does FreeBSD support?
> >>>
> >>Most of 1, a lot of 2, a little of 3.
> >
> >So does v2 or 3 must have a (low?) thermal protection
> >mechanism that shuts down a system?  And, can the
> >threshold be tweaked?
> 
> It doesn't work that way.  When you specify a version to the BIOS, it 
> changes the AML (byte code) that it exports to the OS.  Depending on 
> what we do (or don't do) with it, the BIOS is deciding at some point it 
> doesn't like the OS behavior and shuts down.  It could be anything. 
> You'd have to look at the AML to figure out what we're poking or not 
> poking that the BIOS isn't happy with.

I was afraid you (or someone) would say something like the above.
I used acpidump to get an ASL file, but it was after I booted with
v1.  It appears that I have a lot to learn about the crypted ASL.

> 
> Are you loading cpufreq?
> 

No.

-- 
Steve
From nate at root.org  Tue Jul 15 23:19:25 2008
From: nate at root.org (Nate Lawson)
Date: Tue Jul 15 23:19:35 2008
Subject: What version of acpi is supported?
In-Reply-To: <20080715231401.GA83158@troutmask.apl.washington.edu>
References: <20080715222449.GA82931@troutmask.apl.washington.edu>
	<487D24EC.30900@root.org>
	<20080715223638.GB82931@troutmask.apl.washington.edu>
	<487D2C87.3020209@root.org>
	<20080715231401.GA83158@troutmask.apl.washington.edu>
Message-ID: <487D307E.5020501@root.org>

Steve Kargl wrote:
> On Tue, Jul 15, 2008 at 04:02:31PM -0700, Nate Lawson wrote:
>> Steve Kargl wrote:
>>> On Tue, Jul 15, 2008 at 03:30:04PM -0700, Nate Lawson wrote:
>>>> Steve Kargl wrote:
>>>>> I have several ASUS KFSN4-DRE motherboards.  The BIOS
>>>>> allows one to select acpi version 1, 2, or 3 where 3
>>>>> is the defaults.  Under heavy load and acpi v3, these
>>>>> motherboards shut themselves off.  The boards appear
>>>>> to be stable if I select v1.  So what, version of 
>>>>> acpi does FreeBSD support?
>>>>>
>>>> Most of 1, a lot of 2, a little of 3.
>>> So does v2 or 3 must have a (low?) thermal protection
>>> mechanism that shuts down a system?  And, can the
>>> threshold be tweaked?
>> It doesn't work that way.  When you specify a version to the BIOS, it 
>> changes the AML (byte code) that it exports to the OS.  Depending on 
>> what we do (or don't do) with it, the BIOS is deciding at some point it 
>> doesn't like the OS behavior and shuts down.  It could be anything. 
>> You'd have to look at the AML to figure out what we're poking or not 
>> poking that the BIOS isn't happy with.
> 
> I was afraid you (or someone) would say something like the above.
> I used acpidump to get an ASL file, but it was after I booted with
> v1.  It appears that I have a lot to learn about the crypted ASL.
> 
>> Are you loading cpufreq?
>>
> 
> No.

It might be that your BIOS requires you to have cpufreq if you ask it 
for acpi v2+.

-Nate
From sgk at troutmask.apl.washington.edu  Tue Jul 15 23:54:06 2008
From: sgk at troutmask.apl.washington.edu (Steve Kargl)
Date: Tue Jul 15 23:54:12 2008
Subject: What version of acpi is supported?
In-Reply-To: <487D307E.5020501@root.org>
References: <20080715222449.GA82931@troutmask.apl.washington.edu>
	<487D24EC.30900@root.org>
	<20080715223638.GB82931@troutmask.apl.washington.edu>
	<487D2C87.3020209@root.org>
	<20080715231401.GA83158@troutmask.apl.washington.edu>
	<487D307E.5020501@root.org>
Message-ID: <20080715235405.GA83380@troutmask.apl.washington.edu>

On Tue, Jul 15, 2008 at 04:19:26PM -0700, Nate Lawson wrote:
> Steve Kargl wrote:
> >On Tue, Jul 15, 2008 at 04:02:31PM -0700, Nate Lawson wrote:
> >
> >>Are you loading cpufreq?
> >>
> >
> >No.
> 
> It might be that your BIOS requires you to have cpufreq if you ask it 
> for acpi v2+.
> 

Okay, I rebuilt my kernel (I don't use modules) and reset
the BIOS to version 3.  I'll see if the test node shuts
itself down.

Thanks for your input.

-- 
Steve
From freebsd at meijome.net  Wed Jul 16 08:20:42 2008
From: freebsd at meijome.net (Norberto Meijome)
Date: Wed Jul 16 08:20:48 2008
Subject: What version of acpi is supported?
In-Reply-To: <20080715235405.GA83380@troutmask.apl.washington.edu>
References: <20080715222449.GA82931@troutmask.apl.washington.edu>
	<487D24EC.30900@root.org>
	<20080715223638.GB82931@troutmask.apl.washington.edu>
	<487D2C87.3020209@root.org>
	<20080715231401.GA83158@troutmask.apl.washington.edu>
	<487D307E.5020501@root.org>
	<20080715235405.GA83380@troutmask.apl.washington.edu>
Message-ID: <20080716175355.2e200d75@ayiin>

On Tue, 15 Jul 2008 16:54:05 -0700
Steve Kargl <sgk@troutmask.apl.washington.edu> wrote:

> Okay, I rebuilt my kernel (I don't use modules) and reset
> the BIOS to version 3.  I'll see if the test node shuts
> itself down.

kldload cpufreq

should have worked as well without rebuilding your kernel :)


_________________________
{Beto|Norberto|Numard} Meijome

"The only people that never change are the stupid and the dead"
  Jorge Luis Borges.

I speak for myself, not my employer. Contents may be hot. Slippery when wet. Reading disclaimers makes you go blind. Writing them is worse. You have been Warned.
From patttern at gmail.com  Wed Jul 16 20:30:56 2008
From: patttern at gmail.com (=?ISO-8859-1?Q?Pattern=AE?=)
Date: Wed Jul 16 20:31:02 2008
Subject: Trouble with ACPI on Toshiba Satellite A210
Message-ID: <107cc88f0807161330i5d6f0069h842c20e3f334dca9@mail.gmail.com>

I updated system to 7.0-STABLE
uname -a
FreeBSD toshiba 7.0-STABLE FreeBSD 7.0-STABLE #0: Wed Jul 16 21:10:51 MSD
2008     pattern@toshiba:/usr/obj/usr/src/sys/TOSHIBA  i386
pciconf -lv (http://www.8855.ru/acpi/pciconf-stable-wo_acpi.log)
devinfo -u (http://www.8855.ru/acpi/devinfo-stable-wo_acpi.log)
ASL for Toshiba A210-16F (
http://www.8855.ru/acpi/patttern-toshiba_a210_16f-stable-wo_acpi.asl)
dmesg -a with boot verbose (
http://www.8855.ru/acpi/dmesg-stable-without_acpi.log)
All information was get without ACPI (in /boot/loader.conf option
hint.acpi.0.disabled=1), because HDD detected only in with this option.
From bugmaster at FreeBSD.org  Mon Jul 21 11:06:51 2008
From: bugmaster at FreeBSD.org (FreeBSD bugmaster)
Date: Mon Jul 21 11:06:57 2008
Subject: Current problem reports assigned to freebsd-acpi@FreeBSD.org
Message-ID: <200807211106.m6LB6oue031779@freefall.freebsd.org>

Current FreeBSD problem reports
Critical problems
Serious problems

S Tracker      Resp.      Description
--------------------------------------------------------------------------------
o i386/54756   acpi       ACPI suspend/resume problem on CF-W2 laptop
o i386/55661   acpi       ACPI suspend/resume problem on ARMADA M700
o kern/56024   acpi       ACPI suspend drains battery while in S3
o i386/72566   acpi       ACPI, FreeBSD disables fan on Compaq Armada 1750
o i386/79081   acpi       ACPI suspend/resume not working on HP nx6110
o kern/81000   acpi       [apic] Via 8235 sound card worked great with FreeBSD 5
s kern/91038   acpi       [panic] [ata] [acpi] 6.0-RELEASE on Fujitsu Siemens Am
s i386/91748   acpi       acpi problem on Acer TravelMare 4652LMi (nvidia panic,
o kern/102252  acpi       acpi thermal does not work on Abit AW8D (intel 975)
o kern/104625  acpi       ACPI on ASUS A8N-32 SLI/ASUS P4P800 does not show ther
o kern/106924  acpi       [acpi] ACPI resume returns g_vfs_done() errors and ker
o kern/108954  acpi       [acpi] 'sleep(1)' sleeps >1 seconds when speedstep (Cx
o i386/114562  acpi       [acpi] cardbus is dead after s3 on Thinkpad T43 with a
o kern/116939  acpi       [acpi] PCI-to-PCI misconfigured for bus three and can 
o kern/118973  acpi       [acpi]: Kernel panic with acpi boot
o kern/119200  acpi       [acpi] Lid close switch suspends CPU for 1 second on H
o kern/119356  acpi       [acpi]: i386 ACPI wakeup not work due resource exhaust
o kern/120953  acpi       [acpi]: FreeBSD 6.3 Release:  acpi_tz0: _TMP value is 
f kern/121454  acpi       [pst] Promise SuperTrak SX6000 does not load during bo

19 problems total.

Non-critical problems

S Tracker      Resp.      Description
--------------------------------------------------------------------------------
f kern/67309   acpi       zzz reboot computer (ACPI S3)
o i386/69750   acpi       Boot without ACPI failed on ASUS L5
s kern/73823   acpi       [request] acpi / power-on by timer support
o kern/76950   acpi       ACPI wrongly blacklisted on Micron ClientPro 766Xi sys
o i386/83018   acpi       [install] Installer will not boot on Asus P4S8X BIOS 1
o kern/89411   acpi       [acpi] acpiconf bug
s kern/90243   acpi       Laptop fan doesn't turn off (ACPI enabled) (Packard Be
o kern/97383   acpi       Volume buttons on IBM Thinkpad crash system with ACPI
o kern/105537  acpi       [acpi] problems in acpi on HP Compaq nc6320
o kern/108017  acpi       [acpi]: Acer Aspire 5600
o kern/108488  acpi       [acpi] ACPI-1304: *** Error: Method execution failed
o kern/108581  acpi       [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argume
o kern/108695  acpi       [acpi]: Fatal trap 9: general protection fault when in
s kern/112544  acpi       [acpi] [patch] Add High Precision Event Timer Driver f
o kern/114165  acpi       [acpi] Dell C810 - ACPI problem
o kern/117605  acpi       [acpi] [request] add debug.cpufreq.highest
o kern/120515  acpi       [acpi] [patch] acpi_alloc_wakeup_handler: can't alloc 
o kern/121102  acpi       [acpi_fujitsu] [patch] update acpi_fujitsu for the P80
o kern/121504  acpi       [patch] Correctly set hw.acpi.osname on certain machin
f amd64/122521 acpi       ACPI Error after upgrade to 7.0
o kern/123039  acpi       [acpi] ACPI AML_BUFFER_LIMIT errors during boot
o kern/124223  acpi       [acpi] [patch] acpi_battery.c -- Notify user-defined c
o kern/124412  acpi       [acpi] power off error on Toshiba M40 laptop
o kern/124744  acpi       [acpi] [patch] incorrect _BST result validation for To

24 problems total.

From brock at cottonwoodcomputer.com  Tue Jul 22 16:35:43 2008
From: brock at cottonwoodcomputer.com (Brock Williams)
Date: Tue Jul 22 16:35:52 2008
Subject: acpi no sound, acpi disabled no serial on IBM kiosk
Message-ID: <200807220958.55060.brock@cottonwoodcomputer.com>

Skipped content of type multipart/mixed-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-acpi/attachments/20080722/71b8572f/attachment.pgp
From patttern at gmail.com  Tue Jul 22 20:30:54 2008
From: patttern at gmail.com (=?ISO-8859-1?Q?Pattern=AE?=)
Date: Tue Jul 22 20:31:01 2008
Subject: Trouble with ACPI on Toshiba Satellite A210
Message-ID: <107cc88f0807221330h6c182389l16b0a5f2e39196f@mail.gmail.com>

I fixed this trouble.
This is original ACPIDUMP file for Toshiba A210-16F (
http://www.8855.ru/acpi/fixed/pattern_toshiba-a210-16f_orig.asl )
This is DIFF file of fixes (
http://www.8855.ru/acpi/fixed/toshiba-a210-16f.diff )
dmesg -a (with verbose) ( http://www.8855.ru/acpi/fixed/dmesg_verb_acpi.log
 )
pciconf -lv ( http://www.8855.ru/acpi/fixed/pciconf_acpi.log )
From jhb at freebsd.org  Tue Jul 22 21:00:27 2008
From: jhb at freebsd.org (John Baldwin)
Date: Tue Jul 22 21:00:34 2008
Subject: acpi no sound, acpi disabled no serial on IBM kiosk
In-Reply-To: <200807220958.55060.brock@cottonwoodcomputer.com>
References: <200807220958.55060.brock@cottonwoodcomputer.com>
Message-ID: <200807221353.07575.jhb@freebsd.org>

On Tuesday 22 July 2008 11:58:51 am Brock Williams wrote:
> I'm trying to get our point of sale product ported to run on then new IBM 
> Anyplace Kiosks running FreeBSD 7.0.  When we leave ACPI enabled, the 
> onboard sound works but the serial ports aren't detected.  When we disable 
> ACPI, the serial ports work great but the sound doesn't work.
> 
> I've made the dmesg and devinfo both with and without acpi, sysctl hw.acpi, 
> and the asl available here:
> http://cotcomsol.com/files/acpi_info.tgz
> 
> I've also attached the 2 dmesg outputs here.  Anyone have any ideas what 
> might be going on?  I can't figure it out.  Everything is enabled in the 
> BIOS and we have checked that the version is the lastest available...

Looks like your serial ports are there in the ACPI case, but they are at sio0, 
sio1, and sio2.  In the non-ACPI case the hints cause the serial ports to 
show up at sio0, sio3, and sio4 instead.

-- 
John Baldwin
From brock at cottonwoodcomputer.com  Tue Jul 22 21:28:52 2008
From: brock at cottonwoodcomputer.com (Brock Williams)
Date: Tue Jul 22 21:29:05 2008
Subject: acpi no sound, acpi disabled no serial on IBM kiosk
In-Reply-To: <200807221353.07575.jhb@freebsd.org>
References: <200807220958.55060.brock@cottonwoodcomputer.com>
	<200807221353.07575.jhb@freebsd.org>
Message-ID: <200807221528.49104.brock@cottonwoodcomputer.com>

Yeah, I guess I should have said more about the problem.  in the ACPI case 
I do see the devices there, but they don't work.  For example, the machine 
has an elotouch touchscreen which works great w/o ACPI but doesn't with.  
When I try to cat the device with ACPI enabled,  I get nothing.  Without 
acpi I get the expected touchscreen data when touching the screen.  We 
also have a dallas ibutton reader hooked up to another port and it acts 
the same way.

Brock

On Tuesday 22 July 2008 11:53:07 am John Baldwin wrote:
> On Tuesday 22 July 2008 11:58:51 am Brock Williams wrote:
> > I'm trying to get our point of sale product ported to run on then new
> > IBM Anyplace Kiosks running FreeBSD 7.0.  When we leave ACPI enabled,
> > the onboard sound works but the serial ports aren't detected.  When we
> > disable ACPI, the serial ports work great but the sound doesn't work.
> >
> > I've made the dmesg and devinfo both with and without acpi, sysctl
> > hw.acpi, and the asl available here:
> > http://cotcomsol.com/files/acpi_info.tgz
> >
> > I've also attached the 2 dmesg outputs here.  Anyone have any ideas
> > what might be going on?  I can't figure it out.  Everything is enabled
> > in the BIOS and we have checked that the version is the lastest
> > available...
>
> Looks like your serial ports are there in the ACPI case, but they are at
> sio0, sio1, and sio2.  In the non-ACPI case the hints cause the serial
> ports to show up at sio0, sio3, and sio4 instead.

-- 
Brock Williams  brock@cottonwoodcomputer.com
Cottonwood Computer Solutions, Inc.
www.cotcomsol.com 406-896-4910
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-acpi/attachments/20080722/2d48d6ea/attachment.pgp
From jhb at freebsd.org  Tue Jul 22 22:18:31 2008
From: jhb at freebsd.org (John Baldwin)
Date: Tue Jul 22 22:18:38 2008
Subject: acpi no sound, acpi disabled no serial on IBM kiosk
In-Reply-To: <200807221528.49104.brock@cottonwoodcomputer.com>
References: <200807220958.55060.brock@cottonwoodcomputer.com>
	<200807221353.07575.jhb@freebsd.org>
	<200807221528.49104.brock@cottonwoodcomputer.com>
Message-ID: <200807221813.41431.jhb@freebsd.org>

On Tuesday 22 July 2008 05:28:45 pm Brock Williams wrote:
> Yeah, I guess I should have said more about the problem.  in the ACPI case 
> I do see the devices there, but they don't work.  For example, the machine 
> has an elotouch touchscreen which works great w/o ACPI but doesn't with.  
> When I try to cat the device with ACPI enabled,  I get nothing.  Without 
> acpi I get the expected touchscreen data when touching the screen.  We 
> also have a dallas ibutton reader hooked up to another port and it acts 
> the same way.

Hmm, they seem to have all the same I/O resources (ports and IRQs), so I don't 
see anything that would make them not work.  Also, there isn't anything in 
the AML for these devices that I can see that would help (no _INI or _REG 
methods, etc.).

> Brock
> 
> On Tuesday 22 July 2008 11:53:07 am John Baldwin wrote:
> > On Tuesday 22 July 2008 11:58:51 am Brock Williams wrote:
> > > I'm trying to get our point of sale product ported to run on then new
> > > IBM Anyplace Kiosks running FreeBSD 7.0.  When we leave ACPI enabled,
> > > the onboard sound works but the serial ports aren't detected.  When we
> > > disable ACPI, the serial ports work great but the sound doesn't work.
> > >
> > > I've made the dmesg and devinfo both with and without acpi, sysctl
> > > hw.acpi, and the asl available here:
> > > http://cotcomsol.com/files/acpi_info.tgz
> > >
> > > I've also attached the 2 dmesg outputs here.  Anyone have any ideas
> > > what might be going on?  I can't figure it out.  Everything is enabled
> > > in the BIOS and we have checked that the version is the lastest
> > > available...
> >
> > Looks like your serial ports are there in the ACPI case, but they are at
> > sio0, sio1, and sio2.  In the non-ACPI case the hints cause the serial
> > ports to show up at sio0, sio3, and sio4 instead.
> 
> -- 
> Brock Williams  brock@cottonwoodcomputer.com
> Cottonwood Computer Solutions, Inc.
> www.cotcomsol.com 406-896-4910
> 



-- 
John Baldwin
From brock at cottonwoodcomputer.com  Tue Jul 22 22:52:47 2008
From: brock at cottonwoodcomputer.com (Brock Williams)
Date: Tue Jul 22 22:52:53 2008
Subject: acpi no sound, acpi disabled no serial on IBM kiosk
In-Reply-To: <4886639E.4050201@root.org>
References: <200807220958.55060.brock@cottonwoodcomputer.com>
	<200807221813.41431.jhb@freebsd.org> <4886639E.4050201@root.org>
Message-ID: <200807221652.43618.brock@cottonwoodcomputer.com>

On Tuesday 22 July 2008 4:47:58 pm Nate Lawson wrote:
> John Baldwin wrote:
> > On Tuesday 22 July 2008 05:28:45 pm Brock Williams wrote:
> >> Yeah, I guess I should have said more about the problem.  in the ACPI
> >> case I do see the devices there, but they don't work.  For example,
> >> the machine has an elotouch touchscreen which works great w/o ACPI
> >> but doesn't with. When I try to cat the device with ACPI enabled,  I
> >> get nothing.  Without acpi I get the expected touchscreen data when
> >> touching the screen.  We also have a dallas ibutton reader hooked up
> >> to another port and it acts the same way.
> >
> > Hmm, they seem to have all the same I/O resources (ports and IRQs), so
> > I don't see anything that would make them not work.  Also, there isn't
> > anything in the AML for these devices that I can see that would help
> > (no _INI or _REG methods, etc.).
>
> Just to confirm -- you are switching the device names when you "cat the
> device", right (sio0, 1, 2)?

Yep, I've tried cat'ing every cuad device that shows up, and I can't get 
data out of any of them when I enable acpi. Also while catting with ACPI I 
regularly get a message like:

sio1: 5 more silo overflows (total 5)

Thanks for the help,

Brock


-- 
Brock Williams  brock@cottonwoodcomputer.com
Cottonwood Computer Solutions, Inc.
www.cotcomsol.com 406-896-4910
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-acpi/attachments/20080722/2196f7ac/attachment-0001.pgp
From nate at root.org  Tue Jul 22 23:07:30 2008
From: nate at root.org (Nate Lawson)
Date: Tue Jul 22 23:07:37 2008
Subject: acpi no sound, acpi disabled no serial on IBM kiosk
In-Reply-To: <200807221813.41431.jhb@freebsd.org>
References: <200807220958.55060.brock@cottonwoodcomputer.com>	<200807221353.07575.jhb@freebsd.org>	<200807221528.49104.brock@cottonwoodcomputer.com>
	<200807221813.41431.jhb@freebsd.org>
Message-ID: <4886639E.4050201@root.org>

John Baldwin wrote:
> On Tuesday 22 July 2008 05:28:45 pm Brock Williams wrote:
>> Yeah, I guess I should have said more about the problem.  in the ACPI case 
>> I do see the devices there, but they don't work.  For example, the machine 
>> has an elotouch touchscreen which works great w/o ACPI but doesn't with.  
>> When I try to cat the device with ACPI enabled,  I get nothing.  Without 
>> acpi I get the expected touchscreen data when touching the screen.  We 
>> also have a dallas ibutton reader hooked up to another port and it acts 
>> the same way.
> 
> Hmm, they seem to have all the same I/O resources (ports and IRQs), so I don't 
> see anything that would make them not work.  Also, there isn't anything in 
> the AML for these devices that I can see that would help (no _INI or _REG 
> methods, etc.).
>

Just to confirm -- you are switching the device names when you "cat the 
device", right (sio0, 1, 2)?

-- 
Nate
From jhb at freebsd.org  Wed Jul 23 18:46:12 2008
From: jhb at freebsd.org (John Baldwin)
Date: Wed Jul 23 18:46:18 2008
Subject: acpi no sound, acpi disabled no serial on IBM kiosk
In-Reply-To: <200807221652.43618.brock@cottonwoodcomputer.com>
References: <200807220958.55060.brock@cottonwoodcomputer.com>
	<4886639E.4050201@root.org>
	<200807221652.43618.brock@cottonwoodcomputer.com>
Message-ID: <200807231023.50029.jhb@freebsd.org>

On Tuesday 22 July 2008 06:52:38 pm Brock Williams wrote:
> On Tuesday 22 July 2008 4:47:58 pm Nate Lawson wrote:
> > John Baldwin wrote:
> > > On Tuesday 22 July 2008 05:28:45 pm Brock Williams wrote:
> > >> Yeah, I guess I should have said more about the problem.  in the ACPI
> > >> case I do see the devices there, but they don't work.  For example,
> > >> the machine has an elotouch touchscreen which works great w/o ACPI
> > >> but doesn't with. When I try to cat the device with ACPI enabled,  I
> > >> get nothing.  Without acpi I get the expected touchscreen data when
> > >> touching the screen.  We also have a dallas ibutton reader hooked up
> > >> to another port and it acts the same way.
> > >
> > > Hmm, they seem to have all the same I/O resources (ports and IRQs), so
> > > I don't see anything that would make them not work.  Also, there isn't
> > > anything in the AML for these devices that I can see that would help
> > > (no _INI or _REG methods, etc.).
> >
> > Just to confirm -- you are switching the device names when you "cat the
> > device", right (sio0, 1, 2)?
> 
> Yep, I've tried cat'ing every cuad device that shows up, and I can't get 
> data out of any of them when I enable acpi. Also while catting with ACPI I 
> regularly get a message like:
> 
> sio1: 5 more silo overflows (total 5)
> 
> Thanks for the help,

Oh, it looks like your brain-damaged BIOS has told us that the interrupts are 
active-low instead of active-high, so you probably aren't getting any 
interrupts.  Stupid BIOS writers.  A quick hack would be to #if 0 the call 
to 'acpi_config_intr()' in acpi_alloc_resource() in sys/dev/acpica/acpi.c.  
You could also patch your ASL by fixing each "PNP0501" device like so:

--- brock-ibm-anyplace.asl.orig 2008-07-23 10:20:57.000000000 -0400
+++ brock-ibm-anyplace.asl      2008-07-23 10:21:29.000000000 -0400
@@ -5307,7 +5307,7 @@
                             0x00,               // Alignment
                             0x08,               // Length
                             _Y0F)
-                        IRQ (Edge, ActiveLow, Shared, _Y10)
+                        IRQ (Edge, ActiveHigh, Shared, _Y10)
                             {}
                     })
                     CreateByteField (BUF1, \_SB.PCI0.UAR1._CRS._Y0F._MIN, 
IOLO)

Unfortunately, there are some systems where we really need the 
acpi_config_intr() to work (some serial ports on ia64 machines have 
interrupts that are level/low like PCI interrupts, and w/o the 
acpi_config_intr() call they end up being edge/high), so we can't just 
disable them altogether in FreeBSD proper.

-- 
John Baldwin
From jhb at freebsd.org  Wed Jul 23 18:46:20 2008
From: jhb at freebsd.org (John Baldwin)
Date: Wed Jul 23 18:46:35 2008
Subject: ACPI regression on recent 7.0-STABLE: HPET stops working
In-Reply-To: <20080723140927.duc11agcg44ockw4@webmail.opentransfer.com>
References: <20080719100315.2td4dl2q5ck88wkw@webmail.opentransfer.com>
	<200807221514.55055.jhb@freebsd.org>
	<20080723140927.duc11agcg44ockw4@webmail.opentransfer.com>
Message-ID: <200807231116.02389.jhb@freebsd.org>

On Wednesday 23 July 2008 07:09:27 am Oleg V. Nauman wrote:
> Quoting John Baldwin <jhb@freebsd.org>:
> 
> > On Tuesday 22 July 2008 04:37:51 am Oleg V. Nauman wrote:
> >> Quoting John Baldwin <jhb@freebsd.org>:
> >>
> >> > On Monday 21 July 2008 06:07:52 am Oleg V. Nauman wrote:
> >> >> Quoting "Oleg V. Nauman" <oleg@opentransfer.com>:
> >> >>
> >> >> > Quoting Jeremy Chadwick <koitsu@FreeBSD.org>:
> >> >> >
> >> >> >> On Sat, Jul 19, 2008 at 10:03:15AM +0300, Oleg V. Nauman wrote:
> >> >> >>> It seems to be something was changed with ACPI support on 
7.0-STABLE
> > so
> >> >> >>> my next system upgrade ended with ACPI HPET not working anymore on 
my
> >> >> >>> ASUS A9Rp laptop.
> >> >> >>>
> >> >> >>> Here is the part of /var/log/dmesg.today dated July 13:
> >> >> >>>
> >> >> >>> FreeBSD 7.0-STABLE #65: Tue Jul  8 22:05:07 EEST 2008
> >> >> >>>    root@rainhaven.theweb.org.ua:/usr/src/sys/i386/compile/oleg2
> >> >> >>> [..]
> >> >> >>> acpi0: <A M I OEMRSDT> on motherboard
> >> >> >>> acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 21
> >> >> >>> acpi0: [ITHREAD]
> >> >> >>> acpi0: Power Button (fixed)
> >> >> >>> acpi0: reservation of 0, a0000 (3) failed
> >> >> >>> acpi0: reservation of 100000, 77f00000 (3) failed
> >> >> >>> Timecounter "ACPI-safe" frequency 3579545 Hz quality 850
> >> >> >>> acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on 
acpi0
> >> >> >>> acpi_ec0: <Embedded Controller: GPE 0x18> port 0x62,0x66 on acpi0
> >> >> >>> acpi_hpet0: <High Precision Event Timer> iomem
> >> >> >>> 0xfed00000-0xfed003ff on acpi0
> >> >> >>> Timecounter "HPET" frequency 14318180 Hz quality 900
> >> >> >>>
> >> >> >>> Here is the fresh dmesg output info:
> >> >> >>>
> >> >> >>> FreeBSD 7.0-STABLE #66: Tue Jul 15 22:11:27 EEST 2008
> >> >> >>>    root@rainhaven.theweb.org.ua:/usr/src/sys/i386/compile/oleg2
> >> >> >>> [..]
> >> >> >>> acpi0: <A M I OEMRSDT> on motherboard
> >> >> >>> acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 21
> >> >> >>> acpi0: [ITHREAD]
> >> >> >>> acpi0: Power Button (fixed)
> >> >> >>> acpi0: reservation of 0, a0000 (3) failed
> >> >> >>> acpi0: reservation of 100000, 77f00000 (3) failed
> >> >> >>> Timecounter "ACPI-safe" frequency 3579545 Hz quality 850
> >> >> >>> acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on 
acpi0
> >> >> >>> [..]
> >> >> >>> acpi_hpet0: <High Precision Event Timer> iomem
> >> >> >>> 0xfed00000-0xfed003ff on acpi0
> >> >> >>> device_attach: acpi_hpet0 attach returned 12
> >> >> >>>
> >> >> >>> And the part of actual sysctl kern.timecounter output:
> >> >> >>>
> >> >> >>> kern.timecounter.choice: TSC(800) ACPI-safe(850) i8254(0)
> >> > dummy(-1000000)
> >> >> >>> kern.timecounter.hardware: ACPI-safe
> >> >> >>
> >> >> >> Seems okay here:
> >> >> >>
> >> >> >> FreeBSD icarus.home.lan 7.0-STABLE FreeBSD 7.0-STABLE #0: Sat Jul
> >> >> >> 12  10:53:08 PDT 2008
> >> >> >> root@icarus.home.lan:/usr/obj/usr/src/sys/PDSMI_PLUS_amd64  amd64
> >> >> >>
> >> >> >> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on 
acpi0
> >> >> >> acpi_hpet0: <High Precision Event Timer> iomem
> >> >> >> 0xfed00000-0xfed003ff on acpi0
> >> >> >> Timecounter "i8254" frequency 1193182 Hz quality 0
> >> >> >> Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
> >> >> >> Timecounter "HPET" frequency 14318180 Hz quality 900
> >> >> >> Timecounters tick every 1.000 msec
> >> >> >>
> >> >> >> kern.timecounter.choice: TSC(-100) HPET(900) ACPI-fast(1000)
> >> >> >> i8254(0) dummy(-1000000)
> >> >> >> kern.timecounter.hardware: ACPI-fast
> >> >> >>
> >> >> >> You sure you haven't upgraded your BIOS or something and forgot to
> >> >> >> re-enable HPET?
> >> >> >
> >> >> >  No it was not upgraded.. Have no option to enable/disable HPET 
through
> >> >> > BIOS settings though
> >> >>
> >> >>   I was unclear a bit or so. There are no ACPI related settings in my
> >> >> laptop's BIOS.
> >> >>
> >> >>   Well.. Backout 1.243.2.3 revision of /usr/src/sys/dev/acpica/acpi.c
> >> >> (committed to RELENG_7 at July 10 by jhb) fixes this issue for me:
> >> >>
> >> >> acpi_hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed003ff 
on
> >> > acpi0
> >> >> Timecounter "HPET" frequency 14318180 Hz quality 900
> >> >>
> >> >> kern.timecounter.choice: TSC(800) HPET(900) ACPI-safe(850) i8254(0)
> >> >> dummy(-1000000)
> >> >> kern.timecounter.hardware: HPET
> >> >>
> >> >>   Hopefully it helps to understand what is went wrong there.
> >> >
> >> > Ok, so the attempt to allocate the resource is failing for some reason.
> > Can
> >> > you get output from 'devinfo -r' and 'devinfo -u'?
> >>
> >> ...
> >>
> >> Will not provide with full listings but just a diff comparing two
> >> states (this good one with HPET working and bad w/o it):
> >>
> >> rainhaven# diff devinfo.r.good devinfo.r.bad
> >> 177,179d176
> >> <     acpi_hpet0
> >> <         I/O memory addresses:
> >> <             0xfed00000-0xfed003ff
> >>
> >> rainhaven# diff devinfo.u.good devinfo.u.bad
> >> 128c128
> >> <     0xfed00000-0xfed003ff (acpi_hpet0)
> >> ---
> >> >     0xfed00000-0xfed003ff (ichsmb0)
> >>
> >>   So kernel with 1.243.2.3 revision of /usr/src/sys/dev/acpica/acpi.c
> >> allocates the region required to ichsmb0 instead HPET (it not helps to
> >> ichsmb0 because it never was working on my laptop but it is another
> >> story I think).
> >>
> >> Thank you for looking into.
> >
> > Hmm, so ichsmb0 doesn't show up at all in your earlier dmesg.   Try this
> 
>   It never was working for me. Well nothing more than
> 
> ichsmb0: <SMBus controller> port 0xb00-0xb0f mem 0xfed00000-0xfed003ff  
> at device 20.0 on pci0
> ichsmb0: can't map I/O
> device_attach: ichsmb0 attach returned 6
> 
> 
> > change, it restores the probe orders to be more of what they used to be 
and
> > just gives CPUs a really high probe order so that they should be after 
other
> > devices.
> 
>   It was the patch against the CURRENT as far I understand while my  
> laptop running 7.0-STABLE. Well it was applied manually (not a so big  
> issue finally) against 1.243.2.3 revision of  
> /usr/src/sys/dev/acpica/acpi.c and reporting  success for the HPET  
> functionality at least (part of relevant verbose dmesg output):
> 
> 
> ACPI: HPET @ 0x0x77fd6800/0x0038 (v  1 A M I  OEMHPET  0x10000626 MSFT  
> 0x00000097)
> acpi_hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed003ff on 
acpi0
> acpi_hpet0: vend: 0x4353 rev: 0x10 num: 3 hz: 14318180 opts: legacy_route
> Timecounter "HPET" frequency 14318180 Hz quality 900
> 
> And part of sysctl variables related:
> 
> kern.timecounter.choice: TSC(800) HPET(900) ACPI-safe(850) i8254(0)  
> dummy(-1000000)
> kern.timecounter.hardware: HPET
> 
> I/O mem conflict with ichsmb still in place though
> 
>   Thank you

I've committed the patch.  However, I think this actually points out a 
slightly bigger issue in that the HPET timer is probably piggybacking on the 
ichsmb0 device's BAR, and they really should both be able to attach somehow.

A way to fix that would be to make the HPET device actually borrow the PCI 
device's resource instead of allocating its own perhaps.  I think the HPET 
ACPI device and the table tell us the PCI deviec the HPET lives in.

-- 
John Baldwin
From brock at cottonwoodcomputer.com  Wed Jul 23 22:07:24 2008
From: brock at cottonwoodcomputer.com (Brock Williams)
Date: Wed Jul 23 22:07:35 2008
Subject: acpi no sound, acpi disabled no serial on IBM kiosk
In-Reply-To: <200807231023.50029.jhb@freebsd.org>
References: <200807220958.55060.brock@cottonwoodcomputer.com>
	<200807221652.43618.brock@cottonwoodcomputer.com>
	<200807231023.50029.jhb@freebsd.org>
Message-ID: <200807231607.19469.brock@cottonwoodcomputer.com>

On Wednesday 23 July 2008 8:23:49 am you wrote:
> On Tuesday 22 July 2008 06:52:38 pm Brock Williams wrote:
> > On Tuesday 22 July 2008 4:47:58 pm Nate Lawson wrote:
> > > John Baldwin wrote:
> > > > On Tuesday 22 July 2008 05:28:45 pm Brock Williams wrote:
> > > >> Yeah, I guess I should have said more about the problem.  in the
> > > >> ACPI case I do see the devices there, but they don't work.  For
> > > >> example, the machine has an elotouch touchscreen which works
> > > >> great w/o ACPI but doesn't with. When I try to cat the device
> > > >> with ACPI enabled,  I get nothing.  Without acpi I get the
> > > >> expected touchscreen data when touching the screen.  We also have
> > > >> a dallas ibutton reader hooked up to another port and it acts the
> > > >> same way.
> > > >
> > > > Hmm, they seem to have all the same I/O resources (ports and
> > > > IRQs), so I don't see anything that would make them not work. 
> > > > Also, there isn't anything in the AML for these devices that I can
> > > > see that would help (no _INI or _REG methods, etc.).
> > >
> > > Just to confirm -- you are switching the device names when you "cat
> > > the device", right (sio0, 1, 2)?
> >
> > Yep, I've tried cat'ing every cuad device that shows up, and I can't
> > get data out of any of them when I enable acpi. Also while catting
> > with ACPI I regularly get a message like:
> >
> > sio1: 5 more silo overflows (total 5)
> >
> > Thanks for the help,
>
> Oh, it looks like your brain-damaged BIOS has told us that the
> interrupts are active-low instead of active-high, so you probably aren't
> getting any interrupts.  Stupid BIOS writers.  A quick hack would be to
> #if 0 the call to 'acpi_config_intr()' in acpi_alloc_resource() in
> sys/dev/acpica/acpi.c. You could also patch your ASL by fixing each
> "PNP0501" device like so:
>
> --- brock-ibm-anyplace.asl.orig 2008-07-23 10:20:57.000000000 -0400
> +++ brock-ibm-anyplace.asl      2008-07-23 10:21:29.000000000 -0400
> @@ -5307,7 +5307,7 @@
>                              0x00,               // Alignment
>                              0x08,               // Length
>                              _Y0F)
> -                        IRQ (Edge, ActiveLow, Shared, _Y10)
> +                        IRQ (Edge, ActiveHigh, Shared, _Y10)
>                              {}
>                      })
>                      CreateByteField (BUF1,
> \_SB.PCI0.UAR1._CRS._Y0F._MIN, IOLO)
>
> Unfortunately, there are some systems where we really need the
> acpi_config_intr() to work (some serial ports on ia64 machines have
> interrupts that are level/low like PCI interrupts, and w/o the
> acpi_config_intr() call they end up being edge/high), so we can't just
> disable them altogether in FreeBSD proper.

THANK YOU!!!  Patching the ASL like you suggested worked like a charm.  Now 
all the ports seem to be working great.

I really appreciate the help,

Brock

-- 
Brock Williams  brock@cottonwoodcomputer.com
Cottonwood Computer Solutions, Inc.
www.cotcomsol.com 406-896-4910
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-acpi/attachments/20080723/7cb4f9c1/attachment.pgp
From bugmaster at FreeBSD.org  Mon Jul 28 11:06:51 2008
From: bugmaster at FreeBSD.org (FreeBSD bugmaster)
Date: Mon Jul 28 11:06:57 2008
Subject: Current problem reports assigned to freebsd-acpi@FreeBSD.org
Message-ID: <200807281106.m6SB6o9o078817@freefall.freebsd.org>

Current FreeBSD problem reports
Critical problems
Serious problems

S Tracker      Resp.      Description
--------------------------------------------------------------------------------
o i386/54756   acpi       ACPI suspend/resume problem on CF-W2 laptop
o i386/55661   acpi       ACPI suspend/resume problem on ARMADA M700
o kern/56024   acpi       ACPI suspend drains battery while in S3
o i386/72566   acpi       ACPI, FreeBSD disables fan on Compaq Armada 1750
o i386/79081   acpi       ACPI suspend/resume not working on HP nx6110
o kern/81000   acpi       [apic] Via 8235 sound card worked great with FreeBSD 5
s kern/91038   acpi       [panic] [ata] [acpi] 6.0-RELEASE on Fujitsu Siemens Am
s i386/91748   acpi       acpi problem on Acer TravelMare 4652LMi (nvidia panic,
o kern/102252  acpi       acpi thermal does not work on Abit AW8D (intel 975)
o kern/104625  acpi       ACPI on ASUS A8N-32 SLI/ASUS P4P800 does not show ther
o kern/106924  acpi       [acpi] ACPI resume returns g_vfs_done() errors and ker
o kern/108954  acpi       [acpi] 'sleep(1)' sleeps >1 seconds when speedstep (Cx
o i386/114562  acpi       [acpi] cardbus is dead after s3 on Thinkpad T43 with a
o kern/116939  acpi       [acpi] PCI-to-PCI misconfigured for bus three and can 
o kern/118973  acpi       [acpi]: Kernel panic with acpi boot
o kern/119200  acpi       [acpi] Lid close switch suspends CPU for 1 second on H
o kern/119356  acpi       [acpi]: i386 ACPI wakeup not work due resource exhaust
o kern/120953  acpi       [acpi]: FreeBSD 6.3 Release:  acpi_tz0: _TMP value is 
f kern/121454  acpi       [pst] Promise SuperTrak SX6000 does not load during bo

19 problems total.

Non-critical problems

S Tracker      Resp.      Description
--------------------------------------------------------------------------------
f kern/67309   acpi       zzz reboot computer (ACPI S3)
o i386/69750   acpi       Boot without ACPI failed on ASUS L5
s kern/73823   acpi       [request] acpi / power-on by timer support
o kern/76950   acpi       ACPI wrongly blacklisted on Micron ClientPro 766Xi sys
o i386/83018   acpi       [install] Installer will not boot on Asus P4S8X BIOS 1
o kern/89411   acpi       [acpi] acpiconf bug
s kern/90243   acpi       Laptop fan doesn't turn off (ACPI enabled) (Packard Be
o kern/97383   acpi       Volume buttons on IBM Thinkpad crash system with ACPI
o kern/105537  acpi       [acpi] problems in acpi on HP Compaq nc6320
o kern/108017  acpi       [acpi]: Acer Aspire 5600
o kern/108488  acpi       [acpi] ACPI-1304: *** Error: Method execution failed
o kern/108581  acpi       [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argume
o kern/108695  acpi       [acpi]: Fatal trap 9: general protection fault when in
s kern/112544  acpi       [acpi] [patch] Add High Precision Event Timer Driver f
o kern/114165  acpi       [acpi] Dell C810 - ACPI problem
o kern/117605  acpi       [acpi] [request] add debug.cpufreq.highest
o kern/120515  acpi       [acpi] [patch] acpi_alloc_wakeup_handler: can't alloc 
o kern/121102  acpi       [acpi_fujitsu] [patch] update acpi_fujitsu for the P80
o kern/121504  acpi       [patch] Correctly set hw.acpi.osname on certain machin
f amd64/122521 acpi       ACPI Error after upgrade to 7.0
o kern/123039  acpi       [acpi] ACPI AML_BUFFER_LIMIT errors during boot
o kern/124223  acpi       [acpi] [patch] acpi_battery.c -- Notify user-defined c
o kern/124412  acpi       [acpi] power off error on Toshiba M40 laptop
o kern/124744  acpi       [acpi] [patch] incorrect _BST result validation for To

24 problems total.

From robert.moore at intel.com  Tue Jul 29 20:34:09 2008
From: robert.moore at intel.com (Moore, Robert)
Date: Tue Jul 29 20:36:27 2008
Subject: ACPICA version 20080729 released
Message-ID: <9D39833986E69849A2A8E74C1078B6B3BF9DFB@orsmsx415.amr.corp.intel.com>


29 July 2008. Summary of changes for version 20080729:

This release is available at http://acpica.org/downloads
Direct git access via http://www.acpica.org/repos/acpica.git

1) ACPI CA Core Subsystem:

Fix a possible deadlock in the GPE dispatch. Remove call to
AcpiHwDisableAllGpes during wake in AcpiEvGpeDispatch. This call will
attempt to acquire the GPE lock but can deadlock since the GPE lock is
already held at dispatch time. This code was introduced in version
20060831 as a response to Linux BZ 6881 and has since been removed from
Linux.

Add a function to dereference returned reference objects. Examines the
return object from a call to AcpiEvaluateObject. Any Index or RefOf
references are automatically dereferenced in an attempt to return
something useful (these reference types cannot be converted into an
external ACPI_OBJECT.) Provides MS compatibility. Lin Ming, Bob Moore.
Linux BZ 11105

x2APIC support: changes for MADT and SRAT ACPI tables. There are 2 new
subtables for the MADT and one new subtable for the SRAT. Includes
disassembler and AcpiSrc support. Data from the Intel 64 Architecture
x2APIC Specification, June 2008.

Additional error checking for pathname utilities. Add error check after
all calls to AcpiNsGetPathnameLength. Add status return from
AcpiNsBuildExternalPath and check after all calls. Add parameter
validation to AcpiUtInitializeBuffer. Reported by and initial patch by
Ingo Molnar.

Return status from the global init function AcpiUtGlobalInitialize. This
is used by both the kernel subsystem and the utilities such as iASL
compiler. The function could possibly fail when the caches are
initialized. Yang Yi.

Add a function to decode reference object types to strings. Created for
improved error messages. 

Improve object conversion error messages. Better error messages during
object conversion from internal to the external ACPI_OBJECT. Used for
external calls to AcpiEvaluateObject.

Example Code and Data Size: These are the sizes for the OS-independent
acpica.lib produced by the Microsoft Visual C++ 6.0 32-bit compiler. The
debug version of the code includes the debug output trace mechanism and
has a much larger code and data size.

  Previous Release:
    Non-Debug Version:  79.6K Code, 16.2K Data,  95.8K Total
    Debug Version:     153.5K Code, 48.2K Data, 201.7K Total
  Current Release:
    Non-Debug Version:  79.7K Code, 16.4K Data,  96.1K Total
    Debug Version:     153.9K Code, 48.4K Data, 202.3K Total

2) iASL Compiler/Disassembler and Tools:

Debugger: fix a possible hang when evaluating non-methods. Fixes a
problem introduced in version 20080701. If the object being evaluated
(via execute command) is not a method, the debugger can hang while
trying to obtain non-existent parameters.

iASL: relax error for using reserved "_T_x" identifiers. These names can
appear in a disassembled ASL file if they were emitted by the original
compiler. Instead of issuing an error or warning and forcing the user to
manually change these names, issue a remark instead.

iASL: error if named object created in while loop. Emit an error if any
named object is created within a While loop. If allowed, this code will
generate a run-time error on the second iteration of the loop when an
attempt is made to create the same named object twice. ACPICA bugzilla
730.

iASL: Support absolute pathnames for include files. Add support for
absolute pathnames within the Include operator. previously, only
relative pathnames were supported.

iASL: Enforce minimum 1 interrupt in interrupt macro and Resource
Descriptor. The ACPI spec requires one interrupt minimum. BZ 423

iASL: Handle a missing ResourceSource arg, with a present SourceIndex.
Handles the case for the Interrupt Resource Descriptor where
the ResourceSource argument is omitted but ResourceSourceIndex
is present. Now leave room for the Index. BZ 426

iASL: Prevent error message if CondRefOf target does not exist. Fixes
cases where an error message is emitted if the target does not exist. BZ
516

iASL: Fix broken -g option (get Windows ACPI tables). Fixes the -g
option (get ACPI tables on Windows). This was apparently broken in
version 20070919.

AcpiXtract: Handle EOF while extracting data. Correctly handle the case
where the EOF happens immediately after the last table in the input
file. Print completion message. Previously, no message was displayed in
this case.