On Friday 30 April 2004 10:56 pm, Greg Wallace wrote:

I have no specific knowledge of in this area, but there's always two sides. If, as you say, USB is always busy, maybe it's the process looking to do the connect. I. e., maybe some processes needing USB wait a while when it's before they give up and maybe some are more impatient? Just a wild random thought (hopefully you'll get better answers from someone else), but I have seen this type of behavior elsewhere. For example, I have a large file that I transfer to a networked storage device. It's a unix device running SAMBA, so I have several methods I can use to get to this device -- mount it, use ftp (it has an ftp server), use SMBCLIENT, etc. If I try the easiest way (mount it and use Linux CP), CP eventually aborts because the networked device isn't able to keep up with CP and CP gets impatient (so to speak). If I use FTP, meaning that this external drive is pulling the data and controlling the flow, I have no problems. This is an example of how it depends on the particular process as to how it handles different types of wait state events, etc.

Greg Wallace

Hello Greg, There is a ps to my original email: I should have sent the printer's IPP report. It has a printer-state-message that says: USB port busy; will retry in 30 seconds... I think this is the source of the problem. I have been using: sbin/rchotplug restart. This works until the port becomes busy again. But it doesn't tell me what exactly is going on which I would like to know. Jerome