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" <smi...@nimnet.asn.au 
> <mailto:smi...@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 <smi...@nimnet.asn.au 
> <mailto:smi...@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
>

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

Reply via email to