Under Fedora 10 I used gpsbabel to download tracks from a Garmin Vista HCx connected via USB, with a command like % sudo gpsbabel -t -i garmin -f usb: -o gpx -F ravenscourt2.gpx The need to run it as root was an inconvenience, but it's not the subject of this bug report. Since upgrading to Fedora 11 preview using preupgrade, this no longer works. I get Claim interfaced failed: could not claim interface 0: Device or resource busy The other USB device connected is a mouse, which works fine. Here is the output of lsusb: Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 002: ID 091e:0003 Garmin International GPSmap (various models) Bus 005 Device 003: ID 046d:c50e Logitech, Inc. MX-1000 Cordless Mouse Receiver Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
I believe this is caused by the garmin_gps kernel module claiming the device. % lsmod | grep garmin garmin_gps 17012 0 usbserial 33488 1 garmin_gps After 'sudo rmmod garmin_gps', it works. There is discussion of this in Ubuntu bug <https://bugs.launchpad.net/ubuntu/+bug/114565>. It is suggested that since newer GPS software is able to talk directly to Garmin devices via USB (rather than a serial port as in the old days), the usbserial emulation is no longer needed and should not be loaded by default when a Garmin device is plugged in.
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Hi, My stock F11 install gpsbabel locks up solid when attempting to access the USB ports. 'kill -9' doesn't end the gpsbabel process, which goes zombie, and prevents 'rmmod garmin_gps'. To cause a problem: 1. Plug a Garmin eTrex HCx into a USB port. 2. run 'sudo gpsbabel -i garmin -f usb:-1' 3. Open another terminal, and try to kill gpsbabel 'killall -9 gpababel' Confirmed workaround: 1. Plug a Garmin eTrex HCx into a USB port. 2. check that the stock behavoiur is to start germin_gps and usbserial via 'lsmod|grep gps' garmin_gps 16996 0 usbserial 33488 1 garmin_gps 3. run 'sudo rmmod garmin_gps' to free-up the GPS USB device 4. run 'sudo gpsbabel -i garmin -f usb:-1' to check the USB devices recognised by GPSbabel 0 9999999999 694 eTrex Vista HCx Software Version 3.00 (serial number munged for privacy) Useful information: $ uname -a Linux hostname.domain 2.6.29.6-213.fc11.x86_64 #1 SMP Tue Jul 7 21:02:57 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux $ gpsbabel -V GPSBabel Version 1.3.6
Hi, I've had similar troubles with using the garmin_gps driver. The process locks up and cannot be killed. I am interested in using the usbserial driver as it is required for MyTourbook (http://mytourbook.sourceforge.net/mytourbook/). Using either mytourbook or gpsbabel with "-f /dev/ttyUSB0" causes the hang. Unloading garmin_gps and using gpsbabel with the direct USB access works fine. I have had some success with the patch listed on the garmin_gps sourceForge bug tracker (http://sourceforge.net/tracker/?func=detail&aid=2821531&group_id=115375&atid=671991). I applied the patch to the F11 source for garmin_gps. The process would no longer hang, however data transfer fails (Again with gpsbabel or mytourbook). Running debug with gpsbabel seems to tranfer alot of data but ends with $ gpsbabel -D9 -t -i garmin -f /dev/ttyUSB0 -o gtrnctr -F outSerialUSB.tcx [---final lines of debug-----] Tx Data:10 06 02 22 00 d6 10 03 : .....(ACK ) Rx Data:10 22 18 ff ff ff 7f ff ff ff 7f f4 82 f4 24 51 59 04 69 51 59 04 69 00 ff 00 00 13 10 03 ............QY.iQY.i.... (TRKDAT ) Tx Data:10 06 02 22 00 d6 10 03 : .....(ACK ) Rx Data:10 0c 02 06 00 ec 10 03 .. (XFRCMP ) Tx Data:10 06 02 0c 00 ec 10 03 : .....(ACK ) [ERROR] A301_Get: Non-Pid_Trk_Data $ uname -a Linux hostname.domain 2.6.29.6-217.2.8.fc11.i686.PAE #1 SMP Sat Aug 15 01:07:59 EDT 2009 i686 i686 i386 GNU/Linux Thanks
gpsbabel using serial ttyS1 also doesn't work, fails with following message. gpsbabel -D9 -t -i garmin -f /dev/ttyS1 -o gpx -F tracks.txt > debug.txt GPSBabel Version: 1.3.6 [ERROR] GPS_Packet_Read: Timeout. No data received. GARMIN:Can't init /dev/ttyS1 Compiling from source fixes the problem. Same version of source.
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '11'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 11's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 11 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.