Hello All, This is my first post to the list & I have tried to do as much searching and debugging on my own as I can bear. Please HELP! I am currently using up to date Centos 5.2 32-bit - kernel version: 2.6.18-92.1.10.el5PAE #1 SMP. I am using a Tripplite OMNIVS1500 via usb connection. I am using the tripplite_usb driver. I have tried to user versions 2.2.0 from an rpm, 2.2.2 & and the latest SVN version from source I have had all sorts of strange & aggravating results during the setup and testing of this device. Here I go: - The 3 main ups tools are all working very well back and forth with one an another. Udev rules are set, I am operating under user=nut. I can start all 3 services and query the UPS with 'upsc hub_ups' - which gives me data that looks fine. Everything looks good. - When I simulate the power failure - by pulling the plug to the UPS - I get the wall alerts that I am OB - GOOD! - BUT! 9 out of 10 times When I restore power to the UPS, the driver throws one of several errors and dissconnects. The other two services then assume since the UPS was least reachable in an OB situation that they must power down the system! And that they do! The other few times I repeat this exercise, it actually works! This is my dilemma! Here is the most persistant error type I get when running the Driver in Debug mode (I am using the latest trunk SVN): ----- UPS hub_ups at localhost on battery ***I PLUG IT BACK IN*** Error reading L value: Device detached? (error 0: could not claim interface 0: Device or resource busy) Reconnect attempt #1 ================================================== device has been disconnected, try to reconnect =================================================Checking device (09AE/0001) (003/010) - VendorID: 09ae - ProductID: 0001 - Manufacturer: TRIPP LITE - Product: TRIPP LITE UPS - Serial Number: unknown - Bus: 003 Trying to match device Device matches failed to claim USB device, trying 2 more time(s)... detaching kernel driver from USB device... trying again to claim USB device... Successfully reconnected Using OMNIVS 2001 protocol (2001) Unit ID not retrieved (not available on all models) Attached to Tripp Lite UPS Error reading S value: Device detached? (error 0: could not claim interface 0: Device or resource busy) Reconnect attempt #1 ================================================== device has been disconnected, try to reconnect =================================================Checking device (09AE/0001) (003/010) - VendorID: 09ae - ProductID: 0001 - Manufacturer: TRIPP LITE - Product: TRIPP LITE UPS - Serial Number: unknown - Bus: 003 Trying to match device Device matches failed to claim USB device, trying 2 more time(s)... detaching kernel driver from USB device... trying again to claim USB device... Successfully reconnected *Error reading protocol* ------- Output from 'upsc hub_ups': battery.charge: 95 battery.voltage: 13.19 battery.voltage.nominal: 24 driver.name: tripplite_usb driver.parameter.pollinterval: 2 driver.parameter.port: auto driver.version: 2.3.0-1519 driver.version.internal: 0.18 input.voltage: 0.00 input.voltage.nominal: 120 output.voltage: 118.0 ups.debug.load_banks: 0 ups.debug.V: 31 30 34 30 58 58 0d '1040XX.' ups.delay.shutdown: 64 ups.firmware: F2211.A ups.firmware.aux: protocol 2001 ups.mfr: Tripp Lite ups.model: UPS ups.power.nominal: 1500 ups.status: OB [root at cssgate2 bin]# ./upsc hub_ups battery.charge: 100 battery.voltage: 14.69 battery.voltage.nominal: 24 driver.name: tripplite_usb driver.parameter.pollinterval: 2 driver.parameter.port: auto driver.version: 2.3.0-1519 driver.version.internal: 0.18 input.voltage: 114.40 input.voltage.nominal: 120 output.voltage: 118.5 ups.debug.load_banks: 0 ups.debug.V: 31 30 34 30 58 58 0d '1040XX.' ups.delay.shutdown: 64 ups.firmware: F2211.A ups.firmware.aux: protocol 2001 ups.mfr: Tripp Lite ups.model: UPS ups.power.nominal: 1500 ups.status: OL ----------- Please direct me in what I should do from here. This is my first net-admin type job and I want to make a great impression. Please guide me through this, Any other output or info you need, please just ask. Thank you, Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20080811/d78f28f3/attachment.htm
Jon, I'm also new and don't have any real answer for you, but when you said you tested your unit by unplugging, I recalled a warning I have read. The warning (I believe in the Tripplite Owner's guide) said not to test by unplugging since that removes the ground connection. Without a ground connection, your system may be grounded only via some signal cables which might cause peculiar or damaging effects. My OmniPlus1500LCD unit has a button to push for testing. Without a special button, using a switched power strip can turn off power while keeping the ground connection. Craig On Monday 11 August 2008 09:57:42 Jon Bougher wrote:> Hello All, > > This is my first post to the list & I have tried to do as much searching > and debugging on my own as I can bear. Please HELP! > > I am currently using up to date Centos 5.2 32-bit - kernel version: > 2.6.18-92.1.10.el5PAE #1 SMP. I am using a Tripplite OMNIVS1500 via usb > connection. I am using the tripplite_usb driver. I have tried to user > versions 2.2.0 from an rpm, 2.2.2 & and the latest SVN version from source > > I have had all sorts of strange & aggravating results during the setup and > testing of this device. > > Here I go: > > - The 3 main ups tools are all working very well back and forth with one an > another. Udev rules are set, I am operating under user=nut. I can start all > 3 services and query the UPS with 'upsc hub_ups' - which gives me data that > looks fine. Everything looks good. > > - When I simulate the power failure - by pulling the plug to the UPS - I > get the wall alerts that I am OB - GOOD! > > - BUT! 9 out of 10 times When I restore power to the UPS, the driver throws > one of several errors and dissconnects. The other two services then assume > since the UPS was least reachable in an OB situation that they must power > down the system! And that they do! The other few times I repeat this > exercise, it actually works! This is my dilemma! > > Here is the most persistant error type I get when running the Driver in > Debug mode (I am using the latest trunk SVN): > > ----- > > UPS hub_ups at localhost on battery > > ***I PLUG IT BACK IN*** > > Error reading L value: Device detached? (error 0: could not claim interface > 0: Device or resource busy) > Reconnect attempt #1 > =================================================> = device has been disconnected, try to reconnect > =================================================> Checking device (09AE/0001) (003/010) > - VendorID: 09ae > - ProductID: 0001 > - Manufacturer: TRIPP LITE > - Product: TRIPP LITE UPS > - Serial Number: unknown > - Bus: 003 > Trying to match device > Device matches > failed to claim USB device, trying 2 more time(s)... > detaching kernel driver from USB device... > trying again to claim USB device... > Successfully reconnected > Using OMNIVS 2001 protocol (2001) > Unit ID not retrieved (not available on all models) > Attached to Tripp Lite UPS > Error reading S value: Device detached? (error 0: could not claim interface > 0: Device or resource busy) > Reconnect attempt #1 > =================================================> = device has been disconnected, try to reconnect > =================================================> Checking device (09AE/0001) (003/010) > - VendorID: 09ae > - ProductID: 0001 > - Manufacturer: TRIPP LITE > - Product: TRIPP LITE UPS > - Serial Number: unknown > - Bus: 003 > Trying to match device > Device matches > failed to claim USB device, trying 2 more time(s)... > detaching kernel driver from USB device... > trying again to claim USB device... > Successfully reconnected > *Error reading protocol* > > ------- > > Output from 'upsc hub_ups': > > > battery.charge: 95 > battery.voltage: 13.19 > battery.voltage.nominal: 24 > driver.name: tripplite_usb > driver.parameter.pollinterval: 2 > driver.parameter.port: auto > driver.version: 2.3.0-1519 > driver.version.internal: 0.18 > input.voltage: 0.00 > input.voltage.nominal: 120 > output.voltage: 118.0 > ups.debug.load_banks: 0 > ups.debug.V: 31 30 34 30 58 58 0d '1040XX.' > ups.delay.shutdown: 64 > ups.firmware: F2211.A > ups.firmware.aux: protocol 2001 > ups.mfr: Tripp Lite > ups.model: UPS > ups.power.nominal: 1500 > ups.status: OB > [root at cssgate2 bin]# ./upsc hub_ups > battery.charge: 100 > battery.voltage: 14.69 > battery.voltage.nominal: 24 > driver.name: tripplite_usb > driver.parameter.pollinterval: 2 > driver.parameter.port: auto > driver.version: 2.3.0-1519 > driver.version.internal: 0.18 > input.voltage: 114.40 > input.voltage.nominal: 120 > output.voltage: 118.5 > ups.debug.load_banks: 0 > ups.debug.V: 31 30 34 30 58 58 0d '1040XX.' > ups.delay.shutdown: 64 > ups.firmware: F2211.A > ups.firmware.aux: protocol 2001 > ups.mfr: Tripp Lite > ups.model: UPS > ups.power.nominal: 1500 > ups.status: OL > > ----------- > > Please direct me in what I should do from here. This is my first net-admin > type job and I want to make a great impression. Please guide me through > this, Any other output or info you need, please just ask. > > Thank you, > > Jonathan
On Mon, Aug 11, 2008 at 12:57 PM, Jon Bougher <jonb88 at gmail.com> wrote:> I have had all sorts of strange & aggravating results during the setup and > testing of this device.Just think about how aggravating it was to develop this driver :-)> - BUT! 9 out of 10 times When I restore power to the UPS, the driver throws > one of several errors and dissconnects. The other two services then assume > since the UPS was least reachable in an OB situation that they must power > down the system! And that they do! The other few times I repeat this > exercise, it actually works! This is my dilemma! > > Here is the most persistant error type I get when running the Driver in > Debug mode (I am using the latest trunk SVN):You may need to pass one or two more -D options to see what is really going on. I am suspicious of any "error code 0" messages because "0" usually means "no error".> Please direct me in what I should do from here. This is my first net-admin > type job and I want to make a great impression.In that case, you may want to recommend another brand of UPS for future upgrades. I can't speak for the Windows driver software, but from where we stand, the Tripp Lite protocols are a moving target. -- - Charles Lepple
> [did you mean to reply off-list? I don't mind having this discussion > on the nut-upsdev list.]I did mean to reply off-list. But I'll take it to the list now, leaving whatever I quoted in here.>>>> Here is the most persistant error type I get when running the >>>> Driver in >>>> Debug mode (I am using the latest trunk SVN): >>> >>> You may need to pass one or two more -D options to see what is really >>> going on. I am suspicious of any "error code 0" messages because "0" >>> usually means "no error". >> >> I have one remark here when it comes to the 'tripplite_usb' code. >> The UPS >> seems to reconnect after replugging the power (which is unsurprising, >> since this usually generates lots of EMI). But during the >> reconnection, >> you call upsdrv_initinfo() again. I don't think that is a good idea. >> >> The upsdrv_initinfo() function is meant for detecting the UPS type/ >> model >> and is basically the last time a driver can decide that it is >> unsuitable >> to monitor a UPS and bail out. After that (and running >> upsdrv_updateinfo() >> once), a socket for the 'upsd' server is created and from then on, >> it is >> expected that the driver socket will remain available as long as >> NUT is >> running. Which means that if you fail to (re)connect to the UPS, you >> should call dstate_datastale() and/or upslogx() instead of >> terminating the >> driver, no matter how many communication failures you might see >> (ever). >> What's wrong in the driver now, is that by running upsdrv_initinfo >> () again >> when reconnecting, you introduce the possibility that if there is a >> communications problem or the driver reads enough garbage >> characters to >> miss detecting it on the first try, it will bail out with fatalx(). >> Ouch! >> This problem is aggrevated by the fact that upsdrv_initinfo() never >> retries on failures. >> >> I don't think it is needed to run upsdrv_initinfo() when >> reconnecting in >> the first place. After all, the initialization ran before, so >> unless the >> user removed the UPS from the system, we can expect that it will >> eventually pop up again. So basically, you already have all the >> information that upsdrv_initinfo() provides. I wouldn't care for >> the edge >> cases where people swap models without stopping the driver. It >> wouldn't >> work in the current implementation of this driver anyway, since >> reconnecting to a different model (with possibly different variable >> set) >> would also require dstate_delinfo() all information that is no longer >> available. We do that in the 'usbhid-ups' driver, but this requires >> a lot >> of bookkeeping to prevent first deleting and then creating the same >> variable again. Not recommended. > > I don't claim to completely understand the reconnection code - I > believe Arnaud was pushing for it, and I modeled the tripplite_usb > reconnection code after whatever usbhid-ups (newhidups) was using at > the time (read: copied).I understand, it looks pretty familiar... :-)> The one bit of functionality that I would like to eventually have in > the driver is the case where several units with the same VID/PID are > connected, and we need to read the unit ID to distinguish between > them. (Unfortunately, it's not something that we could put into the > matcher.)If I understand correctly, this requires sending the UPS a command to read the ID. In that case, it *can't* be done (sadly enough). The only information you can read from a USB device without claiming it, is the stuff we use in the existing matchers. Everything else requires claiming a device first. But in the process this will remove the claim any other process may have. Since there is no way to tell which device will be tried first, this will lead to an endless mess of disconnect/connect attempts if two or more drivers are running. We tried this with the 'usbhid-ups' driver, but in practice you can only use this if you have only one UPS connected (in which case this is moot since there will be no confusion). The only thing that might solve the problem with devices with identical VID:PID, is adding the physical port in the matcher. As far as I know, this isn't possible with the existing libusb-0.1 library and not with the future libusb-1.0 library either.> Of course, that wouldn't preclude the removal of the fatalx() call.In order to keep things clear, it is probably best to only call fatalx() from the upsdrv_initups() and upsdrv_initinfo() functions and certainly not from helper functions.> So if I read this right, do you think that upsdrv_initinfo() *should* > retry, or should retrying be relegated to the reconnection code, > since it shouldn't call upsdrv_initinfo() on disconnection?Drivers must never call upsdrv_*() functions themselves, these should be reserved to the interface with the main driver body. It probably wouldn't hurt if upsdrv_initinfo() would retry, but keep the number of retries limited (three times). What we don't want is that the first failed attempt terminates the driver, but it should not retry forever (if the UPS is unavailable we want to know it when starting up). The reconnection code should indeed handle everything by itself (or through helper functions). Best regards, Arjen --
This worked! I noticed while running the driver in debug mode that some of the reconnects took up to 8 trys - this was over the original limit of 3 & the root of my problem. Now it is fixed! Charles, Chris, & Arjen -- Thank you so very much!!! On Thu, Aug 14, 2008 at 8:10 AM, Charles Lepple <clepple at gmail.com> wrote:> On Wed, Aug 13, 2008 at 11:09 PM, Jon Bougher <jonb88 at gmail.com> wrote: > > Should I be using th latest trunk tripplite_usb.c? > > Yes. > > > Does changing the, > > > > #define MAX_SEND_TRIES 3 > > > > line to: > > > > #define MAX_SEND_TRIES 10 > > > > and recompiling the driver do the trick? > > Yes. > > > Does the # cause the line to be > > commented out?? > > No. > > -- > - Charles Lepple >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20080815/8e2cad42/attachment.htm
On Fri, Aug 15, 2008 at 3:10 PM, Jon Bougher <jonb88 at gmail.com> wrote:> This worked! > > I noticed while running the driver in debug mode that some of the reconnects > took up to 8 trys - this was over the original limit of 3 & the root of my > problem. Now it is fixed!I changed the send retries to 10 in the SVN trunk. Anything above that is worth investigating further. -- - Charles Lepple