Bug 184059
| Summary: | pilot-xfer w/ treo650 via USB aborts on -l | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Bowe Strickland <bowe> |
| Component: | pilot-link | Assignee: | Ivana Varekova <varekova> |
| Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 5 | CC: | mattdm, nigel |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2007-07-26 08:34:54 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Bowe Strickland
2006-03-05 17:41:39 UTC
other info: [...@localhost ~]$ uname -r 2.6.15-1.2009.4.2_FC5 [...@localhost ~]$ rpm -qa | grep libc | xargs rpm -q libcroco-0.6.0-6.2.1 libcap-devel-1.10-24.2 glibc-kernheaders-3.0-5.2 glibc-common-2.3.91-1 glibc-devel-2.3.91-1 glibc-2.3.91-1 libcap-1.10-24.2 libcroco-devel-0.6.0-6.2.1 glibc-headers-2.3.91-1 Confirm this on FC5T3 with all updates applied:- kernel-smp-2.6.15-1.1955_FC5 kernel-smp-2.6.15-1.2041_FC5 pilot-link-0.12.0-0.pre4.5.2.1 udev-084-13 on i386 - P4 2.8 This obviously breaks kpilot (crashes) and gnome-pilot (crashes) too. Additionally the udev rules are wrong for this device - the T650 (and other late palm devices) generates 2 ttyUSB devices, only the second of which should be symlinked to /dev/pilot. Currently both are - the first one normally wins. I saw this problem with pilot-xfer -l -p /dev/ttyUSB1 which is looking at the right device:- [nigel@carrot ~]$ pilot-xfer -l -p /dev/ttyUSB1 *** buffer overflow detected ***: pilot-xfer terminated ======= Backtrace: ========= /lib/libc.so.6(__chk_fail+0x41)[0x322965] /lib/libc.so.6(__ptsname_r_chk+0x0)[0x322fa8] /usr/lib/libpisock.so.9[0x437fb19] /usr/lib/libpisock.so.9(pi_bind+0x55)[0x4381f25] pilot-xfer[0x804f3ab] pilot-xfer[0x804dec5] /lib/libc.so.6(__libc_start_main+0xdc)[0x25c7e4] pilot-xfer[0x804a181] ======= Memory map: ======== 00247000-00373000 r-xp 00000000 08:01 7987608 /lib/libc-2.4.so 00373000-00376000 r-xp 0012b000 08:01 7987608 /lib/libc-2.4.so 00376000-00377000 rwxp 0012e000 08:01 7987608 /lib/libc-2.4.so 00377000-0037a000 rwxp 00377000 00:00 0 0046c000-00477000 r-xp 00000000 08:01 7988627 /lib/libgcc_s-4.1.0-20060304.so.1 00477000-00478000 rwxp 0000a000 08:01 7988627 /lib/libgcc_s-4.1.0-20060304.so.1 0051b000-00522000 r-xp 00000000 08:01 6220702 /usr/lib/libpopt.so.0.0.0 00522000-00523000 rwxp 00006000 08:01 6220702 /usr/lib/libpopt.so.0.0.0 00c43000-00c44000 r-xp 00c43000 00:00 0 [vdso] 00e17000-00e30000 r-xp 00000000 08:01 7987601 /lib/ld-2.4.so 00e30000-00e31000 r-xp 00018000 08:01 7987601 /lib/ld-2.4.so 00e31000-00e32000 rwxp 00019000 08:01 7987601 /lib/ld-2.4.so 0435c000-0438f000 r-xp 00000000 08:01 3053732 /usr/lib/libpisock.so.9.0.0 0438f000-04393000 rwxp 00032000 08:01 3053732 /usr/lib/libpisock.so.9.0.0 08048000-08052000 r-xp 00000000 08:01 3058837 /usr/bin/pilot-xfer 08052000-08054000 rw-p 00009000 08:01 3058837 /usr/bin/pilot-xfer 09bfe000-09c1f000 rw-p 09bfe000 00:00 0 [heap] b7f3c000-b7f3d000 rw-p b7f3c000 00:00 0 b7f56000-b7f57000 rw-p b7f56000 00:00 0 bfc41000-bfc57000 rw-p bfc41000 00:00 0 [stack] Aborted Was going to spend some time digging into this - and got more confused.... When I originally booted the box to test this, pilot-xfer worked just fine! Then a couple of minutes later it would not work at all... whats more the symptoms appear to look like a kernel level problem. pilot-xfer bombs as shown above if the device node is not in place, if its not read/write to the process, or if the kernel blocks it in some other way. When the system is in its fucked state you find that /sbin/lsusb hangs when you attempt to connect with the palm (ie hit hotsync) until such time as the connect times out. Putting a manual device node (rather than a udev magic one) can help, but things are still flakey. stracing udev shows that when the kernel is in its odd state udev is not being called - explaining why the device nodes are not appearing. In summary I think there is a different kernel level bug here, but that pilot-xfer is also at fault for failing in such a messy fashion when its calling environment is not just as it wants. [I'm also depressed that the FC5 palm support appears to be in even worse state than the FC4 one] If using USB, I've found you have to time it just right... If you run pilot-xfer -p /dev/ttyUSB1 -i... before initiiting hotsync, the node doesn't exist, and pilot-xfer crashes with symptoms simlar to above. If you initiate transfer from treo650 _first_, then "hit enter" on above command, all works fine... (gpilotd, however, seems to be a different case :(.) Could you please try to reproduce your bug this the latest version of pilot-link pilot-link-0.12.1-3.fc7. Fedora Core 5 and Fedora Core 6 are, as we're sure you've noticed, no longer test releases. We're cleaning up the bug database and making sure important bug reports filed against these test releases don't get lost. It would be helpful if you could test this issue with a released version of Fedora or with the latest development / test release. Thanks for your help and for your patience. [This is a bulk message for all open FC5/FC6 test release bugs. I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.] Unfortunately there's not enough information here, therefore closing this bugzilla. Please re-open if needed. |