Re: [Nut-upsuser] NUT Quit Working [Tripp Lite; USB 3.0]

2014-09-07 Thread Leslie Rhorer

On 9/6/2014 4:34 PM, Charles Lepple wrote:

On Sep 6, 2014, at 4:16 PM, Leslie Rhorer lrho...@mygrande.net wrote:


Oh, hey!  That seems to have worked.  I'm sure the UPS got plugged into 
a different port one of the (many) times the server was removed from the relay 
rack, and it was on a USB 3.0 port.  I moved it to a 1.0 port and everything 
seems to be working just fine.


The specifics of the motherboard and its USB controller might be useful to 
know, then. If nothing else, I'm curious if this affects certain brands of USB 
3.0 controllers and/or their PHY components.


	It's an ASUS M5A99X EVO R2.0 motherboard with an AMD 4.0 GHz FX-8350 
eight core processor (not overclocked).  Details of the two root hubs 
are below.  It also has some USB 2.0 root hubs.  I would be happy to do 
some testing, if you like.  I have a couple of other brands of UPS I 
could plug into the system, if it would help.


The USB 3.0 Phy (upsdrvctl failed):

Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   3.00
  bDeviceClass9 Hub
  bDeviceSubClass 0 Unused
  bDeviceProtocol 3
  bMaxPacketSize0 9
  idVendor   0x1d6b Linux Foundation
  idProduct  0x0003 3.0 root hub
  bcdDevice3.02
  iManufacturer   3 Linux 3.2.0-4-amd64 xhci_hcd
  iProduct2 xHCI Host Controller
  iSerial 1 :04:00.0
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   31
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0
bmAttributes 0xe0
  Self Powered
  Remote Wakeup
MaxPower0mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass 9 Hub
  bInterfaceSubClass  0 Unused
  bInterfaceProtocol  0 Full speed (or root) hub
  iInterface  0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0004  1x 4 bytes
bInterval  12
bMaxBurst   0
Hub Descriptor:
  bLength  12
  bDescriptorType  42
  nNbrPorts 2
  wHubCharacteristic 0x000a
No power switching (usb 1.0)
Per-port overcurrent protection
  bPwrOn2PwrGood   10 * 2 milli seconds
  bHubContrCurrent  0 milli Ampere
  bHubDecLat  0.0 micro seconds
  wHubDelay 0 nano seconds
  DeviceRemovable0x00
 Hub Port Status:
   Port 1: .02a0 5Gbps power Rx.Detect
   Port 2: .02a0 5Gbps power Rx.Detect
Binary Object Store Descriptor:
  bLength 5
  bDescriptorType15
  wTotalLength   15
  bNumDeviceCaps  1
  SuperSpeed USB Device Capability:
bLength10
bDescriptorType16
bDevCapabilityType  3
bmAttributes 0x00
  Latency Tolerance Messages (LTM) Supported
wSpeedsSupported   0x0008
  Device can operate at SuperSpeed (5Gbps)
bFunctionalitySupport   3
  Lowest fully-functional device speed is SuperSpeed (5Gbps)
bU1DevExitLat   0 micro seconds
bU2DevExitLat   0 micro seconds
Device Status: 0x0001
  Self Powered

USB 1.1 Phy (upsdrvctl working):

Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   1.10
  bDeviceClass9 Hub
  bDeviceSubClass 0 Unused
  bDeviceProtocol 0 Full speed (or root) hub
  bMaxPacketSize064
  idVendor   0x1d6b Linux Foundation
  idProduct  0x0001 1.1 root hub
  bcdDevice3.02
  iManufacturer   3 Linux 3.2.0-4-amd64 ohci_hcd
  iProduct2 OHCI Host Controller
  iSerial 1 :00:12.0
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   25
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0
bmAttributes 0xe0
  Self Powered
  Remote Wakeup
MaxPower0mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass 9 Hub
  bInterfaceSubClass  0 Unused
  bInterfaceProtocol  0 

[Nut-upsuser] NUT Quit Working

2014-09-06 Thread Leslie Rhorer


Hello.

	I have had NUT working for several years on my servers.  Recently I 
made changes to the main server, where the UPS is local, and now upsd 
won't properly load there, which essentially disables the entire UPS 
shutdown system.  I made a number of hardware and software changes, 
including an upgrade to the latest software versions for that distro 
(Debian Wheezy), although I did not upgrade to a new distro, and I did 
not make any changes that should affect the UPS, unless NUT was one of 
the packages automatically upgraded.  No changes were made to the UPS 
hardware or the NUT configuration files.  When upsdrvctl runs, I get the 
following:


RAID-Server:/RAID/Server-Main/Equipment/HighPoint Adapters# upsdrvctl start
Network UPS Tools - UPS driver controller 2.6.4
Network UPS Tools - Tripp Lite OMNIVS / SMARTPRO driver 0.20 (2.6.4)
Warning: This is an experimental driver.
Some features may not function correctly.

Detected a UPS: unknown/unknown
libusb_set_report() returned 0 instead of 8
Error reading protocol
Driver failed to start (exit status=1)


lsusb reports:

Bus 007 Device 002: ID 09ae:0001 Tripp Lite
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   1.10
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize0 8
  idVendor   0x09ae Tripp Lite
  idProduct  0x0001
  bcdDevice0.01
  iManufacturer   1
  iProduct2
  iSerial 0
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   34
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0
bmAttributes 0x80
  (Bus Powered)
MaxPower   60mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass 3 Human Interface Device
  bInterfaceSubClass  1 Boot Interface Subclass
  bInterfaceProtocol  0 None
  iInterface  0
HID Device Descriptor:
  bLength 9
  bDescriptorType33
  bcdHID   1.00
  bCountryCode0 Not supported
  bNumDescriptors 1
  bDescriptorType34 Report
  wDescriptorLength  52
  Warning: incomplete report descriptor
  Report Descriptor: (length is 7)
Item(Main  ): (null), data= [ 0x80 ] 128
Item(reserved): (null), data= [ 0xfb ] 251
Item(Main  ): (null), data=none
Item(Main  ): (null), data=none
Item(Main  ): (null), data=none
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0008  1x 8 bytes
bInterval  10
Device Status: 0x80b0
  (Bus Powered)

Where do I go from here?

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser


Re: [Nut-upsuser] NUT Quit Working

2014-09-06 Thread Charles Lepple
On Sep 6, 2014, at 12:39 PM, Leslie Rhorer lrho...@mygrande.net wrote:

 I made a number of hardware and software changes, including an upgrade to the 
 latest software versions for that distro (Debian Wheezy),

Can you be more specific about the changes?

Key variables:

* USB controller information (old and new hardware)
* Kernel versions, for both working and non-working setups

You might also want to try finding an older USB hub to put between the UPS and 
the motherboard. I wouldn't recommend this for production use, but it can be 
useful to isolate the problem. We have had a few reports of issues along these 
lines, but with no resolution (or at least, nobody has confirmed on the lists).

-- 
Charles Lepple
clepple@gmail




___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser


Re: [Nut-upsuser] NUT Quit Working

2014-09-06 Thread Leslie Rhorer

On 9/6/2014 12:47 PM, Charles Lepple wrote:

On Sep 6, 2014, at 12:39 PM, Leslie Rhorer lrho...@mygrande.net wrote:


I made a number of hardware and software changes, including an upgrade to the 
latest software versions for that distro (Debian Wheezy),


Can you be more specific about the changes?


	Well, I did an automated upgrade (apt-get upgrade), I changed to a 
multi-lane drive controller and RAID chassis, rather than using an eSATA 
port with a Port Multiplier chassis.




Key variables:

* USB controller information (old and new hardware)


	No changes.  The UPS is plugged into one of the rear USB ports on the 
motherboard, which was not changed.



* Kernel versions, for both working and non-working setups


	Well, I'm not absolutely certain, but I don't think the kernel was 
upgraded by the automatic process.  The current kernel version is 
3.2.0-4-amd64.  I am going to take the server down for further 
maintenance in a few hours, and I have a hard drive with Debian Jessie 
on it.  I can try booting from that to see if it makes a difference.



You might also want to try finding an older USB hub to put between the UPS and 
the motherboard. I wouldn't recommend this for production use, but it can be 
useful to isolate the problem. We have had a few reports of issues along these 
lines, but with no resolution (or at least, nobody has confirmed on the lists).


	I don't have one lying around.  Motherboards the last few years have 
been loaded with lots of USB ports, so I haven't had any need for a hub. 
 Note as I mentioned above, the motherboard has not changed.  I can 
surely try a different port...


	Oh, hey!  That seems to have worked.  I'm sure the UPS got plugged into 
a different port one of the (many) times the server was removed from the 
relay rack, and it was on a USB 3.0 port.  I moved it to a 1.0 port and 
everything seems to be working just fine.




___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser


Re: [Nut-upsuser] NUT Quit Working [Tripp Lite; USB 3.0]

2014-09-06 Thread Charles Lepple
On Sep 6, 2014, at 4:16 PM, Leslie Rhorer lrho...@mygrande.net wrote:

   Oh, hey!  That seems to have worked.  I'm sure the UPS got plugged into 
 a different port one of the (many) times the server was removed from the 
 relay rack, and it was on a USB 3.0 port.  I moved it to a 1.0 port and 
 everything seems to be working just fine.

The specifics of the motherboard and its USB controller might be useful to 
know, then. If nothing else, I'm curious if this affects certain brands of USB 
3.0 controllers and/or their PHY components.

-- 
Charles Lepple
clepple@gmail




___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser