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

[Charles Lepple]

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