gkrellmBUPS?

Hi list;

Recent changes in the kernel seem to be effecting this plugin, upsd, and the 
bulldog monitor from belkin, making a cpu hog out of upsd if its output is 
tapped into.

And of course belkin is totally un-responsive, to the point that my next ups 
will probably be an apc, and I may not wait till this one needs batteries to 
replace it it.

The changes have made upsd into a bit of a cpu hog, taking 2% or more of the 
cpu once it has establish communications with the ups, and it doesn't make 
any difference whether its setup for a real serial port, or thru an ftdi 
based usb-serial adapter.  The pl2303 based adapters have ceased to function 
with late kernels, so I had to buy others, getting a pair of FTDI based 
adapters based on the recommendations of the heyu list which has also noted 
problems with the pl2303 based adapters since forever.

This 2% cpu would almost be under the radar, except that when either the 
bulldog gui, or the gkrellmBUPS gui starts tapping into its data file for 
their displays, the cpu usage for upsd jumps up the 40-60% range, and 
according to htop, stays there even after bulldog or gkrellm's gui has been 
stopped.  Only killing upsd and restarting it works, and that only until one 
of the gui's starts looking at the PRO_NET.DAT file again.  Killing and 
restarting upsd changes the inode, and the only way to get gkrellmBUPS 
connected to it again is to purposely select a bogus file, apply it, then 
reselect the PRO_NET.DAT file and apply that change, at which point that 
portion of the gkrellm display comes alive again, and the cpu sky-rockets.

If I back up to an older kernel, someplace in the 2.6.18 range, then 
everything works.  And there have been a couple of patches that did help for 
a while that I was applying to all the new kernels I built.  One patch in 
particular, to drivers/serial/serial.c did have the desired effect, for both 
serial and usb-serial, but that has now ceased to work.  It still applies 
cleanly, but doesn't change things enough to bother with any more since 
2.6.21.1.

I have been playing with the newer schedulers, both the sd series from Con 
Kovilas and the cfs series from Ingo Molnar, and Con's sd-0.48 doesn't 
control this pig well at all, whereas Ingo's cfs-v10 seems to detect it and 
throttles it down into the 6-10% range, without apparently effecting how well 
upsd itself works.  So that the kernel I'm running for the nonce.

I've been un-successfull at convincing the lkml people there is a problem, 
mainly because the filtering at vger seems to black hole any message 
containing a patch its seen before, so the posts don't get to the list. 4 
such posts have been gobbled up in the last week alone.

Has anyone else observed this behavior?  And if so, can you note which kernel 
version the problem actually started with?  That would help to pinpoint the 
area where a git bisect might be able to find the offending patch(s).

As a side note, recent versions of this ups device will also show up 
as /dev/hiddev if a usb cable is plugged in, but no ones monitoring software 
seems to be capable of dealing with the already largely decoded output one 
gets by doing so, and then starting a cat on the device.

According to the specs, this /dev/hiddev is where a ups really should be 
handled, but both gkrellmBUPS and the belkin software can't handle it cause 
the belkin stuff is now 5 years old & even gkrellmBUPS is older than a 
working /dev/hiddev in the kernel is.  Which amazes me somewhat since Belkin 
helped write the hid device specs way back when.  upsd doesn't have to be 
running to see the output from /dev/hiddev, its all built into the kernel 
now.

Since changing a ups of this size will cost over $200 (its a 1500kva unit), 
I'd druther get my $ use out of the batteries in this one first, but its 
turning into a cast iron bitch to tolerate also.  And one normally gets a 
divorce from such...

Comments anyone?

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
He who walks on burning coals is sure to get burned.
		-- Sinbad
_______________________________________________
Gkrellm mailing list
[email protected]
http://lists.jutley.org/cgi-bin/mailman/listinfo/gkrellm