Date: Tue, 7 Nov 2006 01:30:23 GMT From: Bruce Evans <bde@zeta.org.au> To: freebsd-i386@FreeBSD.org Subject: Re: i386/104678: SMP not working on Turion XP Laptop Message-ID: <200611070130.kA71UN4u001976@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: Bruce Evans <bde@zeta.org.au>
To: Andrew Pantyukhin <infofarmer@freebsd.org>
Cc: freebsd-gnats-submit@freebsd.org
Subject: Re: i386/104678: SMP not working on Turion XP Laptop
Date: Tue, 7 Nov 2006 12:25:40 +1100 (EST)
On Mon, 6 Nov 2006, Andrew Pantyukhin wrote:
> I experience the same on a Turion X2 laptop
> with FreeBSD 7/amd64,
On a similar laptop (HP nx6325 Turion X2 2GHz), I found 2 workarounds:
1. Boot with battery power only. Usually works.
2. After forgetting (1), toggle AC power off and on. Leave it off a
few seconds. Usually works after 1 iteration.
Some symptoms:
RELENG_6 GENERIC usually (appear to) hang after printing "ad4: ..."
just before mounting root. Hitting keys didn't seem to help. However,
about 1 time in 10, perhaps because I tried (1) or (2) accidentally,
the boot just worked, so I knew that there was no major problem with
ACPI. RELENG_6 GENERIC kernels don't have SMP and boot fine without
ACPI, so disabling ACPI is good enough for them.
My specialized kernels happened to have a wrong ROOTDEVNAME hard-coded,
so they acted like booting with -a. They always have ddb, and debugging
showed that everything was working at the time of asking the rootdev
name. Then a few steps later in the boot, critical interrupts mostly
stop working. Mainly the CPU timer interrupts. A few of them apparently
get through as side effects of other interrupts -- that's why pounding
on the keyboard eventually makes progress. Note that syscons only
redraws the screen after a timeout, so when timeouts don't work the
system appears to be more hung than it actually is. My kernels all
use HZ = 100 and some fixes for stathz and profhz being broken by this.
This may make a difference here.
At a lower level, some of the symptoms are:
- break into ddb using Ctrl-Alt-Esc (some keys, including the normal
debugger key Ctrl-SysReq, don't work on this laptop); put a breakpoint
at hardclock(); give the "c" command to exit from ddb. Then hardclock()
is never reached unless you hit some keys or otherwise generate interrupts
manually (ethernet interrupts don't seem to do it).
- same, except put a breakpoint at lapic_handle_timer() too. Now this
breakpoint keeps getting hit, and one at hardclock() keeps getting
hit too. Programmed delays didn't seem to help, and I stopped trying
them when I found workaround (1) while trying them.
- "show intrcnt" shows most interrupts except timer ones seem to be working,
but the timer interrupt rate drops from 1000*ncpu Hz to about 10 Hz
max (probably because I can only type at about 10 Hz max).
The misconfiguration apparently happens before stopping at the askname
prompt, since turning AC power off (but not back on as in (2)) on
reaching this prompt doesn't help and turning AC power on any time
after reaching this prompt doesn't break the boot or subsequent
operation. Only forgetting to turn it back on breaks subsequent
operation :).
Some other (software) problems with this laptop:
- no sleep states except S5 (shutdown) work right. The next closest to
working is the display switch. It turns the display off but the
system appears to hang for 1 second (+-10usec) and when it comes back
the timecounter has lost 1 second but the cputicker (TSC) has kept track
if the time perfectly.
- bge0 appears to lose interrupts for at least nfs traffic. Pinging with
an interval of 0.01 seconds helps to keep the nfs traffic flowing.,
> only I can't disable
> APIC for obvious reasons. I'll post details
> later, but we might need to reclassify this
> bug again.
I think the problem is in the HP BIOS, not in Turion X*'s.
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200611070130.kA71UN4u001976>