From owner-freebsd-acpi@FreeBSD.ORG Wed Jul 16 17:16:18 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8F0F2AAC for ; Wed, 16 Jul 2014 17:16:18 +0000 (UTC) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D17892D9E for ; Wed, 16 Jul 2014 17:16:17 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id s6GHGACk035060; Thu, 17 Jul 2014 03:16:11 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Thu, 17 Jul 2014 03:16:10 +1000 (EST) From: Ian Smith To: Anthony Jenkins Subject: Re: ACPI support - Freebsd 10 on Sony Vaio VPCCA3C5E In-Reply-To: <53C67D70.6060603@att.net> Message-ID: <20140717011710.W50382@sola.nimnet.asn.au> References: <53C020CE.8010205@att.net> <53C02604.9070207@att.net> <53C3D322.3080302@att.net> <20140716040719.Y50382@sola.nimnet.asn.au> <20140716143406.V50382@sola.nimnet.asn.au> <53C67D70.6060603@att.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-acpi@freebsd.org, Daniele Mazzotti X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 17:16:18 -0000 On Wed, 16 Jul 2014 09:26:08 -0400, Anthony Jenkins wrote: > On 07/16/2014 01:32, Daniele Mazzotti wrote: >> Hi guys, thanks again for the support, but I am leaving for a >> businesses trip and I will be forced to put this debug thing on hold >> for a while. I will be back on track next week. > > Bah... really wanted to figure out the patch problem. I suspect the > file picked up some corruption somewhere between the email and your > FreeBSD filesystem. Your OS version has the same revision of that > source file as mine, so it should apply cleanly. If you feel like > tinkering with it in your free time, I've posted the patch here: > http://pastebin.com/P0B44u0c > > Good luck, > Anthony Either by show raw and save, or by download, the patch has ^M lineends. Interesting, but I can't see atrtc.c being the right sort of place for this, seems way out of scope. Couldn't you include its headers and use functions rtcin() and writertc() from elsewhere in kernel, perhaps a module living in the same hierarchy as acpi_ibm, acpi_asus and such, that one could build and kldload if useful on a certain machine/s? If so, you haven't to do battle with Time Lords :) with something people could add and load at own risk without messing with core kernel stuff. acpi_ibm should be a useful template, as it includes code to read CMOS bytes in the 0x60-0x6f range, presumably updated by the BIOS, whether opaquely or somehow via AML code I don't know. It uses rtcin() so has that scope in place. I'd still like to see your patch reject attempts to read or write to at least below 0x10. Even reading status register/s resets interrupts, and why would anyone need to mess with clock and/or timer regs via ACPI? Have you found exactly which CMOS bytes your box needs to meddle with? Maybe you could add a sysctl to limit access to some specific range? Don't mind me, just thinking aloud, and I've no idea how this might relate to Daniele's issue with stale battery data? cheers, Ian PS Daniele: no, never tempted by Sonys; rusted-on Thinkpad kinda guy :)