ACPI support - Freebsd 10 on Sony Vaio VPCCA3C5E

[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" <smithi at nimnet.asn.au <mailto:smithi at nimnet.asn.au>> 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=120000
>       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 <smithi at nimnet.asn.au <mailto:smithi at nimnet.asn.au>>:
>      >
>      > > 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
>