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.


Il 16/lug/2014 23:08 "Anthony Jenkins" <anthony.b.jenk...@att.net> ha

> 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 :)
> > _______________________________________________
> > freebsd-acpi@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
> > To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
> >
freebsd-acpi@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Reply via email to