On 6/25/2017 8:33 AM, Manuel Wolfshant wrote:
On 06/25/2017 05:52 PM, Philip Rhoades wrote:
Larry,
On 2017-06-25 23:26, Larry Fahnoe wrote:
Hi Phil,
I don't have an answer to your question about the lack of LAN ports,
I think it is weird - with everything else being connected to LANs
lik
On Tue, Sep 16, 2008 at 03:12:22PM -0400, tarbeite wrote:
>Hi all
.
.
.
.
>
>case $(1) in
>onbattwarn)
>WALL "UPS is down fix me please"
>echo "TIM_UPS is on Battery for more then 10 seconds" \
>| mailx -r "[EMAIL PRO
On Tue, Apr 22, 2008 at 11:15:27AM +0200, Arjen de Korte wrote:
> > Attached is approx 30 sec of output from the following command:
>
[...]
>
> /* Get HID notifications on Interrupt pipe first */
> /* TODO: cap number of times we check for events? */
> while ((evtCount = HIDGe
On Mon, Apr 21, 2008 at 09:36:07AM +0200, Arjen de Korte wrote:
> John Darrah wrote:
>> I have determined that the the socket is never created because the program
>> never reaches dstate_init().
>
> It *must* reach this, otherwise it would never reach the part where it
On Mon, Mar 31, 2008 at 09:16:03AM +0200, Arjen de Korte wrote:
> John Darrah wrote:
>
>> I have determined that the socket is not being created. Even with -
>> the following is never executed:
>>
>> upsdebugx(2, "dstate_init: sock %s open on fd %d",
On Sun, Mar 30, 2008 at 10:14:03AM +0200, Arjen de Korte wrote:
>
> > The only reference to "/var/run/nut" in the strace is a
> > chdir("/var/run/nut").
>
> That's where the driver has just dropped priviledges (line 537 in
> drivers/main.c) and just before it sets up the signals (line 540).
>
>
On Sat, Mar 29, 2008 at 10:50:12PM -0400, Charles Lepple wrote:
> On Sat, Mar 29, 2008 at 10:30 PM, John Darrah <[EMAIL PROTECTED]> wrote:
> > Does the following strace segment mean any thing.
> >
> > .
> > .
> > socket(PF_FILE, SOCK_STREAM, 0)
On Sat, Mar 29, 2008 at 06:28:38PM +0100, Arjen de Korte wrote:
>
> You may also want to checkout that you didn't do something
> weird to the STATEPATH (the directory where this socket is
> created). After starting up the driver, you should be able
> to see a listening socket being created ther
I wrote a while back about the inability to kill the
following command with anything but "kill -9" and the
apparent high speed polling rate.
# /lib/nut/usbhid-ups -u root -DDD -a trippy
The setup I have worked on a previous version of nut, but I
have forgotten at what point it stopped working.
On Thu, Feb 07, 2008 at 08:24:13AM +0100, Arjen de Korte wrote:
> > The previous driver would stop by typing a CTRL-C when
> > running interactively in debug mode. The new driver will not
> > respond to a CTRL-C. It does not respond to a "kill -1",
> > "kill -2" or a "kill -15" either (Which may or
On Wed, Feb 06, 2008 at 09:29:47AM +0100, Arjen de Korte wrote:
> > After updating from 2.2.0 to 2.2.1, the following command
> > seems to go into loop and becomes unresponsive except for a
> > "kill -9":
> >
> > /lib/nut/usbhid-ups -u root -DDD -a trippy
>
> Running the driver in debug mode has a
OS: Linux (Linux ares 2.6.22-3-686 #1 SMP)
Dist: Debian (testing)
UPS: Tripp Lite Omni1000 LCD
After updating from 2.2.0 to 2.2.1, the following command
seems to go into loop and becomes unresponsive except for a
"kill -9":
/lib/nut/usbhid-ups -u root -DDD -a trippy
It seem that the previous v
On Sun, Jan 27, 2008 at 10:46:13AM +0100, Arjen de Korte wrote:
>
> > Does the following error message have a specific meaning:
> >
> > usb 1-1: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 161 rq 1 len 2
> > ret -75
>
> [...]
>
> > Can't retrieve Report 49 (75): Value too large for defined
Does the following error message have a specific meaning:
usb 1-1: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 161 rq 1 len 2 ret
-75
I get two of these messages every time I run the following:
/lib/nut/usbhid-ups -u root -DDD -a trippy
The following is the output from the above comm
14 matches
Mail list logo
