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

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

[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.

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.

Thanks in advance..
Richard

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

[Thomas Renninger]

On Sun, 2008-04-27 at 10:06 +0100, Richard wrote:
> 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.
Does:
disable_timer_pin_1
or
noapictimer
work?

   Thomas

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

[Richard]

Thomas Renninger wrote:
> On Sun, 2008-04-27 at 10:06 +0100, Richard wrote:
>   
>> 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.
>>     
> 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

Richard

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

[Thomas Renninger]

On Tue, 2008-04-29 at 16:57 +0100, Richard wrote:
> Thomas Renninger wrote:
> > On Sun, 2008-04-27 at 10:06 +0100, Richard wrote:
> >   
> >> 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.
> >>     
> > 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

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


Index: linux-2.6.25-rc6/arch/x86/kernel/cpu/amd.c
===================================================================
--- linux-2.6.25-rc6.orig/arch/x86/kernel/cpu/amd.c
+++ linux-2.6.25-rc6/arch/x86/kernel/cpu/amd.c
@@ -39,9 +39,14 @@ static __cpuinit int amd_apic_timer_brok
 {
 	u32 lo, hi;
 	u32 eax = cpuid_eax(CPUID_PROCESSOR_SIGNATURE);
+	struct cpuinfo_x86 *c = &boot_cpu_data;
 
 	switch (eax & CPUID_XFAM) {
 	case CPUID_XFAM_K8:
+		if (c->x86 == 15 && c->x86_model == 72 && c->x86_mask == 2) {
+			printk ("Found AMD Turion, disabling apic timer\n");
+			return 1;
+		}
 		if ((eax & CPUID_XMOD) < CPUID_XMOD_REV_F)
 			break;
 	case CPUID_XFAM_10H:
Index: linux-2.6.25-rc6/arch/x86/kernel/setup_64.c
===================================================================
--- linux-2.6.25-rc6.orig/arch/x86/kernel/setup_64.c
+++ linux-2.6.25-rc6/arch/x86/kernel/setup_64.c
@@ -627,11 +627,14 @@ static void __cpuinit early_init_amd_mc(
 static __cpuinit int amd_apic_timer_broken(void)
 {
 	u32 lo, hi, eax = cpuid_eax(CPUID_PROCESSOR_SIGNATURE);
-
 	struct cpuinfo_x86 *c = &boot_cpu_data;
 
   	switch (eax & CPUID_XFAM) {
 	case CPUID_XFAM_K8:
+		if (c->x86 == 15 && c->x86_model == 72 && c->x86_mask == 2) {
+			printk ("Found AMD Turion, disabling apic timer\n");
+			return 1;
+		}
 		if ((eax & CPUID_XMOD) < CPUID_XMOD_REV_F)
 			break;
 	case CPUID_XFAM_10H:

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

[H. Peter Anvin]

Thomas Renninger wrote:
>>>   
>> 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.
> 

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

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

[Richard]

H. Peter Anvin wrote:
> Thomas Renninger wrote:
>>>>   
>>> 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.
>>
>
> 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
>
I have all the grief on a Sempron/ATI  system

model name      : Mobile AMD Sempron(tm) Processor 3600+

If I specify nolapic,noapic or acpi=noirq on kernel boot, the machine  
goes  in  to VERY slow motion  (5 minutes to boot!)   the noapictimer 
option was the magic keyword in my case and I am going to dig in to the 
code to see what things this setting fudges with :-)

Best Regards
Richard

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

[Thomas Renninger]

On Tue, 2008-04-29 at 16:36 -0700, H. Peter Anvin wrote:
> Thomas Renninger wrote:
> >>>   
> >> 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.
> > 
> 
> 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?

-- Unrelated --
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.
-- Unrelated --


Also check for broken apic timer for RevE multi core machines

Signed-off-by: Thomas Renninger <trenn@suse.de>

Index: linux-2.6/arch/x86/kernel/setup_64.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/setup_64.c
+++ linux-2.6/arch/x86/kernel/setup_64.c
@@ -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
 
 	switch (eax & CPUID_XFAM) {
 	case CPUID_XFAM_K8:
-		if ((eax & CPUID_XMOD) < CPUID_XMOD_REV_F)
+		if ((eax & CPUID_XMOD) < CPUID_XMOD_REV_E)
+			break;
+		if (num_online_cpus() < 2)
 			break;
 	case CPUID_XFAM_10H:
 	case CPUID_XFAM_11H:



--
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: ACPI on Compaq 6715b - BIOS from the wrong end of the planet

[Richard]

Thomas Renninger wrote:
> On Tue, 2008-04-29 at 16:36 -0700, H. Peter Anvin wrote:
>   
>> Thomas Renninger wrote:
>>     
>>>>>   
>>>>>           
>>>> 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.
>>>
>>>       
>> 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 <trenn@suse.de>
>
> Index: linux-2.6/arch/x86/kernel/setup_64.c
> ===================================================================
> --- linux-2.6.orig/arch/x86/kernel/setup_64.c
> +++ linux-2.6/arch/x86/kernel/setup_64.c
> @@ -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
>  
>  	switch (eax & CPUID_XFAM) {
>  	case CPUID_XFAM_K8:
> -		if ((eax & CPUID_XMOD) < CPUID_XMOD_REV_F)
> +		if ((eax & CPUID_XMOD) < CPUID_XMOD_REV_E)
> +			break;
> +		if (num_online_cpus() < 2)
>  			break;
>  	case CPUID_XFAM_10H:
>  	case CPUID_XFAM_11H:
>
>
>
>
>   


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' 

<insert twilight zone music here>

Thanks a million,
Richard




--
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: ACPI on Compaq 6715b - BIOS from the wrong end of the planet

[Thomas Renninger]

On Wed, 2008-04-30 at 11:23 +0100, Richard wrote:
> Thomas Renninger wrote:
> > On Tue, 2008-04-29 at 16:36 -0700, H. Peter Anvin wrote:
> >   
> >> Thomas Renninger wrote:
> >>     
> >>>>>   
> >>>>>           
> >>>> 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.
> >>>
> >>>       
> >> 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 <trenn@suse.de>
> >
> > Index: linux-2.6/arch/x86/kernel/setup_64.c
> > ===================================================================
> > --- linux-2.6.orig/arch/x86/kernel/setup_64.c
> > +++ linux-2.6/arch/x86/kernel/setup_64.c
> > @@ -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
> >  
> >  	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");
> > +			break;
}
> > +		if (num_online_cpus() < 2)
{                         printk("Only detected %d online CPUs\n",
                          num_online_cpus());
> >  			break;
}
> >  	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?
> >
> >
> >   
> 
> 
> 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...

--
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: ACPI on Compaq 6715b - BIOS from the wrong end of the planet

[Richard]

Thomas Renninger wrote:
> 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?
>   

This machine is a single processor system (Single core) .. its loading a 
MP kernel tho.  It can wait forever for the second processor :-D

>>>   
>>>       
>> 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
>
>
>
>   
Building again...  should be completed in a minute or so.

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

[Richard]

Thomas Renninger wrote:
> On Wed, 2008-04-30 at 11:23 +0100, Richard wrote:
>   
>> Thomas Renninger wrote:
>>     
>>> On Tue, 2008-04-29 at 16:36 -0700, H. Peter Anvin wrote:
>>>   
>>>       
>>>> Thomas Renninger wrote:
>>>>     
>>>>         
>>>>>>>   
>>>>>>>           
>>>>>>>               
>>>>>> 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.
>>>>>
>>>>>       
>>>>>           
>>>> 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 <trenn@suse.de>
>>>
>>> Index: linux-2.6/arch/x86/kernel/setup_64.c
>>> ===================================================================
>>> --- linux-2.6.orig/arch/x86/kernel/setup_64.c
>>> +++ linux-2.6/arch/x86/kernel/setup_64.c
>>> @@ -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
>>>  
>>>  	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");
>   
>>> +			break;
>>>       
> }
>   
>>> +		if (num_online_cpus() < 2)
>>>       
> {                         printk("Only detected %d online CPUs\n",
>                           num_online_cpus());
>   
>>>  			break;
>>>       
> }
>   
>>>  	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?
>   
>>>   
>>>       
>> 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...
>
>
>   

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

--
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: ACPI on Compaq 6715b - BIOS from the wrong end of the planet

[Thomas Renninger]

Mark got stripped from list of CCs...

On Wed, 2008-04-30 at 14:34 +0100, Richard wrote:
> Thomas Renninger wrote:
> > On Wed, 2008-04-30 at 11:23 +0100, Richard wrote:
> >   
> >> Thomas Renninger wrote:
> >>     
> >>> On Tue, 2008-04-29 at 16:36 -0700, H. Peter Anvin wrote:
> >>>   
> >>>       
> >>>> Thomas Renninger wrote:
> >>>>     
> >>>>         
> >>>>>>>   
> >>>>>>>           
> >>>>>>>               
> >>>>>> 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.
> >>>>>
> >>>>>       
> >>>>>           
> >>>> 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 <trenn@suse.de>
> >>>
> >>> Index: linux-2.6/arch/x86/kernel/setup_64.c
> >>> ===================================================================
> >>> --- linux-2.6.orig/arch/x86/kernel/setup_64.c
> >>> +++ linux-2.6/arch/x86/kernel/setup_64.c
> >>> @@ -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
> >>>  
> >>>  	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");
> >   
> >>> +			break;
> >>>       
> > }
> >   
> >>> +		if (num_online_cpus() < 2)
> >>>       
> > {                         printk("Only detected %d online CPUs\n",
> >                           num_online_cpus());
> >   
> >>>  			break;
> >>>       
> > }
> >   
> >>>  	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?
> >   
> >>>   
> >>>       
> >> 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...
> >
> >
> >   
> 
> Built and run.... only One CPU and no message about revision.. so I take 
> that its an E or above revision.

We need to know from AMD for what exactly to look at.
Matching for Mobile + Sempron in cpu info string sounds like a good
idea.
But I expect matching against Turion is overdosed and working apics
might get switched off...

Maybe this is CPU + chipset specific?
Can you also send lspci, whole cpuinfo and dmidecode output, maybe a
relation with other reports is found...

If you have C-states (cat /proc/acpi/processor/*/power)
you may get a working apictimer with boot param processor.max_cstate=2
or 1.

   Thomas

> 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
> 

--
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

Overriding ACPI tables

[H. Peter Anvin]

Thomas Renninger wrote:
> 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.

We're putting in a mechanism for pushing larger tables already; we need 
it for other things (in particular, the zones for E820 and EDD in the 
boot_info_table are simply not big enough.)  That gives a generic 
mechanism for sending arbitrary-sized binary images to the kernel.  That 
would be the mechanism to use.

I believe it's in upstream as this merge window; it's definitely in 
x86.git already.

	-hpa
--
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