From pldrouin at pldrouin.net  Wed Apr  1 19:38:16 2009
From: pldrouin at pldrouin.net (Pierre-Luc Drouin)
Date: Wed Apr  1 19:38:29 2009
Subject: Wrong dev.cpu.0.freq_levels values
Message-ID: <49D42118.6030206@pldrouin.net>

Hello,

I have noticed that FreeBSD gets the wrong CPU frequency levels for my 
Pentium M 2GHz. It used to work correctly with older versions of 
FreeBSD, but I noticed that this was not working properly when I 
installed 7.1 and this is still not working with -stable:

Mar 30 15:08:03 mdaemon kernel: CPU: Intel(R) Pentium(R) M processor 
2.00GHz (1995.14-MHz 686-class CPU)
Mar 30 15:08:03 mdaemon kernel: Origin = "GenuineIntel"  Id = 0x6d8  
Stepping = 8
Mar 30 15:08:03 mdaemon kernel: 
Features=0xafe9fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,TM,PBE>
Mar 30 15:08:03 mdaemon kernel: Features2=0x180<EST,TM2>
Mar 30 15:08:03 mdaemon kernel: AMD Features=0x100000<NX>
Mar 30 15:08:03 mdaemon kernel: real memory  = 1073577984 (1023 MB)
Mar 30 15:08:03 mdaemon kernel: avail memory = 1032699904 (984 MB)
Mar 30 15:08:03 mdaemon kernel: ACPI APIC Table: <DELL   D05    >

dev.cpu.0.freq: 1500
dev.cpu.0.freq_levels: 1500/-1 1312/-1 1200/-1 1050/-1 1000/-1 875/-1 
800/-1 700/-1 600/-1 525/-1 450/-1 375/-1 300/-1 225/-1 150/-1 75/-1
dev.est.0.%desc: Enhanced SpeedStep Frequency Control
dev.est.0.freq_settings: 1500/-1 1200/-1 1000/-1 800/-1 600/-1

Is there a way to fix this?

Thank you!
Pierre-Luc Drouin
From nate at root.org  Wed Apr  1 19:41:50 2009
From: nate at root.org (Nate Lawson)
Date: Wed Apr  1 19:41:57 2009
Subject: Wrong dev.cpu.0.freq_levels values
In-Reply-To: <49D42118.6030206@pldrouin.net>
References: <49D42118.6030206@pldrouin.net>
Message-ID: <49D425E9.4030700@root.org>

Pierre-Luc Drouin wrote:
> Hello,
> 
> I have noticed that FreeBSD gets the wrong CPU frequency levels for my
> Pentium M 2GHz. It used to work correctly with older versions of
> FreeBSD, but I noticed that this was not working properly when I
> installed 7.1 and this is still not working with -stable:
> 

> dev.cpu.0.freq: 1500
> dev.cpu.0.freq_levels: 1500/-1 1312/-1 1200/-1 1050/-1 1000/-1 875/-1
> 800/-1 700/-1 600/-1 525/-1 450/-1 375/-1 300/-1 225/-1 150/-1 75/-1
> dev.est.0.%desc: Enhanced SpeedStep Frequency Control
> dev.est.0.freq_settings: 1500/-1 1200/-1 1000/-1 800/-1 600/-1
> 
> Is there a way to fix this?

There's nothing wrong. You just got more levels using p4tcc (another
cpufreq device). So use it as-is, or disable the p4tcc driver and
acpi_throttle drivers.

-- 
Nate
From pldrouin at pldrouin.net  Wed Apr  1 19:55:50 2009
From: pldrouin at pldrouin.net (Pierre-Luc Drouin)
Date: Wed Apr  1 19:55:57 2009
Subject: Wrong dev.cpu.0.freq_levels values
In-Reply-To: <49D425E9.4030700@root.org>
References: <49D42118.6030206@pldrouin.net> <49D425E9.4030700@root.org>
Message-ID: <49D42934.5050408@pldrouin.net>

Hi,

I understand that there are more levels than there used to be because of 
the new driver, but why is the maximum 1500 now instead of 2000? Doesn't 
it mean that the maximum frequency set by powerd is now 1500 MHz instead 
of 2000 GHz?

Thanks!

Nate Lawson wrote:
> Pierre-Luc Drouin wrote:
>   
>> Hello,
>>
>> I have noticed that FreeBSD gets the wrong CPU frequency levels for my
>> Pentium M 2GHz. It used to work correctly with older versions of
>> FreeBSD, but I noticed that this was not working properly when I
>> installed 7.1 and this is still not working with -stable:
>>
>>     
>
>   
>> dev.cpu.0.freq: 1500
>> dev.cpu.0.freq_levels: 1500/-1 1312/-1 1200/-1 1050/-1 1000/-1 875/-1
>> 800/-1 700/-1 600/-1 525/-1 450/-1 375/-1 300/-1 225/-1 150/-1 75/-1
>> dev.est.0.%desc: Enhanced SpeedStep Frequency Control
>> dev.est.0.freq_settings: 1500/-1 1200/-1 1000/-1 800/-1 600/-1
>>
>> Is there a way to fix this?
>>     
>
> There's nothing wrong. You just got more levels using p4tcc (another
> cpufreq device). So use it as-is, or disable the p4tcc driver and
> acpi_throttle drivers.
>
>   

From pldrouin at pldrouin.net  Wed Apr  1 20:16:17 2009
From: pldrouin at pldrouin.net (Pierre-Luc Drouin)
Date: Wed Apr  1 20:16:24 2009
Subject: Wrong dev.cpu.0.freq_levels values
In-Reply-To: <49D425E9.4030700@root.org>
References: <49D42118.6030206@pldrouin.net> <49D425E9.4030700@root.org>
Message-ID: <49D42DFD.4060209@pldrouin.net>

I tried disabling both p4tcc and acpi_throttle by putting the following 
in /boot/device.hints:
hint.p4tcc.0.disabled="1"
hint.acpi_throttle.0.disabled="1"

It reduced the number of levels, but I still don't have a level 2000 as 
I used to get:
dev.cpu.0.freq: 1500
dev.cpu.0.freq_levels: 1500/-1 1200/-1 1000/-1 800/-1 600/-1
dev.est.0.%desc: Enhanced SpeedStep Frequency Control
dev.est.0.freq_settings: 1500/-1 1200/-1 1000/-1 800/-1 600/-1

Pierre-Luc Drouin

Nate Lawson wrote:
> Pierre-Luc Drouin wrote:
>   
>> Hello,
>>
>> I have noticed that FreeBSD gets the wrong CPU frequency levels for my
>> Pentium M 2GHz. It used to work correctly with older versions of
>> FreeBSD, but I noticed that this was not working properly when I
>> installed 7.1 and this is still not working with -stable:
>>
>>     
>
>   
>> dev.cpu.0.freq: 1500
>> dev.cpu.0.freq_levels: 1500/-1 1312/-1 1200/-1 1050/-1 1000/-1 875/-1
>> 800/-1 700/-1 600/-1 525/-1 450/-1 375/-1 300/-1 225/-1 150/-1 75/-1
>> dev.est.0.%desc: Enhanced SpeedStep Frequency Control
>> dev.est.0.freq_settings: 1500/-1 1200/-1 1000/-1 800/-1 600/-1
>>
>> Is there a way to fix this?
>>     
>
> There's nothing wrong. You just got more levels using p4tcc (another
> cpufreq device). So use it as-is, or disable the p4tcc driver and
> acpi_throttle drivers.
>
>   

From oberman at es.net  Wed Apr  1 20:35:44 2009
From: oberman at es.net (Kevin Oberman)
Date: Wed Apr  1 20:35:50 2009
Subject: Wrong dev.cpu.0.freq_levels values 
In-Reply-To: Your message of "Wed, 01 Apr 2009 23:16:13 EDT."
	<49D42DFD.4060209@pldrouin.net> 
Message-ID: <20090402033543.43DDD1CC0B@ptavv.es.net>

> Date: Wed, 01 Apr 2009 23:16:13 -0400
> From: Pierre-Luc Drouin <pldrouin@pldrouin.net>
> Sender: owner-freebsd-acpi@freebsd.org
> 
> I tried disabling both p4tcc and acpi_throttle by putting the following 
> in /boot/device.hints:
> hint.p4tcc.0.disabled="1"
> hint.acpi_throttle.0.disabled="1"
> 
> It reduced the number of levels, but I still don't have a level 2000 as 
> I used to get:
> dev.cpu.0.freq: 1500
> dev.cpu.0.freq_levels: 1500/-1 1200/-1 1000/-1 800/-1 600/-1
> dev.est.0.%desc: Enhanced SpeedStep Frequency Control
> dev.est.0.freq_settings: 1500/-1 1200/-1 1000/-1 800/-1 600/-1
> 
> Pierre-Luc Drouin
> 
> Nate Lawson wrote:
> > Pierre-Luc Drouin wrote:
> >   
> >> Hello,
> >>
> >> I have noticed that FreeBSD gets the wrong CPU frequency levels for my
> >> Pentium M 2GHz. It used to work correctly with older versions of
> >> FreeBSD, but I noticed that this was not working properly when I
> >> installed 7.1 and this is still not working with -stable:
> >>
> >>     
> >
> >   
> >> dev.cpu.0.freq: 1500
> >> dev.cpu.0.freq_levels: 1500/-1 1312/-1 1200/-1 1050/-1 1000/-1 875/-1
> >> 800/-1 700/-1 600/-1 525/-1 450/-1 375/-1 300/-1 225/-1 150/-1 75/-1
> >> dev.est.0.%desc: Enhanced SpeedStep Frequency Control
> >> dev.est.0.freq_settings: 1500/-1 1200/-1 1000/-1 800/-1 600/-1
> >>
> >> Is there a way to fix this?
> >>     
> >
> > There's nothing wrong. You just got more levels using p4tcc (another
> > cpufreq device). So use it as-is, or disable the p4tcc driver and
> > acpi_throttle drivers.
> >

There is a problem, of course. I had the same issue with my 2GHz Pentium
M. It was easy to fix, but totally counter-intuitive.

Build your kernel without "device cpufreq" and it will all work
fine. Here is what I see without CPUFREQ:
dev.cpu.0.freq_levels: 2000/27000 1750/23625 1600/22600 1400/19775 1333/19666 1166/17207 1066/16733 932/14641 800/13800 700/12075 600/10350 500/8625 400/6900 300/5175 200/3450 100/1725

These are the correct values.

Also, when on battery, the CPU changes the available frequencies so that
the top one is 800 MHz. This is not a powerd thing. It's entirely BIOS.
-- 
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
From misra.veerendra at gmail.com  Wed Apr  1 21:23:22 2009
From: misra.veerendra at gmail.com (Veer)
Date: Wed Apr  1 21:23:29 2009
Subject: Need to identify From which register Temperature is read
Message-ID: <22840564.post@talk.nabble.com>


Hi,

I have an ACPI BIOS and there are some methods to calculate the temperate of
BIOS. However I want to know which registers are actually read for that. Can
anyone help me here. 

Actually , I want to control the fan speed and there is no Active Cooling
method implemented. So I want to write false temperature value to that
temperature register so that what ever the fancontrol mechanism is thinks
temperature is low/high and then changes the fan speed( I Don't think
Embedded Controller is controlling fan speed)
Also I do not want passive cooling. 

Also any idea how fan speed is being controlled on this bios. I am attaching
the dsdt file. 

Thanks http://www.nabble.com/file/p22840564/dsdt_MY070.dsl dsdt_MY070.dsl 
-- 
View this message in context: http://www.nabble.com/Need-to-identify-From-which-register-Temperature-is-read-tp22840564p22840564.html
Sent from the freebsd-acpi mailing list archive at Nabble.com.

From pldrouin at pldrouin.net  Thu Apr  2 05:59:22 2009
From: pldrouin at pldrouin.net (Pierre-Luc Drouin)
Date: Thu Apr  2 05:59:29 2009
Subject: Wrong dev.cpu.0.freq_levels values
In-Reply-To: <20090402033543.43DDD1CC0B@ptavv.es.net>
References: <20090402033543.43DDD1CC0B@ptavv.es.net>
Message-ID: <49D4B6A6.2000902@pldrouin.net>

Kevin Oberman wrote:
>> Date: Wed, 01 Apr 2009 23:16:13 -0400
>> From: Pierre-Luc Drouin <pldrouin@pldrouin.net>
>> Sender: owner-freebsd-acpi@freebsd.org
>>
>> I tried disabling both p4tcc and acpi_throttle by putting the following 
>> in /boot/device.hints:
>> hint.p4tcc.0.disabled="1"
>> hint.acpi_throttle.0.disabled="1"
>>
>> It reduced the number of levels, but I still don't have a level 2000 as 
>> I used to get:
>> dev.cpu.0.freq: 1500
>> dev.cpu.0.freq_levels: 1500/-1 1200/-1 1000/-1 800/-1 600/-1
>> dev.est.0.%desc: Enhanced SpeedStep Frequency Control
>> dev.est.0.freq_settings: 1500/-1 1200/-1 1000/-1 800/-1 600/-1
>>
>> Pierre-Luc Drouin
>>
>> Nate Lawson wrote:
>>     
>>> Pierre-Luc Drouin wrote:
>>>   
>>>       
>>>> Hello,
>>>>
>>>> I have noticed that FreeBSD gets the wrong CPU frequency levels for my
>>>> Pentium M 2GHz. It used to work correctly with older versions of
>>>> FreeBSD, but I noticed that this was not working properly when I
>>>> installed 7.1 and this is still not working with -stable:
>>>>
>>>>     
>>>>         
>>>   
>>>       
>>>> dev.cpu.0.freq: 1500
>>>> dev.cpu.0.freq_levels: 1500/-1 1312/-1 1200/-1 1050/-1 1000/-1 875/-1
>>>> 800/-1 700/-1 600/-1 525/-1 450/-1 375/-1 300/-1 225/-1 150/-1 75/-1
>>>> dev.est.0.%desc: Enhanced SpeedStep Frequency Control
>>>> dev.est.0.freq_settings: 1500/-1 1200/-1 1000/-1 800/-1 600/-1
>>>>
>>>> Is there a way to fix this?
>>>>     
>>>>         
>>> There's nothing wrong. You just got more levels using p4tcc (another
>>> cpufreq device). So use it as-is, or disable the p4tcc driver and
>>> acpi_throttle drivers.
>>>
>>>       
>
> There is a problem, of course. I had the same issue with my 2GHz Pentium
> M. It was easy to fix, but totally counter-intuitive.
>
> Build your kernel without "device cpufreq" and it will all work
> fine. Here is what I see without CPUFREQ:
> dev.cpu.0.freq_levels: 2000/27000 1750/23625 1600/22600 1400/19775 1333/19666 1166/17207 1066/16733 932/14641 800/13800 700/12075 600/10350 500/8625 400/6900 300/5175 200/3450 100/1725
>
> These are the correct values.
>
> Also, when on battery, the CPU changes the available frequencies so that
> the top one is 800 MHz. This is not a powerd thing. It's entirely BIOS.
>   
Yep, that did it. Thanks! This is quite counter-intuitive effectively!

Pierre-Luc Drouin
From jhb at freebsd.org  Thu Apr  2 07:24:32 2009
From: jhb at freebsd.org (John Baldwin)
Date: Thu Apr  2 07:24:39 2009
Subject: Wrong dev.cpu.0.freq_levels values
In-Reply-To: <20090402033543.43DDD1CC0B@ptavv.es.net>
References: <20090402033543.43DDD1CC0B@ptavv.es.net>
Message-ID: <200904020908.00723.jhb@freebsd.org>

On Wednesday 01 April 2009 11:35:43 pm Kevin Oberman wrote:
> > Date: Wed, 01 Apr 2009 23:16:13 -0400
> > From: Pierre-Luc Drouin <pldrouin@pldrouin.net>
> > Sender: owner-freebsd-acpi@freebsd.org
> > 
> > I tried disabling both p4tcc and acpi_throttle by putting the following 
> > in /boot/device.hints:
> > hint.p4tcc.0.disabled="1"
> > hint.acpi_throttle.0.disabled="1"
> > 
> > It reduced the number of levels, but I still don't have a level 2000 as 
> > I used to get:
> > dev.cpu.0.freq: 1500
> > dev.cpu.0.freq_levels: 1500/-1 1200/-1 1000/-1 800/-1 600/-1
> > dev.est.0.%desc: Enhanced SpeedStep Frequency Control
> > dev.est.0.freq_settings: 1500/-1 1200/-1 1000/-1 800/-1 600/-1
> > 
> > Pierre-Luc Drouin
> > 
> > Nate Lawson wrote:
> > > Pierre-Luc Drouin wrote:
> > >   
> > >> Hello,
> > >>
> > >> I have noticed that FreeBSD gets the wrong CPU frequency levels for my
> > >> Pentium M 2GHz. It used to work correctly with older versions of
> > >> FreeBSD, but I noticed that this was not working properly when I
> > >> installed 7.1 and this is still not working with -stable:
> > >>
> > >>     
> > >
> > >   
> > >> dev.cpu.0.freq: 1500
> > >> dev.cpu.0.freq_levels: 1500/-1 1312/-1 1200/-1 1050/-1 1000/-1 875/-1
> > >> 800/-1 700/-1 600/-1 525/-1 450/-1 375/-1 300/-1 225/-1 150/-1 75/-1
> > >> dev.est.0.%desc: Enhanced SpeedStep Frequency Control
> > >> dev.est.0.freq_settings: 1500/-1 1200/-1 1000/-1 800/-1 600/-1
> > >>
> > >> Is there a way to fix this?
> > >>     
> > >
> > > There's nothing wrong. You just got more levels using p4tcc (another
> > > cpufreq device). So use it as-is, or disable the p4tcc driver and
> > > acpi_throttle drivers.
> > >
> 
> There is a problem, of course. I had the same issue with my 2GHz Pentium
> M. It was easy to fix, but totally counter-intuitive.
> 
> Build your kernel without "device cpufreq" and it will all work
> fine. Here is what I see without CPUFREQ:
> dev.cpu.0.freq_levels: 2000/27000 1750/23625 1600/22600 1400/19775 
1333/19666 1166/17207 1066/16733 932/14641 800/13800 700/12075 600/10350 
500/8625 400/6900 300/5175 200/3450 100/1725

Hmm, that means one of the cpufreq drivers is busted I think.  Can you try 
disabling all of them to see which one is the problem (est perhaps?)  Also, 
can you show the 'devinfo' output for your cpu0 device (and its child 
devices) in the cpufreq and non-cpufreq cases?

-- 
John Baldwin
From pldrouin at pldrouin.net  Thu Apr  2 07:51:26 2009
From: pldrouin at pldrouin.net (Pierre-Luc Drouin)
Date: Thu Apr  2 07:51:32 2009
Subject: Wrong dev.cpu.0.freq_levels values
In-Reply-To: <200904020908.00723.jhb@freebsd.org>
References: <20090402033543.43DDD1CC0B@ptavv.es.net>
	<200904020908.00723.jhb@freebsd.org>
Message-ID: <49D4D0EA.1050108@pldrouin.net>

John Baldwin wrote:
> On Wednesday 01 April 2009 11:35:43 pm Kevin Oberman wrote:
>   
>>> Date: Wed, 01 Apr 2009 23:16:13 -0400
>>> From: Pierre-Luc Drouin <pldrouin@pldrouin.net>
>>> Sender: owner-freebsd-acpi@freebsd.org
>>>
>>> I tried disabling both p4tcc and acpi_throttle by putting the following 
>>> in /boot/device.hints:
>>> hint.p4tcc.0.disabled="1"
>>> hint.acpi_throttle.0.disabled="1"
>>>
>>> It reduced the number of levels, but I still don't have a level 2000 as 
>>> I used to get:
>>> dev.cpu.0.freq: 1500
>>> dev.cpu.0.freq_levels: 1500/-1 1200/-1 1000/-1 800/-1 600/-1
>>> dev.est.0.%desc: Enhanced SpeedStep Frequency Control
>>> dev.est.0.freq_settings: 1500/-1 1200/-1 1000/-1 800/-1 600/-1
>>>
>>> Pierre-Luc Drouin
>>>
>>> Nate Lawson wrote:
>>>       
>>>> Pierre-Luc Drouin wrote:
>>>>   
>>>>         
>>>>> Hello,
>>>>>
>>>>> I have noticed that FreeBSD gets the wrong CPU frequency levels for my
>>>>> Pentium M 2GHz. It used to work correctly with older versions of
>>>>> FreeBSD, but I noticed that this was not working properly when I
>>>>> installed 7.1 and this is still not working with -stable:
>>>>>
>>>>>     
>>>>>           
>>>>   
>>>>         
>>>>> dev.cpu.0.freq: 1500
>>>>> dev.cpu.0.freq_levels: 1500/-1 1312/-1 1200/-1 1050/-1 1000/-1 875/-1
>>>>> 800/-1 700/-1 600/-1 525/-1 450/-1 375/-1 300/-1 225/-1 150/-1 75/-1
>>>>> dev.est.0.%desc: Enhanced SpeedStep Frequency Control
>>>>> dev.est.0.freq_settings: 1500/-1 1200/-1 1000/-1 800/-1 600/-1
>>>>>
>>>>> Is there a way to fix this?
>>>>>     
>>>>>           
>>>> There's nothing wrong. You just got more levels using p4tcc (another
>>>> cpufreq device). So use it as-is, or disable the p4tcc driver and
>>>> acpi_throttle drivers.
>>>>
>>>>         
>> There is a problem, of course. I had the same issue with my 2GHz Pentium
>> M. It was easy to fix, but totally counter-intuitive.
>>
>> Build your kernel without "device cpufreq" and it will all work
>> fine. Here is what I see without CPUFREQ:
>> dev.cpu.0.freq_levels: 2000/27000 1750/23625 1600/22600 1400/19775 
>>     
> 1333/19666 1166/17207 1066/16733 932/14641 800/13800 700/12075 600/10350 
> 500/8625 400/6900 300/5175 200/3450 100/1725
>
> Hmm, that means one of the cpufreq drivers is busted I think.  Can you try 
> disabling all of them to see which one is the problem (est perhaps?)  Also, 
> can you show the 'devinfo' output for your cpu0 device (and its child 
> devices) in the cpufreq and non-cpufreq cases?
>
>   
est0 seems to be the problem. When I have the cpufreq driver in my 
kernel, that I disable est0 and that I leave p4tcc0 and acpi_throttle0 
enabled, the output from sysctl is right. If I disable p4tcc0 and 
acpi_throttle0 and that I leave est0 enabled, the highest level is 1500 
rather than 2000. Here is the output from devinfo that concerns cpu0:

cpu0 pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU0
        ACPI I/O ports:
            0x1014
            0x1015
            0x1016
      est0
      p4tcc0
      acpi_perf0
      acpi_throttle0
      cpufreq0

Pierre-Luc Drouin
From dd at gizmocreative.com  Thu Apr  2 08:54:45 2009
From: dd at gizmocreative.com (Daniel Duerr)
Date: Thu Apr  2 08:54:51 2009
Subject: Wrong dev.cpu.0.freq_levels values
In-Reply-To: <49D4D0EA.1050108@pldrouin.net>
References: <20090402033543.43DDD1CC0B@ptavv.es.net>
	<200904020908.00723.jhb@freebsd.org>
	<49D4D0EA.1050108@pldrouin.net>
Message-ID: <9EC2C57E-1BAA-4023-8A86-EFCB706D95FE@gizmocreative.com>

For what it's worth, I recently reported a similar bug with est where  
the top-most frequency of my CPU is less than it should be.  In my  
case, cpufreq *is not* compiled into the kernel and is instead loaded  
as a driver at boot.  I'm using a 1.8GHz dual core Pentium from a  
couple years ago.

On Apr 2, 2009, at 7:51 AM, Pierre-Luc Drouin wrote:

> John Baldwin wrote:
>> On Wednesday 01 April 2009 11:35:43 pm Kevin Oberman wrote:
>>
>>>> Date: Wed, 01 Apr 2009 23:16:13 -0400
>>>> From: Pierre-Luc Drouin <pldrouin@pldrouin.net>
>>>> Sender: owner-freebsd-acpi@freebsd.org
>>>>
>>>> I tried disabling both p4tcc and acpi_throttle by putting the  
>>>> following in /boot/device.hints:
>>>> hint.p4tcc.0.disabled="1"
>>>> hint.acpi_throttle.0.disabled="1"
>>>>
>>>> It reduced the number of levels, but I still don't have a level  
>>>> 2000 as I used to get:
>>>> dev.cpu.0.freq: 1500
>>>> dev.cpu.0.freq_levels: 1500/-1 1200/-1 1000/-1 800/-1 600/-1
>>>> dev.est.0.%desc: Enhanced SpeedStep Frequency Control
>>>> dev.est.0.freq_settings: 1500/-1 1200/-1 1000/-1 800/-1 600/-1
>>>>
>>>> Pierre-Luc Drouin
>>>>
>>>> Nate Lawson wrote:
>>>>
>>>>> Pierre-Luc Drouin wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> I have noticed that FreeBSD gets the wrong CPU frequency levels  
>>>>>> for my
>>>>>> Pentium M 2GHz. It used to work correctly with older versions of
>>>>>> FreeBSD, but I noticed that this was not working properly when I
>>>>>> installed 7.1 and this is still not working with -stable:
>>>>>>
>>>>>>
>>>>>
>>>>>> dev.cpu.0.freq: 1500
>>>>>> dev.cpu.0.freq_levels: 1500/-1 1312/-1 1200/-1 1050/-1 1000/-1  
>>>>>> 875/-1
>>>>>> 800/-1 700/-1 600/-1 525/-1 450/-1 375/-1 300/-1 225/-1 150/-1  
>>>>>> 75/-1
>>>>>> dev.est.0.%desc: Enhanced SpeedStep Frequency Control
>>>>>> dev.est.0.freq_settings: 1500/-1 1200/-1 1000/-1 800/-1 600/-1
>>>>>>
>>>>>> Is there a way to fix this?
>>>>>>
>>>>> There's nothing wrong. You just got more levels using p4tcc  
>>>>> (another
>>>>> cpufreq device). So use it as-is, or disable the p4tcc driver and
>>>>> acpi_throttle drivers.
>>>>>
>>>>>
>>> There is a problem, of course. I had the same issue with my 2GHz  
>>> Pentium
>>> M. It was easy to fix, but totally counter-intuitive.
>>>
>>> Build your kernel without "device cpufreq" and it will all work
>>> fine. Here is what I see without CPUFREQ:
>>> dev.cpu.0.freq_levels: 2000/27000 1750/23625 1600/22600 1400/19775
>> 1333/19666 1166/17207 1066/16733 932/14641 800/13800 700/12075  
>> 600/10350 500/8625 400/6900 300/5175 200/3450 100/1725
>>
>> Hmm, that means one of the cpufreq drivers is busted I think.  Can  
>> you try disabling all of them to see which one is the problem (est  
>> perhaps?)  Also, can you show the 'devinfo' output for your cpu0  
>> device (and its child devices) in the cpufreq and non-cpufreq cases?
>>
>>
> est0 seems to be the problem. When I have the cpufreq driver in my  
> kernel, that I disable est0 and that I leave p4tcc0 and  
> acpi_throttle0 enabled, the output from sysctl is right. If I  
> disable p4tcc0 and acpi_throttle0 and that I leave est0 enabled, the  
> highest level is 1500 rather than 2000. Here is the output from  
> devinfo that concerns cpu0:
>
> cpu0 pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU0
>       ACPI I/O ports:
>           0x1014
>           0x1015
>           0x1016
>     est0
>     p4tcc0
>     acpi_perf0
>     acpi_throttle0
>     cpufreq0
>
> Pierre-Luc Drouin
> _______________________________________________
> 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"



--
daniel duerr   |   president   |   gizmo creative
dd@gizmocreative.com  |  +1 (831) 621-1710 x103



From dfilter at FreeBSD.ORG  Sat Apr  4 10:10:03 2009
From: dfilter at FreeBSD.ORG (dfilter service)
Date: Sat Apr  4 10:10:10 2009
Subject: kern/128634: commit references a PR
Message-ID: <200904041710.n34HA3eo076356@freefall.freebsd.org>

The following reply was made to PR kern/128634; it has been noted by GNATS.

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/128634: commit references a PR
Date: Sat,  4 Apr 2009 17:01:42 +0000 (UTC)

 Author: attilio
 Date: Sat Apr  4 17:01:32 2009
 New Revision: 190695
 URL: http://svn.freebsd.org/changeset/base/190695
 
 Log:
   - Add the support for the Asus A3F and A3E device
   - Fix style for A3N and for a comment
   
   Submitted by:	Akira Funahashi <funa@funa.org>
   Tested by:	Marcin Nowak <marcin.nowak@simplusnet.pl>,
   		Diego Sardina <diego.sardina@gmx.com>
   PR:		kern/128634
 
 Modified:
   head/sys/dev/acpi_support/acpi_asus.c
 
 Modified: head/sys/dev/acpi_support/acpi_asus.c
 ==============================================================================
 --- head/sys/dev/acpi_support/acpi_asus.c	Sat Apr  4 16:03:28 2009	(r190694)
 +++ head/sys/dev/acpi_support/acpi_asus.c	Sat Apr  4 17:01:32 2009	(r190695)
 @@ -176,16 +176,39 @@ static struct acpi_asus_model acpi_asus_
  		.disp_set	= "SDSP"
  	},
  	{
 +		.name           = "A3E",
 +		.mled_set       = "MLED",
 +		.wled_set       = "WLED",
 +		.lcd_get        = "\\_SB.PCI0.SBRG.EC0.RPIN(0x67)",
 +		.lcd_set        = "\\_SB.PCI0.SBRG.EC0._Q10",
 +		.brn_get        = "GPLV",
 +		.brn_set        = "SPLV",
 +		.disp_get       = "\\_SB.PCI0.P0P2.VGA.GETD",
 +		.disp_set       = "SDSP"
 +	},
 +	{
 +		.name           = "A3F",
 +		.mled_set       = "MLED",
 +		.wled_set       = "WLED",
 +		.bled_set       = "BLED",
 +		.lcd_get        = "\\_SB.PCI0.SBRG.EC0.RPIN(0x11)",
 +		.lcd_set        = "\\_SB.PCI0.SBRG.EC0._Q10",
 +		.brn_get        = "GPLV",
 +		.brn_set        = "SPLV",
 +		.disp_get       = "\\SSTE",
 +		.disp_set       = "SDSP"
 +	},
 +	{
  		.name           = "A3N",
  		.mled_set       = "MLED",
  		.bled_set       = "BLED",
  		.wled_set       = "WLED",
 -		.lcd_get        = NULL,
 +		.lcd_get        = "\\BKLT",
  		.lcd_set        = "\\_SB.PCI0.SBRG.EC0._Q10",
 +		.brn_get        = "GPLV",
  		.brn_set        = "SPLV",
 -		.brn_get        = "SDSP",
 -		.disp_set       = "SDSP",
 -		.disp_get       = "\\_SB.PCI0.P0P3.VGA.GETD"
 +		.disp_get       = "\\_SB.PCI0.P0P3.VGA.GETD",
 +		.disp_set       = "SDSP"
  	},
  	{
  		.name		= "A4D",
 @@ -577,7 +600,7 @@ acpi_asus_probe(device_t dev)
  			return (0);
  		}
  
 -		/* if EeePC */
 +		/* EeePC */
  		if (strncmp("ASUS010", rstr, 7) == 0) {
  			sc->model = &acpi_eeepc_models[0];
  			device_set_desc(dev, "ASUS EeePC");
 @@ -627,6 +650,9 @@ good:
  		else if (strncmp(model->name, "A2x", 3) == 0 &&
  		    strncmp(Obj->String.Pointer, "A2", 2) == 0)
  			goto good;
 +		else if (strncmp(model->name, "A3F", 3) == 0 &&
 +		    strncmp(Obj->String.Pointer, "A6F", 3) == 0)
 +			goto good;
  		else if (strncmp(model->name, "D1x", 3) == 0 &&
  		    strncmp(Obj->String.Pointer, "D1", 2) == 0)
  			goto good;
 _______________________________________________
 svn-src-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-all
 To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
 
From kulka at man.poznan.pl  Sun Apr  5 23:59:38 2009
From: kulka at man.poznan.pl (Michal Kulczewski)
Date: Sun Apr  5 23:59:44 2009
Subject: acpi_hp
Message-ID: <49D9A4D0.8000205@man.poznan.pl>

Hi,

does anyone have sources for acpi_hp kernel module? It's not in the CVS
sources (at least I can't find it), I've googled that some guy wrote
this module, but he didn't commit it to sources (he also did not respond
to me). I wish I could work with my hp laptop, but I can't get my wlan
to work. Is there some kind of workaround or should I implement my own
acpi_hp module?

Cheers,
 Michal
From c.r.n.a at wanadoo.fr  Mon Apr  6 02:23:18 2009
From: c.r.n.a at wanadoo.fr (Nicolas)
Date: Mon Apr  6 02:23:25 2009
Subject: acpi_hp
Message-ID: <49D9C994.9060208@wanadoo.fr>

Hi Michal,

I'm also interested in this driver.
I contacted Michael, we'll see if he replies.

Nicolas.

From bugmaster at FreeBSD.org  Mon Apr  6 04:06:50 2009
From: bugmaster at FreeBSD.org (FreeBSD bugmaster)
Date: Mon Apr  6 04:07:13 2009
Subject: Current problem reports assigned to freebsd-acpi@FreeBSD.org
Message-ID: <200904061106.n36B6meD061766@freefall.freebsd.org>

Note: to view an individual PR, use:
  http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.


S Tracker      Resp.      Description
--------------------------------------------------------------------------------
o kern/132602  acpi       [acpi] ACPI Problem with Intel SS4200: System does not
o kern/130683  acpi       [ACPI] shutdown hangs after syncing disks - ACPI race?
o i386/129953  acpi       [acpi] ACPI timeout (CDROM) with Shuttle X27D
o kern/129618  acpi       [acpi] Problem with ACPI on HP Pavilion DV2899 laptop
o kern/129563  acpi       [acpi] sleep broken on IBM/Lenovo T61 in amd64 mode
o kern/128639  acpi       [patch] [acpi_asus] acpi for ASUS A6F,A3E,A3F,A3N not 
f kern/128634  acpi       [patch] fix acpi_asus(4) in asus a6f laptop
o kern/127581  acpi       [patch] [acpi_sony] Add support for more Sony features
o kern/124744  acpi       [acpi] [patch] incorrect _BST result validation for To
o kern/124412  acpi       [acpi] power off error on Toshiba M40 laptop
o kern/123039  acpi       [acpi] ACPI AML_BUFFER_LIMIT errors during boot
o kern/121504  acpi       [patch] Correctly set hw.acpi.osname on certain machin
f kern/121454  acpi       [pst] Promise SuperTrak SX6000 does not load during bo
o kern/121102  acpi       [acpi_fujitsu] [patch] update acpi_fujitsu for the P80
o kern/120515  acpi       [acpi] [patch] acpi_alloc_wakeup_handler: can't alloc 
o kern/119356  acpi       [acpi]: i386 ACPI wakeup not work due resource exhaust
o kern/119200  acpi       [acpi] Lid close switch suspends CPU for 1 second on H
o kern/118973  acpi       [acpi]: Kernel panic with acpi boot
o kern/117605  acpi       [acpi] [request] add debug.cpufreq.highest
o kern/116939  acpi       [acpi] PCI-to-PCI misconfigured for bus three and can 
o i386/114562  acpi       [acpi] cardbus is dead after s3 on Thinkpad T43 with a
o kern/114165  acpi       [acpi] Dell C810 - ACPI problem
s kern/112544  acpi       [acpi] [patch] Add High Precision Event Timer Driver f
o kern/108954  acpi       [acpi] 'sleep(1)' sleeps >1 seconds when speedstep (Cx
o kern/108695  acpi       [acpi]: Fatal trap 9: general protection fault when in
o kern/108488  acpi       [acpi] ACPI-1304: *** Error: Method execution failed
o kern/108017  acpi       [acpi]: Acer Aspire 5600
o kern/106924  acpi       [acpi] ACPI resume returns g_vfs_done() errors and ker
o kern/105537  acpi       [acpi] problems in acpi on HP Compaq nc6320
o kern/104625  acpi       ACPI on ASUS A8N-32 SLI/ASUS P4P800 does not show ther
o kern/102252  acpi       acpi thermal does not work on Abit AW8D (intel 975)
o kern/97383   acpi       Volume buttons on IBM Thinkpad crash system with ACPI
s i386/91748   acpi       acpi problem on Acer TravelMare 4652LMi (nvidia panic,
s kern/91038   acpi       [panic] [ata] [acpi] 6.0-RELEASE on Fujitsu Siemens Am
s kern/90243   acpi       Laptop fan doesn't turn off (ACPI enabled) (Packard Be
f kern/89411   acpi       [acpi] acpiconf bug
o i386/83018   acpi       [install] Installer will not boot on Asus P4S8X BIOS 1
o kern/81000   acpi       [apic] Via 8235 sound card worked great with FreeBSD 5
o i386/79081   acpi       ACPI suspend/resume not working on HP nx6110
o kern/76950   acpi       ACPI wrongly blacklisted on Micron ClientPro 766Xi sys
s kern/73823   acpi       [request] acpi / power-on by timer support
o i386/72566   acpi       ACPI, FreeBSD disables fan on Compaq Armada 1750
o i386/69750   acpi       Boot without ACPI failed on ASUS L5
f kern/67309   acpi       zzz reboot computer (ACPI S3)
o kern/56024   acpi       ACPI suspend drains battery while in S3
o i386/55661   acpi       ACPI suspend/resume problem on ARMADA M700
o i386/54756   acpi       ACPI suspend/resume problem on CF-W2 laptop

47 problems total.

From cokane at cokane.org  Mon Apr  6 09:37:02 2009
From: cokane at cokane.org (Coleman Kane)
Date: Mon Apr  6 09:37:08 2009
Subject: acpi_hp
In-Reply-To: <49D9C994.9060208@wanadoo.fr>
References: <49D9C994.9060208@wanadoo.fr>
Message-ID: <1239034816.1946.7.camel@localhost>

On Mon, 2009-04-06 at 11:21 +0200, Nicolas wrote:
> Hi Michal,
> 
> I'm also interested in this driver.
> I contacted Michael, we'll see if he replies.
> 
> Nicolas.
> 

I too am interested... let me know if anything comes out of it.


-- 
Coleman Kane

From avg at icyb.net.ua  Fri Apr 10 01:12:11 2009
From: avg at icyb.net.ua (Andriy Gapon)
Date: Fri Apr 10 01:12:27 2009
Subject: 6.x acpi powerbutton
In-Reply-To: <49DE596E.2050406@earthlink.net>
References: <49DE1F8B.2080400@earthlink.net> <49DE2E6D.5050001@icyb.net.ua>
	<49DE596E.2050406@earthlink.net>
Message-ID: <49DEFF53.1040306@icyb.net.ua>

on 09/04/2009 23:24 Stephen Clark said the following:
> Probably not. But I spent a couple of hours googling without much luck
> so I got desperate. ;-)

Let me introduce freebsd-acpi@freebsd.org

> Is there a reason it doesn't send and event like Linux that can be acted
> upon by user space other
> than signaling init? I like to have a message written in
> /var/log/messages that someone pressed
> the powerbutton.

I think that for all suspend states except S5 userland is notified via
devd mechanism and potentially can veto the suspend. S5 (soft-off) is
coded to start shutdown immediately. You can try to hack on
acpi_ReqSleepState in sys/dev/acpica/acpi.c.

I am not sure what is the reason for this special behavior of S5. But I
like it, because it sometimes allows me to perform semi-clean shutdown
when X goes crazy. But I also see when it could be useful to have S5
request go through userland. So this could be configurable.

-- 
Andriy Gapon
From nate at root.org  Fri Apr 10 09:56:00 2009
From: nate at root.org (Nate Lawson)
Date: Fri Apr 10 09:56:07 2009
Subject: 6.x acpi powerbutton
In-Reply-To: <49DEFF53.1040306@icyb.net.ua>
References: <49DE1F8B.2080400@earthlink.net>
	<49DE2E6D.5050001@icyb.net.ua>	<49DE596E.2050406@earthlink.net>
	<49DEFF53.1040306@icyb.net.ua>
Message-ID: <49DF7A1C.90009@root.org>

Andriy Gapon wrote:
> on 09/04/2009 23:24 Stephen Clark said the following:
>> Is there a reason it doesn't send and event like Linux that can be acted
>> upon by user space other
>> than signaling init? I like to have a message written in
>> /var/log/messages that someone pressed
>> the powerbutton.
> 
> I think that for all suspend states except S5 userland is notified via
> devd mechanism and potentially can veto the suspend. S5 (soft-off) is
> coded to start shutdown immediately. You can try to hack on
> acpi_ReqSleepState in sys/dev/acpica/acpi.c.
> 
> I am not sure what is the reason for this special behavior of S5. But I
> like it, because it sometimes allows me to perform semi-clean shutdown
> when X goes crazy. But I also see when it could be useful to have S5
> request go through userland. So this could be configurable.

The reason for userland getting into the loop in the first place was to
run programs to shut down devices and reinit them after resume. This
isn't necessary in the shutdown case because init already sends a
signal, as you mention.

There's already a mechanism for timing out if userland is not
responding, so a suspend will ultimately happen whether or not it
answers. However, that waits for a while (1 minute?) and devd used to be
optional, so I thought it best to keep the existing S5 behavior
(immediate shutdown).

It may be ok to enable this for S5 but I don't think it's very useful.

-- 
Nate
From bugmaster at FreeBSD.org  Mon Apr 13 04:06:48 2009
From: bugmaster at FreeBSD.org (FreeBSD bugmaster)
Date: Mon Apr 13 04:32:53 2009
Subject: Current problem reports assigned to freebsd-acpi@FreeBSD.org
Message-ID: <200904131106.n3DB6lx8084832@freefall.freebsd.org>

Note: to view an individual PR, use:
  http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.


S Tracker      Resp.      Description
--------------------------------------------------------------------------------
o kern/132602  acpi       [acpi] ACPI Problem with Intel SS4200: System does not
o kern/130683  acpi       [ACPI] shutdown hangs after syncing disks - ACPI race?
o i386/129953  acpi       [acpi] ACPI timeout (CDROM) with Shuttle X27D
o kern/129618  acpi       [acpi] Problem with ACPI on HP Pavilion DV2899 laptop
o kern/129563  acpi       [acpi] sleep broken on IBM/Lenovo T61 in amd64 mode
o kern/128639  acpi       [patch] [acpi_asus] acpi for ASUS A6F,A3E,A3F,A3N not 
f kern/128634  acpi       [patch] fix acpi_asus(4) in asus a6f laptop
o kern/127581  acpi       [patch] [acpi_sony] Add support for more Sony features
o kern/124744  acpi       [acpi] [patch] incorrect _BST result validation for To
o kern/124412  acpi       [acpi] power off error on Toshiba M40 laptop
o kern/123039  acpi       [acpi] ACPI AML_BUFFER_LIMIT errors during boot
o kern/121504  acpi       [patch] Correctly set hw.acpi.osname on certain machin
f kern/121454  acpi       [pst] Promise SuperTrak SX6000 does not load during bo
o kern/121102  acpi       [acpi_fujitsu] [patch] update acpi_fujitsu for the P80
o kern/120515  acpi       [acpi] [patch] acpi_alloc_wakeup_handler: can't alloc 
o kern/119356  acpi       [acpi]: i386 ACPI wakeup not work due resource exhaust
o kern/119200  acpi       [acpi] Lid close switch suspends CPU for 1 second on H
o kern/118973  acpi       [acpi]: Kernel panic with acpi boot
o kern/117605  acpi       [acpi] [request] add debug.cpufreq.highest
o kern/116939  acpi       [acpi] PCI-to-PCI misconfigured for bus three and can 
o i386/114562  acpi       [acpi] cardbus is dead after s3 on Thinkpad T43 with a
o kern/114165  acpi       [acpi] Dell C810 - ACPI problem
s kern/112544  acpi       [acpi] [patch] Add High Precision Event Timer Driver f
o kern/108954  acpi       [acpi] 'sleep(1)' sleeps >1 seconds when speedstep (Cx
o kern/108695  acpi       [acpi]: Fatal trap 9: general protection fault when in
o kern/108488  acpi       [acpi] ACPI-1304: *** Error: Method execution failed
o kern/108017  acpi       [acpi]: Acer Aspire 5600
o kern/106924  acpi       [acpi] ACPI resume returns g_vfs_done() errors and ker
o kern/105537  acpi       [acpi] problems in acpi on HP Compaq nc6320
o kern/104625  acpi       ACPI on ASUS A8N-32 SLI/ASUS P4P800 does not show ther
o kern/102252  acpi       acpi thermal does not work on Abit AW8D (intel 975)
o kern/97383   acpi       Volume buttons on IBM Thinkpad crash system with ACPI
s i386/91748   acpi       acpi problem on Acer TravelMare 4652LMi (nvidia panic,
s kern/91038   acpi       [panic] [ata] [acpi] 6.0-RELEASE on Fujitsu Siemens Am
s kern/90243   acpi       Laptop fan doesn't turn off (ACPI enabled) (Packard Be
f kern/89411   acpi       [acpi] acpiconf bug
o i386/83018   acpi       [install] Installer will not boot on Asus P4S8X BIOS 1
o kern/81000   acpi       [apic] Via 8235 sound card worked great with FreeBSD 5
o i386/79081   acpi       ACPI suspend/resume not working on HP nx6110
o kern/76950   acpi       ACPI wrongly blacklisted on Micron ClientPro 766Xi sys
s kern/73823   acpi       [request] acpi / power-on by timer support
o i386/72566   acpi       ACPI, FreeBSD disables fan on Compaq Armada 1750
o i386/69750   acpi       Boot without ACPI failed on ASUS L5
f kern/67309   acpi       zzz reboot computer (ACPI S3)
o kern/56024   acpi       ACPI suspend drains battery while in S3
o i386/55661   acpi       ACPI suspend/resume problem on ARMADA M700
o i386/54756   acpi       ACPI suspend/resume problem on CF-W2 laptop

47 problems total.

From avg at freebsd.org  Tue Apr 14 09:11:23 2009
From: avg at freebsd.org (Andriy Gapon)
Date: Tue Apr 14 09:51:16 2009
Subject: run resume code only for S1-S4 states
In-Reply-To: <49DF3CA4.1090309@freebsd.org>
References: <49DB639A.4090504@icyb.net.ua> <49DCF5C2.60805@root.org>
	<49DDF906.8090400@icyb.net.ua> <49DF3CA4.1090309@freebsd.org>
Message-ID: <49E4B2A7.3020302@freebsd.org>


Guys,
could you please review the attached patch?

Its main idea is to make control flow of acpi_EnterSleepState similar
to that of acpi_ReqSleepState: reject invalid state parameter immediately and
handle special S5 as early as possible. Primary purpose is to avoid running resume
code when it is not necessary - e.g. shutdown_nice() typically returns immediately
after initiating a graceful shutdown by sending a signal to init.

As such, S5 is handled right after checking/disabling re-entry.
switch becomes unneeded, because all remaining possibilities are grouped
into a single case. I decided to use do-while(0) statement in the place of the
switch for the following reasons:
1. minimize diff by preserving indentation
2. minimize diff by preserving control flow that depends on break statement
But I am not sure how this while(0) corresponds with style(9), I couldn't find any
reference in the manual page.

There is also a concern about calling shutdown_nice() outside of the Giant lock
and binding to CPU 0. I am not sure about the pre-requisites for this function.
John, maybe you could help me here?

-- 
Andriy Gapon

-------------- next part --------------
diff --git a/sys/dev/acpica/acpi.c b/sys/dev/acpica/acpi.c
index 50b84a5..ac654d2 100644
--- a/sys/dev/acpica/acpi.c
+++ b/sys/dev/acpica/acpi.c
@@ -2482,6 +2482,9 @@ acpi_EnterSleepState(struct acpi_softc *sc, int state)
 
     ACPI_FUNCTION_TRACE_U32((char *)(uintptr_t)__func__, state);
 
+    if (state < ACPI_STATE_S1 || state > ACPI_STATE_S5)
+	return_ACPI_STATUS (AE_BAD_PARAMETER);
+
     /* Re-entry once we're suspending is not allowed. */
     status = acpi_sleep_disable(sc);
     if (ACPI_FAILURE(status)) {
@@ -2489,6 +2492,15 @@ acpi_EnterSleepState(struct acpi_softc *sc, int state)
 	return (status);
     }
 
+    if (state == ACPI_STATE_S5) {
+	/*
+	 * Shut down cleanly and power off.  This will call us back through the
+	 * shutdown handlers.
+	 */
+	shutdown_nice(RB_POWEROFF);
+	return_ACPI_STATUS (AE_OK);
+    }
+
 #ifdef SMP
     thread_lock(curthread);
     sched_bind(curthread, 0);
@@ -2502,11 +2514,7 @@ acpi_EnterSleepState(struct acpi_softc *sc, int state)
     mtx_lock(&Giant);
 
     slp_state = ACPI_SS_NONE;
-    switch (state) {
-    case ACPI_STATE_S1:
-    case ACPI_STATE_S2:
-    case ACPI_STATE_S3:
-    case ACPI_STATE_S4:
+    do {
 	status = AcpiGetSleepTypeData(state, &TypeA, &TypeB);
 	if (status == AE_NOT_FOUND) {
 	    device_printf(sc->acpi_dev,
@@ -2569,20 +2577,7 @@ acpi_EnterSleepState(struct acpi_softc *sc, int state)
 	    }
 	}
 	slp_state = ACPI_SS_SLEPT;
-	break;
-    case ACPI_STATE_S5:
-	/*
-	 * Shut down cleanly and power off.  This will call us back through the
-	 * shutdown handlers.
-	 */
-	shutdown_nice(RB_POWEROFF);
-	status = AE_OK;
-	break;
-    case ACPI_STATE_S0:
-    default:
-	status = AE_BAD_PARAMETER;
-	break;
-    }
+    } while (0);
 
     /*
      * Back out state according to how far along we got in the suspend
@@ -2609,8 +2604,7 @@ acpi_EnterSleepState(struct acpi_softc *sc, int state)
 #endif
 
     /* Allow another sleep request after a while. */
-    if (state != ACPI_STATE_S5)
-	timeout(acpi_sleep_enable, sc, hz * ACPI_MINIMUM_AWAKETIME);
+    timeout(acpi_sleep_enable, sc, hz * ACPI_MINIMUM_AWAKETIME);
 
     /* Run /etc/rc.resume after we are back. */
     if (devctl_process_running())
From jkim at FreeBSD.org  Tue Apr 14 11:24:17 2009
From: jkim at FreeBSD.org (Jung-uk Kim)
Date: Tue Apr 14 12:12:34 2009
Subject: run resume code only for S1-S4 states
In-Reply-To: <49E4B2A7.3020302@freebsd.org>
References: <49DB639A.4090504@icyb.net.ua> <49DF3CA4.1090309@freebsd.org>
	<49E4B2A7.3020302@freebsd.org>
Message-ID: <200904141424.00943.jkim@FreeBSD.org>

On Tuesday 14 April 2009 11:58 am, Andriy Gapon wrote:
> Guys,
> could you please review the attached patch?
>
> Its main idea is to make control flow of acpi_EnterSleepState
> similar to that of acpi_ReqSleepState: reject invalid state
> parameter immediately and handle special S5 as early as possible.
> Primary purpose is to avoid running resume code when it is not
> necessary - e.g. shutdown_nice() typically returns immediately
> after initiating a graceful shutdown by sending a signal to init.

I tried to solve this problem once.  To preserve the current 
behaviour, you have to clean up sc->acpi_next_sstate and set 
sc->acpi_sstate to S5 as well if my memory serves.

> As such, S5 is handled right after checking/disabling re-entry.
> switch becomes unneeded, because all remaining possibilities are
> grouped into a single case. I decided to use do-while(0) statement
> in the place of the switch for the following reasons:
> 1. minimize diff by preserving indentation
> 2. minimize diff by preserving control flow that depends on break
> statement But I am not sure how this while(0) corresponds with
> style(9), I couldn't find any reference in the manual page.

I think goto is more cleaner and easy to read in this case.

> There is also a concern about calling shutdown_nice() outside of
> the Giant lock and binding to CPU 0. I am not sure about the
> pre-requisites for this function. John, maybe you could help me
> here?

I think you don't need giant here and CPU binding is done from boot().

Jung-uk Kim
From avg at freebsd.org  Wed Apr 15 01:59:50 2009
From: avg at freebsd.org (Andriy Gapon)
Date: Wed Apr 15 02:39:04 2009
Subject: run resume code only for S1-S4 states
In-Reply-To: <200904141424.00943.jkim@FreeBSD.org>
References: <49DB639A.4090504@icyb.net.ua> <49DF3CA4.1090309@freebsd.org>
	<49E4B2A7.3020302@freebsd.org>
	<200904141424.00943.jkim@FreeBSD.org>
Message-ID: <49E5A200.6010306@freebsd.org>

on 14/04/2009 21:23 Jung-uk Kim said the following:
> On Tuesday 14 April 2009 11:58 am, Andriy Gapon wrote:
>> Guys,
>> could you please review the attached patch?
>>
>> Its main idea is to make control flow of acpi_EnterSleepState
>> similar to that of acpi_ReqSleepState: reject invalid state
>> parameter immediately and handle special S5 as early as possible.
>> Primary purpose is to avoid running resume code when it is not
>> necessary - e.g. shutdown_nice() typically returns immediately
>> after initiating a graceful shutdown by sending a signal to init.
> 
> I tried to solve this problem once.  To preserve the current 
> behaviour, you have to clean up sc->acpi_next_sstate and set 
> sc->acpi_sstate to S5 as well if my memory serves.

I am not sure if I understand why/where this could be useful.
S5 is a "terminal" state, so unless shutdown fails for some reason (can
there be any?) this shouldn't matter.

>> As such, S5 is handled right after checking/disabling re-entry.
>> switch becomes unneeded, because all remaining possibilities are
>> grouped into a single case. I decided to use do-while(0) statement
>> in the place of the switch for the following reasons:
>> 1. minimize diff by preserving indentation
>> 2. minimize diff by preserving control flow that depends on break
>> statement But I am not sure how this while(0) corresponds with
>> style(9), I couldn't find any reference in the manual page.
> 
> I think goto is more cleaner and easy to read in this case.

Ok, I'll switch to that.

>> There is also a concern about calling shutdown_nice() outside of
>> the Giant lock and binding to CPU 0. I am not sure about the
>> pre-requisites for this function. John, maybe you could help me
>> here?
> 
> I think you don't need giant here and CPU binding is done from boot().

Thank you for the review!

-- 
Andriy Gapon
From jkim at FreeBSD.org  Wed Apr 15 09:08:12 2009
From: jkim at FreeBSD.org (Jung-uk Kim)
Date: Wed Apr 15 09:26:09 2009
Subject: run resume code only for S1-S4 states
In-Reply-To: <49E5A200.6010306@freebsd.org>
References: <49DB639A.4090504@icyb.net.ua>
	<200904141424.00943.jkim@FreeBSD.org>
	<49E5A200.6010306@freebsd.org>
Message-ID: <200904151208.03822.jkim@FreeBSD.org>

On Wednesday 15 April 2009 04:59 am, Andriy Gapon wrote:
> on 14/04/2009 21:23 Jung-uk Kim said the following:
> > On Tuesday 14 April 2009 11:58 am, Andriy Gapon wrote:
> >> Guys,
> >> could you please review the attached patch?
> >>
> >> Its main idea is to make control flow of acpi_EnterSleepState
> >> similar to that of acpi_ReqSleepState: reject invalid state
> >> parameter immediately and handle special S5 as early as
> >> possible. Primary purpose is to avoid running resume code when
> >> it is not necessary - e.g. shutdown_nice() typically returns
> >> immediately after initiating a graceful shutdown by sending a
> >> signal to init.
> >
> > I tried to solve this problem once.  To preserve the current
> > behaviour, you have to clean up sc->acpi_next_sstate and set
> > sc->acpi_sstate to S5 as well if my memory serves.
>
> I am not sure if I understand why/where this could be useful.
> S5 is a "terminal" state, so unless shutdown fails for some reason
> (can there be any?) this shouldn't matter.

Actually, my patch was more complex, e.g., I added more code to make 
sure power/sleep button events get ignored and cleared when it is not 
in S0 state, etc.  Probably I needed to track the current state 
because of it.  I think you may ignore it for now if it is not needed 
anywhere else.

Thanks,

Jung-uk Kim
From avg at freebsd.org  Wed Apr 15 09:11:32 2009
From: avg at freebsd.org (Andriy Gapon)
Date: Wed Apr 15 09:27:36 2009
Subject: run resume code only for S1-S4 states
In-Reply-To: <200904151208.03822.jkim@FreeBSD.org>
References: <49DB639A.4090504@icyb.net.ua>
	<200904141424.00943.jkim@FreeBSD.org>
	<49E5A200.6010306@freebsd.org>
	<200904151208.03822.jkim@FreeBSD.org>
Message-ID: <49E60731.8050402@freebsd.org>

on 15/04/2009 19:08 Jung-uk Kim said the following:
> Actually, my patch was more complex, e.g., I added more code to make 
> sure power/sleep button events get ignored and cleared when it is not 
> in S0 state, etc.  Probably I needed to track the current state 
> because of it.  I think you may ignore it for now if it is not needed 
> anywhere else.

Interesting. I think that I will go with the current patch (modulo break->goto
changes), if my mentors approve. But I would like to see your patch :-)

-- 
Andriy Gapon
From jkim at FreeBSD.org  Wed Apr 15 09:30:19 2009
From: jkim at FreeBSD.org (Jung-uk Kim)
Date: Wed Apr 15 10:20:55 2009
Subject: run resume code only for S1-S4 states
In-Reply-To: <49E60731.8050402@freebsd.org>
References: <49DB639A.4090504@icyb.net.ua>
	<200904151208.03822.jkim@FreeBSD.org>
	<49E60731.8050402@freebsd.org>
Message-ID: <200904151230.06288.jkim@FreeBSD.org>

On Wednesday 15 April 2009 12:11 pm, Andriy Gapon wrote:
> on 15/04/2009 19:08 Jung-uk Kim said the following:
> > Actually, my patch was more complex, e.g., I added more code to
> > make sure power/sleep button events get ignored and cleared when
> > it is not in S0 state, etc.  Probably I needed to track the
> > current state because of it.  I think you may ignore it for now
> > if it is not needed anywhere else.
>
> Interesting. I think that I will go with the current patch (modulo
> break->goto changes), if my mentors approve. But I would like to
> see your patch :-)

I am not sure I still have it.  It wasn't finished (thus not 
committed) because it was a lot more complex than I originally 
thought.  We really have to consolidate ACPI state tracking in one 
variable outside of ACPI softc so that it can be atomically tracked 
without complex locking/unlocking layers of various locks, e.g., 
acpi_button from DSDT, fixed buttons from FADT, acpi, giant, etc. :-(

Jung-uk Kim
From nate at root.org  Wed Apr 15 10:29:46 2009
From: nate at root.org (Nate Lawson)
Date: Wed Apr 15 11:06:33 2009
Subject: run resume code only for S1-S4 states
In-Reply-To: <49E4B2A7.3020302@freebsd.org>
References: <49DB639A.4090504@icyb.net.ua>
	<49DCF5C2.60805@root.org>	<49DDF906.8090400@icyb.net.ua>
	<49DF3CA4.1090309@freebsd.org> <49E4B2A7.3020302@freebsd.org>
Message-ID: <49E61986.7040709@root.org>

Andriy Gapon wrote:
> Guys,
> could you please review the attached patch?
> 
> Its main idea is to make control flow of acpi_EnterSleepState similar
> to that of acpi_ReqSleepState: reject invalid state parameter immediately and
> handle special S5 as early as possible. Primary purpose is to avoid running resume
> code when it is not necessary - e.g. shutdown_nice() typically returns immediately
> after initiating a graceful shutdown by sending a signal to init.
> 
> As such, S5 is handled right after checking/disabling re-entry.
> switch becomes unneeded, because all remaining possibilities are grouped
> into a single case. I decided to use do-while(0) statement in the place of the
> switch for the following reasons:
> 1. minimize diff by preserving indentation
> 2. minimize diff by preserving control flow that depends on break statement
> But I am not sure how this while(0) corresponds with style(9), I couldn't find any
> reference in the manual page.

Overall, still looks good.

I like the idea of gotos instead of the do/while(0). It's ok if the
indent changes.

> There is also a concern about calling shutdown_nice() outside of the Giant lock
> and binding to CPU 0. I am not sure about the pre-requisites for this function.
> John, maybe you could help me here?

I trust jkim's opinion also. So it is probably ok to leave this way.
Make sure someone with SMP tests that their system still powers off ok
with this patch.

Thanks,
-- 
Nate
From avg at freebsd.org  Fri Apr 17 09:31:17 2009
From: avg at freebsd.org (Andriy Gapon)
Date: Fri Apr 17 10:16:10 2009
Subject: run resume code only for S1-S4 states
In-Reply-To: <49E61986.7040709@root.org>
References: <49DB639A.4090504@icyb.net.ua>
	<49DCF5C2.60805@root.org>	<49DDF906.8090400@icyb.net.ua>
	<49DF3CA4.1090309@freebsd.org> <49E4B2A7.3020302@freebsd.org>
	<49E61986.7040709@root.org>
Message-ID: <49E8AED0.1090008@freebsd.org>


An updated version of the patch, the only difference is: do-while(0) is gone,
breaks are replaces with gotos, indentation is reduced.

Per Nate's request I am calling for people with SMP systems to test if powering
off via power button still works with this change. It's desirable to test power
off at least two times to increase a chance of non-BSP CPU being used.

-- 
Andriy Gapon
-------------- next part --------------
diff --git a/sys/dev/acpica/acpi.c b/sys/dev/acpica/acpi.c
index 50b84a5..6477125 100644
--- a/sys/dev/acpica/acpi.c
+++ b/sys/dev/acpica/acpi.c
@@ -2482,6 +2482,9 @@ acpi_EnterSleepState(struct acpi_softc *sc, int state)
 
     ACPI_FUNCTION_TRACE_U32((char *)(uintptr_t)__func__, state);
 
+    if (state < ACPI_STATE_S1 || state > ACPI_STATE_S5)
+	return_ACPI_STATUS (AE_BAD_PARAMETER);
+
     /* Re-entry once we're suspending is not allowed. */
     status = acpi_sleep_disable(sc);
     if (ACPI_FAILURE(status)) {
@@ -2489,6 +2492,15 @@ acpi_EnterSleepState(struct acpi_softc *sc, int state)
 	return (status);
     }
 
+    if (state == ACPI_STATE_S5) {
+	/*
+	 * Shut down cleanly and power off.  This will call us back through the
+	 * shutdown handlers.
+	 */
+	shutdown_nice(RB_POWEROFF);
+	return_ACPI_STATUS (AE_OK);
+    }
+
 #ifdef SMP
     thread_lock(curthread);
     sched_bind(curthread, 0);
@@ -2502,92 +2514,74 @@ acpi_EnterSleepState(struct acpi_softc *sc, int state)
     mtx_lock(&Giant);
 
     slp_state = ACPI_SS_NONE;
-    switch (state) {
-    case ACPI_STATE_S1:
-    case ACPI_STATE_S2:
-    case ACPI_STATE_S3:
-    case ACPI_STATE_S4:
-	status = AcpiGetSleepTypeData(state, &TypeA, &TypeB);
-	if (status == AE_NOT_FOUND) {
-	    device_printf(sc->acpi_dev,
-			  "Sleep state S%d not supported by BIOS\n", state);
-	    break;
-	} else if (ACPI_FAILURE(status)) {
-	    device_printf(sc->acpi_dev, "AcpiGetSleepTypeData failed - %s\n",
-			  AcpiFormatException(status));
-	    break;
-	}
+    status = AcpiGetSleepTypeData(state, &TypeA, &TypeB);
+    if (status == AE_NOT_FOUND) {
+	device_printf(sc->acpi_dev,
+		      "Sleep state S%d not supported by BIOS\n", state);
+	goto backout;
+    } else if (ACPI_FAILURE(status)) {
+	device_printf(sc->acpi_dev, "AcpiGetSleepTypeData failed - %s\n",
+		      AcpiFormatException(status));
+	goto backout;
+    }
 
-	sc->acpi_sstate = state;
+    sc->acpi_sstate = state;
 
-	/* Enable any GPEs as appropriate and requested by the user. */
-	acpi_wake_prep_walk(state);
-	slp_state = ACPI_SS_GPE_SET;
+    /* Enable any GPEs as appropriate and requested by the user. */
+    acpi_wake_prep_walk(state);
+    slp_state = ACPI_SS_GPE_SET;
 
-	/*
-	 * Inform all devices that we are going to sleep.  If at least one
-	 * device fails, DEVICE_SUSPEND() automatically resumes the tree.
-	 *
-	 * XXX Note that a better two-pass approach with a 'veto' pass
-	 * followed by a "real thing" pass would be better, but the current
-	 * bus interface does not provide for this.
-	 */
-	if (DEVICE_SUSPEND(root_bus) != 0) {
-	    device_printf(sc->acpi_dev, "device_suspend failed\n");
-	    break;
-	}
-	slp_state = ACPI_SS_DEV_SUSPEND;
+    /*
+     * Inform all devices that we are going to sleep.  If at least one
+     * device fails, DEVICE_SUSPEND() automatically resumes the tree.
+     *
+     * XXX Note that a better two-pass approach with a 'veto' pass
+     * followed by a "real thing" pass would be better, but the current
+     * bus interface does not provide for this.
+     */
+    if (DEVICE_SUSPEND(root_bus) != 0) {
+	device_printf(sc->acpi_dev, "device_suspend failed\n");
+	goto backout;
+    }
+    slp_state = ACPI_SS_DEV_SUSPEND;
 
-	/* If testing device suspend only, back out of everything here. */
-	if (acpi_susp_bounce)
-	    break;
+    /* If testing device suspend only, back out of everything here. */
+    if (acpi_susp_bounce)
+	goto backout;
 
-	status = AcpiEnterSleepStatePrep(state);
-	if (ACPI_FAILURE(status)) {
-	    device_printf(sc->acpi_dev, "AcpiEnterSleepStatePrep failed - %s\n",
-			  AcpiFormatException(status));
-	    break;
-	}
-	slp_state = ACPI_SS_SLP_PREP;
+    status = AcpiEnterSleepStatePrep(state);
+    if (ACPI_FAILURE(status)) {
+	device_printf(sc->acpi_dev, "AcpiEnterSleepStatePrep failed - %s\n",
+		      AcpiFormatException(status));
+	goto backout;
+    }
+    slp_state = ACPI_SS_SLP_PREP;
 
-	if (sc->acpi_sleep_delay > 0)
-	    DELAY(sc->acpi_sleep_delay * 1000000);
+    if (sc->acpi_sleep_delay > 0)
+	DELAY(sc->acpi_sleep_delay * 1000000);
 
-	if (state != ACPI_STATE_S1) {
-	    acpi_sleep_machdep(sc, state);
+    if (state != ACPI_STATE_S1) {
+	acpi_sleep_machdep(sc, state);
 
-	    /* Re-enable ACPI hardware on wakeup from sleep state 4. */
-	    if (state == ACPI_STATE_S4)
-		AcpiEnable();
-	} else {
-	    ACPI_DISABLE_IRQS();
-	    status = AcpiEnterSleepState(state);
-	    if (ACPI_FAILURE(status)) {
-		device_printf(sc->acpi_dev, "AcpiEnterSleepState failed - %s\n",
-			      AcpiFormatException(status));
-		break;
-	    }
+	/* Re-enable ACPI hardware on wakeup from sleep state 4. */
+	if (state == ACPI_STATE_S4)
+	    AcpiEnable();
+    } else {
+	ACPI_DISABLE_IRQS();
+	status = AcpiEnterSleepState(state);
+	if (ACPI_FAILURE(status)) {
+	    device_printf(sc->acpi_dev, "AcpiEnterSleepState failed - %s\n",
+			  AcpiFormatException(status));
+	    goto backout;
 	}
-	slp_state = ACPI_SS_SLEPT;
-	break;
-    case ACPI_STATE_S5:
-	/*
-	 * Shut down cleanly and power off.  This will call us back through the
-	 * shutdown handlers.
-	 */
-	shutdown_nice(RB_POWEROFF);
-	status = AE_OK;
-	break;
-    case ACPI_STATE_S0:
-    default:
-	status = AE_BAD_PARAMETER;
-	break;
     }
+    slp_state = ACPI_SS_SLEPT;
 
     /*
      * Back out state according to how far along we got in the suspend
      * process.  This handles both the error and success cases.
      */
+backout:
     sc->acpi_next_sstate = 0;
     if (slp_state >= ACPI_SS_GPE_SET) {
 	acpi_wake_prep_walk(state);
@@ -2609,8 +2603,7 @@ acpi_EnterSleepState(struct acpi_softc *sc, int state)
 #endif
 
     /* Allow another sleep request after a while. */
-    if (state != ACPI_STATE_S5)
-	timeout(acpi_sleep_enable, sc, hz * ACPI_MINIMUM_AWAKETIME);
+    timeout(acpi_sleep_enable, sc, hz * ACPI_MINIMUM_AWAKETIME);
 
     /* Run /etc/rc.resume after we are back. */
     if (devctl_process_running())
From smithi at nimnet.asn.au  Fri Apr 17 11:45:07 2009
From: smithi at nimnet.asn.au (Ian Smith)
Date: Fri Apr 17 12:27:36 2009
Subject: 6.x acpi powerbutton
In-Reply-To: <49DF7A1C.90009@root.org>
References: <49DE1F8B.2080400@earthlink.net> <49DE2E6D.5050001@icyb.net.ua>
	<49DE596E.2050406@earthlink.net> <49DEFF53.1040306@icyb.net.ua>
	<49DF7A1C.90009@root.org>
Message-ID: <20090418043432.O34434@sola.nimnet.asn.au>

On Fri, 10 Apr 2009, Nate Lawson wrote:
 > Andriy Gapon wrote:
 > > on 09/04/2009 23:24 Stephen Clark said the following:
 > >> Is there a reason it doesn't send and event like Linux that can be acted
 > >> upon by user space other
 > >> than signaling init? I like to have a message written in
 > >> /var/log/messages that someone pressed
 > >> the powerbutton.
 > > 
 > > I think that for all suspend states except S5 userland is notified via
 > > devd mechanism and potentially can veto the suspend. S5 (soft-off) is
 > > coded to start shutdown immediately. You can try to hack on
 > > acpi_ReqSleepState in sys/dev/acpica/acpi.c.
 > > 
 > > I am not sure what is the reason for this special behavior of S5. But I
 > > like it, because it sometimes allows me to perform semi-clean shutdown
 > > when X goes crazy. But I also see when it could be useful to have S5
 > > request go through userland. So this could be configurable.
 > 
 > The reason for userland getting into the loop in the first place was to
 > run programs to shut down devices and reinit them after resume. This
 > isn't necessary in the shutdown case because init already sends a
 > signal, as you mention.
 > 
 > There's already a mechanism for timing out if userland is not
 > responding, so a suspend will ultimately happen whether or not it
 > answers. However, that waits for a while (1 minute?) and devd used to be
 > optional, so I thought it best to keep the existing S5 behavior
 > (immediate shutdown).
 > 
 > It may be ok to enable this for S5 but I don't think it's very useful.

Perhaps a silly question, but is it too late at this stage of the game 
to try logging S5 events to syslog before dying?  I agree with Stephen, 
logging 'shutdown by powerbutton' surely beats what might otherwise 
resemble a spontaneous reboot?  Or is something already logged here?

cheers, Ian
From nate at root.org  Fri Apr 17 12:27:36 2009
From: nate at root.org (Nate Lawson)
Date: Fri Apr 17 12:54:01 2009
Subject: 6.x acpi powerbutton
In-Reply-To: <20090418043432.O34434@sola.nimnet.asn.au>
References: <49DE1F8B.2080400@earthlink.net> <49DE2E6D.5050001@icyb.net.ua>
	<49DE596E.2050406@earthlink.net> <49DEFF53.1040306@icyb.net.ua>
	<49DF7A1C.90009@root.org>
	<20090418043432.O34434@sola.nimnet.asn.au>
Message-ID: <49E8D824.1000001@root.org>

Ian Smith wrote:
> On Fri, 10 Apr 2009, Nate Lawson wrote:
>  > Andriy Gapon wrote:
>  > > on 09/04/2009 23:24 Stephen Clark said the following:
>  > >> Is there a reason it doesn't send and event like Linux that can be acted
>  > >> upon by user space other
>  > >> than signaling init? I like to have a message written in
>  > >> /var/log/messages that someone pressed
>  > >> the powerbutton.
>  > > 
>  > > I think that for all suspend states except S5 userland is notified via
>  > > devd mechanism and potentially can veto the suspend. S5 (soft-off) is
>  > > coded to start shutdown immediately. You can try to hack on
>  > > acpi_ReqSleepState in sys/dev/acpica/acpi.c.
>  > > 
>  > > I am not sure what is the reason for this special behavior of S5. But I
>  > > like it, because it sometimes allows me to perform semi-clean shutdown
>  > > when X goes crazy. But I also see when it could be useful to have S5
>  > > request go through userland. So this could be configurable.
>  > 
>  > The reason for userland getting into the loop in the first place was to
>  > run programs to shut down devices and reinit them after resume. This
>  > isn't necessary in the shutdown case because init already sends a
>  > signal, as you mention.
>  > 
>  > There's already a mechanism for timing out if userland is not
>  > responding, so a suspend will ultimately happen whether or not it
>  > answers. However, that waits for a while (1 minute?) and devd used to be
>  > optional, so I thought it best to keep the existing S5 behavior
>  > (immediate shutdown).
>  > 
>  > It may be ok to enable this for S5 but I don't think it's very useful.
> 
> Perhaps a silly question, but is it too late at this stage of the game 
> to try logging S5 events to syslog before dying?  I agree with Stephen, 
> logging 'shutdown by powerbutton' surely beats what might otherwise 
> resemble a spontaneous reboot?  Or is something already logged here?

I'm not resisting this, but I'm having trouble seeing the importance.
What happens differently than if someone hits CTRL-ALT-DEL on a virtual
console?

-- 
Nate
From nate at root.org  Fri Apr 17 13:30:30 2009
From: nate at root.org (Nate Lawson)
Date: Fri Apr 17 13:59:23 2009
Subject: 6.x acpi powerbutton
In-Reply-To: <20090417200726.GG3014@deviant.kiev.zoral.com.ua>
References: <49DE1F8B.2080400@earthlink.net> <49DE2E6D.5050001@icyb.net.ua>
	<49DE596E.2050406@earthlink.net> <49DEFF53.1040306@icyb.net.ua>
	<49DF7A1C.90009@root.org>
	<20090418043432.O34434@sola.nimnet.asn.au>
	<49E8D824.1000001@root.org>
	<20090417200726.GG3014@deviant.kiev.zoral.com.ua>
Message-ID: <49E8E6E3.40304@root.org>

Kostik Belousov wrote:
> On Fri, Apr 17, 2009 at 12:27:32PM -0700, Nate Lawson wrote:
>> Ian Smith wrote:
>>> Perhaps a silly question, but is it too late at this stage of the game 
>>> to try logging S5 events to syslog before dying?  I agree with Stephen, 
>>> logging 'shutdown by powerbutton' surely beats what might otherwise 
>>> resemble a spontaneous reboot?  Or is something already logged here?
>> I'm not resisting this, but I'm having trouble seeing the importance.
>> What happens differently than if someone hits CTRL-ALT-DEL on a virtual
>> console?
> 
> Actually, this is quite reasonable feature. Quite often, machines
> do not have physical consoles, or C-A-D is disabled. On the other
> hand, power button is quite easy to be pressed by mistake by passing
> staff.

Sure. Perhaps Andriy will pick up this task after reworking the suspend
path code for S5? It seems related.

-- 
Nate
From kostikbel at gmail.com  Fri Apr 17 13:51:26 2009
From: kostikbel at gmail.com (Kostik Belousov)
Date: Fri Apr 17 14:05:32 2009
Subject: 6.x acpi powerbutton
In-Reply-To: <49E8D824.1000001@root.org>
References: <49DE1F8B.2080400@earthlink.net> <49DE2E6D.5050001@icyb.net.ua>
	<49DE596E.2050406@earthlink.net> <49DEFF53.1040306@icyb.net.ua>
	<49DF7A1C.90009@root.org>
	<20090418043432.O34434@sola.nimnet.asn.au>
	<49E8D824.1000001@root.org>
Message-ID: <20090417200726.GG3014@deviant.kiev.zoral.com.ua>

On Fri, Apr 17, 2009 at 12:27:32PM -0700, Nate Lawson wrote:
> Ian Smith wrote:
> > Perhaps a silly question, but is it too late at this stage of the game 
> > to try logging S5 events to syslog before dying?  I agree with Stephen, 
> > logging 'shutdown by powerbutton' surely beats what might otherwise 
> > resemble a spontaneous reboot?  Or is something already logged here?
> 
> I'm not resisting this, but I'm having trouble seeing the importance.
> What happens differently than if someone hits CTRL-ALT-DEL on a virtual
> console?

Actually, this is quite reasonable feature. Quite often, machines
do not have physical consoles, or C-A-D is disabled. On the other
hand, power button is quite easy to be pressed by mistake by passing
staff.
-------------- 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/20090417/8604c3de/attachment.pgp
From cswiger at mac.com  Fri Apr 17 14:25:07 2009
From: cswiger at mac.com (Chuck Swiger)
Date: Fri Apr 17 14:57:34 2009
Subject: 6.x acpi powerbutton
In-Reply-To: <49E8D824.1000001@root.org>
References: <49DE1F8B.2080400@earthlink.net> <49DE2E6D.5050001@icyb.net.ua>
	<49DE596E.2050406@earthlink.net> <49DEFF53.1040306@icyb.net.ua>
	<49DF7A1C.90009@root.org> <20090418043432.O34434@sola.nimnet.asn.au>
	<49E8D824.1000001@root.org>
Message-ID: <1F394E42-BB02-41AC-8A52-C47A76EC55C9@mac.com>

On Apr 17, 2009, at 12:27 PM, Nate Lawson wrote:
>> Perhaps a silly question, but is it too late at this stage of the  
>> game
>> to try logging S5 events to syslog before dying?  I agree with  
>> Stephen,
>> logging 'shutdown by powerbutton' surely beats what might otherwise
>> resemble a spontaneous reboot?  Or is something already logged here?
>
> I'm not resisting this, but I'm having trouble seeing the importance.
> What happens differently than if someone hits CTRL-ALT-DEL on a  
> virtual
> console?

Well, I'd like to get a one-line message saying "rebooted by CTRL-ALT- 
DEL" versus "shutdown by powerbutton".  Other systems would log a one- 
liner like "system rebooted by /etc/shutdown -i 6: _MESSAGE_"....

Regards,
-- 
-Chuck

From sclark46 at earthlink.net  Fri Apr 17 20:22:49 2009
From: sclark46 at earthlink.net (Stephen Clark)
Date: Sat Apr 18 04:56:15 2009
Subject: 6.x acpi powerbutton
In-Reply-To: <49E8D824.1000001@root.org>
References: <49DE1F8B.2080400@earthlink.net> <49DE2E6D.5050001@icyb.net.ua>
	<49DE596E.2050406@earthlink.net> <49DEFF53.1040306@icyb.net.ua>
	<49DF7A1C.90009@root.org>
	<20090418043432.O34434@sola.nimnet.asn.au>
	<49E8D824.1000001@root.org>
Message-ID: <49E944DE.7080409@earthlink.net>

Nate Lawson wrote:
> Ian Smith wrote:
>> On Fri, 10 Apr 2009, Nate Lawson wrote:
>>  > Andriy Gapon wrote:
>>  > > on 09/04/2009 23:24 Stephen Clark said the following:
>>  > >> Is there a reason it doesn't send and event like Linux that can be acted
>>  > >> upon by user space other
>>  > >> than signaling init? I like to have a message written in
>>  > >> /var/log/messages that someone pressed
>>  > >> the powerbutton.
>>  > > 
>>  > > I think that for all suspend states except S5 userland is notified via
>>  > > devd mechanism and potentially can veto the suspend. S5 (soft-off) is
>>  > > coded to start shutdown immediately. You can try to hack on
>>  > > acpi_ReqSleepState in sys/dev/acpica/acpi.c.
>>  > > 
>>  > > I am not sure what is the reason for this special behavior of S5. But I
>>  > > like it, because it sometimes allows me to perform semi-clean shutdown
>>  > > when X goes crazy. But I also see when it could be useful to have S5
>>  > > request go through userland. So this could be configurable.
>>  > 
>>  > The reason for userland getting into the loop in the first place was to
>>  > run programs to shut down devices and reinit them after resume. This
>>  > isn't necessary in the shutdown case because init already sends a
>>  > signal, as you mention.
>>  > 
>>  > There's already a mechanism for timing out if userland is not
>>  > responding, so a suspend will ultimately happen whether or not it
>>  > answers. However, that waits for a while (1 minute?) and devd used to be
>>  > optional, so I thought it best to keep the existing S5 behavior
>>  > (immediate shutdown).
>>  > 
>>  > It may be ok to enable this for S5 but I don't think it's very useful.
>>
>> Perhaps a silly question, but is it too late at this stage of the game 
>> to try logging S5 events to syslog before dying?  I agree with Stephen, 
>> logging 'shutdown by powerbutton' surely beats what might otherwise 
>> resemble a spontaneous reboot?  Or is something already logged here?
> 
> I'm not resisting this, but I'm having trouble seeing the importance.
> What happens differently than if someone hits CTRL-ALT-DEL on a virtual
> console?
> 
Hi Nate,

We have over 500 units in the field that are used as firewall/vpn/routers. They 
have no console, but they do have a powerbutton. We have had customers say the 
machine turned itself off. It would be nice to know that someone pressed the 
power button.

Thanks,
Steve

-- 

"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety."  (Ben Franklin)

"The course of history shows that as a government grows, liberty
decreases."  (Thomas Jefferson)


From smithi at nimnet.asn.au  Sat Apr 18 01:28:18 2009
From: smithi at nimnet.asn.au (Ian Smith)
Date: Sat Apr 18 05:16:58 2009
Subject: 6.x acpi powerbutton
In-Reply-To: <1F394E42-BB02-41AC-8A52-C47A76EC55C9@mac.com>
References: <49DE1F8B.2080400@earthlink.net> <49DE2E6D.5050001@icyb.net.ua>
	<49DE596E.2050406@earthlink.net> <49DEFF53.1040306@icyb.net.ua>
	<49DF7A1C.90009@root.org> <20090418043432.O34434@sola.nimnet.asn.au>
	<49E8D824.1000001@root.org>
	<1F394E42-BB02-41AC-8A52-C47A76EC55C9@mac.com>
Message-ID: <20090418170826.T34434@sola.nimnet.asn.au>

On Fri, 17 Apr 2009, Chuck Swiger wrote:
 > On Apr 17, 2009, at 12:27 PM, Nate Lawson wrote:
 > > > Perhaps a silly question, but is it too late at this stage of the game
 > > > to try logging S5 events to syslog before dying?  I agree with Stephen,
 > > > logging 'shutdown by powerbutton' surely beats what might otherwise
 > > > resemble a spontaneous reboot?  Or is something already logged here?
 > > 
 > > I'm not resisting this, but I'm having trouble seeing the importance.
 > > What happens differently than if someone hits CTRL-ALT-DEL on a virtual
 > > console?
 > 
 > Well, I'd like to get a one-line message saying "rebooted by CTRL-ALT-DEL"
 > versus "shutdown by powerbutton".  Other systems would log a one-liner like
 > "system rebooted by /etc/shutdown -i 6: _MESSAGE_"....

I don't know about C-A-D as I've always disabled it in my kernels - lest 
some 'windows expert' may be hoping to see a TaskList - but 'reboot' and 
'shutdown -[rhp] ..' are already logged nicely:

May 31 16:25:26 paqi reboot: rebooted by root
May 31 16:25:26 paqi syslogd: exiting on signal 15
May 31 16:26:30 paqi syslogd: kernel boot file is /boot/kernel/kernel

Mar 31 20:04:14 paqi shutdown: power-down by smithi: down after fixing localtime Sydney
Mar 31 19:04:32 paqi named[16442]: stopping command channel on 127.0.0.1#953
Mar 31 19:04:33 paqi named[16442]: exiting
Mar 31 19:04:33 paqi syslogd: exiting on signal 15
Mar 31 19:07:16 paqi syslogd: kernel boot file is /boot/kernel/kernel

I suspect a 'windows expert' would have to break down doors to get to 
Nate's boxes, but for those of us condemned to being remote catherders, 
a powerbutton shutdown message would be helpful.

cheers, Ian
From freebsd-listen at fabiankeil.de  Sat Apr 18 04:11:51 2009
From: freebsd-listen at fabiankeil.de (Fabian Keil)
Date: Sat Apr 18 05:29:36 2009
Subject: run resume code only for S1-S4 states
In-Reply-To: <49E8AED0.1090008@freebsd.org>
References: <49DB639A.4090504@icyb.net.ua> <49DCF5C2.60805@root.org>
	<49DDF906.8090400@icyb.net.ua> <49DF3CA4.1090309@freebsd.org>
	<49E4B2A7.3020302@freebsd.org> <49E61986.7040709@root.org>
	<49E8AED0.1090008@freebsd.org>
Message-ID: <20090418125806.2a48b0a8@fabiankeil.de>

Andriy Gapon <avg@freebsd.org> wrote:

> An updated version of the patch, the only difference is: do-while(0) is gone,
> breaks are replaces with gotos, indentation is reduced.
> 
> Per Nate's request I am calling for people with SMP systems to test if powering
> off via power button still works with this change. It's desirable to test power
> off at least two times to increase a chance of non-BSP CPU being used.

With an AMD Athlon(tm) 64 X2 Dual Core Processor 4600+ (2542.15-MHz K8-class CPU)
the first few shutdowns were successful, but on the fourth try pressing the
power button only lead to:

Apr 18 12:52:42 kendra kernel: acpi: suspend request ignored (not ready yet)
Apr 18 12:52:42 kendra kernel: acpi: request to enter state S5 failed (err 6)
Apr 18 12:52:43 kendra kernel: acpi: suspend request ignored (not ready yet)
Apr 18 12:52:43 kendra kernel: acpi: request to enter state S5 failed (err 6)
Apr 18 12:52:43 kendra kernel: acpi: suspend request ignored (not ready yet)
Apr 18 12:52:43 kendra kernel: acpi: request to enter state S5 failed (err 6)
[...]

Fabian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-acpi/attachments/20090418/098074c3/signature.pgp
From nate at root.org  Sat Apr 18 16:28:36 2009
From: nate at root.org (Nate Lawson)
Date: Sat Apr 18 16:28:43 2009
Subject: run resume code only for S1-S4 states
In-Reply-To: <20090418125806.2a48b0a8@fabiankeil.de>
References: <49DB639A.4090504@icyb.net.ua>
	<49DCF5C2.60805@root.org>	<49DDF906.8090400@icyb.net.ua>
	<49DF3CA4.1090309@freebsd.org>	<49E4B2A7.3020302@freebsd.org>
	<49E61986.7040709@root.org>	<49E8AED0.1090008@freebsd.org>
	<20090418125806.2a48b0a8@fabiankeil.de>
Message-ID: <49E9FFB0.6090707@root.org>

Fabian Keil wrote:
> Andriy Gapon <avg@freebsd.org> wrote:
> 
>> An updated version of the patch, the only difference is: do-while(0) is gone,
>> breaks are replaces with gotos, indentation is reduced.
>>
>> Per Nate's request I am calling for people with SMP systems to test if powering
>> off via power button still works with this change. It's desirable to test power
>> off at least two times to increase a chance of non-BSP CPU being used.
> 
> With an AMD Athlon(tm) 64 X2 Dual Core Processor 4600+ (2542.15-MHz K8-class CPU)
> the first few shutdowns were successful, but on the fourth try pressing the
> power button only lead to:
> 
> Apr 18 12:52:42 kendra kernel: acpi: suspend request ignored (not ready yet)
> Apr 18 12:52:42 kendra kernel: acpi: request to enter state S5 failed (err 6)
> Apr 18 12:52:43 kendra kernel: acpi: suspend request ignored (not ready yet)
> Apr 18 12:52:43 kendra kernel: acpi: request to enter state S5 failed (err 6)
> Apr 18 12:52:43 kendra kernel: acpi: suspend request ignored (not ready yet)
> Apr 18 12:52:43 kendra kernel: acpi: request to enter state S5 failed (err 6)
> [...]

Yes, I think the case for S5 should probably come before
acpi_sleep_disable().

-- 
Nate
From william88 at gmail.com  Sun Apr 19 19:58:07 2009
From: william88 at gmail.com (William Grzybowski)
Date: Sun Apr 19 19:58:13 2009
Subject: EST on PentiumD-T2080
Message-ID: <20090419223118.GA1320@venon.lostgarden>

Hi,

I'm running 8-CURRENT from yesterday.

Before the update I was running the snapshot for 2008-02.

In this snapshot the cpufreq with EST seemed t be working fine, but after the update it is not recognizing the processor MSR.

After a little bit of debugging I was able to get my MSR (32 most significant bits) as 0x06190d28 .
And this value is not in the ESTprocs list, which would be ID32(1300, 1340, 600, 1100, 100) and does not make any sense for this CPU.

So, the ESTprocs list hasn't changed for a while if I've looked it right which means the rdmsr instruction is returning the wrong data for some reason!?

I am not any kind of the expert in the subject, just curious what could be wrong...

The CPU is:
CPU: Genuine Intel(R) CPU           T2080  @ 1.73GHz (1733.41-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0x6ec  Stepping = 12
  Features=0xbfe9fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
  Features2=0xc189<SSE3,MON,EST,TM2,xTPR,PDCM>
  AMD Features=0x100000<NX>
  TSC: P-state invariant
  Cores per package: 2

Any toughts?

Thank you.
From william88 at gmail.com  Sun Apr 19 20:16:47 2009
From: william88 at gmail.com (William Grzybowski)
Date: Sun Apr 19 20:16:55 2009
Subject: EST on PentiumD-T2080
In-Reply-To: <20090419223118.GA1320@venon.lostgarden>
References: <20090419223118.GA1320@venon.lostgarden>
Message-ID: <20090419231713.GA1118@venon.lostgarden>

Well, forget about it, sorry.

I realized that the static table is not really necessary, the est.c tries to fetch the table list from ACPI.

I recompiled the module once again and now the freq_list has a lot of possible frequencies, a lot more than before.

Before I send the first e-mail there as only 6 and I could not set any of them because was listed as XXXX/-1.

This problem is possible related to my bug laptop's acpi which has a lot of errors about allocating resources.

By the way, I already sent a couple of e-mails to this list before, ACPI is a subject which I really like, maybe there is any kind of task (development) that I could accomplish to help the freebsd project and increases my knowledge about this?

That's all, sorry for the annoyance with the previously e-mail.

William.

On Sun, Apr 19, 2009 at 07:31:18PM -0300, William Grzybowski wrote:
> Hi,
> 
> I'm running 8-CURRENT from yesterday.
> 
> Before the update I was running the snapshot for 2008-02.
> 
> In this snapshot the cpufreq with EST seemed t be working fine, but after the update it is not recognizing the processor MSR.
> 
> After a little bit of debugging I was able to get my MSR (32 most significant bits) as 0x06190d28 .
> And this value is not in the ESTprocs list, which would be ID32(1300, 1340, 600, 1100, 100) and does not make any sense for this CPU.
> 
> So, the ESTprocs list hasn't changed for a while if I've looked it right which means the rdmsr instruction is returning the wrong data for some reason!?
> 
> I am not any kind of the expert in the subject, just curious what could be wrong...
> 
> The CPU is:
> CPU: Genuine Intel(R) CPU           T2080  @ 1.73GHz (1733.41-MHz 686-class CPU)
>   Origin = "GenuineIntel"  Id = 0x6ec  Stepping = 12
>   Features=0xbfe9fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
>   Features2=0xc189<SSE3,MON,EST,TM2,xTPR,PDCM>
>   AMD Features=0x100000<NX>
>   TSC: P-state invariant
>   Cores per package: 2
> 
> Any toughts?
> 
> Thank you.
From bugmaster at FreeBSD.org  Mon Apr 20 11:06:47 2009
From: bugmaster at FreeBSD.org (FreeBSD bugmaster)
Date: Mon Apr 20 11:07:09 2009
Subject: Current problem reports assigned to freebsd-acpi@FreeBSD.org
Message-ID: <200904201106.n3KB6kks032915@freefall.freebsd.org>

Note: to view an individual PR, use:
  http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.


S Tracker      Resp.      Description
--------------------------------------------------------------------------------
o kern/132602  acpi       [acpi] ACPI Problem with Intel SS4200: System does not
o kern/130683  acpi       [ACPI] shutdown hangs after syncing disks - ACPI race?
o i386/129953  acpi       [acpi] ACPI timeout (CDROM) with Shuttle X27D
o kern/129618  acpi       [acpi] Problem with ACPI on HP Pavilion DV2899 laptop
o kern/129563  acpi       [acpi] sleep broken on IBM/Lenovo T61 in amd64 mode
o kern/128639  acpi       [patch] [acpi_asus] acpi for ASUS A6F,A3E,A3F,A3N not 
f kern/128634  acpi       [patch] fix acpi_asus(4) in asus a6f laptop
o kern/127581  acpi       [patch] [acpi_sony] Add support for more Sony features
o kern/124744  acpi       [acpi] [patch] incorrect _BST result validation for To
o kern/124412  acpi       [acpi] power off error on Toshiba M40 laptop
o kern/123039  acpi       [acpi] ACPI AML_BUFFER_LIMIT errors during boot
o kern/121504  acpi       [patch] Correctly set hw.acpi.osname on certain machin
f kern/121454  acpi       [pst] Promise SuperTrak SX6000 does not load during bo
o kern/121102  acpi       [acpi_fujitsu] [patch] update acpi_fujitsu for the P80
o kern/120515  acpi       [acpi] [patch] acpi_alloc_wakeup_handler: can't alloc 
o kern/119356  acpi       [acpi]: i386 ACPI wakeup not work due resource exhaust
o kern/119200  acpi       [acpi] Lid close switch suspends CPU for 1 second on H
o kern/118973  acpi       [acpi]: Kernel panic with acpi boot
o kern/117605  acpi       [acpi] [request] add debug.cpufreq.highest
o kern/116939  acpi       [acpi] PCI-to-PCI misconfigured for bus three and can 
o i386/114562  acpi       [acpi] cardbus is dead after s3 on Thinkpad T43 with a
o kern/114165  acpi       [acpi] Dell C810 - ACPI problem
s kern/112544  acpi       [acpi] [patch] Add High Precision Event Timer Driver f
o kern/108954  acpi       [acpi] 'sleep(1)' sleeps >1 seconds when speedstep (Cx
o kern/108695  acpi       [acpi]: Fatal trap 9: general protection fault when in
o kern/108488  acpi       [acpi] ACPI-1304: *** Error: Method execution failed
o kern/108017  acpi       [acpi]: Acer Aspire 5600
o kern/106924  acpi       [acpi] ACPI resume returns g_vfs_done() errors and ker
o kern/105537  acpi       [acpi] problems in acpi on HP Compaq nc6320
o kern/104625  acpi       ACPI on ASUS A8N-32 SLI/ASUS P4P800 does not show ther
o kern/102252  acpi       acpi thermal does not work on Abit AW8D (intel 975)
o kern/97383   acpi       Volume buttons on IBM Thinkpad crash system with ACPI
s i386/91748   acpi       acpi problem on Acer TravelMare 4652LMi (nvidia panic,
s kern/91038   acpi       [panic] [ata] [acpi] 6.0-RELEASE on Fujitsu Siemens Am
s kern/90243   acpi       Laptop fan doesn't turn off (ACPI enabled) (Packard Be
f kern/89411   acpi       [acpi] acpiconf bug
o i386/83018   acpi       [install] Installer will not boot on Asus P4S8X BIOS 1
o kern/81000   acpi       [apic] Via 8235 sound card worked great with FreeBSD 5
o i386/79081   acpi       ACPI suspend/resume not working on HP nx6110
o kern/76950   acpi       ACPI wrongly blacklisted on Micron ClientPro 766Xi sys
s kern/73823   acpi       [request] acpi / power-on by timer support
o i386/72566   acpi       ACPI, FreeBSD disables fan on Compaq Armada 1750
o i386/69750   acpi       Boot without ACPI failed on ASUS L5
f kern/67309   acpi       zzz reboot computer (ACPI S3)
o kern/56024   acpi       ACPI suspend drains battery while in S3
o i386/55661   acpi       ACPI suspend/resume problem on ARMADA M700
o i386/54756   acpi       ACPI suspend/resume problem on CF-W2 laptop

47 problems total.

From avg at freebsd.org  Mon Apr 20 11:47:34 2009
From: avg at freebsd.org (Andriy Gapon)
Date: Mon Apr 20 11:47:41 2009
Subject: run resume code only for S1-S4 states
In-Reply-To: <49E9FFB0.6090707@root.org>
References: <49DB639A.4090504@icyb.net.ua>
	<49DCF5C2.60805@root.org>	<49DDF906.8090400@icyb.net.ua>
	<49DF3CA4.1090309@freebsd.org>	<49E4B2A7.3020302@freebsd.org>
	<49E61986.7040709@root.org>	<49E8AED0.1090008@freebsd.org>
	<20090418125806.2a48b0a8@fabiankeil.de> <49E9FFB0.6090707@root.org>
Message-ID: <49EC60C6.7000702@freebsd.org>

on 18/04/2009 19:28 Nate Lawson said the following:
> Fabian Keil wrote:
>> Andriy Gapon <avg@freebsd.org> wrote:
>>
>>> An updated version of the patch, the only difference is: do-while(0) is gone,
>>> breaks are replaces with gotos, indentation is reduced.
>>>
>>> Per Nate's request I am calling for people with SMP systems to test if powering
>>> off via power button still works with this change. It's desirable to test power
>>> off at least two times to increase a chance of non-BSP CPU being used.
>> With an AMD Athlon(tm) 64 X2 Dual Core Processor 4600+ (2542.15-MHz K8-class CPU)
>> the first few shutdowns were successful, but on the fourth try pressing the
>> power button only lead to:
>>
>> Apr 18 12:52:42 kendra kernel: acpi: suspend request ignored (not ready yet)
>> Apr 18 12:52:42 kendra kernel: acpi: request to enter state S5 failed (err 6)
>> Apr 18 12:52:43 kendra kernel: acpi: suspend request ignored (not ready yet)
>> Apr 18 12:52:43 kendra kernel: acpi: request to enter state S5 failed (err 6)
>> Apr 18 12:52:43 kendra kernel: acpi: suspend request ignored (not ready yet)
>> Apr 18 12:52:43 kendra kernel: acpi: request to enter state S5 failed (err 6)
>> [...]
> 
> Yes, I think the case for S5 should probably come before
> acpi_sleep_disable().

Right now the patch tries to preserve the same behavior in this respect
as the current code has. I don't have a good understanding of
overlapping requests to enter different sleep states and potential bad
effects (e.g. S1 request while soft power off is already in progress).

But in this case I actually wonder what left ACPI driver is "sleep
disabled" state. Did the first soft poweroff attempt fail and caused
subsequent attempts to be disabled? Hmm, if so, then I wonder why it
could have failed.

-- 
Andriy Gapon
From william88 at gmail.com  Mon Apr 20 14:46:01 2009
From: william88 at gmail.com (William Grzybowski)
Date: Mon Apr 20 14:46:07 2009
Subject: Workaround pci-pci bridge resources
Message-ID: <20090420144616.GA1162@venon.lostgarden>

Almost a year and a half ago I did report a problem with my laptop and ACPI, which was unable to allocate resources for my NIC (msk).
Which you can see here: http://lists.freebsd.org/pipermail/freebsd-acpi/2007-August/003968.html

Today I was seeing some code to understand a little bit more about how ACPI works (pci host, bridge etc).

Then I tried some workaround for my problem, allocating resource for the PCI-PCI Bridge when attaching, and surprise, it's workng now.

As I can understund so far, the devices passes the allocation to their parent recursively until some of them can handle it, am I right? So doing this is not the right way to solve the problem and I am forcing a memory resource and being active even if there is no device attached to its bridge, but maybe it could help for now...
Or would pcib_alloc_resource not handling it correctly as pcib1 parent is pci0?

Any thoughts?

PATCH: http://dev.agencialivre.com.br/pub/patch_pci-pci-bridge.txt

Thanks!
From dan at dburkland.com  Mon Apr 20 15:33:21 2009
From: dan at dburkland.com (Daniel Burkland)
Date: Mon Apr 20 15:33:27 2009
Subject: ACPI Issues: Dell Vostro 1310 
Message-ID: <9BF0E9EFFF8AD245AAB6AAB1542D95965A094CED@mail>

Let me start out by saying I am a rookie when it comes to FreeBSD so I apologize if I forgot some information. Before I list the debug information let me briefly explain my issue. I have installed FreeBSD 7.1 i386 on my Dell Vostro and it seems that the machine will not be properly shutdown when using the command "shutdown -p now". According to the output the machine halts but for some reason there is miscommunication between the software and the ACPI on my laptop. Below I have listed the full hardware specs along with the required debug information. Thank you so much for your help!

Full Hardware Specs
Laptop Model: Dell Vostro 1310
CPU: Core 2 Duo Merom T7250
DVDRW: Integrated Drive Electronics Teac DVD+/-RW
HDD: 320GB WD-ML160
WIFI: Broadcom 4312
NVIDIA: 8400GS 128MB

Dmesg output after boot -v: http://dburkland.net/freebsd/dmesg1.log

Dmesg output after boot -v with ACPI disabled: http://dburkland.net/freebsd/dmesg2.log

Output from systctl hw.acpi: http://dburkland.net/freebsd/sysctloutput.log

URL where my ASL can be found: http://dburkland.net/freebsd/dan@dburkland.com-DellVostro1310.asl

Again I want to prematurely thank you guys for taking a look at this!

Daniel Burkland
dan@dburkland.com

From nate at root.org  Mon Apr 20 16:05:03 2009
From: nate at root.org (Nate Lawson)
Date: Mon Apr 20 16:05:09 2009
Subject: run resume code only for S1-S4 states
In-Reply-To: <49EC60C6.7000702@freebsd.org>
References: <49DB639A.4090504@icyb.net.ua>
	<49DCF5C2.60805@root.org>	<49DDF906.8090400@icyb.net.ua>
	<49DF3CA4.1090309@freebsd.org>	<49E4B2A7.3020302@freebsd.org>
	<49E61986.7040709@root.org>	<49E8AED0.1090008@freebsd.org>
	<20090418125806.2a48b0a8@fabiankeil.de>
	<49E9FFB0.6090707@root.org> <49EC60C6.7000702@freebsd.org>
Message-ID: <49EC9D2F.8080701@root.org>

Andriy Gapon wrote:
> on 18/04/2009 19:28 Nate Lawson said the following:
>> Fabian Keil wrote:
>>> Andriy Gapon <avg@freebsd.org> wrote:
>>>
>>>> An updated version of the patch, the only difference is: do-while(0) is gone,
>>>> breaks are replaces with gotos, indentation is reduced.
>>>>
>>>> Per Nate's request I am calling for people with SMP systems to test if powering
>>>> off via power button still works with this change. It's desirable to test power
>>>> off at least two times to increase a chance of non-BSP CPU being used.
>>> With an AMD Athlon(tm) 64 X2 Dual Core Processor 4600+ (2542.15-MHz K8-class CPU)
>>> the first few shutdowns were successful, but on the fourth try pressing the
>>> power button only lead to:
>>>
>>> Apr 18 12:52:42 kendra kernel: acpi: suspend request ignored (not ready yet)
>>> Apr 18 12:52:42 kendra kernel: acpi: request to enter state S5 failed (err 6)
>>> Apr 18 12:52:43 kendra kernel: acpi: suspend request ignored (not ready yet)
>>> Apr 18 12:52:43 kendra kernel: acpi: request to enter state S5 failed (err 6)
>>> Apr 18 12:52:43 kendra kernel: acpi: suspend request ignored (not ready yet)
>>> Apr 18 12:52:43 kendra kernel: acpi: request to enter state S5 failed (err 6)
>>> [...]
>> Yes, I think the case for S5 should probably come before
>> acpi_sleep_disable().
> 
> Right now the patch tries to preserve the same behavior in this respect
> as the current code has. I don't have a good understanding of
> overlapping requests to enter different sleep states and potential bad
> effects (e.g. S1 request while soft power off is already in progress).
> 
> But in this case I actually wonder what left ACPI driver is "sleep
> disabled" state. Did the first soft poweroff attempt fail and caused
> subsequent attempts to be disabled? Hmm, if so, then I wonder why it
> could have failed.

It's a good question. Better to figure out why the first poweroff failed.

-- 
Nate
From avg at icyb.net.ua  Tue Apr 21 16:57:42 2009
From: avg at icyb.net.ua (Andriy Gapon)
Date: Tue Apr 21 16:57:48 2009
Subject: 6.x acpi powerbutton
In-Reply-To: <49E8E6E3.40304@root.org>
References: <49DE1F8B.2080400@earthlink.net> <49DE2E6D.5050001@icyb.net.ua>
	<49DE596E.2050406@earthlink.net> <49DEFF53.1040306@icyb.net.ua>
	<49DF7A1C.90009@root.org>
	<20090418043432.O34434@sola.nimnet.asn.au>
	<49E8D824.1000001@root.org>
	<20090417200726.GG3014@deviant.kiev.zoral.com.ua>
	<49E8E6E3.40304@root.org>
Message-ID: <49EDFAED.4030606@icyb.net.ua>

on 17/04/2009 23:30 Nate Lawson said the following:
> Sure. Perhaps Andriy will pick up this task after reworking the suspend
> path code for S5? It seems related.

Oh I think that this would be a much easier and independent task.
Right now I have the following in my local tree, but I think that it might be
better to limit the message to S5 state only, so that people with laptops do not
complain about extra spam.

diff --git a/sys/dev/acpica/acpi.c b/sys/dev/acpica/acpi.c
index 8a592d2..f3e0c1f 100644
--- a/sys/dev/acpica/acpi.c
+++ b/sys/dev/acpica/acpi.c
@@ -2169,6 +2169,8 @@ acpi_ReqSleepState(struct acpi_softc *sc, int state)
     if (state < ACPI_STATE_S1 || state > ACPI_STATE_S5)
 	return (EINVAL);

+    printf("acpi: request to enter S%d sleep state\n", state);
+
     /* S5 (soft-off) should be entered directly with no waiting. */
     if (state == ACPI_STATE_S5) {
 	if (ACPI_SUCCESS(acpi_EnterSleepState(sc, state)))

-- 
Andriy Gapon
From avg at freebsd.org  Tue Apr 21 17:00:47 2009
From: avg at freebsd.org (Andriy Gapon)
Date: Tue Apr 21 17:00:52 2009
Subject: run resume code only for S1-S4 states
In-Reply-To: <49EC9D2F.8080701@root.org>
References: <49DB639A.4090504@icyb.net.ua>
	<49DCF5C2.60805@root.org>	<49DDF906.8090400@icyb.net.ua>
	<49DF3CA4.1090309@freebsd.org>	<49E4B2A7.3020302@freebsd.org>
	<49E61986.7040709@root.org>	<49E8AED0.1090008@freebsd.org>
	<20090418125806.2a48b0a8@fabiankeil.de>
	<49E9FFB0.6090707@root.org> <49EC60C6.7000702@freebsd.org>
	<49EC9D2F.8080701@root.org>
Message-ID: <49EDFBBA.1080504@freebsd.org>

on 20/04/2009 19:05 Nate Lawson said the following:
> It's a good question. Better to figure out why the first poweroff failed.

Nate,
do you have any suggestion on how to debug this?

Fabian,

maybe you have some additional info like any other messages appearing in the logs,
whether the system eventually went down, etc. BTW, did something like this ever
happen before applying the patch? I mean power button press not shutting down the
system.

-- 
Andriy Gapon
From nate at root.org  Tue Apr 21 19:03:02 2009
From: nate at root.org (Nate Lawson)
Date: Tue Apr 21 19:03:09 2009
Subject: 6.x acpi powerbutton
In-Reply-To: <49EDFAED.4030606@icyb.net.ua>
References: <49DE1F8B.2080400@earthlink.net> <49DE2E6D.5050001@icyb.net.ua>
	<49DE596E.2050406@earthlink.net> <49DEFF53.1040306@icyb.net.ua>
	<49DF7A1C.90009@root.org>
	<20090418043432.O34434@sola.nimnet.asn.au>
	<49E8D824.1000001@root.org>
	<20090417200726.GG3014@deviant.kiev.zoral.com.ua>
	<49E8E6E3.40304@root.org> <49EDFAED.4030606@icyb.net.ua>
Message-ID: <49EE1863.1000306@root.org>

Andriy Gapon wrote:
> on 17/04/2009 23:30 Nate Lawson said the following:
>> Sure. Perhaps Andriy will pick up this task after reworking the suspend
>> path code for S5? It seems related.
> 
> Oh I think that this would be a much easier and independent task.
> Right now I have the following in my local tree, but I think that it might be
> better to limit the message to S5 state only, so that people with laptops do not
> complain about extra spam.
> 
> diff --git a/sys/dev/acpica/acpi.c b/sys/dev/acpica/acpi.c
> index 8a592d2..f3e0c1f 100644
> --- a/sys/dev/acpica/acpi.c
> +++ b/sys/dev/acpica/acpi.c
> @@ -2169,6 +2169,8 @@ acpi_ReqSleepState(struct acpi_softc *sc, int state)
>      if (state < ACPI_STATE_S1 || state > ACPI_STATE_S5)
>  	return (EINVAL);
> 
> +    printf("acpi: request to enter S%d sleep state\n", state);
> +
>      /* S5 (soft-off) should be entered directly with no waiting. */
>      if (state == ACPI_STATE_S5) {
>  	if (ACPI_SUCCESS(acpi_EnterSleepState(sc, state)))
> 

I don't think that's what they're asking for. The normal shutdown
process creates log entries, even if destined for poweroff. For example,
shutdown -p will log before powering off. acpi_ReqSleepState() can come
through /dev/apm, sysctl, etc. as well as the power button handler.

They are interested in the initiator of the event, the button itself. So
you'd be adding a printf to the power button handler, "power button
pressed". Then the normal shutdown messages would be logged but they
would know the reason. Remember that with sysctl, you can configure
different events to button mappings. So the power button could be used
to initiate a suspend, for example.

-- 
Nate
From avg at icyb.net.ua  Wed Apr 22 13:04:16 2009
From: avg at icyb.net.ua (Andriy Gapon)
Date: Wed Apr 22 13:04:28 2009
Subject: 6.x acpi powerbutton
In-Reply-To: <49EE1863.1000306@root.org>
References: <49DE1F8B.2080400@earthlink.net> <49DE2E6D.5050001@icyb.net.ua>
	<49DE596E.2050406@earthlink.net> <49DEFF53.1040306@icyb.net.ua>
	<49DF7A1C.90009@root.org>
	<20090418043432.O34434@sola.nimnet.asn.au>
	<49E8D824.1000001@root.org>
	<20090417200726.GG3014@deviant.kiev.zoral.com.ua>
	<49E8E6E3.40304@root.org> <49EDFAED.4030606@icyb.net.ua>
	<49EE1863.1000306@root.org>
Message-ID: <49EF15B0.10402@icyb.net.ua>

on 21/04/2009 22:02 Nate Lawson said the following:
> 
> I don't think that's what they're asking for. The normal shutdown
> process creates log entries, even if destined for poweroff. For example,
> shutdown -p will log before powering off. acpi_ReqSleepState() can come
> through /dev/apm, sysctl, etc. as well as the power button handler.

Yes, the normal shutdown does log. But the other types of Sx state changes do not
seem to get logged anywhere, so I think that that log message might still be useful.

> They are interested in the initiator of the event, the button itself. So
> you'd be adding a printf to the power button handler, "power button
> pressed". Then the normal shutdown messages would be logged but they
> would know the reason. Remember that with sysctl, you can configure
> different events to button mappings. So the power button could be used
> to initiate a suspend, for example.

Yes, I agree.
Which place do you think is the best for this log - acpi sleep event handler
(acpi_system_eventhandler_sleep) or individual sleep event triggers (power button
sleep button, lid)?

-- 
Andriy Gapon
From freebsd-listen at fabiankeil.de  Wed Apr 22 16:32:22 2009
From: freebsd-listen at fabiankeil.de (Fabian Keil)
Date: Wed Apr 22 16:32:30 2009
Subject: run resume code only for S1-S4 states
In-Reply-To: <49EDFBBA.1080504@freebsd.org>
References: <49DB639A.4090504@icyb.net.ua> <49DCF5C2.60805@root.org>
	<49DDF906.8090400@icyb.net.ua> <49DF3CA4.1090309@freebsd.org>
	<49E4B2A7.3020302@freebsd.org> <49E61986.7040709@root.org>
	<49E8AED0.1090008@freebsd.org>
	<20090418125806.2a48b0a8@fabiankeil.de> <49E9FFB0.6090707@root.org>
	<49EC60C6.7000702@freebsd.org> <49EC9D2F.8080701@root.org>
	<49EDFBBA.1080504@freebsd.org>
Message-ID: <20090422183214.1e3372c6@fabiankeil.de>

Andriy Gapon <avg@freebsd.org> wrote:

> on 20/04/2009 19:05 Nate Lawson said the following:
> > It's a good question. Better to figure out why the first poweroff failed.

> Fabian,
> 
> maybe you have some additional info like any other messages appearing in the logs,
> whether the system eventually went down, etc. BTW, did something like this ever
> happen before applying the patch? I mean power button press not shutting down the
> system.

There were no other messages that seemed to be related to the problem.
I've never seen the problem on the system before, however I don't use
the power button that often.

When the problem occurred, I tried the power button several times
but only got more of the messages. I waited a few minutes and finally
powered the system down with "shutdown -p now" which worked flawlessly.

Fabian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-acpi/attachments/20090422/ac8eefe7/signature.pgp
From robert.moore at intel.com  Wed Apr 22 20:33:55 2009
From: robert.moore at intel.com (Moore, Robert)
Date: Wed Apr 22 21:04:16 2009
Subject: ACPICA version 20090422 released
Message-ID: <4911F71203A09E4D9981D27F9D83085822400C96@orsmsx503.amr.corp.intel.com>

22 April 2009. Summary of changes for version 20090422:

This release is available at www.acpica.org/downloads

1) ACPI CA Core Subsystem:

Fixed a compatibility issue with the recently released I/O port protection mechanism. For windows compatibility, 1) On a port protection violation, simply ignore the request and do not return an exception (allow the control method to continue execution.) 2) If only part of the request overlaps a protected port, read/write the individual ports that are not protected. Linux BZ 13036. Lin Ming

Enhanced the execution of the ASL/AML BreakPoint operator so that it actually breaks into the AML debugger if the debugger is present. This matches the ACPI-defined behavior.

Fixed several possible warnings related to the use of the configurable ACPI_THREAD_ID. This type can now be configured as either an integer or a pointer with no warnings. Also fixes several warnings in printf-like statements for the 64-bit build when the type is configured as a pointer. ACPICA BZ 766, 767.

Fixed a number of possible warnings when compiling with gcc 4+ (depending on warning options.) Examples include printf formats, aliasing, unused globals, missing prototypes, missing switch default statements, use of non-ANSI library functions, use of non-ANSI constructs. See generate/unix/Makefile for a list of warning options used with gcc 3 and 4. ACPICA BZ 735.

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:  82.6K Code, 17.6K Data, 100.2K Total
    Debug Version:     157.7K Code, 49.9K Data, 207.6K Total
  Current Release:
    Non-Debug Version:  82.8K Code, 17.5K Data, 100.3K Total
    Debug Version:     158.0K Code, 49.9K Data, 207.9K Total

2) iASL Compiler/Disassembler and Tools:

iASL: Fixed a generation warning from Bison 2.3 and fixed several warnings on the 64-bit build.

iASL: Fixed a problem where the Unix/Linux versions of the compiler could not correctly digest Windows/DOS formatted files (with CR/LF).

iASL: Added a new option for "quiet mode" (-va) that produces only the compilation summary, not individual errors and warnings. Useful for large batch compilations.

AcpiExec: Implemented a new option (-z) to enable a forced semaphore/mutex timeout that can be used to detect hang conditions during execution of AML code (includes both internal semaphores and AML-defined mutexes and events.)

Added new makefiles for the generation of acpica in a generic unix-like environment. These makefiles are intended to generate the acpica tools and utilities from the original acpica git source tree structure.

Test Suites: Updated and cleaned up the documentation files. Updated the copyrights to 2009, affecting all source files. Use the new version of iASL with quiet mode. Increased the number of available semaphores in the Windows OSL, allowing the aslts to execute fully on Windows. For the Unix OSL, added an alternate implementation of the semaphore timeout to allow aslts to execute fully on Cygwin.

From update+a2=690a6 at facebookmail.com  Thu Apr 23 05:01:00 2009
From: update+a2=690a6 at facebookmail.com (Facebook)
Date: Thu Apr 23 05:01:07 2009
Subject: Reminder: Maitri invited you to join Facebook...
Message-ID: <81a679fdb244a35264d1d753dcb63c5e@localhost.localdomain>

Hi Freebsd-acpi,

The following person recently invited you to be their friend on Facebook:

Other people you may know on Facebook:

Facebook is a great place to keep in touch with friends, post photos, videos and create events. But first you need to join! Sign up today to create a profile and connect with the people you know.

Thanks,
The Facebook Team

To sign up for Facebook, follow the link below:
http://www.facebook.com/r.php?re=3b7fa7b14cadbb3c688b37af717919fc&mid=59efb3G3c33d580G2663bcG46

This message was intended for freebsd-acpi@freebsd.org. If you do not wish to receive this type of email from Facebook in the future, please click on the link below to unsubscribe.
http://www.facebook.com/o.php?c&k=282090&u=1010029952&mid=59efb3G3c33d580G2663bcG46
Facebook's offices are located at 156 University Ave., Palo Alto, CA 94301.

From klingfon at gmail.com  Thu Apr 23 13:47:42 2009
From: klingfon at gmail.com (M K)
Date: Thu Apr 23 13:47:49 2009
Subject: Kernel panic on 7.2-RC1 when booting with ACPI enabled kernel.
Message-ID: <43b1bb350904230622u4b7790f0p9f665b649c97a3b@mail.gmail.com>

Hi!

I upgraded my fileserver from 7.0 to 7.2-RC1 using the freebsd-update
method. Everything went fine during the upgrade but when I attempted to boot
with the new kernel(GENERIC) the default choice of kernel with ACPI enabled
did not work. I have to boot by choosing the kernel with ACPI disabled. And
then it boots perfect. When I used 7.0 everything worked fine.

dmesg when booting without ACPI and ASL can be found on
http://midroc.dyndns.org/~kling/
I have little experience of using kgdb and debugging. So if I should pull
out some more info from the dump please specify exactly what I should write.

I have tried to disable things in BIOS but without luck.

Best regards,
Magnus

This is what a bt and list of instruction pointer from kgdb has to offer:

GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd"...

Unread portion of the kernel message buffer:
Copyright (c) 1992-2009 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
        The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 7.1-RELEASE-p5 #1: Thu Apr 23 12:46:52 CEST 2009
    root@kling.telia.se:/usr/obj/usr/src/sys/GENERIC
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Intel(R) Pentium(R) 4 CPU 2.40GHz (2405.46-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0xf27  Stepping = 7

Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,C
MOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
  Features2=0x4400<CNXT-ID,xTPR>
real memory  = 268353536 (255 MB)
avail memory = 248500224 (236 MB)
ACPI APIC Table: <ASUS   P4T533-C>
ioapic0 <Version 2.0> irqs 0-23 on motherboard
kbd1 at kbdmux0
ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413)
acpi0: <ASUS P4T533-C> on motherboard
acpi0: [ITHREAD]
acpi0: Power Button (fixed)
acpi0: reservation of 0, a0000 (3) failed
acpi0: reservation of 100000, ff00000 (3) failed
Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
acpi_timer0: <24-bit timer at 3.579545MHz> port 0xe408-0xe40b on acpi0
acpi_button0: <Power Button> on acpi0
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pci0: <ACPI PCI bus> on pcib0
agp0: <Intel 82850 host to AGP bridge> on hostb0
pcib1: <ACPI PCI-PCI bridge> at device 1.0 on pci0
pci1: <ACPI PCI bus> on pcib1
vgapci0: <VGA-compatible display> mem
0xee000000-0xeeffffff,0xf0000000-0xf7ffffff irq 16 at device 0.0 on pci1
pcib2: <ACPI PCI-PCI bridge> at device 30.0 on pci0
pci2: <ACPI PCI bus> on pcib2
ohci0: <NEC uPD 9210 USB controller> mem 0xed800000-0xed800fff irq 21 at
device 4.0 on pci2
ohci0: [GIANT-LOCKED]
ohci0: [ITHREAD]
usb0: OHCI version 1.0
usb0: <NEC uPD 9210 USB controller> on ohci0
usb0: USB revision 1.0
uhub0: <NEC OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb0
uhub0: 3 ports with 3 removable, self powered
ohci1: <NEC uPD 9210 USB controller> mem 0xed000000-0xed000fff irq 22 at
device 4.1 on pci2
ohci1: [GIANT-LOCKED]
ohci1: [ITHREAD]
usb1: OHCI version 1.0
usb1: <NEC uPD 9210 USB controller> on ohci1
usb1: USB revision 1.0
uhub1: <NEC OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb1
uhub1: 2 ports with 2 removable, self powered
ehci0: <NEC uPD 720100 USB 2.0 controller> mem 0xec800000-0xec8000ff irq 23
at device 4.2 on pci2
ehci0: [GIANT-LOCKED]
ehci0: [ITHREAD]
usb2: EHCI version 0.95
usb2: companion controllers, 3 ports each: usb0 usb1
usb2: <NEC uPD 720100 USB 2.0 controller> on ehci0
usb2: USB revision 2.0
uhub2: <NEC EHCI root hub, class 9/0, rev 2.00/1.00, addr 1> on usb2
uhub2: 5 ports with 5 removable, self powered
atapci0: <Promise PDC20621 UDMA100 controller> port
0xd800-0xd8ff,0xd400-0xd4ff, 0xd000-0xd0ff mem
0xec000000-0xec0fffff,0xeb800000-0xeb807fff irq 22 at device 10.0 on pci2
atapci0: [ITHREAD]
atapci0: [ITHREAD]
atapci0: DIMM size 128MB @ 0x00000000
ata2: <ATA channel 0> on atapci0
ata2: [ITHREAD]
ata3: <ATA channel 1> on atapci0
ata3: [ITHREAD]
ata4: <ATA channel 2> on atapci0
ata4: [ITHREAD]
ata5: <ATA channel 3> on atapci0
ata5: [ITHREAD]
xl0: <3Com 3c905B-TX Fast Etherlink XL> port 0xb800-0xb87f mem
0xeb000000-0xeb00007f irq 20 at device 12.0 on pci2
miibus0: <MII bus> on xl0
xlphy0: <3Com internal media interface> PHY 24 on miibus0
xlphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
xl0: Ethernet address: 00:10:4b:45:ba:cf
xl0: [ITHREAD]
xl1: <3Com 3c905-TX Fast Etherlink XL> port 0xb400-0xb43f irq 18 at device
13.0 on pci2
miibus1: <MII bus> on xl1
nsphy0: <DP83840 10/100 media interface> PHY 24 on miibus1
nsphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
xl1: Ethernet address: 00:60:08:6b:45:f2
xl1: [ITHREAD]
isab0: <PCI-ISA bridge> at device 31.0 on pci0
isa0: <ISA bus> on isab0
atapci1: <Intel ICH2 UDMA100 controller> port
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xa800-0xa80f at device 31.1 on pci0
ata0: <ATA channel 0> on atapci1
ata0: [ITHREAD]
ata1: <ATA channel 1> on atapci1
ata1: [ITHREAD]
uhci0: <Intel 82801BA/BAM (ICH2) USB controller USB-A> port 0xa400-0xa41f
irq 19 at device 31.2 on pci0
uhci0: [GIANT-LOCKED]
uhci0: [ITHREAD]
usb3: <Intel 82801BA/BAM (ICH2) USB controller USB-A> on uhci0
usb3: USB revision 1.0
uhub3: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb3
uhub3: 2 ports with 2 removable, self powered
uhci1: <Intel 82801BA/BAM (ICH2) USB controller USB-B> port 0xa000-0xa01f
irq 23 at device 31.4 on pci0
uhci1: [GIANT-LOCKED]
uhci1: [ITHREAD]
usb4: <Intel 82801BA/BAM (ICH2) USB controller USB-B> on uhci1
usb4: USB revision 1.0
uhub4: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb4
uhub4: 2 ports with 2 removable, self powered
sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on
acpi0
sio0: type 16550A
sio0: [FILTER]
sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0
sio1: type 16550A
sio1: [FILTER]
atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
atkbd0: [ITHREAD]
cpu0: <ACPI CPU> on acpi0
p4tcc0: <CPU Frequency Thermal Control> on cpu0
pmtimer0 on isa0
orm0: <ISA Option ROM> at iomem 0xd0000-0xdc7ff pnpid ORM0000 on isa0
ppc0: <Parallel port> at port 0x378-0x37f irq 7 on isa0
ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode
ppc0: FIFO with 16/16/9 bytes threshold
ppbus0: <Parallel port bus> on ppc0
ppbus0: [ITHREAD]
plip0: <PLIP network interface> on ppbus0
plip0: WARNING: using obsoleted IFF_NEEDSGIANT flag
lpt0: <Printer> on ppbus0
lpt0: Interrupt-driven port
ppi0: <Parallel I/O> on ppbus0
ppc0: [GIANT-LOCKED]
ppc0: [ITHREAD]
sc0: <System console> at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
Timecounter "TSC" frequency 2405464112 Hz quality 800
Timecounters tick every 1.000 msec
ad0: 238475MB <Hitachi HDP725025GLAT80 GM2OA42A> at ata0-master UDMA100
ad8: 238475MB <Seagate ST3250820A 3.AAE> at ata4-master UDMA100
ad10: 238475MB <Seagate ST3250820A 3.AAE> at ata5-master UDMA100
ar0: 238475MB <Promise Fasttrak RAID1> status: READY
ar0: disk0 READY (master) using ad8 at ata4-master
ar0: disk1 READY (mirror) using ad10 at ata5-master
Trying to mount root from ufs:/dev/ad0s1a
<118>Loading configuration files.
<118>kernel dumps on /dev/ad0s1b
<118>Entropy harvesting:
<118> interrupts
<118> ethernet
<118> point_to_point


Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0xb
fault code              = supervisor read, page not present
instruction pointer     = 0x20:0xc0da4de7
stack pointer           = 0x28:0xcd1e6aac
frame pointer           = 0x28:0xcd1e6aac
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, def32 1, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 70 (sysctl)
trap number             = 12
panic: page fault
cpuid = 0
Uptime: 1s
Physical memory: 243 MB
Dumping 27 MB: 12

Reading symbols from /boot/kernel/acpi.ko...Reading symbols from
/boot/kernel/acpi.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/acpi.ko
#0  doadump () at pcpu.h:196
196             __asm __volatile("movl %%fs:0,%0" : "=r" (td));
(kgdb) list *0xc0da4de7
0xc0da4de7 is in AcpiNsMapHandleToNode
(/usr/src/sys/modules/acpi/acpi/../../../contrib/dev/acpica/nsutils.c:889).
884             return (AcpiGbl_RootNode);
885         }
886
887         /* We can at least attempt to verify the handle */
888
889         if (ACPI_GET_DESCRIPTOR_TYPE (Handle) != ACPI_DESC_TYPE_NAMED)
890         {
891             return (NULL);
892         }
893
(kgdb) bt
#0  doadump () at pcpu.h:196
#1  0xc0790eb7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418
#2  0xc0791189 in panic (fmt=Variable "fmt" is not available.
) at /usr/src/sys/kern/kern_shutdown.c:574
#3  0xc0aa339c in trap_fatal (frame=0xcd1e6a6c, eva=11)
    at /usr/src/sys/i386/i386/trap.c:939
#4  0xc0aa3620 in trap_pfault (frame=0xcd1e6a6c, usermode=0, eva=11)
    at /usr/src/sys/i386/i386/trap.c:852
#5  0xc0aa3fdc in trap (frame=0xcd1e6a6c) at
/usr/src/sys/i386/i386/trap.c:530
#6  0xc0a89e4b in calltrap () at /usr/src/sys/i386/i386/exception.s:159
#7  0xc0da4de7 in AcpiNsMapHandleToNode (Handle=0x7)
    at
/usr/src/sys/modules/acpi/acpi/../../../contrib/dev/acpica/nsutils.c:889
#8  0xc0da44cf in AcpiNsHandleToPathname (TargetHandle=0x7,
Buffer=0xcd1e6ae0)
    at
/usr/src/sys/modules/acpi/acpi/../../../contrib/dev/acpica/nsnames.c:320
#9  0xc0db0a72 in acpi_name (handle=0x7)
    at /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/acpi.c:2842
#10 0xc0db4ca8 in acpi_pci_child_location_str_method (cbdev=0xc2212680,
    child=0xc2243400, buf=0xc22c2400 "slot=0 function=0 handle=",
buflen=1024)
    at /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/acpi_pci.c:150
#11 0xc07b4ca6 in bus_child_location_str (child=0xc2243400,
    buf=0xc22c2400 "slot=0 function=0 handle=", buflen=1024) at bus_if.h:604
#12 0xc07b4f49 in device_sysctl_handler (oidp=0xc223f780, arg1=0xc2243400,
    arg2=2, req=0xcd1e6ba4) at /usr/src/sys/kern/subr_bus.c:256
#13 0xc079a707 in sysctl_root (oidp=Variable "oidp" is not available.
) at /usr/src/sys/kern/kern_sysctl.c:1307
From gavin at FreeBSD.org  Thu Apr 23 14:30:59 2009
From: gavin at FreeBSD.org (gavin@FreeBSD.org)
Date: Thu Apr 23 14:31:06 2009
Subject: kern/67309: zzz reboot computer (ACPI S3)
Message-ID: <200904231430.n3NEUwIV074246@freefall.freebsd.org>

Synopsis: zzz reboot computer (ACPI S3)

State-Changed-From-To: feedback->closed
State-Changed-By: gavin
State-Changed-When: Thu Apr 23 14:28:48 UTC 2009
State-Changed-Why: 
Feedback timeout (~1 year).  Far too much has been changed in the
ACPI subsystem since FreeBSD 5.2 for it to be worthwhile keeping
this PR open without feedback, I'm afraid.  To submitter: if you
are still able to test it, we can reopen this PR.


Responsible-Changed-From-To: freebsd-acpi->gavin
Responsible-Changed-By: gavin
Responsible-Changed-When: Thu Apr 23 14:28:48 UTC 2009
Responsible-Changed-Why: 


http://www.freebsd.org/cgi/query-pr.cgi?pr=67309
From avg at freebsd.org  Thu Apr 23 16:41:11 2009
From: avg at freebsd.org (Andriy Gapon)
Date: Thu Apr 23 16:41:17 2009
Subject: run resume code only for S1-S4 states
In-Reply-To: <20090422183214.1e3372c6@fabiankeil.de>
References: <49DB639A.4090504@icyb.net.ua>	<49DCF5C2.60805@root.org>	<49DDF906.8090400@icyb.net.ua>	<49DF3CA4.1090309@freebsd.org>	<49E4B2A7.3020302@freebsd.org>	<49E61986.7040709@root.org>	<49E8AED0.1090008@freebsd.org>	<20090418125806.2a48b0a8@fabiankeil.de>	<49E9FFB0.6090707@root.org>	<49EC60C6.7000702@freebsd.org>	<49EC9D2F.8080701@root.org>	<49EDFBBA.1080504@freebsd.org>
	<20090422183214.1e3372c6@fabiankeil.de>
Message-ID: <49F09A23.9080802@freebsd.org>

on 22/04/2009 19:32 Fabian Keil said the following:
> There were no other messages that seemed to be related to the problem.
> I've never seen the problem on the system before, however I don't use
> the power button that often.
> 
> When the problem occurred, I tried the power button several times
> but only got more of the messages. I waited a few minutes and finally
> powered the system down with "shutdown -p now" which worked flawlessly.
> 

Fabian,

I realize that this is not much fun, but could you please apply the below patch on
top of the previous patch and try to reproduce the problem?


diff --git a/sys/dev/acpica/acpi.c b/sys/dev/acpica/acpi.c
index 6477125..0432fab 100644
--- a/sys/dev/acpica/acpi.c
+++ b/sys/dev/acpica/acpi.c
@@ -2497,7 +2497,9 @@ acpi_EnterSleepState(struct acpi_softc *sc, int state)
 	 * Shut down cleanly and power off.  This will call us back through the
 	 * shutdown handlers.
 	 */
+	printf("acpi: S5 - before shutdown_nice");
 	shutdown_nice(RB_POWEROFF);
+	printf("acpi: S5 - after shutdown_nice");
 	return_ACPI_STATUS (AE_OK);
     }



-- 
Andriy Gapon
From jhb at freebsd.org  Fri Apr 24 17:11:40 2009
From: jhb at freebsd.org (John Baldwin)
Date: Fri Apr 24 17:11:46 2009
Subject: Kernel panic on 7.2-RC1 when booting with ACPI enabled kernel.
In-Reply-To: <43b1bb350904230622u4b7790f0p9f665b649c97a3b@mail.gmail.com>
References: <43b1bb350904230622u4b7790f0p9f665b649c97a3b@mail.gmail.com>
Message-ID: <200904240828.17663.jhb@freebsd.org>

On Thursday 23 April 2009 9:22:29 am M K wrote:
> Hi!
> 
> I upgraded my fileserver from 7.0 to 7.2-RC1 using the freebsd-update
> method. Everything went fine during the upgrade but when I attempted to boot
> with the new kernel(GENERIC) the default choice of kernel with ACPI enabled
> did not work. I have to boot by choosing the kernel with ACPI disabled. And
> then it boots perfect. When I used 7.0 everything worked fine.
> 
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address   = 0xb
> fault code              = supervisor read, page not present
> instruction pointer     = 0x20:0xc0da4de7
> stack pointer           = 0x28:0xcd1e6aac
> frame pointer           = 0x28:0xcd1e6aac
> code segment            = base 0x0, limit 0xfffff, type 0x1b
>                         = DPL 0, pres 1, def32 1, gran 1
> processor eflags        = interrupt enabled, resume, IOPL = 0
> current process         = 70 (sysctl)
> trap number             = 12
> panic: page fault
> cpuid = 0
> Uptime: 1s
> Physical memory: 243 MB
> Dumping 27 MB: 12
> 
> Reading symbols from /boot/kernel/acpi.ko...Reading symbols from
> /boot/kernel/acpi.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/acpi.ko
> #0  doadump () at pcpu.h:196
> 196             __asm __volatile("movl %%fs:0,%0" : "=r" (td));
> (kgdb) list *0xc0da4de7
> 0xc0da4de7 is in AcpiNsMapHandleToNode
> (/usr/src/sys/modules/acpi/acpi/../../../contrib/dev/acpica/nsutils.c:889).
> 884             return (AcpiGbl_RootNode);
> 885         }
> 886
> 887         /* We can at least attempt to verify the handle */
> 888
> 889         if (ACPI_GET_DESCRIPTOR_TYPE (Handle) != ACPI_DESC_TYPE_NAMED)
> 890         {
> 891             return (NULL);
> 892         }
> 893
> (kgdb) bt
> #0  doadump () at pcpu.h:196
> #1  0xc0790eb7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418
> #2  0xc0791189 in panic (fmt=Variable "fmt" is not available.
> ) at /usr/src/sys/kern/kern_shutdown.c:574
> #3  0xc0aa339c in trap_fatal (frame=0xcd1e6a6c, eva=11)
>     at /usr/src/sys/i386/i386/trap.c:939
> #4  0xc0aa3620 in trap_pfault (frame=0xcd1e6a6c, usermode=0, eva=11)
>     at /usr/src/sys/i386/i386/trap.c:852
> #5  0xc0aa3fdc in trap (frame=0xcd1e6a6c) at
> /usr/src/sys/i386/i386/trap.c:530
> #6  0xc0a89e4b in calltrap () at /usr/src/sys/i386/i386/exception.s:159
> #7  0xc0da4de7 in AcpiNsMapHandleToNode (Handle=0x7)
>     at
> /usr/src/sys/modules/acpi/acpi/../../../contrib/dev/acpica/nsutils.c:889
> #8  0xc0da44cf in AcpiNsHandleToPathname (TargetHandle=0x7,
> Buffer=0xcd1e6ae0)
>     at
> /usr/src/sys/modules/acpi/acpi/../../../contrib/dev/acpica/nsnames.c:320
> #9  0xc0db0a72 in acpi_name (handle=0x7)
>     at /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/acpi.c:2842
> #10 0xc0db4ca8 in acpi_pci_child_location_str_method (cbdev=0xc2212680,
>     child=0xc2243400, buf=0xc22c2400 "slot=0 function=0 handle=",
> buflen=1024)
>     at /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/acpi_pci.c:150

Can you do 'frame 10' followed by 'p *(struct acpi_pci_devinfo *)child->ivars'

-- 
John Baldwin
From bahamasfranks at gmail.com  Sat Apr 25 06:46:59 2009
From: bahamasfranks at gmail.com (Steve Franks)
Date: Sat Apr 25 06:47:05 2009
Subject: lenovo s10e minor errors
Message-ID: <539c60b90904242313g20a3e6e4q20e555b318798764@mail.gmail.com>

Hi,

These in no way seem to affect my system (although it won't resume, I
suspect that's seperate), but I thought someone would want a look at
it, since these netbooks are pretty new.

Incidentally, if anyone picks one up, there's no bios-block against
replacing the broadcom 80211 with a ath (i.e. sparklan).

Best,
Steve

[steve@terra /usr/home/steve/projects/include]$ dmesg
ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler [20070320]
ACPI Error (psparse-0626): Method parse/execution failed
[\\_TZ_.TZ00._TMP] (Node 0xc41b7220), AE_NOT_EXIST
ACPI Error (evregion-0427): No handler for Region [ERAM] (0xc41b8c80)
[EmbeddedControl] [20070320]
ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler [20070320]
ACPI Error (psparse-0626): Method parse/execution failed
[\\_TZ_.TZ00._TMP] (Node 0xc41b7220), AE_NOT_EXIST
ACPI Error (evregion-0427): No handler for Region [ERAM] (0xc41b8c80)
[EmbeddedControl] [20070320]
ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler [20070320]
ACPI Error (psparse-0626): Method parse/execution failed [\\_GPE._L02]
(Node 0xc41b74a0), AE_NOT_EXIST
ACPI Exception (evgpe-0687): AE_NOT_EXIST, while evaluating GPE method
[_L02] [20070320]
ACPI Error (evregion-0427): No handler for Region [ERAM] (0xc41b8c80)
[EmbeddedControl] [20070320]
ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler [20070320]

etc...as you can see, they overrun the dmesg buffer after a few minutes...
From freebsd-listen at fabiankeil.de  Sat Apr 25 08:21:24 2009
From: freebsd-listen at fabiankeil.de (Fabian Keil)
Date: Sat Apr 25 08:21:31 2009
Subject: run resume code only for S1-S4 states
In-Reply-To: <49F09A23.9080802@freebsd.org>
References: <49DB639A.4090504@icyb.net.ua> <49DCF5C2.60805@root.org>
	<49DDF906.8090400@icyb.net.ua> <49DF3CA4.1090309@freebsd.org>
	<49E4B2A7.3020302@freebsd.org> <49E61986.7040709@root.org>
	<49E8AED0.1090008@freebsd.org>
	<20090418125806.2a48b0a8@fabiankeil.de> <49E9FFB0.6090707@root.org>
	<49EC60C6.7000702@freebsd.org> <49EC9D2F.8080701@root.org>
	<49EDFBBA.1080504@freebsd.org>
	<20090422183214.1e3372c6@fabiankeil.de>
	<49F09A23.9080802@freebsd.org>
Message-ID: <20090425102109.0520ce59@fabiankeil.de>

Andriy Gapon <avg@freebsd.org> wrote:

> on 22/04/2009 19:32 Fabian Keil said the following:
> > There were no other messages that seemed to be related to the problem.
> > I've never seen the problem on the system before, however I don't use
> > the power button that often.
> > 
> > When the problem occurred, I tried the power button several times
> > but only got more of the messages. I waited a few minutes and finally
> > powered the system down with "shutdown -p now" which worked flawlessly.

> I realize that this is not much fun, but could you please apply the below patch on
> top of the previous patch and try to reproduce the problem?

Sure. It turns out that the problem is unrelated to your patch.
I can reproduce it with an unpatched kernel too, by once pressing
the power button before the second core is started.

I probably did the same a few days ago, and forgot about it. Sorry.

With your patch, the messages are:

Apr 25 10:01:07 kendra kernel: Enter passphrase for ad4s1d: acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 
Apr 25 10:01:07 kendra kernel: (probe0:ata0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 
Apr 25 10:01:07 kendra kernel: (probe0:ata0:0:0:0): CAM Status: SCSI Status Error
Apr 25 10:01:07 kendra kernel: (probe0:ata0:0:0:0): SCSI Status: Check Condition
Apr 25 10:01:07 kendra kernel: (probe0:ata0:0:0:0): NOT READY asc:3a,0
Apr 25 10:01:07 kendra kernel: (probe0:ata0:0:0:0): Medium not present
Apr 25 10:01:07 kendra kernel: (probe0:ata0:0:0:0): Unretryable error
Apr 25 10:01:07 kendra kernel: uhub5: 10 ports with 10 removable, self powered
Apr 25 10:01:07 kendra kernel: acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 
Apr 25 10:01:07 kendra kernel: acpi: S5 - before shutdown_nice
Apr 25 10:01:07 kendra kernel: acpi: S5 - after shutdown_nice
Apr 25 10:01:07 kendra kernel: 
Apr 25 10:01:07 kendra kernel: GEOM_ELI: Device ad4s1d.eli created.
Apr 25 10:01:07 kendra kernel: GEOM_ELI: Encryption: AES-CBC 256
Apr 25 10:01:07 kendra kernel: GEOM_ELI:     Crypto: software
Apr 25 10:01:07 kendra kernel: run_interrupt_driven_hooks: still waiting after 60 seconds for
Apr 25 10:01:07 kendra kernel: cd0 at ata0 bus 0 target 0 lun 0
Apr 25 10:01:07 kendra kernel: cd0: <LITE-ON DVDRW LDW-811S HS0R> Removable CD-ROM SCSI-0 device SMP: AP CPU #
Apr 25 10:01:07 kendra kernel: 1 Launccdh0e:d !33.000MB/s transfers
Apr 25 10:01:07 kendra kernel: 
[...]
Apr 25 10:01:24 kendra kernel: acpi: suspend request ignored (not ready yet)
Apr 25 10:01:24 kendra kernel: acpi: request to enter state S5 failed (err 6)
Apr 25 10:01:27 kendra kernel: acpi: suspend request ignored (not ready yet)
Apr 25 10:01:27 kendra kernel: acpi: request to enter state S5 failed (err 6)
Apr 25 10:01:27 kendra kernel: acpi: suspend request ignored (not ready yet)
Apr 25 10:01:27 kendra kernel: acpi: request to enter state S5 failed (err 6)
Apr 25 10:01:28 kendra kernel: acpi: suspend request ignored (not ready yet)
Apr 25 10:01:28 kendra kernel: acpi: request to enter state S5 failed (err 6)
Apr 25 10:01:28 kendra kernel: acpi: suspend request ignored (not ready yet)
Apr 25 10:01:28 kendra kernel: acpi: request to enter state S5 failed (err 6)
Apr 25 10:01:28 kendra kernel: acpi: suspend request ignored (not ready yet)
Apr 25 10:01:28 kendra kernel: acpi: request to enter state S5 failed (err 6)

Fabian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-acpi/attachments/20090425/774c8f42/signature.pgp
From klingfon at gmail.com  Sat Apr 25 10:27:26 2009
From: klingfon at gmail.com (Magnus Kling)
Date: Sat Apr 25 10:27:32 2009
Subject: Fwd: Kernel panic on 7.2-RC1 when booting with ACPI enabled kernel.
In-Reply-To: <43b1bb350904250326o63cb3085vc6a7079fba7cd700@mail.gmail.com>
References: <43b1bb350904230622u4b7790f0p9f665b649c97a3b@mail.gmail.com>
	<200904240828.17663.jhb@freebsd.org>
	<43b1bb350904250326o63cb3085vc6a7079fba7cd700@mail.gmail.com>
Message-ID: <43b1bb350904250327n2bc0c651y7e725abda56538b0@mail.gmail.com>

2009/4/24 John Baldwin <jhb@freebsd.org>

On Thursday 23 April 2009 9:22:29 am M K wrote:
> > Hi!
> >
> > I upgraded my fileserver from 7.0 to 7.2-RC1 using the freebsd-update
> > method. Everything went fine during the upgrade but when I attempted to
> boot
> > with the new kernel(GENERIC) the default choice of kernel with ACPI
> enabled
> > did not work. I have to boot by choosing the kernel with ACPI disabled.
> And
> > then it boots perfect. When I used 7.0 everything worked fine.
> >
> > Fatal trap 12: page fault while in kernel mode
> > cpuid = 0; apic id = 00
> > fault virtual address   = 0xb
> > fault code              = supervisor read, page not present
> > instruction pointer     = 0x20:0xc0da4de7
> > stack pointer           = 0x28:0xcd1e6aac
> > frame pointer           = 0x28:0xcd1e6aac
> > code segment            = base 0x0, limit 0xfffff, type 0x1b
> >                         = DPL 0, pres 1, def32 1, gran 1
> > processor eflags        = interrupt enabled, resume, IOPL = 0
> > current process         = 70 (sysctl)
> > trap number             = 12
> > panic: page fault
> > cpuid = 0
> > Uptime: 1s
> > Physical memory: 243 MB
> > Dumping 27 MB: 12
> >
> > Reading symbols from /boot/kernel/acpi.ko...Reading symbols from
> > /boot/kernel/acpi.ko.symbols...done.
> > done.
> > Loaded symbols for /boot/kernel/acpi.ko
> > #0  doadump () at pcpu.h:196
> > 196             __asm __volatile("movl %%fs:0,%0" : "=r" (td));
> > (kgdb) list *0xc0da4de7
> > 0xc0da4de7 is in AcpiNsMapHandleToNode
> >
> (/usr/src/sys/modules/acpi/acpi/../../../contrib/dev/acpica/nsutils.c:889).
> > 884             return (AcpiGbl_RootNode);
> > 885         }
> > 886
> > 887         /* We can at least attempt to verify the handle */
> > 888
> > 889         if (ACPI_GET_DESCRIPTOR_TYPE (Handle) !=
> ACPI_DESC_TYPE_NAMED)
> > 890         {
> > 891             return (NULL);
> > 892         }
> > 893
> > (kgdb) bt
> > #0  doadump () at pcpu.h:196
> > #1  0xc0790eb7 in boot (howto=260) at
> /usr/src/sys/kern/kern_shutdown.c:418
> > #2  0xc0791189 in panic (fmt=Variable "fmt" is not available.
> > ) at /usr/src/sys/kern/kern_shutdown.c:574
> > #3  0xc0aa339c in trap_fatal (frame=0xcd1e6a6c, eva=11)
> >     at /usr/src/sys/i386/i386/trap.c:939
> > #4  0xc0aa3620 in trap_pfault (frame=0xcd1e6a6c, usermode=0, eva=11)
> >     at /usr/src/sys/i386/i386/trap.c:852
> > #5  0xc0aa3fdc in trap (frame=0xcd1e6a6c) at
> > /usr/src/sys/i386/i386/trap.c:530
> > #6  0xc0a89e4b in calltrap () at /usr/src/sys/i386/i386/exception.s:159
> > #7  0xc0da4de7 in AcpiNsMapHandleToNode (Handle=0x7)
> >     at
> > /usr/src/sys/modules/acpi/acpi/../../../contrib/dev/acpica/nsutils.c:889
> > #8  0xc0da44cf in AcpiNsHandleToPathname (TargetHandle=0x7,
> > Buffer=0xcd1e6ae0)
> >     at
> > /usr/src/sys/modules/acpi/acpi/../../../contrib/dev/acpica/nsnames.c:320
> > #9  0xc0db0a72 in acpi_name (handle=0x7)
> >     at /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/acpi.c:2842
> > #10 0xc0db4ca8 in acpi_pci_child_location_str_method (cbdev=0xc2212680,
> >     child=0xc2243400, buf=0xc22c2400 "slot=0 function=0 handle=",
> > buflen=1024)
> >     at /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/acpi_pci.c:150
>
> Can you do 'frame 10' followed by 'p *(struct acpi_pci_devinfo
> *)child->ivars'
>
> --
> John Baldwin


Sure, no problem. This is a none critical server so I can do alot of
debugging and testing if that is needed.


(kgdb) frame 10
#10 0xc0db4ca8 in acpi_pci_child_location_str_method (cbdev=0xc2212680,
    child=0xc2243400, buf=0xc22c2400 "slot=0 function=0 handle=",
buflen=1024)
    at /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/acpi_pci.c:150
150             strlcat(buf, acpi_name(dinfo->ap_handle), buflen);

(kgdb)  p *(struct acpi_pci_devinfo *)child->ivars
$1 = {ap_dinfo = {pci_links = {stqe_next = 0xc0b00f8c}, resources = {
      stqh_first = 0xc0b00f8c, stqh_last = 0x1030000}, cfg = {dev = 0x0,
      bar = {4, 0, 0, 3257136600, 0, 0}, bios = 0, subvendor = 0,
      subdevice = 0, vendor = 0, device = 0, cmdreg = 0, statreg = 0,
      baseclass = 0 '\0', subclass = 0 '\0', progif = 0 '\0', revid = 0
'\0',
      hdrtype = 0 '\0', cachelnsz = 0 '\0', intpin = 0 '\0', intline = 0
'\0',
      mingnt = 0 '\0', maxlat = 0 '\0', lattimer = 0 '\0', mfdev = 0 '\0',
      nummaps = 80 'P', domain = 3257157632, bus = 4 '\004', slot = 0 '\0',
      func = 0 '\0', pp = {pp_cap = 5696, pp_status = 36 '$',
        pp_pmcsr = 194 '?', pp_data = 0 '\0'}, vpd = {vpd_reg = 0 '\0',
        vpd_cached = 0 '\0', vpd_ident = 0x0, vpd_rocnt = -1037758948,
        vpd_ros = 0x14, vpd_wcnt = 0, vpd_w = 0x0}, msi = {msi_ctrl = 0,
        msi_location = 0 '\0', msi_msgnum = 0 '\0', msi_alloc = 0,
        msi_addr = 0, msi_data = 7248, msi_handlers = 3257137472}, msix = {
        msix_ctrl = 1477, msix_msgnum = 0, msix_location = 0 '\0',
        msix_table_bar = 0 '\0', msix_pba_bar = 0 '\0',
        msix_table_offset = 3257280512, msix_pba_offset = 0,
        msix_alloc = -1037820896, msix_table_len = -1065660736,
        msix_table = 0xc0b2bb52, msix_vectors = 0x1,
        msix_table_res = 0xc222e660, msix_pba_res = 0x0}, ht = {
        ht_msimap = 0 '\0', ht_msictrl = 0, ht_msiaddr = 0}}, conf = {
      pc_sel = {pc_domain = 0, pc_bus = 128 '\200', pc_dev = 246 '?',
        pc_func = 35 '#'}, pc_hdr = 0 '\0', pc_subvendor = 0,
---Type <return> to continue, or q <return> to quit---
      pc_subdevice = 0, pc_vendor = 0, pc_device = 0, pc_class = 0 '\0',
      pc_subclass = 0 '\0', pc_progif = 0 '\0', pc_revid = 0 '\0',
      pd_name = "\000\000@\016%?pC&?pC&?\026\000", pd_unit = 22}},
  ap_handle = 0x7, ap_flags = 0}
(kgdb)

/Magnus
From william88 at gmail.com  Sat Apr 25 19:07:33 2009
From: william88 at gmail.com (William Grzybowski)
Date: Sat Apr 25 19:07:40 2009
Subject: pci access question
Message-ID: <20090425190801.GA1150@venon.lostgarden>

Hi,

I was reading some code and running some tests in freebsd and some doubts came out.

I know this is not a school but I would like to ask some questions regarding 8086 architecture and pci access, I really appreciate if someone could answer or point me to some good book.

As far as I can understund the pci controllers have some registers which the cpu can read and write stuff.
Everythings starts with the host pci bridge bus, this bus is define as _BBN in the acpi and is 0 when it is not set. 
Then for every pci controller attached to this bus the interrupt routing table is set so this bridge can control them properly. If any of them is a pci controller of the type pci bridge this process is repeated.

This is how I would describe in a very simple way how the process works with my limited knowledge.

My questions would be:

Does ACPI directly inteferes in how pci regs are accesses somehow or a pci_cfgregread is 100% inpendent just with proper locks and asm inb, inl, inw instructions after setting the bus and slot/func?
How does the bridge discovers the pci controllers attached to the bus? Is there some kind of signal or all possible addresses are tested?
Does the pci bridges need to be initialized by the OS (by initialized i mean set some registers in the controller or something)?

Again, sorry for asking this here, probably not the right place, but I would love any kind of "light", specially a good book about it.
From sfourman at gmail.com  Sat Apr 25 23:48:50 2009
From: sfourman at gmail.com (Sam Fourman Jr.)
Date: Sat Apr 25 23:48:56 2009
Subject: Kernel panic on 7.2-RC1 when booting with ACPI enabled kernel.
In-Reply-To: <43b1bb350904250327n2bc0c651y7e725abda56538b0@mail.gmail.com>
References: <43b1bb350904230622u4b7790f0p9f665b649c97a3b@mail.gmail.com>
	<200904240828.17663.jhb@freebsd.org>
	<43b1bb350904250326o63cb3085vc6a7079fba7cd700@mail.gmail.com>
	<43b1bb350904250327n2bc0c651y7e725abda56538b0@mail.gmail.com>
Message-ID: <11167f520904251626y6bdb4cfbs104d79c06f7a06e8@mail.gmail.com>

On Sat, Apr 25, 2009 at 5:27 AM, Magnus Kling <klingfon@gmail.com> wrote:
> 2009/4/24 John Baldwin <jhb@freebsd.org>
>
> On Thursday 23 April 2009 9:22:29 am M K wrote:
>> > Hi!
>> >
>> > I upgraded my fileserver from 7.0 to 7.2-RC1 using the freebsd-update
>> > method. Everything went fine during the upgrade but when I attempted to
>> boot
>> > with the new kernel(GENERIC) the default choice of kernel with ACPI
>> enabled
>> > did not work. I have to boot by choosing the kernel with ACPI disabled.
>> And
>> > then it boots perfect. When I used 7.0 everything worked fine.
>> >


I can confirm this same thing, This morning I bought 3 new Asus
X83VB-X2 notebooks
a RELENG_7 build from 11-24-2008 (aka PC-BSD 7.02 i386) boots just
fine with ACPI enabled
but a 7.2RC2 install cd panics, as well as a recent 8 CURRENT snapshot.

if I disable ACPI everything works fine.

I am willing to provide any feedback that I can, as well as provide
SSH via public ipaddress
all I need is someone to tell me what to do.

my intent was to bring these 3 notebooks to BSDCan in a few weeks.

Sam Fourman Jr.
From jakub_lach at mailplus.pl  Sun Apr 26 20:02:12 2009
From: jakub_lach at mailplus.pl (Jakub Lach)
Date: Sun Apr 26 20:02:22 2009
Subject: EST on PentiumD-T2080
In-Reply-To: <20090419231713.GA1118@venon.lostgarden>
References: <20090419223118.GA1320@venon.lostgarden>
	<20090419231713.GA1118@venon.lostgarden>
Message-ID: <23245990.post@talk.nabble.com>


Hello.

You may be interested in ACPICA patches against CURRENT provided by jkim.

http://people.freebsd.org/~jkim/

(acpica-import)

-best regards, 
Jakub Lach



William Grzybowski wrote:
> 
> Well, forget about it, sorry.
> 
> I realized that the static table is not really necessary, the est.c tries
> to fetch the table list from ACPI.
> 
> I recompiled the module once again and now the freq_list has a lot of
> possible frequencies, a lot more than before.
> 
> Before I send the first e-mail there as only 6 and I could not set any of
> them because was listed as XXXX/-1.
> 
> This problem is possible related to my bug laptop's acpi which has a lot
> of errors about allocating resources.
> 
> By the way, I already sent a couple of e-mails to this list before, ACPI
> is a subject which I really like, maybe there is any kind of task
> (development) that I could accomplish to help the freebsd project and
> increases my knowledge about this?
> 
> That's all, sorry for the annoyance with the previously e-mail.
> 
> William.
> 
> On Sun, Apr 19, 2009 at 07:31:18PM -0300, William Grzybowski wrote:
>> Hi,
>> 
>> I'm running 8-CURRENT from yesterday.
>> 
>> Before the update I was running the snapshot for 2008-02.
>> 
>> In this snapshot the cpufreq with EST seemed t be working fine, but after
>> the update it is not recognizing the processor MSR.
>> 
>> After a little bit of debugging I was able to get my MSR (32 most
>> significant bits) as 0x06190d28 .
>> And this value is not in the ESTprocs list, which would be ID32(1300,
>> 1340, 600, 1100, 100) and does not make any sense for this CPU.
>> 
>> So, the ESTprocs list hasn't changed for a while if I've looked it right
>> which means the rdmsr instruction is returning the wrong data for some
>> reason!?
>> 
>> I am not any kind of the expert in the subject, just curious what could
>> be wrong...
>> 
>> The CPU is:
>> CPU: Genuine Intel(R) CPU           T2080  @ 1.73GHz (1733.41-MHz
>> 686-class CPU)
>>   Origin = "GenuineIntel"  Id = 0x6ec  Stepping = 12
>>  
>> Features=0xbfe9fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
>>   Features2=0xc189<SSE3,MON,EST,TM2,xTPR,PDCM>
>>   AMD Features=0x100000<NX>
>>   TSC: P-state invariant
>>   Cores per package: 2
>> 
>> Any toughts?
>> 
>> Thank you.
> _______________________________________________
> 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"
> 
> 

-- 
View this message in context: http://www.nabble.com/EST-on-PentiumD-T2080-tp23126771p23245990.html
Sent from the freebsd-acpi mailing list archive at Nabble.com.

From yanefbsd at gmail.com  Mon Apr 27 03:00:32 2009
From: yanefbsd at gmail.com (Garrett Cooper)
Date: Mon Apr 27 03:00:39 2009
Subject: ACPI-fast default timecounter, but HPET 83% faster
In-Reply-To: <200904270150.31912.pieter@degoeje.nl>
References: <200904270150.31912.pieter@degoeje.nl>
Message-ID: <7d6fde3d0904261927s1a67cf85jc982c1a68e30e081@mail.gmail.com>

On Sun, Apr 26, 2009 at 4:50 PM, Pieter de Goeje <pieter@degoeje.nl> wrote:
> Dear hackers,
>
> While fiddling with the sysctl kern.timecounter.hardware, I found out that on
> my system HPET is significantly faster than ACPI-fast. Using the program
> below I measured the number of clock_gettime() calls the system can execute
> per second. I ran the program 10 times for each configuration and here are
> the results:
>
> x ACPI-fast
> + HPET
> +-------------------------------------------------------------------------+
> |x ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? +|
> |x ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? +|
> |x ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?++|
> |x ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?++|
> |x ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?++|
> |x ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?++|
> |A ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|A|
> +-------------------------------------------------------------------------+
> ? ?N ? ? ? ? ? Min ? ? ? ? ? Max ? ? ? ?Median ? ? ? ? ? Avg ? ? ? ?Stddev
> x ?10 ? ? ? ?822032 ? ? ? ?823752 ? ? ? ?823551 ? ? ?823397.8 ? ? 509.43254
> + ?10 ? ? ? 1498348 ? ? ? 1506862 ? ? ? 1502830 ? ? 1503267.4 ? ? 2842.9779
> Difference at 95.0% confidence
> ? ? ? ?679870 +/- 1918.94
> ? ? ? ?82.5688% +/- 0.233052%
> ? ? ? ?(Student's t, pooled s = 2042.31)
>
> System details: Intel(R) Core(TM)2 Duo CPU E6750 ?@ 2.66GHz (3200.02-MHz
> 686-class CPU), Gigabyte P35-DS3R motherboard running i386 -CURRENT updated
> today.
>
> Unfortunately I only have one system with a HPET timecounter, so I cannot
> verify these results on another system. If similar results are obtained on
> other machines, I think the HPET timecounter quality needs to be increased
> beyond that of ACPI-fast.
>
> Regards,
>
> Pieter de Goeje
>
> ----- 8< ----- clock_gettime.c ----- 8< ------
> #include <sys/time.h>
> #include <stdio.h>
> #include <time.h>
>
> #define COUNT 1000000
>
> int main() {
> ? ? ? ?struct timespec ts_start, ts_stop, ts_read;
> ? ? ? ?double time;
> ? ? ? ?int i;
>
> ? ? ? ?clock_gettime(CLOCK_MONOTONIC, &ts_start);
> ? ? ? ?for(i = 0; i < COUNT; i++) {
> ? ? ? ? ? ? ? ?clock_gettime(CLOCK_MONOTONIC, &ts_read);
> ? ? ? ?}
> ? ? ? ?clock_gettime(CLOCK_MONOTONIC, &ts_stop);
>
> ? ? ? ?time = (ts_stop.tv_sec - ts_start.tv_sec) + (ts_stop.tv_nsec -
> ts_start.tv_nsec) * 1E-9;
> ? ? ? ?printf("%.0f\n", COUNT / time);
> }

I'm seeing similar results.

[root@orangebox /usr/home/gcooper]# dmesg | grep 'Timecounter "'
Timecounter "i8254" frequency 1193182 Hz quality 0
Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
Timecounter "HPET" frequency 14318180 Hz quality 900
[root@orangebox /usr/home/gcooper]# ./cgt
1369355
[root@orangebox /usr/home/gcooper]# sysctl
kern.timecounter.hardware="ACPI-fast"
kern.timecounter.hardware: HPET -> ACPI-fast
[root@orangebox /usr/home/gcooper]# ./cgt
772289

Why's the default ACPI-fast? For power-saving functionality or because
of the `quality' factor? What is the criteria that determines the
`quality' of a clock as what's being reported above (I know what
determines the quality of a clock visually from a oscilloscope =])?

Thanks,
-Garrett
From bugmaster at FreeBSD.org  Mon Apr 27 11:06:49 2009
From: bugmaster at FreeBSD.org (FreeBSD bugmaster)
Date: Mon Apr 27 11:07:10 2009
Subject: Current problem reports assigned to freebsd-acpi@FreeBSD.org
Message-ID: <200904271106.n3RB6mOo002178@freefall.freebsd.org>

Note: to view an individual PR, use:
  http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.


S Tracker      Resp.      Description
--------------------------------------------------------------------------------
o kern/132602  acpi       [acpi] ACPI Problem with Intel SS4200: System does not
o kern/130683  acpi       [ACPI] shutdown hangs after syncing disks - ACPI race?
o i386/129953  acpi       [acpi] ACPI timeout (CDROM) with Shuttle X27D
o kern/129618  acpi       [acpi] Problem with ACPI on HP Pavilion DV2899 laptop
o kern/129563  acpi       [acpi] sleep broken on IBM/Lenovo T61 in amd64 mode
o kern/128639  acpi       [patch] [acpi_asus] acpi for ASUS A6F,A3E,A3F,A3N not 
f kern/128634  acpi       [patch] fix acpi_asus(4) in asus a6f laptop
o kern/127581  acpi       [patch] [acpi_sony] Add support for more Sony features
o kern/124744  acpi       [acpi] [patch] incorrect _BST result validation for To
o kern/124412  acpi       [acpi] power off error on Toshiba M40 laptop
o kern/123039  acpi       [acpi] ACPI AML_BUFFER_LIMIT errors during boot
o kern/121504  acpi       [patch] Correctly set hw.acpi.osname on certain machin
f kern/121454  acpi       [pst] Promise SuperTrak SX6000 does not load during bo
o kern/121102  acpi       [acpi_fujitsu] [patch] update acpi_fujitsu for the P80
o kern/120515  acpi       [acpi] [patch] acpi_alloc_wakeup_handler: can't alloc 
o kern/119356  acpi       [acpi]: i386 ACPI wakeup not work due resource exhaust
o kern/119200  acpi       [acpi] Lid close switch suspends CPU for 1 second on H
o kern/118973  acpi       [acpi]: Kernel panic with acpi boot
o kern/117605  acpi       [acpi] [request] add debug.cpufreq.highest
o kern/116939  acpi       [acpi] PCI-to-PCI misconfigured for bus three and can 
o i386/114562  acpi       [acpi] cardbus is dead after s3 on Thinkpad T43 with a
o kern/114165  acpi       [acpi] Dell C810 - ACPI problem
s kern/112544  acpi       [acpi] [patch] Add High Precision Event Timer Driver f
o kern/108954  acpi       [acpi] 'sleep(1)' sleeps >1 seconds when speedstep (Cx
o kern/108695  acpi       [acpi]: Fatal trap 9: general protection fault when in
o kern/108488  acpi       [acpi] ACPI-1304: *** Error: Method execution failed
o kern/108017  acpi       [acpi]: Acer Aspire 5600
o kern/106924  acpi       [acpi] ACPI resume returns g_vfs_done() errors and ker
o kern/105537  acpi       [acpi] problems in acpi on HP Compaq nc6320
o kern/104625  acpi       ACPI on ASUS A8N-32 SLI/ASUS P4P800 does not show ther
o kern/102252  acpi       acpi thermal does not work on Abit AW8D (intel 975)
o kern/97383   acpi       Volume buttons on IBM Thinkpad crash system with ACPI
s i386/91748   acpi       acpi problem on Acer TravelMare 4652LMi (nvidia panic,
s kern/91038   acpi       [panic] [ata] [acpi] 6.0-RELEASE on Fujitsu Siemens Am
s kern/90243   acpi       Laptop fan doesn't turn off (ACPI enabled) (Packard Be
f kern/89411   acpi       [acpi] acpiconf bug
o i386/83018   acpi       [install] Installer will not boot on Asus P4S8X BIOS 1
o kern/81000   acpi       [apic] Via 8235 sound card worked great with FreeBSD 5
o i386/79081   acpi       ACPI suspend/resume not working on HP nx6110
o kern/76950   acpi       ACPI wrongly blacklisted on Micron ClientPro 766Xi sys
s kern/73823   acpi       [request] acpi / power-on by timer support
o i386/72566   acpi       ACPI, FreeBSD disables fan on Compaq Armada 1750
o i386/69750   acpi       Boot without ACPI failed on ASUS L5
o kern/56024   acpi       ACPI suspend drains battery while in S3
o i386/55661   acpi       ACPI suspend/resume problem on ARMADA M700
o i386/54756   acpi       ACPI suspend/resume problem on CF-W2 laptop

46 problems total.

From avg at freebsd.org  Mon Apr 27 12:54:13 2009
From: avg at freebsd.org (Andriy Gapon)
Date: Mon Apr 27 12:54:19 2009
Subject: run resume code only for S1-S4 states
In-Reply-To: <20090425102109.0520ce59@fabiankeil.de>
References: <49DB639A.4090504@icyb.net.ua>	<49DCF5C2.60805@root.org>	<49DDF906.8090400@icyb.net.ua>	<49DF3CA4.1090309@freebsd.org>	<49E4B2A7.3020302@freebsd.org>	<49E61986.7040709@root.org>	<49E8AED0.1090008@freebsd.org>	<20090418125806.2a48b0a8@fabiankeil.de>	<49E9FFB0.6090707@root.org>	<49EC60C6.7000702@freebsd.org>	<49EC9D2F.8080701@root.org>	<49EDFBBA.1080504@freebsd.org>	<20090422183214.1e3372c6@fabiankeil.de>	<49F09A23.9080802@freebsd.org>
	<20090425102109.0520ce59@fabiankeil.de>
Message-ID: <49F5AAF0.9080607@freebsd.org>

on 25/04/2009 11:21 Fabian Keil said the following:
> Sure. It turns out that the problem is unrelated to your patch.
> I can reproduce it with an unpatched kernel too, by once pressing
> the power button before the second core is started.
> 
> I probably did the same a few days ago, and forgot about it. Sorry.

Fabian,

thank you very much for the testing and the insight, this is very useful and
interesting.
I think that it might be that 'init' process in pre-natal state loses a signal
sent to it.

I decided to follow Nate's advice and exempt S5 from timeout policy (after all it
is possible to execute shutdown(8) multiple times and concurrently with any other
sleep request). With previous version of the patch once shutdown_nice() failed
once it was impossible to enter any sleep state ever. shutdown_nice failure is
quite exotic event, but as you have proven it is not impossible.

So the new patch is attached.


-- 
Andriy Gapon
-------------- next part --------------
diff --git a/sys/dev/acpica/acpi.c b/sys/dev/acpica/acpi.c
index 50b84a5..d8626b4 100644
--- a/sys/dev/acpica/acpi.c
+++ b/sys/dev/acpica/acpi.c
@@ -2482,6 +2482,18 @@ acpi_EnterSleepState(struct acpi_softc *sc, int state)
 
     ACPI_FUNCTION_TRACE_U32((char *)(uintptr_t)__func__, state);
 
+    if (state < ACPI_STATE_S1 || state > ACPI_STATE_S5)
+	return_ACPI_STATUS (AE_BAD_PARAMETER);
+
+    if (state == ACPI_STATE_S5) {
+	/*
+	 * Shut down cleanly and power off.  This will call us back through the
+	 * shutdown handlers.
+	 */
+	shutdown_nice(RB_POWEROFF);
+	return_ACPI_STATUS (AE_OK);
+    }
+
     /* Re-entry once we're suspending is not allowed. */
     status = acpi_sleep_disable(sc);
     if (ACPI_FAILURE(status)) {
@@ -2502,92 +2514,74 @@ acpi_EnterSleepState(struct acpi_softc *sc, int state)
     mtx_lock(&Giant);
 
     slp_state = ACPI_SS_NONE;
-    switch (state) {
-    case ACPI_STATE_S1:
-    case ACPI_STATE_S2:
-    case ACPI_STATE_S3:
-    case ACPI_STATE_S4:
-	status = AcpiGetSleepTypeData(state, &TypeA, &TypeB);
-	if (status == AE_NOT_FOUND) {
-	    device_printf(sc->acpi_dev,
-			  "Sleep state S%d not supported by BIOS\n", state);
-	    break;
-	} else if (ACPI_FAILURE(status)) {
-	    device_printf(sc->acpi_dev, "AcpiGetSleepTypeData failed - %s\n",
-			  AcpiFormatException(status));
-	    break;
-	}
+    status = AcpiGetSleepTypeData(state, &TypeA, &TypeB);
+    if (status == AE_NOT_FOUND) {
+	device_printf(sc->acpi_dev,
+		      "Sleep state S%d not supported by BIOS\n", state);
+	goto backout;
+    } else if (ACPI_FAILURE(status)) {
+	device_printf(sc->acpi_dev, "AcpiGetSleepTypeData failed - %s\n",
+		      AcpiFormatException(status));
+	goto backout;
+    }
 
-	sc->acpi_sstate = state;
+    sc->acpi_sstate = state;
 
-	/* Enable any GPEs as appropriate and requested by the user. */
-	acpi_wake_prep_walk(state);
-	slp_state = ACPI_SS_GPE_SET;
+    /* Enable any GPEs as appropriate and requested by the user. */
+    acpi_wake_prep_walk(state);
+    slp_state = ACPI_SS_GPE_SET;
 
-	/*
-	 * Inform all devices that we are going to sleep.  If at least one
-	 * device fails, DEVICE_SUSPEND() automatically resumes the tree.
-	 *
-	 * XXX Note that a better two-pass approach with a 'veto' pass
-	 * followed by a "real thing" pass would be better, but the current
-	 * bus interface does not provide for this.
-	 */
-	if (DEVICE_SUSPEND(root_bus) != 0) {
-	    device_printf(sc->acpi_dev, "device_suspend failed\n");
-	    break;
-	}
-	slp_state = ACPI_SS_DEV_SUSPEND;
+    /*
+     * Inform all devices that we are going to sleep.  If at least one
+     * device fails, DEVICE_SUSPEND() automatically resumes the tree.
+     *
+     * XXX Note that a better two-pass approach with a 'veto' pass
+     * followed by a "real thing" pass would be better, but the current
+     * bus interface does not provide for this.
+     */
+    if (DEVICE_SUSPEND(root_bus) != 0) {
+	device_printf(sc->acpi_dev, "device_suspend failed\n");
+	goto backout;
+    }
+    slp_state = ACPI_SS_DEV_SUSPEND;
 
-	/* If testing device suspend only, back out of everything here. */
-	if (acpi_susp_bounce)
-	    break;
+    /* If testing device suspend only, back out of everything here. */
+    if (acpi_susp_bounce)
+	goto backout;
 
-	status = AcpiEnterSleepStatePrep(state);
-	if (ACPI_FAILURE(status)) {
-	    device_printf(sc->acpi_dev, "AcpiEnterSleepStatePrep failed - %s\n",
-			  AcpiFormatException(status));
-	    break;
-	}
-	slp_state = ACPI_SS_SLP_PREP;
+    status = AcpiEnterSleepStatePrep(state);
+    if (ACPI_FAILURE(status)) {
+	device_printf(sc->acpi_dev, "AcpiEnterSleepStatePrep failed - %s\n",
+		      AcpiFormatException(status));
+	goto backout;
+    }
+    slp_state = ACPI_SS_SLP_PREP;
 
-	if (sc->acpi_sleep_delay > 0)
-	    DELAY(sc->acpi_sleep_delay * 1000000);
+    if (sc->acpi_sleep_delay > 0)
+	DELAY(sc->acpi_sleep_delay * 1000000);
 
-	if (state != ACPI_STATE_S1) {
-	    acpi_sleep_machdep(sc, state);
+    if (state != ACPI_STATE_S1) {
+	acpi_sleep_machdep(sc, state);
 
-	    /* Re-enable ACPI hardware on wakeup from sleep state 4. */
-	    if (state == ACPI_STATE_S4)
-		AcpiEnable();
-	} else {
-	    ACPI_DISABLE_IRQS();
-	    status = AcpiEnterSleepState(state);
-	    if (ACPI_FAILURE(status)) {
-		device_printf(sc->acpi_dev, "AcpiEnterSleepState failed - %s\n",
-			      AcpiFormatException(status));
-		break;
-	    }
+	/* Re-enable ACPI hardware on wakeup from sleep state 4. */
+	if (state == ACPI_STATE_S4)
+	    AcpiEnable();
+    } else {
+	ACPI_DISABLE_IRQS();
+	status = AcpiEnterSleepState(state);
+	if (ACPI_FAILURE(status)) {
+	    device_printf(sc->acpi_dev, "AcpiEnterSleepState failed - %s\n",
+			  AcpiFormatException(status));
+	    goto backout;
 	}
-	slp_state = ACPI_SS_SLEPT;
-	break;
-    case ACPI_STATE_S5:
-	/*
-	 * Shut down cleanly and power off.  This will call us back through the
-	 * shutdown handlers.
-	 */
-	shutdown_nice(RB_POWEROFF);
-	status = AE_OK;
-	break;
-    case ACPI_STATE_S0:
-    default:
-	status = AE_BAD_PARAMETER;
-	break;
     }
+    slp_state = ACPI_SS_SLEPT;
 
     /*
      * Back out state according to how far along we got in the suspend
      * process.  This handles both the error and success cases.
      */
+backout:
     sc->acpi_next_sstate = 0;
     if (slp_state >= ACPI_SS_GPE_SET) {
 	acpi_wake_prep_walk(state);
@@ -2609,8 +2603,7 @@ acpi_EnterSleepState(struct acpi_softc *sc, int state)
 #endif
 
     /* Allow another sleep request after a while. */
-    if (state != ACPI_STATE_S5)
-	timeout(acpi_sleep_enable, sc, hz * ACPI_MINIMUM_AWAKETIME);
+    timeout(acpi_sleep_enable, sc, hz * ACPI_MINIMUM_AWAKETIME);
 
     /* Run /etc/rc.resume after we are back. */
     if (devctl_process_running())
From freebsd-listen at fabiankeil.de  Mon Apr 27 19:20:25 2009
From: freebsd-listen at fabiankeil.de (Fabian Keil)
Date: Mon Apr 27 19:20:32 2009
Subject: run resume code only for S1-S4 states
In-Reply-To: <49F5AAF0.9080607@freebsd.org>
References: <49DB639A.4090504@icyb.net.ua> <49DCF5C2.60805@root.org>
	<49DDF906.8090400@icyb.net.ua> <49DF3CA4.1090309@freebsd.org>
	<49E4B2A7.3020302@freebsd.org> <49E61986.7040709@root.org>
	<49E8AED0.1090008@freebsd.org>
	<20090418125806.2a48b0a8@fabiankeil.de> <49E9FFB0.6090707@root.org>
	<49EC60C6.7000702@freebsd.org> <49EC9D2F.8080701@root.org>
	<49EDFBBA.1080504@freebsd.org>
	<20090422183214.1e3372c6@fabiankeil.de>
	<49F09A23.9080802@freebsd.org>
	<20090425102109.0520ce59@fabiankeil.de>
	<49F5AAF0.9080607@freebsd.org>
Message-ID: <20090427212016.43dd83d6@fabiankeil.de>

Andriy Gapon <avg@freebsd.org> wrote:

> on 25/04/2009 11:21 Fabian Keil said the following:
> > Sure. It turns out that the problem is unrelated to your patch.
> > I can reproduce it with an unpatched kernel too, by once pressing
> > the power button before the second core is started.
> > 
> > I probably did the same a few days ago, and forgot about it. Sorry.

> thank you very much for the testing and the insight, this is very useful and
> interesting.
> I think that it might be that 'init' process in pre-natal state loses a signal
> sent to it.
> 
> I decided to follow Nate's advice and exempt S5 from timeout policy (after all it
> is possible to execute shutdown(8) multiple times and concurrently with any other
> sleep request). With previous version of the patch once shutdown_nice() failed
> once it was impossible to enter any sleep state ever. shutdown_nice failure is
> quite exotic event, but as you have proven it is not impossible.
> 
> So the new patch is attached.

Thanks. The patch works and pressing the power button early on
boot before it actually has any effect no longer prevents the
power button from working later on.

Fabian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-acpi/attachments/20090427/0dcdc5cf/signature.pgp
From jakub_lach at mailplus.pl  Mon Apr 27 20:19:29 2009
From: jakub_lach at mailplus.pl (Jakub Lach)
Date: Mon Apr 27 20:19:35 2009
Subject: lenovo s10e minor errors
In-Reply-To: <539c60b90904242313g20a3e6e4q20e555b318798764@mail.gmail.com>
References: <539c60b90904242313g20a3e6e4q20e555b318798764@mail.gmail.com>
Message-ID: <23264191.post@talk.nabble.com>


Hello.

If you are running CURRENT, you may like to try
fresh acapica-import patches.

http://people.freebsd.org/~jkim/

-best regards, 
Jakub Lach




Steve Franks-4 wrote:
> 
> Hi,
> 
> These in no way seem to affect my system (although it won't resume, I
> suspect that's seperate), but I thought someone would want a look at
> it, since these netbooks are pretty new.
> 
> Incidentally, if anyone picks one up, there's no bios-block against
> replacing the broadcom 80211 with a ath (i.e. sparklan).
> 
> Best,
> Steve
> 
> [steve@terra /usr/home/steve/projects/include]$ dmesg
> ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler
> [20070320]
> ACPI Error (psparse-0626): Method parse/execution failed
> [\\_TZ_.TZ00._TMP] (Node 0xc41b7220), AE_NOT_EXIST
> ACPI Error (evregion-0427): No handler for Region [ERAM] (0xc41b8c80)
> [EmbeddedControl] [20070320]
> ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler
> [20070320]
> ACPI Error (psparse-0626): Method parse/execution failed
> [\\_TZ_.TZ00._TMP] (Node 0xc41b7220), AE_NOT_EXIST
> ACPI Error (evregion-0427): No handler for Region [ERAM] (0xc41b8c80)
> [EmbeddedControl] [20070320]
> ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler
> [20070320]
> ACPI Error (psparse-0626): Method parse/execution failed [\\_GPE._L02]
> (Node 0xc41b74a0), AE_NOT_EXIST
> ACPI Exception (evgpe-0687): AE_NOT_EXIST, while evaluating GPE method
> [_L02] [20070320]
> ACPI Error (evregion-0427): No handler for Region [ERAM] (0xc41b8c80)
> [EmbeddedControl] [20070320]
> ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler
> [20070320]
> 
> etc...as you can see, they overrun the dmesg buffer after a few minutes...
> _______________________________________________
> 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"
> 
> 

-- 
View this message in context: http://www.nabble.com/lenovo-s10e-minor-errors-tp23229166p23264191.html
Sent from the freebsd-acpi mailing list archive at Nabble.com.

From bahamasfranks at gmail.com  Mon Apr 27 20:57:26 2009
From: bahamasfranks at gmail.com (Steve Franks)
Date: Mon Apr 27 20:57:31 2009
Subject: lenovo s10e minor errors
In-Reply-To: <23264191.post@talk.nabble.com>
References: <539c60b90904242313g20a3e6e4q20e555b318798764@mail.gmail.com>
	<23264191.post@talk.nabble.com>
Message-ID: <539c60b90904271357q2a1256d9qba46bdd8e63da2a7@mail.gmail.com>

On Mon, Apr 27, 2009 at 1:19 PM, Jakub Lach <jakub_lach@mailplus.pl> wrote:
>
> Hello.
>
> If you are running CURRENT, you may like to try
> fresh acapica-import patches.
>

Thanks, I'm on STABLE - just pushing it up the chain, since it really
doesn't affect me (other than barfing all over dmesg).

Now if I could figure out why the box won't power off on shutdown, or
resume past a blinking cursor, that would be worth a move to
CURRENT...

Steve
From smithi at nimnet.asn.au  Tue Apr 28 03:39:04 2009
From: smithi at nimnet.asn.au (Ian Smith)
Date: Tue Apr 28 03:39:10 2009
Subject: lenovo s10e minor errors
In-Reply-To: <539c60b90904271357q2a1256d9qba46bdd8e63da2a7@mail.gmail.com>
References: <539c60b90904242313g20a3e6e4q20e555b318798764@mail.gmail.com>
	<23264191.post@talk.nabble.com>
	<539c60b90904271357q2a1256d9qba46bdd8e63da2a7@mail.gmail.com>
Message-ID: <20090428132508.R89549@sola.nimnet.asn.au>

On Mon, 27 Apr 2009, Steve Franks wrote:
 > On Mon, Apr 27, 2009 at 1:19 PM, Jakub Lach <jakub_lach@mailplus.pl> wrote:
 > >
 > > Hello.
 > >
 > > If you are running CURRENT, you may like to try
 > > fresh acapica-import patches.
 > >
 > 
 > Thanks, I'm on STABLE - just pushing it up the chain, since it really
 > doesn't affect me (other than barfing all over dmesg).
 > 
 > Now if I could figure out why the box won't power off on shutdown, or
 > resume past a blinking cursor, that would be worth a move to
 > CURRENT...

Some older thinkpads (eg my T23) resume properly (or better, or at all) 
with sysctl hw.syscons.sc_no_suspend_vtswitch=1

Some others have reported benefit from hw.acpi.reset_video=1

Just curious: does loading acpi_ibm work with this lenovo?

cheers, Ian
From patttern at gmail.com  Wed Apr 29 23:52:29 2009
From: patttern at gmail.com (=?ISO-8859-1?Q?Pattern=AE?=)
Date: Wed Apr 29 23:52:35 2009
Subject: ACPI on Toshiba A210
Message-ID: <107cc88f0904291627ra8517e6j661ae329446852a1@mail.gmail.com>

Hi! I have a problem with ACPI on notebook Toshiba Sattelite A210-16f.
At loading FreeBSD by default, the system does not detect hard disks.
Through acpidump i have received a dsl-file. (dsdt_SB600.dsl)
After considerable editing of a file, i have received a file without errors.
(dsdt_SB600.diff)
Result of operation iasl.

[2:36 pattern@toshiba /root/acpica]# iasl dsdt_SB600_edit.dsl
Intel ACPI Component Architecture
ASL Optimizing Compiler version 20070320 [Mar 31 2009]
Copyright (C) 2000 - 2007 Intel Corporation
Supports ACPI Specification Revision 3.0a
ASL Input:  dsdt_SB600_edit.dsl - 7596 lines, 283835 bytes, 3271 keywords
AML Output: /root/acpica/dsdt_SB600_edit.aml - 29374 bytes 873 named objects
2398 executable opcodes
Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 9 Optimizations

I have placed the aml-file received as a result of operation in /boot and
have registered it in loader.conf.

[2:36 pattern@toshiba /root/acpica]# less /boot/loader.conf
acpi_dsdt_load="YES"
acpi_dsdt_name="/boot/dsdt_SB600_edit.aml"

After system reboot, hard disks as have not found out. In the console
following errors are output.

acpi0: <TOSCPL TOSCPL00> om motherboard
ACPI Error (evregion-0427): No handler for Region [ERAM] (0xc69cde80)
[EmbeddedControl] [20070320]
ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler
[20070320]
ACPI Error (psparse-0626): Method parse/execution failed [\_SB_.HTEV] (Node
0xc6897b60), AE_NOT_EXIST
ACPI Error (psparse-0626): Method parse/execution failed
[\_SB_.PCI0.LPC0.EC0_._REG] (Node 0xc69d6260), AE_NOT_EXIST
acpi0: Could not initialise SystemIO handler: AE_NOT_EXIST
...
unknown: <PNP0c02> can't assign resources (memory)
unknown: <PNP0c01> can't assign resources (memory)
unknown: <PNP0100> can't assign resources (irq)
unknown: <PNP0303> can't assign resources (port)
unknown: <PNP0c02> can't assign resources (memory)
unknown: <PNP0c02> can't assign resources (memory)
unknown: <PNP0c02> can't assign resources (memory)
unknown: <PNP0f13> can't assign resources (irq)
That the system has successfully booted it is required to apply the
following file. (dsdt_SB600_addon.diff)
(dsdt_SB600.dsl -> dsdt_SB600.diff -> dsdt_SB600_edit.dsl
dsdt_SB600_edit.dsl -> dsdt_SB600_addon.diff -> dsdt_SB600_addon.dsl)
Why it occurs and how it to fix?
From patttern at gmail.com  Thu Apr 30 00:38:33 2009
From: patttern at gmail.com (=?ISO-8859-1?Q?Pattern=AE?=)
Date: Thu Apr 30 00:38:39 2009
Subject: ACPI on Toshiba A210
Message-ID: <107cc88f0904291738g2708915dx7b797aac7a802547@mail.gmail.com>

Sorry, i have forgotten to add files.

http://pma.8855.ru/files/dsdt_SB600.dsl
http://pma.8855.ru/files/dsdt_SB600.diff
http://pma.8855.ru/files/dsdt_SB600_addon.diff
From jkim at FreeBSD.org  Thu Apr 30 18:23:12 2009
From: jkim at FreeBSD.org (Jung-uk Kim)
Date: Thu Apr 30 18:23:18 2009
Subject: run resume code only for S1-S4 states
In-Reply-To: <20090427212016.43dd83d6@fabiankeil.de>
References: <49DB639A.4090504@icyb.net.ua> <49F5AAF0.9080607@freebsd.org>
	<20090427212016.43dd83d6@fabiankeil.de>
Message-ID: <200904301423.03761.jkim@FreeBSD.org>

On Monday 27 April 2009 03:20 pm, Fabian Keil wrote:
> Andriy Gapon <avg@freebsd.org> wrote:
> > on 25/04/2009 11:21 Fabian Keil said the following:
> > > Sure. It turns out that the problem is unrelated to your patch.
> > > I can reproduce it with an unpatched kernel too, by once
> > > pressing the power button before the second core is started.
> > >
> > > I probably did the same a few days ago, and forgot about it.
> > > Sorry.
> >
> > thank you very much for the testing and the insight, this is very
> > useful and interesting.
> > I think that it might be that 'init' process in pre-natal state
> > loses a signal sent to it.
> >
> > I decided to follow Nate's advice and exempt S5 from timeout
> > policy (after all it is possible to execute shutdown(8) multiple
> > times and concurrently with any other sleep request). With
> > previous version of the patch once shutdown_nice() failed once it
> > was impossible to enter any sleep state ever. shutdown_nice
> > failure is quite exotic event, but as you have proven it is not
> > impossible.
> >
> > So the new patch is attached.
>
> Thanks. The patch works and pressing the power button early on
> boot before it actually has any effect no longer prevents the
> power button from working later on.

Can you try r191699 acpi.c and tell me if there is any regression?

Thanks!

Jung-uk Kim
From jhb at freebsd.org  Thu Apr 30 21:41:22 2009
From: jhb at freebsd.org (John Baldwin)
Date: Thu Apr 30 21:41:33 2009
Subject: Fwd: Kernel panic on 7.2-RC1 when booting with ACPI enabled
	kernel.
In-Reply-To: <43b1bb350904250327n2bc0c651y7e725abda56538b0@mail.gmail.com>
References: <43b1bb350904230622u4b7790f0p9f665b649c97a3b@mail.gmail.com>
	<43b1bb350904250326o63cb3085vc6a7079fba7cd700@mail.gmail.com>
	<43b1bb350904250327n2bc0c651y7e725abda56538b0@mail.gmail.com>
Message-ID: <200904300836.34238.jhb@freebsd.org>

On Saturday 25 April 2009 6:27:23 am Magnus Kling wrote:
> 2009/4/24 John Baldwin <jhb@freebsd.org>
> > Can you do 'frame 10' followed by 'p *(struct acpi_pci_devinfo
> > *)child->ivars'
> >
> > --
> > John Baldwin
> 
> 
> Sure, no problem. This is a none critical server so I can do alot of
> debugging and testing if that is needed.
> 
> 
> (kgdb) frame 10
> #10 0xc0db4ca8 in acpi_pci_child_location_str_method (cbdev=0xc2212680,
>     child=0xc2243400, buf=0xc22c2400 "slot=0 function=0 handle=",
> buflen=1024)
>     at /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/acpi_pci.c:150
> 150             strlcat(buf, acpi_name(dinfo->ap_handle), buflen);
> 
> (kgdb)  p *(struct acpi_pci_devinfo *)child->ivars
> $1 = {ap_dinfo = {pci_links = {stqe_next = 0xc0b00f8c}, resources = {
>       stqh_first = 0xc0b00f8c, stqh_last = 0x1030000}, cfg = {dev = 0x0,
>       bar = {4, 0, 0, 3257136600, 0, 0}, bios = 0, subvendor = 0,
>       subdevice = 0, vendor = 0, device = 0, cmdreg = 0, statreg = 0,
>       baseclass = 0 '\0', subclass = 0 '\0', progif = 0 '\0', revid = 0

Hmm, this is all completely wrong and trashed.  What if you do 'p *child'?

-- 
John Baldwin
From jhb at freebsd.org  Thu Apr 30 21:41:23 2009
From: jhb at freebsd.org (John Baldwin)
Date: Thu Apr 30 21:41:34 2009
Subject: pci access question
In-Reply-To: <20090425190801.GA1150@venon.lostgarden>
References: <20090425190801.GA1150@venon.lostgarden>
Message-ID: <200904300844.24710.jhb@freebsd.org>

On Saturday 25 April 2009 3:08:01 pm William Grzybowski wrote:
> Hi,
> 
> I was reading some code and running some tests in freebsd and some doubts 
came out.
> 
> I know this is not a school but I would like to ask some questions regarding 
8086 architecture and pci access, I really appreciate if someone could answer 
or point me to some good book.
> 
> As far as I can understund the pci controllers have some registers which the 
cpu can read and write stuff.
> Everythings starts with the host pci bridge bus, this bus is define as _BBN 
in the acpi and is 0 when it is not set. 
> Then for every pci controller attached to this bus the interrupt routing 
table is set so this bridge can control them properly. If any of them is a 
pci controller of the type pci bridge this process is repeated.
> 
> This is how I would describe in a very simple way how the process works with 
my limited knowledge.
> 
> My questions would be:
> 
> Does ACPI directly inteferes in how pci regs are accesses somehow or a 
pci_cfgregread is 100% inpendent just with proper locks and asm inb, inl, inw 
instructions after setting the bus and slot/func?

ACPI does not interfere with PCI config access.  It is all done by using I/O 
port access to 0xcf8 and 0xcfc.  Newer PCI express systems do support an 
alternative method of PCI config access using a memory-mapped I/O window.  
(That is what pcie_cfgreg* implement.)  ACPI does provide a table ('MCFG') 
that describes the available memory windows, but the BIOS does not provide 
any public AML methods to manage PCI config access.

> How does the bridge discovers the pci controllers attached to the bus? Is 
there some kind of signal or all possible addresses are tested?

When scanning a PCI bus, all possible addresses are tested.  Look at 
pci_add_children() in sys/dev/pci/pci.c.  When a PCI-PCI bridge driver 
attaches to a PCI-PCI bridge it scans its child bus during its attach 
routine.  This is all using methods defined in the PCI standard which are 
true for all PCI implementations.  One thing PCI does not define is how to 
enumerate the list of Host-PCI bridges.  ACPI provides this by giving each 
top-level PCI bus a separate device node with a _BBN method in the ACPI 
namespace.  Other architectures and firmwares provide this info via different 
methods.

> Does the pci bridges need to be initialized by the OS (by initialized i mean 
set some registers in the controller or something)?

Well, the firmware often does some of the setup, but it is not required to.  
There are all sorts of setup an OS may need to do.  It may need to assign bus 
numbers to PCI-PCI bridges.  It may need to assign resources to BARs on 
devices and to I/O windows on PCI-PCI bridges to provide resources to BARs on 
devices behind the bridges.

> Again, sorry for asking this here, probably not the right place, but I would 
love any kind of "light", specially a good book about it.

For PCI stuff, the Mindshare 'PCI System Architecture' book is what I use.

-- 
John Baldwin
From jhb at freebsd.org  Thu Apr 30 21:41:24 2009
From: jhb at freebsd.org (John Baldwin)
Date: Thu Apr 30 21:41:55 2009
Subject: ACPI-fast default timecounter, but HPET 83% faster
In-Reply-To: <7d6fde3d0904261927s1a67cf85jc982c1a68e30e081@mail.gmail.com>
References: <200904270150.31912.pieter@degoeje.nl>
	<7d6fde3d0904261927s1a67cf85jc982c1a68e30e081@mail.gmail.com>
Message-ID: <200904300846.41576.jhb@freebsd.org>

On Sunday 26 April 2009 10:27:42 pm Garrett Cooper wrote:
> I'm seeing similar results.
> 
> [root@orangebox /usr/home/gcooper]# dmesg | grep 'Timecounter "'
> Timecounter "i8254" frequency 1193182 Hz quality 0
> Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
> Timecounter "HPET" frequency 14318180 Hz quality 900
> [root@orangebox /usr/home/gcooper]# ./cgt
> 1369355
> [root@orangebox /usr/home/gcooper]# sysctl
> kern.timecounter.hardware="ACPI-fast"
> kern.timecounter.hardware: HPET -> ACPI-fast
> [root@orangebox /usr/home/gcooper]# ./cgt
> 772289
> 
> Why's the default ACPI-fast? For power-saving functionality or because
> of the `quality' factor? What is the criteria that determines the
> `quality' of a clock as what's being reported above (I know what
> determines the quality of a clock visually from a oscilloscope =])?

I suspect that the quality of the HPET driver is lower simply because no one
had measured it previously and HPET is newer and less "proven".

-- 
John Baldwin
From jhb at freebsd.org  Thu Apr 30 21:41:24 2009
From: jhb at freebsd.org (John Baldwin)
Date: Thu Apr 30 21:41:55 2009
Subject: ACPI-fast default timecounter, but HPET 83% faster
In-Reply-To: <7d6fde3d0904261927s1a67cf85jc982c1a68e30e081@mail.gmail.com>
References: <200904270150.31912.pieter@degoeje.nl>
	<7d6fde3d0904261927s1a67cf85jc982c1a68e30e081@mail.gmail.com>
Message-ID: <200904300846.41576.jhb@freebsd.org>

On Sunday 26 April 2009 10:27:42 pm Garrett Cooper wrote:
> I'm seeing similar results.
> 
> [root@orangebox /usr/home/gcooper]# dmesg | grep 'Timecounter "'
> Timecounter "i8254" frequency 1193182 Hz quality 0
> Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
> Timecounter "HPET" frequency 14318180 Hz quality 900
> [root@orangebox /usr/home/gcooper]# ./cgt
> 1369355
> [root@orangebox /usr/home/gcooper]# sysctl
> kern.timecounter.hardware="ACPI-fast"
> kern.timecounter.hardware: HPET -> ACPI-fast
> [root@orangebox /usr/home/gcooper]# ./cgt
> 772289
> 
> Why's the default ACPI-fast? For power-saving functionality or because
> of the `quality' factor? What is the criteria that determines the
> `quality' of a clock as what's being reported above (I know what
> determines the quality of a clock visually from a oscilloscope =])?

I suspect that the quality of the HPET driver is lower simply because no one
had measured it previously and HPET is newer and less "proven".

-- 
John Baldwin
From bruce at cran.org.uk  Thu Apr 30 21:52:52 2009
From: bruce at cran.org.uk (Bruce Cran)
Date: Thu Apr 30 21:53:10 2009
Subject: ACPI-fast default timecounter, but HPET 83% faster
In-Reply-To: <200904300846.41576.jhb@freebsd.org>
References: <200904270150.31912.pieter@degoeje.nl>
	<7d6fde3d0904261927s1a67cf85jc982c1a68e30e081@mail.gmail.com>
	<200904300846.41576.jhb@freebsd.org>
Message-ID: <20090430225245.538d073e@gluon.draftnet>

On Thu, 30 Apr 2009 08:46:41 -0400
John Baldwin <jhb@freebsd.org> wrote:

> On Sunday 26 April 2009 10:27:42 pm Garrett Cooper wrote:

> > Why's the default ACPI-fast? For power-saving functionality or
> > because of the `quality' factor? What is the criteria that
> > determines the `quality' of a clock as what's being reported above
> > (I know what determines the quality of a clock visually from a
> > oscilloscope =])?
> 
> I suspect that the quality of the HPET driver is lower simply because
> no one had measured it previously and HPET is newer and less "proven".
> 

http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/acpica/acpi_hpet.c
shows some of the history behind the decision.  Apparently it used to
be slower but it was hoped it would get faster as systems supported it
better. I guess that's happening now.

-- 
Bruce Cran
From sfourman at gmail.com  Thu Apr 30 22:26:12 2009
From: sfourman at gmail.com (Sam Fourman Jr.)
Date: Thu Apr 30 22:26:19 2009
Subject: Fwd: Kernel panic on 7.2-RC1 when booting with ACPI enabled 
	kernel.
In-Reply-To: <200904300836.34238.jhb@freebsd.org>
References: <43b1bb350904230622u4b7790f0p9f665b649c97a3b@mail.gmail.com>
	<43b1bb350904250326o63cb3085vc6a7079fba7cd700@mail.gmail.com>
	<43b1bb350904250327n2bc0c651y7e725abda56538b0@mail.gmail.com>
	<200904300836.34238.jhb@freebsd.org>
Message-ID: <11167f520904301526g3f0185a9m51e601cbfa04177a@mail.gmail.com>

On Thu, Apr 30, 2009 at 7:36 AM, John Baldwin <jhb@freebsd.org> wrote:
> On Saturday 25 April 2009 6:27:23 am Magnus Kling wrote:
>> 2009/4/24 John Baldwin <jhb@freebsd.org>
>> > Can you do 'frame 10' followed by 'p *(struct acpi_pci_devinfo
>> > *)child->ivars'
>> >
>> > --
>> > John Baldwin
>>
>> (kgdb) frame 10
>> #10 0xc0db4ca8 in acpi_pci_child_location_str_method (cbdev=0xc2212680,
>> ? ? child=0xc2243400, buf=0xc22c2400 "slot=0 function=0 handle=",
>> buflen=1024)
>> ? ? at /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/acpi_pci.c:150
>> 150 ? ? ? ? ? ? strlcat(buf, acpi_name(dinfo->ap_handle), buflen);
>>
>> (kgdb) ?p *(struct acpi_pci_devinfo *)child->ivars
>> $1 = {ap_dinfo = {pci_links = {stqe_next = 0xc0b00f8c}, resources = {
>> ? ? ? stqh_first = 0xc0b00f8c, stqh_last = 0x1030000}, cfg = {dev = 0x0,
>> ? ? ? bar = {4, 0, 0, 3257136600, 0, 0}, bios = 0, subvendor = 0,
>> ? ? ? subdevice = 0, vendor = 0, device = 0, cmdreg = 0, statreg = 0,
>> ? ? ? baseclass = 0 '\0', subclass = 0 '\0', progif = 0 '\0', revid = 0

I also have a ACPI problem that may be related

http://www.nabble.com/Asus-X83VB-X2-Notebook-ACPI-kernel-panic-td23290433.html

Sam Fourman Jr.