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@xxxxxxxx]
Sent: Tuesday, April 04, 2006 1:24 AM
To: Brown, Len; Moore, Robert; Luck, Tony; linux-acpi@xxxxxxxxxxxxxxx; Therien, Guy
Cc: linux-ia64@xxxxxxxxxxxxxxx
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=ACPI
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
-
: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
|