Bug 171605 - Pilot-xfer errors reading system info after connecting to Zire 72.
Pilot-xfer errors reading system info after connecting to Zire 72.
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: pilot-link (Show other bugs)
3
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Ngo Than
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-10-24 05:31 EDT by Pete Eggers
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version: FC5/FC5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-04-14 12:33:14 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)

  None (edit)
Description Pete Eggers 2005-10-24 05:31:19 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc3 Firefox/1.0.7

Description of problem:
This is not a timing issue with udev.  Same issue with a static node (i.e. mknod /tmp/pilot c 188 0).  Also, udev permissions were updated to 666 for ttyUSB*.  Here is a copy of the output:

[Peter@goo ~]$ pilot-xfer -p /dev/ttyUSB1 -b x/


   Listening to port: /dev/ttyUSB1

   Please press the HotSync button now... Connected


   Error read system info on /dev/ttyUSB1
[Peter@goo ~]$ 

Using strace, it is shows that the device is openned and read from, establishing a connection, and "Connected" being printed on terminal.  The following write of an apparent binary command errors out:

open("/dev/null", O_RDWR)               = 3
open("/dev/ttyUSB1", O_RDWR|O_NONBLOCK) = 4
ioctl(4, SNDCTL_TMR_TIMEBASE or TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(4, SNDCTL_TMR_TIMEBASE or TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(4, SNDCTL_TMR_START or TCSETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(4, SNDCTL_TMR_TIMEBASE or TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
fcntl64(4, F_GETFL)                     = 0x802 (flags O_RDWR|O_NONBLOCK)
fcntl64(4, F_SETFL, O_RDWR)             = 0
dup2(4, 3)                              = 3
close(4)                                = 0
write(2, "\n   Listening to port: /dev/ttyU"..., 79
   Listening to port: /dev/ttyUSB1

   Please press the HotSync button now... ) = 79
ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, {B9600 -opost -isig -icanon -echo ...}) = 0
ioctl(3, SNDCTL_TMR_STOP or TCSETSW, {B9600 -opost -isig -icanon -echo ...}) = 0
select(4, [3], NULL, NULL, NULL)        = 1 (in [3])
dup(3)                                  = 4
select(5, [4], NULL, NULL, NULL)        = 1 (in [4])
read(4, "", 1)                          = 0
write(2, "Connected\n\n", 11Connected

)           = 11
select(5, NULL, [4], NULL, NULL)        = 1 (out [4])
write(4, "\22\1 \4\0\1\0\3", 8)         = -1 EIO (Input/output error)
write(2, "\n   Error read system info on /d"..., 43
   Error read system info on /dev/ttyUSB1
) = 43
close(3)                                = 0
select(5, NULL, [4], NULL, NULL)        = 1 (out [4])
write(4, "/\1 \2\0\0", 6)               = -1 EIO (Input/output error)
close(4)                                = 0
exit_group(1)                           = ?
[Peter@goo ~]$

The "close(4)" which appears to be the lun for /dev/ttyUSB1 just before it prints "Listening to port"... seems odd, but I am not familiar with Linux.  In any case the following read works as I stated above but the write does not, nor the second write (to signal the Zire to close the port?).

Exactly the same results with /dev/ttyUSB0 using the same tests/setups as /dev/ttyUSB1.

I have tried several kernels (2.6.9, 2.6.11, 2.6.12-1.137[26]; incl. smp versions), with no change in symtoms.

I also tried the latest beta of pilot-link, 0.12.0-pre4 with strace.  As soon as the Zire's hotsync was engaged, it went into an apparent infinite loop of select(... and read(... on at least 2 different kernels including 2.6.12-1.1378.

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

How reproducible:
Always

Steps to Reproduce:
1.plug in Zire 72
2.wait for udev to establish ports /dev/ttyUSB0 and /dev/ttyUSB1
3.run: pilot-xfer -p /dev/ttyUSB1 -l
     or
  run: pilot-xfer -p /dev/ttyUSB1 -b x/   (where "x" is an empty directory)
  

Actual Results:     Listening to port: /dev/ttyUSB1

   Please press the HotSync button now... Connected


   Error read system info on /dev/ttyUSB1


Exactly the same error with either option, either node, or using a static node (i.e. /tmp/pilot).

The Zire 72 and its USB cable were tested on a Windows XP machine, where the combination linked and synced successfully without incident.

Expected Results:  Zire 72's contents should have been backed up to directory "x".

Or, with the "-l" option, the contents of the Zire 72 should have been printed on the terminal.

Additional info:

Linux goo.home 2.6.12-1.1378_FC3smp #1 SMP Wed Sep 14 04:52:36 EDT 2005 i686 athlon i386 GNU/Linux

It is a single processor, but the system started to freeze frequently about the time an Audigy sound card was installed and ALSA apps were being run.  Using an SMP kernel resolved the problem, whatever it was.
Comment 1 Ngo Than 2006-04-14 12:33:14 EDT
it looks like a kernel problem, which probably has been fixed in FC4 and fc5.
it's recommemd to update your machine to FC4/FC5. FC3 is not supported anymore.

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