ACPI on Compaq 6715b - BIOS from the wrong end of the planet

Hi all,

Pardon for the intrusion, I am trying to fault find a horrible wrong ACPI interface and fix it.

the problem is as follows...

Kernel 2.6.23 works fine, except there is no stable clocksource.. acpi_pm, tsc doesnt work and jiffies .. well thats just jiffies. The kernel boots but time sources are erratic and this results in an unstable clock (Mp3's play at erratic speeds)

Kernel 2.6.25 hangs the system if I enable ACPI Timer and rebuild/boot the new linux kernel. The only clock sources are tsc and jiffies and TSC is disables due to being erratic. If I totally disable ACPI, the kernel boots and works with stable clocks.. but obviously Power management is gone.

The system is an ATI bridged AMD Sempron notebook. I have tried Millions of options in the kernel bootup and none seem to do clear the problem. This system seems to suffer from the Clocks fast bug. (the dmesg reports that the 8254 clock is disables, IO-APIC int0 fails and IO-APIC Vritual wire is OK.. if that means anything :D)

Any pointers.. and if anyone wants the AML/ACPI stuff, please feel free to shout.

Quoted 6 lines · Richard

Hi all,

Pardon for the intrusion, I am trying to fault find a horrible wrong ACPI interface and fix it.

the problem is as follows...

Quoted 8 lines

Kernel 2.6.23 works fine, except there is no stable clocksource.. acpi_pm, tsc doesnt work and jiffies .. well thats just jiffies. The kernel boots but time sources are erratic and this results in an unstable clock (Mp3's play at erratic speeds)

Kernel 2.6.25 hangs the system if I enable ACPI Timer and rebuild/boot the new linux kernel. The only clock sources are tsc and jiffies and TSC is disables due to being erratic. If I totally disable ACPI, the kernel boots and works with stable clocks.. but obviously Power management is gone.

The system is an ATI bridged AMD Sempron notebook. I have tried Millions of options in the kernel bootup and none seem to do clear the problem. This system seems to suffer from the Clocks fast bug. (the dmesg reports that the 8254 clock is disables, IO-APIC int0 fails and IO-APIC Vritual wire is OK.. if that means anything :D)

Any pointers.. and if anyone wants the AML/ACPI stuff, please feel free to shout.

Does:
disable_timer_pin_1
or
noapictimer
work?

Thomas

Quoted 29 lines · Thomas Renninger

Quoted 18 lines · Richard

Hi all,

Pardon for the intrusion, I am trying to fault find a horrible wrong ACPI interface and fix it.

the problem is as follows...

Kernel 2.6.23 works fine, except there is no stable clocksource.. acpi_pm, tsc doesnt work and jiffies .. well thats just jiffies. The kernel boots but time sources are erratic and this results in an unstable clock (Mp3's play at erratic speeds)

Kernel 2.6.25 hangs the system if I enable ACPI Timer and rebuild/boot the new linux kernel. The only clock sources are tsc and jiffies and TSC is disables due to being erratic. If I totally disable ACPI, the kernel boots and works with stable clocks.. but obviously Power management is gone.

Quoted 9 lines

The system is an ATI bridged AMD Sempron notebook. I have tried Millions of options in the kernel bootup and none seem to do clear the problem. This system seems to suffer from the Clocks fast bug. (the dmesg reports that the 8254 clock is disables, IO-APIC int0 fails and IO-APIC Vritual wire is OK.. if that means anything :D)

Any pointers.. and if anyone wants the AML/ACPI stuff, please feel free to shout.

Quoted 10 lines

Does:
disable_timer_pin_1
or
noapictimer
work?

Thomas

Thanks a Million..
noapictimer works perfectly ... BUT .. only on 64Bit. acpi_pm is not present on 32bit as a clocksource and it defaulted to jiffies. (tsc was marked as imreliable)

I am really surprised that this Sempron notebook actually had 64Bit CPU compatibility :D

Quoted 5 lines

Quoted 1 line

Thanks a Million..
noapictimer works perfectly ... BUT .. only on 64Bit. acpi_pm is not present on 32bit as a clocksource and it defaulted to jiffies. (tsc was marked as imreliable)

I am really surprised that this Sempron notebook actually had 64Bit CPU compatibility :D

This one helps for my Turion.
AFAIK, another Turion (very similar) does not need this, but I do not know for sure.

Quoted 6 lines · Thomas Renninger

Quoted 5 lines

Quoted 1 line

Thanks a Million..
noapictimer works perfectly ... BUT .. only on 64Bit. acpi_pm is not present on 32bit as a clocksource and it defaulted to jiffies. (tsc was marked as imreliable)

I am really surprised that this Sempron notebook actually had 64Bit CPU compatibility :D

Quoted 4 lines

This one helps for my Turion.
AFAIK, another Turion (very similar) does not need this, but I do not know for sure.

Is the common denominator here the Turion (and if so, what model number), or is it the mainboard or BIOS? If the latter, it should be keyed on a DMI signature instead of the CPU.

-hpa

Quoted 9 lines · Thomas Renninger

Quoted 8 lines

Quoted 1 line

Thanks a Million..
noapictimer works perfectly ... BUT .. only on 64Bit. acpi_pm is not present on 32bit as a clocksource and it defaulted to jiffies. (tsc was marked as imreliable)

I am really surprised that this Sempron notebook actually had 64Bit CPU compatibility :D

Quoted 4 lines

This one helps for my Turion.
AFAIK, another Turion (very similar) does not need this, but I do not know for sure.

Is the common denominator here the Turion (and if so, what model number), or is it the mainboard or BIOS? If the latter, it should be keyed on a DMI signature instead of the CPU.

Quoted 7 lines · H. Peter Anvin

Quoted 5 lines · Thomas Renninger

Quoted 5 lines

Quoted 2 lines

Thanks a Million..
noapictimer works perfectly ... BUT .. only on 64Bit. acpi_pm is not present on 32bit as a clocksource and it defaulted to jiffies. (tsc was marked as imreliable)

Quoted 9 lines

Quoted 7 lines

Quoted 2 lines

I am really surprised that this Sempron notebook actually had 64Bit CPU compatibility :D

This one helps for my Turion.
AFAIK, another Turion (very similar) does not need this, but I do not know for sure.

Is the common denominator here the Turion (and if so, what model number), or is it the mainboard or BIOS? If the latter, it should be keyed on a DMI signature instead of the CPU.

noapictimer is needed on machines with C1E (when all cores issue C1, the BIOS may decide to shut down more things, like the apic timer...). Therefore the checking for C1E (in arch/x86/setup_64.c amd_apic_timer_broken(..)). The check for C1E is done for K8 RevF, K10 and K11. I now expect it simply has been forgotten that K8 RevE CPUs may also have C1E (maybe only mobile Turion and Semprons, could the check below be enhanced to only check mobile CPUs?)?

This patch should also check for RevE with more than one core. It's untested, but should compile. Does this one work for you Richard?

Also check for broken apic timer for RevE multi core machines

Signed-off-by Thomas Renninger <[email protected]>

Index: linux-2.6/arch/x86/kernel/setup_64.c
===================================================================

arch/x86/kernel/setup_64.c +1 -1

@@ -686,7 +686,7 @@ static void __cpuinit early_init_amd_mc(
 #define CPUID_XFAM_10H		0x00100000
 #define CPUID_XFAM_11H		0x00200000
 #define CPUID_XMOD		0x000f0000
-#define CPUID_XMOD_REV_F	0x00040000
+#define CPUID_XMOD_REV_E	0x00020000
 
 /* AMD systems with C1E don't have a working lAPIC timer. Check for that. */
 static __cpuinit int amd_apic_timer_broken(void)

Quoted 51 lines · Thomas Renninger

Quoted 12 lines · H. Peter Anvin

Quoted 10 lines · Thomas Renninger

Quoted 10 lines

Quoted 2 lines

Thanks a Million..
noapictimer works perfectly ... BUT .. only on 64Bit. acpi_pm is not present on 32bit as a clocksource and it defaulted to jiffies. (tsc was marked as imreliable)

I am really surprised that this Sempron notebook actually had 64Bit CPU compatibility :D

Quoted 9 lines

Quoted 5 lines

This one helps for my Turion.
AFAIK, another Turion (very similar) does not need this, but I do not know for sure.

Is the common denominator here the Turion (and if so, what model number), or is it the mainboard or BIOS? If the latter, it should be keyed on a DMI signature instead of the CPU.

noapictimer is needed on machines with C1E (when all cores issue C1, the BIOS may decide to shut down more things, like the apic timer...). Therefore the checking for C1E (in arch/x86/setup_64.c amd_apic_timer_broken(..)). The check for C1E is done for K8 RevF, K10 and K11. I now expect it simply has been forgotten that K8 RevE CPUs may also have C1E (maybe only mobile Turion and Semprons, could the check below be enhanced to only check mobile CPUs?)?

This patch should also check for RevE with more than one core. It's untested, but should compile. Does this one work for you Richard?

Also check for broken apic timer for RevE multi core machines

Signed-off-by Thomas Renninger <[email protected]>

Index: linux-2.6/arch/x86/kernel/setup_64.c
===================================================================

arch/x86/kernel/setup_64.c +1 -1

@@ -686,7 +686,7 @@ static void __cpuinit early_init_amd_mc(
 #define CPUID_XFAM_10H		0x00100000
 #define CPUID_XFAM_11H		0x00200000
 #define CPUID_XMOD		0x000f0000
-#define CPUID_XMOD_REV_F	0x00040000
+#define CPUID_XMOD_REV_E	0x00020000
 

arch/x86/kernel/setup_64.c static __cpuinit int amd_apic_timer_brok · line 698

Quoted 8 lines

arch/x86/kernel/setup_64.c +1 -1

 /* AMD systems with C1E don't have a working lAPIC timer. Check for that. */
 static __cpuinit int amd_apic_timer_broken(void)

@@ -695,7 +695,9 @@ static __cpuinit int amd_apic_timer_brok
 
 	switch (eax & CPUID_XFAM) {
 	case CPUID_XFAM_K8:
-		if ((eax & CPUID_XMOD) < CPUID_XMOD_REV_F)
+		if ((eax & CPUID_XMOD) < CPUID_XMOD_REV_E)

arch/x86/kernel/setup_64.c static __cpuinit int amd_apic_timer_brok · line 699

Quoted 1 line

arch/x86/kernel/setup_64.c +1 -0

+			break;

arch/x86/kernel/setup_64.c static __cpuinit int amd_apic_timer_brok · line 700

Quoted 1 line

arch/x86/kernel/setup_64.c +1 -0

+		if (num_online_cpus() < 2)

arch/x86/kernel/setup_64.c static __cpuinit int amd_apic_timer_brok · line 701

Quoted 1 line

arch/x86/kernel/setup_64.c +0 -0

 			break;

arch/x86/kernel/setup_64.c static __cpuinit int amd_apic_timer_brok · line 703

Quoted 2 lines

arch/x86/kernel/setup_64.c +0 -0

 	case CPUID_XFAM_10H:
 	case CPUID_XFAM_11H:

Quoted 3 lines

Hi there,

The results are in.. and the patch done nothing on my notebook. The symptoms are exactly the same as before. Kernel loads, INIT starts and then the machine shuts down a few seconds later. noapictimer still fixes it tho'

Also something at the C1E check which should come here then, does it match?
Maybe it really is a RevE and the second CPU is not brought up yet?

Quoted 6 lines

Quoted 2 lines

Hi there,

The results are in.. and the patch done nothing on my notebook. The symptoms are exactly the same as before. Kernel loads, INIT starts and then the machine shuts down a few seconds later. noapictimer still fixes it tho'

Googled this:
Sempron 3600+ (CN),256K,rev.F2,62W,SocketAM2 ALL 0107
So this Sempron probably is RevF already but the C1E check does not work?
Hope you still have the kernel compiled flying around?
Could you add a lot printks at the place (some examples above) where it is checked for broken apic timer.
Maybe you can also just return that it's broken to check whether setting noapictimer variable at this place generally works for you...

Thanks,

Thomas

Quoted 57 lines · Richard

Quoted 55 lines · Thomas Renninger

Quoted 12 lines · H. Peter Anvin

Quoted 9 lines · Thomas Renninger

Quoted 9 lines

Quoted 3 lines

Thanks a Million..
noapictimer works perfectly ... BUT .. only on 64Bit. acpi_pm is not present on 32bit as a clocksource and it defaulted to jiffies. (tsc was marked as imreliable)

I am really surprised that this Sempron notebook actually had 64Bit CPU compatibility :D

Quoted 9 lines

Quoted 6 lines

This one helps for my Turion.
AFAIK, another Turion (very similar) does not need this, but I do not know for sure.

Is the common denominator here the Turion (and if so, what model number), or is it the mainboard or BIOS? If the latter, it should be keyed on a DMI signature instead of the CPU.

noapictimer is needed on machines with C1E (when all cores issue C1, the BIOS may decide to shut down more things, like the apic timer...). Therefore the checking for C1E (in arch/x86/setup_64.c amd_apic_timer_broken(..)). The check for C1E is done for K8 RevF, K10 and K11. I now expect it simply has been forgotten that K8 RevE CPUs may also have C1E (maybe only mobile Turion and Semprons, could the check below be enhanced to only check mobile CPUs?)?

This patch should also check for RevE with more than one core. It's untested, but should compile. Does this one work for you Richard?

Also check for broken apic timer for RevE multi core machines

Signed-off-by Thomas Renninger <[email protected]>

Index: linux-2.6/arch/x86/kernel/setup_64.c
===================================================================

arch/x86/kernel/setup_64.c +1 -1

@@ -686,7 +686,7 @@ static void __cpuinit early_init_amd_mc(
 #define CPUID_XFAM_10H		0x00100000
 #define CPUID_XFAM_11H		0x00200000
 #define CPUID_XMOD		0x000f0000
-#define CPUID_XMOD_REV_F	0x00040000
+#define CPUID_XMOD_REV_E	0x00020000
 
 /* AMD systems with C1E don't have a working lAPIC timer. Check for that. */
 static __cpuinit int amd_apic_timer_broken(void)

@@ -695,7 +695,9 @@ static __cpuinit int amd_apic_timer_brok
 

Quoted 5 lines

arch/x86/kernel/setup_64.c static __cpuinit int amd_apic_timer_brok

Quoted 5 lines

arch/x86/kernel/setup_64.c +1 -1

 	switch (eax & CPUID_XFAM) {
 	case CPUID_XFAM_K8:
-		if ((eax & CPUID_XMOD) < CPUID_XMOD_REV_F)
+		if ((eax & CPUID_XMOD) < CPUID_XMOD_REV_E)
 

{ printk("RevD or lower\n");

Quoted 2 lines

arch/x86/kernel/setup_64.c static __cpuinit int amd_apic_timer_brok · line 701

Quoted 2 lines

arch/x86/kernel/setup_64.c +1 -0

+			break;
 

}

Quoted 2 lines

arch/x86/kernel/setup_64.c static __cpuinit int amd_apic_timer_brok · line 703

Quoted 2 lines

arch/x86/kernel/setup_64.c +1 -0

+		if (num_online_cpus() < 2)
 

{ printk("Only detected %d online CPUs\n",

                          num_online_cpus());

Quoted 2 lines

Quoted 2 lines

break;

}

Quoted 3 lines

arch/x86/kernel/setup_64.c static __cpuinit int amd_apic_timer_brok · line 703

Quoted 3 lines

arch/x86/kernel/setup_64.c +0 -0

 	case CPUID_XFAM_10H:
 	case CPUID_XFAM_11H:

Also something at the C1E check which should come here then, does it match?
Maybe it really is a RevE and the second CPU is not brought up yet?

Quoted 6 lines

Quoted 2 lines

Hi there,

The results are in.. and the patch done nothing on my notebook. The symptoms are exactly the same as before. Kernel loads, INIT starts and then the machine shuts down a few seconds later. noapictimer still fixes it tho'

Googled this:
Sempron 3600+ (CN),256K,rev.F2,62W,SocketAM2 ALL 0107
So this Sempron probably is RevF already but the C1E check does not work?
Hope you still have the kernel compiled flying around?
Could you add a lot printks at the place (some examples above) where it is checked for broken apic timer.
Maybe you can also just return that it's broken to check whether setting noapictimer variable at this place generally works for you...

Thanks,

Thomas

PS: That i386 does not boot sounds related to:

Mobile AMD Sempron(tm) Processor 3500+ does not boot with i386 kernel
https://bugzilla.novell.com/show_bug.cgi?id=331960

If you don't mind you could post the timer things you found out there and eventually we could have a look how to get the machine going with i386, the reporter has handed over the machine to his girl friend, therefore the bug got stuck...

Quoted 119 lines · Thomas Renninger

Quoted 62 lines · Richard

Quoted 60 lines · Thomas Renninger

Quoted 21 lines · H. Peter Anvin

Quoted 8 lines · Thomas Renninger

Quoted 8 lines

Quoted 3 lines

Thanks a Million..
noapictimer works perfectly ... BUT .. only on 64Bit. acpi_pm is not present on 32bit as a clocksource and it defaulted to jiffies. (tsc was marked as imreliable)

Quoted 10 lines

Quoted 4 lines

I am really surprised that this Sempron notebook actually had 64Bit CPU compatibility :D

This one helps for my Turion.
AFAIK, another Turion (very similar) does not need this, but I do not know for sure.

Quoted 5 lines

Is the common denominator here the Turion (and if so, what model number), or is it the mainboard or BIOS? If the latter, it should be keyed on a DMI signature instead of the CPU.

noapictimer is needed on machines with C1E (when all cores issue C1, the BIOS may decide to shut down more things, like the apic timer...). Therefore the checking for C1E (in arch/x86/setup_64.c amd_apic_timer_broken(..)). The check for C1E is done for K8 RevF, K10 and K11. I now expect it simply has been forgotten that K8 RevE CPUs may also have C1E (maybe only mobile Turion and Semprons, could the check below be enhanced to only check mobile CPUs?)?

This patch should also check for RevE with more than one core. It's untested, but should compile. Does this one work for you Richard?

Also check for broken apic timer for RevE multi core machines

Signed-off-by Thomas Renninger <[email protected]>

Index: linux-2.6/arch/x86/kernel/setup_64.c
===================================================================

arch/x86/kernel/setup_64.c +1 -1

@@ -686,7 +686,7 @@ static void __cpuinit early_init_amd_mc(
 #define CPUID_XFAM_10H		0x00100000
 #define CPUID_XFAM_11H		0x00200000
 #define CPUID_XMOD		0x000f0000
-#define CPUID_XMOD_REV_F	0x00040000
+#define CPUID_XMOD_REV_E	0x00020000
 
 /* AMD systems with C1E don't have a working lAPIC timer. Check for that. */
 static __cpuinit int amd_apic_timer_broken(void)

@@ -695,7 +695,9 @@ static __cpuinit int amd_apic_timer_brok
 

Quoted 5 lines

arch/x86/kernel/setup_64.c static __cpuinit int amd_apic_timer_brok

Quoted 5 lines

arch/x86/kernel/setup_64.c +1 -1

 	switch (eax & CPUID_XFAM) {
 	case CPUID_XFAM_K8:
-		if ((eax & CPUID_XMOD) < CPUID_XMOD_REV_F)
+		if ((eax & CPUID_XMOD) < CPUID_XMOD_REV_E)
 

{ printk("RevD or lower\n");

Quoted 2 lines

arch/x86/kernel/setup_64.c static __cpuinit int amd_apic_timer_brok · line 701

Quoted 2 lines

arch/x86/kernel/setup_64.c +1 -0

+			break;
 

}

Quoted 2 lines

arch/x86/kernel/setup_64.c static __cpuinit int amd_apic_timer_brok · line 703

Quoted 2 lines

arch/x86/kernel/setup_64.c +1 -0

+		if (num_online_cpus() < 2)
 

{ printk("Only detected %d online CPUs\n",

                          num_online_cpus());

Quoted 2 lines

Quoted 2 lines

break;

}

Quoted 3 lines

arch/x86/kernel/setup_64.c static __cpuinit int amd_apic_timer_brok · line 703

Quoted 3 lines

arch/x86/kernel/setup_64.c +0 -0

 	case CPUID_XFAM_10H:
 	case CPUID_XFAM_11H:

Also something at the C1E check which should come here then, does it match?
Maybe it really is a RevE and the second CPU is not brought up yet?

Quoted 9 lines

Quoted 2 lines

Hi there,

The results are in.. and the patch done nothing on my notebook. The symptoms are exactly the same as before. Kernel loads, INIT starts and then the machine shuts down a few seconds later. noapictimer still fixes it tho'

Googled this:
Sempron 3600+ (CN),256K,rev.F2,62W,SocketAM2 ALL 0107
So this Sempron probably is RevF already but the C1E check does not work?
Hope you still have the kernel compiled flying around?
Could you add a lot printks at the place (some examples above) where it is checked for broken apic timer.
Maybe you can also just return that it's broken to check whether setting noapictimer variable at this place generally works for you...

Thanks,

Thomas

PS: That i386 does not boot sounds related to:

Quoted 10 lines

Mobile AMD Sempron(tm) Processor 3500+ does not boot with i386 kernel
https://bugzilla.novell.com/show_bug.cgi?id=331960

If you don't mind you could post the timer things you found out there and eventually we could have a look how to get the machine going with i386, the reporter has handed over the machine to his girl friend, therefore the bug got stuck...

Built and run.... only One CPU and no message about revision.. so I take that its an E or above revision.

32bit is a bit of a nightmare now :-) unless I can install a minimal kernel on a USB stick... I'll give that a bash.

Regards,
Richard

Peter: You wrote the syslinux stuff, right? What kind of luck is that :) There currently is a discussion about being able to override ACPI tables via initrd. The discussion is a bit stuck because the data is needed earlier than initrd is unpacked and the hacks to make it work are not accepted by Linus. I thought about adding another binary image to i386 boot protocol, similar to initrd= which contains data for very early kernel boot initialization, but this would be a heavy hammer (but IMO still better than only do it for kexec, another suggestion...) , I better open a separate thread or pre-ask privately whether this makes sense at all. It would be great if you could advise and possibly help to convince so that we finally may find a solution accepted mainline.