[Nut-upsuser] MGE Pulsar Extreme communication problems

[Arnaud Quette]

2006/6/15, Daniel O'Connor <doconnor at gsoft.com.au>:
> On Thursday 15 June 2006 18:40, Arnaud Quette wrote:
> > > Have you had a chance to look at this? We're getting pretty close to ship
> > > date so I won't be able to test it after much longer.
> >
> > yes, I'm currently modifying some things on the Development tree.
> > outlet.X.switch doesn't work as expected, but you can have the same
> > result by using outlet.x.delay.{shutdown,start), ie:
> > - the equivalent to load.off on outlet.1 is:
> > upsrw -u user -p password -s outlet.x.delay.shutdown=0 ups at host
> >
> > the same goes for load.on on outlet.1:
> > upsrw -u user -p password -s outlet.x.delay.start=0 ups at host
> >
> > I'll add new commands (ie outlet.X.load.{on,off}), but I don't think
> > I'll backport it for 2.0.4. While waiting, you have the above solution
>
> That is fine - the independent port switching is just gravy :)
>
> > > kiruna# /usr/local/libexec/nut/newhidups -k -u nutmon -D -D
> > >  ...
> >
> > a bit hard to check this line, with all the html noise.
> > can you send it back for validation.
>
> Hmm strange, it's just a text attachment... I generated it using script.
>
> I've trimmed off the control characters and re-attached it.
>
> > > Shutoff command failed (setting ondelay)
> > > Shutdown failed.
> > > kiruna# ^D=08=08exit
> >
> > I've tried with several EXtreme 700C and 1000C (no 1500 underhand), on
> > Linux and everything works as expected. Note that both using inline
> > {off,on}delay (using "-x offdelay...") and config file parameters
> > works.
>
> Hmm, could be a Linux vs FreeBSD USB problem :(

possible, I'm not sure for the moment.
what is sure that the problem comes from the fbsd usb stack or
possibly from libusb for bsd...

> > Here are several things to validate:
> > - are you sure about the ups.conf file used (ie configured in
> > /etc/nut, but using /usr/local/ups/etc...)?
>
> It is definitely using /usr/local/etc
> (I have no NUT config in /etc)
>
> > - are the device right ok (rw) for nutmon?
>
> Yes, I have chown'd /dev/ugen0* to the nutmon user.
>
> > - a good test is to try:
> > "newhidups -u root -DDD -x offdelay=90 -x ondelay=120 -k auto"
> > after having done "export USB_DEBUG=3"
> > and then send me back the log excerpt (starting at "Initiating UPS
> > shutdown")
>
> ...
> Initiating UPS shutdown
> entering setvar(ups.delay.start, 120)
>
> entering string_to_path()
> Looking up UPS
> Looking up PowerSummary
> Looking up DelayBeforeStartup
> usb_control_msg: 161 1 791 0 0x514f34 8 4000
> Report : (8 bytes) => 17 FF FF FF CB 1F 51 0A
> =>> SET: Before set: -10.00 (120)
> =>> SET: after exp: 12/12.00 (exp = 0.10)
> PhyMax = 0, PhyMin = 0, LogMax = 65535, LogMin = -1
> =>> SET: after PL: 12
> ==> Report after setvalue: (8 bytes) => 17 0C 00 00 CB 1F 51 0A
>
> usb_control_msg: 33 9 791 0 0x514f34 8 4000
> USB error: error sending control message: Input/output error

       ^^^^^^^^^^^
the problem is here. But I don't know why we get an I/O error...
the USB data is fine and the HID report data seems too, so the problem
is deeper.

Another test: while having newhidups running in debug mode, call upsrw
to set ups.delay.start to 120, and check if the I/O error has been
reproduced. I don't have much to say for the moment, but after a good
night, I might be back with more... You should also contact bsd
hackers to see if there is something known, or other ideas.

finally, what are you bsd and libusb versions?

Arnaud
-- 
Linux / Unix Expert - MGE UPS SYSTEMS - R&D Dpt
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://people.debian.org/~aquette/
OpenSource Developer - http://arnaud.quette.free.fr/