This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/osmocom-sdr@lists.osmocom.org/.
Christian Gagneraud chris at techworks.ieOn 07/08/12 15:49, Peter Stuge wrote: > Christian Gagneraud wrote: >> Please find attached the full log. > > Thanks! > > >> I can provide u with a simple python program, but it will depends >> on gnuradio, gr-osmosdr and you will need a compatible device >> plugged in as well. > > No problem, but I think I find the problem. > > >> libusb: 0.783771 debug [libusb_handle_events_timeout_completed] doing our own event handling >> libusb: 0.783793 debug [handle_events] poll() 3 fds with timeout in 1000ms >> libusb: 0.783811 debug [libusb_release_interface] interface 0 >> libusb: 0.785853 debug [handle_events] poll() returned 1 > > The above lines show that the interface is released while event > handling is still running. The destructor was called while the IO > thread is running, and the destructor does cancel all IO, but it only > waited 200 ms for the IO to complete, before it went on to close > everything. Please try the attached patch for gr-osmosdr. > > This may or may not be the appropriate fix. This should perhaps be > fixed inside rtl-sdr, or even libusb (we're already considering it) > instead. It doesn't fix the problem alone. The script simply never exits. I've just sent a patch for rtl-sdr that fix the issue. I think it's still possible that a call to join() could block the app forever, so maybe a longer timeout would be safer here. As well the same apply for the osmosdr wrapper code. Chris > > > //Peter > -- Christian Gagneraud, Embedded systems engineer. Techworks Marine 1 Harbour road Dun Laoghaire Co. Dublin Ireland Tel: + 353 (0) 1 236 5990 Web: http://www.techworks.ie/