From owner-freebsd-current@FreeBSD.ORG Fri Jun 21 09:34:02 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9472E848; Fri, 21 Jun 2013 09:34:02 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bk0-x22e.google.com (mail-bk0-x22e.google.com [IPv6:2a00:1450:4008:c01::22e]) by mx1.freebsd.org (Postfix) with ESMTP id C42FB1682; Fri, 21 Jun 2013 09:34:01 +0000 (UTC) Received: by mail-bk0-f46.google.com with SMTP id na10so3271823bkb.5 for ; Fri, 21 Jun 2013 02:34:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=AHjI4FLGmMomyh9OaHkm/tCfub4rxZO9DdacXUE175A=; b=ny6uPmHhDnimUpilXl43Gtq7FxtwgCh8IcGZRtiDrxGjDHpzNrkTgp8Uh4Q1FlqNvn eRATwUQVZJqaRMuXcb37e/nGzpOObMZi1uvS676DEF6Vu3igO/3QqFmssBZpNH1cSmPv Y+KTKnMwRQV3G/UvHrGYUQmTQBMpFC1TyIz42jxi4bwQjvW0YtlklAFttvwgQXD+MQ0s dR+ZmapFTZyNeleivo0VAlRzll8q813mlES+jGXzMwgjzizvg9gcIqNcbt7A8w+xvQSY NOpzooKkq6MPIXcmdDiKLpDycy/s8REb8pMFRkp9++fFbd2u8V7oWrxYvS4viy6KIIle nYJQ== X-Received: by 10.205.12.67 with SMTP id ph3mr1682652bkb.87.1371807240771; Fri, 21 Jun 2013 02:34:00 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPSA id fz10sm1270527bkc.9.2013.06.21.02.33.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Jun 2013 02:33:58 -0700 (PDT) Sender: Alexander Motin Message-ID: <51C41E03.6060205@FreeBSD.org> Date: Fri, 21 Jun 2013 12:33:55 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130616 Thunderbird/17.0.6 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: Atom N450 + C3 + HPET == bad timer behaviour References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current , freebsd-mobile@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 09:34:02 -0000 On 21.06.2013 04:02, Adrian Chadd wrote: > On 20 June 2013 16:45, Adrian Chadd wrote: >> Hi, >> >> I'm having issues with HPET + C3 state on this Atom N450 based >> netbook. This is (shocking, I know!) running -HEAD (r251605.) >> >> If I use C2, HPET is fine. >> >> If I use RTC, i8254, LAPIC, C3 is also fine. LAPIC use probably disables C3 usage automatically there. RTC and i8254 use only periodic modes and so system will wakeup with at least HZ rate, so it is hard to say whether C3 will be used. >> But C3 + HPET results in multi-second pauses where it should be 1 second. What timecounter are you using? Have you tried to check what is going on in that moment: timecounter stoped, eventttimer interrupt losd or system is completely stuck somehow? >> I've disabled powerd and verified that dev.cpu.0.freq=1667; so it's >> not CPU frequency related. >> >> Doug found this: apparently SMI + timer fondling doesn't quite work out? >> >> http://lkml.indiana.edu/hypermail/linux/kernel/1102.3/00842.html SMI is a black box that can give us any kind of unexpected surprises. Theoretically there could be number of scenarios: HPET counter or comparator values corrupted by SMI code (not sure we can protect), SMI code can open race window on HPET comparator programming (that should be handled now), SMI code can have own bugs triggered by some specific HPET usage pattern (not our area). > .. and the resolution: > > http://lkml.indiana.edu/hypermail/linux/kernel/1102.3/00957.html > > "clockevents: Prevent oneshot mode when broadcast device is periodic > > When the per cpu timer is marked CLOCK_EVT_FEAT_C3STOP, then we only > can switch into oneshot mode, when the backup broadcast device > supports oneshot mode as well. Otherwise we would try to switch the > broadcast device into an unsupported mode unconditionally. This went > unnoticed so far as the current available broadcast devices support > oneshot mode. Seth unearthed this problem while debugging and working > around an hpet related BIOS wreckage. > > Add the necessary check to tick_is_oneshot_available()." > > does that help? That looks more like workaround for Linux-specific issue. Linux can use different timers hardware when CPU is active and when in deep sleep, and, as I understand from description, it tried to improperly use one of devices. Our code doesn't have that magic. Also I think this fix fixes not the original problem, but different one they've found during debugging. HPET always has ONESHOT capability, so this check is irrelevant when it is used as a broadcast device. -- Alexander Motin