cvs commit: src/sys/dev/acpica acpi_perf.c

[Nate Lawson]

Vladimir Grebenschikov wrote:
> В вс, 27/03/2005 в 14:46 -0800, Nate Lawson пишет:
> 
>>Vladimir Grebenschikov wrote:
>>
>>>В вс, 20/03/2005 в 03:51 +0000, Nate Lawson пишет:
>>>
>>>
>>>>njl         2005-03-20 03:51:18 UTC
>>>>
>>>>FreeBSD src repository
>>>>
>>>>Modified files:
>>>>  sys/dev/acpica       acpi_perf.c 
>>>>Log:
>>>>Attach acpi_perf early.  Especially when it is being used to provide info
>>>>to other devices, it needs to be attached first.  (Multi-pass newbus
>>>>probes would be a better solution.)
>>>>
>>>>Revision  Changes    Path
>>>>1.16      +6 -1      src/sys/dev/acpica/acpi_perf.c
>>>
>>>
>>>I guess this patch makes panic on my notebook:
>>>
>>>cpu0: <ACPI CPU (2 Cx states)> on acpi0
>>>acpi_perf0: <ACPI CPU Frequency Control> on cpu0
>>>acpi_perf0: failed in PERF_STATUS attach
>>>device_attach: acpi_perf0 attach returned 6
>>>panic: resource_list_add: resource entry is busy
>>
>>I believe the patch I just committed fully cleans up resources for the 
>>error case correctly.  This should fix your panic.  The other question 
>>is why your status register fails to attach but the control register 
>>succeeds.  Can you send me your acpidump:
> 
> 
> Thank you, will try fresh kernel  later today.
> 
> 
> Attached
>
> 
>         Method (_PCT, 0, NotSerialized)
>         {
>             If (LEqual (And (PDC0, One), One))
>             {
>             ...
>             }
>             Else
>             {
>                 Return (Package (0x02)
>                 {
>                     ResourceTemplate ()
>                     {
>                         Register (SystemIO, 0x10, 0x00, 0x00000000000000B2)
>                     }, 
> 
>                     ResourceTemplate ()
>                     {
>                         Register (SystemIO, 0x08, 0x00, 0x00000000000000B3)
>                     }
>                 })
>             }
>         }

I've moved this to the acpi@ list now...

Are you sure there isn't a BIOS update for your system available?  It 
appears this is a Dell since a number of them have the same problem. 
The issue is that the control and status registers overlap.  To fix, 
change this line:

Register (SystemIO, 0x10, 0x00, 0x00000000000000B2)

to this:

Register (SystemIO, 0x08, 0x00, 0x00000000000000B2)

Then, recompile your asl as described in the handbook and load it at 
boot.  I'll try to figure out a way to work around this but it looks 
difficult to detect since 16 bits is a valid register width.  I seem to 
remember imp@ had a means for detecting that a resource alloc failed due 
to an overlapping register and then split the previous resource (since 
this driver owns both).  I'll ask.

-- 
Nate