Nut upsdev - May 2013 - Problems with USB-serial converters -- please advise on code fix

Hello!

I've ran into this annoying issue when setting up a new server. I have an
APC
SmartUPS hooked up on a USB-serial converter on /dev/ttyUSB0.

This works nicely, until:

hub 3-0:1.0: port 1 disabled by hub (EMI?), re-enabling... 
pl2303 ttyUSB0: pl2303 converter now disconnected from ttyUSB0
usb 3-1: pl2303 converter now attached to ttyUSB1

apcsmart gets into an infinite loop of this:
apcsmart[2285]: smartmode: issuing 'Y' failed: Input/output error

while upsd becomes unhappy:
upsd[2311]: Data for UPS [apc] is stale - check driver (because now it can't
talk to the UPS)

After this, a shutdown usually follows, though my understanding is that this 
should only happen on battery power.

This is very easy to reproduce, just use an USB-serial converter, and pull it 
out of the port.


I've been looking into fixing that and would like some advice on how to 
proceed.

I tried the easiest fix possible: abort on EIO and hope I can get systemd to 
restart the driver. That so far hasn't worked, it results in a series of
very
fast restarts, and systemd giving up shortly.

So I'm going to try to make the driver reconnect on EIO. So far I have made
an
attempt, but it still quits somewhere. It also seems some changes might be 
necessary to the driver API to get this done.

So I'd like some advice first:

Is there any work on this planned already?

Do you have any preferences regarding how this should work? Eg, retry 
connection only after connection has been established? Add a configuration 
parameter to enable this mode?

How should I approach changing the driver API? For instance it seems like a 
upsdrv_initups argument to ensure it won't quit on failure may be needed.

What about other UPS models? This would imply changes in main.c, and affect 
other models, but I can only test my APC SmartUPS. Also this problem probably 
applies to USB UPSes.


Thanks!

On May 7, 2013, at 7:09 PM, Vadim wrote:
> Hello!
> 
> I've ran into this annoying issue when setting up a new server. I have
an APC
> SmartUPS hooked up on a USB-serial converter on /dev/ttyUSB0.
> 
> This works nicely, until:
> 
> hub 3-0:1.0: port 1 disabled by hub (EMI?), re-enabling... 
> pl2303 ttyUSB0: pl2303 converter now disconnected from ttyUSB0
> usb 3-1: pl2303 converter now attached to ttyUSB1
Assuming this is Linux, you may want to look into creating a symlink for that
USB-to-serial adapter, such that the driver can reconnect to the same name. What
appears to be happening is that the ttyUSB0 node is still open after
disconnection, so udev/kernel decides to create a ttyUSB1 node.

Does your USB-to-serial converter have a unique serial number? That is probably
the best way to match in order to create the symlink. If not, you could match on
the model or bus number, but that is more brittle.
> apcsmart gets into an infinite loop of this:
> apcsmart[2285]: smartmode: issuing 'Y' failed: Input/output error
> 
> while upsd becomes unhappy:
> upsd[2311]: Data for UPS [apc] is stale - check driver (because now it
can't
> talk to the UPS)
> 
> After this, a shutdown usually follows, though my understanding is that
this
> should only happen on battery power.
Agreed, stale data when on line power should not trigger a shutdown. Starting
the driver directly with a few "-D" flags might reveal whether the
apcsmart driver is not handling the error condition correctly.

Which version of the apcsmart driver (and NUT, for completeness) are you
running?
> This is very easy to reproduce, just use an USB-serial converter, and pull
it
> out of the port.
> 
> 
> I've been looking into fixing that and would like some advice on how to
> proceed.
> 
> I tried the easiest fix possible: abort on EIO and hope I can get systemd
to
> restart the driver. That so far hasn't worked, it results in a series
of very
> fast restarts, and systemd giving up shortly.
I wonder if this is related to the /dev node name change mentioned above?
> So I'm going to try to make the driver reconnect on EIO. So far I have
made an
> attempt, but it still quits somewhere. It also seems some changes might be 
> necessary to the driver API to get this done.
> 
> So I'd like some advice first:
> 
> Is there any work on this planned already?
Not to my knowledge. One proposed driver tried to poll the USB subsystem for
information about a USB-to-serial driver, but it was very Linux-specific, and
probably would need a lot of tweaking to generalize it. I'll try to remember
to look that up later.
> Do you have any preferences regarding how this should work? Eg, retry 
> connection only after connection has been established?
Yes, this is what the USB HID drivers do.

There is a possibility that the retry parameters might need tuning down the
road, but I'd keep the first implementation simple.

-- 
Charles Lepple
clepple at gmail

Hi Vadim,

Have you tried using a UDEV rule (/etc/udev/rules.d) to create a persistent
state for the port? What I would do is add a persistent rule for the serial
converter so that it either has a persistent device name, or a persistent
syslink (e.g. "ups0" could be a symlink to /dev/ttyUSBx).

What you need to find is a unique device attribute:

General info:
	udevadm info -a -n /dev/ttyUSBx | less

Find the idVendor and idProduct:
	udevadm info -a -n /dev/ttyUSBx | grep "{id" | head -n2

(the interesting identifiers 0403/6001 for the pl2303 on my system)


See if there is a unique serial number:
	udevadm info -a -n /dev/ttyUSBx | grep "{serial" | head -n1



Then create a udev rule (create the file
/etc/udev/rules.d/70-persistent-serial.rules and insert one of the
following): 

# Either as a symlink e.g. /dev/ups0 links to /dev/ttyUSBx (my preferred
method)
SUBSYSTEM="tty", ATTRS{idVendor}=="0403",
ATTRS{idProduct}=="6001",
ATTRS{serial}=="FTF0XG5N", SYMLINK+="ups0" 

# Or, a persistent device name e.g. /dev/ttyUSB0:
SUBSYSTEM="tty", ATTRS{idVendor}=="0403",
ATTRS{idProduct}=="6001",
ATTRS{serial}=="FTF0XG5N", NAME="ttyUSB0" 

For multiple devices you may have to pick another attribute to uniquely
identify each device.

Once the rule is created all you do is remove and re-insert the converter,
it should then appear with the same name.

This will not prevent the USB controller restarting but it will make sure
that the device name remains constant.


Hope this helps.

Simon

-----Original Message-----
From: nut-upsdev-bounces+simon-alioth=eazimail.com at lists.alioth.debian.org
[mailto:nut-upsdev-bounces+simon-alioth=eazimail.com at lists.alioth.debian.org
] On Behalf Of Vadim
Sent: Wednesday, May 08, 2013 01:10
To: nut-upsdev at lists.alioth.debian.or
Subject: [Nut-upsdev] Problems with USB-serial converters -- please adviseon
code fix

Hello!

I've ran into this annoying issue when setting up a new server. I have an
APC SmartUPS hooked up on a USB-serial converter on /dev/ttyUSB0.

This works nicely, until:

hub 3-0:1.0: port 1 disabled by hub (EMI?), re-enabling... 
pl2303 ttyUSB0: pl2303 converter now disconnected from ttyUSB0 usb 3-1:
pl2303 converter now attached to ttyUSB1

apcsmart gets into an infinite loop of this:
apcsmart[2285]: smartmode: issuing 'Y' failed: Input/output error

while upsd becomes unhappy
upsd[2311]: Data for UPS [apc] is stale - check driver (because now it can't
talk to the UPS)

After this, a shutdown usually follows, though my understanding is that this
should only happen on battery power.

This is very easy to reproduce, just use an USB-serial converter, and pull
it out of the port.


I've been looking into fixing that and would like some advice on how to 
proceed.

I tried the easiest fix possible: abort on EIO and hope I can get systemd to

restart the driver. That so far hasn't worked, it results in a series of
very 
fast restarts, and systemd giving up shortly.

So I'm going to try to make the driver reconnect on EIO. So far I have made
an 
attempt, but it still quits somewhere. It also seems some changes might be 
necessary to the driver API to get this done.

So I'd like some advice first:

Is there any work on this planned already?

Do you have any preferences regarding how this should work? Eg, retry 
connection only after connection has been established? Add a configuration 
parameter to enable this mode?

How should I approach changing the driver API? For instance it seems like a 
upsdrv_initups argument to ensure it won't quit on failure may be needed.

What about other UPS models? This would imply changes in main.c, and affect 
other models, but I can only test my APC SmartUPS. Also this problem
probably 
applies to USB UPSes.


Thanks!




_______________________________________________
Nut-upsdev mailing list
Nut-upsdev at lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev