Date: Thu, 17 Jul 2014 03:16:10 +1000 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: Anthony Jenkins <Anthony.B.Jenkins@att.net> Cc: freebsd-acpi@freebsd.org, Daniele Mazzotti <kappei84@gmail.com> Subject: Re: ACPI support - Freebsd 10 on Sony Vaio VPCCA3C5E Message-ID: <20140717011710.W50382@sola.nimnet.asn.au> In-Reply-To: <53C67D70.6060603@att.net> References: <CAC=ypSVopgcL82FpqJosmgFeRkeeevP0RG-GrAEZD2YQyi%2BPrg@mail.gmail.com> <CAC=ypSULmXU2HBpG2gf2J=9_o-sLccECud%2Be9KUg6-ppz7phww@mail.gmail.com> <CAC=ypSV36Dk_3a30OeCxmowqnM5iqcJkM%2B4qKgsOTNTEzmztSQ@mail.gmail.com> <53C020CE.8010205@att.net> <CAC=ypSV_qQ-EsfwJAa6NRiZhTvOi-xh9A=oFKXzNMj9GTpHbOA@mail.gmail.com> <53C02604.9070207@att.net> <CAC=ypSV=yXjnNYJTMSU3tDTjez9NAe3PqsDPRiF5sf2D6FBxRA@mail.gmail.com> <CAC=ypSVbiOpTxUZeJnQUTMdjtbicu2JdG5p5g9%2BgR%2BS72-6RVg@mail.gmail.com> <CAC=ypSU3J3cPuEqDhrwAGm3MyNNGCc39W_4kTLJFbsYWjV5HoQ@mail.gmail.com> <53C3D322.3080302@att.net> <CAC=ypSXA8MZzT0V1RxhxyXd88Xk8od_6zmjn%2B9rd4W%2BtVgyvXQ@mail.gmail.com> <CAC=ypSUqHF%2B2_ajsjU5x3=if01twAtmsPcmQGBgNC=VEAdOKnQ@mail.gmail.com> <20140716040719.Y50382@sola.nimnet.asn.au> <CAC=ypSXYxpuqw9KA-OZRNJ=R50Cw9RoJtzp_bsqfG7pKvXYvmQ@mail.gmail.com> <20140716143406.V50382@sola.nimnet.asn.au> <CAC=ypSX19jrHxFp5cNzEJJZKOeKiGj%2BCgNRCA=yRMjWatEy1zA@mail.gmail.com> <53C67D70.6060603@att.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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 :)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140717011710.W50382>