Tiny Core Linux
Tiny Core Extensions => TCE Q&A Forum => Topic started by: dentonlt on October 04, 2009, 08:18:14 AM
-
Hey there - I'm hoping that curaga will be browsing by to catch a usb-utils question.
I'm trying to get pilot-xfer (http://www.pilot-link.org/) working on my TC installation. I previously had it running on TC + HP Evo N410c and it was perfect. It doesn't play nice on my netbook (HP Mini 1001), however ... so I think it has to do with the USB hardware on this laptop.
I have an intermittent bug - pilot-xfer locks up at random places, random times. I've been through the pilot-xfer code quite a lot, and the best I can pin down is that my hardware doesn't like disconnecting from the Palm. Most of the time, pilot-xfer just locks up after finishing its work (backup/sync fine), but it doesn't like to close up. It doesn't seem to crash out in a consistent place in the pilot-xfer code, so I think it depends upon when the usb disconnects. Frankly, I'm at a loss since the target keeps moving. :-\
I've caught a usb segfault just once in dmesg:
usb 2-1: new full speed USB device using uhci_hcd and address 6
usb 2-1: configuration #1 chosen from 1 choice
usb 2-1: USB disconnect, address 6
lt-pilot-xfer[12410]: segfault at 0 ip b7f5a49f sp bffb47b4 error 4 in libusb-0.1.so.4.4.4[b7f59000+3000]
usb 2-1: new full speed USB device using uhci_hcd and address 7
usb 2-1: configuration #1 chosen from 1 choice
usb 2-1: USB disconnect, address 7
lsusb shows the following when my Palm is connected:
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 10f1:1a08
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 023: ID 0830:0060 Palm, Inc. Tungsten C/E/T/T2/T3 / Zire 71
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 002: ID 13d3:3249 IMC Networks
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
And lsusb shows this when my Palm disconnects:
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 10f1:1a08
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 002: ID 13d3:3249 IMC Networks
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
The whole pilot-link suite compiles nicely provided compiletc and usb-utils. I'm using the options from the wiki:
export CFLAGS="-march=i486 -mtune=i686 -Os -pipe"
export CXXFLAGS="-march=i486 -mtune=i686 -Os -pipe -fno-exceptions -fno-rtti"
export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:/usr/lib/pkgconfig
And I've run ./configure with a slew of different combinations to try stumbling upon a solution. No luck. Currently using:
./configure --enable-conduits --enable-libusb --enable-threads --disable-libtool-lock --disable-debug --prefix=/usr/local
Then I make, make DESTDIR=/tmp/pkg install.
I'm at a loss. I've compiled/used pilot-xfer on TC with different hardware no problem, and other distros no problem. I don't know why this one is odd! Any advice for where/how to find out what's wrong? Palm OS is aging hardware, I know, but it's still a great use.
I can hobble through as is, but it's extension-ready if this has a fix. TIA.
-
lt-pilot-xfer[12410]: segfault at 0 ip b7f5a49f sp bffb47b4 error 4 in libusb-0.1.so.4.4.4[b7f59000+3000]
I believe libusb-0.1.so.4.4.4 is the wrapper that makes libusb-1.x look like libusb-0.x - maybe this is the cause of the problem?
You could try libusb-1.x without the wrapper or the legacy libusb-0.1.12?
-
There have been updates to all three components of the usb-utils extension, they might have fixed the bug. Also, the segfault was within libusb, so the pilot-link code might be just fine.
I suggest first running pilot-xfer inside gdb, built with debug options. It might be necessary to do the same to libusb to get meaningful output, but try first.
-
I played around with the latest versions of the usb stuff:
libusb-0.1.12 - legacy libusb
libusb-1.0.3 - new libusb
libusb-compat-0.1.3 - makes new libusb look like legacy libusb
usbutils-0.86 - depends on libusb-legacy or libusb+libusb-compat
I guess it would make sense to make two extensions:
libusb = libusb+libusb-compat
usb-utils
I don't see much point in a libusb-legacy
comments?
-
Thanks for the assistance. I'm testing again now (running with gdb) and will get back with details when I have them.
Personally, I'm fine with usbutils+libusb as one extension right now ... unless I find that I need them separated to get this working! :P
EDIT:
It seems that there is a problem exiting one of the threads (LWP) that take care of usb connect/disconnect. The thread library doesn't seem to have debugging info, though ... gdb says:
Cannot initialize thread debugging library: Versions of libpthread and libpthread_db do not match
I'm working out how to make that happen. I'll keep digging, but it's slow going for now.
I also took time to run/gdb the same under Xubuntu (same hardware), and I can't make it crash. I figure that means it can be worked out somehow.
EDIT:
Built libusb w/ debugging info. pilot-xfer locks up just after libusb connection close ... of course, I haven't figured out exactly why yet.
EDIT:
Ah ... it locks when calling usbi_remove_pollfd. I'll have to set this aside and revisit.
-
the latest libusb is now posted in libusb.tczl if you'd like to try with this.
-
Juanito - thanks for that (libusb.tczl). Unfortunately, problem persists. I rebooted into base, built using only compiletc and the new libusb.tczl. Builds fine, but has the same problem :-\
I'll keep at it. Current plan is to figure out how to get the threading libs to match, then I can debug down to the right spot. At least that's the plan ...
-
EDIT:
It seems that there is a problem exiting one of the threads (LWP) that take care of usb connect/disconnect. The thread library doesn't seem to have debugging info, though ... gdb says:
Cannot initialize thread debugging library: Versions of libpthread and libpthread_db do not match
Looks like the extension is from 1.x. It contains the older library and needs to be updated.
-
I have still been working on this, albeit slowly. The pilot-link.org site is down (perhaps indefinitely), so I have nowhere to post questions.
In the end, I don't believe it is the libusb or libusb compatibility code. Pilot-tools has its own file libusb.c, and so the debug output gets confusing against the libusb library debug output ...
Anyhow, two bugs found in pilot-link thus far:
./configure uses HAVE_PTHREADS, should read HAVE_PTHREAD
/libpisock/libusb uses PTHREAD_CANCEL_ASYNCHRONOUS, which is probably causing the lock-up when closing the connection ... testing with PTHREAD_CANCEL_DEFERRED
If I can get this going reliably, I'll post an extension.
-
Completed updating pilot-link-0.12.4 to support libusb-1.0. Now works well - I'll submit an extension.
The pilot-link project will probably produce no more updates (it supports rather old, though effective hardware). I've mentioned to the maintainer that I made these changes, but there is nowhere to formally submit them to that project. I'll post them at my own site and mention this in the extension's info file.
-
The best way would probably be to submit those changes/src along with the extension.
-
Done as suggested - thanks for the help on this one.