[2.6.16-rc2] Error - nsxfeval - And uncool silence from kernel hackers.

[2.6.16-rc2] Error - nsxfeval - And uncool silence from kernel hackers.

[Voluspa]

Booted 2.6.16-rc2 on my AMD x86_64 notebook and saw something new in the
log (different from 2.6.15):

ACPI: Subsystem revision 20060127
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI Error (nsxfeval-0242): Handle is NULL and Pathname is relative [20060127]

[Same error repeated 3 more times]

Searching the archives gives:

linux-2.6.16-rc1-mm2: new ACPI errors [2006-01-21]
http://marc.theaimsgroup.com/?l=linux-acpi&m=113786840630844&w=2

Wherein the reporter points to a previous display of a similar looking
message (but not exactly like it) in:

Re: 2.6.12.3 clock drifting twice too fast (amd64) [2005-08-17]
http://marc.theaimsgroup.com/?l=linux-kernel&m=112428492427357&w=2

He did not receive any reply/response to his report and that is a MAJOR
error as far as kernel programmer <--> kernel tester relationship goes.

If the error is harmless, then for the love of Embla just jot down a
quick reply, and hide the freakin message from user eyes. Now I have
to waste additional time asking the same thing: "Is this a real error?
Is it OK for my dsdt to lack these _PRx objects?".

My machine doesn't seem to behave differently from 2.6.15 so a gut
feeling says 'Disregard the message'. But will the message now linger on
just like that PCI error message that never got any love (yeah Greg KH,
I'm blaming you here):

Re: PCI error on x86_64 2.6.13 kernel [2005-11-19]
http://marc.theaimsgroup.com/?l=linux-kernel&m=113236418300012&w=2

In that message you ask me to do a git bisect, Greg, since I had seen
when the message first turned up. So I did, and identified the offender
as git-299de0343c7d18448a69c635378342e9214b14af After that... complete
silence, not even an ACK.

And the PCI error _still_ stares a user in the face, 3 months later in
2.6.16-rc2:

PCI: Failed to allocate mem resource #6:20000@f0000000 for 0000:01:00.0

You've written a slew of documents about how users, testers and patch
submitters should behave towards the linux kernel hackers, Greg.
Perhaps it's time to point the pen in the other direction. Let me start
the job for you:

"1) Silence is _not_ golden."

Please, we the users breathe and bleed just like you do.

As for the PCI error, I made a patch against 2.6.15-rc6 backing out the
offending parts. The message went away and nothing bad happened to my
machine:

diff -Nur linux-2.6.15-rc6-clean/arch/i386/pci/i386.c linux-2.6.15-rc6-hacked/arch/i386/pci/i386.c
--- linux-2.6.15-rc6-clean/arch/i386/pci/i386.c	2005-12-21 19:10:20.000000000 +0100
+++ linux-2.6.15-rc6-hacked/arch/i386/pci/i386.c	2005-12-21 19:15:03.000000000 +0100
@@ -106,16 +106,11 @@
 		if ((dev = bus->self)) {
 			for (idx = PCI_BRIDGE_RESOURCES; idx < PCI_NUM_RESOURCES; idx++) {
 				r = &dev->resource[idx];
-				if (!r->flags)
+				if (!r->start)
 					continue;
 				pr = pci_find_parent_resource(dev, r);
-				if (!r->start || !pr || request_resource(pr, r) < 0) {
+				if (!pr || request_resource(pr, r) < 0)
 					printk(KERN_ERR "PCI: Cannot allocate resource region %d of bridge %s\n", idx, pci_name(dev));
-					/* Something is wrong with the region.
-					   Invalidate the resource to prevent child
-					   resource allocations in this range. */
-					r->flags = 0;
-				}
 			}
 		}
 		pcibios_allocate_bus_resources(&bus->children);
@@ -188,8 +183,6 @@
 		}
 	}
 
-	pci_assign_unassigned_resources();
-
 	return 0;
 }
 
@@ -215,7 +208,7 @@
 
 	pci_read_config_word(dev, PCI_COMMAND, &cmd);
 	old_cmd = cmd;
-	for(idx = 0; idx < PCI_NUM_RESOURCES; idx++) {
+	for(idx=0; idx<6; idx++) {
 		/* Only set up the requested stuff */
 		if (!(mask & (1<<idx)))
 			continue;
diff -Nur linux-2.6.15-rc6-clean/drivers/pci/setup-bus.c linux-2.6.15-rc6-hacked/drivers/pci/setup-bus.c
--- linux-2.6.15-rc6-clean/drivers/pci/setup-bus.c	2005-10-28 02:02:08.000000000 +0200
+++ linux-2.6.15-rc6-hacked/drivers/pci/setup-bus.c	2005-12-21 19:12:49.000000000 +0100
@@ -268,8 +268,6 @@
 
 	for (i = 0; i < PCI_BUS_NUM_RESOURCES; i++) {
 		r = bus->resource[i];
-		if (r == &ioport_resource || r == &iomem_resource)
-			continue;
 		if (r && (r->flags & type_mask) == type && !r->parent)
 			return r;
 	}



Mvh
Mats Johannesson
--

Re: [2.6.16-rc2] Error - nsxfeval - And uncool silence from kernel hackers.

[Greg KH]

On Fri, Feb 10, 2006 at 12:01:01AM +0100, Voluspa wrote:
> 
> Booted 2.6.16-rc2 on my AMD x86_64 notebook and saw something new in the
> log (different from 2.6.15):

So, 2.6.16-rc2 works just fine, with out your reversal of that one
patch?

> "1) Silence is _not_ golden."
> 
> Please, we the users breathe and bleed just like you do.

Sorry, and like you, we are human and drop things on the floor all the
time.  Sorry for not following up on this before.

Persistance is a good trait to have when dealing with overworked kernel
developers :)

thanks,

greg k-h

Re: [2.6.16-rc2] Error - nsxfeval - And uncool silence from kernel hackers.

[Voluspa]

On Thu, 9 Feb 2006 15:32:33 -0800 Greg KH wrote:
> On Fri, Feb 10, 2006 at 12:01:01AM +0100, Voluspa wrote:
> > 
> > Booted 2.6.16-rc2 on my AMD x86_64 notebook and saw something new in the
> > log (different from 2.6.15):
> 
> So, 2.6.16-rc2 works just fine, with out your reversal of that one
> patch?

Eh, I bundled two issues in my rant. 1) nsxfeval, which the ACPI guys
have confirmed is pure noise and can be forgotten. 2) "PCI: Failed to
allocate mem resource" which has been there since the commit I pointed
to, and never has effected the machine negatively (as far as I can tell).
So yes, 2.6.16-rc2 seems fine, and I don't patch it for that PCI thing.
It's just that the message is present and will worry people 'forever'
if nothing is done.

There is another issue, but it's not a regression. I'll file a
bugzilla for that in a couple of days. Or a week...

> > "1) Silence is _not_ golden."
> > 
> > Please, we the users breathe and bleed just like you do.
> 
> Sorry, and like you, we are human and drop things on the floor all the
> time.  Sorry for not following up on this before.
> 
> Persistance is a good trait to have when dealing with overworked kernel
> developers :)

Yeah, I know, sorry if I jabbed too hard. I was caught up in a sadness for
anyone who's mail is ignored. There is a form of humiliation when that
happens on a high profile list like lkml or other kernel related lists.
A mirror of the defeat can be found on a small server in Korpilombolo for
the next two decades at least.

But I must say that during the years that I've read lkml, it _feels_ as if
the reply-rate has improved significantly. The list is not as terrifying as
it used to be.

Mvh
Mats Johannesson
--

Re: [2.6.16-rc2] Error - nsxfeval - And uncool silence from kernel hackers.

[Greg KH]

On Fri, Feb 10, 2006 at 03:50:51AM +0100, Voluspa wrote:
> On Thu, 9 Feb 2006 15:32:33 -0800 Greg KH wrote:
> > On Fri, Feb 10, 2006 at 12:01:01AM +0100, Voluspa wrote:
> > > 
> > > Booted 2.6.16-rc2 on my AMD x86_64 notebook and saw something new in the
> > > log (different from 2.6.15):
> > 
> > So, 2.6.16-rc2 works just fine, with out your reversal of that one
> > patch?
> 
> Eh, I bundled two issues in my rant. 1) nsxfeval, which the ACPI guys
> have confirmed is pure noise and can be forgotten. 2) "PCI: Failed to
> allocate mem resource" which has been there since the commit I pointed
> to, and never has effected the machine negatively (as far as I can tell).
> So yes, 2.6.16-rc2 seems fine, and I don't patch it for that PCI thing.
> It's just that the message is present and will worry people 'forever'
> if nothing is done.

As long as everything is working properly, you can happily ignore the
issue and blame your bios vendor for making such a stupid mistake :)

> Yeah, I know, sorry if I jabbed too hard. I was caught up in a sadness for
> anyone who's mail is ignored. There is a form of humiliation when that
> happens on a high profile list like lkml or other kernel related lists.
> A mirror of the defeat can be found on a small server in Korpilombolo for
> the next two decades at least.

I know it's tough when things like this are ignored, and no, you didn't
jab to hard at all.  We all need to be reminded when we forget things
like this, myself especially at times :)

> But I must say that during the years that I've read lkml, it _feels_ as if
> the reply-rate has improved significantly. The list is not as terrifying as
> it used to be.

Glad to hear it, we are trying here...

thanks,

greg k-h

Re: [2.6.16-rc2] Error - nsxfeval - And uncool silence from kernel hackers.

[Tako Schotanus]

Greg KH wrote:

>On Fri, Feb 10, 2006 at 03:50:51AM +0100, Voluspa wrote:
>  
>
>>Yeah, I know, sorry if I jabbed too hard. I was caught up in a sadness for
>>anyone who's mail is ignored. There is a form of humiliation when that
>>happens on a high profile list like lkml or other kernel related lists.
>>A mirror of the defeat can be found on a small server in Korpilombolo for
>>the next two decades at least.
>>    
>>
>
>I know it's tough when things like this are ignored, and no, you didn't
>jab to hard at all.  We all need to be reminded when we forget things
>like this, myself especially at times :)
>  
>
Well, I still got an unanswered message here: 
http://marc.theaimsgroup.com/?l=linux-acpi&m=113924047806727&w=2

:-)

Might have been such a stupid question as not to warrant any attention, 
but even a "oh please leave us alone" would be better than this dratted 
silence hehe

Cheers,
 -Tako

Re: [2.6.16-rc2] Error - nsxfeval - And uncool silence from kernel hackers.

[Erik Slagter]

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

On Sun, 2006-02-12 at 14:05 +0100, Tako Schotanus wrote:

> Might have been such a stupid question as not to warrant any attention, 
> but even a "oh please leave us alone" would be better than this dratted 
> silence hehe

Don't be sad, it's probably just that nobody knows how to tackle the
problem.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 2771 bytes --]

Re: [2.6.16-rc2] Error - nsxfeval - And uncool silence from kernel hackers.

[Tako Schotanus]

Erik Slagter wrote:
> On Sun, 2006-02-12 at 14:05 +0100, Tako Schotanus wrote:
>
>   
>> Might have been such a stupid question as not to warrant any attention, 
>> but even a "oh please leave us alone" would be better than this dratted 
>> silence hehe
>>     
>
> Don't be sad, it's probably just that nobody knows how to tackle the
> problem.
>   
Ok, I'll try not to be :-)

But nobody who has even a hint or a tip where I could begin to look for 
an answer?

For example: IS there actually a difference between a system that has 
been shut down and woken up again and a system that has been reset? I 
just don't understand how I can get these errors when waking up the 
system but that they go away if I quickly press the reset button after 
waking the system.

Clutching at straws here! :-)

Cheers,
 -Tako

RE: [2.6.16-rc2] Error - nsxfeval - And uncool silence from kernel hackers.

[Moore, Robert]

> ACPI Error (nsxfeval-0242): Handle is NULL and Pathname is relative
> [20060127]

This is an extraneous message and has been removed.

We recently changed all of the DEBUG_PRINT statements with error and
warning levels to ACPI_ERROR and ACPI_WARNING. There have been a couple
of messages that now pop out inappropriately, and they have been fixed.



> -----Original Message-----
> From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-
> owner@vger.kernel.org] On Behalf Of Voluspa
> Sent: Thursday, February 09, 2006 3:01 PM
> To: linux-kernel@vger.kernel.org
> Cc: linux-acpi@vger.kernel.org; Brown, Len; greg@kroah.com
> Subject: [2.6.16-rc2] Error - nsxfeval - And uncool silence from
kernel
> hackers.
> 
> 
> Booted 2.6.16-rc2 on my AMD x86_64 notebook and saw something new in
the
> log (different from 2.6.15):
> 
> ACPI: Subsystem revision 20060127
> ACPI: Interpreter enabled
> ACPI: Using IOAPIC for interrupt routing
> ACPI Error (nsxfeval-0242): Handle is NULL and Pathname is relative
> [20060127]
> 
> [Same error repeated 3 more times]
> 
> Searching the archives gives:
> 
> linux-2.6.16-rc1-mm2: new ACPI errors [2006-01-21]
> http://marc.theaimsgroup.com/?l=linux-acpi&m=113786840630844&w=2
> 
> Wherein the reporter points to a previous display of a similar looking
> message (but not exactly like it) in:
> 
> Re: 2.6.12.3 clock drifting twice too fast (amd64) [2005-08-17]
> http://marc.theaimsgroup.com/?l=linux-kernel&m=112428492427357&w=2
> 
> He did not receive any reply/response to his report and that is a
MAJOR
> error as far as kernel programmer <--> kernel tester relationship
goes.
> 
> If the error is harmless, then for the love of Embla just jot down a
> quick reply, and hide the freakin message from user eyes. Now I have
> to waste additional time asking the same thing: "Is this a real error?
> Is it OK for my dsdt to lack these _PRx objects?".
> 
> My machine doesn't seem to behave differently from 2.6.15 so a gut
> feeling says 'Disregard the message'. But will the message now linger
on
> just like that PCI error message that never got any love (yeah Greg
KH,
> I'm blaming you here):
> 
> Re: PCI error on x86_64 2.6.13 kernel [2005-11-19]
> http://marc.theaimsgroup.com/?l=linux-kernel&m=113236418300012&w=2
> 
> In that message you ask me to do a git bisect, Greg, since I had seen
> when the message first turned up. So I did, and identified the
offender
> as git-299de0343c7d18448a69c635378342e9214b14af After that... complete
> silence, not even an ACK.
> 
> And the PCI error _still_ stares a user in the face, 3 months later in
> 2.6.16-rc2:
> 
> PCI: Failed to allocate mem resource #6:20000@f0000000 for
0000:01:00.0
> 
> You've written a slew of documents about how users, testers and patch
> submitters should behave towards the linux kernel hackers, Greg.
> Perhaps it's time to point the pen in the other direction. Let me
start
> the job for you:
> 
> "1) Silence is _not_ golden."
> 
> Please, we the users breathe and bleed just like you do.
> 
> As for the PCI error, I made a patch against 2.6.15-rc6 backing out
the
> offending parts. The message went away and nothing bad happened to my
> machine:
> 
> diff -Nur linux-2.6.15-rc6-clean/arch/i386/pci/i386.c
linux-2.6.15-rc6-
> hacked/arch/i386/pci/i386.c
> --- linux-2.6.15-rc6-clean/arch/i386/pci/i386.c	2005-12-21
> 19:10:20.000000000 +0100
> +++ linux-2.6.15-rc6-hacked/arch/i386/pci/i386.c	2005-12-21
> 19:15:03.000000000 +0100
> @@ -106,16 +106,11 @@
>  		if ((dev = bus->self)) {
>  			for (idx = PCI_BRIDGE_RESOURCES; idx <
> PCI_NUM_RESOURCES; idx++) {
>  				r = &dev->resource[idx];
> -				if (!r->flags)
> +				if (!r->start)
>  					continue;
>  				pr = pci_find_parent_resource(dev, r);
> -				if (!r->start || !pr ||
request_resource(pr, r) <
> 0) {
> +				if (!pr || request_resource(pr, r) < 0)
>  					printk(KERN_ERR "PCI: Cannot
allocate
> resource region %d of bridge %s\n", idx, pci_name(dev));
> -					/* Something is wrong with the
region.
> -					   Invalidate the resource to
prevent child
> -					   resource allocations in this
range. */
> -					r->flags = 0;
> -				}
>  			}
>  		}
>  		pcibios_allocate_bus_resources(&bus->children);
> @@ -188,8 +183,6 @@
>  		}
>  	}
> 
> -	pci_assign_unassigned_resources();
> -
>  	return 0;
>  }
> 
> @@ -215,7 +208,7 @@
> 
>  	pci_read_config_word(dev, PCI_COMMAND, &cmd);
>  	old_cmd = cmd;
> -	for(idx = 0; idx < PCI_NUM_RESOURCES; idx++) {
> +	for(idx=0; idx<6; idx++) {
>  		/* Only set up the requested stuff */
>  		if (!(mask & (1<<idx)))
>  			continue;
> diff -Nur linux-2.6.15-rc6-clean/drivers/pci/setup-bus.c
linux-2.6.15-rc6-
> hacked/drivers/pci/setup-bus.c
> --- linux-2.6.15-rc6-clean/drivers/pci/setup-bus.c	2005-10-28
> 02:02:08.000000000 +0200
> +++ linux-2.6.15-rc6-hacked/drivers/pci/setup-bus.c	2005-12-21
> 19:12:49.000000000 +0100
> @@ -268,8 +268,6 @@
> 
>  	for (i = 0; i < PCI_BUS_NUM_RESOURCES; i++) {
>  		r = bus->resource[i];
> -		if (r == &ioport_resource || r == &iomem_resource)
> -			continue;
>  		if (r && (r->flags & type_mask) == type && !r->parent)
>  			return r;
>  	}
> 
> 
> 
> Mvh
> Mats Johannesson
> --
> -
> 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: [2.6.16-rc2] Error - nsxfeval - And uncool silence from kernel hackers.

[Voluspa]

On Thu, 9 Feb 2006 15:13:51 -0800 Moore, Robert wrote:
> > ACPI Error (nsxfeval-0242): Handle is NULL and Pathname is relative
> > [20060127]
> 
> This is an extraneous message and has been removed.
> 
> We recently changed all of the DEBUG_PRINT statements with error and
> warning levels to ACPI_ERROR and ACPI_WARNING. There have been a couple
> of messages that now pop out inappropriately, and they have been fixed.

Thank you for the quick jot down. Now the answer is archived for others.

Mvh
Mats Johannesson
--