Bug 147621

Support for this is in patches.suse/acpi_dsdt_initrd_initramfs
This patch is owned by Olaf Hering, assigning to him

Thomas claimed he tested it. In beta2 it was broken. Are you sure it's
with beta3 and not an earlier version?

Ooops, I must have messed up the versions...
It was Beta2, of course.

I've tested Beta3 now, it works.
Please close this bug, sorry.

As requested by reporter.

Why do you want to override your DSDT?
There should come up several fixups in Beta4 that may make overriding of your DSDT unnecessary.

My MainBoard (Asus K8N-VM CSM) is not stable w/o ACPI enabled.
I got some random lockups, and I can reproduce one when I shut down X.
They go away when loading the custom ACPI DSDT and thus enabling ACPI.
Dunno whether I will be able to test Beta4- it's going into production soon.
Can I download the Kernel somewhere already?

There is no beta4 yet - beta3 is only just out.
The latest kernel of the day is always available from ftp.suse.com:/pub/projects/kernel/kotd/

Best you open a separate bug report with acpidmp / hwinfo output for the ACPI
problems.

Please also point me to the changed DSDT or just also attach the modified one.

I got my DSDT from there:
http://acpi.sourceforge.net/dsdt/view.php?id=537


Yes, it is an Asus A8N-VM CSM, i misspelled it above.

Is this a duplicate of this one: #141375 ?
Do you get these messages very early when booting?:
   ACPI-0311: *** Error: ns_search_and_enter: Bad character in ACPI Name: 43035350
    ACPI-0292: *** Error: Looking up [0x43035350] (NON-ASCII)
 in namespace, AE_BAD_CHARACTER
    ACPI-0115: *** Error: acpi_load_tables: Could not load namespace: AE_BAD_CHARACTER
    ACPI-0123: *** Error: acpi_load_tables: Could not load tables: AE_BAD_CHARACTER

*** Bug 141375 has been marked as a duplicate of this bug. ***

Sorry, I hit the submit button, by accident -> modifing title correctly.
a switched byte on x86_64 in ACPI BIOS memory? I wonder whether this is BIOS bug and workarounded by the other OS or could something corrupt a single byte in ACPI memory space?!?
Could you (turboj and Rihards) please check whether you have exactly the same machines or at least the same BIOS/machine vendors.

Could someone check whether a 32-bit kernel works properly?
Theoretically it is possible to install a 32-bit kernel on a 64-bit system, but the names of the kernels would probably crash if you take both from Beta2.
Maybe Andi has an idea how to do it easily.

Or maybe you could just install a minimal 32-bit installation and see if you still get the 
"ACPI-0311: *** Error: ns_search_and_enter: Bad character in ACPI Name:
43035350 "
message?

You can just boot the rescue system. But I doubt it will be any different on 32bit.

Yes you are right, just an idea, because of the nx6125 that has the switched bit, but works for x86 kernels. But there the ACPI subsystem may touch this mem area before -> I still didn't go on with this one because I don't have the machine any more... Here the mem area shouldn't be touched by anything. But starting a rescue system does not take long and should be worth a try?

> Is this a duplicate of this one: #141375 ?
> Do you get these messages very early when booting?:
Yup.
I got _very_ similar looking Messages.
Can't remember exactly, though (havn't copied it).

   ACPI-0311: *** Error: ns_search_and_enter: Bad character in ACPI Name:
43035350
    ACPI-0292: *** Error: Looking up [0x43035350] (NON-ASCII)
 in namespace, AE_BAD_CHARACTER
    ACPI-0115: *** Error: acpi_load_tables: Could not load namespace:
AE_BAD_CHARACTER
    ACPI-0123: *** Error: acpi_load_tables: Could not load tables:
AE_BAD_CHARACTER

I have no direct access to that box anymore so I can't verify it.
But in my memory the error messages look exactly like those above.

It could be a common BIOS bug. BIOS programmers do a lot of cut'n'paste.

But it would be good to double check it in acpidmp. If it's wrong there
too i guess it's pretty unlikely the kernel messes it up.

Created attachment 66642 [details]
acpidmp output from Asus A8N-VM CSM

attached acpidmp output

1. we have different vendors - asus vs asrock (though maybe they are very close judging by name ? :) )

2. my bios information can be found in linked issue :
   Vendor: American Megatrends Inc.
   Version: P1.40

i informed asrock almost a month ago. so far i haven't received any response, no confirmation - anything. latest bios version available for download still is the one machine has installed.

btw, condition reported by turboj is similar to mine - the computer just locks randomly up. i was able to avoid lockups by passing noapic to kernel (though acpi still failed to work because of the switched byte)

i'm thinking about slightly more angry message to asrock - or should we debug some more ?

Looking at the asrock system in the bug closed as dupe of this one:
https://bugzilla.novell.com/show_bug.cgi?id=141375

The illegal character, 0x3, is shown as '*' below
in the Name of the last item in the Processor object:

Processor (CPU2, 0x02, 0x00000000, 0x00)
   ...
   Name (P*SC, 0x0A)

The CPU1 Processor object looks almost the same, except it has "PSSC",
and that is what results here too when updating the binary as Thomas
suggested.

In both cases, this name seems to be un-referenced.  So presumably
the MS implementation is (silently?) throwing it away with no mal effect.
(It is a bug in the MS compiler that it generated this
code in the first place, and presumably the Windows interpreter
is bug compatible:-)

ACPICA chokes all over this error, in the dis-assembler, compiler,
and the interpreter -- in all cases fatal.

The iasl disassembler can grok the original corrupted DSDT
if you ignore the error like so:

--- namespace/nssearch.c        2006-02-09 01:12:19.000000000 -0500
+++ namespace/nssearch.c.orig   2006-02-09 01:55:25.000000000 -0500
@@ -403,7 +403,7 @@ AcpiNsSearchAndEnter (
     {
         ACPI_ERROR ((AE_INFO, "Bad character in ACPI Name: %X",
             TargetName));
-//        return_ACPI_STATUS (AE_BAD_CHARACTER);
+        return_ACPI_STATUS (AE_BAD_CHARACTER);
     }

     /* Try to find the name in the namespace level specified by the caller */

Created attachment 67125 [details]
test patch vs 2.6.16-rc2 nssearch.c

This is a test patch to ignore the illegal names
bytes in the kernel just like we ignored them
in the dis-assembler above.

It may be somewhat reckless to do this,
but please give it a go so we can see if it helps.
(and if we should do something like it, but perhaps
 slightly less reckless:-)

*** Bug 149922 has been marked as a duplicate of this bug. ***

I guess we should apply the patch. These switched bytes seem to be really
common. Len is it ok to apply the patch from #22 for the next beta or do
you want to do a better one first?

I'd sure like to see some feedback from (any of) the bug submitters
that the patch in comment #22 makes a difference and doesn't have
any bad effect...

BTW. it isn't really "switched bytes", it is the presence of
unprintable characters in identifier names.  Possibly this corruption
happened at the BIOS vendor and is being copied to multiple platforms.

Created attachment 67906 [details]
ASUS A8R-MVP With ACPI support in bios: dmesg

I have applied the patch on 2.6.16-rc1-git3-7-smp. I also tried to apply it on 2.6.16-rc2, but I was unsuccesful to make it work. I'm sure this is because it's my first time to rebuild a kernel. 

My problem (Bug 149922) was that only one of the two cores was brought up on my ASUS A8R-MVP board. With the patched kernel (2.6.16-rc1-git3-7-smp) both CPU where 
brought up, but only after I changed the bios to switch on "ACPI 2.0 Support" and  enabling "ACPI APIC support". The non-patched kernel could not boot with these settings. 

With the patched kernel, but without the bios changes still only one CPU was brought up. I have attached the dmesg with and without support for ACPI in bios.

Created attachment 67912 [details]
ASUS A8R-MVP without ACPI support in bios

The mptables that are used as fallback from ACPI are broken on your
system and don't list all CPUs. Hardly uncommon because they are normally
not used anymore so the mobo vendors don't care much about them.
I think we can ignore that no ACPI failure. Just don't do that when it hurts.

I applied Len's patch. Thanks. Len, can you please push it for mainline too?

-------------------------------------------------------------------
Mon Feb 13 11:41:25 CET 2006 - ak@suse.de

- patches.arch/acpi-ignore-bad-names: Ignore bad characters in
  ACPI names (SUSE147621).

fixed in ACPICA 20060331, which shipped in Linux-2.6.17-git9.