Re: atrtc.c patch for ACPI CMOS region (was Re: ACPI support - Freebsd 10 on Sony Vaio VPCCA3C5E)

2014-07-16 Thread Daniele Mazzotti 
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"  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 :)
> > ___
> > 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
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

atrtc.c patch for ACPI CMOS region (was Re: ACPI support - Freebsd 10 on Sony Vaio VPCCA3C5E)

2014-07-16 Thread Anthony Jenkins 
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
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: ACPI support - Freebsd 10 on Sony Vaio VPCCA3C5E

2014-07-16 Thread Ian Smith 
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 :)
___
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"

Re: ACPI support - Freebsd 10 on Sony Vaio VPCCA3C5E

2014-07-16 Thread Anthony Jenkins 
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
>
> @Ian: there is only one thing I got from this problem NEVER BUY A SONY VAIO. 
> It took 3 years before having support for my WiFi card on BSD and I hate 
> Linux (especially Ubuntu)... There is no way I am going to use that OS on my 
> desktop :-).
>
> Cheers,
> Daniele.
>
> Il 16/lug/2014 07:20 "Ian Smith"  > ha scritto:
>
> On Tue, 15 Jul 2014 20:47:44 +0200, Daniele Mazzotti wrote:
>  > Hi Ian,
>  >
>  > I have just rebooted the PC after turning the deep debug on. Here is 
> the
>  > output: http://pastebin.com/H61zJhqc. It is very likely that the dmesg 
> has
>  > been cut due to the large amount of output. Is there any way to have 
> it all?
>  >
>  > Cheers,
>  > Daniele.
>
> >From the boot menu you can drop to the loader, and enter something like:
>   set kern.msgbufsize=12
>   boot
> where the default is about 64K these days, I think.
>
> However I couldn't spot anything further regarding 'battery|BAT0', and
> you did catch the start of initialisation.  I'm out of my depth, but you
> might also try layer 'ACPI_EC' with high verbosity?
>
> You shoudn't need to reboot to try things now that ACPI_DEBUG is enabled
> in your kernel; you can adjust them on the fly.  From section 11.16.6 on
> the acpi-debug page:
>
> "If the information you want is triggered by a specific event (say, a
> suspend and then resume), you can leave out changes to loader.conf and
> instead use sysctl to specify the layer and level after booting and
> preparing your system for the specific event. The sysctls are named the
> same as the tunables in loader.conf."
>
> So you could avoid all the boot messages, if they're not helpful, and
> log events like switching from AC to battery and vice versa, which might
> trigger interrogating the battery (via the EC, probably), by adjusting
> those sysctls, just for an example:
>
> root# sysctl debug.acpi.layer="ACPI_EC ACPI_BATTERY ACPI_AC_ADAPTER"
> root# sysctl debug.acpi.level="ACPI_LV_VERBOSITY3"
>
> But I'm just stabbing in the dark, really .. good luck.
>
> cheers, Ian
>
>  > 2014-07-15 20:22 GMT+02:00 Ian Smith  >:
>  >
>  > > On Tue, 15 Jul 2014 19:49:46 +0200, Daniele Mazzotti wrote:
>  > >
>  > >  > I made a few step ahead (at least on my side) and tried to follow 
> the
>  > >  > recommendation from the handbook (
>  > >  > http://www.pl.freebsd.org/doc/handbook/acpi-debug.html).
>  > >  >
>  > >  > I was able to turn on the verbose boot and here you can find the 
> output:
>  > >  > http://pastebin.com/kkDAZEVb. At boot time I can see an error 
> stating
>  > >  > "battery0: battery initialization failed, giving up" which is 
> thrown by
>  > > the
>  > >  > acpi_cmbat_init_battery within acpi_cmbat.c module. After six 
> retries
>  > > the
>  > >  > error is printed out. Actually I am not able to figure out who is
>  > > calling
>  > >  > the method, but that is another story.
>  > >
>  > > Actually you'll see those messages on a 'normal' verbose boot, ie
>  > > there's nothing extra logged of note regarding battery issues.  If 
> you
>  > > are up for lots more output on one boot at least, perhaps try what
>  > > acpi(4) suggests:
>  > >
>  > >debug.acpi.layer="ACPI_ALL_COMPONENTS ACPI_ALL_DRIVERS"
>  > >debug.acpi.level="ACPI_LV_ALL_EXCEPTIONS"
>  > >
>  > > which is less deep, but wider :)  Communications with batteries 
> often,
>  > > likely usually, is moderated by the embedded controler (ACPI_EC) and 
> it
>  > > wouldn't hurt to report any exceptions from other subsystems also. If
>  > > that yields nothing useful you could increase the level ..
>  > >
>  > > Sorry, I can't read messages backwards very well, so I'll drop the 
> tail.
>  > >
>  > > cheers, Ian
>

___
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"