GNOME Bugzilla – Bug 162641
Develop a FreeBSD ACPI backend for battstat
Last modified: 2005-03-02 03:44:42 UTC
I am running Freebsd 5.3 -p2 with gnome2-lite-2.8.2 and xorg 6.8.1. The computer is an Inspiron 8600. The issue that I am having is every few seconds gnome and all other applacations will freeze for a moment. This can become quite annoying while typing, listening to music, or watching a movie. From setting the gnome clock to display seconds, I can safely say that every 7 seconds gnome will freeze for one second. I have run Xorg by its self and it preforms without any issues. Any ideas?
This is more a support issue. I'm moving it to general product, but you'll have more luck first identifying the problem on a mailing list or a forum. Basically nobody reads bugs in the general, but no other product currently applies (first cause has to be identified). Things to try (these might be Linux specific): - Run top and check for high cpu usage apps - Check ~/.xsession-errors for strange messages Does it happen all the time, or only when using a sound application (listing to mp3 / watching movie)?
I have been checking the forums and have not come up with any answers. I did however find someone with the same setup i8600 Freebsd 5.3 –p2 that was having the same issue. http://www.freebsdforums.org/forums/showthread.php?s=e449c9b8c17444e8c87798858f364d9b&threadid=27436 >Things to try (these might be Linux specific): >- Run top and check for high cpu usage apps >- Check ~/.xsession-errors for strange messages I have checked top, and I avg around 3% CPU usage and there are no processes sucking up the CPU. I don’t have an .xsession-errors file, must be Linux specific. I did however, grep the Xorg.0.log file for errors and found nothing. Like I said before Xorg on its own runs without any issues. >Does it happen all the time, or only when using a sound application (listing to >mp3 / watching movie)? This happens about ever seven seconds, which affects music, movies, typing, dragging files, everything. It makes the system unusable. Thanks for you help, let me know if I need to get you any information.
At the url you pointed someone said: "If you go to the gnome clock and change it to show seconds and watch it, you will find that every 7 seconds the whole system pauses for 1 second." Can you remove the clock applet? Also try to make the gnome as minimal as possible. Eg start gconf-editor and disable /apps/nautilus/preferences/show_desktop (you maybe have to kill nautilus after that).
The problem is now fixed. I set my system to just boot X without gnome. From X I started various gnome applications, including nautilus and they all worked fine. After about 30 minuets of trying different things I came to realize the issues that was causing the brief freezing every few seconds was the “Battery Charge Monitor” in the top panel. When I removed it the system preformed great, when it was their, pausing ever few seconds. Is this a bug, should it freeze pause like that?
It should never freeze like that. Don't think the bug is in that applet, it only triggers the bug. However, the maintainer(s) might know more, moving.
Interesting. I saw something similar to this with ACPI a year or so ago. Since it's FreeBSD, I assume ACPI support is non-existant. Could apm be locking your kernel up for a bit? You could possibly write a test case for this by just calling the libapm calls every couple of seconds. I don't have access to the libapm documentation for FreeBSD (or infact a FreeBSD box), so I can't do you a test case. Do other battery monitors freeze your machine? How about the 'apm' command?
FreeBSD5.x has ACPI support although I will take your suggestion about writing a test case. I will let you know what I find.
Are you using this ACPI support? and do you have acpid?
I know the kernel loads acpi up because I have seen it when I run kldstat. However, I have yet to check my processes to make sure that it is running, but I would assume that it would be. I don’t have the laptop with me so I am unable to check. As far as acpid goes I believe it is a kernel patch for Linux.
Ok, I have looked at my laptop and I have both apci and apm enabled and running. When I run apm this is my output. APM version: 1.2 APM Management: Enabled AC Line status: off-line Battery Status: high Remaining battery life: 98% Remaining battery time: 3:35:00 Number of batteries: 2 Battery 0: Battery Status: high Remaining battery life: 98% Remaining battery time: 3:35:00 Battery 1: not present Resume timer: unknown Resume on ring indicator: disabled Does anything look suspicious to you?
You can't run ACPI and APM simultaneously AFAIK. Does running the apm command cause your machine to freeze?
I have read that both can not be run at the same time even if the laptop supports it, but I can load both ACPI and APM modules into the kernel without problems. However, once I place the battery monitor applet into the panel it proceeds to freeze the system every seven seconds. This is very strange since all the power management seems to be working fine.
Ok, these are the things we need to establish: - if you are using ACPI or APM - how ACPI works in FreeBSD (it is highly likely that we're not supporting ACPI in FreeBSD) - If any application that accesses the power management can freeze up the system In Linux, constantly polling /proc/acpi hurts, which is why we use asyncronous events from ACPId. I need a lot of specific implementation details for FreeBSD and your system to properly understand this bug.
>- if you are using ACPI or APM I am using ACPI and since ACPI interacts with the bios I made sure I was on the latest BIOS for my laptop. I also updated Freebsd to 5.3 –p3 so all my software is up to date. >- how ACPI works in FreeBSD >(it is highly likely that we're not supporting ACPI in FreeBSD) I agree gnome may not work properly with ACPI from freebsd. I can run the “acpiconf –i batt” command to display information about my battery while running gnome and I have no issues. >In Linux, constantly polling /proc/acpi hurts, which is why we >use asyncronous >events from ACPId. I need a lot of specific implementation details for >FreeBSD >and your system to properly understand this bug Freebsd does not have a /proc/acpi and does not use ACPId. What sort of implementation details do you want about ACPI and my system? Could you give me a few examples? Thanks.
Yeah, I figured that FreeBSD does not have /proc/acpi (obsessive usage of /proc is a Linux habit). I am not sure what the GNOME battery applet will be doing in this case (or how it even works, since there is no available supported power backend). It is possible that ACPI on FreeBSD can emulate APM, and that battstat is using that. From memory, there is no FreeBSD version of strace, so I we can't work out what calls the system is making when it freezes. I think the solution to this bug is to write a FreeBSD ACPI backend. This will currently prove to be a pain in the neck due to the shocking design of the battstat code, but should be doable. I do not have access to what's required to develop this backend. Failing all else, battstat will be rewritten when HAL support for batteries comes through, so ideally it will at least be fixed then (or will become a HAL problem).
> From memory, there is no FreeBSD version of strace No, but there's a similar program call ktrace. (And there's truss for Solaris, and other programs for other OSes; all of which I believe take totally different arguments as well...). Unfortunately, I don't have FreeBSD installed either, but for those that do they can take a look into ktrace.
bug #168355 has a fix for this. Marking this bug as a duplicate. *** This bug has been marked as a duplicate of 168355 ***