All of lore.kernel.org
 help / color / mirror / Atom feed
From: xb <xavier.bru@bull.net>
To: linux-ia64@vger.kernel.org
Subject: Re: 2.6.16 not booting due to ACPI  revision 20060127
Date: Mon, 03 Apr 2006 14:34:04 +0000	[thread overview]
Message-ID: <4431325C.1040508@bull.net> (raw)
In-Reply-To: <44310983.3070000@bull.net>

[-- 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


  reply	other threads:[~2006-04-03 14:34 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-03 11:39 2.6.16 not booting due to ACPI revision 20060127 xb
2006-04-03 14:34 ` xb [this message]
  -- strict thread matches above, loose matches on Subject: below --
2006-04-03 17:14 Brown, Len
2006-04-03 17:14 ` Brown, Len
2006-04-03 17:18 Moore, Robert
2006-04-04 22:57 Moore, Robert
2006-04-04 22:57 ` Moore, Robert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4431325C.1040508@bull.net \
    --to=xavier.bru@bull.net \
    --cc=linux-ia64@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.