Updated FC4-t3 udev to 0.58-1 and now it takes 30 seconds (sometimes longer) to create the /dev/ttyUSB0 & /dev/ttyUSB1 entries when hotsyncing a palm device. By the time the entries have been created, the Palm device has stopped polling. As a result, the pilot-link suite never gets a connection to the Palm device. This has only started since updating udev to 0.58-1
*** Bug 161058 has been marked as a duplicate of this bug. ***
Wouldn't it be better to "upgrade" this bug to FC4, so it will show up directly when querying on FC4, just as bug 161058 does (but only when searching on closed bugs)? (This is of course a more general issue with testing bugs: why aren't (unclosed) testing bugs upgraded (or cloned, etc.) to the "final" release when that final release is available? This would mean that test releases reach their end-of-life - their bug reports at least - when the final release is available ...)
Upgraded to Fedora Core 4 as this problem is persistant.
From duplicate bug 161058, a temporary solution for anyone still sitting frustrated at not having pilot-xfer working with your Palm device, try the following: As root: mknod /tmp/pilot c 188 1 chown your_user_name /tmp/pilot Then use the flag '-p /tmp/pilot' for pilot-xfer. Working great for me so far.
Keith, Did you get gpilotd to work with it? I'm using the latest pilot-* and gnome-pilot-* from -testing; pilot-* (pilot-xfer, etc) work just fine. Under gpilotd, the palm device trys to sync and immediately quits.
Come to think about it. This belongs to another bug report (gnome-pilot doesn't play well with shipped pilot-link). Please ignore my last post.
FC-3 (not FC-4) # uname -rm 2.6.12-1.1376_FC3 i686 My solution (temporary until udev works per above) as root... mknod /tmp/pilot c 188 1 chown craig /tmp/pilot plug in treo and press hotsync button as craig (cli) pilot-xfer -L -p /tmp/pilot Works - got file list from Treo so to make gpilotd work I had to add... <!-- Handspring Treo 650 --> <device vendor_id="0830" product_id="0061" /> to /usr/share/gnome-pilot/devices.xml
tried today on FC4 with Kernel 2.6.13-1.1526_FC4: once I plug the USB Cable of my Tungsten T5 into the PC (Dell Latitude D800) it takes max 4 seconds until my T5 is in Nirvana and needs a hard-reset :-( this is reproducable every time.
Jens, just tried under FC4 with kernel 2.6.13-1.1526_FC4, a device node of ~/dev/pilot (as per comment #7), jpilot-0.99.8-0.pre10.fc4.1 and pilot-link-0.12.0-0.pre4.0.fc4.2 I can sync to jpilot just fine and get no hang on my T5 (Palm OS 5.4.8) PC is a desktop machine (A7V600-X mainboard FWIW)
Updating to a rawhide udev solved all the problems without having to kludge dev entries.
I came to this bug as I have similar issue but with HP Jornada 720. There is situation bit worse as the Jornada timeout is only 3-4s and udev/hotplug takes 6-7 seconds to start synce-start-serial that is defined in /etc/udev/scripts/synce.dev (synce package is from fedora extras). Dec 17 13:03:01 fb kernel: ohci_hcd 0000:00:02.0: wakeup Dec 17 13:03:02 fb kernel: usb 2-7: new full speed USB device using ohci_hcd and address 11 Dec 17 13:03:02 fb kernel: ipaq 2-7:1.0: PocketPC PDA converter detected Dec 17 13:03:02 fb kernel: usb 2-7: PocketPC PDA converter now attached to ttyUSB0 Dec 17 13:03:06 fb kernel: usb 2-7: USB disconnect, address 11 Dec 17 13:03:06 fb kernel: PocketPC PDA ttyUSB0: PocketPC PDA converter now disconnected from ttyUSB0 Dec 17 13:03:06 fb kernel: ipaq 2-7:1.0: device disconnected When I start in the mean time synce-serial-start manualy then device connects OK.
Yesterday, I was generally able to get the "mknod /tmp/pilot c 188 1 chown your_user_name /tmp/pilot" method to work, from comment 4, but today it's just not cooperating (this may be because I updated; not sure if udev was one of the packages updated or not). I'm not sure if this is the same problem or not, so I add my info to the pile. It looks to be starting to create the /dev/ttyUSB{0,1} devices, but somehow not finishing them. By this, I mean... before I hit the sync button, there is nothing there: "# ls -l /dev/ttyUSB* ls: /dev/ttyUSB*: No such file or directory" When I hit the sync button, the following shows up in /var/log/messages: "Dec 22 20:30:44 phoenix kernel: usb 1-2: new full speed USB device using ohci_hcd and address 13 Dec 22 20:30:44 phoenix kernel: visor 1-2:1.0: Handspring Visor / Palm OS converter detected Dec 22 20:30:44 phoenix kernel: usb 1-2: Handspring Visor / Palm OS converter now attached to ttyUSB0 Dec 22 20:30:44 phoenix kernel: usb 1-2: Handspring Visor / Palm OS converter now attached to ttyUSB1" And approximately 5 seconds later, I see: "# ls -l /dev/ttyUSB* crw-rw---- 1 root uucp 188, 0 Dec 22 20:30 /dev/ttyUSB0 crw-rw---- 1 root uucp 188, 1 Dec 22 20:30 /dev/ttyUSB1" But the text of the device names are yellow on a black background, which I seem to recall happens when a device is created on the filesystem, but nothing actually exists. (the /dev/pilot link is also not created) udev-058-1.0.FC4.1 - which is I believe the most recent version available. I do also note that the visor module does appear to be loaded: # lsmod | grep visor visor 19149 0 usbserial 30377 1 visor
To confirm, this is still an issue with kernel-2.6.14-1.1656_FC4, udev-058-1.0.FC4.1, and a Treo 650. As per the initial report, pressing the hotsync button is required to activate the USB connection, but by the time udev has created the device nodes the Treo has given up polling for the higher level sync software (i.e. pilot-xfer). However, it would appear that only some Palm devices time out before udev creates the device node: a Palm Tungsten T syncs fine (once the device node is finally created), but on the same machine a Treo 650 times out. N.B. There is no immediate error on the Treo that it has timed out - it appears to be waiting for hotsync, while pilot-xfer waits forever at: Listening for incoming connection on /dev/pilot The "mknod /tmp/pilot c 188 1" kludge works as expected.
Where is a good place to insert those 'kludge' commands to make it happen every boot (in case /tmp gets emptied)?
Why not create /etc/dev (this is what I do) though every other place (/usr/dev, etc) should work just as well.
The problem with devices that you create either by mknod or by copiing them to /etc/udev/devices or anything else is, that when this device is managed anyhow by udev, then it is deleted when you remove device. At least this is how it works with ttyUSBx. You can create it manualy, but it will be deleted on device removal, next time it will not be created in time again.
Just put the mknoded devices outside of udev reach (I usually put them in /etc/dev). udev will be unaware of /etc/dev (or /usr/dev), and there-fore will not touch them when the device disconnects.
That is a "band-aid" fix and not the real solution. UDEV should be able to manage this in a timely manner by itself.
... Should :(
Seems to be fixed with udev-071-0.FC4.2 no ?
The situation does not change for me. It is true that ttyUSB0 is maybe created fast enought, but the start of synce.dev (the script) is somewhat slow...
Same here. pilot-xxx and gnome-pilot still timeout. Back to static ttyUSB0/1 for me. Once I'll have some free time I'll give FC5T3 a test run.
*** Bug 175859 has been marked as a duplicate of this bug. ***
This report targets the FC3 or FC4 products, which have now been EOL'd. Could you please check that it still applies to a current Fedora release, and either update the target product or close it ? Thanks.
Still happening on FC6. Please change target to FC6. - Gilboa
Information provided above.
For a while now, it's been the case that udev creates the /dev/ttyUSB{0,1} nodes very quickly; usually in about a second or so. However, hotsync'ing still only works sporadically. This seems to be true no matter how quickly I press the "sync" button in jpilot after pressing the hotsync button on my Palm. Sometimes it syncs the first time. Usually, I have to try a few times before it'll sync. Sometimes I have to try almost a dozen times. It's irritating, but not overly so.
how about fixing the application?
Because it's not the application's fault. The problem is that occasionally, the select() call on /dev/pilot never returns. (This is unrelated to how long it takes udev to create the device nodes.)
That is because the ttyUSB device nodes are recreated in the kernel and can change numbers (some pilots disconnect and reconnect to the USB bus on a hotsync button press). So the app should, look in HAL for the device nodes, which the pilot device has and try both of them, and after the user pressed the hotsync button scan for HAL changes and reopen those devices.
pilot-link isn't HAL-aware, and IMHO, shouldn't need to be in order to complete a HotSync operation. Simply reading/writing from/to a tty should be sufficient. Regardless, however, your comment gave me the needed clue to figure out the problem: the select() call occasionally hangs because udev occasionally symlinks /dev/pilot to /dev/ttyUSB0 instead of /dev/ttyUSB1: # CORRECT RUN: I press the HotSync button on my Palm... $ ls -lsa /dev/pilot /dev/ttyUSB* 0 lrwxrwxrwx 1 root root 7 Jan 24 12:08 /dev/pilot -> ttyUSB1 0 crw------- 1 example uucp 188, 0 Jan 24 12:08 /dev/ttyUSB0 0 crw------- 1 example uucp 188, 1 Jan 24 12:08 /dev/ttyUSB1 $ pilot-xfer -p /dev/pilot -l 1>/dev/null Listening to port: /dev/pilot Please press the HotSync button now... Connected # INCORRECT RUN: I press the HotSync button on my Palm... $ ls -lsa /dev/pilot /dev/ttyUSB* 0 lrwxrwxrwx 1 root root 7 Jan 24 11:57 /dev/pilot -> ttyUSB0 0 crw------- 1 example uucp 188, 0 Jan 24 11:57 /dev/ttyUSB0 0 crw-rw---- 1 root uucp 188, 1 Jan 24 11:57 /dev/ttyUSB1 $ pilot-xfer -p /dev/pilot -l 1>/dev/null Listening to port: /dev/pilot Please press the HotSync button now... ^C $ pilot-xfer -p /dev/ttyUSB1 -l 1>/dev/null Listening to port: /dev/ttyUSB1 Please press the HotSync button now... Connected I don't know why udev is doing this, but I don't see how it can't be wrong; /dev/pilot should always be symlinked to /dev/ttyUSB1, because /dev/ttyUSB1 is always the correct device to open. (Or at least I've never seen a single instance where opening ttyUSB0 worked.)
what if another USB device acquired ttyUSB0-ttyUSB4 before you plugin the pilot?
(In reply to comment #31) > pilot-link isn't HAL-aware, and IMHO, shouldn't need to be in order to complete > a HotSync operation. Simply reading/writing from/to a tty should be sufficient. I thought about this a bit, and it can't be strictly true. Something has to know which /dev/ttyUSB device is a Palm Pilot and which isn't. I don't think it's possible for udev to have all the needed information to know what to link /dev/pilot to in all cases. Especially if you're using a USB RS-232 adapter to connect to an older RS-232 based Palm Pilot. Maybe the best answer is to have it pick appropriately whenever it can tell by the USB id alone and otherwise not link /dev/pilot to anything. If /dev/pilot isn't linked, pilot-xfer could query all the /dev/ttyUSB ports looking for a Palm Pilot or something. Anyway, just a random idea after seeing this exchange.
Ok. After spending some time digging through pilot-link, and spending a lot of time pondering, I now think that Harald's comment 28 was correct: the best thing to do is to fix the application. The fundamental issue here is that the kernel's visor driver is essentially a backwards compatibility layer for applications that don't understand the USB subsystem, and just want to use a serial port to HotSync. That is, fundamentally, what the visor driver does: it provides device files that look like serial ports in order to talk to a USB device. All of the problems that people have experienced trying to HotSync on Linux (including this bug and others) boil down to the fact that compatibility layers are easy to perturb. Fortunately, the pilot-link developers agree. Version 0.12.0 of pilot-link, released on 2006-09-04, includes native USB support. Meaning, that instead of this: $ pilot-xfer -p /dev/pilot -l You can simply do this: $ pilot-xfer -p usb: -l ...and pilot-xfer will scan USB devices looking for Palm-compatible devices. If it doesn't find any, it will wait until it receives one. There are some additional udev rules that are needed; these are described in the README.libusb file in the pilot-link package. You also have to blacklist the visor driver (otherwise the kernel will load it, and it will grab the device instead), but it's doable. In fact, I've been using this configuration for months. The only problem I haven't been able to solve is that the character devices that are created under /dev/bus/usb are always owned by root, which doesn't work, because pilot-link needs to be able to both read from and write to them. I've been hacking around this by running this command (as root) after I press the HotSync button on my pilot: $ find /dev/bus/usb -mmin -1 -type c | xargs -e -r -t chown username:username Then pilot-link can successfully HotSync. It just works. So, I'm not sure what package/service is responsible for the ownerships in /dev/bus/usb, but that definitely needs to be corrected. I'm going to file another bug against pilot-link, as udev, pilot-link, and potentially other packages will all need to be updated in lockstep to make this work.
I filed bug 236413 against pilot-link.
I think the ownership should be managed by udev...
Well, from tracing through udev in debug mode, it's clear that udev expects the pam_console_apply helper to set the permissions on the device node: Apr 16 10:49:38 example udevd-event[22445]: run_program: '/sbin/pam_console_apply /dev/bus/usb/003/005 ' The tricky part is that the device node created for the Palm device won't look any "different" than any other USB device nodes, and a generic rule that says "anything under /dev/bus/usb should be owned by the console user" is probably too broad. Harald, do you see any easy way to do this?
- general write permissions for console users (problem with USB disks) - suid pilot-link only for console users (problem with buffer overflow attacks) - additional helper app called for known product/vendor
Created attachment 153968 [details] udev rules that pilot-link suggests Ok, it looks like there isn't already an easy hook to do this. General write permissions for console users and suid pilot-link only for console users are both no-ops. It looks like an additional helper app is the best solution. In fact, pilot-link might already be trying to do this, because it suggests putting a bunch of rules (attached) in /etc/udev/rules.d. The suggested rules identify all Palm and compatible devices. The GROUP="dialout" line makes me suspect the point of the rules is to get write permission for the console user, but I'm not sure. How about this: have udev call /sbin/pam_console_apply for the specific Palm devices; use the -c option to specify an alternate console.perms file that dictates that the console user should own all device files under /dev/bus/usb. (This would be wrong in the general case, but since these rules will only be used in this specific case that /sbin/pam_console_apply is being applied to a Palm device, this should be ok.) I think it would be cleaner if there were some way to just tell pam_console_apply, "look, I know you don't have this device file in your configuration, but make it owned by the console user with group blah and mode blah." But pam_console_apply doesn't seem to have that ability.
then pilot-link should ship these rules and helper apps.. pam_console_apply is called for _every_ device node. Just put in some config files.
Ok. I'm going to attach three files. They are: /etc/udev/rules.d/60-libpisock.rules This file contains udev rules to match pilot devices. In order to get the console permissions correct, the rules use /sbin/pam_console_apply with a custom console.perms file. (Someone who speaks udev better than I do could probably remove some of the redundancy in this file.) /etc/security/console.perms.pilot-link The console.perms files that /etc/udev/rules.d/60-libpisock.rules uses. /etc/modprobe.d/blacklist-visor This file blacklists the visor driver, so that the kernel won't load it. (I've yet to find a way to make the blacklist take effect other than by rebooting.) If you install all 3 of these files, reboot, and ensure that pilot-link is compiled with native USB support (which is *NOT* the case as of this writing; see bug 236413), then configure jpilot to use "usb:" as the device file to use, everything works. I'm using this configuration right now.
Created attachment 156931 [details] udev rules
Created attachment 156932 [details] console.perms file for /etc/udev/rules.d/60-libpisock.rules
Created attachment 156933 [details] blacklist the visor driver
Created attachment 156934 [details] udev rules Sigh... so much for "autodetecting" the file type. Fixing...
Created attachment 156935 [details] console.perms file for /etc/udev/rules.d/60-libpisock.rules
Created attachment 156936 [details] blacklist the visor driver
Any chance of getting these changes into Fedora Development anytime soon? I've been using it for almost a month, and it Just Works. Note you will need pilot-link compiled with native USB support as well; see bug 236413.
Hello, for now pilot-link package is build with --enable-libusb. The other bug - which is described from comment #34 is in my opinion hal problem and should be fixed by hal -> rassign to hal.
*** Bug 238418 has been marked as a duplicate of this bug. ***
*** Bug 280251 has been marked as a duplicate of this bug. ***
I must respectfully disagree with marking 280251 (https://bugzilla.redhat.com/show_bug.cgi?id=280251) as a duplicate of this bug. I cannot distinguish my problem from that in 280251, both symptoms and work around, _BUT_ in my case, udev creates the /dev entries nearly instantaneously. What appears to be going wrong, is that my Palm Z22 and udev are creating too many entries in /dev, confusing both pilot-xfer and KpilotDaemon, which I use for syncing. In more detail, attaching my Z22 creates /dev/ttyUSB0 and /dev/ttyUSB1, and udev will (apparently non-deterministically) link one or the other to /dev/pilot, which the syncing applications will follow if they are started before I tap the sync button on my Z22. Sadly, when I then tap the sync button, /dev/ttyUSB2 and /dev/ttyUSB3, and udev will move the link from /dev/pilot to one of the new ttyUSB?'s, but the syncing apps are still using whichever of the old ttyUSB?'s the dev/pilot link originally pointed to. If I then cancel the sync on my Z22, the next tap on its sync button creates two more ttyUSB?'s. The workaround that allows me to sync is to first tap the sync button on my Z22, then lickedy-split launch either pilot-xfer or Kpilot from the commandline. As a recent thread on the Fedora list (Getting GPilot and J-Pilot to Play Nice) seems to confirm, the problem probably could be fixed by appropriate udev rules. If someone will give me one each of every extant Palm OS based PDA a/o Smartphone, I would be glad to write the neccessary rules ;).
The two bugs (this one and https://bugzilla.redhat.com/show_bug.cgi?id=280251) are actually complaining about subtly different things. One is a problem with /dev/ttyUSB* and linking the correct node to /dev/pilot, then using a serial port wrapper for a USB connections using the visor driver, that is the thrust of bug 280251. This bug is about the libusb (a much preferred method for syncing) not being configured correctly so the device is not located. If this bug is fixed, and the configuration for any Pilot sync app (GPilot, JPilot etc) is defaulted to an address usb:, then bug 280251 *should* then be redundant because few people will need to use the old method. The problem is that if the visor module is blacklisted, then should someone have a PDA that won't work with libusb for any reason, they will need to comment out the entry in /etc/modprobe.d/blacklist-palm so that the module can load and allow the use of /dev/ttyUSB* and /dev/pilot If anyone disagrees with this, please discuss and explain why :)
Brian, I agree with your assessment; the correct resolution for bug 280251 is to have pilot-tools use libusb instead of the visor kernel module. That's why bug 280251 is a dupe. I can't think of a way someone could have a PDA that won't work with libusb (the device, after all, doesn't know what "stack" is being used on the host PC to talk to it), but if we encounter that situation, the correct course of action would be to attack the problem in libusb, not abandon using libusb for the visor module. I haven't had a chance to check yet... does syncing in F8test2 work correctly (using libusb) out of the box?
(In reply to comment #54) > Brian, I agree with your assessment; the correct resolution for bug 280251 is to have pilot-tools use libusb instead of the visor kernel module. That's why bug 280251 is a dupe. > I can't think of a way someone could have a PDA that won't work with libusb Unfortunately that's not always the case, libusb doesn't work on all devices, see David D's (maintainer of pilot-link, he should know!) comment: http://mail.gnome.org/archives/gnome-pilot-list/2007-September/msg00006.html > (the device, after all, doesn't know what "stack" is being used on the host PC to > talk to it), but if we encounter that situation, the correct course of action > would be to attack the problem in libusb, not abandon using libusb for the visor module. True, but it's useful if the correct udev configuration for using the visor module is present, should it be necessary to drop back to using the visor module. So the fix isn't mutually exclusive.
Even more pointedly, David Desrosiers says in the same e-mail: "No distro should be shipping with Palm libusb enabled by default. They're more than welcome to build their pilot-link/libpisock packages with libusb support, but enabling that iterface by default (i.e. disabling visor in the process), is definitely not something they should be doing. "
Yes, that's true, I forgot about that. In fact I've not yet succeeded in getting my Palm TX to work with libusb (it's given me enough trouble with the visor module method) and I know a fix went into pilot-link 0.12.2 specifically to deal with a problem with the TX and libusb. I can't yet confirm it works for me but I will be trying James' suggested fix to see if it does. Using a network sync is very reliable though, but it means more configuration on the Palm!
(In reply to comment #52) > What appears to be going wrong, is that my Palm Z22 and udev are creating too > many entries in /dev, confusing both pilot-xfer and KpilotDaemon, which I use > for syncing. > > In more detail, attaching my Z22 creates /dev/ttyUSB0 and /dev/ttyUSB1, and udev > will (apparently non-deterministically) link one or the other to /dev/pilot, > which the syncing applications will follow if they are started before I tap the > sync button on my Z22. Sadly, when I then tap the sync button, /dev/ttyUSB2 and > /dev/ttyUSB3, and udev will move the link from /dev/pilot to one of the new > ttyUSB?'s, but the syncing apps are still using whichever of the old ttyUSB?'s > the dev/pilot link originally pointed to. To add to this Joe, for any given Palm device, the correct device node will be either /dev/ttyUSB0 or 1 and it will be fixed for that device (i.e. any Z22 will always need that same device node linked to /dev/pilot) and this will also be the case for where /dev/ttyUSB2 and 3 are created, the correct one will always be /dev/ttyUSB(n+2) where n is 0 or 1 as described above. As an unsubstantiated comment, I think that most USB Palms use /dev/ttyUSB1 these days, but the Tungsten T used /dev/ttyUSB0 for some reason. pilot-link.org may have information on this for all the various Palms/Handsprings/Clies/Zodiacs etc, but I don't have a URI. If udev is linking the wrong /dev/ttyUSB? to /dev/pilot, then that is a bug in the rule or a udev bug, I don't know which. I agree that if the sync application grabs /dev/pilot and subsequently udev moves the /dev/pilot link to point to a different device node, it will fail to work properly. This is why the current advice is not to click the application sync button for a couple of seconds after the hardware sync button is pressed on the Palm, but if udev is slow even this won't help as several different timeouts interact.
Actually, there is some information here: http://www.pilot-link.org/node/111 for Handspring devices http://www.pilot-link.org/node/112 for miscellaneous devices http://www.pilot-link.org/node/113 for Palm and palmOne devices http://www.pilot-link.org/node/114 for Sony devices I hope that's useful
I must respectfully disagree with David Desrosiers in comment 56: if distros don't at least *attempt* to ship with Palm libusb enabled by default, no one is going to be testing it, because the steps to configure libusb by default are beyond what most people are going to take the initiative to do on their own. We currently in the F8 test cycle. IMHO, now would be a *very* good time to enable libusb by default. If it breaks, then simply revert back to the visor module for F8 final, but make sure libusb support is compiled into pilot-tools so that people who don't have problems with libusb have the option to configure it for themselves.
Sync to Palm devices using pilot-link in Fedora 8 is still completely broken (could owner or assignee amend the release tag, please?). Having trawled through bugzilla and mailing lists, what I see are lots of arguments about whether it's a problem in the pilot-link package or the udev package, how broken the visor module is, how libusb would sidestep the problem, how we can't turn libusb on by default yet, etc. etc. These arguments seem kind of pointless, since as it stands Fedora 8 doesn't include a working configuration for EITHER, let alone one enabled in preference to the other! Back in the day, I remember Fedora/Redhat releases where I connected a Palm and it Just Worked - this is a pretty poor state of affairs. Over the last few releases both pilot-link and udev have changed a lot, so there are bound to have been problems inflicted upon each other. It's been a moving target, and this has complicated much of the discussion and bug resolution. Might I suggest the pilot-link package at the very least ships with working configurations for both visor and libusb in /usr/share/pilot-link, and a README to explain how a user might put one configuration or the other in place. Even if the config files are carried in the pilot-link package, we could do with reassurance from udev maintainers that these files destined for /etc/udev/rules.d/ and /etc/security/console.perms.d/ are technically correct. Once we have a consistent and standard set of configs, we can move on to see if there are timing problems etc. between udev and pilot-link. This bug seems to have reasonable configs for libusb attached - would someone udev knowledgeable like to sign them off? Bug #280251 has suggested configurations for visor, and I've attempted to summarise my current understanding in bug #280251 comment #11. But again, it would be useful it a udev maintainer could critique these configs.
Here is a solution for Fedora 8 http://www.harald-hoyer.de/linux/console_acls_for_palm
Test version of pilot-link package - pilot-link-0.12.2-9.fc8 which contains Harald Hoyer solution (thanks for your great help) is build now.
pilot-link-0.12.2-9.fc8 has been pushed to the Fedora 8 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update pilot-link'
This fix is probably responsible for hal-acl-tool segfaulting. Please see bug #411321.
according to the comments it seems to be still there with Fedora 8, so I guess this bug is also there with Fedora 7
I am running with pilot-link-0.12.2-17.fc8 and cannot get anything to happen re: pilot-xfer. I've tried the visor method as well as the libusb method as described in #280251, as well as the harold-hoyer direct modification stuff. No sync, ever. I do get a kernel: usb 3-2: new full speed USB device using uhci_hcd and address 4 kernel: usb 3-2: configuration #1 chosen from 1 choice and then later a kernel: usb 3-2: USB disconnect, address 4 when the hotsync fails. I've tried with gnome-pilot, but all the above is via pilot-xfer. I have no idea what to try next. Is there some extra debugging I can turn on?
Lenny: - what Palm device are you using? - what version of the udev package do you have installed? - does "pilot-xfer -p usb: -l" work as root? - is this a clean install, or might you have some manual configuration left over from previous attempts? These may conflict with the new configs. libusb should work in pilot-link-0.12.2-17.fc8 without any additional config. That you don't get a mention of the visor module in messages is a good sign that the newer pilot-link package has disabled visor. Have you seen README.Fedora in this package?
This is a Sony Clie (SJ20/U)(In reply to comment #68) > Lenny: > - what Palm device are you using? Sony Clie SJ20/U > - what version of the udev package do you have installed? udev-116-3.fc8 > - does "pilot-xfer -p usb: -l" work as root? No, doesn't work as root either. > - is this a clean install, or might you have some manual configuration left over > from previous attempts? These may conflict with the new configs. libusb should > work in pilot-link-0.12.2-17.fc8 without any additional config. This is an upgrade for fc6, and there certainly might be left over config; I've tried to be very careful about exorcising non fc8 packages that were left after the upgrade, and I've checked all the files that I think might be involved (60-libpisock.rules, /usr/share/PolicyKit/policy/pilot-device-file.policy, /usr/share/hal/fdi/policy/10osvendor/20-pda-acl-management.fdi, etc) but there must be something I am missing.... any ideas? > That you don't get a mention of the visor module in messages is a good sign that > the newer pilot-link package has disabled visor. Have you seen README.Fedora in > this package? Yes, visor is blacklisted. I will go through the 'disable libusb' instructions in the readme again and see if that gets me anywhere (didn't have luck with this before). Thanks for the pointers -- if you think of anything I else I can try that might shed some light I'd be happy to give it a whirl.
(In reply to comment #69) > > - what version of the udev package do you have installed? > udev-116-3.fc8 There's a udev update available you'll need - however this "only" fixes a permission problem for non-root problems. Also make sure udev is running - there's a bug which crashes udev the first time only after install (as mentioned in bug #280251). The new PolicyKit configs almost exclusively deal with correctly setting permissions for the logged in user, so if you can't even list the Palm contents as root it may be a problem with libusb in pilot-link itself. What does lsusb say? From a quick browse of the pilot-link source you should get vendor/product ID 0x054c/0x0066. Long term you'll be better served getting libusb to work. But if you decide you need to try using the visor module, check you see visor module output in /var/log/messages and the creation of ttyUSBx devices when you connect the Palm. If it's not even getting that far, this should probably be a separate bug against pilot-link.
when hotsync is active on the clie, I do get Bus 003 Device 006: ID 054c:0066 Sony Corp. Clie PEG-N7x0C/PEG-T425 PalmOS PDA Serial via lsusb. no pilot-xfer love, however, via "pilot-xfer -p usb: -l" (as root or other). The fallback visor mode does work when I follow the pilot-link README.fedora instructions, so that's what I'll use for now. Should I try to debug further with upstream libusb?
(In reply to comment #71) > The fallback visor mode does work when I follow the pilot-link README.fedora > instructions, so that's what I'll use for now. > Should I try to debug further with upstream libusb? Yes, if you can, perhaps you could ask on the pilot-link list whether this device is expected to work with libusb. I note - without fully knowing what it does - that a different Clie model recently had a USB_INIT_SONY_CLIE flag set in the pilot-link USB code to fix timing issues. This is not set for your Clie. Perhaps it's something similar? If you get anywhere (or not!) you might like to file a separate Fedora bug regarding pilot-link libusb compatibility with the Clie SJ20 - it's a bit off-topic here (maybe leave a cross-reference).
If the pilot-link currently in updates-testing works for you (or does not work), consider adding a note and/or a "works for me" (or "doesn't work" as appropriate) on: https://admin.fedoraproject.org/updates/F8/FEDORA-2008-0453 Please only leave short notes, detailed bug reports should go here (or on bug # 280251, depending on what is appropriate).
(In reply to comment #58) > To add to this Joe, for any given Palm device, the correct device node will be > either /dev/ttyUSB0 or 1 and it will be fixed for that device (i.e. any Z22 will > always need that same device node linked to /dev/pilot) and this will also be > the case for where /dev/ttyUSB2 and 3 are created, the correct one will always > be /dev/ttyUSB(n+2) where n is 0 or 1 as described above. As an unsubstantiated > comment, I think that most USB Palms use /dev/ttyUSB1 these days, but the > Tungsten T used /dev/ttyUSB0 for some reason. Actually, not *quite*. If /dev/ttyUSB0 already exists, say for a PocketPC device (yes, I have both PocketPC and Palm devices here) then the Palm device will get the next available ttyUSB? instances. It is true that a given device will always try to Hotsync through the 1st or 2nd of the /dev/ entries that it is assigned, but which /dev/ entries are assigned can never be relied upon. E.g. my Palm TX will normally be assigned /dev/ttyUSB{0,1} and 'talk' Hotsync through /dev/ttyUSB1, however if I've plugged in a PocketPC device beforehand, it will get /dev/ttyUSB{1,2} and so Hotsync on /dev/ttyUSB2. If I disconnect and reconnect I see that /dev/ttyUSB{1,2} are still in use, so the device gets /dev/ttyUSB{3,4} in which case I should Hotsync on ttyUSB4. Udev rules work with many devices for setting the /dev/pilot symlink because those devices always use the *first* of the two visor ttyUSB? entries. Not so for the TX. I have gotten the TX to sync with both command line tools and Gnome-pilot using both visor and libusb but the second method is much more prone to timing problems (chowning the /proc/bus/usb/ entry at the right time)
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. 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 '7'. 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 7'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 7 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. 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. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists. Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs: http://docs.fedoraproject.org/release-notes/ The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 7 changed to end-of-life (EOL) status on June 13, 2008. Fedora 7 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.