[Nut-upsdev] Problems with USB-serial converters -- please adviseon code fix

[simon-alioth at eazimail.com]

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