Can you provide acpidmp output, please.
Lowering severity -> There is an acceptable workaround: acpi=ht.

Created attachment 52078 [details]
acpidmp output

Created attachment 52079 [details]
dsdt.dsl

The SSDT is not found, also not exported by acpidmp.
CC'ing Intel people hopefully they could help.

Have you already searched for a BIOS update? You should do that first.
I wonder why acpi=ht helps, need to investigate a bit more...

I've investigating about this issue and...
I founded this report https://bugzilla.novell.com/show_bug.cgi?id=117177, and 
followed these steps 

QUOTE
Could you try to boot with acpi=oldboot.
Then modify /etc/sysconfig/kernel and throw out the processor, thermal and fan
module in the INITRD_MODULES="..." variable. Then invoke mkinitrd.
Also change the ACPI_MODULES variable to
ACPI_MODULES="NONE"
in /etc/sysconfig/powersave/common
and the CPUFREQD_MODULE variable to
CPUFREQD_MODULE="off"
in /etc/sysconfig/powersave/cpufreq
->Reboot
Can you boot now?
/QUOTE

I can boot too :)

QUOTE
Great.
So it is the thermal, fan or processor module that causes the system freeze.
(...)

First you should enable sysreq:
echo 1 >/proc/sys/kernel/sysrq and change ENABLE_SYSRQ="no" to
ENABLE_SYSRQ="yes" in /etc/sysconfig/sysctl. Now, if you hit the <SysReq>
(ALT-Print) and <h> keys you should get a message at the end of
/var/log/messages like:
kernel: SysRq : HELP : loglevel0-8 reBoot Crashdump tErm Full kIll saK showMem
Nice powerOff showPc unRaw Sync showTasks Unmount

I expect the processor module to be the bad one...
Could you try to load the modules step by step manually.
Always wait some seconds after loading a module to be sure that it really does
not freeze the machine. Also have a look into /var/log/messages for error
messages after each step.

First try:
modprobe processor nocst=1
sill running? Then try:
rmmod processor; modprobe processor
sill running? Then try:
modprobe thermal
sill running? Then try:
modprobe fan
/QUOTE

In my case it's obvious that is the processor module the bad one, when i make 
modprobe processor nocst=1, my machine becomes very very slow, when i make 
modprobe -r processor, my machine recovers his normal speed.

After that, because that post almost ends there, i followed this another post 
https://bugzilla.novell.com/show_bug.cgi?id=117974 Which has a link ( http://
www.whoopy.it/linux/ACPI_problem_linux_resolved.html ) to a guide which i 
followed 'till 5th step, and my dsdt.dsl file is the attached above. (It is 
above, 'cause this forum works in a little strange way :p)


I have to say that the acpidmp output if attached is made after throwing out the 
processor, thermal and fan module in the INITRD_MODULES="..." variable in the /
etc/sysconfig/kernel file and rebooting, 'cause i followed those steps in that 
guide before posting this reply. 
I am clarifying this, because i don't know if having erased processor, thermal 
and fan module in the INITRD_MODULES="..." could concern to the acpidmp command 
output...  


I've post all information i have been able, if you need more info ask me, don't 
worry ;). Thanks again.

Created attachment 52085 [details]
Comment out _PDC and cpufreq relevant code where SSDT is tried to be loaded

acpi=ht disables ACPI interpreter, no wonder that you can boot with it.

Still the real error seems to be that the SSDT is not found.
Do you have some additional settings concerning ACPI or Speedstep in BIOS?

You might want to copy the attached file to /etc/DSDT.aml, change the variable
ACPI_DSDT="" to ACPI_DSDT="/etc/DSDT.aml" and call mkinitrd. If you reboot the
processor module should not slow down the system any more?

Be aware that this is also only a bad workaround. If you do hardware changes
like exchanging memory you need to patch the DSDT again. Hopefully Intel could
help to figure out where the SSDT can be found on this system, I cannot.

OperationRegion (SSDT, SystemMemory, 0xFFFF0000, 0xFFFF) in DSDT means that
method PDC tries to load this memory region as SSDT.
Please try to dump it with acpidump --address 0xFFFF0000 --length 0xFFFF -o
memory.aml 

 

The memory and length declaration looks strange.
Maybe 0xFFFF indicates a non-valid length and/or 0xFFFF0000 an invalid address
on M$ OS and the (SSDT) table should not be loaded at all? (Just an idea...)

beginning of dmesg output would be helpful too... there is a list of
BIOS-related memory areas, just to be shure that these addresses are bogus.

Yo: Be careful there are two executables: acpidmp and acpidump.
Use the latter with the options described in #8 (it's actually a similar tool,
but you can also define the exact address you want to dump).
I wouldn't be surpised if the output is empty or something else strange is
happening.

I've made #7, and i don't get the error at the boot yet, but my machine is still slow. 
And about memory exchanges... don't worry, i haven't got anything thinked about any 
hardware exchange :).

I've found a very good page, it is my laptop founded by Serial Number, so it is for 
sure that it provides specifications about my laptop ;) http://support.packardbell.
com/es/mypc/index.php?sernr=100306210247 , may you could get some valuable 
information. 

About BIOS settings concerning ACPI or Speedstep... I've updated my BIOS, (thing which 
hadn't solved the trouble, like you can expect :( ), and i've got checked ACPI 1.0 
support enabled, and Speedstep disabled.

I'll attach my acpidump --addr 0xFFFF0000 --length 0xFFFF -o
memory.aml output, after booting with acpi=ht option, and my dmesg output when i finish 
posting what i'm writting ;) .

Just one more thing.... If i'm going to ask Intel's people where my laptop SSDT is, i 
should know what SSDT is, don't you think so? :p Can you explain me a little or link 
me to an explanation web, please?

I think i don't forget anything... do you need more information, or are thinking about 
any other solution??? 

Created attachment 53635 [details]
acpidump --addr 0xFFFF0000 --length 0xFFFF -o memory.aml output

Created attachment 53636 [details]
dmesg output

If i'm going to ask Intel's people where my laptop SSDT is
  --> Alexey is already in CC.

The dump is everything, but a SSDT.
However I don't know how to debug this any further, any ideas Alexey?
Here some other examples of SSDT declarations:
OperationRegion (SSDT, SystemMemory, 0x1F7D5130, 0x03A3)
OperationRegion (SSDT, SystemMemory, 0x1DFD4050, 0x03CC)
OperationRegion (SSDT, SystemMemory, 0xFFFF0000, 0xFFFF)
The first two look valid.
Not sure for the last one (can't relate the DSDT to any bugreport anymore, but
maybe there was the same problem?).
CC'ing ak: 0xFFFF0000 is not a valid memory address, isn't it?
At least 0xFFFF is not a valid SSDT length.

Alexey/Andi: Do think there should be some code looking for 0xFFFF SSDT length
and/or 0xFFFF0000 SystemMemory address before loading SSDT?

Yo: That your machine still becomes dead slow is strange. Is there something
strange in dmesg when the processor module gets loaded?
What does cat /proc/acpi/processor/*/throttling tell you?
Does echo 0 >/proc/acpi/processor/*/throttling help?
or maybe:
echo 4 >/proc/acpi/processor/*/throttling
and then
echo 0 >/proc/acpi/processor/*/throttling ?

You don't have the p4_clockmod module loaded?

Sorry for the noise, returning AE_BAD_HEADER should be enough?
I still wonder why the machine gets so slow, I expect throttling is activated
wrongly, could you try my last suggestions?
Maybe it helps if you boot without the powersave daemon service (chkconfig
powersaved off)?

SSDT is a "secondary software description table", which contains executable
bytecode differences to DSDT found by BIOS at start-up. So frequency numbers for
CPU is a good example of such code. Any SSDT as a valid ACPI table should have
correct header with the "SSDT" 4 character signature at the beginning, and loading 
of your SSDT fails on checking this header (there are no signature or header at
this address). 

Sorry, i've to go to work, this night when i'll come back i'll try all you say 
me,
Booting with acpi=ht, p4_clockmod is not in the lsmod list.
And, i haven't got /proc/acpi, this folder must be in another location but /
proc, where more must i search?

I don't find anything strange in dmesg, don't you refer to the dmesg output i've 
attached?

I haven't got more time, i'll come back this night (in about 5 hours), see you!

well, I haven't got the /proc/acpi folder, so i cannot make any step from #15, 
may that's the real trouble, in my desktop pc i've got a P3 3.0 Ghz with SuSE 
Linux 9.3, it has that folder and it all works perfect... So, how could i create 
that folder and what should i put into that acpi folder?? 'cause althought i 
change permissions i'm not able to write into /proc...

And booting without powersaved daemon does not change anything.

Some more ideas???

Let's don't mess things up.
If I summarize correctly, you:

   1) boot with acpi=ht and there the ACPI interpreter is disabled and you don't
      get a directory /proc/acpi and your machine is not slow, right?

   2) If you have followed comment #7 and attached the fixed DSDT to your initrd
      you should also be able to boot without acpi=ht and without acpi=off (you 
      possibly need pci=noacpi). In this case you should have a /proc/acpi 
      directory or something really odd is happening (please show us
      /proc/cmdline if this is really the case).

/proc:
Once you mounted /proc (normally done by some early init script) the kernel
automatically places information about your system there. The /proc/acpi folder
for example should just exist if the ACPI interpreter is enabled - you don't
have to generate anything.

I expect that you accidently booted with acpi=ht or acpi=off and therefore you
didn't see the /proc/acpi directory?

Lets see... you've summarized well: first point, right; second: i've followed 
comment #7 and attached the "fixed DSDT" to my initrd, then i don't get the 
"ACPI-1174: *** Error: Method execution failed [\_PR_.CPU2._PDC] (Node dffcedc0
), AE_BAD_HEADER" first error, but my machine is very slow instead. 

I've done a normal boot, without any options, so with acpi and all things by 
default enabled, so, at the slow speed too. And after appearing the "Error - 
Kpowersave: The powersave daemon is not running. Starting it will improve 
performance: /usr/sbin/rcpowersaved start" error at the begining of the kde 
session, (like always happen, it is the same I'd have it enabled or disabled),i 
have been able to make the #15 steps, these are the results:

PortatilLINUX:~ # cat /proc/acpi/processor/*/throttling
state count:             8
active state:            T0
states:
   *T0:                  00%
    T1:                  12%
    T2:                  25%
    T3:                  37%
    T4:                  50%
    T5:                  62%
    T6:                  75%
    T7:                  87%
state count:             8
active state:            T0
states:
   *T0:                  00%
    T1:                  12%
    T2:                  25%
    T3:                  37%
    T4:                  50%
    T5:                  62%
    T6:                  75%
    T7:                  87%
PortatilLINUX:~ # echo 0 >/proc/acpi/processor/*/throttling
bash: /proc/acpi/processor/*/throttling: ambiguous redirect
PortatilLINUX:~ # echo 4 >/proc/acpi/processor/*/throttling
bash: /proc/acpi/processor/*/throttling: ambiguous redirect
PortatilLINUX:~ # echo 0 >/proc/acpi/processor/*/throttling
bash: /proc/acpi/processor/*/throttling: ambiguous redirect
PortatilLINUX:~ #

I hope this would be the information you asked me. But i would like add my /var/
log/boot.msg , 'cause after doing comment #7 steps, and making a normal boot, 
something has changed, take a look at about 84 and at 118 lines

Created attachment 53803 [details]
My /var/log/boot.msg after doing comment #7 step, and making a normal boot

Thomas,
Do you have TM reporting (X86_MCE_P4THERMAL) enabled in the kernel? It seems
that ACPI is ok, but CPU is too hot (75 deg) and this can start automatic
thermal throttling.
Yo, could you please attach output of "cat /proc/acpi/fan/*/* " and "cat
/proc/acpi/thermal_zone/*/*"

Midaircollision... I have the same apprehension:

Thanks for the detailed info, now I get the picture again.

Hmm, what I could imagine happening here is that the temperature (75 degree when
thermal module was loaded) exceeds a passive thermal trip point and your machine
gets throttled.
That would make sense because speedstep does not work. Do you now whether this
machine should support Speedstep? (From DSDT point of few it looks like that and
if it would find the SSDT (where probably the appropriate BIOS functions for
cpufreq can be found) it could work).

If the machine is throttled you should see it in the files that you pasted in
comment #21. Maybe the machine was still cool when you looked into it and the
machine still fast?

Could you watch the temperature and throttling/limit files a while (or just let
this command run in the background and have a look at it when you feel the
machine is really slow - if you copy paste it, be careful to avoid a line break):
watch -n1 cat /proc/acpi/processor/*/{throttling,limit}
/proc/acpi/thermal_zone/*/{trip_points,temperature}

If you encounter very bad slowlyness you might want to redirect the output into
a file and paste here again for verification like:
cat /proc/acpi/processor/*/{throttling,limit}
/proc/acpi/thermal_zone/*/{trip_points,temperature} >/tmp/thermal_limits_output

(X86_MCE_P4THERMAL) enabled in the kernel?
Yes it is enabled. To be honest, I see this the first time...
This is a separate interface and does not export throttling information to
/proc/acpi/processor/*/*?

If it would kick in we should still see some kernel messages, maybe its
initialisation fails?

Yo: Could you also increase the kernel log level in /etc/sysconfig/syslog to 7
and restart the syslog daemon (rcsyslog restart) before doing anything else.
After doing this and rebooting have a look at dmesg when the machine is slow
again. You should see some Intel machine check message(s) after reboot?

Thomas,
There are two ways to init throttling in P4. First is activated automatically by
thermal diode embedded into CPU and it is used to prevent frying CPU with broken
software -- and MCE_P4THERMAL reports such a condition.

First of it all, i've increased the kernel log level in /etc/sysconfig/syslog to 
7, restarted the syslog daemon, and rebooted my laptop with normal boot, very 
slow, i'm going to post /var/log/boot.msg right now.

After that, this is what i've done, and its output:

PortatilLINUX:~ # watch -n1 cat /proc/acpi/processor/*/{throttling,limit} /proc/
acpi/thermal_zone/*/{trip_points,temperature} >/tmp/thermal_limits_output
(now i'll attach the file)
PortatilLINUX:~ # cat /proc/acpi/fan/*/*
cat: /proc/acpi/fan/*/*: No such file or directory
PortatilLINUX:~ # cat /proc/acpi/thermal_zone/*/*
<setting not supported>
cooling mode:   critical
<polling disabled>
state:                   ok
temperature:             75 C
critical (S5):           85 C
PortatilLINUX:~ #

My machine should support Speedstep, because there is a BIOS option in order to 
enable or disable that feature, feature which i've got disabled in the BIOS.

Created attachment 53818 [details]
Booted my laptop with 7th kernel log level

Created attachment 53820 [details]
Command "watch -n1 cat /proc/acpi/processor/*/{throttling,limit} /proc/acpi/thermal_zone/*/{trip_points,temperature} >/tmp/thermal_limits_output" output.

Did you try to run with SpeedStep enabled in BIOS?

Why have you disabled this feature?
Assumption:
Speedstep is disabled -> SSDT which includes speedstep features gets an invalid
address. This is a Pentium4 3,2 GHz inside a laptop -> It gets very hot ->
Machine (even we do not see it in dmesg) gets throttled.

You should use the BIOS exported DSDT again:
Replace ACPI_DSDT="..." to ACPI_DSDT="" in /etc/sysconfig/kernel again.
Call mkinitrd. 
Revert the settings you described in comment #6, so that processor module is
loaded again and cpufreq gets activated.
Reboot, go into BIOS and activate speedstep.

Hopefully speedstep works and everything is fine.

I did it because the explanation the BIOS help gives, is that Speedstep makes 
you cpu go slower depending if you're using battery or cable, so i thinked that 
it would be better that BIOS wouldn't make anything, and would be the SO which 
manage that feature... Suse linux 9.2, was working perfectly, and windows too. 
Because of that i let this feature disabled... Speedstep options Bios gives are: 
Maximun Performance, Battery optimised, Reversed, Automatic, or Disabled.
I'm going to try any of them, if all of them works, i will let it as automatic 
or Maximun Performance. But like in win it works, and in suse linux 9.2 did too, 
i don't think changing this in the BIOS would solucionate the trouble. I'm going 
to try it....

Nothing, changing Speedstep on BIOS doesn't change anything, with every option, 
system is still slow, so i'll let Speedstep as automatic in the bios setup... 
what more can i try?? Where the trouble is??? and what is more important.... How 
do we solucionate it?? :D

Do you have error AE_BAD_HEADER?
Can you update output of acpidump?

No, i don't see that error anywhere... I'm attaching acpidump output, and /var/
log/boot.msg... 

Created attachment 53830 [details]
acpidump output after having enabled Speedstep like automatic in the BIOS, and booted normally

Created attachment 53831 [details]
/var/log/boot.msg with normal boot, and SpeedStep Automatic in BIOS

Ok, SSDT address changed to something meaningfull:
OperationRegion (SSDT, SystemMemory, 0x1FFD40B0, 0xFFFF)
Could you do "acpidump --addr 0x1FFD40B0 --length 0xFFFF -o memory.aml" again?
Also, do you have acpi modules loaded? E.g. did you revert changes from #6?

Yes, i've reverted changes from #6.

Created attachment 53834 [details]
acpidump --addr 0x1FFD40B0 --length 0xFFFF -o memory1.aml output

Is the acpi-cpufreq or speedstep-centrion module loaded?
If not, try it out:
modprobe acpi-cpufreq
modprobe speedstep-centrino

Did you have success with one of them?
If yes and you have a directory /sys/devices/system/cpu/cpu0/cpufreq
start the powersave daemon (rcpowersaved start) and wait a while for the CPU to
cool down.
cat /proc/cpuinfo
should show you a lower value than 3200 MHz now.

speedstep-centrino - sorry

Have you already tried to clean your fan slots?
You would not be the first suffering from thermal problems because the fan is
broken or the slots are dirty.

mmm... i have my slots well cleaned :D, i bought my laptop, 2 months ago, and 
about the fan... i heard how when i boot with acpi=off its's always spining, and 
when i boot normaly it stops and restart, and stop... I supose it's the same fan 
the processor and the power supply one. 

I hadn't have success with both of them... There is still more, i made modprobe 
acpi-cpufreq, all went on the same, and when i made rcpowersaved restart, my 
computer turned off rcpowersaved, but when it should had started it, my computer 
crashed, and then my fan yes it were at the top speed :D.

Tomorrow i will follow your next instructions, now i have to rest, see you!

well... finally we've arrived at the point in which "modprobe acpi_cpufreq" 
freezes my laptop, when i load that module i wait less than a minute, and my 
laptop frezzes. What can i do now??

Not sure, but I think our kernels miss the SSDT double loading check I added
some time ago ...
Do you have AE_ALREADY_EXISTS messages in /var/log/messages now?

If this is the case, this needs to be fixed ...
As a workaround it should work with the setting
CPUFREQD_MODULE="acpi-cpufreq"
in /etc/sysconfig/powersave/cpufreq
and disabling HT in BIOS

This is not a blocker..., but a machine specific thing.

"Do you have AE_ALREADY_EXISTS messages in /var/log/messages now?"

Yes, I've got it, followed by a lot of acpi errors XD. You can see this file attached ;)

"As a workaround it should work with the setting
CPUFREQD_MODULE="acpi-cpufreq"
in /etc/sysconfig/powersave/cpufreq
and disabling HT in BIOS"

The first thing i did, was disabling HT in BIOS, and then it worked at the good speed, after that i set CPUFREQD_MODULE="acpi-cpufreq", and restarted. I've done  it this way just because i read this post in my another computer before boot my laptop.

After setting CPUFREQD_MODULE="acpi-cpufreq" and rebooting the laptop, i still get this error windows when i login in KDE...
"The powersave daemon is not running.
Starting it will improve performance: /usr/sbin/rcpowersaved start"
Shouldn't it always autostart at boot?? At least it have always done so whenever i was making a "custom" SUSE installation...
Although i've got to say that now my laptop differs among the power cable being plugged or unplugged, i think it wasn't able before (it is the same if i do "rcpowersaved start" before or if i don't), may i wasn't patient enough before :p.

OK.... After it all... these are my /var/log/boot.msg; and my /var/log/messages

Trouble now is that i want Hyper Threading support, and this way i got it disabled, isn't it???

(PD: Excuse my weekend being myself out please, sorry :) )

Created attachment 54402 [details]
/var/log/boot.msg after booting like #45

Created attachment 54404 [details]
I found AE_ALREADY_EXISTS messages in /var/log/messages now, this is the file :)

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

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

Could you try out this kernel (could take some hours until ftp server is synced and file is available):
ftp.suse.com/pub/people/trenn/AE_ALREADY_EXISTS_fixed_kernel/kernel-smp-2.6.13-2.i586.rpm
Hopefully this one works with HT on and off...

Somehow Michael is not in CC anymore... I hope this one also works on your P4-HT.

nothing, this kernel, in addition to it's an older than my 2.6.13-15 kernel, doesn't fix the slow speed issue if i check HT in BIOS. Do you need any output??

Do you have also a x86_64 kernel? 

comment #54: The -15 is only the build no., simply ignore it. Do the AE_ALREADY_EXIST messages disappear? Normally the kernel should freeze if they appear? See your comment #44 -> it should not freeze anymore now?

Sorry Thomas, no luck.

My system did not freeze, but I get the same messages as before.
I attach the interesting part of /var/log/messages

If I add "acpi-cpufreq" to CPUFREQD_MODULE in /etc/sysconfig/powersave/cpufreq
everything works fine again.

Created attachment 55985 [details]
/var/log/messages from EM64T system with HT (special kernel)

Aaaarghh.
That means it should also not work with the latest mainline kernel.
I was sure it works and didn't add any debug info.
Could you try this one (be sure the new in the name exists or it is still the old one...):
ftp.suse.com/pub/people/trenn/AE_ALREADY_EXISTS_fixed_kernel/kernel-smp-2.6.13-2_new.*.rpm

This one does not fix anything, but hopefully gives a picture why the tables are still loaded twice.
Could you attach the whole /var/log/message output of the boot this time, please.

Ok, done. See attachement.

Created attachment 56107 [details]
new messages from EM64T

Here is another one, I hope I got it now, x86_64 only.
Michael, could you please try both kernels in:
ftp.suse.com/pub/people/trenn/AE_ALREADY_EXISTS_fixed_kernel

If the without_locking works it should be OK for okir to add it to 10.0.
If not, the with_locking might help for Hyperthreaded machines.
There is a potential long time span between installing the table (is locked) and loading the table into namespace (parsing all table functions -> not locked) that might still cause a table double loading.

What is going on is like:
lock (ACPI_MTX_TABLE)
if (!table already loaded into namespace)
install table
unlock (ACPI_MTX_TABLE)
load table into namespace      (potentially takes a long time -> context switch 
                               -> same table is loaded twice as loaded into 
                               namesspace flag for the table is not set, yet)
set table is loaded into namespace

and it should be:
lock (ACPI_MTX_TABLE)
if (!table already loaded into namespace)
install table
load table into namespace
set table is loaded into namespace
unlock (ACPI_MTX_TABLE)

But this is going over several functions and I need at least help/review from others to get this into 10.0 if it is really necessary.
If nothing works, I give up and wait until I can access such a machine ...

Well, it seems that the kernel oopses are gone. But I still get AE_ALREADY_EXISTS. I'll attache both messages files.

Created attachment 56550 [details]
messages: kernel without locking

Created attachment 56551 [details]
messages: kernel with locking

I asked for help...
For that you should try with the newest kernels (OpenSuse kernel/installation).
If the problem still exists there (what I believe) and we can help the Intel guys to fix it in mainline, it should be easy for me to backport it to 10.0.

Created attachment 60131 [details]
Move checks under MUTEXes...

Please check this patch, may help...

OK, it took me a while to get it... it looks for already installed (memory allocated) tables instead of already loaded into namesspace tables. This was all a bit mixed up together before.

I build a kernel and place it here:
ftp.suse.com/pub/people/trenn/AE_ALREADY_EXISTS_fixed_kernel/kernel-smp-2.6.15_rc5_git5-2.*.rpm
(Could take a while until file is synced).

Be aware that this kernel is built for the latest OpenSuse 10.1 or SLES/NLD10 Previews. It would be nice if someone could check whether the bug with the original kernel there really still exists and if yes, whether the patch from Alexey helps.

If you want your machine to boot with HT enabled for SL10.1, please give it a try...

Is the bug still valid?

No answer for 8 months.
I expect that fixed in latest kernels, please reopen if not.