[DragonFlyBSD - Bug #2653] Timer DELAY hangs boot on Lenovo S10 Intel Atom N270 with acpi enabled

bugtracker-admin at leaf.dragonflybsd.org bugtracker-admin at leaf.dragonflybsd.org
Fri Mar 7 04:36:03 PST 2014


Issue #2653 has been updated by sepherosa.


On Fri, Mar 7, 2014 at 6:50 PM,  <bugtracker-admin at leaf.dragonflybsd.org> wrote:
> Issue #2653 has been updated by swildner.
>
>
> Does it make a difference when you put hw.tsc_cputimer_enable=0 in /boot/loader.conf?
>
>
> ----------------------------------------
> Bug #2653: Timer DELAY hangs boot on Lenovo S10 Intel Atom N270 with acpi enabled
> http://bugs.dragonflybsd.org/issues/2653#change-11887
>
> * Author: davshao
> * Status: New
> * Priority: Normal
> * Assignee:
> * Category:
> * Target version:
> ----------------------------------------
> On a i386 Lenovo S10 netbook with Intel Atom N270 and acpi enabled, boot hangs after:
>
> acpi0.nexus0.root0
> acpi0: <LENOVO CB-01> [tentative] on motherboard
> ACPI: All ACPI Tables successfully acquired
> ACPI FADT: SCI testing interrupt mode ...
> ACPI FADT: SCI testing level/high
> IOAPIC: irq 9, gsi 9 edge/high -> level/high
>
> Brute force debugging with kprintf shows that commenting out the
> DELAY(100 * 1000);
> in function acpi_sci_test() of file sys/platform/pc32/acpica/acpi_fadt.c
>
> enables boot to at least progress to the end of function call
> acpi_sci_config();
> in function AcpiOsInstallInterruptHandler() in
> file sys/dev/acpica/Osd/OsdInterrupt.c
> (after which at some point booting hangs again).
>
> I can only speculate this may have some relation to the thread
> "Time keeping Issues with the low-resolution TSC timecounter"
> on the FreeBSD current mailing list around June 2011.  For example:
>
> http://lists.freebsd.org/pipermail/freebsd-current/2011-June/025319.html
>
> "Somewhere from an Intel manual, I think I read TSC stops when DPSLP#
> pin is asserted for Core/Core2/Atom processors and I guess that means
> entering C3 stops TSC. :-("

I don't think TSC is used as cputimer on N270 here.  It's still i8254,
since ACPI timer and HPET is not yet probed.  The cpu probably is
choked by high interrupt rate when SCI mode is being tested.  As about
later hanging, it may be caused by BIOS triggered C1E which could
choke local APIC timer.  Let's try following tunables (you probably
want all of them):

hw.lapic_timer_enable="0"
hw.acpi.sci.trigger="level"
hw.acpi.sci.polarity="low"

Best Regards,
sephe

-- 
Tomorrow Will Never Die

----------------------------------------
Bug #2653: Timer DELAY hangs boot on Lenovo S10 Intel Atom N270 with acpi enabled
http://bugs.dragonflybsd.org/issues/2653#change-11888

* Author: davshao
* Status: New
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
----------------------------------------
On a i386 Lenovo S10 netbook with Intel Atom N270 and acpi enabled, boot hangs after:

acpi0.nexus0.root0
acpi0: <LENOVO CB-01> [tentative] on motherboard
ACPI: All ACPI Tables successfully acquired
ACPI FADT: SCI testing interrupt mode ...
ACPI FADT: SCI testing level/high
IOAPIC: irq 9, gsi 9 edge/high -> level/high

Brute force debugging with kprintf shows that commenting out the
DELAY(100 * 1000);
in function acpi_sci_test() of file sys/platform/pc32/acpica/acpi_fadt.c

enables boot to at least progress to the end of function call
acpi_sci_config();
in function AcpiOsInstallInterruptHandler() in
file sys/dev/acpica/Osd/OsdInterrupt.c
(after which at some point booting hangs again).

I can only speculate this may have some relation to the thread
"Time keeping Issues with the low-resolution TSC timecounter"
on the FreeBSD current mailing list around June 2011.  For example:

http://lists.freebsd.org/pipermail/freebsd-current/2011-June/025319.html

"Somewhere from an Intel manual, I think I read TSC stops when DPSLP# 
pin is asserted for Core/Core2/Atom processors and I guess that means 
entering C3 stops TSC. :-("

Attached is a dmesg from an acpi-disabled successful boot of the machine.


---Files--------------------------------
lenovo_s10_dmesg.txt (36.5 KB)


-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account



More information about the Bugs mailing list