Critical battery low bug / linux mint 12
Recently received the CRITICAL battery low report, while unplugging from line power.
So i started looking into the problem. Found a few bugs in relation. Seems there is problems with gnome-power-management and upower. But I did start tracking down the event handling for the process on my own. First found the initial event handler script: etc/acpi/events/battery There was a linker in there to power.sh of course I found that and opened it. There is a few parts to it. One refers to check upower policy. another refers to gnome-power-management PMS. Ive been trying to firstly see if I cant alter the policy. I have looked through most of the files on the box related to upower. I did find org.freedesktop.upower.device. I altered some of the unknown elements in it. This was a test seeing as there was a patch for debian that this worked to clear up part of the problem. Im ubuntu based so that did not work. Of course. While using upower -m in terminal i found another org file come up. org/freedesktop/upower/devices/battery_bat1 I tried to find that as org.freedesktop.upower.devices.battery_bat1 , file search returned nothing. I have read there are some gnome-power-management workarounds. But I have been hoping to manually fix the upower problem. What and where is the upower policy for this function? Also does anyone know how to open or alter the battery_bat1 file either through ui or terminal? |
Hi there,
Quote:
[X] Doc CPU |
workarounds
Yes I have found multiple workarounds. That you could try.
This is a you tube link: It pertains to Ubuntu 11.10 (Linux Mint is based on ubuntu so it should work) http://www.youtube.com/watch?v=CQ-SMAK9dNo You can also try the fixes proposed here: http://askubuntu.com/questions/70877...ally-low-at-85 One person said that this fix worked for them: " I've found that editing /usr/share/polkit-1/actions/org.freedesktop.upower.policy so that hibernate's <allow_active> to "no" fixed it for me. It completely removes hibernate functionality (a plus for me as I abhor that garbage). As an added bonus it removes it from the session menu." Reference: https://bugs.launchpad.net/ubuntu/+s...er/+bug/860427 I have personally tried to alter one of the scripts to alter the unknown elements. As I stated above. A fix I was working on but have not found the time to confirm, was to change the dict entry for the "energy-empty" from double 0 to 10% of the energy-full number. (energy-empty=7.5 if energy-full=75) Reference: http://upower.freedesktop.org/docs/Device.html use ctrl-f: energy-empty From what I have read upower seems to have problems calculating the battery measurement properly. I also dont like the time-to-empty and time-to-full values are set at zero as well. It uses int64 to find those values. Then upower sends its findings across dbus to gnome-power-management witch addresses the findings accordingly. If you care to, read this: It will help to understand how the whole process works and runs through the troubleshooting procedures: http://www.monperrus.net/martin/trou...er-preferences Ive done some work on this problem ;) Post back if this helps or does not help. Possibly we can work together on the matter. Good luck. |
Hi there,
Quote:
Quote:
Quote:
And yes, I decline hibernation, too. When I want to turn off my computer, I shut down the system normally. In real life, however, I regret very much that mankind isn't made for hibernating - especially considering the hard winter conditions we're suddenly experiencing in Europe. But very often I felt the desire to retire in late November or early December, and wake up no sooner than late March or mid-April. Quote:
Quote:
Quote:
[X] Doc CPU |
workarounds
What I offered is just a drop in the bucket, compared to what I have read. ;)
Hopefully that puts it into a context you can relate to.
You are correct that the article falls short of completion. I think learning more commands such as gsettings, gconftool-2 and understanding dbus more will help with getting to a point of how to fix the problems that might be found in the troubleshooting process. Im freshly learning much of this. Commands that relate to these applications of the system, file structure and hierarchy. Some more reading material: http://hal.freedesktop.org/docs/PolicyKit/ https://wiki.ubuntu.com/DebuggingGNOMEPowerManager Ill be working on this over the weekend. I have been waiting for more time to dual boot linux mint 12 onto the laptop and begin testing. Ending note: To go further down the rabbit hole. There can be either a bios problem not conveying proper information. As well there can be Kernel problems to blame. Also making sure everything is up to date for upower, dbus, pm-utils, gnome-power-manager would be worth looking into. Lastly an interesting program came under my radar: http://live.gnome.org/BatteryStatus |
Good morning again!
Quote:
Quote:
Quote:
Quote:
Quote:
If the power supply is present, you can assume that the battery is being charged or fully charged already. If not, you assume that the notebook is running on battery bower. The battery voltage decreases slowly during dicharging, and it increases slowly during charging. This is, however, not a linear correlation. But knowing the battery type, you can tell the charging status as a percentage from that measurement (there's a big uncertainty anyway). Modern Li-Ion batteries have a small controller built in that monitors the inbound and outbond flow of energy. Summing it up: A battery monitoring software must know how to correctly get a battery voltage reading, and it must know the type of battery (most of them are Li-Ion nowadays). So I find it amazing that generic software can actually give a reasonable battery status report on most machines. Quote:
Quote:
I'm a long-term software engineer and electronics (hardware) developer, but I haven't yet dug that deep into these matters. Quote:
http://live.gnome.org/BatteryStatus That looks very interesting, thank you. I'll give it a try these days. [X] Doc CPU |
Hey Doc,
I have concerns with Google, in regards to the privacy as well. Amazing search engine hands down. I have spent a long time learning how to put in query's that would return the best results. Learning the "dorks" and all the engine can deliver. But I do not use any other service beyond that. I even stopped using the email service shortly after setting it up. lol Quote:
Temperature readings. This is something I was working on just recently. There are some programs that can help for use in linux mint. But if your pc does not have the proper physical temperature sensors on board then it is no use. A program called fancontrol works directly with lm-sensors witch reads temperatures. I wanted to use these to slow down the loud cpu fan on a laptop. Quote:
Quote:
I agree. The Software should be able to correctly read stats about the battery, in order to properly display battery life or in our case dead battery "critical battery low". I have read some forums where ubuntu users were complaining that upower (gnome power management) was showing in the battery tab that it was estimating battery life and showing a battery %. But would never finalize the estimation for time left. Another example of the software not being engineered correctly. Quote:
Quote:
I'm a long-term Electrician. I have only in the last 7 years begun to get this deep into computers. It started with the desire to understand the tcp/ip protocol, of course that required wanting to learn everything about osi, sockets, dns, networks, internet, intranet,......you get the idea. Security was always of interest as well. Be it on a per user basis or network security. IT, IS, you name it. Before this "recession" I was going to college and in the process of working towards some certifications. CEH and GPEN (CISSP is hard to meet the requirements without an employers reference.) I have dabbled in programming. I have worked with Visual Basic, Python, C, and ASM. I love the idea of programing in ASM. No compiling, faster, and smaller file sizes. I try to envision an entire system (hardware and software)completely built on ASM. Almost makes having 100gig+ hard drives a waste of space ;) . The CPU and electricity consumption to name a few would benefit from this implementation. Quote:
Ok I could write all night. Sorry for my long posts. |
Hi there,
Quote:
Quote:
Quote:
Quote:
Except DELL, because they do the same sh** as Apple: They have a little µC in their power supplies that communicates with the charging circuitry in the computer itself. That's why you won't be able to run a DELL notebook with a non-DELL power supply, even if the power ratings would match... *middle-finger at DELL* Quote:
Unfortunately, "Do nothing" isn't available for this event. :-( But trying to play with the settings, I had another strange effect: Just out of the blue, my mouse seemed to freeze. The system didn't react any more to moving or clicking the mouse! And I couldn't get it back to life again except by restarting the whole system. That's weird. Maybe Mint isn't as stable yet as it should be? Note that I'm running it with "Classical GNOME, no effects". Quote:
[X] Doc CPU |
brainstorming and all of the above
Hey Doc,
I do think I was invited by a friend to use gmail at the time. That is funny. Quote:
I have seen the applet your talking about in something I read. Trying to find answers. Quote:
Must be nice to work in peace. Both notebooks I have been working on are HP and the fan runs loud and proud full time. Quote:
Seems dell and apple are doing some sales security with those kinds of features. It is understandable from one standpoint but as a user I get annoyed by those kinds of road blocks. If in a pinch a need to utilize a part or adapter I like to be able to do so without having to match manufacturers and so forth. Quote:
I do believe it was a gnome problem. Not 100% sure. Since I could not replicate the problem I did not look to hard into it. I was and still am focused on this battery problem. I have been thinking of writing an event handler on my own. That is to replace or upgrade the acpi event handler found in linux mint 12. Upgrade would be easier as replacing would require linkers, more work. I may go this route if need be. But modifying the existing event seems more logical for a test avenue. I believe if my memory serves me well the path to the event is etc/acpi/event/battery Currently the event is engaged when ac is disconnected. Then it links to power.sh, the chain of problems begin from there in my opinion. That is being the start of upower's involvement in the process. So if I could stop the event process at the initial acpi battery event with a small script to check the battery and report to gnome. In attempt to do what upower is failing to do with less files required. Here is a reference link to a similar train of thought: http://askubuntu.com/questions/33062...-power-manager Then look at these for some script idea examples: http://www.thinkwiki.org/wiki/ACPI_a...battery_events http://mindspill.net/computing/linux...ttery-warning/ I used search query "etc+acpi+events+battery". There are a few other links that looked appealing. But Im going to call it a night. EOF Let me know your thoughts. Neq |
Manual repair, perhaps short period of time to solve your problem. I've also encountered similar problems, after repair, battery or often, therefore, change the batteries (buy here:deal-battery.com), then there is no similar problem occurs. If your battery is low, a long time, the battery quality is getting worse, relatively large impact on the computer, if you short-term support, repair to, to long-term consideration, to change the battery.
|
Hi there,
Quote:
That hasn't anything to do with the actual charging cycles, as they are controlled by a hardware circuit. Software can only monitor what's going on, but not interfere. [X] Doc CPU |
All times are GMT -5. The time now is 05:04 AM. |