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