2.6.16 not booting due to ACPI revision 20060127

2.6.16 not booting due to ACPI revision 20060127

[xb]

[-- Attachment #1: Type: text/plain, Size: 2095 bytes --]

Hi all,

We have platforms that do not boot in 2.6.16, but boot OK with 2.6.15 
(loop in ACPI code).
After some investigations, I found this is due to pci buses that are 
described in the configuration, but not available in limited configurations.
These buses have a _STA method, but no _INI method.
With 2.6.15, the _STA method is run, and as the bus is not present, the 
bus and all devices behind it are ignored.
With 2.6.16, as no _INI method is provided for the bus, _STA method is 
not run, and then we loop when executing methods for devices behind the 
not present bus.

Having a look to ACPI specification, I could find nowhere the 
restriction that _STA method is called only when an _INI method is 
provided for the device:

"6.5.1 _INI (Init)
...
If the _STA method indicates that the device is present, OSPM will 
evaluate the _INI for the device (if the _INI method exists) and will 
examine each of the children of the device for _INI methods. If the _STA 
method indicates that the device is not present, OSPM will not run the 
_INI and will not examine the children of the device for _INI methods. "


traces -----------------------------------------------


 Device PC11
000060e4:  02 . .  Name _HID
000060e9:  03 . . .  PNP0A03  PCI Bus  0x030ad041
000060ee:  02 . .  Name _UID
000060f3:  03 . . .  0x0b
000060f5:  02 . .  Name _ADR
000060fa:  03 . . .  0x00
000060fc:  02 ---- 'PCI bus number setup by the BIOS'  Method _BBN
00006102:  03 . . .  0x00
00006103:  03 . . .  Return
00006104:  04 . . . .  path: \_SB_.CSFF.IO15.B1__
00006117:  02 ---- 'Dynamic_Statu'  Method _STA
0000611d:  03 . . .  0x00
0000611e:  03 . . .  If
00006120:  04 . . . .  LEqual
00006121:  05 . . . . .  path: \_SB_.CSFF.IO11.HUBD
00006134:  05 . . . . .  0x00
00006136:  04 . . . .  Return
00006137:  05 . . . . .  0x0f
00006139:  03 . . .  Return
0000613a:  04 . . . .  0x00
0000613c:  02 ---- 'Current Resource Setting'  Method _CRS
00006142:  03 . . .  0x00
00006143:  03 . . .  Return
00006144:  04 . . . .  path: \_SB_.HLRS
0000614e:  03 . . .  0x01
00006150:  03 . . .  0x01
00006152:  02


[-- Attachment #2: xavier.bru.vcf --]
[-- Type: text/x-vcard, Size: 304 bytes --]

begin:vcard
fn:Xavier Bru
n:Bru;Xavier
adr:;;1 rue de Provence, BP 208;38432 Echirolles Cedex;;;France
email;internet:Xavier.Bru@bull.net
title:BULL/DT/Open Software/linux/ia64
tel;work:+33 (0)4 76 29 77 45
tel;fax:+33 (0)4 76 29 77 70 
x-mozilla-html:TRUE
url:http://www.bull.com
version:2.1
end:vcard

Re: 2.6.16 not booting due to ACPI revision 20060127

[xb]

[-- Attachment #1: Type: text/plain, Size: 3843 bytes --]

xb wrote:

> Hi all,
>
> We have platforms that do not boot in 2.6.16, but boot OK with 2.6.15 
> (loop in ACPI code).
> After some investigations, I found this is due to pci buses that are 
> described in the configuration, but not available in limited 
> configurations.
> These buses have a _STA method, but no _INI method.
> With 2.6.15, the _STA method is run, and as the bus is not present, 
> the bus and all devices behind it are ignored.
> With 2.6.16, as no _INI method is provided for the bus, _STA method is 
> not run, and then we loop when executing methods for devices behind 
> the not present bus.
>
> Having a look to ACPI specification, I could find nowhere the 
> restriction that _STA method is called only when an _INI method is 
> provided for the device:
>
> "6.5.1 _INI (Init)
> ...
> If the _STA method indicates that the device is present, OSPM will 
> evaluate the _INI for the device (if the _INI method exists) and will 
> examine each of the children of the device for _INI methods. If the 
> _STA method indicates that the device is not present, OSPM will not 
> run the _INI and will not examine the children of the device for _INI 
> methods. "
>
>
> traces -----------------------------------------------
>
>
> Device PC11
> 000060e4:  02 . .  Name _HID
> 000060e9:  03 . . .  PNP0A03  PCI Bus  0x030ad041
> 000060ee:  02 . .  Name _UID
> 000060f3:  03 . . .  0x0b
> 000060f5:  02 . .  Name _ADR
> 000060fa:  03 . . .  0x00
> 000060fc:  02 ---- 'PCI bus number setup by the BIOS'  Method _BBN
> 00006102:  03 . . .  0x00
> 00006103:  03 . . .  Return
> 00006104:  04 . . . .  path: \_SB_.CSFF.IO15.B1__
> 00006117:  02 ---- 'Dynamic_Statu'  Method _STA
> 0000611d:  03 . . .  0x00
> 0000611e:  03 . . .  If
> 00006120:  04 . . . .  LEqual
> 00006121:  05 . . . . .  path: \_SB_.CSFF.IO11.HUBD
> 00006134:  05 . . . . .  0x00
> 00006136:  04 . . . .  Return
> 00006137:  05 . . . . .  0x0f
> 00006139:  03 . . .  Return
> 0000613a:  04 . . . .  0x00
> 0000613c:  02 ---- 'Current Resource Setting'  Method _CRS
> 00006142:  03 . . .  0x00
> 00006143:  03 . . .  Return
> 00006144:  04 . . . .  path: \_SB_.HLRS
> 0000614e:  03 . . .  0x01
> 00006150:  03 . . .  0x01
> 00006152:  02
>
I checked that the following patch fixes the problem:

--- linux-2.6.16-old/drivers/acpi/namespace/nsinit.c    2006-03-31 
18:26:23.000000000 +0200
+++ linux-2.6.16-new/drivers/acpi/namespace/nsinit.c    2006-04-03 
14:57:28.000000000 +0200
@@ -362,19 +362,6 @@ acpi_ns_init_one_device(acpi_handle obj_
     info->device_count++;
 
     /*
-     * Check if the _INI method exists for this device -
-     * if _INI does not exist, there is no need to run _STA
-     * No _INI means device requires no initialization
-     */
-    status = acpi_ns_search_node(*ACPI_CAST_PTR(u32, METHOD_NAME__INI),
-                     device_node, ACPI_TYPE_METHOD, &ini_node);
-    if (ACPI_FAILURE(status)) {
-        /* No _INI method found - move on to next device */
-
-        return_ACPI_STATUS(AE_OK);
-    }
-
-    /*
      * Run _STA to determine if we can run _INI on the device -
      * the device must be present before _INI can be run.
      * However, _STA is not required - assume device present if no _STA
@@ -405,6 +392,17 @@ acpi_ns_init_one_device(acpi_handle obj_
     }
 
     /*
+     * Check if the _INI method exists for this device -
+     * No _INI means device requires no initialization
+     */
+    status = acpi_ns_search_node(*ACPI_CAST_PTR(u32, METHOD_NAME__INI),
+                     device_node, ACPI_TYPE_METHOD, &ini_node);
+    if (ACPI_FAILURE(status)) {
+        /* No _INI method found - move on to next device */
+        return_ACPI_STATUS(AE_OK);
+    }
+
+    /*
      * The device is present and _INI exists. Run the _INI method.
      * (We already have the _INI node from above)
      */


[-- Attachment #2: xavier.bru.vcf --]
[-- Type: text/x-vcard, Size: 304 bytes --]

begin:vcard
fn:Xavier Bru
n:Bru;Xavier
adr:;;1 rue de Provence, BP 208;38432 Echirolles Cedex;;;France
email;internet:Xavier.Bru@bull.net
title:BULL/DT/Open Software/linux/ia64
tel;work:+33 (0)4 76 29 77 45
tel;fax:+33 (0)4 76 29 77 70 
x-mozilla-html:TRUE
url:http://www.bull.com
version:2.1
end:vcard

RE: 2.6.16 not booting due to ACPI revision 20060127

[Brown, Len]

>We have platforms that do not boot in 2.6.16, but boot OK with 2.6.15 
>(loop in ACPI code).

Sounds like it wouldn't have booted any of the 2.6.16 pre-release
candidates either...

>After some investigations, I found this is due to pci buses that are 
>described in the configuration, but not available in limited 
>configurations.

>These buses have a _STA method, but no _INI method.
>With 2.6.15, the _STA method is run, and as the bus is not 
>present, the bus and all devices behind it are ignored.

The non-present busses should still be ignored in 2.6.16,
independent of the STA/INI optimization.

>With 2.6.16, as no _INI method is provided for the bus, _STA method is 
>not run, and then we loop when executing methods for devices 
>behind the not present bus.

Need to find out what methods are looping on non-existent
devices, and why STA didn't prevent that.  This is probably
independent of the STA/INI optimization in 20060127.

It sounds like either
1. we're not evaluating _STA someplace in the bus enumeration code
   when we should be, and perhaps this was masked in 2.6.15 when
   we blindly evaluated STA everywhere.

   I'll venture that is the issue here -- the STA/INI optimization
   has unmasked a Linux bug.  Note that the patch to
   again blindly execute STA everwhere would simply re-mask the bug,
   rather than fixing it directly.
or

2. _STA on this box is somehow special and has side effects.


Please open a bugzilla here:
http://bugzilla.kernel.org/enter_bug.cgi?product¬PI

and attach the output from acpidump
acpidump is available in the latest pmtools here:
http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/


>Having a look to ACPI specification, I could find nowhere the 
>restriction that _STA method is called only when an _INI method is 
>provided for the device:
>
>"6.5.1 _INI (Init)
>...
>If the _STA method indicates that the device is present, OSPM will 
>evaluate the _INI for the device (if the _INI method exists) and will 
>examine each of the children of the device for _INI methods. 
>If the _STA 
>method indicates that the device is not present, OSPM will not run the 
>_INI and will not examine the children of the device for _INI 
>methods. "

That is true, but it is also true that the ACPI spec doesn't say
how how many times STA will be evaluated, if at all.

> traces -----------------------------------------------
>
>
> Device PC11
> 000060e4:  02 . .  Name _HID
> 000060e9:  03 . . .  PNP0A03  PCI Bus  0x030ad041
> 000060ee:  02 . .  Name _UID
> 000060f3:  03 . . .  0x0b
> 000060f5:  02 . .  Name _ADR
> 000060fa:  03 . . .  0x00
> 000060fc:  02 ---- 'PCI bus number setup by the BIOS'  Method _BBN
> 00006102:  03 . . .  0x00
> 00006103:  03 . . .  Return
> 00006104:  04 . . . .  path: \_SB_.CSFF.IO15.B1__
> 00006117:  02 ---- 'Dynamic_Statu'  Method _STA
> 0000611d:  03 . . .  0x00
> 0000611e:  03 . . .  If
> 00006120:  04 . . . .  LEqual
> 00006121:  05 . . . . .  path: \_SB_.CSFF.IO11.HUBD
> 00006134:  05 . . . . .  0x00
> 00006136:  04 . . . .  Return
> 00006137:  05 . . . . .  0x0f
> 00006139:  03 . . .  Return
> 0000613a:  04 . . . .  0x00
> 0000613c:  02 ---- 'Current Resource Setting'  Method _CRS
> 00006142:  03 . . .  0x00
> 00006143:  03 . . .  Return
> 00006144:  04 . . . .  path: \_SB_.HLRS
> 0000614e:  03 . . .  0x01
> 00006150:  03 . . .  0x01
> 00006152:  02
>

Does this trace show the access to the bus that does not exist?
Where is the loop?

thanks,
-Len

RE: 2.6.16 not booting due to ACPI revision 20060127

[Moore, Robert]

I believe that we must run _STA in order to determine whether the device is present or not and whether to continue initialization of the device children.

Thus, the patch given is essentially correct.




-----Original Message-----
From: xb [mailto:xavier.bru@bull.net] 
Sent: Tuesday, April 04, 2006 1:24 AM
To: Brown, Len; Moore, Robert; Luck, Tony; linux-acpi@vger.kernel.org; Therien, Guy
Cc: linux-ia64@vger.kernel.org
Subject: Re: 2.6.16 not booting due to ACPI revision 20060127

Hi Robert and len,

Thanks for answering my mail.
I think that the problem is that we execute methods on the hot plug controler for an unexisting bus. 
There is a method that loops on a particular field:

000065f3:  04 -------- Method WSOB
000065f9:  05 . . . . .  0x00
000065fa:  05 . . . . .  While
000065fc:  06 . . . . . .  SOBO
00006600:  06 . . . . . .  Noop

I put, attached a partial trace of the called methods, and a dump of the DSDT.
Thanks again.

Brown, Len wrote: 
We have platforms that do not boot in 2.6.16, but boot OK with 2.6.15 
(loop in ACPI code).
    

Sounds like it wouldn't have booted any of the 2.6.16 pre-release
candidates either...

  
Yes.

After some investigations, I found this is due to pci buses that are 
described in the configuration, but not available in limited 
configurations.
    

  
These buses have a _STA method, but no _INI method.
With 2.6.15, the _STA method is run, and as the bus is not 
present, the bus and all devices behind it are ignored.
    

The non-present busses should still be ignored in 2.6.16,
independent of the STA/INI optimization.

  
How can this be done if we do not run the STA method ?

With 2.6.16, as no _INI method is provided for the bus, _STA method is 
not run, and then we loop when executing methods for devices 
behind the not present bus.
    

Need to find out what methods are looping on non-existent
devices, and why STA didn't prevent that.  This is probably
independent of the STA/INI optimization in 20060127.

  
As described earlier, we loop in WSOB method for hotplug controler for unexisting bus...

It sounds like either
1. we're not evaluating _STA someplace in the bus enumeration code
   when we should be, and perhaps this was masked in 2.6.15 when
   we blindly evaluated STA everywhere.

   I'll venture that is the issue here -- the STA/INI optimization
   has unmasked a Linux bug.  Note that the patch to
   again blindly execute STA everwhere would simply re-mask the bug,
   rather than fixing it directly.
or

2. _STA on this box is somehow special and has side effects.

  

Please open a bugzilla here:
http://bugzilla.kernel.org/enter_bug.cgi?product¬PI

and attach the output from acpidump
acpidump is available in the latest pmtools here:
http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/


  
OK, I will do that.

Having a look to ACPI specification, I could find nowhere the 
restriction that _STA method is called only when an _INI method is 
provided for the device:

"6.5.1 _INI (Init)
...
If the _STA method indicates that the device is present, OSPM will 
evaluate the _INI for the device (if the _INI method exists) and will 
examine each of the children of the device for _INI methods. 
If the _STA 
method indicates that the device is not present, OSPM will not run the 
_INI and will not examine the children of the device for _INI 
methods. "
    

That is true, but it is also true that the ACPI spec doesn't say
how how many times STA will be evaluated, if at all.

  
traces -----------------------------------------------


Device PC11
000060e4:  02 . .  Name _HID
000060e9:  03 . . .  PNP0A03  PCI Bus  0x030ad041
000060ee:  02 . .  Name _UID
000060f3:  03 . . .  0x0b
000060f5:  02 . .  Name _ADR
000060fa:  03 . . .  0x00
000060fc:  02 ---- 'PCI bus number setup by the BIOS'  Method _BBN
00006102:  03 . . .  0x00
00006103:  03 . . .  Return
00006104:  04 . . . .  path: \_SB_.CSFF.IO15.B1__
00006117:  02 ---- 'Dynamic_Statu'  Method _STA
0000611d:  03 . . .  0x00
0000611e:  03 . . .  If
00006120:  04 . . . .  LEqual
00006121:  05 . . . . .  path: \_SB_.CSFF.IO11.HUBD
00006134:  05 . . . . .  0x00
00006136:  04 . . . .  Return
00006137:  05 . . . . .  0x0f
00006139:  03 . . .  Return
0000613a:  04 . . . .  0x00
0000613c:  02 ---- 'Current Resource Setting'  Method _CRS
00006142:  03 . . .  0x00
00006143:  03 . . .  Return
00006144:  04 . . . .  path: \_SB_.HLRS
0000614e:  03 . . .  0x01
00006150:  03 . . .  0x01
00006152:  02

    

Does this trace show the access to the bus that does not exist?
Where is the loop?
  
Yes (see traces).


thanks,
-Len

  
Moore, Robert wrote: 
We changed the device initialization sequence to improve boot
performance by not executing _STA unless an _INI is actually present.

The change to selectively run _STA was made in 20051216, from the
release notes:

"Implemented an optimization to the initialization sequence that can
improve boot time. During ACPI device initialization, the _STA method is
now run if and only if the _INI method exists. The _STA method is used
to determine if the device is present; An _INI can only be run if _STA
returns present, but it is a waste of time to run the _STA method if the
_INI does not exist."

  
Our BIOS provides description for the maximum configuration, then I think it relies on the fact we run _STA method on the bus before accessing devices on that bus...


It is my understanding of the ACPI spec that there is no requirement
that _STA be run, ever. There is only a requirement that _INI be run if
the device is present and _INI exists.
 
Therefore, the optimization above was implemented because we were only
running _STA to determine whether or not to run _INI. If there is no
_INI present, it is pointless to run the _STA.


  
Having a look to ACPI specification, I could find nowhere the 
restriction that _STA method is called only when an _INI method is 
provided for the device:

      

Yes, there is no restriction on when or if _STA can be run. However, I
do not think that there a *requirement* to run _STA, only _INI.

I don't understand why running _STA fixes the problem. Exactly what or
who is depending on _STA to be run?

Bob