Date: Fri, 17 Nov 2006 16:50:14 GMT From: John Baldwin <jhb@freebsd.org> To: freebsd-i386@FreeBSD.org Subject: Re: i386/104678: SMP not working on Turion XP Laptop Message-ID: <200611171650.kAHGoEXQ009259@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR i386/104678; it has been noted by GNATS.
From: John Baldwin <jhb@freebsd.org>
To: Ariff Abdullah <ariff@freebsd.org>
Cc: Bruce Evans <bde@zeta.org.au>, bug-followup@freebsd.org, danolson@visi.com,
rainer.alves@gmail.com, infofarmer@freebsd.org
Subject: Re: i386/104678: SMP not working on Turion XP Laptop
Date: Fri, 17 Nov 2006 11:21:29 -0500
On Friday 17 November 2006 09:50, Ariff Abdullah wrote:
> On Fri, 17 Nov 2006 23:36:49 +1100 (EST)
> Bruce Evans <bde@zeta.org.au> wrote:
> > On Fri, 17 Nov 2006, Ariff Abdullah wrote:
> >
> > > It seems the workaround is rather simple:
> > >
> > > machdep.cpu_idle_hlt=0
> >
> > This sort of works on an HP nx6325 too. It fixes booting.
> >
> > > Unfortunately, the only place where you can set that is after the
> > > system comes alive. This patch deals with that so that you can set
> > > it as early as possible during boot procedure through loader.conf.
> >
> > After booting I had no problems that matter much to me
> > (sleep/suspend don't work; closing the lid only turns off the screen
> > and drops 1 second from the timecounter), but with cpu_idle_hlt=0
> > (set manually in ddb after booting with -d), the system runs very
> > hot, and turning cpu_idle_hlt back on works strangely (it cools an
> > idle system, but stops clock interrupts working), and turning it
> > back off works as expected (it reheats an idle system and restarts
> > clock interrupts). Apparently the SMP hook into cpu_idle() doesn't
> > work right if the flag is changed after booting.
> >
> > > Summary:
> > > Basically the cpu enter deep sleep mode whenever it receives HLT
> > > call within idle loop, and that only if APIC + Local APIC timer is
> > > enabled. I can't tell whether it is because of APIC misseting, CPU
> > > bug or else, but one thing for sure, FreeBSD 5.x/SMP boots happily
> > > on this (well, that's because it doesn't use local APIC timer).
> >
> > The boot problem also caused clock interrupts to stop working *until
> > I toggled AC power), so the problem is apparently related to using
> > the local APIC timer.
> >
> > The power penalty seems to be more than slight. On my nx6325,
> > tz0.temperature is now 50C with cpu_idle_hlt=1 and 75C with
> > cpu_idle_hlt=0, the latter even when on battery power. I've also
> > noticed this system getting hot while in ddb, and wondered if it
> > would help to use pause() in the spinloops in console i/o routines.
> >
>
> Apparently executing HLT on other cores seems fine, as long as we
> _exclude_ at least a single core from doing so. That way, we still
> have manageable timer interrupt while letting the other cores doing
> power management stuffs. Currently, this is my crude crack on
> machdep.c (both for i386 and amd64):
>
> ## BEGIN ##
> void
> cpu_idle(void)
> {
>
> #ifdef SMP
> if (mp_grab_cpu_hlt())
> return;
> #endif
>
> if (cpu_idle_hlt) {
> disable_intr();
> if (sched_runnable())
> enable_intr();
> else if (PCPU_GET(cpuid) == 0) <<<<<
> enable_intr(); <<<<<
> else
> (*cpu_idle_hook)();
> }
> }
> ## END ##
>
>
> Again, this only concern where local apic timer is in action for this
> cpu.
Are you using ACPI with Cx hlt states? It's known that on many Intel chips at
least, entering C2 or C3 powers off the local APIC timer. I know of one
possible workaround that we can use, but haven't had any time to look at it.
Specifically, we could use another interrupt source (such as the HPET
counters) and schedule them to wake us up when the next clock tick should
fire when we enter C2 or higher sleep state. You can test this theory by
setting the sysctl for ACPI to use only C1.
--
John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200611171650.kAHGoEXQ009259>