Bug 131100 - Can't backup Treo 90 through Belkin USB hub, but no problems with USB ports on system unit.
Can't backup Treo 90 through Belkin USB hub, but no problems with USB ports o...
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
2
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Pete Zaitcev
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-08-27 11:20 EDT by George Avrunin
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-04-16 01:15:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
/proc/bus/usb/devices with the Treo connected to the Belkin hub and sync button on Treo cable pushed (5.04 KB, text/plain)
2004-08-27 11:24 EDT, George Avrunin
no flags Details

  None (edit)
Description George Avrunin 2004-08-27 11:20:54 EDT
Description of problem:
I am trying to sync a Treo 90 (originally with jpilot, but the problem
seems to be in pilot-link, or maybe even in the USB stuff in the
kernel?).  I am running a fully updated Fedora Core 2 system on a Dell
Precision 350 (i.e., with kernel 2.6.8-1.521, etc.).

I can sync the Treo using jpilot or backup with pilot-xfer using the
USB ports on the Dell system unit.  But these are not reachable from
my desk, so I bought a Belkin USB 2 hub (model F5U234, 4-port powered)
and plugged it into a USB port on the system unit.  (I have tried with
different USB ports; the results are the same.)

When I plug the Treo's USB cable into the hub and press the sync
button on the cable, I get the following in /var/log/messages:

Aug 27 10:49:29 g2 kernel: usb 2-1.2: new full speed USB device using
address 9
Aug 27 10:49:29 g2 kernel: visor 2-1.2:1.0: Handspring Visor / Palm OS
converter detected
Aug 27 10:49:29 g2 kernel: usb 2-1.2: Handspring Visor / Palm OS
converter now attached to ttyUSB0
Aug 27 10:49:29 g2 kernel: usb 2-1.2: Handspring Visor / Palm OS
converter now attached to ttyUSB1
Aug 27 10:49:31 g2 udev[10234]: creating device node '/udev/ttyUSB0'
Aug 27 10:49:31 g2 udev[10236]: creating device node '/udev/ttyUSB1'

If I then press the "Sync" button on jpilot or issue the command
"pilot-xfer -p /dev/ttyUSB1 -b pilot-xfer-backup", /var/log/messages
shows:

Aug 27 10:49:41 g2 kernel: visor ttyUSB1: visor_open - failed
submitting interrupt urb, error -28
Aug 27 10:49:41 g2 udev[10256]: removing device node '/udev/ttyUSB0'
Aug 27 10:49:41 g2 kernel: visor ttyUSB0: Handspring Visor / Palm OS
converter now disconnected from ttyUSB0
Aug 27 10:49:41 g2 udev[10274]: removing device node '/udev/ttyUSB1'
Aug 27 10:49:41 g2 kernel: visor ttyUSB1: Handspring Visor / Palm OS
converter now disconnected from ttyUSB1

The same sequence of commands works fine if I plug the Treo's USB
cable directly into one of the USB ports on the Dell system unit.

The hub appears to work fine with other devices (such as my USB memory
key).  I don't know enough about the details of pilot-link or the USB
infrastructure to have any idea whether this is an error in visor_open
or in the way the USB structure is set up and passed to visor_open.



Version-Release number of selected component (if applicable):
pilot-link-0.11.8-3.1

How reproducible:
Every time:

Steps to Reproduce:
1. Plug Treo's USB cable into Belkin USB hub and press sync button on
cable.
2.  Click Sync button on jpilot or enter "pilot-xfer -p /dev/ttyUSB1
-b pilot-xfer-backup"
3.
  
Actual results:
pilot-xfer says: 
   Unable to bind to port: /dev/ttyUSB1
   Please use --help for more information
jpilot says:
  pi_bind Illegal seek
  Check your serial port and settings
  Exiting with status SYNC_ERROR_BIND
  Finished


Expected results:
  Backup or sync.  (E.g., pilot-xfer saying something like:
   Listening to port: /dev/ttyUSB1
 
   Please press the HotSync button now... Connected
 
Backing up pilot-xfer-backup/Datebk5DB.pdb
Backing up pilot-xfer-backup/CityTimeDB.pdb
Backing up pilot-xfer-backup/Datebk3HDB.pdb
Backing up pilot-xfer-backup/HSAdvCalcDB.pdb
Backing up pilot-xfer-backup/AddressDB.pdb
Backing up pilot-xfer-backup/DatebookDB.pdb
... )  These are the results I get using a USB port on the system unit. 

Additional info:
Comment 1 George Avrunin 2004-08-27 11:24:30 EDT
Created attachment 103165 [details]
/proc/bus/usb/devices with the Treo connected to the Belkin hub and sync button on Treo cable pushed

As far as I can tell, the hub works correctly with other devices.  Here's
/proc/bus/usb/devices after I've connected the Treo to the hub and pushed the
sync button on the Treo's cable, but before calling pilot-xfer.
Comment 2 Ngo Than 2004-08-31 11:18:08 EDT
it looks like you are using udev on your machine!

you find the usb device node ttyUSB0/ttyUSB1 in /udev

could you please try with /udev/ttyUSB[0|1] or just disable udev. Does
it work for you?
Comment 3 George Avrunin 2004-08-31 12:44:10 EDT
With "pilot-xfer -p /udev/ttyUSB0 -b pilot-xfer-backup3"
I get the error message 
 
  Port not connected, sleeping for 2 seconds, 5 retries..   The device
/udev/ttyUSB0 does not exist..

and /var/log/messages says:

Aug 31 12:37:43 g2 kernel: usb 2-1.4: new full speed USB device using
address 5
Aug 31 12:37:44 g2 kernel: visor 2-1.4:1.0: Handspring Visor / Palm OS
converter detected
Aug 31 12:37:44 g2 kernel: usb 2-1.4: Handspring Visor / Palm OS
converter now attached to ttyUSB0
Aug 31 12:37:44 g2 kernel: usb 2-1.4: Handspring Visor / Palm OS
converter now attached to ttyUSB1
Aug 31 12:37:45 g2 udev[4297]: creating device node '/udev/ttyUSB0'
Aug 31 12:37:45 g2 udev[4299]: creating device node '/udev/ttyUSB1'
Aug 31 12:37:54 g2 kernel: visor ttyUSB0: Device lied about number of
ports, please use a lower one.
Aug 31 12:37:54 g2 udev[4315]: removing device node '/udev/ttyUSB0'
Aug 31 12:37:54 g2 kernel: visor ttyUSB0: Handspring Visor / Palm OS
converter now disconnected from ttyUSB0
Aug 31 12:37:54 g2 udev[4333]: removing device node '/udev/ttyUSB1'
Aug 31 12:37:54 g2 kernel: visor ttyUSB1: Handspring Visor / Palm OS
converter now disconnected from ttyUSB1


With "pilot-xfer -p /udev/ttyUSB1 -b pilot-xfer-backup3" 
I get the error message

   Unable to bind to port: /udev/ttyUSB1
   Please use --help for more information

(The port is in group uucp with group rw permission.  I am in group
uucp.)  /var/log/messages has:

Aug 31 12:36:33 g2 kernel: usb 2-1.4: new full speed USB device using
address 4
Aug 31 12:36:33 g2 kernel: drivers/usb/serial/usb-serial.c: USB Serial
support registered for Generic
Aug 31 12:36:33 g2 kernel: usbcore: registered new driver
usbserial_generic
Aug 31 12:36:33 g2 kernel: usbcore: registered new driver usbserial
Aug 31 12:36:33 g2 kernel: drivers/usb/serial/usb-serial.c: USB Serial
Driver core v2.0
Aug 31 12:36:33 g2 kernel: drivers/usb/serial/usb-serial.c: USB Serial
support registered for Handspring Visor / Palm OS
Aug 31 12:36:33 g2 kernel: drivers/usb/serial/usb-serial.c: USB Serial
support registered for Sony Clie 3.5
Aug 31 12:36:33 g2 kernel: drivers/usb/serial/usb-serial.c: USB Serial
support registered for Sony Clie 5.0
Aug 31 12:36:33 g2 kernel: visor 2-1.4:1.0: Handspring Visor / Palm OS
converter detected
Aug 31 12:36:33 g2 kernel: usb 2-1.4: Handspring Visor / Palm OS
converter now attached to ttyUSB0
Aug 31 12:36:33 g2 kernel: usb 2-1.4: Handspring Visor / Palm OS
converter now attached to ttyUSB1
Aug 31 12:36:33 g2 kernel: usbcore: registered new driver visor
Aug 31 12:36:33 g2 kernel: drivers/usb/serial/visor.c: USB HandSpring
Visor / Palm OS driver v2.1
Aug 31 12:36:35 g2 udev[4143]: creating device node '/udev/ttyUSB0'
Aug 31 12:36:35 g2 udev[4145]: creating device node '/udev/ttyUSB1'
Aug 31 12:36:45 g2 kernel: visor ttyUSB1: visor_open - failed
submitting interrupt urb, error -28
Aug 31 12:36:45 g2 udev[4161]: removing device node '/udev/ttyUSB0'

I tried setting USE_UDEV="no" in /etc/sysconfig/udev and then
rebooting.  Issuing the pilot-xfer command using /dev/ttyUSB1 as usual
got the same results as I reported initially (the failed submitted
interrup stuff).  

I'm not sure this is what you meant by "disabling udev".  If there's
something else I should have done, please let me know. 

Comment 4 George Avrunin 2004-09-03 08:11:02 EDT
I'm back to USE_UDEV="yes", as it was originally.  I borrowed a Palm
Tungsten E.  I first tried synchronizing with jpilot set to port
/dev/ttyUSB1 (what I usually use for my Treo) through a USB port on
the system unit.  It basically worked fine, though it ran into some
problem with some photo application on the Palm and I saw
  Sep  3 07:39:40 g2 kernel: usb 4-2: control timeout on ep0in
in /var/log/messages.  (But jpilot isn't completely happy with some of
the new stuff in PalmOS 5.x, so I'm not worrying about that.)  Then I
plugged the Palm's cable into the Belkin USB port and did another sync
(starting the hotsync on the Palm, so the device gets registered, and
then hitting the sync button on jpilot).  It started just fine:

Sep  3 07:42:14 g2 kernel: usb 2-1.3: new full speed USB device using
address 6
Sep  3 07:42:14 g2 kernel: ehci_hcd 0000:02:02.2: qh 3e69d180 (#0) state 1
Sep  3 07:42:14 g2 kernel: visor 2-1.3:1.0: Handspring Visor / Palm OS
converter detected
Sep  3 07:42:14 g2 kernel: usb 2-1.3: Handspring Visor / Palm OS
converter now attached to ttyUSB0
Sep  3 07:42:14 g2 kernel: usb 2-1.3: Handspring Visor / Palm OS
converter now attached to ttyUSB1
Sep  3 07:42:16 g2 udev[23225]: creating device node '/udev/ttyUSB0'
Sep  3 07:42:16 g2 udev[23227]: creating device node '/udev/ttyUSB1'

And jpilot was doing the sync normally.  But while I was logging into
Bugzilla to report this, all of a sudden my USB mouse locked up
completely and the sync died.  /var/log/messages reported:
Sep  3 07:43:04 g2 kernel: bad: scheduling while atomic!
Sep  3 07:43:04 g2 kernel: Stack pointer is garbage, not printing trace
Sep  3 07:43:04 g2 kernel: visor ttyUSB1: visor_unthrottle - failed
submitting read urb, error -1
Sep  3 07:44:26 g2 su(pam_unix)[23278]: session opened for user root
by avrunin(uid=500)
Sep  3 07:45:12 g2 kernel: usb 2-1.3: USB disconnect, address 6
Sep  3 07:45:12 g2 kernel: ehci_hcd 0000:02:02.2: qh 3e69d280 (#18)
state 5
Sep  3 07:45:12 g2 kernel: visor 2-1.3:1.0: device disconnected

I wasn't able to get the mouse restarted (though I didn't mess around
with removing the USB modules) and just rebooted.  

I just checked out the hub again by successfully mounting a USB2
memory key and transferring a 10 MB file from the key to my home
directory.  According to diff, the two files are identical.  So it
doesn't *seem* to be a hardware problem with the hub.
Comment 5 Ngo Than 2004-09-03 08:29:31 EDT
it looks like a bug in kernel (USB). I reassign it to correct component
Comment 6 Pete Zaitcev 2005-02-07 17:57:11 EST
I might have discovered the reason by accident last week.
If a device requires interrupt transfers, plugging it into
a hub and then into EHCI will not work. Requests to transfer
interrupt URBs fail (unless the interrupt period is bigger
than a certain value, usually 4ms). The EHCI driver is unable
to calculate the bandwidth correctly and refusts the transfer.
This happens because USB 2.0 hubs already contain interrupt
endpoints, and so transfer are already started in slots.
And the current EHCI driver cannot provide sharing between
those transfers.

Unfortunately, prognosis is not good. The upstream author (David B)
says that more fine grained interrupt transfer scheduling is
possible, but not easy to do. I looked at the code and was unable
to understand it at all.

The workaround is to use a USB 1.1 hub and/or move devices with
interrupt endpoints to different buses/controllers.
Comment 7 Dave Jones 2005-04-16 01:15:57 EDT
Fedora Core 2 has now reached end of life, and no further updates will be
provided by Red Hat.  The Fedora legacy project will be producing further kernel
updates for security problems only.

If this bug has not been fixed in the latest Fedora Core 2 update kernel, please
try to reproduce it under Fedora Core 3, and reopen if necessary, changing the
product version accordingly.

Thank you.

Note You need to log in before you can comment on or make changes to this bug.