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

From: Moore, Robert
Date: Thu Feb 09 2006 - 18:12:14 EST


> 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@xxxxxxxxxxxxxxx [mailto:linux-acpi-
> owner@xxxxxxxxxxxxxxx] On Behalf Of Voluspa
> Sent: Thursday, February 09, 2006 3:01 PM
> To: linux-kernel@xxxxxxxxxxxxxxx
> Cc: linux-acpi@xxxxxxxxxxxxxxx; Brown, Len; greg@xxxxxxxxx
> 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@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/