RE: one more ACPI Error (utglobal-0125): Unknown exception code: 0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

RE: one more ACPI Error (utglobal-0125): Unknown exception code: 0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

[Moore, Robert]

>From one of the ACPI guys:

> Get hid
> Look for driver
> If you find a match, load it
> If no match, get CID
> Look for driver
> If you find a match, load it
> If you did not find an hid or cid match, punt



> -----Original Message-----
> From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-
> owner@vger.kernel.org] On Behalf Of keith mannthey
> Sent: Wednesday, September 06, 2006 11:14 AM
> To: Bjorn Helgaas
> Cc: Len Brown; Moore, Robert; Li, Shaohua; Mattia Dongili; Andrew
Morton;
> lkml; linux acpi; KAMEZAWA Hiroyuki
> Subject: Re: one more ACPI Error (utglobal-0125): Unknown exception
code:
> 0xFFFFFFEA [Re: 2.6.18-rc4-mm3]
> 
> On Fri, 2006-09-01 at 17:20 -0600, Bjorn Helgaas wrote:
> > On Friday 01 September 2006 17:01, keith mannthey wrote:
> > > On Thu, 2006-08-31 at 21:15 -0600, Bjorn Helgaas wrote:
> > > > The current ACPI driver binding algorithm in
acpi_bus_find_driver()
> > > > looks at each driver, checking whether it can match either the
_HID
> > > > or the _CID of a device.  Since we try the motherboard driver
first,
> > > > it matches the memory device _CID.
> > >
> > > Ok I reverted the motherboard driver patch and cooked up the
following
> > > patch that works for my issue.
> > >
> > >   It creates the idea that acpi_match_ids has a type of request to
> check
> > > against for _HID, _CID or both.  See acpi_bus_match_req. I then
fix up
> > > all the needed callers to change the API to acpi_match_ids and
> > > acpi_bus_match and have callers can say what they want to match
> > > against.
> > >
> > >   Then in acpi_bus_find_driver I have it do 2 passes to search for
> _HID
> > > first then the _CID.
> > >
> > > Does this look like it is in the right ballpark or should we be
doing
> > > something else?  Built/tested against 2.6.18-rc4-mm3.
> >
> > Conceptually I like this much better than mucking with the
motherboard
> > driver.  I'm not sure the important people have signed off on this
> > strategy of binding with _HID first, then _CID (hi, Len :-))  Maybe
> > there are ramifications that we need to consider.  But I think it
> > is a better match for "what people expect should happen."
> 
> ACPI folks can we get some response to this?  This problem has been
> reported a few times against the -mm tree and I would like to get the
> proper fix (whatever it is) upstream sometime soon.
> 
> Bjorn thanks for the help and for pointing the error reports in the
> right direction.
> 
> Thanks,
>   Keith
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-acpi"
in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: one more ACPI Error (utglobal-0125): Unknown exception code: 0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

[keith mannthey]

On Wed, 2006-09-06 at 11:59 -0700, Moore, Robert wrote:
> From one of the ACPI guys:
> 
> > Get hid
> > Look for driver
> > If you find a match, load it
> > If no match, get CID
> > Look for driver
> > If you find a match, load it
> > If you did not find an hid or cid match, punt

I think this is what my patch is doing.

when looking for a driver: (acpi_bus_find_driver)
I check against the HID 
return if found 
Then I check against the CID
return if found
else
punt 

Any objections to pushing this into -mm and dropping the motherboard
change?

Thanks,
  Keith 
  

RE: one more ACPI Error (utglobal-0125): Unknown exception code:0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

[Shaohua Li]

On Thu, 2006-09-07 at 04:04 +0800, keith mannthey wrote:
> On Wed, 2006-09-06 at 11:59 -0700, Moore, Robert wrote: 
> > From one of the ACPI guys: 
> >  
> > > Get hid 
> > > Look for driver 
> > > If you find a match, load it 
> > > If no match, get CID 
> > > Look for driver 
> > > If you find a match, load it 
> > > If you did not find an hid or cid match, punt
> 
> I think this is what my patch is doing.
> 
> when looking for a driver: (acpi_bus_find_driver) 
> I check against the HID  
> return if found  
> Then I check against the CID 
> return if found 
> else 
> punt 
> 
> Any objections to pushing this into -mm and dropping the motherboard 
> change?
I'd prefer not take this way. The ACPI driver model is already mess
enough, let's don't make it worse. We are converting the ACPI driver
model to Linux driver model, this will make the attempt difficult.

We can let the motherboard driver not bind to your device (say we didn't
register the motherboard driver, but just reserve the resource of the
deivce). Is it ok to you? (I remember Bjorn said he wants to reserve the
mem region of the device too).

Thanks,
Shaohua

Re: one more ACPI Error (utglobal-0125): Unknown exception code:0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

[Bjorn Helgaas]

On Wednesday 06 September 2006 20:03, Shaohua Li wrote:
> On Thu, 2006-09-07 at 04:04 +0800, keith mannthey wrote:
> > On Wed, 2006-09-06 at 11:59 -0700, Moore, Robert wrote: 
> > > From one of the ACPI guys: 
> > >  
> > > > Get hid 
> > > > Look for driver 
> > > > If you find a match, load it 
> > > > If no match, get CID 
> > > > Look for driver 
> > > > If you find a match, load it 
> > > > If you did not find an hid or cid match, punt
> > 
> > I think this is what my patch is doing.
> > 
> > when looking for a driver: (acpi_bus_find_driver) 
> > I check against the HID  
> > return if found  
> > Then I check against the CID 
> > return if found 
> > else 
> > punt 
> > 
> > Any objections to pushing this into -mm and dropping the motherboard 
> > change?

> I'd prefer not take this way. The ACPI driver model is already mess
> enough, let's don't make it worse. We are converting the ACPI driver
> model to Linux driver model, this will make the attempt difficult.

I see that driver_bind() and driver_probe_device() don't mesh well
with the idea that multiple drivers might be able to claim a device,
because there doesn't seem to be a way to prioritize one driver
over another.  Is that the problem you're referring to?

If we decide that "try HID first, then try CID" is the right thing,
I think we should figure out how to make that work.  Maybe that
means extending the driver model somehow.

> We can let the motherboard driver not bind to your device (say we didn't
> register the motherboard driver, but just reserve the resource of the
> deivce). Is it ok to you? (I remember Bjorn said he wants to reserve the
> mem region of the device too).

My point was that ACPI tells us what resources the device uses,
and we should reserve all of them so we accurately model the system.

Reserving resources without registering the driver sounds like a hack
to work around broken behavior elsewhere, so I don't think it's a
good idea.

Bjorn

Re: one more ACPI Error (utglobal-0125): Unknown exception code:0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

[Shaohua Li]

On Thu, 2006-09-07 at 09:25 -0600, Bjorn Helgaas wrote:
> On Wednesday 06 September 2006 20:03, Shaohua Li wrote:
> > On Thu, 2006-09-07 at 04:04 +0800, keith mannthey wrote:
> > > On Wed, 2006-09-06 at 11:59 -0700, Moore, Robert wrote: 
> > > > From one of the ACPI guys: 
> > > >  
> > > > > Get hid 
> > > > > Look for driver 
> > > > > If you find a match, load it 
> > > > > If no match, get CID 
> > > > > Look for driver 
> > > > > If you find a match, load it 
> > > > > If you did not find an hid or cid match, punt
> > > 
> > > I think this is what my patch is doing.
> > > 
> > > when looking for a driver: (acpi_bus_find_driver) 
> > > I check against the HID  
> > > return if found  
> > > Then I check against the CID 
> > > return if found 
> > > else 
> > > punt 
> > > 
> > > Any objections to pushing this into -mm and dropping the motherboard 
> > > change?
> 
> > I'd prefer not take this way. The ACPI driver model is already mess
> > enough, let's don't make it worse. We are converting the ACPI driver
> > model to Linux driver model, this will make the attempt difficult.
> 
> I see that driver_bind() and driver_probe_device() don't mesh well
> with the idea that multiple drivers might be able to claim a device,
> because there doesn't seem to be a way to prioritize one driver
> over another.  Is that the problem you're referring to?
Yes.

> If we decide that "try HID first, then try CID" is the right thing,
> I think we should figure out how to make that work.  Maybe that
> means extending the driver model somehow.
Don't think it's easy, especially no other bus needs it I guess.

> > We can let the motherboard driver not bind to your device (say we didn't
> > register the motherboard driver, but just reserve the resource of the
> > deivce). Is it ok to you? (I remember Bjorn said he wants to reserve the
> > mem region of the device too).
> 
> My point was that ACPI tells us what resources the device uses,
> and we should reserve all of them so we accurately model the system.
> 
> Reserving resources without registering the driver sounds like a hack
> to work around broken behavior elsewhere, so I don't think it's a
> good idea.
Do we really need the memory hotplug device returns pnp0c01/pnp0c02?
What's the purpose?

Thanks,
Shaohua

Re: one more ACPI Error (utglobal-0125): Unknown exception code:0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

[Bjorn Helgaas]

> On Thu, 2006-09-07 at 09:25 -0600, Bjorn Helgaas wrote:
>> If we decide that "try HID first, then try CID" is the right thing,
>> I think we should figure out how to make that work.  Maybe that
>> means extending the driver model somehow.
> Don't think it's easy, especially no other bus needs it I guess.

I agree it's probably not easy, but I think having the right
semantics is more important than fitting cleanly into the
driver model.  But I know that without code, I'm just venting
hot air, not contributing to a solution.

How's the ACPI driver model integration going, anyway?  I seem
to recall some patches a while back, but I don't think they're
in the tree yet.

> Do we really need the memory hotplug device returns pnp0c01/pnp0c02?
> What's the purpose?

I don't know.  But I think Keith already determined that a BIOS change
is not likely.  I hate to ask for BIOS changes like this because it
feels like asking them to avoid broken things in Linux.

Re: one more ACPI Error (utglobal-0125): Unknown exception code:0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

[keith mannthey]

On Thu, 2006-09-07 at 20:27 -0600, Bjorn Helgaas wrote:
> > On Thu, 2006-09-07 at 09:25 -0600, Bjorn Helgaas wrote:
> >> If we decide that "try HID first, then try CID" is the right thing,
> >> I think we should figure out how to make that work.  Maybe that
> >> means extending the driver model somehow.
> > Don't think it's easy, especially no other bus needs it I guess.
> 
> I agree it's probably not easy, but I think having the right
> semantics is more important than fitting cleanly into the
> driver model.  But I know that without code, I'm just venting
> hot air, not contributing to a solution.
> 
> How's the ACPI driver model integration going, anyway?  I seem
> to recall some patches a while back, but I don't think they're
> in the tree yet.
> 
> > Do we really need the memory hotplug device returns pnp0c01/pnp0c02?
> > What's the purpose?
> 
> I don't know.  But I think Keith already determined that a BIOS change
> is not likely.  I hate to ask for BIOS changes like this because it
> feels like asking them to avoid broken things in Linux.

  Ok my motherboard patch was dropped from -mm so I am broken again but
others are fixed. Is the answer that we do nothing about this issues?   

  I am pretty sure my SSDT table is valid if someone *cannot* point out
in the spec where my device is malformed  by having both HID and CID I
will not be able even start the request to change the BIOS (it would be
a waste of my time).  Sure having the CID of the memory device may be
overkill but is it wrong?  

  Unless someone can show me a alternate solution I am going to push the
check HID before CID patch to -mm in the next day or two. 

Thanks,
  Keith 

Re: one more ACPI Error (utglobal-0125): Unknown exception code:0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

[Bjorn Helgaas]

On Tuesday 12 September 2006 19:27, keith mannthey wrote:
> On Thu, 2006-09-07 at 20:27 -0600, Bjorn Helgaas wrote:
> > > On Thu, 2006-09-07 at 09:25 -0600, Bjorn Helgaas wrote:
> > >> If we decide that "try HID first, then try CID" is the right thing,
> > >> I think we should figure out how to make that work.  Maybe that
> > >> means extending the driver model somehow.
> > > Don't think it's easy, especially no other bus needs it I guess.
> > 
> > I agree it's probably not easy, but I think having the right
> > semantics is more important than fitting cleanly into the
> > driver model.  But I know that without code, I'm just venting
> > hot air, not contributing to a solution.
> > 
> > How's the ACPI driver model integration going, anyway?  I seem
> > to recall some patches a while back, but I don't think they're
> > in the tree yet.
> > 
> > > Do we really need the memory hotplug device returns pnp0c01/pnp0c02?
> > > What's the purpose?
> > 
> > I don't know.  But I think Keith already determined that a BIOS change
> > is not likely.  I hate to ask for BIOS changes like this because it
> > feels like asking them to avoid broken things in Linux.
> 
>   Ok my motherboard patch was dropped from -mm so I am broken again but
> others are fixed. Is the answer that we do nothing about this issues?   
> 
>   I am pretty sure my SSDT table is valid if someone *cannot* point out
> in the spec where my device is malformed  by having both HID and CID I
> will not be able even start the request to change the BIOS (it would be
> a waste of my time).  Sure having the CID of the memory device may be
> overkill but is it wrong?  

I think that your SSDT is valid.  I can't point to a specific
reference in the spec, but I think the "try _HID first, then try
_CID" strategy is clearly the intent.  Otherwise, there would be
no reason to separate _HID from _CID.

>   Unless someone can show me a alternate solution I am going to push the
> check HID before CID patch to -mm in the next day or two. 

I support this, although I do understand that it will make it more
difficult to integrate ACPI into the driver model because the driver
model currently only does one pass to check whether a driver can claim
a device.

Bjorn

Re: one more ACPI Error (utglobal-0125): Unknown exception code:0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

[Shaohua Li]

On Wed, 2006-09-13 at 22:51 +0800, Bjorn Helgaas wrote:
> On Tuesday 12 September 2006 19:27, keith mannthey wrote:
> > On Thu, 2006-09-07 at 20:27 -0600, Bjorn Helgaas wrote:
> > > > On Thu, 2006-09-07 at 09:25 -0600, Bjorn Helgaas wrote:
> > > >> If we decide that "try HID first, then try CID" is the right
> thing,
> > > >> I think we should figure out how to make that work.  Maybe that
> > > >> means extending the driver model somehow.
> > > > Don't think it's easy, especially no other bus needs it I guess.
> > >
> > > I agree it's probably not easy, but I think having the right
> > > semantics is more important than fitting cleanly into the
> > > driver model.  But I know that without code, I'm just venting
> > > hot air, not contributing to a solution.
> > >
> > > How's the ACPI driver model integration going, anyway?  I seem
> > > to recall some patches a while back, but I don't think they're
> > > in the tree yet.
> > >
> > > > Do we really need the memory hotplug device returns
> pnp0c01/pnp0c02?
> > > > What's the purpose?
> > >
> > > I don't know.  But I think Keith already determined that a BIOS
> change
> > > is not likely.  I hate to ask for BIOS changes like this because
> it
> > > feels like asking them to avoid broken things in Linux.
> >
> >   Ok my motherboard patch was dropped from -mm so I am broken again
> but
> > others are fixed. Is the answer that we do nothing about this
> issues?  
> >
> >   I am pretty sure my SSDT table is valid if someone *cannot* point
> out
> > in the spec where my device is malformed  by having both HID and CID
> I
> > will not be able even start the request to change the BIOS (it would
> be
> > a waste of my time).  Sure having the CID of the memory device may
> be
> > overkill but is it wrong? 
> 
> I think that your SSDT is valid.  I can't point to a specific
> reference in the spec, but I think the "try _HID first, then try
> _CID" strategy is clearly the intent.  Otherwise, there would be
> no reason to separate _HID from _CID.
The spec actually doesn't mention PNP0C01/PNP0C02. It's hard to say this
is valid or invalid. 

The 'try _HID first then _CID' has another downside. It highly depends
on the driver is loaded first and then load the device. See motherboard
driver loads first and the mem hotplug driver isn't loaded, in this
situation if you scan the mem hotplug device, the mechanism will fail as
the two pass search will still bind motherboard driver to the device.

If you take the two pass search, I have a feeling this will make acpi
never be able to convert Linux driver model.

If you really want to workaround the issue, I prefer have a blacklist or
something to let ACPI not use the _CID for your device, but please don't
mess the ACPI core itself.

Thanks,
Shaohua

Re: one more ACPI Error (utglobal-0125): Unknown exception code:0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

[Bjorn Helgaas]

On Wednesday 13 September 2006 21:01, Shaohua Li wrote:
> On Wed, 2006-09-13 at 22:51 +0800, Bjorn Helgaas wrote:
> > I think that your SSDT is valid.  I can't point to a specific
> > reference in the spec, but I think the "try _HID first, then try
> > _CID" strategy is clearly the intent.  Otherwise, there would be
> > no reason to separate _HID from _CID.

> The spec actually doesn't mention PNP0C01/PNP0C02. It's hard to say this
> is valid or invalid. 

This problem is more general than just Keith's situation.  This
could happen with any device that has both _HID and _CID.  As
soon as you have both _HID and _CID, you can have a driver that
claims the _HID and another that claims the _CID.

The spec obviously anticipates this situation, which is why I
think the SSDT is valid from the ACPI spec point of view.

Now, if you have some definition of the programming model of
PNP0C01/PNP0C02, and the memory device doesn't conform to that
model, then I would agree that the SSDT is invalid.  But I
don't know where a PNP0C01/PNP0C02 programming model is defined.

The linux driver does nothing more than reserve the resources
of the device, so it doesn't use any programming model at all.
The memory device (in fact, any ACPI device at all) trivially
conforms to this "null programming model."

> The 'try _HID first then _CID' has another downside. It highly depends
> on the driver is loaded first and then load the device. See motherboard
> driver loads first and the mem hotplug driver isn't loaded, in this
> situation if you scan the mem hotplug device, the mechanism will fail as
> the two pass search will still bind motherboard driver to the device.

I agree, this is a problem that will have to be resolved.  And it's
really not just an ACPI problem.  A PCI driver can claim devices based
on a class or a vendor/device/subvendor/subdevice with wildcards.
Another driver can claim devices with a specific vendor/device/etc.
Some devices may match with both drivers.

PCI has a /sys/bus/pci/driver/XXX/{bind,unbind} mechanism to cause a
driver to release a device and bind another driver to it.  Maybe we
could do something similar for ACPI. 

Bjorn

Re: one more ACPI Error (utglobal-0125): Unknown exception code:0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

[Shaohua Li]

On Thu, 2006-09-14 at 10:36 -0600, Bjorn Helgaas wrote:
> On Wednesday 13 September 2006 21:01, Shaohua Li wrote:
> > On Wed, 2006-09-13 at 22:51 +0800, Bjorn Helgaas wrote:
> > > I think that your SSDT is valid.  I can't point to a specific
> > > reference in the spec, but I think the "try _HID first, then try
> > > _CID" strategy is clearly the intent.  Otherwise, there would be
> > > no reason to separate _HID from _CID.
> 
> > The spec actually doesn't mention PNP0C01/PNP0C02. It's hard to say this
> > is valid or invalid. 
> 
> This problem is more general than just Keith's situation.  This
> could happen with any device that has both _HID and _CID.  As
> soon as you have both _HID and _CID, you can have a driver that
> claims the _HID and another that claims the _CID.
We don't see such issue before, don't think it's generic. We did have
some devices with _CID, like a pcie root bridge claims pnp0a03 (pci root
bridge), but they are really compatible.

> The spec obviously anticipates this situation, which is why I
> think the SSDT is valid from the ACPI spec point of view.
> 
> Now, if you have some definition of the programming model of
> PNP0C01/PNP0C02, and the memory device doesn't conform to that
> model, then I would agree that the SSDT is invalid.  But I
> don't know where a PNP0C01/PNP0C02 programming model is defined.
> 
> The linux driver does nothing more than reserve the resources
> of the device, so it doesn't use any programming model at all.
> The memory device (in fact, any ACPI device at all) trivially
> conforms to this "null programming model."
> 
> > The 'try _HID first then _CID' has another downside. It highly depends
> > on the driver is loaded first and then load the device. See motherboard
> > driver loads first and the mem hotplug driver isn't loaded, in this
> > situation if you scan the mem hotplug device, the mechanism will fail as
> > the two pass search will still bind motherboard driver to the device.
> 
> I agree, this is a problem that will have to be resolved.  And it's
> really not just an ACPI problem.  A PCI driver can claim devices based
> on a class or a vendor/device/subvendor/subdevice with wildcards.
> Another driver can claim devices with a specific vendor/device/etc.
> Some devices may match with both drivers.
I'd prefer don't do ACPI core change in this stage and just workaround
Keith's issue till we find this is really a generic problem.

> PCI has a /sys/bus/pci/driver/XXX/{bind,unbind} mechanism to cause a
> driver to release a device and bind another driver to it.  Maybe we
> could do something similar for ACPI. 
After we convert acpi core to Linux driver model, we have the
capability. But not sure if this can help Keith.

Thanks,
Shaohua

Re: one more ACPI Error (utglobal-0125): Unknown exception code:0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

[Bjorn Helgaas]

On Thursday 14 September 2006 19:39, Shaohua Li wrote:
> > PCI has a /sys/bus/pci/driver/XXX/{bind,unbind} mechanism to cause a
> > driver to release a device and bind another driver to it.  Maybe we
> > could do something similar for ACPI. 
> After we convert acpi core to Linux driver model, we have the
> capability. But not sure if this can help Keith.

When will the conversion to the Linux driver model happen?

Re: one more ACPI Error (utglobal-0125): Unknown exception code:0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

[keith mannthey]

On Thu, 2006-09-14 at 11:01 +0800, Shaohua Li wrote:
> On Wed, 2006-09-13 at 22:51 +0800, Bjorn Helgaas wrote:
> > On Tuesday 12 September 2006 19:27, keith mannthey wrote:
> > > On Thu, 2006-09-07 at 20:27 -0600, Bjorn Helgaas wrote:
> > > > > On Thu, 2006-09-07 at 09:25 -0600, Bjorn Helgaas wrote:

> > I think that your SSDT is valid.  I can't point to a specific
> > reference in the spec, but I think the "try _HID first, then try
> > _CID" strategy is clearly the intent.  Otherwise, there would be
> > no reason to separate _HID from _CID.
> The spec actually doesn't mention PNP0C01/PNP0C02. It's hard to say this
> is valid or invalid. 

Lets work on the assumption it is valid until someone points out in a
spec that says it isn't. 

> The 'try _HID first then _CID' has another downside. It highly depends
> on the driver is loaded first and then load the device. See motherboard
> driver loads first and the mem hotplug driver isn't loaded, in this
> situation if you scan the mem hotplug device, the mechanism will fail as
> the two pass search will still bind motherboard driver to the device.
Any solution depends on the mem hotplug device being loaded.  This
doesn't appear to be _HID before _CID specific issue .  

> If you take the two pass search, I have a feeling this will make acpi
> never be able to convert Linux driver model.

I am not trying to break forward work but what I do want is a solution
to my problem. 

> If you really want to workaround the issue, I prefer have a blacklist or
> something to let ACPI not use the _CID for your device, but please don't
> mess the ACPI core itself.

My fist pass to fix the problem was I guess a hack of sorts that caused
others problems (motherboard add return != 0 on unknown devices).  I
don't want another Keith grown hack that breaks other people. 

Can you elaborate on what you think would be safe way to do what you
propose since the ACPI core (can't/won't?) be fixed? I can imagine a
couple of different ways to fix this but I would like some feedback
before I go off and work on the 3rd pass of this fix. 

1.  Make the memory device get scanned before the motherboard device
somehow.  Implicitly reorder the devices in the list. Perhaps a priority
sorted of sorts to have _HID device always before _CID devices during
the scan? 

2.  Have the motherboard device (if it finds the right acpi device type)
hook into the memory device somehow. 

3.  Some special blacklist of the motherboard device on my specific
system. 


Thanks,
  Keith 

Re: one more ACPI Error (utglobal-0125): Unknown exception code:0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

[Shaohua Li]

On Thu, 2006-09-14 at 10:55 -0700, keith mannthey wrote:
> On Thu, 2006-09-14 at 11:01 +0800, Shaohua Li wrote:
> > On Wed, 2006-09-13 at 22:51 +0800, Bjorn Helgaas wrote:
> > > On Tuesday 12 September 2006 19:27, keith mannthey wrote:
> > > > On Thu, 2006-09-07 at 20:27 -0600, Bjorn Helgaas wrote:
> > > > > > On Thu, 2006-09-07 at 09:25 -0600, Bjorn Helgaas wrote:
> 
> > > I think that your SSDT is valid.  I can't point to a specific
> > > reference in the spec, but I think the "try _HID first, then try
> > > _CID" strategy is clearly the intent.  Otherwise, there would be
> > > no reason to separate _HID from _CID.
> > The spec actually doesn't mention PNP0C01/PNP0C02. It's hard to say this
> > is valid or invalid. 
> 
> Lets work on the assumption it is valid until someone points out in a
> spec that says it isn't. 
> 
> > The 'try _HID first then _CID' has another downside. It highly depends
> > on the driver is loaded first and then load the device. See motherboard
> > driver loads first and the mem hotplug driver isn't loaded, in this
> > situation if you scan the mem hotplug device, the mechanism will fail as
> > the two pass search will still bind motherboard driver to the device.
> Any solution depends on the mem hotplug device being loaded.  This
> doesn't appear to be _HID before _CID specific issue .  
> 
> > If you take the two pass search, I have a feeling this will make acpi
> > never be able to convert Linux driver model.
> 
> I am not trying to break forward work but what I do want is a solution
> to my problem. 
> 
> > If you really want to workaround the issue, I prefer have a blacklist or
> > something to let ACPI not use the _CID for your device, but please don't
> > mess the ACPI core itself.
> 
> My fist pass to fix the problem was I guess a hack of sorts that caused
> others problems (motherboard add return != 0 on unknown devices).  I
> don't want another Keith grown hack that breaks other people. 
> 
> Can you elaborate on what you think would be safe way to do what you
> propose since the ACPI core (can't/won't?) be fixed? I can imagine a
> couple of different ways to fix this but I would like some feedback
> before I go off and work on the 3rd pass of this fix. 
> 
> 1.  Make the memory device get scanned before the motherboard device
> somehow.  Implicitly reorder the devices in the list. Perhaps a priority
> sorted of sorts to have _HID device always before _CID devices during
> the scan? 
This will change the scan order of ACPI device, and sounds too hack to me.

> 2.  Have the motherboard device (if it finds the right acpi device type)
> hook into the memory device somehow. 
> 
> 3.  Some special blacklist of the motherboard device on my specific
> system. 
Either one of the two looks ok.

Thanks,
Shaohua

Re: one more ACPI Error (utglobal-0125): Unknown exception code:0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

[keith mannthey]

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

On Fri, 2006-09-15 at 09:52 +0800, Shaohua Li wrote:
> On Thu, 2006-09-14 at 10:55 -0700, keith mannthey wrote:
> > On Thu, 2006-09-14 at 11:01 +0800, Shaohua Li wrote:
> > > On Wed, 2006-09-13 at 22:51 +0800, Bjorn Helgaas wrote:
> > > > On Tuesday 12 September 2006 19:27, keith mannthey wrote:
> > > > > On Thu, 2006-09-07 at 20:27 -0600, Bjorn Helgaas wrote:
> > > > > > > On Thu, 2006-09-07 at 09:25 -0600, Bjorn Helgaas wrote:
> > 
> > > > I think that your SSDT is valid.  I can't point to a specific
> > > > reference in the spec, but I think the "try _HID first, then try
> > > > _CID" strategy is clearly the intent.  Otherwise, there would be
> > > > no reason to separate _HID from _CID.
> > > The spec actually doesn't mention PNP0C01/PNP0C02. It's hard to say this
> > > is valid or invalid. 
> > 
> > Lets work on the assumption it is valid until someone points out in a
> > spec that says it isn't. 
> > 
> > > The 'try _HID first then _CID' has another downside. It highly depends
> > > on the driver is loaded first and then load the device. See motherboard
> > > driver loads first and the mem hotplug driver isn't loaded, in this
> > > situation if you scan the mem hotplug device, the mechanism will fail as
> > > the two pass search will still bind motherboard driver to the device.
> > Any solution depends on the mem hotplug device being loaded.  This
> > doesn't appear to be _HID before _CID specific issue .  
> > 
> > > If you take the two pass search, I have a feeling this will make acpi
> > > never be able to convert Linux driver model.
> > 
> > I am not trying to break forward work but what I do want is a solution
> > to my problem. 
> > 
> > > If you really want to workaround the issue, I prefer have a blacklist or
> > > something to let ACPI not use the _CID for your device, but please don't
> > > mess the ACPI core itself.
> > 
> > My fist pass to fix the problem was I guess a hack of sorts that caused
> > others problems (motherboard add return != 0 on unknown devices).  I
> > don't want another Keith grown hack that breaks other people. 
> > 
> > Can you elaborate on what you think would be safe way to do what you
> > propose since the ACPI core (can't/won't?) be fixed? I can imagine a
> > couple of different ways to fix this but I would like some feedback
> > before I go off and work on the 3rd pass of this fix. 

Ok off I went.... 

> > 1.  Make the memory device get scanned before the motherboard device
> > somehow.  Implicitly reorder the devices in the list. Perhaps a priority
> > sorted of sorts to have _HID device always before _CID devices during
> > the scan? 
> This will change the scan order of ACPI device, and sounds too hack to me.

  ACPI driver only has name with no _HID _CID contest.  The handle reads
the name space to fill in the device.    There is no way to explicitly
order the list correctly for all cases as we are trying to reorder the
driver list.
  
  I looked into making the memory device dynamically change itself to
not contain a _CID (thus changing the namespace) but it got pretty ugly.
This is perhaps doable but a little on the ugly side.  

  So I just flip the order of the device list for all cases in a simple
patch.  This is a total hack and workaround for just my current
situation.   


> > 3.  Some special blacklist of the motherboard device on my specific
> > system. 

Uhh this looks to require a whole new black list infrastructure?

Any more ideas????

Thanks,
  Keith 

Signed-off-by: Keith Mannthey <kmannth@us.ibm.com>


[-- Attachment #2: patch-acpi-scanfix-v2 --]
[-- Type: text/plain, Size: 396 bytes --]

--- linux-2.6.17/drivers/acpi/scan.c	2006-09-20 13:58:06.000000000 -0700
+++ linux-2.6.18-rc6-mm2-works/drivers/acpi/scan.c	2006-09-20 11:31:33.000000000 -0700
@@ -601,7 +601,7 @@
 		return -ENODEV;
 
 	spin_lock(&acpi_device_lock);
-	list_add_tail(&driver->node, &acpi_bus_drivers);
+	list_add(&driver->node, &acpi_bus_drivers);
 	spin_unlock(&acpi_device_lock);
 	acpi_driver_attach(driver);
 

RE: one more ACPI Error (utglobal-0125): Unknown exception code:0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

[Moore, Robert]

Return AE_OK to continue the walk. AE_CTRL_DEPTH will cause the walk to
continue, but go no further down the current branch of the namespace.

Anything other than these two exceptions will completely abort the walk.

Bob


> -----Original Message-----
> From: keith mannthey [mailto:kmannth@us.ibm.com]
> Sent: Thursday, August 31, 2006 9:49 AM
> To: Len Brown
> Cc: Moore, Robert; Li, Shaohua; Mattia Dongili; Andrew Morton; lkml;
linux
> acpi; KAMEZAWA Hiroyuki
> Subject: Re: one more ACPI Error (utglobal-0125): Unknown exception
> code:0xFFFFFFEA [Re: 2.6.18-rc4-mm3]
> 
> On Thu, 2006-08-31 at 02:48 -0400, Len Brown wrote:
> > On Tuesday 29 August 2006 16:04, Moore, Robert wrote:
> > > As far as the unknown exception,
> > >
> > > >[    9.392729]  [<c0246fb6>] acpi_ut_status_exit+0x31/0x5e
> > > >[    9.393453]  [<c0243352>] acpi_walk_resources+0x10e/0x11b
> > > >[    9.394174]  [<c025697e>] acpi_motherboard_add+0x22/0x31
> > >
> > > I would guess that the callback routine for walk_resources is
> returning
> > > a non-zero status value which is causing an immediate abort of the
> walk
> > > with that value -- and the value is bogus.
> 
>   Before I put this check in acpi_motherboard_add always attached
itself
> to any resource type. I simply changed it so if the type is not
> ACPI_RESOURCE_TYPE_IO or ACPI_RESOURCE_TYPE_FIXED_IO it doesn't attach
> and can continue to find the correct device to attach to.
> 
>   Perhaps the motherboard device needs to attach to more device types?
> 
>   It was suggest by acpi folks to return -EINVAL.  Should something
else
> be returned?
> 
> 
> Thanks,
>   Keith
> 
> > Yep, see -EINVAL below.
> >
> > -Len
> >
> >
http://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-
> rc4/2.6.18-rc4-mm3/broken-out/hot-add-mem-x86_64-acpi-motherboard-
> fix.patch
> >
> >
> >
> > From: Keith Mannthey <kmannth@us.ibm.com>
> >
> > This patch set allow SPARSEMEM and RESERVE based hot-add to work.  I
> have
> > test both options and they work as expected.  I am adding memory to
the
> > 2nd node of a numa system (x86_64).
> >
> > Major changes from last set is the config change and RESERVE
enablment.
> >
> >
> > This patch:
> >
> >
> > Make ACPI motherboard driver not attach to devices/handles it
dosen't
> expect.
> > Fix a bug where the motherboard driver attached to hot-add memory
event
> and
> > caused the add memory call to fail.
> >
> > Signed-off-by: Keith Mannthey<kmannth@us.ibm.com>
> > Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
> > Cc: Andi Kleen <ak@muc.de>
> > Signed-off-by: Andrew Morton <akpm@osdl.org>
> > ---
> >
> >
> > diff -puN drivers/acpi/motherboard.c~hot-add-mem-x86_64-acpi-
> motherboard-fix drivers/acpi/motherboard.c
> > ---
a/drivers/acpi/motherboard.c~hot-add-mem-x86_64-acpi-motherboard-fix
> > +++ a/drivers/acpi/motherboard.c
> > @@ -87,6 +87,7 @@ static acpi_status acpi_reserve_io_range
> >  		}
> >  	} else {
> >  		/* Memory mapped IO? */
> > +		 return -EINVAL;
> >  	}
> >
> >  	if (requested_res)
> > @@ -96,11 +97,16 @@ static acpi_status acpi_reserve_io_range
> >
> >  static int acpi_motherboard_add(struct acpi_device *device)
> >  {
> > +	acpi_status status;
> >  	if (!device)
> >  		return -EINVAL;
> > -	acpi_walk_resources(device->handle, METHOD_NAME__CRS,
> > +
> > +	status = acpi_walk_resources(device->handle, METHOD_NAME__CRS,
> >  			    acpi_reserve_io_ranges, NULL);
> >
> > +	if (ACPI_FAILURE(status))
> > +		return -ENODEV;
> > +
> >  	return 0;
> >  }
> >
> > _

RE: one more ACPI Error (utglobal-0125): Unknown exception code:0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

[keith mannthey]

On Thu, 2006-08-31 at 10:02 -0700, Moore, Robert wrote: 
> Return AE_OK to continue the walk. AE_CTRL_DEPTH will cause the walk to
> continue, but go no further down the current branch of the namespace.
> 
> Anything other than these two exceptions will completely abort the walk.

Let me check with AE_OK (this is non-zero?).  It will be several hours. 

Thanks,
  Keith 


> > -----Original Message-----
> > From: keith mannthey [mailto:kmannth@us.ibm.com]
> > Sent: Thursday, August 31, 2006 9:49 AM
> > To: Len Brown
> > Cc: Moore, Robert; Li, Shaohua; Mattia Dongili; Andrew Morton; lkml;
> linux
> > acpi; KAMEZAWA Hiroyuki
> > Subject: Re: one more ACPI Error (utglobal-0125): Unknown exception
> > code:0xFFFFFFEA [Re: 2.6.18-rc4-mm3]
> > 
> > On Thu, 2006-08-31 at 02:48 -0400, Len Brown wrote:
> > > On Tuesday 29 August 2006 16:04, Moore, Robert wrote:
> > > > As far as the unknown exception,
> > > >
> > > > >[    9.392729]  [<c0246fb6>] acpi_ut_status_exit+0x31/0x5e
> > > > >[    9.393453]  [<c0243352>] acpi_walk_resources+0x10e/0x11b
> > > > >[    9.394174]  [<c025697e>] acpi_motherboard_add+0x22/0x31
> > > >
> > > > I would guess that the callback routine for walk_resources is
> > returning
> > > > a non-zero status value which is causing an immediate abort of the
> > walk
> > > > with that value -- and the value is bogus.
> > 
> >   Before I put this check in acpi_motherboard_add always attached
> itself
> > to any resource type. I simply changed it so if the type is not
> > ACPI_RESOURCE_TYPE_IO or ACPI_RESOURCE_TYPE_FIXED_IO it doesn't attach
> > and can continue to find the correct device to attach to.
> > 
> >   Perhaps the motherboard device needs to attach to more device types?
> > 
> >   It was suggest by acpi folks to return -EINVAL.  Should something
> else
> > be returned?
> > 
> > 
> > Thanks,
> >   Keith
> > 
> > > Yep, see -EINVAL below.
> > >
> > > -Len
> > >
> > >
> http://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-
> > rc4/2.6.18-rc4-mm3/broken-out/hot-add-mem-x86_64-acpi-motherboard-
> > fix.patch
> > >
> > >
> > >
> > > From: Keith Mannthey <kmannth@us.ibm.com>
> > >
> > > This patch set allow SPARSEMEM and RESERVE based hot-add to work.  I
> > have
> > > test both options and they work as expected.  I am adding memory to
> the
> > > 2nd node of a numa system (x86_64).
> > >
> > > Major changes from last set is the config change and RESERVE
> enablment.
> > >
> > >
> > > This patch:
> > >
> > >
> > > Make ACPI motherboard driver not attach to devices/handles it
> dosen't
> > expect.
> > > Fix a bug where the motherboard driver attached to hot-add memory
> event
> > and
> > > caused the add memory call to fail.
> > >
> > > Signed-off-by: Keith Mannthey<kmannth@us.ibm.com>
> > > Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
> > > Cc: Andi Kleen <ak@muc.de>
> > > Signed-off-by: Andrew Morton <akpm@osdl.org>
> > > ---
> > >
> > >
> > > diff -puN drivers/acpi/motherboard.c~hot-add-mem-x86_64-acpi-
> > motherboard-fix drivers/acpi/motherboard.c
> > > ---
> a/drivers/acpi/motherboard.c~hot-add-mem-x86_64-acpi-motherboard-fix
> > > +++ a/drivers/acpi/motherboard.c
> > > @@ -87,6 +87,7 @@ static acpi_status acpi_reserve_io_range
> > >  		}
> > >  	} else {
> > >  		/* Memory mapped IO? */
> > > +		 return -EINVAL;
> > >  	}
> > >
> > >  	if (requested_res)
> > > @@ -96,11 +97,16 @@ static acpi_status acpi_reserve_io_range
> > >
> > >  static int acpi_motherboard_add(struct acpi_device *device)
> > >  {
> > > +	acpi_status status;
> > >  	if (!device)
> > >  		return -EINVAL;
> > > -	acpi_walk_resources(device->handle, METHOD_NAME__CRS,
> > > +
> > > +	status = acpi_walk_resources(device->handle, METHOD_NAME__CRS,
> > >  			    acpi_reserve_io_ranges, NULL);
> > >
> > > +	if (ACPI_FAILURE(status))
> > > +		return -ENODEV;
> > > +
> > >  	return 0;
> > >  }
> > >
> > > _

RE: one more ACPI Error (utglobal-0125): Unknown exception code: 0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

[Moore, Robert]

As far as the unknown exception,

>[    9.392729]  [<c0246fb6>] acpi_ut_status_exit+0x31/0x5e
>[    9.393453]  [<c0243352>] acpi_walk_resources+0x10e/0x11b
>[    9.394174]  [<c025697e>] acpi_motherboard_add+0x22/0x31

I would guess that the callback routine for walk_resources is returning
a non-zero status value which is causing an immediate abort of the walk
with that value -- and the value is bogus.

Bob


> -----Original Message-----
> From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-
> owner@vger.kernel.org] On Behalf Of Li, Shaohua
> Sent: Monday, August 28, 2006 7:06 PM
> To: Mattia Dongili; Andrew Morton
> Cc: linux-kernel@vger.kernel.org; linux-acpi@vger.kernel.org
> Subject: RE: one more ACPI Error (utglobal-0125): Unknown exception
code:
> 0xFFFFFFEA [Re: 2.6.18-rc4-mm3]
> 
> 
> 
> >-----Original Message-----
> >From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-
> >owner@vger.kernel.org] On Behalf Of Mattia Dongili
> >Sent: Tuesday, August 29, 2006 4:24 AM
> >To: Andrew Morton
> >Cc: linux-kernel@vger.kernel.org; linux-acpi@vger.kernel.org
> >Subject: one more ACPI Error (utglobal-0125): Unknown exception code:
> >0xFFFFFFEA [Re: 2.6.18-rc4-mm3]
> >
> >On Sat, Aug 26, 2006 at 04:09:22PM -0700, Andrew Morton wrote:
> >>
> >>
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-
> >rc4/2.6.18-rc4-mm3/
> >[...]
> >>  git-acpi.patch
> >
> >Sorry for reporting separately, I deleted the other thread on the
> issue.
> >Here we go:
> >[    9.386644] PCI: Using ACPI for IRQ routing
> >[    9.386688] PCI: If a device doesn't work, try "pci=routeirq".  If
> it
> >helps, post a report
> >[    9.391209] ACPI Error (utglobal-0125): Unknown exception code:
> >0xFFFFFFEA [20060707]
> >[    9.391521]  [<c0103a9f>] dump_trace+0x1ef/0x230
> >[    9.391626]  [<c0103b06>] show_trace_log_lvl+0x26/0x40
> >[    9.391724]  [<c01042bb>] show_trace+0x1b/0x20
> >[    9.391820]  [<c01043a4>] dump_stack+0x24/0x30
> >[    9.391918]  [<c0249f15>] acpi_format_exception+0xa3/0xb0
> >[    9.392729]  [<c0246fb6>] acpi_ut_status_exit+0x31/0x5e
> >[    9.393453]  [<c0243352>] acpi_walk_resources+0x10e/0x11b
> >[    9.394174]  [<c025697e>] acpi_motherboard_add+0x22/0x31
> >[    9.394977]  [<c0255890>] acpi_bus_driver_init+0x2b/0x7c
> >[    9.395742]  [<c02568da>] acpi_bus_register_driver+0xa1/0x123
> >[    9.396507]  [<c0418adb>] acpi_motherboard_init+0x17/0xfb
> >[    9.397268]  [<c01003d0>] init+0x80/0x290
> >[    9.397343]  [<c0103593>] kernel_thread_helper+0x7/0x14
> >[    9.397439]  =======================
> >
> >full dmesg: http://oioio.altervista.org/linux/dmesg-2.6.18-rc4-mm3-1
> >config: http://oioio.altervista.org/linux/config-2.6.18-rc4-mm3-1
> >DSDT: http://oioio.altervista.org/linux/DSDT.aml
> >      http://oioio.altervista.org/linux/DSDT.dsl
> >lspci: http://oioio.altervista.org/linux/lspci-v
> Below patch is the root cause.
>
http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc
>
4/2.6.18-rc4-mm3/broken-out/hot-add-mem-x86_64-acpi-motherboard-fix.patc
> h
> 
> motherboard driver is expected to reserve resources used by
motherboard,
> so hotplug will not fail. I don't know why memory hotplug guys change
> it.
> 
> Thanks,
> Shaohua
> -
> To unsubscribe from this list: send the line "unsubscribe linux-acpi"
in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: one more ACPI Error (utglobal-0125): Unknown exception code: 0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

[Len Brown]

On Tuesday 29 August 2006 16:04, Moore, Robert wrote:
> As far as the unknown exception,
> 
> >[    9.392729]  [<c0246fb6>] acpi_ut_status_exit+0x31/0x5e
> >[    9.393453]  [<c0243352>] acpi_walk_resources+0x10e/0x11b
> >[    9.394174]  [<c025697e>] acpi_motherboard_add+0x22/0x31
> 
> I would guess that the callback routine for walk_resources is returning
> a non-zero status value which is causing an immediate abort of the walk
> with that value -- and the value is bogus.

Yep, see -EINVAL below.

-Len

http://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm3/broken-out/hot-add-mem-x86_64-acpi-motherboard-fix.patch



From: Keith Mannthey <kmannth@us.ibm.com>

This patch set allow SPARSEMEM and RESERVE based hot-add to work.  I have
test both options and they work as expected.  I am adding memory to the
2nd node of a numa system (x86_64).

Major changes from last set is the config change and RESERVE enablment.


This patch:


Make ACPI motherboard driver not attach to devices/handles it dosen't expect.
Fix a bug where the motherboard driver attached to hot-add memory event and
caused the add memory call to fail.

Signed-off-by: Keith Mannthey<kmannth@us.ibm.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Andi Kleen <ak@muc.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---


diff -puN drivers/acpi/motherboard.c~hot-add-mem-x86_64-acpi-motherboard-fix drivers/acpi/motherboard.c
--- a/drivers/acpi/motherboard.c~hot-add-mem-x86_64-acpi-motherboard-fix
+++ a/drivers/acpi/motherboard.c
@@ -87,6 +87,7 @@ static acpi_status acpi_reserve_io_range
 		}
 	} else {
 		/* Memory mapped IO? */
+		 return -EINVAL;
 	}
 
 	if (requested_res)
@@ -96,11 +97,16 @@ static acpi_status acpi_reserve_io_range
 
 static int acpi_motherboard_add(struct acpi_device *device)
 {
+	acpi_status status;
 	if (!device)
 		return -EINVAL;
-	acpi_walk_resources(device->handle, METHOD_NAME__CRS,
+
+	status = acpi_walk_resources(device->handle, METHOD_NAME__CRS,
 			    acpi_reserve_io_ranges, NULL);
 
+	if (ACPI_FAILURE(status))
+		return -ENODEV;
+
 	return 0;
 }
 
_

Re: one more ACPI Error (utglobal-0125): Unknown exception code: 0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

[keith mannthey]

On Thu, 2006-08-31 at 02:48 -0400, Len Brown wrote:
> On Tuesday 29 August 2006 16:04, Moore, Robert wrote:
> > As far as the unknown exception,
> > 
> > >[    9.392729]  [<c0246fb6>] acpi_ut_status_exit+0x31/0x5e
> > >[    9.393453]  [<c0243352>] acpi_walk_resources+0x10e/0x11b
> > >[    9.394174]  [<c025697e>] acpi_motherboard_add+0x22/0x31
> > 
> > I would guess that the callback routine for walk_resources is returning
> > a non-zero status value which is causing an immediate abort of the walk
> > with that value -- and the value is bogus.

  Before I put this check in acpi_motherboard_add always attached itself
to any resource type. I simply changed it so if the type is not
ACPI_RESOURCE_TYPE_IO or ACPI_RESOURCE_TYPE_FIXED_IO it doesn't attach
and can continue to find the correct device to attach to.

  Perhaps the motherboard device needs to attach to more device types?  

  It was suggest by acpi folks to return -EINVAL.  Should something else
be returned? 
 

Thanks,
  Keith 

> Yep, see -EINVAL below.
> 
> -Len
> 
> http://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm3/broken-out/hot-add-mem-x86_64-acpi-motherboard-fix.patch
> 
> 
> 
> From: Keith Mannthey <kmannth@us.ibm.com>
> 
> This patch set allow SPARSEMEM and RESERVE based hot-add to work.  I have
> test both options and they work as expected.  I am adding memory to the
> 2nd node of a numa system (x86_64).
> 
> Major changes from last set is the config change and RESERVE enablment.
> 
> 
> This patch:
> 
> 
> Make ACPI motherboard driver not attach to devices/handles it dosen't expect.
> Fix a bug where the motherboard driver attached to hot-add memory event and
> caused the add memory call to fail.
> 
> Signed-off-by: Keith Mannthey<kmannth@us.ibm.com>
> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
> Cc: Andi Kleen <ak@muc.de>
> Signed-off-by: Andrew Morton <akpm@osdl.org>
> ---
> 
> 
> diff -puN drivers/acpi/motherboard.c~hot-add-mem-x86_64-acpi-motherboard-fix drivers/acpi/motherboard.c
> --- a/drivers/acpi/motherboard.c~hot-add-mem-x86_64-acpi-motherboard-fix
> +++ a/drivers/acpi/motherboard.c
> @@ -87,6 +87,7 @@ static acpi_status acpi_reserve_io_range
>  		}
>  	} else {
>  		/* Memory mapped IO? */
> +		 return -EINVAL;
>  	}
>  
>  	if (requested_res)
> @@ -96,11 +97,16 @@ static acpi_status acpi_reserve_io_range
>  
>  static int acpi_motherboard_add(struct acpi_device *device)
>  {
> +	acpi_status status;
>  	if (!device)
>  		return -EINVAL;
> -	acpi_walk_resources(device->handle, METHOD_NAME__CRS,
> +
> +	status = acpi_walk_resources(device->handle, METHOD_NAME__CRS,
>  			    acpi_reserve_io_ranges, NULL);
>  
> +	if (ACPI_FAILURE(status))
> +		return -ENODEV;
> +
>  	return 0;
>  }
>  
> _

Re: one more ACPI Error (utglobal-0125): Unknown exception code: 0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

[Bjorn Helgaas]

On Thursday 31 August 2006 10:48, keith mannthey wrote:
> On Thu, 2006-08-31 at 02:48 -0400, Len Brown wrote:
> > On Tuesday 29 August 2006 16:04, Moore, Robert wrote:
> > > As far as the unknown exception,
> > > 
> > > >[    9.392729]  [<c0246fb6>] acpi_ut_status_exit+0x31/0x5e
> > > >[    9.393453]  [<c0243352>] acpi_walk_resources+0x10e/0x11b
> > > >[    9.394174]  [<c025697e>] acpi_motherboard_add+0x22/0x31
> > > 
> > > I would guess that the callback routine for walk_resources is returning
> > > a non-zero status value which is causing an immediate abort of the walk
> > > with that value -- and the value is bogus.
> 
>   Before I put this check in acpi_motherboard_add always attached itself
> to any resource type. I simply changed it so if the type is not
> ACPI_RESOURCE_TYPE_IO or ACPI_RESOURCE_TYPE_FIXED_IO it doesn't attach
> and can continue to find the correct device to attach to.
> 
>   Perhaps the motherboard device needs to attach to more device types?  
> 
>   It was suggest by acpi folks to return -EINVAL.  Should something else
> be returned? 

Problem 1: acpi_reserve_io_ranges() needs to return an acpi_status
like AE_OK or AE_CTRL_TERMINATE, not a -EINVAL.

Problem 2: I don't understand how your patch works.  An ACPI device
has a list of resources it uses.  Are you saying that claiming all
the IO port resources of a PNP0C01 or PNP0C02 device causes the ACPI
memory hotplug driver to fail?

Is there some conflict between those PNP0C01 resources and the
resources of a hotplug memory device?  Can you figure out exactly
what the conflict is by disassembling the DSDT for those devices?

We should understand this better before introducing special cases
to the motherboard driver.  We should be able to trust the ACPI
description of the motherboard resources.  The motherboard driver
currently claims only I/O port resources, but it really should
claim MMIO resources as well.

> > http://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm3/broken-out/hot-add-mem-x86_64-acpi-motherboard-fix.patch
> > 
> > From: Keith Mannthey <kmannth@us.ibm.com>
> > ...
> > Make ACPI motherboard driver not attach to devices/handles it dosen't expect.
> > Fix a bug where the motherboard driver attached to hot-add memory event and
> > caused the add memory call to fail.
> > 
> > Signed-off-by: Keith Mannthey<kmannth@us.ibm.com>
> > Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
> > Cc: Andi Kleen <ak@muc.de>
> > Signed-off-by: Andrew Morton <akpm@osdl.org>
> > ---
> > diff -puN drivers/acpi/motherboard.c~hot-add-mem-x86_64-acpi-motherboard-fix drivers/acpi/motherboard.c
> > --- a/drivers/acpi/motherboard.c~hot-add-mem-x86_64-acpi-motherboard-fix
> > +++ a/drivers/acpi/motherboard.c
> > @@ -87,6 +87,7 @@ static acpi_status acpi_reserve_io_range
> >  		}
> >  	} else {
> >  		/* Memory mapped IO? */
> > +		 return -EINVAL;
> >  	}
> >  
> >  	if (requested_res)
> > @@ -96,11 +97,16 @@ static acpi_status acpi_reserve_io_range
> >  
> >  static int acpi_motherboard_add(struct acpi_device *device)
> >  {
> > +	acpi_status status;
> >  	if (!device)
> >  		return -EINVAL;
> > -	acpi_walk_resources(device->handle, METHOD_NAME__CRS,
> > +
> > +	status = acpi_walk_resources(device->handle, METHOD_NAME__CRS,
> >  			    acpi_reserve_io_ranges, NULL);
> >  
> > +	if (ACPI_FAILURE(status))
> > +		return -ENODEV;
> > +
> >  	return 0;
> >  }

Re: one more ACPI Error (utglobal-0125): Unknown exception code:0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

[Shaohua Li]

On Fri, 2006-09-01 at 09:19 +0800, keith mannthey wrote:
> On Thu, 2006-08-31 at 17:06 -0600, Bjorn Helgaas wrote: 
> > On Thursday 31 August 2006 10:48, keith mannthey wrote: 
> > > On Thu, 2006-08-31 at 02:48 -0400, Len Brown wrote: 
> > > > On Tuesday 29 August 2006 16:04, Moore, Robert wrote: 
> > > > > As far as the unknown exception, 
> > > > >  
> > > > > >[    9.392729]  [<c0246fb6>] acpi_ut_status_exit+0x31/0x5e 
> > > > > >[    9.393453]  [<c0243352>] acpi_walk_resources+0x10e/0x11b 
> > > > > >[    9.394174]  [<c025697e>] acpi_motherboard_add+0x22/0x31 
> > > > >  
> > > > > I would guess that the callback routine for walk_resources is
> returning 
> > > > > a non-zero status value which is causing an immediate abort of
> the walk 
> > > > > with that value -- and the value is bogus. 
> > >  
> > >   Before I put this check in acpi_motherboard_add always attached
> itself 
> > > to any resource type. I simply changed it so if the type is not 
> > > ACPI_RESOURCE_TYPE_IO or ACPI_RESOURCE_TYPE_FIXED_IO it doesn't
> attach 
> > > and can continue to find the correct device to attach to. 
> > >  
> > >   Perhaps the motherboard device needs to attach to more device
> types?   
> > >  
> > >   It was suggest by acpi folks to return -EINVAL.  Should
> something else 
> > > be returned?  
> >  
> > Problem 1: acpi_reserve_io_ranges() needs to return an acpi_status 
> > like AE_OK or AE_CTRL_TERMINATE, not a -EINVAL.
> 
> Sure great sounds.  I understand AE_OK is a 0 return so I can change
> it 
> to AE_CTRL_TERMINATE.  I don't want  acpi_reserve_io_ranges to return
> a 
> happy state when if finds a resource type is doesn't know.   
>   
> > Problem 2: I don't understand how your patch works.  An ACPI device 
> > has a list of resources it uses.  Are you saying that claiming all 
> > the IO port resources of a PNP0C01 or PNP0C02 device causes the
> ACPI 
> > memory hotplug driver to fail? 
> >  
>   I don't know a whole heck of a lot about ACPI but let me try and 
> explain the situation as best I can. I will attach my SSDT as well. 
> Memory devices are PNP0C80. 
> 
>    What the acpi_memory_device_driver is loaded in the system and you
> do 
> a hot-add event the following call path takes place...
> 
> acpi_memory_get_device 
>   acpi_bus_add 
>     acpi_add_single_object 
>       acpi_bus_find_driver 
>         acpi_bus_driver_init 
>           driver->ops.add
> 
>   The problem is the motherboard driver driver->ops.add is called
> before 
> my memory device is scanned and it ALWASY returns AE_OK. Such that
> the 
> device that is passed back up to that acpi_memory_get_device is NOT
> the 
> memory_device_driver but this motherboard device and the add fails 
> bigtime.  I need acpi_find_bus_driver to return to me the 
> acpi_memory_device_driver not the motherboard driver.  
> 
>   It seems pretty sane to be to have the add 
> 
> > Is there some conflict between those PNP0C01 resources and the 
> > resources of a hotplug memory device?  Can you figure out exactly 
> > what the conflict is by disassembling the DSDT for those devices?
> 
> Kame (who helped me greatly in tracking down the source my troubles) 
> thinks that the root cause is that the device (my memory_device) has 
> both a _HID and _CID. The driver for _HID is different for _CID and
> the 
> driver for _CID is found before _HID and I pass the wrong device up
> the 
> chain. 
> 
> > We should understand this better before introducing special cases 
> > to the motherboard driver.  We should be able to trust the ACPI 
> > description of the motherboard resources.  The motherboard driver 
> > currently claims only I/O port resources, but it really should 
> > claim MMIO resources as well.
> 
> The design of my patch is to make the motherboard driver return 
> something other than 0 when it's driver->ops.add is called with
> resource 
> types that are not what it expects.  
> 
> This way the scan if acpi_bus_find_driver will fine the correct acpi 
> device. 
> 
> Also see   
> http://sourceforge.net/mailarchive/forum.php? 
> thread_id=15282420&forum_id=223
> 
> I don't claim this is the ACPI correct solution and am welcome to any 
> input that fixes my issue: acpi_bus_find_driver returning the
> incorrect 
> driver for a given handle.    
Then the issue is your device _CID returned PNP0C01 or PNP0C02. Is this
intended? Can we change the BIOS?

Thanks,
Shaohua

Re: one more ACPI Error (utglobal-0125): Unknown exception code:0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

[keith mannthey]

> > Also see   
> > http://sourceforge.net/mailarchive/forum.php? 
> > thread_id=15282420&forum_id=223
> > 
> > I don't claim this is the ACPI correct solution and am welcome to any 
> > input that fixes my issue: acpi_bus_find_driver returning the
> > incorrect 
> > driver for a given handle.    
> Then the issue is your device _CID returned PNP0C01 or PNP0C02. Is this
> intended? Can we change the BIOS?

  The spec talks about _HID for the memory device and that is ok but I
don't see any reference to required _CID. My _CID is listed as hex.  Can
I just convert it?

 Changing the bios is a little bit of a long shot at this point. 

Thanks,
  Keith 

Re: one more ACPI Error (utglobal-0125): Unknown exception code: 0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

[Bjorn Helgaas]

> On Thu, 2006-08-31 at 17:06 -0600, Bjorn Helgaas wrote:
>> Problem 1: acpi_reserve_io_ranges() needs to return an acpi_status
>> like AE_OK or AE_CTRL_TERMINATE, not a -EINVAL.
>
> Sure great sounds.  I understand AE_OK is a 0 return so I can change it
> to AE_CTRL_TERMINATE.  I don't want  acpi_reserve_io_ranges to return a
> happy state when if finds a resource type is doesn't know.

Except that when the motherboard driver claims a device, it really
should claim all the resources used by the device.  It currently only
claims I/O port resources, but I think it should also claim MMIO
resources.  Otherwise, the system resource accounting is screwed up,
and resources consumed by the motherboard device could be mistakenly
allocated to another device.

> Kame (who helped me greatly in tracking down the source my troubles)
> thinks that the root cause is that the device (my memory_device) has
> both a _HID and _CID. The driver for _HID is different for _CID and the
> driver for _CID is found before _HID and I pass the wrong device up the
> chain.

Ok, this is starting to make sense.  It sounds like your memory
device has _HID of PNP0C80 and _CID of PNP0C01 (or PNP0C02).

The current ACPI driver binding algorithm in acpi_bus_find_driver()
looks at each driver, checking whether it can match either the _HID
or the _CID of a device.  Since we try the motherboard driver first,
it matches the memory device _CID.

I couldn't find a specific reference in the spec, but this seems
intuitively sub-optimal.  It seems like it'd be better to look
first for a driver that can claim the _HID (which is more specific),
and only fall back to checking the _CIDs if no _HID-specific driver
is found.

This looks fairly easy to do in ACPI.  Not so easy in PNPACPI,
since I don't think PNP has the concept of _HID vs _CID.  Maybe
Len will chime in with an opinion.

Bjorn

Re: one more ACPI Error (utglobal-0125): Unknown exception code: 0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

[KAMEZAWA Hiroyuki]

On Thu, 31 Aug 2006 21:15:55 -0600 (MDT)
"Bjorn Helgaas" <bjorn.helgaas@hp.com> wrote:

> Ok, this is starting to make sense.  It sounds like your memory
> device has _HID of PNP0C80 and _CID of PNP0C01 (or PNP0C02).
> 
> The current ACPI driver binding algorithm in acpi_bus_find_driver()
> looks at each driver, checking whether it can match either the _HID
> or the _CID of a device.  Since we try the motherboard driver first,
> it matches the memory device _CID.
> 
> I couldn't find a specific reference in the spec, but this seems
> intuitively sub-optimal.  It seems like it'd be better to look
> first for a driver that can claim the _HID (which is more specific),
> and only fall back to checking the _CIDs if no _HID-specific driver
> is found.
> 
I like it :)

-Kame

Re: one more ACPI Error (utglobal-0125): Unknown exception code: 0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

[keith mannthey]

On Thu, 2006-08-31 at 21:15 -0600, Bjorn Helgaas wrote:
> > On Thu, 2006-08-31 at 17:06 -0600, Bjorn Helgaas wrote:
> >> Problem 1: acpi_reserve_io_ranges() needs to return an acpi_status
> >> like AE_OK or AE_CTRL_TERMINATE, not a -EINVAL.
> >
> > Sure great sounds.  I understand AE_OK is a 0 return so I can change it
> > to AE_CTRL_TERMINATE.  I don't want  acpi_reserve_io_ranges to return a
> > happy state when if finds a resource type is doesn't know.
> 
> Except that when the motherboard driver claims a device, it really
> should claim all the resources used by the device.  It currently only
> claims I/O port resources, but I think it should also claim MMIO
> resources.  Otherwise, the system resource accounting is screwed up,
> and resources consumed by the motherboard device could be mistakenly
> allocated to another device.
> 
> > Kame (who helped me greatly in tracking down the source my troubles)
> > thinks that the root cause is that the device (my memory_device) has
> > both a _HID and _CID. The driver for _HID is different for _CID and the
> > driver for _CID is found before _HID and I pass the wrong device up the
> > chain.
> 
> Ok, this is starting to make sense.  It sounds like your memory
> device has _HID of PNP0C80 and _CID of PNP0C01 (or PNP0C02).
> 
> The current ACPI driver binding algorithm in acpi_bus_find_driver()
> looks at each driver, checking whether it can match either the _HID
> or the _CID of a device.  Since we try the motherboard driver first,
> it matches the memory device _CID.

Ok I reverted the motherboard driver patch and cooked up the following
patch that works for my issue.  

  It creates the idea that acpi_match_ids has a type of request to check
against for _HID, _CID or both.  See acpi_bus_match_req. I then fix up
all the needed callers to change the API to acpi_match_ids and
acpi_bus_match and have callers can say what they want to match
against. 
  
  Then in acpi_bus_find_driver I have it do 2 passes to search for _HID
first then the _CID.  

Does this look like it is in the right ballpark or should we be doing
something else?  Built/tested against 2.6.18-rc4-mm3. 

Signed-off-by: Keith Mannthey <kmannth@us.ibm.com>


diff -urN linux-2.6.17-orig/drivers/acpi/scan.c linux-2.6.17/drivers/acpi/scan.c
--- linux-2.6.17-orig/drivers/acpi/scan.c	2006-09-01 17:11:37.000000000 -0400
+++ linux-2.6.17/drivers/acpi/scan.c	2006-09-01 18:13:53.000000000 -0400
@@ -235,13 +235,13 @@
 	return 0;
 }
 
-int acpi_match_ids(struct acpi_device *device, char *ids)
+int acpi_match_ids(struct acpi_device *device, char *ids, int type)
 {
-	if (device->flags.hardware_id)
+	if ((device->flags.hardware_id) && (type != ACPI_BUS_MATCH_CID))
 		if (strstr(ids, device->pnp.hardware_id))
 			return 0;
 
-	if (device->flags.compatible_ids) {
+	if ((device->flags.compatible_ids) && (type != ACPI_BUS_MATCH_HID)) {
 		struct acpi_compatible_id_list *cid_list = device->pnp.cid_list;
 		int i;
 
@@ -329,7 +329,8 @@
 
 	device->wakeup.flags.valid = 1;
 	/* Power button, Lid switch always enable wakeup */
-	if (!acpi_match_ids(device, "PNP0C0D,PNP0C0C,PNP0C0E"))
+	if (!acpi_match_ids(device, "PNP0C0D,PNP0C0C,PNP0C0E", 
+							ACPI_BUS_MATCH_ALL))
 		device->wakeup.flags.run_wake = 1;
 
       end:
@@ -471,11 +472,11 @@
  * matches the specified driver's criteria.
  */
 static int
-acpi_bus_match(struct acpi_device *device, struct acpi_driver *driver)
+acpi_bus_match(struct acpi_device *device, struct acpi_driver *driver, int type)
 {
 	if (driver && driver->ops.match)
 		return driver->ops.match(device, driver);
-	return acpi_match_ids(device, driver->ids);
+	return acpi_match_ids(device, driver->ids, type);
 }
 
 /**
@@ -549,7 +550,7 @@
 			continue;
 		spin_unlock(&acpi_device_lock);
 
-		if (!acpi_bus_match(dev, drv)) {
+		if (!acpi_bus_match(dev, drv, ACPI_BUS_MATCH_ALL)) {
 			if (!acpi_bus_driver_init(dev, drv)) {
 				acpi_start_single_object(dev);
 				atomic_inc(&drv->references);
@@ -651,7 +652,22 @@
 
 		atomic_inc(&driver->references);
 		spin_unlock(&acpi_device_lock);
-		if (!acpi_bus_match(device, driver)) {
+		if (!acpi_bus_match(device, driver, ACPI_BUS_MATCH_HID)) {
+			result = acpi_bus_driver_init(device, driver);
+			if (!result)
+				goto Done;
+		}
+		atomic_dec(&driver->references);
+		spin_lock(&acpi_device_lock);
+	}
+
+	list_for_each_safe(node, next, &acpi_bus_drivers) {
+		struct acpi_driver *driver =
+		    container_of(node, struct acpi_driver, node);
+
+		atomic_inc(&driver->references);
+		spin_unlock(&acpi_device_lock);
+		if (!acpi_bus_match(device, driver, ACPI_BUS_MATCH_ALL)) {
 			result = acpi_bus_driver_init(device, driver);
 			if (!result)
 				goto Done;
diff -urN linux-2.6.17-orig/drivers/pnp/pnpacpi/core.c linux-2.6.17/drivers/pnp/pnpacpi/core.c
--- linux-2.6.17-orig/drivers/pnp/pnpacpi/core.c	2006-09-01 17:11:37.000000000 -0400
+++ linux-2.6.17/drivers/pnp/pnpacpi/core.c	2006-09-01 18:03:26.000000000 -0400
@@ -41,7 +41,7 @@
 	;
 static inline int is_exclusive_device(struct acpi_device *dev)
 {
-	return (!acpi_match_ids(dev, excluded_id_list));
+	return (!acpi_match_ids(dev, excluded_id_list, ACPI_BUS_MATCH_ALL));
 }
 
 /*
diff -urN linux-2.6.17-orig/include/acpi/acpi_bus.h linux-2.6.17/include/acpi/acpi_bus.h
--- linux-2.6.17-orig/include/acpi/acpi_bus.h	2006-09-01 17:11:38.000000000 -0400
+++ linux-2.6.17/include/acpi/acpi_bus.h	2006-09-01 18:00:27.000000000 -0400
@@ -79,6 +79,12 @@
 	ACPI_BUS_DEVICE_TYPE_COUNT
 };
 
+enum acpi_bus_match_req {
+	ACPI_BUS_MATCH_HID = 0,
+	ACPI_BUS_MATCH_CID,
+	ACPI_BUS_MATCH_ALL
+};
+
 struct acpi_driver;
 struct acpi_device;
 
@@ -335,7 +341,7 @@
 int acpi_bus_trim(struct acpi_device *start, int rmdevice);
 int acpi_bus_start(struct acpi_device *device);
 acpi_status acpi_bus_get_ejd(acpi_handle handle, acpi_handle *ejd);
-int acpi_match_ids(struct acpi_device *device, char *ids);
+int acpi_match_ids(struct acpi_device *device, char *ids, int type);
 int acpi_create_dir(struct acpi_device *);
 void acpi_remove_dir(struct acpi_device *);
 



-- 
VGER BF report: H 0.238464

Re: one more ACPI Error (utglobal-0125): Unknown exception code: 0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

[Bjorn Helgaas]

On Friday 01 September 2006 17:01, keith mannthey wrote:
> On Thu, 2006-08-31 at 21:15 -0600, Bjorn Helgaas wrote:
> > The current ACPI driver binding algorithm in acpi_bus_find_driver()
> > looks at each driver, checking whether it can match either the _HID
> > or the _CID of a device.  Since we try the motherboard driver first,
> > it matches the memory device _CID.
> 
> Ok I reverted the motherboard driver patch and cooked up the following
> patch that works for my issue.  
> 
>   It creates the idea that acpi_match_ids has a type of request to check
> against for _HID, _CID or both.  See acpi_bus_match_req. I then fix up
> all the needed callers to change the API to acpi_match_ids and
> acpi_bus_match and have callers can say what they want to match
> against. 
>   
>   Then in acpi_bus_find_driver I have it do 2 passes to search for _HID
> first then the _CID.  
> 
> Does this look like it is in the right ballpark or should we be doing
> something else?  Built/tested against 2.6.18-rc4-mm3. 

Conceptually I like this much better than mucking with the motherboard
driver.  I'm not sure the important people have signed off on this
strategy of binding with _HID first, then _CID (hi, Len :-))  Maybe
there are ramifications that we need to consider.  But I think it
is a better match for "what people expect should happen."

> Signed-off-by: Keith Mannthey <kmannth@us.ibm.com>
> 
> 
> diff -urN linux-2.6.17-orig/drivers/acpi/scan.c linux-2.6.17/drivers/acpi/scan.c
> --- linux-2.6.17-orig/drivers/acpi/scan.c	2006-09-01 17:11:37.000000000 -0400
> +++ linux-2.6.17/drivers/acpi/scan.c	2006-09-01 18:13:53.000000000 -0400
> @@ -235,13 +235,13 @@
>  	return 0;
>  }
>  
> -int acpi_match_ids(struct acpi_device *device, char *ids)
> +int acpi_match_ids(struct acpi_device *device, char *ids, int type)
>  {
> -	if (device->flags.hardware_id)
> +	if ((device->flags.hardware_id) && (type != ACPI_BUS_MATCH_CID))
>  		if (strstr(ids, device->pnp.hardware_id))
>  			return 0;
>  
> -	if (device->flags.compatible_ids) {
> +	if ((device->flags.compatible_ids) && (type != ACPI_BUS_MATCH_HID)) {
>  		struct acpi_compatible_id_list *cid_list = device->pnp.cid_list;
>  		int i;
>  
> @@ -329,7 +329,8 @@
>  
>  	device->wakeup.flags.valid = 1;
>  	/* Power button, Lid switch always enable wakeup */
> -	if (!acpi_match_ids(device, "PNP0C0D,PNP0C0C,PNP0C0E"))
> +	if (!acpi_match_ids(device, "PNP0C0D,PNP0C0C,PNP0C0E", 
> +							ACPI_BUS_MATCH_ALL))
>  		device->wakeup.flags.run_wake = 1;
>  
>        end:
> @@ -471,11 +472,11 @@
>   * matches the specified driver's criteria.
>   */
>  static int
> -acpi_bus_match(struct acpi_device *device, struct acpi_driver *driver)
> +acpi_bus_match(struct acpi_device *device, struct acpi_driver *driver, int type)
>  {
>  	if (driver && driver->ops.match)
>  		return driver->ops.match(device, driver);
> -	return acpi_match_ids(device, driver->ids);
> +	return acpi_match_ids(device, driver->ids, type);
>  }
>  
>  /**
> @@ -549,7 +550,7 @@
>  			continue;
>  		spin_unlock(&acpi_device_lock);
>  
> -		if (!acpi_bus_match(dev, drv)) {
> +		if (!acpi_bus_match(dev, drv, ACPI_BUS_MATCH_ALL)) {
>  			if (!acpi_bus_driver_init(dev, drv)) {
>  				acpi_start_single_object(dev);
>  				atomic_inc(&drv->references);
> @@ -651,7 +652,22 @@
>  
>  		atomic_inc(&driver->references);
>  		spin_unlock(&acpi_device_lock);
> -		if (!acpi_bus_match(device, driver)) {
> +		if (!acpi_bus_match(device, driver, ACPI_BUS_MATCH_HID)) {
> +			result = acpi_bus_driver_init(device, driver);
> +			if (!result)
> +				goto Done;
> +		}
> +		atomic_dec(&driver->references);
> +		spin_lock(&acpi_device_lock);
> +	}
> +
> +	list_for_each_safe(node, next, &acpi_bus_drivers) {
> +		struct acpi_driver *driver =
> +		    container_of(node, struct acpi_driver, node);
> +
> +		atomic_inc(&driver->references);
> +		spin_unlock(&acpi_device_lock);
> +		if (!acpi_bus_match(device, driver, ACPI_BUS_MATCH_ALL)) {
>  			result = acpi_bus_driver_init(device, driver);
>  			if (!result)
>  				goto Done;
> diff -urN linux-2.6.17-orig/drivers/pnp/pnpacpi/core.c linux-2.6.17/drivers/pnp/pnpacpi/core.c
> --- linux-2.6.17-orig/drivers/pnp/pnpacpi/core.c	2006-09-01 17:11:37.000000000 -0400
> +++ linux-2.6.17/drivers/pnp/pnpacpi/core.c	2006-09-01 18:03:26.000000000 -0400
> @@ -41,7 +41,7 @@
>  	;
>  static inline int is_exclusive_device(struct acpi_device *dev)
>  {
> -	return (!acpi_match_ids(dev, excluded_id_list));
> +	return (!acpi_match_ids(dev, excluded_id_list, ACPI_BUS_MATCH_ALL));
>  }
>  
>  /*
> diff -urN linux-2.6.17-orig/include/acpi/acpi_bus.h linux-2.6.17/include/acpi/acpi_bus.h
> --- linux-2.6.17-orig/include/acpi/acpi_bus.h	2006-09-01 17:11:38.000000000 -0400
> +++ linux-2.6.17/include/acpi/acpi_bus.h	2006-09-01 18:00:27.000000000 -0400
> @@ -79,6 +79,12 @@
>  	ACPI_BUS_DEVICE_TYPE_COUNT
>  };
>  
> +enum acpi_bus_match_req {
> +	ACPI_BUS_MATCH_HID = 0,
> +	ACPI_BUS_MATCH_CID,
> +	ACPI_BUS_MATCH_ALL
> +};
> +
>  struct acpi_driver;
>  struct acpi_device;
>  
> @@ -335,7 +341,7 @@
>  int acpi_bus_trim(struct acpi_device *start, int rmdevice);
>  int acpi_bus_start(struct acpi_device *device);
>  acpi_status acpi_bus_get_ejd(acpi_handle handle, acpi_handle *ejd);
> -int acpi_match_ids(struct acpi_device *device, char *ids);
> +int acpi_match_ids(struct acpi_device *device, char *ids, int type);
>  int acpi_create_dir(struct acpi_device *);
>  void acpi_remove_dir(struct acpi_device *);
>  
> 
> 
> 

-- 
VGER BF report: H 0

Re: one more ACPI Error (utglobal-0125): Unknown exception code: 0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

[keith mannthey]

On Fri, 2006-09-01 at 17:20 -0600, Bjorn Helgaas wrote:
> On Friday 01 September 2006 17:01, keith mannthey wrote:
> > On Thu, 2006-08-31 at 21:15 -0600, Bjorn Helgaas wrote:
> > > The current ACPI driver binding algorithm in acpi_bus_find_driver()
> > > looks at each driver, checking whether it can match either the _HID
> > > or the _CID of a device.  Since we try the motherboard driver first,
> > > it matches the memory device _CID.
> > 
> > Ok I reverted the motherboard driver patch and cooked up the following
> > patch that works for my issue.  
> > 
> >   It creates the idea that acpi_match_ids has a type of request to check
> > against for _HID, _CID or both.  See acpi_bus_match_req. I then fix up
> > all the needed callers to change the API to acpi_match_ids and
> > acpi_bus_match and have callers can say what they want to match
> > against. 
> >   
> >   Then in acpi_bus_find_driver I have it do 2 passes to search for _HID
> > first then the _CID.  
> > 
> > Does this look like it is in the right ballpark or should we be doing
> > something else?  Built/tested against 2.6.18-rc4-mm3. 
> 
> Conceptually I like this much better than mucking with the motherboard
> driver.  I'm not sure the important people have signed off on this
> strategy of binding with _HID first, then _CID (hi, Len :-))  Maybe
> there are ramifications that we need to consider.  But I think it
> is a better match for "what people expect should happen."

ACPI folks can we get some response to this?  This problem has been
reported a few times against the -mm tree and I would like to get the
proper fix (whatever it is) upstream sometime soon. 

Bjorn thanks for the help and for pointing the error reports in the
right direction. 

Thanks,
  Keith 

RE: one more ACPI Error (utglobal-0125): Unknown exception code: 0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

[Li, Shaohua]

>-----Original Message-----
>From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-
>owner@vger.kernel.org] On Behalf Of Mattia Dongili
>Sent: Tuesday, August 29, 2006 4:24 AM
>To: Andrew Morton
>Cc: linux-kernel@vger.kernel.org; linux-acpi@vger.kernel.org
>Subject: one more ACPI Error (utglobal-0125): Unknown exception code:
>0xFFFFFFEA [Re: 2.6.18-rc4-mm3]
>
>On Sat, Aug 26, 2006 at 04:09:22PM -0700, Andrew Morton wrote:
>>
>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-
>rc4/2.6.18-rc4-mm3/
>[...]
>>  git-acpi.patch
>
>Sorry for reporting separately, I deleted the other thread on the
issue.
>Here we go:
>[    9.386644] PCI: Using ACPI for IRQ routing
>[    9.386688] PCI: If a device doesn't work, try "pci=routeirq".  If
it
>helps, post a report
>[    9.391209] ACPI Error (utglobal-0125): Unknown exception code:
>0xFFFFFFEA [20060707]
>[    9.391521]  [<c0103a9f>] dump_trace+0x1ef/0x230
>[    9.391626]  [<c0103b06>] show_trace_log_lvl+0x26/0x40
>[    9.391724]  [<c01042bb>] show_trace+0x1b/0x20
>[    9.391820]  [<c01043a4>] dump_stack+0x24/0x30
>[    9.391918]  [<c0249f15>] acpi_format_exception+0xa3/0xb0
>[    9.392729]  [<c0246fb6>] acpi_ut_status_exit+0x31/0x5e
>[    9.393453]  [<c0243352>] acpi_walk_resources+0x10e/0x11b
>[    9.394174]  [<c025697e>] acpi_motherboard_add+0x22/0x31
>[    9.394977]  [<c0255890>] acpi_bus_driver_init+0x2b/0x7c
>[    9.395742]  [<c02568da>] acpi_bus_register_driver+0xa1/0x123
>[    9.396507]  [<c0418adb>] acpi_motherboard_init+0x17/0xfb
>[    9.397268]  [<c01003d0>] init+0x80/0x290
>[    9.397343]  [<c0103593>] kernel_thread_helper+0x7/0x14
>[    9.397439]  =======================
>
>full dmesg: http://oioio.altervista.org/linux/dmesg-2.6.18-rc4-mm3-1
>config: http://oioio.altervista.org/linux/config-2.6.18-rc4-mm3-1
>DSDT: http://oioio.altervista.org/linux/DSDT.aml
>      http://oioio.altervista.org/linux/DSDT.dsl
>lspci: http://oioio.altervista.org/linux/lspci-v
Below patch is the root cause.
http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc
4/2.6.18-rc4-mm3/broken-out/hot-add-mem-x86_64-acpi-motherboard-fix.patc
h

motherboard driver is expected to reserve resources used by motherboard,
so hotplug will not fail. I don't know why memory hotplug guys change
it.

Thanks,
Shaohua

2.6.18-rc4-mm3

[Andrew Morton]

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm3/

- autofs mounting of nfs submounts remains broken.



Boilerplate:

- See the `hot-fixes' directory for any important updates to this patchset.

- To fetch an -mm tree using git, use (for example)

  git fetch git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git v2.6.16-rc2-mm1

- -mm kernel commit activity can be reviewed by subscribing to the
  mm-commits mailing list.

        echo "subscribe mm-commits" | mail majordomo@vger.kernel.org

- If you hit a bug in -mm and it is not obvious which patch caused it, it is
  most valuable if you can perform a bisection search to identify which patch
  introduced the bug.  Instructions for this process are at

        http://www.zip.com.au/~akpm/linux/patches/stuff/bisecting-mm-trees.txt

  But beware that this process takes some time (around ten rebuilds and
  reboots), so consider reporting the bug first and if we cannot immediately
  identify the faulty patch, then perform the bisection search.

- When reporting bugs, please try to Cc: the relevant maintainer and mailing
  list on any email.

- Semi-daily snapshots of the -mm lineup are uploaded to
  ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/ and are announced on
  the mm-commits list.



Changes since 2.6.18-rc4-mm2:

 origin.patch
 git-acpi.patch
 git-alsa.patch
 git-agpgart.patch
 git-arm.patch
 git-block.patch
 git-cifs.patch
 git-cpufreq.patch
 git-drm.patch
 git-geode.patch
 git-gfs2.patch
 git-ia64.patch
 git-ieee1394.patch
 git-input.patch
 git-intelfb.patch
 git-kbuild.patch
 git-libata-all.patch
 git-lxdialog.patch
 git-mtd.patch
 git-netdev-all.patch
 git-net.patch
 git-nfs.patch
 git-ocfs2.patch
 git-parisc.patch
 git-pcmcia.patch
 git-powerpc.patch
 git-r8169.patch
 git-sas.patch
 git-s390.patch
 git-scsi-misc.patch
 git-scsi-rc-fixes.patch
 git-scsi-target.patch
 git-supertrak.patch
 git-watchdog.patch
 git-xfs.patch
 git-cryptodev.patch

 git trees

-add-imacfb-documentation-and-detection.patch
-adfs-error-message-fix.patch
-initialize-parts-of-udf-inode-earlier-in-create.patch
-fix-hrtimer-percpu-usage-typo.patch
-fix-x86_64-mm-allow-users-to-force-a-panic-on-nmi.patch
-dm-bug-oops-fix.patch
-change-panic_on_oops-message-to-fatal-exception.patch
-sys_getppid-oopses-on-debug-kernel-v2.patch
-futex_handle_fault-always-fails.patch
-fbdev-include-backlighth-only-when-__kernel__-is-defined.patch
-workqueue-remove-lock_cpu_hotplug.patch
-fuse-fix-error-case-in-fuse_readpages.patch
-asus_acpi-w3000-support.patch
-acpi-change-gfp_atomic-to-gfp_kernel-for-non-atomic.patch
-sound-pci-fm801-use-array_size-macro.patch
-emu10k1x-simplify-around-pci_register_driver.patch
-gregkh-driver-add-stable-branch-to-maintainers-file.patch
-gregkh-driver-pr_debug-should-not-be-used-in-drivers.patch
-add-__must_check-to-device-management-code.patch
-add-config_enable_must_check.patch
-v4l-dev2-handle-__must_check.patch
-drivers-base-platform-notify-needs-to-occur.patch
-sysfs-add-proper-sysfs_init-prototype.patch
-drm-build-fix.patch
-git-drm-oops-fix.patch
-i2c-build-fixes-tps65010.patch
-config_pm=n-slim-drivers-scsi-sata_sil.patch
-mtd-nand-fix-ams-delta-after-core-conversion.patch
-e100-fix-mdio-mdio-x.patch
-e100-increment-version-to-3510-k4.patch
-e1000-same-cosmetic-fix-as-earlier-sent-out-for-ipv4.patch
-e1000-remove-0x1000-as-supported-device.patch
-e1000-explicitly-power-up-the-phy-during-loopback-testing.patch
-e1000-explicit-locking-for-two-ethtool-path-functions.patch
-e1000-allow-nvm-to-setup-lplu-for-igp2-and-igp3.patch
-e1000-force-full-dma-clocking-for-10-100-speed.patch
-e1000-disable-aggressive-clocking-on-esb2-with-serdes-port.patch
-e1000-increment-driver-version-to-719-k6.patch
-ixgb-add-cx4-phy-type-detection-and-subdevice-id.patch
-ixgb-fix-cache-miss-due-to-miscalculation.patch
-ixgb-increment-version-to-10109-k4.patch
-82596-section-fixes.patch
-ac3200-section-fixes.patch
-cops-section-fix.patch
-cs89x0-section-fix.patch
-at1700-section-fix.patch
-e2100-section-fix.patch
-eepro-section-fix.patch
-eexpress-section-fix.patch
-es3210-section-fix.patch
-eth16i-section-fix.patch
-lance-section-fix.patch
-lne390-section-fix.patch
-ni52-section-fix.patch
-ibmtr-section-fix.patch
-smctr-section-fix.patch
-wd-section-fix.patch
-ni65-section-fix.patch
-seeq8005-section-fix.patch
-winbond-840-section-fix.patch
-fealnx-section-fix.patch
-sundance-section-fix.patch
-freescale-qe-ucc-gigabit-ethernet-driver.patch
-s2io-build-fix.patch
-net-add-netconsole-support-to-dm9000-driver.patch
-smc911x-re-release-spinlock-on-spurious-interrupt.patch
-via-rhine-napi-support.patch
-via-rhine-napi-poll-enable.patch
-via-rhine-add-option-avoid_d3-work-around-broken-bioses-2.patch
-lockdep-fix-smc91x.patch
-build-fixes-smc91x.patch
-add-ethtool-g-support-to-spidernet-network-driver.patch
-skge-remember-to-run-netif_poll_disable.patch
-s390-fix-arp_tbl-lock-usage-in-qeth.patch
-xircom_cb-wire-up-errors-from-pci_register_driver.patch
-pal-support-of-the-fixed-phy.patch
-fs_enet-use-pal-for-mii-management.patch
-ppc32-board-specific-part-of-fs_enet-update.patch
-velocity-remove-an-unused-function-from-the-header.patch
-net-drivers-net-via-rhinec-pci_module_init-to-pci_register_driver-conversion.patch
-lockdep-fix-sk_dst_check-deadlock.patch
-ppp-handle-kmalloc-failures.patch
-xt_physdev-build-fix.patch
-fix-potential-stack-overflow-in-net-core-utilsc.patch
-net-atm-compile-error-on-arm.patch
-tg3-convert-the-pci_device_id-table-to-pci_device.patch
-gregkh-pci-pciehp-make-pciehp-build-for-powerpc.patch
-gregkh-pci-pci-remove-dead-hotplug_pci_shpc_phprm_legacy-option.patch
-gregkh-pci-pci-use-pci_bios-as-last-fallback.patch
-pci-use-pcbios-as-last-fallback.patch
-pci-i386-mmconfig-dont-forget-bus-number-when-setting-fallback_slots-bits.patch
-pci-fix-ich6-quirks.patch
-aic7-cleanup-module_parm_desc-strings.patch
-buslogic-gcc-41-warning-fixes.patch
-scsi-limit-recursion-when-flushing-shost-starved_list.patch
-sg-nopage-page-refcounting-fix.patch
-gregkh-usb-usb-unusual_devs-entry-for-a-vox-wsx-300er-mp3-player.patch
-gregkh-usb-usb-removed-a-unbalanced-endif-from-ohci-au1xxx.c.patch
-gregkh-usb-usb-appletouch-fix-atp_disconnect.patch
-gregkh-usb-usb-additional-pid-for-sharp-w-zero3.patch
-gregkh-usb-usb-ftdi_sio-driver-new-pids.patch
-gregkh-usb-usb-usbtest.c-unsigned-retval-makes-ctrl_out-return-0-in-case-of-error.patch
-x86_64-mm-i386-kprobes-error_code.patch
-x86_64-mm-re-positioning-the-bss-segment.patch
-x86_64-wire-up-oops_enter-oops_exit.patch
-kprobes-x86_64-add-kprobe_end-macro-for-popsection.patch
-git-cryptodev-padlock-generic-build-fix.patch
-git-crypto-alignment-build-fixes.patch
-fix-up-lockdep-trace-in-fs-execc.patch
-intelfbhwc-intelfbhw_get_p1p2-defined-but-not-used.patch

 Merged into mainline or a subsystem tree.

+char-moxac-fix-endianess-and-multiple-card-issues.patch
+char-moxac-fix-endianess-and-multiple-card-issues-tidy.patch
+matroxfb-fix-jittery-display-on-non-ppc-systems.patch
+vcsa-attribute-bits-ioctlvt_gethifontmask.patch
+futex_find_get_task-remove-an-obscure-exit_zombie-check.patch
+mtd-nand-fix-ams-delta-after-core-conversion.patch
+fix-for-minix-crash.patch
+ext2-prevent-div-by-zero-on-corrupted-fs.patch
+spectrum_cs-fix-firmware-uploading-errors.patch
+ext3-filesystem-bogus-enospc-with-reservation-fix.patch
+ufs-write-to-hole-in-big-file.patch
+ufs-truncate-correction.patch
+remove-redundent-up-in-stop_machine.patch
+documentation-update-for-relay-interface.patch
+eventpollc-compile-fix.patch
+md-avoid-backward-event-updates-in-md-superblock-when-degraded.patch
+md-fix-recent-breakage-of-md-raid1-array-checking.patch
+cpuset-top_cpuset-tracks-hotplug-changes-to-cpu_online_map.patch
+manage-jbd-allocations-from-its-own-slabs.patch
+manage-jbd-allocations-from-its-own-slabs-tidy.patch
+register_one_node-compile-fix.patch
+sun-disk-label-fix-signed-int-usage-for-sector-count.patch
+sun-disk-label-fix-signed-int-usage-for-sector-count-fix.patch
+config_acpi_srat-numa-build-fix.patch
+lockdep-annotate-idescsi_pc_intr.patch
+lockdep-annotate-reiserfs.patch
+fix-up-lockdep-trace-in-fs-execc.patch
+proc-meminfo-dont-put-spaces-in-names.patch
+x86-numaq-kconfig-fix.patch
+cdrom-gdsc-fix-printk-format-warning.patch

 2.6.18 queue.

+asus_acpi-fix-proc-files-parsing.patch
+asus_acpi-dont-printk-on-writing-garbage-to-proc-files.patch

 ACPI driver fixes

+agph-constify-struct-agp_bridge_dataversion.patch

 AGP cleanup

+gregkh-driver-add-__must_check-to-device-management-code.patch
+gregkh-driver-add-config_enable_must_check.patch
+gregkh-driver-v4l-dev2-handle-__must_check.patch
+gregkh-driver-drivers-base-platform-notify-needs-to-occur-before-drivers-attach-to-the-device.patch
+gregkh-driver-drivers-base-check-errors.patch
+gregkh-driver-sysfs-add-proper-sysfs_init-prototype.patch
+gregkh-driver-nozomi.patch

 driver tree updates

-drm-minor-fixes.patch

 Dropped.

+ks0127-wire-up-i2c_add_driver-return-value.patch
+drivers-media-video-bt866c-array-overflows.patch

 DVB updates

+gregkh-i2c-i2c-tps65010-build-fixes.patch
+gregkh-i2c-hwmon-abituguru-timeout-fixes.patch
+gregkh-i2c-i2c-__must_check-fixes.patch
+gregkh-i2c-i2c-__must_check-fixes-i2c-dev.patch
+gregkh-i2c-i2c-algo-sibyte-cleanups.patch
+gregkh-i2c-i2c-algo-sibyte-merge-in-i2c-sibyte.patch
+gregkh-i2c-i2c-sibyte-drop-kip-walker-address.patch
+gregkh-i2c-i2c-au1550-fix-timeout-problem.patch
+gregkh-i2c-i2c-au1550-add-smbus-functionality-flag.patch
+gregkh-i2c-i2c-au1550-add-au1200-support.patch
+gregkh-i2c-i2c-fix-copy-n-paste-in-subsystem-Kconfig.patch
+gregkh-i2c-i2c-matroxfb-c99-struct-init.patch
+gregkh-i2c-i2c-algo-bit-kill-mdelay.patch
+gregkh-i2c-i2c-bus-driver-for-TI-OMAP-boards.patch
+gregkh-i2c-i2c-isa-plan-for-removal.patch
+gregkh-i2c-i2c-stub-add-chip_addr-param.patch

 I2C tree updates

+input-i8042-get-rid-of-polling-timer.patch

 Yet another attempt at this input layer cleanup.

+git-intelfb-fixup.patch

 Fix rejects in git-intelfb.patch

+libata-add-40pin-short-cable-support-honour-drive.patch

 ATA fix

-1-of-2-jmicron-driver-hard_port_no-fix.patch

 Folded into 1-of-2-jmicron-driver.patch

+1-of-2-jmicron-driver-fix.patch

 Fix it.

+via-pata-controller-xfer-fixes-fix.patch

 Fix via-pata-controller-xfer-fixes.patch

+e1000-e1000_probe-resources-cleanup.patch

 net driver cleanup

+signedness-issue-in-drivers-net-phy-phy_devicec.patch
+b44-fix-eeprom-endianess-issue.patch
+forcedeth-decouple-vlan-and-rx-checksum-dependency.patch

 net driver fixes.

+git-net-fixup.patch

 Fix rejects in git-net.patch

+atm-he-fix-section-mismatch.patch

 ATM driver section fix.

+git-nfs-fixup.patch

 Fix rejects in git-nfs.patch

+drivers-net-pcmcia-xirc2ps_csc-remove-unused-label.patch

 PCMCIA driver cleanup.

+gregkh-pci-pci-use-pcbios-as-last-fallback.patch
+gregkh-pci-pci-i386-mmconfig-don-t-forget-bus-number-when-setting-fallback_slots-bits.patch
+gregkh-pci-pci-fix-ich6-quirks.patch
+gregkh-pci-cpci-hotplug-fix-resource-assignment.patch
+gregkh-pci-pci-kerneldoc-correction-in-pci-driver.patch

 PCI tree updates

-revert-gregkh-pci-pci-use-pci_bios-as-last-fallback.patch

 Unneeded (hopefully)

+pci-add-ich7-8-acpi-gpio-io-resource-quirks.patch

 More PCI quirks.

+signedness-issue-in-drivers-scsi-iprc.patch
+signedness-issue-in-drivers-scsi-osstc.patch

 SCSI driver fixlets.

-git-scsi-target-ibmvscsi-build-fix.patch

 Unneeded

+gregkh-usb-usb-pl2303-removed-support-for-oti-s-dku-5-clone-cable.patch
+gregkh-usb-unusual_devs-update-for-ucr-61s2b.patch
+gregkh-usb-uhci-increase-resume-detect-off-delay.patch
+gregkh-usb-usbcore-make-hcd_endpoint_disable-wait-for-queue-to-drain.patch
+gregkh-usb-usbcore-khubd-and-busy-port-handling.patch
+gregkh-usb-usb-skeleton-small-update.patch
+gregkh-usb-usb-storage-add-rio-karma-eject-support.patch

 USB tree updates.

+gregkh-usb-usb-storage-add-rio-karma-eject-support-fix.patch

 Fix it.

+turn-usb_resume_both-into-static-inline.patch
+signedness-issue-in-drivers-usb-gadget-etherc.patch
+adutux-fix-printk-format-warnings.patch
+aircable-fix-printk-format-warnings.patch

 USB fixes.

+x86_64-mm-disable-mmconfig-e820-heuristic.patch
+x86_64-mm-remove-safe_smp_processor_id.patch
+x86_64-mm-early_ioremap-warning.patch
+x86_64-mm-pte-exec.patch
+x86_64-mm-cpa-pse-cleanup.patch
+x86_64-mm-remove-apic-version-capability.patch
+x86_64-mm-cleanup-apic-id-checking.patch
+x86_64-mm-mpparse-style.patch
+x86_64-mm-nmi-irqtrace-check.patch
+x86_64-mm-fix-head.S-warning.patch
+x86_64-mm-recover-1mb.patch
+x86_64-mm-remove-e820-fallback.patch
+x86_64-mm-optimize-hweight64-for-x86_64.patch
+x86_64-mm-reload-cs-in-head.patch
+x86_64-mm-note-section.patch
+x86_64-mm-e820-comment.patch
+x86_64-mm-spin-irqs-enabled.patch
+x86_64-mm-remove-alternative-smp.patch
+x86_64-mm-i386-remove-alternative-smp.patch
+x86_64-mm-cleanup-spinlock.patch
+x86_64-mm-dmi-mmconfig-intel-sdv.patch

 x86_64 tree updates

+mm-x86_64-mm-generic-getcpu-syscall-tweaks.patch

 Cleanup

+git-cryptodev-fixup.patch
+git-cryptodev-fixup-2.patch

 Fix rejects in git-cryptodev.patch

+adix-tree-rcu-lockless-readside-fix-3.patch
+radix-tree-cleanup-radix_tree_deref_slot-and.patch
+cleanup-radix_tree_derefreplace_slot-calling-conventions.patch

 More radix-tree work.

+standardize-pxx_page-macros-fix.patch

 Fix standardize-pxx_page-macros.patch

+zvc-scale-thresholds-depending-on-the-size-of-the-system.patch
+zvc-scale-thresholds-depending-on-the-size-of-the-system-fix.patch
+extract-the-allocpercpu-functions-from-the-slab-allocator.patch
+introduce-mechanism-for-registering-active-regions-of-memory.patch
+have-power-use-add_active_range-and-free_area_init_nodes.patch
+have-x86-use-add_active_range-and-free_area_init_nodes.patch
+have-x86-use-add_active_range-and-free_area_init_nodes-fix.patch
+have-x86_64-use-add_active_range-and-free_area_init_nodes.patch
+have-ia64-use-add_active_range-and-free_area_init_nodes.patch
+account-for-memmap-and-optionally-the-kernel-image-as-holes.patch
+replace-min_unmapped_ratio-by-min_unmapped_pages-in-struct-zone.patch
+zvc-support-nr_slab_reclaimable--nr_slab_unreclaimable.patch
+zone_reclaim-dynamic-slab-reclaim.patch
+zone_reclaim-dynamic-slab-reclaim-tidy.patch

 Memory management updates

+selinux-1-3-eliminate-inode_security_set_security.patch
+selinux-2-3-change-isec-semaphore-to-a-mutex.patch
+selinux-2-3-change-isec-semaphore-to-a-mutex-vs-git-net.patch
+selinux-3-3-convert-sbsec-semaphore-to-a-mutex.patch
+selinux-fix-tty-locking.patch

 SELinux updates

+avr32-set-kbuild_defconfig.patch
+avr32-kprobes-compile-fix.patch
+avr32-asm-ioh-should-include-asm-byteorderh.patch
+avr32-fix-output-constraints-in-asm-bitopsh.patch
+avr32-standardize-pxx_page-macros-fix.patch

 Update avr32 architecture.

+x86-put-note-sections-into-a-pt_note-segment-in-vmlinux-fix.patch

 Fix x86-put-note-sections-into-a-pt_note-segment-in-vmlinux.patch

-add-force-of-use-mmconfig.patch
-add-efi-e820-memory-mapping-on-x86.patch
-fix-boot-on-efi-32-bit-machines.patch

 Dropped.

+mtrr-add-lock-annotations-for-prepare_set-and.patch
+x86-remove-default_ldt-and-simplify-ldt-setting.patch

 x86 updates.

-kill-default_ldt.patch

 Updated.

+alpha-fix-alpha_ev56-dependencies-typo.patch

 Alpha fixlet.

+xtensa-ptrace-exit_zombie-fix.patch

 xtensa fix.

+copy_process-cosmetic-ioprio-tweak.patch
+autofs4-autofs4_follow_link-false-negative-fix.patch
+autofs4-pending-flag-not-cleared-on-mount-fail.patch
+futex_find_get_task-dont-take-tasklist_lock.patch
+sys_get_robust_list-dont-take-tasklist_lock.patch
+docbook-fix-segfault-in-docprocc.patch
+solaris-emulation-incorrect-tty-locking.patch
+solaris-emulation-incorrect-tty-locking-fix.patch
+solaris-emulation-incorrect-tty-locking-fix-2.patch
+tty-fix-bits-and-note-more-bits-to-fix.patch
+windfarm_smu_satc-simplify-around-i2c_add_driver.patch
+make-spinlock-rwlock-annotations-more-accurate-by-using.patch
+replace-_spin_trylock-with-spin_trylock-in-the-irq.patch
+ext3-turn-on-reservation-dump-on-block-allocation-errors.patch
+ext3-add-more-comments-in-block-allocation-reservation-code.patch
+generic-boolean.patch
+fs-ntfs-conversion-to-generic-boolean.patch
+fs-jfs-conversion-to-generic-boolean.patch
+block_devc-mutex_lock_nested-fix.patch
+fix-mem_write-return-value.patch
+doc-fix-kernel-parameters-quiet.patch
+pass-a-lock-expression-to-__cond_lock-like-__acquire-and.patch
+cramfs-rewrite-init_cramfs_fs.patch
+freevxfs-fix-leak-on-error-path.patch
+cramfs-make-cramfs_uncompress_exit-return-void.patch
+9p-fix-leak-on-error-path.patch
+ban-register_filesystemnull.patch
+jbd-use-build_bug_on-in-journal-init.patch
+more-ext3-16t-overflow-fixes.patch
+ext3-inode-numbers-are-unsigned-long.patch
+lockdep-core-add-enable-disable_irq_irqsave-irqrestore-apis.patch
+really-ignore-kmem_cache_destroy-return-value.patch
+make-kmem_cache_destroy-return-void.patch
+set-exit_dead-state-in-do_exit-not-in-schedule.patch
+kill-pf_dead-flag.patch
+introduce-task_dead-state.patch
+fix-typo-in-rtc-kconfig.patch

 Misc.

+pass-sparse-the-lock-expression-given-to-lock-annotations.patch

 Update for new sparse features.

+ntp-add-ntp_update_frequency-fix.patch

 Fix ntp-add-ntp_update_frequency.patch

+kill-wall_jiffies.patch

 Time management cleanup.

+reiserfs-eliminate-minimum-window-size-for-bitmap-searching.patch

 reiserfs speedup/simplification.

+fs-cache-make-kafs-use-fs-cache-12-fix.patch

 Fix fs-cache-make-kafs-use-fs-cache-12.patch

+fs-cache-cachefiles-a-cache-that-backs-onto-a-mounted-filesystem-warning-fixes.patch

 Fix fs-cache-cachefiles-a-cache-that-backs-onto-a-mounted-filesystem.patch
 some more.

+hdaps-add-explicit-hardware-configuration-functions-fix-fix.patch

 Fix hdaps-add-explicit-hardware-configuration-functions.patch some more.

+generic-ioremap_page_range-x86_64-conversion-fix.patch

 Fix generic-ioremap_page_range-x86_64-conversion.patch

+support-piping-into-commands-in-proc-sys-kernel-core_pattern-fix-2.patch

 Fix support-piping-into-commands-in-proc-sys-kernel-core_pattern.patch some
 more.

+kprobes-make-kprobe-modules-more-portable.patch
+kprobes-make-kprobe-modules-more-portable-update.patch
+add-regs_return_value-helper.patch
+update-documentation-kprobestxt.patch
+update-documentation-kprobestxt-update.patch

 kprobes updates.

+knfsd-split-svc_serv-into-pools-fix.patch

 Fix knfsd-split-svc_serv-into-pools.patch

+nfsd-lockdep-annotation.patch
+knfsd-nfsd-lockdep-annotation-fix.patch
+knfsd-call-lockd_down-when-closing-a-socket-via-a-write-to-nfsd-portlist.patch
+knfsd-protect-update-to-sn_nrthreads-with-lock_kernel.patch
+knfsd-fixed-handling-of-lockd-fail-when-adding-nfsd-socket.patch
+knfsd-replace-two-page-lists-in-struct-svc_rqst-with-one.patch
+knfsd-avoid-excess-stack-usage-in-svc_tcp_recvfrom.patch
+knfsd-prepare-knfsd-for-support-of-rsize-wsize-of-up-to-1mb-over-tcp.patch
+knfsd-allow-max-size-of-nfsd-payload-to-be-configured.patch
+knfsd-make-nfsd-readahead-params-cache-smp-friendly.patch
+knfsd-knfsd-cache-ipmap-per-tcp-socket.patch

 NFSD updates.

+zvc-support-nr_slab_reclaimable--nr_slab_unreclaimable-swap_prefetch.patch

 Update swap prefetch for mm changes.

+ecryptfs-mntput-lower-mount-on-umount_begin.patch
+vfs-make-filldir_t-and-struct-kstat-deal-in-64-bit-inode-numbers-ecryptfs.patch
+make-kmem_cache_destroy-return-void-ecryptfs.patch

 ecryptfs updates

-namespaces-add-nsproxy-dont-include-compileh.patch
+namespaces-add-nsproxy-move-init_nsproxy-into-kernel-nsproxyc.patch
-namespaces-utsname-switch-to-using-uts-namespaces-uml-fix.patch
-namespaces-utsname-use-init_utsname-when-appropriate-gmidi.patch
-namespaces-utsname-use-init_utsname-when-appropriate-print_kernel_version.patch
-namespaces-utsname-sysctl-hack-fix.patch

 namespace patch consolidation.

+make-kmem_cache_destroy-return-void-reiser4.patch

 Fix reiser4 for other -mm patches.

+atyfb-possible-cleanups.patch
+mbxfb-fix-a-chip-bug-resulting-in-wrong-pixclock.patch
+mbxfb-fix-framebuffer-size-smaller-than-requested.patch
+fbcon-make-3-functions-static.patch
+vt-proper-prototypes-for-some-console-functions.patch
+sstfb-clean-ups.patch

 fbdev updates.

+md-fix-issues-with-referencing-rdev-in-md-raid1.patch
+md-new-sysfs-interface-for-setting-bits-in-the-write-intent-bitmap.patch
+md-remove-unnecessary-variable-x-in-stripe_to_pdidx.patch

 MD updates

+srcu-3-rcu-variant-permitting-read-side-blocking-srcu-add-lock-annotations.patch

 Add lock annotation to SRCU.

+rcu-add-fake-writers-to-rcutorture-tidy.patch

 Clean up rcu-add-fake-writers-to-rcutorture.patch

+acpi_format_exception-debug.patch

 ACPI debugging.



All 1658 patches:

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm3/patch-list

one more ACPI Error (utglobal-0125): Unknown exception code: 0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

[Mattia Dongili]

On Sat, Aug 26, 2006 at 04:09:22PM -0700, Andrew Morton wrote:
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm3/
[...]
>  git-acpi.patch

Sorry for reporting separately, I deleted the other thread on the issue.
Here we go:
[    9.386644] PCI: Using ACPI for IRQ routing
[    9.386688] PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
[    9.391209] ACPI Error (utglobal-0125): Unknown exception code: 0xFFFFFFEA [20060707]
[    9.391521]  [<c0103a9f>] dump_trace+0x1ef/0x230
[    9.391626]  [<c0103b06>] show_trace_log_lvl+0x26/0x40
[    9.391724]  [<c01042bb>] show_trace+0x1b/0x20
[    9.391820]  [<c01043a4>] dump_stack+0x24/0x30
[    9.391918]  [<c0249f15>] acpi_format_exception+0xa3/0xb0
[    9.392729]  [<c0246fb6>] acpi_ut_status_exit+0x31/0x5e
[    9.393453]  [<c0243352>] acpi_walk_resources+0x10e/0x11b
[    9.394174]  [<c025697e>] acpi_motherboard_add+0x22/0x31
[    9.394977]  [<c0255890>] acpi_bus_driver_init+0x2b/0x7c
[    9.395742]  [<c02568da>] acpi_bus_register_driver+0xa1/0x123
[    9.396507]  [<c0418adb>] acpi_motherboard_init+0x17/0xfb
[    9.397268]  [<c01003d0>] init+0x80/0x290
[    9.397343]  [<c0103593>] kernel_thread_helper+0x7/0x14
[    9.397439]  =======================

full dmesg: http://oioio.altervista.org/linux/dmesg-2.6.18-rc4-mm3-1
config: http://oioio.altervista.org/linux/config-2.6.18-rc4-mm3-1
DSDT: http://oioio.altervista.org/linux/DSDT.aml
      http://oioio.altervista.org/linux/DSDT.dsl
lspci: http://oioio.altervista.org/linux/lspci-v

-- 
mattia
:wq!