similar to: Tripp-Lite AVR-900U

Hi all, As requested by upsdrvctl, I'm reporting on my results connecting a Tripp Lite UPS (G1010USB). This server is running on Ubuntu Lucid, nut version is 2.4.3-1ubuntu3.1. With ups.conf: [ups] driver = usbhid-ups port = auto Results: # upsdrvctl start Network UPS Tools - UPS driver controller 2.4.3 Network UPS Tools - Generic HID driver 0.34 (2.4.3) USB communication driver 0.31

Hi, I'm running the latest stable nut (2.4.3). It doesn't appear to provide support for the Tripp Lite SmartOnline SU1000XLA. [sups] driver = usbhid-ups port = auto vendorid = 09ae productid = 4004 4337# upsdrvctl start Network UPS Tools - UPS driver controller 2.4.3 Network UPS Tools - Generic HID driver 0.34 (2.4.3) USB communication driver 0.31 Using subdriver:

Hi, I kludged support for the TrippLite SU2200XLA into nut-2.4.3 as follows: --- ./drivers/tripplite-hid.c.0 2010-03-03 15:53:20.000000000 -0500 +++ ./drivers/tripplite-hid.c 2010-03-03 15:53:40.000000000 -0500 @@ -81,6 +81,8 @@ { USB_DEVICE(TRIPPLITE_VENDORID, 0x4002), battery_scale_1dot0 }, /* e.g. TrippLite SmartOnline SU1500RTXL2ua */ {

Trying to get a Tripp-Lite to work with nut--Ubuntu 10.10. I was getting the error message "unable to claim USB device", tried to unbind the drivers to that device, and had the following delightful experience. In short, continue to get the same problem, and the drivers bound themselves back. Any suggestions? ----------- usb.conf has the following: [Tripp-Lite] driver = usbhid-ups port

I have the following UPS that I'm trying to get to work with NUT: SU3000RTXL3U I have it connected via USB. My ups.conf looks like: [test] driver = usbhid-ups vendorid = 09ae port = auto When I run upsdrvctl -DD start, I get: Network UPS Tools - UPS driver controller 2.4.1 Starting UPS: test exec: /lib/nut/usbhid-ups -a test Network UPS Tools - Generic HID driver 0.34 (2.4.1)

I was getting: "Can't claim USB device [0764:0501]: could not detach kernel driver from interface 0: Operation not permitted" so I manually installed the udev rules the source (I installed the Gentoo ebuild). I am now getting: # upsdrvctl start Network UPS Tools - UPS driver controller 2.4.3 Network UPS Tools - Generic HID driver 0.34 (2.4.3) USB communication driver 0.31 Using

Device manufacturer and name: Tripp-Lite OmniSmart500 upsc output: matt at backup:/etc$ sudo upsc tripplite battery.charge: 100 battery.test.status: Battery OK battery.voltage: 14.56 battery.voltage.nominal: 12 device.mfr: Tripp Lite device.model: OMNISMART500 device.type: ups driver.name: tripplite_usb driver.parameter.pollinterval: 2 driver.parameter.port: auto driver.version: 2.4.3

I'm trying to set up a single host to monitor the state of several UPS in my data center. I have a mix of several APC and Tripp-Lite in production. The former are great, the latter are not so much. With the APCs (using usbhid-ups), I can set up configs for each based on the value they report from ups.serial. With the Tripp-Lites (using tripplite_usb), there is no value returned for

I am experiencing the same kind of disconnects, stale data on Eaton brand UPS (Nova AVR). It keeps doing it probably due to Windows to detect it as a new hardware, until Eaton software is installed. With Eaton Linux IPP http://pqsoftware.eaton.com/explore/eng/ipp/default.htm?lang=en this does not happen. Think what? It disables it somehow. But as soon as you remove this proprietary driver, its

I have been working on supporting the TrippLite Internet350SER (serial connection only using communication protocol 1004) in nuts.2.4.1. I sent a patch around 2009/11/9. I just look at the 2.4.3 release and the support for this model does not look to be added in either tripplite driver. Can I help to add support in the project? -- Pat This electronic message may contain proprietary and

Charles, So I installed a minimal CentOS 6.5 installation on the Fedora box this morning and I got the same issue. Below are the kernel versions used. CentOS 6.5 Minimal - [root at nemo tmp]# uname -a Linux nemo 2.6.32-431.el6.x86_64 #1 SMP Fri Nov 22 03:15:09 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux [root at nemo tmp]# rpm -qa | grep nut nut-2.6.5-2.el6.x86_64 nut-client-2.6.5-2.el6.x86_64

Soon as I get back to that computer I will let you know which kernel version. Both were just recently installed, Fedora was installed specifically for this actually, though updates have been applied. I've tried it with other USB ports already across 5 different machines. I've also swapped out the USB cable for another one that I knew worked fine. I'll see what I can do about

Am 04.03.20 um 11:16 schrieb Dylan McKay: > > The new are of xmega3 architecture, which is already included. So this > should be simple. > > Where is the information about ISR-vector table, SRAM addresses and so > on stored? > > > At the moment, this is not implemented in LLVM; these details are left > to the frontend. Clang/compiler-rt does not

To those interested in AVR backend additions to LLVM, the LLVM review tools "Phabricator" ( don't ask me to say that 3 times fast ), allows easy searching. Go to http://reviews.llvm.org/ and type in AVR in the search entry. This will give you a list of the commits, and resolutions. From my understanding ( NO Expert ), a large part of the skeleton code has been added. The leave

Hello, 1) On OpenIndiana 151, I configured nut 2.6.1 as configure --prefix=/opt/nut/2.6.1 --with-cgi --with-hal --with-user=ups --with-group=nut CC=cc The result is -e Configuration summary: ====================== build serial drivers: yes build USB drivers: yes build SNMP drivers: yes build neon based XML driver: yes build Powerman PDU client driver: no enable SSL development code: yes

Am 04.03.20 um 13:28 schrieb Dylan McKay: > > * *The C/C++ function needs to be declared with either the calling > convention avr-interrupt or avr-non-blocking-interrupt.* Skipping > this step will cause regular ret instructions to be emitted for > return-from-subroutine, instead of the required reti for interrupt > handlers. ISRs also have stricter

> > Should we just make it a normal target? > My only remaining reservation here - the generic DebugInfo tests, which presumably due to an unimplemented 16-bit branch somewhere deep in the llvm-objdump callstack. The AVR backend passes virtually all of the LLVM test suite but these when avr-unknown-unknown is set as the default target. It feels like the inclusion of ~80 XFAILs for these

Thanks! The new are of xmega3 architecture, which is already included. So this should be simple. Where is the information about ISR-vector table, SRAM addresses and so on stored? -- Wilhelm Am 04.03.20 um 11:03 schrieb Dylan McKay: > Hey Wilhelm, > > This should be possible by editing the 'AVRDevices.td' [1]TableGen > definitions to add an entry for the newer chip types.

Hi Dylan, the following code volatile uint8_t v1; volatile uint8_t v2; __attribute__((interrupt)) void __vector_21(void) { v2 = v1; } produces in C mode: 00000092 <__vector_21>: 92: 80 91 61 00 lds r24, 0x0061 ; 0x800061 <v1> 96: 80 93 60 00 sts 0x0060, r24 ; 0x800060 <__data_end> 9a: 08 95 ret and in C++ mode: 00000074

I think this is broken in at least one place when legalising the DAG. This llvm ir: %3 = call { i16, i1 } @llvm.umul.with.overflow.i16(i16 %2, i16 11) Fails to lower correctly on AVR but the problem is, unfortunately, not just coming from the AVR Target code and I am not sure it can be cleanly fixed just there. (But I would be very happy to be proved wrong as I'm very new to this.) The above