[PATCH] fix(Fix _STA checking in acpi_bus_add)

[PATCH] fix(Fix _STA checking in acpi_bus_add)

[Simon Derr]

Hi,

On our 4-way and 2-way IA-64 systems, the PCI bus with id 0xff does not
appear anymore on recent Linux 2.6 kernels. This is a problem because we
use it to find out the revision of the chipset of the system.

It used to work fine "before", i.e. running lspci showed the 0xff bus.

It hunted this change and found the culprit to be this patch (that was
introduced between 2.6.1 and 2.6.2):

https://sourceforge.net/mailarchive/message.php?msg_id=6923348

This patch seems to have received no feedback at all, and is a source of
trouble for us.

I propose a patch that reverts to the 2.6.1 situation, with a somewhat
more good-looking code.

	Simon.

--- linux-2.6.5-vanilla/drivers/acpi/scan.c	Sun Apr  4 05:36:57 2004
+++ linux-2.6.5/drivers/acpi/scan.c	Wed Apr 28 15:17:57 2004
@@ -706,7 +706,7 @@
 	switch (type) {
 	case ACPI_BUS_TYPE_DEVICE:
 		result = acpi_bus_get_status(device);
-		if (ACPI_FAILURE(result) || !device->status.present) {
+		if (ACPI_FAILURE(result)) {
 			result = -ENOENT;
 			goto end;
 		}


-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Re: [PATCH] fix(Fix _STA checking in acpi_bus_add)

[Matthew Wilcox]

On Wed, Apr 28, 2004 at 04:18:46PM +0200, Simon Derr wrote:
> On our 4-way and 2-way IA-64 systems, the PCI bus with id 0xff does not
> appear anymore on recent Linux 2.6 kernels. This is a problem because we
> use it to find out the revision of the chipset of the system.
> 
> It used to work fine "before", i.e. running lspci showed the 0xff bus.
> 
> It hunted this change and found the culprit to be this patch (that was
> introduced between 2.6.1 and 2.6.2):
> 
> https://sourceforge.net/mailarchive/message.php?msg_id=6923348
> 
> This patch seems to have received no feedback at all, and is a source of
> trouble for us.
> 
> I propose a patch that reverts to the 2.6.1 situation, with a somewhat
> more good-looking code.

Sounds like you have a bug.  Why does your firmware not report that the
device is present?

> --- linux-2.6.5-vanilla/drivers/acpi/scan.c	Sun Apr  4 05:36:57 2004
> +++ linux-2.6.5/drivers/acpi/scan.c	Wed Apr 28 15:17:57 2004
> @@ -706,7 +706,7 @@
>  	switch (type) {
>  	case ACPI_BUS_TYPE_DEVICE:
>  		result = acpi_bus_get_status(device);
> -		if (ACPI_FAILURE(result) || !device->status.present) {
> +		if (ACPI_FAILURE(result)) {
>  			result = -ENOENT;
>  			goto end;
>  		}
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 10g. 
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> Acpi-devel mailing list
> Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/acpi-devel

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain


-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Re: [PATCH] fix(Fix _STA checking in acpi_bus_add)

[Simon Derr]

On Wed, 28 Apr 2004, Matthew Wilcox wrote:

> Sounds like you have a bug.  Why does your firmware not report that the
> device is present?
>
Yes there is very probably some firmware bug involved, and as a matter of
fact we happen to have a 16-way system where the 0xff bus is visible even
with recent kernels.

Anyway...

The previous state of acpi_bus_add() (I mean Linux 2.6.1) almost looked
like a quick hack/workaround, so I'm wondering what its author had in
mind. Maybe this is a common firmware "bug" and Linux should know how to
handle it ?

	Simon.


-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Re: [PATCH] fix(Fix _STA checking in acpi_bus_add)

[Bjorn Helgaas]

On Wednesday 28 April 2004 8:53 am, Simon Derr wrote:
> On Wed, 28 Apr 2004, Matthew Wilcox wrote:
> 
> > Sounds like you have a bug.  Why does your firmware not report that the
> > device is present?
> >
> Yes there is very probably some firmware bug involved, and as a matter of
> fact we happen to have a 16-way system where the 0xff bus is visible even
> with recent kernels.

Is your box based on Intel chipsets and/or firmware?  You might be
suffering from the problem I described here:

    https://sourceforge.net/mailarchive/message.php?msg_id=6923358

Intel firmware seems to describe the PCI root bridge where chipset
configuration space lives with _STA==0x8.  The spec says this means
"functional, but not present".  The current Linux code ignores things
that are "not present".

Nobody cared enough to do anything about this issue at the time, so
it is still broken.  I did raise the issue with our ACPI representative,
but I don't know what happened.  I'd like to see some clarification in
the spec.


-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Re: [PATCH] fix(Fix _STA checking in acpi_bus_add)

[Simon Derr]

On Wed, 28 Apr 2004, Bjorn Helgaas wrote:

> Is your box based on Intel chipsets and/or firmware?  You might be
Indeed.

> suffering from the problem I described here:
>
>     https://sourceforge.net/mailarchive/message.php?msg_id=6923358
>
> Intel firmware seems to describe the PCI root bridge where chipset
> configuration space lives with _STA==0x8.  The spec says this means
> "functional, but not present".  The current Linux code ignores things
> that are "not present".

I tried your patch and it works perfectly. Thank you.
This chipset/firmware is probably very common in the ia64 world so I think
it might be a good idea to include your patch in the stock Linux kernel.

	Simon.

This is just your patch with updated line offsets, applies cleanly to
Linux 2.6.5:

--- linux-2.6.5-vanilla/drivers/acpi/bus.c	Sun Apr  4 05:37:24 2004
+++ linux-2.6.5/drivers/acpi/bus.c	Thu Apr 29 09:43:14 2004
@@ -112,6 +112,14 @@
 	else
 		STRUCT_TO_INT(device->status) = 0x0F;

+	if (device->status.functional && !device->status.present) {
+		printk(KERN_WARNING PREFIX "Device [%s] status [%08x]: "
+			"functional but not present; setting present\n",
+			device->pnp.bus_id,
+			(u32) STRUCT_TO_INT(device->status));
+		device->status.present = 1;
+	}
+
 	ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Device [%s] status [%08x]\n",
 		device->pnp.bus_id, (u32) STRUCT_TO_INT(device->status)));



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Re: [PATCH] fix(Fix _STA checking in acpi_bus_add)

[Bjorn Helgaas]

On Thursday 29 April 2004 2:18 am, Simon Derr wrote:
> On Wed, 28 Apr 2004, Bjorn Helgaas wrote:
> 
> > Is your box based on Intel chipsets and/or firmware?  You might be
> Indeed.
> 
> > suffering from the problem I described here:
> >
> >     https://sourceforge.net/mailarchive/message.php?msg_id=6923358
> >
> > Intel firmware seems to describe the PCI root bridge where chipset
> > configuration space lives with _STA==0x8.  The spec says this means
> > "functional, but not present".  The current Linux code ignores things
> > that are "not present".
> 
> I tried your patch and it works perfectly. Thank you.
> This chipset/firmware is probably very common in the ia64 world so I think
> it might be a good idea to include your patch in the stock Linux kernel.

Well, the patch is a gross hack for a special case, and I'd be worried
about it breaking something related to docking or hotplug.  That's why
I posted it as "RFC" first, in the hope that someone could explain the
intent behind the Intel firmware.

Given the current ACPI spec, I'd say it's a bug in the Intel firmware,
and any workaround should be specific to that firmware.  If Intel
figures out good semantics for what they're trying to do, I think that
should be reflected in a future spec.

> This is just your patch with updated line offsets, applies cleanly to
> Linux 2.6.5:
> 
> --- linux-2.6.5-vanilla/drivers/acpi/bus.c	Sun Apr  4 05:37:24 2004
> +++ linux-2.6.5/drivers/acpi/bus.c	Thu Apr 29 09:43:14 2004
> @@ -112,6 +112,14 @@
>  	else
>  		STRUCT_TO_INT(device->status) = 0x0F;
> 
> +	if (device->status.functional && !device->status.present) {
> +		printk(KERN_WARNING PREFIX "Device [%s] status [%08x]: "
> +			"functional but not present; setting present\n",
> +			device->pnp.bus_id,
> +			(u32) STRUCT_TO_INT(device->status));
> +		device->status.present = 1;
> +	}
> +
>  	ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Device [%s] status [%08x]\n",
>  		device->pnp.bus_id, (u32) STRUCT_TO_INT(device->status)));
> 
> 

-- 
Bjorn Helgaas - bjorn.helgaas at hp.com
Linux and Open Source Lab
Hewlett-Packard Company


-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Re: [PATCH] fix(Fix _STA checking in acpi_bus_add)

[Bruno Ducrot]

On Thu, Apr 29, 2004 at 08:46:41AM -0600, Bjorn Helgaas wrote:
> On Thursday 29 April 2004 2:18 am, Simon Derr wrote:
> > On Wed, 28 Apr 2004, Bjorn Helgaas wrote:
> > 
> > > Is your box based on Intel chipsets and/or firmware?  You might be
> > Indeed.
> > 
> > > suffering from the problem I described here:
> > >
> > >     https://sourceforge.net/mailarchive/message.php?msg_id=6923358
> > >
> > > Intel firmware seems to describe the PCI root bridge where chipset
> > > configuration space lives with _STA==0x8.  The spec says this means
> > > "functional, but not present".  The current Linux code ignores things
> > > that are "not present".
> > 
> > I tried your patch and it works perfectly. Thank you.
> > This chipset/firmware is probably very common in the ia64 world so I think
> > it might be a good idea to include your patch in the stock Linux kernel.
> 
> Well, the patch is a gross hack for a special case, and I'd be worried
> about it breaking something related to docking or hotplug.  That's why
> I posted it as "RFC" first, in the hope that someone could explain the
> intent behind the Intel firmware.

Note that my previous post is how I interpret the specs.  I can be
completely wrong, and thinks like breaking docking etc. is only based on
my interpretation.

> Given the current ACPI spec, I'd say it's a bug in the Intel firmware,
> and any workaround should be specific to that firmware.  If Intel
> figures out good semantics for what they're trying to do, I think that
> should be reflected in a future spec.

It's up to real ACPI experts, like Bob, to tell actually what means
exactly that funny 0x8 returned from _STA.

-- 
Bruno Ducrot

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Re: [PATCH] fix(Fix _STA checking in acpi_bus_add)

[Len Brown]

As this is needed by more than just Big Sur,
I'm okay with applying Bjorn's workaround to acpi-test
(and thus -mm) while we wait for definitive word
from the spec writers.  We can always back it out
or make it system specific later.  I have no fear
that we'll break docking stations, because at this
point we have no docking station support...

thanks,
-Len

On Thu, 2004-04-29 at 04:18, Simon Derr wrote:
> On Wed, 28 Apr 2004, Bjorn Helgaas wrote:
> 
> > Is your box based on Intel chipsets and/or firmware?  You might be
> Indeed.
> 
> > suffering from the problem I described here:
> >
> >     https://sourceforge.net/mailarchive/message.php?msg_id=6923358
> >
> > Intel firmware seems to describe the PCI root bridge where chipset
> > configuration space lives with _STA==0x8.  The spec says this means
> > "functional, but not present".  The current Linux code ignores things
> > that are "not present".
> 
> I tried your patch and it works perfectly. Thank you.
> This chipset/firmware is probably very common in the ia64 world so I think
> it might be a good idea to include your patch in the stock Linux kernel.
> 
> 	Simon.
> 
> This is just your patch with updated line offsets, applies cleanly to
> Linux 2.6.5:
> 
> --- linux-2.6.5-vanilla/drivers/acpi/bus.c	Sun Apr  4 05:37:24 2004
> +++ linux-2.6.5/drivers/acpi/bus.c	Thu Apr 29 09:43:14 2004
> @@ -112,6 +112,14 @@
>  	else
>  		STRUCT_TO_INT(device->status) = 0x0F;
> 
> +	if (device->status.functional && !device->status.present) {
> +		printk(KERN_WARNING PREFIX "Device [%s] status [%08x]: "
> +			"functional but not present; setting present\n",
> +			device->pnp.bus_id,
> +			(u32) STRUCT_TO_INT(device->status));
> +		device->status.present = 1;
> +	}
> +
>  	ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Device [%s] status [%08x]\n",
>  		device->pnp.bus_id, (u32) STRUCT_TO_INT(device->status)));
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 10g. 
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> Acpi-devel mailing list
> Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/acpi-devel



-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver
higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Re: [PATCH] fix(Fix _STA checking in acpi_bus_add)

[Len Brown]

The ACPI spec gurus say that as of 2.0c,
_STA.functional is meaningless unless _STA.present.

However, they also say that the (_STA.functional && !_STA.present)
implementation was intentional -- apparently to trick some OSPM into
using a resource for initialization only, but to not load
a driver.

So...

I'm advocating that the spec be clarified to explicitly
allow or disallow this idiom.

In the mean-time, Bjorn's patch is now present in the acpi-test tree.

-Len

On Wed, 2004-05-12 at 00:40, Len Brown wrote:
> As this is needed by more than just Big Sur,
> I'm okay with applying Bjorn's workaround to acpi-test
> (and thus -mm) while we wait for definitive word
> from the spec writers.  We can always back it out
> or make it system specific later.  I have no fear
> that we'll break docking stations, because at this
> point we have no docking station support...
> 
> thanks,
> -Len
> 
> On Thu, 2004-04-29 at 04:18, Simon Derr wrote:
> > On Wed, 28 Apr 2004, Bjorn Helgaas wrote:
> > 
> > > Is your box based on Intel chipsets and/or firmware?  You might be
> > Indeed.
> > 
> > > suffering from the problem I described here:
> > >
> > >     https://sourceforge.net/mailarchive/message.php?msg_id=6923358
> > >
> > > Intel firmware seems to describe the PCI root bridge where chipset
> > > configuration space lives with _STA==0x8.  The spec says this means
> > > "functional, but not present".  The current Linux code ignores things
> > > that are "not present".
> > 
> > I tried your patch and it works perfectly. Thank you.
> > This chipset/firmware is probably very common in the ia64 world so I think
> > it might be a good idea to include your patch in the stock Linux kernel.
> > 
> > 	Simon.
> > 
> > This is just your patch with updated line offsets, applies cleanly to
> > Linux 2.6.5:
> > 
> > --- linux-2.6.5-vanilla/drivers/acpi/bus.c	Sun Apr  4 05:37:24 2004
> > +++ linux-2.6.5/drivers/acpi/bus.c	Thu Apr 29 09:43:14 2004
> > @@ -112,6 +112,14 @@
> >  	else
> >  		STRUCT_TO_INT(device->status) = 0x0F;
> > 
> > +	if (device->status.functional && !device->status.present) {
> > +		printk(KERN_WARNING PREFIX "Device [%s] status [%08x]: "
> > +			"functional but not present; setting present\n",
> > +			device->pnp.bus_id,
> > +			(u32) STRUCT_TO_INT(device->status));
> > +		device->status.present = 1;
> > +	}
> > +
> >  	ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Device [%s] status [%08x]\n",
> >  		device->pnp.bus_id, (u32) STRUCT_TO_INT(device->status)));
> > 
> > 
> > 
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: Oracle 10g
> > Get certified on the hottest thing ever to hit the market... Oracle 10g. 
> > Take an Oracle 10g class now, and we'll give you the exam FREE.
> > http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> > _______________________________________________
> > Acpi-devel mailing list
> > Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> > https://lists.sourceforge.net/lists/listinfo/acpi-devel
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Sleepycat Software
> Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver
> higher performing products faster, at low TCO.
> http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
> _______________________________________________
> Acpi-devel mailing list
> Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/acpi-devel



-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver
higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Re: [PATCH] fix(Fix _STA checking in acpi_bus_add)

[Bjorn Helgaas]

On Wednesday 12 May 2004 3:49 pm, Len Brown wrote:
> The ACPI spec gurus say that as of 2.0c,
> _STA.functional is meaningless unless _STA.present.
> 
> However, they also say that the (_STA.functional && !_STA.present)
> implementation was intentional -- apparently to trick some OSPM into
> using a resource for initialization only, but to not load
> a driver.

Yup, I think somebody said Windows did something special with
this combination.  Figures.

> I'm advocating that the spec be clarified to explicitly
> allow or disallow this idiom.
> 
> In the mean-time, Bjorn's patch is now present in the acpi-test tree.

Sounds good to me.  Thanks for chasing it down!

Bjorn


-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver
higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Re: [PATCH] fix(Fix _STA checking in acpi_bus_add)

[Bruno Ducrot]

On Wed, Apr 28, 2004 at 09:34:26AM -0600, Bjorn Helgaas wrote:
> On Wednesday 28 April 2004 8:53 am, Simon Derr wrote:
> > On Wed, 28 Apr 2004, Matthew Wilcox wrote:
> > 
> > > Sounds like you have a bug.  Why does your firmware not report that the
> > > device is present?
> > >
> > Yes there is very probably some firmware bug involved, and as a matter of
> > fact we happen to have a 16-way system where the 0xff bus is visible even
> > with recent kernels.
> 
> Is your box based on Intel chipsets and/or firmware?  You might be
> suffering from the problem I described here:
> 
>     https://sourceforge.net/mailarchive/message.php?msg_id=6923358
> 
> Intel firmware seems to describe the PCI root bridge where chipset
> configuration space lives with _STA==0x8.  The spec says this means
> "functional, but not present".  The current Linux code ignores things
> that are "not present".
> 
> Nobody cared enough to do anything about this issue at the time, so
> it is still broken.  I did raise the issue with our ACPI representative,
> but I don't know what happened.  I'd like to see some clarification in
> the spec.
> 

This is only my interpretation of the specs but I think that if bit3 is
set, then that mean the device have been checked at POST time.
But if bit0 is cleared also, that mean that the device is not present,
so far it may be indication of an event like unplugging a laptop from a
station (for example), or a pci card removed in a hotplug system, etc.

Note that even if there is somehow a way to say, hey, that device is
present (via for example a RELAX rule), there is still the problem of
bit1 (device decode ressources, which could be cleared if for example
the device is set to a low power mode).

-- 
Bruno Ducrot

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

RE: [PATCH] fix(Fix _STA checking in acpi_bus_add)

[Yu, Luming]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="us-ascii", Size: 3634 bytes --]

Bob,

I think,  If Bit 3 is set , then Bit 0 can be ignored. Because, If the
device is functioning properly, then the device should be present.
Am I right?

Thanks,
Luming

>-----Original Message-----
>From: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org 
>[mailto:acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] On Behalf Of 
>Bjorn Helgaas
>Sent: Thursday, April 29, 2004 10:47 PM
>To: Simon Derr
>Cc: Matthew Wilcox; acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>Subject: Re: [ACPI] [PATCH] fix(Fix _STA checking in acpi_bus_add)
>
>On Thursday 29 April 2004 2:18 am, Simon Derr wrote:
>> On Wed, 28 Apr 2004, Bjorn Helgaas wrote:
>> 
>> > Is your box based on Intel chipsets and/or firmware?  You might be
>> Indeed.
>> 
>> > suffering from the problem I described here:
>> >
>> >     https://sourceforge.net/mailarchive/message.php?msg_id=6923358
>> >
>> > Intel firmware seems to describe the PCI root bridge where chipset
>> > configuration space lives with _STA==0x8.  The spec says this means
>> > "functional, but not present".  The current Linux code 
>ignores things
>> > that are "not present".
>> 
>> I tried your patch and it works perfectly. Thank you.
>> This chipset/firmware is probably very common in the ia64 
>world so I think
>> it might be a good idea to include your patch in the stock 
>Linux kernel.
>
>Well, the patch is a gross hack for a special case, and I'd be worried
>about it breaking something related to docking or hotplug.  That's why
>I posted it as "RFC" first, in the hope that someone could explain the
>intent behind the Intel firmware.
>
>Given the current ACPI spec, I'd say it's a bug in the Intel firmware,
>and any workaround should be specific to that firmware.  If Intel
>figures out good semantics for what they're trying to do, I think that
>should be reflected in a future spec.
>
>> This is just your patch with updated line offsets, applies cleanly to
>> Linux 2.6.5:
>> 
>> --- linux-2.6.5-vanilla/drivers/acpi/bus.c	Sun Apr  4 05:37:24 2004
>> +++ linux-2.6.5/drivers/acpi/bus.c	Thu Apr 29 09:43:14 2004
>> @@ -112,6 +112,14 @@
>>  	else
>>  		STRUCT_TO_INT(device->status) = 0x0F;
>> 
>> +	if (device->status.functional && !device->status.present) {
>> +		printk(KERN_WARNING PREFIX "Device [%s] status [%08x]: "
>> +			"functional but not present; setting present\n",
>> +			device->pnp.bus_id,
>> +			(u32) STRUCT_TO_INT(device->status));
>> +		device->status.present = 1;
>> +	}
>> +
>>  	ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Device [%s] status [%08x]\n",
>>  		device->pnp.bus_id, (u32) 
>STRUCT_TO_INT(device->status)));
>> 
>> 
>
>-- 
>Bjorn Helgaas - bjorn.helgaas at hp.com
>Linux and Open Source Lab
>Hewlett-Packard Company
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: Oracle 10g
>Get certified on the hottest thing ever to hit the market... 
>Oracle 10g. 
>Take an Oracle 10g class now, and we'll give you the exam FREE.
>http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
>_______________________________________________
>Acpi-devel mailing list
>Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>https://lists.sourceforge.net/lists/listinfo/acpi-devel
>


-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id66&op=click

RE: [PATCH] fix(Fix _STA checking in acpi_bus_add)

[Moore, Robert]

My proposal for spec change to ACPI 3.0:


Section 6.3.6 _STA (Status)

<in the description section>

A special case is where bit 0 is cleared (not present) but bit 3 is set
(device is functional).  This case is used to indicate a valid device
for which no device driver should be loaded (for example, a bridge
device.)  Children of this device may be present and valid, so a device
scan should continue enumeration below a device whose _STA returns this
bit combination.




> -----Original Message-----
> From: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org [mailto:acpi-devel-
> admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] On Behalf Of Bjorn Helgaas
> Sent: Wednesday, May 12, 2004 2:54 PM
> To: Brown, Len
> Cc: Simon Derr; Matthew Wilcox; ACPI Developers
> Subject: Re: [ACPI] [PATCH] fix(Fix _STA checking in acpi_bus_add)
> 
> On Wednesday 12 May 2004 3:49 pm, Len Brown wrote:
> > The ACPI spec gurus say that as of 2.0c,
> > _STA.functional is meaningless unless _STA.present.
> >
> > However, they also say that the (_STA.functional && !_STA.present)
> > implementation was intentional -- apparently to trick some OSPM into
> > using a resource for initialization only, but to not load
> > a driver.
> 
> Yup, I think somebody said Windows did something special with
> this combination.  Figures.
> 
> > I'm advocating that the spec be clarified to explicitly
> > allow or disallow this idiom.
> >
> > In the mean-time, Bjorn's patch is now present in the acpi-test
tree.
> 
> Sounds good to me.  Thanks for chasing it down!
> 
> Bjorn
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Sleepycat Software
> Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to
> deliver
> higher performing products faster, at low TCO.
> http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
> _______________________________________________
> Acpi-devel mailing list
> Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/acpi-devel


-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver
higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3