public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Thomas Renninger <trenn@suse.de>
To: Richard <tuxbox.guru@gmail.com>
Cc: linux-acpi@vger.kernel.org, andreas.herrmann3@amd.com,
	"Langsdorf, Mark" <mark.langsdorf@amd.com>
Subject: Re: ACPI on Compaq 6715b - BIOS from the wrong end of the planet
Date: Wed, 30 Apr 2008 15:58:10 +0200	[thread overview]
Message-ID: <1209563890.1784.962.camel@queen.suse.de> (raw)
In-Reply-To: <4818755B.2090602@gmail.com>

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

  reply	other threads:[~2008-04-30 13:58 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-27  9:06 ACPI on Compaq 6715b - BIOS from the wrong end of the planet Richard
2008-04-29 13:45 ` Thomas Renninger
2008-04-29 15:57   ` Richard
2008-04-29 18:29     ` Thomas Renninger
2008-04-29 23:36       ` H. Peter Anvin
2008-04-30  8:30         ` Richard
2008-04-30  8:39         ` Thomas Renninger
2008-04-30 10:23           ` Richard
2008-04-30 12:07             ` Thomas Renninger
2008-04-30 13:09               ` Richard
2008-04-30 13:34               ` Richard
2008-04-30 13:58                 ` Thomas Renninger [this message]
2008-04-30 17:56           ` Overriding ACPI tables H. Peter Anvin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1209563890.1784.962.camel@queen.suse.de \
    --to=trenn@suse.de \
    --cc=andreas.herrmann3@amd.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=mark.langsdorf@amd.com \
    --cc=tuxbox.guru@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox