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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1158202876.20560.14.camel@sli10-conroe.sh.intel.com>
Date:	Thu, 14 Sep 2006 11:01:16 +0800
From:	Shaohua Li <shaohua.li@...el.com>
To:	Bjorn Helgaas <bjorn.helgaas@...com>
Cc:	kmannth@...ibm.com, "Moore, Robert" <robert.moore@...el.com>,
	Len Brown <lenb@...nel.org>,
	Mattia Dongili <malattia@...ux.it>,
	Andrew Morton <akpm@...l.org>,
	lkml <linux-kernel@...r.kernel.org>,
	linux acpi <linux-acpi@...r.kernel.org>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
Subject: Re: one more ACPI Error (utglobal-0125): Unknown exception 
	code:0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/