public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: keith mannthey <kmannth@us.ibm.com>
To: Shaohua Li <shaohua.li@intel.com>
Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>,
	"Moore, Robert" <robert.moore@intel.com>,
	Len Brown <lenb@kernel.org>, Mattia Dongili <malattia@linux.it>,
	Andrew Morton <akpm@osdl.org>,
	lkml <linux-kernel@vger.kernel.org>,
	linux acpi <linux-acpi@vger.kernel.org>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Subject: Re: one more ACPI Error (utglobal-0125): Unknown exception  code:0xFFFFFFEA [Re: 2.6.18-rc4-mm3]
Date: Thu, 14 Sep 2006 10:55:05 -0700	[thread overview]
Message-ID: <1158256505.5660.22.camel@keithlap> (raw)
In-Reply-To: <1158202876.20560.14.camel@sli10-conroe.sh.intel.com>

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 


  parent reply	other threads:[~2006-09-14 17:55 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-06 18:59 one more ACPI Error (utglobal-0125): Unknown exception code: 0xFFFFFFEA [Re: 2.6.18-rc4-mm3] Moore, Robert
2006-09-06 20:04 ` keith mannthey
2006-09-07  2:03   ` one more ACPI Error (utglobal-0125): Unknown exception code:0xFFFFFFEA " Shaohua Li
2006-09-07 15:25     ` Bjorn Helgaas
2006-09-08  0:57       ` Shaohua Li
2006-09-08  2:27         ` Bjorn Helgaas
2006-09-13  1:27           ` keith mannthey
2006-09-13 14:51             ` Bjorn Helgaas
2006-09-14  3:01               ` Shaohua Li
2006-09-14 16:36                 ` Bjorn Helgaas
2006-09-15  1:39                   ` Shaohua Li
2006-09-19 10:22                     ` Bjorn Helgaas
2006-09-14 17:55                 ` keith mannthey [this message]
2006-09-15  1:52                   ` Shaohua Li
2006-09-21  0:27                     ` keith mannthey
  -- strict thread matches above, loose matches on Subject: below --
2006-08-31 17:02 Moore, Robert
2006-08-31 17:56 ` keith mannthey
2006-08-29 20:04 one more ACPI Error (utglobal-0125): Unknown exception code: 0xFFFFFFEA " Moore, Robert
2006-08-31  6:48 ` Len Brown
2006-08-31 16:48   ` keith mannthey
2006-08-31 23:06     ` Bjorn Helgaas
     [not found]       ` <1157073592.5649.29.camel@keithlap>
2006-09-01  2:39         ` one more ACPI Error (utglobal-0125): Unknown exception code:0xFFFFFFEA " Shaohua Li
2006-09-01  3:31           ` keith mannthey
2006-09-01  3:15         ` one more ACPI Error (utglobal-0125): Unknown exception code: 0xFFFFFFEA " Bjorn Helgaas
2006-09-01  3:56           ` KAMEZAWA Hiroyuki
2006-09-01 23:01           ` keith mannthey
2006-09-01 23:20             ` Bjorn Helgaas
2006-09-06 18:14               ` keith mannthey
2006-08-29  2:05 Li, Shaohua
2006-08-26 23:09 2.6.18-rc4-mm3 Andrew Morton
2006-08-28 20:24 ` one more ACPI Error (utglobal-0125): Unknown exception code: 0xFFFFFFEA [Re: 2.6.18-rc4-mm3] Mattia Dongili

Reply instructions:

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

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

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

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

  git send-email \
    --in-reply-to=1158256505.5660.22.camel@keithlap \
    --to=kmannth@us.ibm.com \
    --cc=akpm@osdl.org \
    --cc=bjorn.helgaas@hp.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=malattia@linux.it \
    --cc=robert.moore@intel.com \
    --cc=shaohua.li@intel.com \
    /path/to/YOUR_REPLY

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

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