Hi guys, @Anthony: actually I am a "he" and not a "she" and I never thought about changing my nature below the waist :-).
By the way I will try to apply the patch as soon as I will be back home as I left my personal PC at home and I won't be back until Monday. I will let you know if that will fix my suspend/resume issue. Regarding the battery issue I hope that I will try to follow the recommendations from Ian in another email and see what happen. Cheers, Daniele. Il 16/lug/2014 23:08 "Anthony Jenkins" <[email protected]> ha scritto: > On 07/16/2014 13:16, Ian Smith wrote: > > 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. > Bah! Well that'd explain it... I'm generating the file on a pure FreeBSD > box, opened in gvim, select all, copy, paste to pastebin.com. > > 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? > This is in support of the PNP0800 device, for which atrtc.c is the driver. > The ACPI spec (5.0 is what I'm reading) says that device should implement > a handler to read offset 0x00-0x7F. > > 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? > I assume it'd be the BIOS AML which would use my CMOS region handler; it'd > be a BIOS bug that reads/writes the clock regs. > > Have you found exactly which CMOS bytes your box needs to meddle with? > I do have printf()s in my code (don't think I added it to the patch) that > says what's read/written, I'll have to look again. > > Maybe you could add a sysctl to limit access to some specific range? > I dunno... I really think what I have is the Right Thing To Do... Someone > else from freebsd-acpi@ suggested this approach. Maybe someone versed in > ACPI could clarify from the spec? > > > Don't mind me, just thinking aloud, and I've no idea how this might > > relate to Daniele's issue with stale battery data? > > Agreed... I'm pretty much just blindly tossing the patch over to her. :-) > She did complain about suspend issues, and my patch fixes suspend issues > on my HP and another guinea pig from the mailing list (with an HP). Next I > need to figure out why acpi_hp doesn't work on my laptop, as I see SystemIO > calls to 0x72/0x73 when I try to adjust the brightness. > > Thanks, > Anthony > > cheers, Ian > > > > PS Daniele: no, never tempted by Sonys; rusted-on Thinkpad kinda guy :) > > _______________________________________________ > > [email protected] mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > > To unsubscribe, send any mail to "[email protected]" > > > > _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "[email protected]"
