ACPI support - Freebsd 10 on Sony Vaio VPCCA3C5E

[Daniele Mazzotti]

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.

@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> 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>:
>  >
>  > > 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
>