Le Mer 21 fév 07 à 9:31:21 +0100, Arnaud Quette <[EMAIL PROTECTED]>
écrivait :
> not an idea, but comments:
> The usb problem is huger than thought (not limited to interrupt handling)
> It seems that the ugen <-> UPS connection is lost somewhere, and can't
> be reattached ("Device does not match
On Thursday 15 March 2007 13:45, Rob Wise wrote:
> On 22/02/07, Rob Wise <[EMAIL PROTECTED]> wrote:
> > On 22/02/07, Thierry Thomas <[EMAIL PROTECTED]> wrote:
> > > Actually the USB stack is beeing rewritten from scratch by Hans Petter
> > > Selasky. It has not yet been committed, but it's availabl
On 22/02/07, Rob Wise <[EMAIL PROTECTED]> wrote:
On 22/02/07, Thierry Thomas <[EMAIL PROTECTED]> wrote:
> Actually the USB stack is beeing rewritten from scratch by Hans Petter
> Selasky. It has not yet been committed, but it's available for testing:
I'll give this a try and report back with re
Thanks a lot for your actions Thierry,
also, please feed us back when you have news on these points.
one more beer on your account when you're passing by Grenoble ;-)
2007/2/21, Thierry Thomas <[EMAIL PROTECTED]>:
Le Lun 19 fév 07 à 10:03:21 +0100, Arnaud Quette <[EMAIL PROTECTED]>
écrivait:
On 22/02/07, Thierry Thomas <[EMAIL PROTECTED]> wrote:
Actually the USB stack is beeing rewritten from scratch by Hans Petter
Selasky. It has not yet been committed, but it's available for testing:
I'll give this a try and report back with results.
Cheers,
Rob
__
Le Lun 19 fév 07 à 10:03:21 +0100, Arnaud Quette <[EMAIL PROTECTED]>
écrivait :
> >Just to clarify this.. There is a bug with the USB code in FreeBSD
> >6.2 causing the driver to block - do you know if anyone has raised a
> >PR for it?
>
> I don't know.
>
> @Thierry: any input on this point?
Le Mer 21 fév 07 à 9:31:21 +0100, Arnaud Quette <[EMAIL PROTECTED]>
écrivait :
> It seems freebsd has got some more work to be done on the USB stack...
Actually the USB stack is beeing rewritten from scratch by Hans Petter
Selasky. It has not yet been committed, but it's available for testing:
On 21/02/07, Arnaud Quette <[EMAIL PROTECTED]> wrote:
When in the above situation, does relaunching newhidups / usbhid-ups
solves the point (=> does the driver start and run fine?)
Yeah, after restarting the driver all is well for another 8 hours or so.
It seems freebsd has got some more wor
Hi all,
At 09:31 21/02/2007, you wrote:
2007/2/20, Rob Wise <[EMAIL PROTECTED]>:
Just to follow up on my recent success - it seems the workaround is
not working 100%. I stopped getting data from the UPS after a while
and had to restart usbhid-ups to get it working again. I ran it with
- a
2007/2/20, Rob Wise <[EMAIL PROTECTED]>:
Just to follow up on my recent success - it seems the workaround is
not working 100%. I stopped getting data from the UPS after a while
and had to restart usbhid-ups to get it working again. I ran it with
- and caught the following just before it die
Just to follow up on my recent success - it seems the workaround is
not working 100%. I stopped getting data from the UPS after a while
and had to restart usbhid-ups to get it working again. I ran it with
- and caught the following just before it died:
---Start output---
parsing BelowRemaini
On Monday 19 February 2007 19:37, Arnaud Quette wrote:
> > I tried setting the power share output off but the load continued on as
> > normal, ie..
> > upsrw -s outlet.2.delay.shutdown=0 -u user -p password [EMAIL PROTECTED]
>
> Are you sure your unit supports outlet.2?
> ie, validating with an ups
2007/2/19, Arjen de Korte <[EMAIL PROTECTED]>:
[...]
> Also your comment "(so the driver only polls the UPS)" - does this
> mean the UPS will not be able to notify NUT of a power failure as it
> occurs, but we'll pick it up next time NUT polls?
As Arnaud already answered, yes. You may want to r
Hi Daniel
2007/2/19, Daniel O'Connor <[EMAIL PROTECTED]>:
On Friday 16 February 2007 22:51, Arnaud Quette wrote:
> then relaunch usbhid-ups in debug and feed us back,
> Note that this is only a temporary fix that disable interrupt handling
> (so the driver only polls the UPS), while waiting for
[...]
> Also your comment "(so the driver only polls the UPS)" - does this
> mean the UPS will not be able to notify NUT of a power failure as it
> occurs, but we'll pick it up next time NUT polls?
As Arnaud already answered, yes. You may want to reduce the interval
between polls by setting 'poll
Hi Arnaud,
On 16/02/07, Arnaud Quette <[EMAIL PROTECTED]> wrote:
does the driver block on "Waiting for notifications... "
or do you see some other identical messages?
if the driver is blocked, then you have (about) the same problem as
solaris (but they don't have implemented USB interrupts thro
[adding back nut list ; please, keep it cc'ed]
2007/2/19, Rob Wise <[EMAIL PROTECTED]>:
Hi Arnaud,
On 16/02/07, Arnaud Quette <[EMAIL PROTECTED]> wrote:
> does the driver block on "Waiting for notifications... "
> or do you see some other identical messages?
>
> if the driver is blocked, then y
On Friday 16 February 2007 22:51, Arnaud Quette wrote:
> then relaunch usbhid-ups in debug and feed us back,
> Note that this is only a temporary fix that disable interrupt handling
> (so the driver only polls the UPS), while waiting for a proper
> solution in freebsd / sun...
I tried this on an M
2007/2/16, Arjen de Korte <[EMAIL PROTECTED]>:
> My ups.conf:
> [mge-nova]
> driver=usbhid-ups
> port=auto
> desc="MGE Nova 600VA on Bozo"
> vendorid = 0463
> pollinterval = 30
The latter needs to be 'pollfreq', not 'pollinterval'. I know this is not
docu
fellows,
2007/2/16, Rob Wise <[EMAIL PROTECTED]>:
On 16/02/07, Arjen de Korte <[EMAIL PROTECTED]> wrote:
> The latter needs to be 'pollfreq', not 'pollinterval'.
Ok - changed:
root# cat ups.conf
[mge-nova]
driver=usbhid-ups
port=auto
desc="MGE Nova 600VA on Bozo"
?
Herman
- Original Message -
From: "Rob Wise" <[EMAIL PROTECTED]>
To: "Arjen de Korte" <[EMAIL PROTECTED]>
Cc:
Sent: Friday, February 16, 2007 11:52 AM
Subject: Re: [Nut-upsuser] MGE Nova AVR 600 USB on FreeBSD
On 16/02/07, Arjen de Korte <[EMAIL PROTE
> The interval between thing 'Pinging UPS' messages seems to be roughly
> 5 seconds. Can I debug the parsing of the config file?
I would expect about 5 seconds between the 'Pinging UPS' messages if using
the default MAXAGE=15. Apparently, treating a double as an integer in
upsdebugx() doesn't wo
Hi Arjen,
On 16/02/07, Arjen de Korte <[EMAIL PROTECTED]> wrote:
> /usr/local/ups/etc/upsd.conf is world readable
That is bad, fix it.
I understand that in a production environment this would be bad, but
considering the software is not not working at this point I have
bigger fish to fry :)
On 16/02/07, Arjen de Korte <[EMAIL PROTECTED]> wrote:
The latter needs to be 'pollfreq', not 'pollinterval'.
Ok - changed:
root# cat ups.conf
[mge-nova]
driver=usbhid-ups
port=auto
desc="MGE Nova 600VA on Bozo"
vendorid = 0463
pollfreq = 30
root#
Unfortuna
> Unfortunately it didn't seem to have any effect. I have taken a debug
> of usbhid-ups starting up in case there is some info you need in
> there. It's too long to include here so I put it on pastebin:
> http://pastebin.com/882071
The startup of usbhid-ups seems to be OK. Could you startup ups
On 16/02/07, Arjen de Korte <[EMAIL PROTECTED]> wrote:
The server is reporting that it didn't hear from the server for 0 seconds,
which means that elapsed must be less than 1. So maxage must be smaller
than that, it can never be 60. Maybe the value is parsed incorrectly, so
could you try comment
> My ups.conf:
> [mge-nova]
> driver=usbhid-ups
> port=auto
> desc="MGE Nova 600VA on Bozo"
> vendorid = 0463
> pollinterval = 30
The latter needs to be 'pollfreq', not 'pollinterval'. I know this is not
documented, but trust me on this. Usually pollinterva
>>> sstate_dead: didn't hear from driver for UPS [mge-nova] for 0 seconds
>> Oops! For some reason you decided to set MAXAGE to 0 seconds. Please
>> read the appropriate section from 'man 5 upsd.conf' again. Do not set
>> MAXAGE to anything *lower* than the 15 second default.
> I included my upsd.
> ./upsd -DDD -u root
> Network UPS Tools upsd 2.1.0
> /usr/local/ups/etc/upsd.conf is world readable
That is bad, fix it.
> listen_add: added 0.0.0.0:3493
> listening on 0.0.0.0 port 3493
> Connected to UPS [mge-nova]: mge-nova
> /usr/local/ups/etc/upsd.users is world readable
This is *really*
Hi Rob,
Please state which version of FreeBSD you are running and if you have a
custom kernel.
There were some ugen bugs in FreeBSD 6.0
Herman
- Original Message -
From: "Rob Wise" <[EMAIL PROTECTED]>
To:
Sent: Friday, February 16, 2007 4:52 AM
Subject: [Nut-upsus
On Friday 16 February 2007 13:22, Rob Wise wrote:
> I've seen a few emails in the archives about problems polling MGE UPSs
> via USB under FreeBSD, but unfortunately I didn't find a solution in
> them that works for me.
I haven't been able to get it working, I stuck with RS232 :(
...
> I could us
Hi,
I've seen a few emails in the archives about problems polling MGE UPSs
via USB under FreeBSD, but unfortunately I didn't find a solution in
them that works for me.
A few details about my setup.. The UPS is a MGE Nova AVR 600 connected
via USB to a FreeBSD 6.2 box. I have tried both the nut
32 matches
Mail list logo
