Python Serial Script running nohup ending

[sys_spud]

This is probably more of a linux question but don't know where to start, so might as well start here.

I have mightyohm's Asus WL-520GU hack installed, have OpenWRT up and running, successfully using mpd, all of that is happy.

For a project I'm doing, I wanted to use python to parse RSS feeds out to a display and periodically refresh the display with new information.

I followed the instructions on the Buck Up Chinny Blog http://lizard43.blogspot.com/2009/03/tw ... -xbee.html and got python, pyserial and feedparser (to help with the RSS parsing) installed on a USB stick under an /opt directory. Had a few glitches but that seems to be working.

What I want to do is refresh the parsed RSS feed to the display every 20 seconds or so out to an arduino through the USB (FTDI) serial on the arduino. Note: this is not going through the added serial header as mightyohm has detailed, but through the USB connector on the arduino. I had to install the kmod-usb-ftdi pkg to do this.
I have a script that I start up like so from a command line:

Code: Select all

nohup wunderground.py &

so that this will run in the background without hangup. So far, I'm starting this manually and it works. For a while.

After about 8 hours, logread reports that the script ends. After that, I get I/O errors on the USB stick and can't remount it. I have to reboot to be able to mount and start over again.

Anyone have a guess as to what's happening? Does nohup just time out, or does the USB stick need to be repolled somehow (it looks like it's faking scsi)?
Should I try running this as an /etc/rc.d script?

Any suggestions on resolution or areas of research gratefully accepted.

TIA

[mightyohm]

I don't think starting the process at boot is going to solve the problem.

Do you see anything interesting in the dmesg output when the USB stick starts having problems?

What filesystem type and size of USB stick are you using?

[sys_spud]

Do you see anything interesting in the dmesg output when the USB stick starts having problems?

Here's the output of dmesg. Since I'm new at this, I have a hard time deciphering what it's trying to tell me:

Code: Select all

usb-ohci.c: OHCI Unrecoverable Error, controller usb-00:03.0 disabled
ftdi_sio.c: error from flowcontrol urb
ftdi_sio.c: Error from DTR LOW urb
ftdi_sio.c: Error from RTS LOW urb
ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity
ftdi_sio.c: ftdi_set_termios urb failed to set baurdrate
ftdi_sio.c: urb failed to clear flow control
ftdi_sio.c: ftdi_open Error from DTR HIGH urb
ftdi_sio.c: ftdi_open Error from RTS HIGH urb
ftdi_sio.c: ftdi_open - failed submitting read urb, error -143
usbserial.c: __serial_close - port 0: not open
SCSI disk error : host 0 channel 0 id 0 lun 0 return code = 70000
 I/O error: dev 08:01, sector 2625808
SCSI disk error : host 0 channel 0 id 0 lun 0 return code = 70000
 I/O error: dev 08:01, sector 2625816

with the SCSI disk errors repeated on increasing sectors

What filesystem type and size of USB stick are you using?

It's a cheap-o A-Data 4GB stick (woo-hoo, $7.99 @ Fry's!). I have it formatted EXT3.

[mightyohm]

Those FTDI errors - do they show up at the time of the crash or before? I wonder if the USB bus is crashing for some reason and taking out both the USB-serial and the flash drive?

[sys_spud]

Those FTDI errors - do they show up at the time of the crash or before? I wonder if the USB bus is crashing for some reason and taking out both the USB-serial and the flash drive?

Jeff -
I think your premise of the USB crashing and taking out the USB-serial and flash drive is a good one.

Out of two error logs I kept, the common denominator always seems to be the OHCI disabled error, then at least the SCSI errors for the flash drive. I think I had one undocumented run where the DTR/RTS LOW errors occured before the OHCI crash, one documented crash of OHCI without DTR/RTS errors, and then there is this example with the OHCI crash before the DTR/RTS.

Right now, I'm branching around the problem. I'm using /dev/tts/0 from the WL-520GU like your WiFi radio, as TX directly to the Arduino, instead of the USB Serial port TX through a hub, which is encountering problems. I'm still using the hub for the USB flash drive, and that seems OK. Currently, I've been running over 9 hours without problems. If I make it until tomorrow, I'll probably just use /dev/tts/0 and forget about the USB.

Though it would be nice to debug the USB Serial problem, I'm not tall enough to ride this ride.

At least it's anecdotal evidence to avoid using the arduino USB serial port for like applications and might help someone avoid a blind alley.

[mightyohm]

What kind of USB hub are you using? There may be some sensitivity to the brand/speed of the hub, I think I've heard this from others before.

[sys_spud]

I'm using a very cheap IOGear four port unpowered hub, model GUH285W6. I have a Belkin four port powered hub that I may give a try when I have time. I'll post my results back if I experiment with that.

[mightyohm]

Sounds like it would be worth a try. I wonder if you can increase the frequency of the RSS updates to get the bus to crash faster? An 8 hour troubleshooting cycle is a real drag!

[coreymaaskant]

Where did you get nohup?

[tink]

I’m using an Asus 520GU running Open WRT 10.03 RC3 and have been having difficulty with a FTDI chip as well. At this point I’m just getting a handle on the issue, but I have the USB connected to a 4 port hub, then a cell phone, flash drive and a FTDI based relay board. If anybody is interested, I can get all the details on the stuff.

The important thing is if I don’t connect the FTDI relay board, the system works for 24+ hours (I have it configured to boot daily.) If I connect the FTDI relay board (making no attempt to use it, just connect it.) The system works for a random period of time usually less then 2 hours and then the USB subsystem fails. Currently the only way to get it back is to reboot the Open WRT box.

Time permitting, I’m planning to:

1) Put the relay board in bitbang mode as soon as it is connected and see if that makes a difference. (speculating that noise is causing an input buffer to overflow.)
2) Connect the FTDI directly to the 520 to see if it behaves itself without the other devices.

As a note, I was having a similar issue with Open WRT 10.00, but the failure brought down the OS and I wasn’t able to figure out what it was. At that time, I thought the issue was with the cell phone.

If anybody has a fix or thoughts, I would appreciate them.