Brad Midgley wrote:
>> Once it gets into this state, all further attempts to bind fail with
>> "Address already in use" ... until I reboot.
>
> if you're using kernel modules, you might be able to unload/reload a
> bluetooth related kernel module to restore it. This would also help
> narrowing down the cause.
The bad news is that I can't unload the sco or bluetooth modules when the
problem occurs because they are allegedly "in use".
The good news is that I have found a combination of circumstances that makes the
problem hard-on rather than intermittent. As a result, I have discovered some
additional symptoms. In addition to the /sys/class/bluetooth/sco file that is
not cleaned-up, there is also a /sys/class/bluetooth/rfcomm file with contents
that correspond to a listen() on a RFCOMM socket. There is also a leftover SDP
entry arising from advertise_service() even after stop_advertising() has been
called.
From what I know of sysfs (learned during the past 24 hours), these entries are
controlled by reference counts, so it looks like the counts are getting screwed
somewhere.
Can anyone suggest where I should start looking?
John.
John,
> Can anyone suggest where I should start looking?
Are you using a recent kernel and bluez? Do you have example code that
will cause the problem? Even better if it is in script like python.
--
Brad Midgley