USB changing port from ttyUSB0 to ttyUSB1
Gregory Berardi
5.19.0-1. The weather station I have is a Davis Vantage Pro2. The
system seems to run fine for days and then the USB port will change
from the original /dev/ttyUSB0 to /dev/ttyUSB1. Here is the output
from dmesg showing the usb port information.
[ 0.533531] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[ 0.533573] ehci_hcd 0000:00:1d.7: PCI INT D -> GSI 23 (level, low) -> IRQ 23
[ 0.533597] ehci_hcd 0000:00:1d.7: setting latency timer to 64
[ 0.533602] ehci_hcd 0000:00:1d.7: EHCI Host Controller
[ 0.533660] ehci_hcd 0000:00:1d.7: new USB bus registered, assigned
bus number 1
[ 0.533702] ehci_hcd 0000:00:1d.7: debug port 1
[ 0.537595] ehci_hcd 0000:00:1d.7: cache line size of 64 is not supported
[ 0.537947] ehci_hcd 0000:00:1d.7: irq 23, io mem 0xf8500000
[ 0.560335] ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00
[ 0.560581] hub 1-0:1.0: USB hub found
[ 0.560589] hub 1-0:1.0: 8 ports detected
[ 0.560709] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[ 0.560734] uhci_hcd: USB Universal Host Controller Interface driver
[ 0.560807] uhci_hcd 0000:00:1d.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[ 0.560819] uhci_hcd 0000:00:1d.0: setting latency timer to 64
[ 0.560824] uhci_hcd 0000:00:1d.0: UHCI Host Controller
[ 0.560893] uhci_hcd 0000:00:1d.0: new USB bus registered, assigned
bus number 2
[ 0.560938] uhci_hcd 0000:00:1d.0: irq 16, io base 0x00001440
[ 0.561121] hub 2-0:1.0: USB hub found
[ 0.561128] hub 2-0:1.0: 2 ports detected
[ 0.561227] uhci_hcd 0000:00:1d.1: PCI INT B -> GSI 19 (level, low) -> IRQ 19
[ 0.561237] uhci_hcd 0000:00:1d.1: setting latency timer to 64
[ 0.561243] uhci_hcd 0000:00:1d.1: UHCI Host Controller
[ 0.561305] uhci_hcd 0000:00:1d.1: new USB bus registered, assigned
bus number 3
[ 0.561341] uhci_hcd 0000:00:1d.1: irq 19, io base 0x00001460
[ 0.561524] hub 3-0:1.0: USB hub found
[ 0.561531] hub 3-0:1.0: 2 ports detected
[ 0.561610] uhci_hcd 0000:00:1d.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18
[ 0.561620] uhci_hcd 0000:00:1d.2: setting latency timer to 64
[ 0.561624] uhci_hcd 0000:00:1d.2: UHCI Host Controller
[ 0.561694] uhci_hcd 0000:00:1d.2: new USB bus registered, assigned
bus number 4
[ 0.561721] uhci_hcd 0000:00:1d.2: irq 18, io base 0x00001480
[ 0.561893] hub 4-0:1.0: USB hub found
[ 0.561900] hub 4-0:1.0: 2 ports detected
[ 1.384050] usb 3-2: new full speed USB device using uhci_hcd and address 2
[ 15.106771] lp0: using parport0 (interrupt-driven).
[ 15.352633] usbcore: registered new interface driver usbserial
[ 15.352691] USB Serial support registered for generic
[ 15.352769] usbcore: registered new interface driver usbserial_generic
[ 15.352773] usbserial: USB Serial Driver core
[ 15.399265] USB Serial support registered for cp210x
[ 15.399310] cp210x 3-2:1.0: cp210x converter detected
[ 15.798459] usb 3-2: reset full speed USB device using uhci_hcd and address 2
[ 15.847979] ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 15.976228] usb 3-2: cp210x converter now attached to ttyUSB0
[ 15.976255] usbcore: registered new interface driver cp210x
[ 15.976259] cp210x: v0.09:Silicon Labs CP210x RS232 serial adaptor driver
[727060.528042] hub 3-0:1.0: port 2 disabled by hub (EMI?), re-enabling...
[727060.528111] usb 3-2: USB disconnect, address 2
[727060.528310] cp210x ttyUSB0: cp210x converter now disconnected from ttyUSB0
[727060.528325] cp210x 3-2:1.0: device disconnected
[727060.768025] usb 3-2: new full speed USB device using uhci_hcd and address 3
[727060.938838] cp210x 3-2:1.0: cp210x converter detected
[727061.048019] usb 3-2: reset full speed USB device using uhci_hcd
and address 3
[727061.195860] usb 3-2: cp210x converter now attached to ttyUSB1
***************************************************************************************************
I disconnected the weather station and then reconnected
[819185.832042] usb 3-2: USB disconnect, address 3
[819185.832219] cp210x ttyUSB1: cp210x converter now disconnected from ttyUSB1
[819185.832241] cp210x 3-2:1.0: device disconnected
[819214.676016] usb 3-2: new full speed USB device using uhci_hcd and address 4
[819214.847258] cp210x 3-2:1.0: cp210x converter detected
[819214.956026] usb 3-2: reset full speed USB device using uhci_hcd
and address 4
[819215.104087] usb 3-2: cp210x converter now attached to ttyUSB0
Then I restarted wviewd and everything works.
***************************************************************************************************
Here is the output from lsusb
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 004: ID 10c4:ea61 Cygnal Integrated Products, Inc.
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
***************************************************************************************************
output from vpconfig
vpconfig /dev/ttyUSB0 show
Firmware Version: Nov 2 2007
Station Location: 41.3 N, 91.3 W, 760 feet
Archive Interval: 5 minutes
Rain Season Start Month: 1
Wind direction calibration: 0 degrees
Listening on channel: 5 for ISS
Retransmit channel: 7
Rain collector size: 0.01 in
Wind cup size: large
RX Check Stats: 1969 1033 2 212 1
recvd:missed:resyncs:good-pkts-in-a-row:CRC errors
***************************************************************************************************
The computer is an HP Workstation XW4100 with a Pentium 4 2.4GHz
Any ideas on how I can fix this?
Thank you
pterodaktil
I fix it with making alias for /dev/ttyUSB* to /dev/davis
I have documentation only in russian. so i think you google it.
and make script to resatrt wview then ther are probblems with replug
usb.
it's not butiful but it's work
#! /bin/bash
tail -n 50 /var/log/messages | grep wakeupConsole >> /dev/null
if [ "$?" = "0" ]; then
echo Connection to station fail, restarting wview `date` $* | tee -a /
var/log/w$
/etc/init.d/wview stop
sleep 15
/etc/init.d/wview start
else
exit
fi
Michael
locking down the USB port
http://groups.google.com/group/wview/browse_thread/thread/c2213f94704f37b6?fwc=2
On Jul 12, 12:05 pm, Gregory Berardi <berardi.greg...@gmail.com>
wrote:
Chris
tty?
For example I am using a serial attached station via a Proflic Serial
to USB adapter and this can be found as:
/dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controler-
if00-port0
This will never change! I guess you could also create a symbolic link
from /dev/weather_station to /dev/serial/by-id/<whatever your device
gets called here> also.
Cheers
Chris
gberar
there but I have decided to implemented the one here
http://groups.google.com/group/wview/browse_thread/thread/c2213f94704f37b6?fwc=2
You ought to try it as it seems to work well.
gberar
That is exactly what I was looking for and thanks for pointing it out
to me. I have implemented it but time will tell if it works.
Thank you for your help.
> Check out this post and maybe search for others on the subject of
> locking down the USB port
>
gberar
I used the udev rules as suggested by Michael.
Thanks for the help.
Dan
Dan
Jonathan Ryshpan
> Just installed 5.20.2 and am running into a related problem with
> ttyUSB resetting itself. I went through the udev steps to set up a
> link (/dev/davis) per the instructions in this thread and have wview
> set up to use at /dev/davis. Upon boot it links to /dev/ttyUSB0.
> However at some point or another the machine will eventually reassign
> my weather station to ttyUSB1. Fortunately, /dev/davis also changes to
> point to ttyUSB1. However, wview still hiccups and I get errors such
> as the following in my /var/log/wview.log file:
> wviewd:vproErrorState: received stimulus 5
>
> I was hoping pointing wview to /dev/davis would be sufficient but
> something is still awry. Any idea what I might have done wrong or
> anything else I can try?
is that to cure the problem the wview server will have to be rewritten
to recognize when there is a loss of service from the Davis console and
when this happens close and reopen the port, which will (of course) have
to be pointed to a fixed location as you have done.
I've been meaning to do some work on this but have been too lazy to do so.
Here's a summary of the discussion:
------------------------------
From: Jonathan Ryshpan <jon...@pacbell.net>
To: Fedora List <us...@lists.fedoraproject.org>
Subject: /dev/ttyUSB0 spontaneously changes to /dev/ttyUSB1
Date: Tue, 05 Jun 2012 14:10:23 -0700
This is a problem which is being kicked around on another mailing list,
devoted to the wview weather server, without very good results, so I
have taken the liberty of putting it to a wider audience:
I have a system with a device (a Davis VantagePro2 weather console)
attached to a USB port. When the system starts, the device is visible
as /dev/ttyUSB0. A wview server attaches to /dev/ttyUSB0 and runs fine
till suddenly the device disappears from /dev/ttyUSB0 and appears
as /dev/ttyUSB1, at which time the server fails.
I suspect (though without much evidence) that the reason for the device
moving around is that there is a brief interruption of service from the
device, so that it appears to the computer that a *new* device has
appeared, which it has to find a device name for before it had deleted
the old name of the device.
I have tried the obvious, to open what ought to be the permanent
location of the device, namely:
/dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0
But the software stops working when the change takes place, evidently
because
/dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0
is a dynamically updated symbolic link to /dev/ttyUSB0 or /dev/ttyUSB1,
as the case may be. The server can only be made to work again by
restarting it.
Does anyone know of a way to keep the USB device open at a known
location, maybe by creating a permanent entry in /dev, and bypassing
udev? Any more theories about what, in general, is happening?
------------------------------
From: Sam Varshavchik <mr...@courier-mta.com>
Jonathan Ryshpan writes:
<...>
That strongly suggests that, even if the device reconnects under the same
name, your software app will still choke. If your app still chokes if it's
told to open /dev/serial/by-id, then it's going to have a problem when your
USB device disconnects and reconnects, even if it keeps the same /dev/ttyUSB?
name. You've just proven this yourself: by pointing your software to open
/dev/serial/by-id. After all, the device name now, as far as your software
is concerned, remains the same. The fact that the underlying symlink changes
is irrelevant; unless your software manually checks if it is opening a
symlink, then reads it and proceeds to use the real path. This seems very
unlikely.
So, your real problem is that your software is unable to handle the device
disconnecting and reconnecting. The different device name is a red herring.
Either the software needs to get fixed, so at least it can recover by
reopening the device (and you pointing it to the unchanged /dev/serial/by-id
path), or the underlying root cause of your USB device disconnect must be
identified, and fixed.
------------------------------
From: Tom Horsley <horsl...@gmail.com>
On Tue, 05 Jun 2012 19:22:50 -0400
Sam Varshavchik wrote:
> Either the software needs to get fixed, so at least it can recover by
> reopening the device
Libudev might help with this, and what the heck, it would probably
be nice if the software could handle a user yanking out the device
as well (which would look much the same).
------------------------------
From: Chris Adams <cma...@hiwaay.net>
Once upon a time, Jonathan Ryshpan <jon...@pacbell.net> said:
<...>
I've had this happen on occasion (not often) with a GPS receiver used
for NTP. The reason the reconnected USB device gets a different
node/name is that your service is still connected to the old device
node, so it can't be reused.
Your service should notice that the serial device went away and exit.
I'm not sure if there's a way to have udev run a script or send a signal
when a device goes away.
------------------------------
From: Alan Cox <al...@lxorguk.ukuu.org.uk>
Jonathan Ryshpan wrote:
> as /dev/ttyUSB0. A wview server attaches to /dev/ttyUSB0 and runs fine
> till suddenly the device disappears from /dev/ttyUSB0 and appears
> as /dev/ttyUSB1, at which time the server fails.
You need to fix the server.
Jonathan Ryshpan wrote:
> I suspect (though without much evidence) that the reason for the device
> moving around is that there is a brief interruption of service from the
> device, so that it appears to the computer that a *new* device has
> appeared, which it has to find a device name for before it had deleted
> the old name of the device.
That sounds likely - dmesg will probably tell you.
Jonathan Ryshpan wrote:
> Does anyone know of a way to keep the USB device open at a known
> location, maybe by creating a permanent entry in /dev, and bypassing
> udev? Any more theories about what, in general, is happening?
Even if you overwrote the old device node the server needs to re-open the
file handle. Given the server will get notification that the port has
failed (eg a SIGHUP or going ready for read and getting an error on the
read) it shouldn't be too hard to fix it.
Graham Eddy
Try adding a restart of wview to udev rules
_______________
Graham Eddy
--
You received this message because you are subscribed to the Google Groups "wview" group.
To view this discussion on the web visit https://groups.google.com/d/msg/wview/-/x5j86ixy-zcJ.
To post to this group, send email to wv...@googlegroups.com.
To unsubscribe from this group, send email to wview+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/wview?hl=en.
Warren Gill
reload) # Restart wview only if it was already running
if pidof $WVIEWD_FILE
then
$0 stop && sleep 2
$0 start
fi
;;
And then set up a udev rule to run /etc/init.d/wview reload