[lkml]   [2013]   [Dec]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [REGRESSION] rfcomm (userland) broken by commit 29cd718b
On Fri, Dec 13, 2013 at 12:35:26AM +0100, Alexander Holler wrote:
> Am 12.12.2013 21:36, schrieb Peter Hurley:
> >> What currently happens is that when one kills rfcomm (and any other
> >> terminal which might use that tty), the entry in /dev doesn't
> >> disappear. That means the same call to refcomm with the same device
> >> (e.g. [/dev/]rfcomm1 doesn't work.
> >
> > Thanks for the report, Alexander.
> >
> > Point 4 above details a different situation; something else is
> > happening.
> >
> > Would you please detail the necessary steps to reproduce this regression?
> > (How do you 'kill' rfcomm? etc. Shell command lines would be best.)
> Just call
> rfcomm connect rfcomm9 01:23:45:67:89:ab
> wait until the connection happened (a message will appear) and then
> press ctrl-c. This still terminates the bluetooth connection, but the
> device in /dev is now left.

Yes I'm able to reproduce the regression which is indeed caused by that

However I'm puzzled. Surely there is a fifth case I didn't cover because
when rfcomm_dev_state_change() is called, the tty_port is there but the tty is
not, and therefore I cannot get a reference to it and send the HUP.

I'll let you know when I have something working.

> Regards,
> Alexander Holler

 \ /
  Last update: 2013-12-15 13:01    [W:0.079 / U:0.360 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site