Hi all,
After some research I've found that this device should run with the
blazer_usb driver.
Jun 3 16:15:38 pegasus kernel: ugen0.4: <vendor 0x0001> at usbus0
Jun 3 16:15:38 pegasus kernel: uhid0: <vendor 0x0001 product 0x0000,
class 0/0, rev 1.00/1.00, addr 4> on usbus0
However, even after shoehorning it;
[crees at pegasus]/usr/local/libexec/nut% sudo ./blazer_usb -a zigor
-DDDDDDDDD -x vendorid=0x0001 -x productid=0x0000 -x subdriver=krauler
Password:
Network UPS Tools - Megatec/Q1 protocol USB driver 0.04
(2.6.3-Unversioned directory)
0.000000 send_to_all: SETINFO driver.parameter.vendorid
"0x0001"
0.000013 send_to_all: SETINFO driver.parameter.productid
"0x0000"
0.000018 send_to_all: SETINFO driver.parameter.subdriver
"krauler"
0.000020 debug level is '9'
0.000874 language ID workaround enabled (using '0x409')
0.001019 No appropriate HID device found
0.001025 No supported devices found. Please check your device
availability with 'lsusb'
and make sure you have an up-to-date version of NUT. If this does not help,
try running the driver with at least 'subdriver', 'vendorid' and
'productid'
options specified. Please refer to the man page for details about these options
(man 8 blazer).
This is on FreeBSD with NUT updated to 2.6.3 (I've modified the port).
The UPS comes with UPSilon, but it's several years (!) old and I can't
even get it to install, let alone work.
Have I sent enough info? I'm willing to have a go at hacking the
driver, but having trouble getting started.
Chris
[crees at pegasus]/usr/local/libexec/nut% grep -v ^# /usr/local/etc/nut/ups.conf
[zigor]
port = auto
driver = blazer_usb
langid_fix = 0x409
desc = "Zigor UPS"
vendorid = 0001
productid = 0000
2012/6/3 Chris Rees <crees at freebsd.org>:> Hi all,Hi Chris,> After some research I've found that this device should run with the > blazer_usb driver. > > Jun ?3 16:15:38 pegasus kernel: ugen0.4: <vendor 0x0001> at usbus0 > Jun ?3 16:15:38 pegasus kernel: uhid0: <vendor 0x0001 product 0x0000, > class 0/0, rev 1.00/1.00, addr 4> on usbus0 > > However, even after shoehorning it; > > [crees at pegasus]/usr/local/libexec/nut% sudo ./blazer_usb -a zigor > -DDDDDDDDD -x vendorid=0x0001 -x productid=0x0000 -x subdriver=krauler > Password: > Network UPS Tools - Megatec/Q1 protocol USB driver 0.04 > (2.6.3-Unversioned directory) > ? 0.000000 ? ? send_to_all: SETINFO driver.parameter.vendorid "0x0001" > ? 0.000013 ? ? send_to_all: SETINFO driver.parameter.productid "0x0000" > ? 0.000018 ? ? send_to_all: SETINFO driver.parameter.subdriver "krauler" > ? 0.000020 ? ? debug level is '9' > ? 0.000874 ? ? language ID workaround enabled (using '0x409') > ? 0.001019 ? ? No appropriate HID device found > ? 0.001025 ? ? No supported devices found. Please check your device > availability with 'lsusb' > and make sure you have an up-to-date version of NUT. If this does not help, > try running the driver with at least 'subdriver', 'vendorid' and 'productid' > options specified. Please refer to the man page for details about these options > (man 8 blazer). > > This is on FreeBSD with NUT updated to 2.6.3 (I've modified the port). > > The UPS comes with UPSilon, but it's several years (!) old and I can't > even get it to install, let alone work. > > Have I sent enough info? ?I'm willing to have a go at hacking the > driver, but having trouble getting started. > > Chris > > [crees at pegasus]/usr/local/libexec/nut% grep -v ^# /usr/local/etc/nut/ups.conf > > [zigor] > ? ? ? ?port = auto > ? ? ? ?driver = blazer_usb > ? ? ? ?langid_fix = 0x409 > ? ? ? ?desc = "Zigor UPS" > ? ? ? ?vendorid = 0001 > ? ? ? ?productid = 0000it's quite probably due to a permission issue. See "4) Permissions" on http://people.freebsd.org/~thierry/nut_FreeBSD_HowTo.txt cheers, Arnaud -- Linux / Unix / Opensource Engineering Expert - Eaton - http://opensource.eaton.com Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org Debian Developer - http://www.debian.org Free Software Developer - http://arnaud.quette.free.fr
2012/8/11 Chris Rees <utisoft at gmail.com>> > On 11 Aug 2012 13:03, "Martyn Hill" <martyn.joseph.hill at gmail.com> wrote: > (...) > > My FreeBSD 8 appears to be running/linking against libusb20 - the 'new' > one... > > We killed the old one a long time ago ;) >not sure of what you exactly mean here! libusb 0.1 is still avail in FBSD 9: http://www.freebsd.org/cgi/ports.cgi?query=libusb&stype=all Update: while reading the comment on libusb1.0 website [1], I now understand why you're using "2.0"! "FreeBSD 8 and above include a FreeBSD-specific reimplementation of the libusb-1.0 API, so your applications will probably work there too. The source code for this library can be found: http://svnweb.freebsd.org/base/head/lib/libusb/" but still, your "killing" comment leave me in a doubtful state ;) cheers, Arno -- [1] http://www.libusb.org/wiki/libusb-1.0 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20120811/8117a2f1/attachment.html>
On 11/08/2012 20:13, Martyn Hill wrote:> On 11/08/2012 19:01, Arnaud Quette wrote: >> >> 2012/8/11 Martyn Hill <martyn.joseph.hill at gmail.com >> <mailto:martyn.joseph.hill at gmail.com>> >> >> On 10/08/2012 22:27, Arnaud Quette wrote: >>> >>> As I mentioned above I've now got it to 2.6.4, and have a >>> new message; >>> >>> [crees at pegasus]/usr/local/libexec/nut% sudo ./blazer_usb -a >>> zigor -DDDDDDDDDDDDD >>> Network UPS Tools - Megatec/Q1 protocol USB driver 0.08 >>> (2.6.4-Unversioned directory) >>> 0.000000 debug level is '13' >>> 0.001081 Checking device (0001/0000) >>> (/dev/usb//dev/ugen2.3) >>> 0.001688 - VendorID: 0001 >>> 0.001694 - ProductID: 0000 >>> 0.001697 - Manufacturer: unknown >>> 0.001701 - Product: unknown >>> 0.001705 - Serial Number: unknown >>> 0.001708 - Bus: /dev/usb >>> 0.001712 Trying to match device >>> 0.001717 Device matches >>> 0.001737 send_to_all: SETINFO ups.vendorid "0001" >>> 0.001744 send_to_all: SETINFO ups.productid "0000" >>> 0.001751 send_to_all: SETINFO device.type "ups" >>> 0.001758 send_to_all: SETINFO driver.version >>> "2.6.4-Unversioned >>> directory" >>> 0.001764 send_to_all: SETINFO driver.version.internal >>> "0.08" >>> 0.001770 send_to_all: SETINFO driver.name >>> <http://driver.name> "blazer_usb" >>> 0.001775 Trying megatec protocol... >>> 0.001786 send: Q1 >>> 0.002191 read: Unknown error >>> 0.002242 Permissions problem: Input/output error >>> >>> >>> damn BSD USB stack. is it the "new" or the "old" (I may totally >>> be off topic!) >> >> My FreeBSD 8 appears to be running/linking against libusb20 - the >> 'new' one... >> >> >> you mean libusb1.0? with libusb-compat? >> NUT USB drivers are still on 0.1, and need to be ported to 1.0. >> this may be (part of) the problem! > > Hummm... > >> >> can you please post back the list of libs linked. >> >>> it's not answering at all for now! the I/O error is initial. >>> you should try using "export USB_DEBUG=3", which will enable >>> libusb debug. >>> >>> I've just seen that Martin has sent more data... jumping on this >>> mail. >>> >>> cheers, >>> Arno >>> >> >> I'll also try this and see what it reveals... >> > > Can't see any debug output, but am probably misunderstanding something... > >> >> I've very (very very!) quickly looked at the snoop... >> can you send me an "lsusb -v -d0001:0000". > > Attached within archive as 'lsusb.txt' > >> another interesting test would be with usbhid-ups: >> - add the following in ups.conf >> [test] >> driver = usbhid-ups >> port = auto >> vendorid = 0001 >> productid = 0000 >> explore >> >> - and launch the driver: >> $ /path/to/usbhid-ups -DDDDD -a <ups.conf devname> >> > Attached within archive as 'usbhid-ups_test.txt'... > >> as told previously, compress the archive if needed, to stay under the >> 40 Kb limit. >> >> cheers, >> Arno >> > > > -- > "There are 10 types of people in this world. Those who understand binary and those who don't."-- "There are 10 types of people in this world. Those who understand binary and those who don't." -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20120811/ac917b51/attachment.html>
On 15/08/2012 22:23, Martyn Hill wrote:> Hi Arnaud! > > On 14/08/2012 21:50, Arnaud Quette wrote: >> >> >> 2012/8/14 Martyn Hill <martyn.joseph.hill at gmail.com >> <mailto:martyn.joseph.hill at gmail.com>> >> >> On 11/08/2012 21:27, Arnaud Quette wrote: >>> >>> >>> 2012/8/11 Martyn Hill <martyn.joseph.hill at gmail.com >>> <mailto:martyn.joseph.hill at gmail.com>> >>> >>> On 11/08/2012 21:00, Chris Rees wrote: >>> >>> On 11 August 2012 20:52, Martyn Hill >>> <martyn.joseph.hill at gmail.com >>> <mailto:martyn.joseph.hill at gmail.com>> wrote: >>> >>> On 11/08/2012 20:48, Chris Rees wrote: >>> >>> On 11 August 2012 20:29, Martyn Hill >>> <martyn.joseph.hill at gmail.com >>> <mailto:martyn.joseph.hill at gmail.com>> wrote: >>> >>> On 11/08/2012 20:24, Chris Rees wrote: >>> >>> On 11 August 2012 19:14, Arnaud Quette >>> <aquette.dev at gmail.com >>> <mailto:aquette.dev at gmail.com>> wrote: >>> >>> >>> 2012/8/11 Chris Rees >>> <utisoft at gmail.com >>> <mailto:utisoft at gmail.com>> >>> >>> >>> On 11 Aug 2012 13:03, "Martyn >>> Hill" >>> <martyn.joseph.hill at gmail.com >>> <mailto:martyn.joseph.hill at gmail.com>> >>> wrote: >>> (...) >>> >>> My FreeBSD 8 appears to be >>> running/linking against >>> libusb20 - the >>> 'new' >>> one... >>> >>> We killed the old one a long >>> time ago ;) >>> >>> not sure of what you exactly mean here! >>> libusb 0.1 is still avail in FBSD 9: >>> http://www.freebsd.org/cgi/ports.cgi?query=libusb&stype=all >>> >>> Update: while reading the comment on >>> libusb1.0 website [1], I now >>> understand why you're using "2.0"! >>> >>> "FreeBSD 8 and above include a >>> FreeBSD-specific reimplementation of the >>> libusb-1.0 API, so your applications >>> will probably work there too. The >>> source code for this library can be >>> found: >>> http://svnweb.freebsd.org/base/head/lib/libusb/" >>> >>> but still, your "killing" comment >>> leave me in a doubtful state ;) >>> >>> Oops, haha, sorry, that's right; we >>> didn't kill it, just switched >>> default, and loads of ports needed >>> modification over it. >>> >>> >>> Do we know how to 'use' the legacy libusb >>> 0.1 in FreeBSD? >>> >>> As Arnaud pointed out, they're still there; >>> including usb.h uses the >>> libusb 0.1 compat layer. >>> >>> >>> So, does that mean I would need to recompile nut, >>> but link it against libusb >>> 0.1 compat layer? >>> >>> If so, how would I go about that? >>> >>> My understanding is that you shouldn't need to be >>> concerned with >>> that-- NUT uses libusb-0.1, which is emulated in FreeBSD >>> with >>> libusb20. Thus changing the version to link with makes >>> no sense. >>> >>> Chris >>> >>> >>> OK, so back to square one... I guess testing the UPS on a >>> currently supported is the next most sensible step, then - >>> at least to determine if the driver really works with the >>> Zigor... >>> >>> >>> the good is that it's a HID device, as you've guessed, supported >>> by usbhid-ups. >>> though the device has a bad/buggy implementation: >>> - vendorid/productid, >>> - and the main "UPS", coded as 00860004 instead of 00840004. >>> I'll have to create a fix for this one. >> >> I patched your drivers/libhid.c and recompiled, which atleast >> allowed the incorrect code to be recognised as 'UPS'. Obviously, >> not enough to get things working... >> >> >>> >>> the bad news is the I/O errors: until it's fixed, we're stuck! >>> you should still be able to force compilation/link against the >>> actual libusb 0.1 (ie not 2.0 compat), and should really do it. >> >> Can't figure out how to do this and, in the light of Chris's >> comments previously, not sure it's supposed to be necessary... >> >>> a 2nd thing to check is uhid. iirc, you should either unload it >>> or blacklist the dev or something like that... >> >> I recompiled my FreeBSD kernel without uhid.ko and can >> succesfully load/unload uhid as a module now. >>> >>> cheers, >>> Arno >>> >> >> So, stalled for now, until I can figure how to link against >> libusb01 on FreeBSD... Not giving up hope yet, but no amount of >> googling is shinng a light on this point. :-( >> >> Thanks for your help thus far. >> >> >> send in your configure log and config.log (compressed) to see what >> gets detected at compile time. > > config.log <sent direct>... Not sure what you mean by my 'configure > log' that is distinct from config.log - could you please clarify? > > >> I'd also like to see the output of 'pkg-config --list-all', > > <sent direct>... > >> and still the ldd output (you never sent it iirc) >> > Oh yes - ldd against blazer_usb: > > KRISHNA# ldd /usr/local/libexec/nut/blazer_usb > /usr/local/libexec/nut/blazer_usb: > libusb.so.2 => /usr/lib/libusb.so.2 (0x2809a000) > libm.so.5 => /lib/libm.so.5 (0x280a8000) > libthr.so.3 => /lib/libthr.so.3 (0x280c2000) > libc.so.7 => /lib/libc.so.7 (0x280d7000) > > and usbhid-ups: > > KRISHNA# ldd /usr/local/libexec/nut/usbhid-ups > /usr/local/libexec/nut/usbhid-ups: > libusb.so.2 => /usr/lib/libusb.so.2 (0x280a2000) > libthr.so.3 => /lib/libthr.so.3 (0x280b0000) > libc.so.7 => /lib/libc.so.7 (0x280c5000) > > Is that what you needed? > >> cheers, >> Arno >> > Thanks again for your time... > > M. > > -- > "There are 10 types of people in this world. Those who understand binary and those who don't."-- "There are 10 types of people in this world. Those who understand binary and those who don't." -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20120815/f7f1f014/attachment.html>
2012/8/15 Martyn Hill <martyn.joseph.hill at gmail.com>> Hi Arnaud! >Hi Martin> > On 14/08/2012 21:50, Arnaud Quette wrote: > > > > 2012/8/14 Martyn Hill <martyn.joseph.hill at gmail.com> > >> On 11/08/2012 21:27, Arnaud Quette wrote: >> >> >> >> 2012/8/11 Martyn Hill <martyn.joseph.hill at gmail.com> >> >>> On 11/08/2012 21:00, Chris Rees wrote: >>> >>>> On 11 August 2012 20:52, Martyn Hill <martyn.joseph.hill at gmail.com> >>>> wrote: >>>> >>>>> On 11/08/2012 20:48, Chris Rees wrote: >>>>> >>>>>> On 11 August 2012 20:29, Martyn Hill <martyn.joseph.hill at gmail.com> >>>>>> wrote: >>>>>> >>>>>>> On 11/08/2012 20:24, Chris Rees wrote: >>>>>>> >>>>>>>> On 11 August 2012 19:14, Arnaud Quette <aquette.dev at gmail.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> 2012/8/11 Chris Rees <utisoft at gmail.com> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 11 Aug 2012 13:03, "Martyn Hill" <martyn.joseph.hill at gmail.com >>>>>>>>>> > >>>>>>>>>> wrote: >>>>>>>>>> (...) >>>>>>>>>> >>>>>>>>>> My FreeBSD 8 appears to be running/linking against libusb20 - the >>>>>>>>>>> 'new' >>>>>>>>>>> one... >>>>>>>>>>> >>>>>>>>>> We killed the old one a long time ago ;) >>>>>>>>>> >>>>>>>>> not sure of what you exactly mean here! >>>>>>>>> libusb 0.1 is still avail in FBSD 9: >>>>>>>>> http://www.freebsd.org/cgi/ports.cgi?query=libusb&stype=all >>>>>>>>> >>>>>>>>> Update: while reading the comment on libusb1.0 website [1], I now >>>>>>>>> understand why you're using "2.0"! >>>>>>>>> >>>>>>>>> "FreeBSD 8 and above include a FreeBSD-specific reimplementation >>>>>>>>> of the >>>>>>>>> libusb-1.0 API, so your applications will probably work there too. >>>>>>>>> The >>>>>>>>> source code for this library can be found: >>>>>>>>> http://svnweb.freebsd.org/base/head/lib/libusb/" >>>>>>>>> >>>>>>>>> but still, your "killing" comment leave me in a doubtful state ;) >>>>>>>>> >>>>>>>>> Oops, haha, sorry, that's right; we didn't kill it, just switched >>>>>>>> default, and loads of ports needed modification over it. >>>>>>>> >>>>>>> >>>>>>> Do we know how to 'use' the legacy libusb 0.1 in FreeBSD? >>>>>>> >>>>>> As Arnaud pointed out, they're still there; including usb.h uses the >>>>>> libusb 0.1 compat layer. >>>>>> >>>>> >>>>> So, does that mean I would need to recompile nut, but link it against >>>>> libusb >>>>> 0.1 compat layer? >>>>> >>>>> If so, how would I go about that? >>>>> >>>> My understanding is that you shouldn't need to be concerned with >>>> that-- NUT uses libusb-0.1, which is emulated in FreeBSD with >>>> libusb20. Thus changing the version to link with makes no sense. >>>> >>>> Chris >>>> >>> >>> OK, so back to square one... I guess testing the UPS on a currently >>> supported is the next most sensible step, then - at least to determine if >>> the driver really works with the Zigor... >> >> >> the good is that it's a HID device, as you've guessed, supported by >> usbhid-ups. >> though the device has a bad/buggy implementation: >> - vendorid/productid, >> - and the main "UPS", coded as 00860004 instead of 00840004. >> I'll have to create a fix for this one. >> >> >> I patched your drivers/libhid.c and recompiled, which atleast allowed >> the incorrect code to be recognised as 'UPS'. Obviously, not enough to get >> things working... >> >> >> >> the bad news is the I/O errors: until it's fixed, we're stuck! >> you should still be able to force compilation/link against the actual >> libusb 0.1 (ie not 2.0 compat), and should really do it. >> >> >> Can't figure out how to do this and, in the light of Chris's comments >> previously, not sure it's supposed to be necessary... >> >> a 2nd thing to check is uhid. iirc, you should either unload it or >> blacklist the dev or something like that... >> >> >> I recompiled my FreeBSD kernel without uhid.ko and can succesfully >> load/unload uhid as a module now. >> >> >> cheers, >> Arno >> >> >> So, stalled for now, until I can figure how to link against libusb01 on >> FreeBSD... Not giving up hope yet, but no amount of googling is shinng a >> light on this point. :-( >> >> Thanks for your help thus far. >> > > send in your configure log and config.log (compressed) to see what gets > detected at compile time. > > > config.log attached... Not sure what you mean by my 'configure log' that > is distinct from config.log - could you please clarify? > >perfect, thanks. "configure log" was referring to "configure output", which is just a user version of config.log (less details, more readable for an overview) it's a laziness from me, using this for a first "5 seconds" check, to see if there's a need to go in depth... I'd also like to see the output of 'pkg-config --list-all',> Attached... >I see no libusb out there, so we are using the fallback CFLAGS / LIBS values> > and still the ldd output (you never sent it iirc) > > Oh yes - ldd against blazer_usb: > > KRISHNA# ldd /usr/local/libexec/nut/blazer_usb > /usr/local/libexec/nut/blazer_usb: > libusb.so.2 => /usr/lib/libusb.so.2 (0x2809a000) > libm.so.5 => /lib/libm.so.5 (0x280a8000) > libthr.so.3 => /lib/libthr.so.3 (0x280c2000) > libc.so.7 => /lib/libc.so.7 (0x280d7000) > > and usbhid-ups: > > KRISHNA# ldd /usr/local/libexec/nut/usbhid-ups > /usr/local/libexec/nut/usbhid-ups: > libusb.so.2 => /usr/lib/libusb.so.2 (0x280a2000) > libthr.so.3 => /lib/libthr.so.3 (0x280b0000) > libc.so.7 => /lib/libc.so.7 (0x280c5000) > > Is that what you needed? >yup, thanks. I interpret this as "libusb 2 reimplementation on BSD also includes a libusb 0.1 compat, beside of the 1.0 one". as an example, on a Linux system: $ ldd drivers/usbhid-ups linux-gate.so.1 => (0xb77b5000) libusb-0.1.so.4 => /lib/libusb-0.1.so.4 (0xb778b000) libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb7770000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb75f1000) /lib/ld-linux.so.2 (0xb77b6000) beside of the recompilation with libusb 0.1, I'm still interested in seeing a verbose USB log from the current driver. so if "export USB_DEBUG=3" doesn't work, there should be another way to do the same thing. cheers, Arno (on holidays for 3 weeks, as of now...) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20120817/7deec36e/attachment-0001.html>
On 07/09/2012, at 5:01, Martyn Hill <martyn.joseph.hill at gmail.com> wrote:> Unfortunately, VirtualBox refused to allow me to attach the UPS USB port to the guest OS (saying 'busy with a previous request'), so that came to nothing - and after several night's effort::-(Windows may be connecting to the UPS using a service automatically. I am not sure how you would stop it but at a guess I would trying looking for a likely service and stop it.> So, do you (or anyone else here) have any guidance on how to force NUT to link against libusb-0.1 at compile time ???I think you'd have to mangle the configure script. What does pkg-config --cflags libusb say on your system?> I'm still not convinced that the FreeBSD implementation of libusb v2 is fully compatible with v0.1 - the available documentation is confusing...I believe it is compatible although 0.1 was evolved rather than designed :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C