FW: [PATCH] Bluetooth-next: Add incremental indexing in sysfs HCI connection name.

* FW: [PATCH] Bluetooth-next: Add incremental indexing in sysfs HCI connection name.
@ 2011-08-28 15:16 Keren, Doron
  2011-08-29 13:23 ` etsang
  0 siblings, 1 reply; 2+ messages in thread
From: Keren, Doron @ 2011-08-28 15:16 UTC (permalink / raw)
  To: linux-bluetooth; +Cc: Marcel Holtmann, Ilia, Kolominsky, Hadar, Amir

Hi Marcel,

Please read further explanation in the lines below...

Thanks,
Doron

> >> -----Original Message-----
> >> From: David Herrmann [mailto:dh.herrmann@googlemail.com]
> >> Sent: Thursday, August 18, 2011 3:38 PM
> >> To: Keren, Doron
> >> Subject: Re: [PATCH] Bluetooth-next: Add incremental indexing in sysfs
> HCI
> >> connection name.
> >>
> >> Hi Doron
> >>
> >> On Thu, Aug 18, 2011 at 2:25 PM, Keren, Doron <doronkeren@ti.com>
> wrote:
> >> > Hi David,
> >> >
> >> > Please write how did you reproduce the scenario?
> >> > I'm repeating the scenario by connecting to HID keyboard (Logitech).
> >> > After the connection I'm pulling out the HID device batteries and
> >> > Return the batteries fast before any Bluetooth timeout. Even with
> this
> >>
> >> I use a bluetooth HID device, shut it down and reconnect. The bug
> >> triggers quite randomly so I can't tell when it happens. It doesn't
> >> matter what device I use.
> >>
> >> > Action it takes several times (~up to 10) to cause the kernel panic.
> >> > My fix solves this kernel panic.
> >>
> >> I still get kernel panics. I don't get the sysfs-oops anymore, but
> >> hidp_add_connection() still fails. As it happens quite randomly, I
> >> can't reproduce it.
> >>
> >> > Regards,
> >> > Doron
> >>
> >> Cheers
> >> David
> >
> > I got the kernel panic before the fix, when the
> "hci_conn_complete_evt()"
> > comes and call "hci_conn_add_sysfs()", before the "hidp_session()"
> finished
> > and call "hci_conn_del_sysfs()".
> > The HID device reconnects when the HID session waits for the 2 L2CAP
> > channels delete event.
> > The base-band is getting the reconnect attempt and because it is the
> same
> > device that is still connected, it sends immediately DISCONNECT and the=
n
> > > CONNECT events with the same handle number.
>=20
> > Why didn't you write that in your first email? ;) I now understand the
> > issue. New connections are added in atomic-context, but the removal of
> > old connections may sleep, so new connections may be initiated even
> > though the removal of the old is still in progress. Locking doesn't
> > apply here so a counter is the only way.
>=20
> > My bug may be related to something else. I will try to investigate
> > further but currently don't have time.
>=20
> > BR,
> > Doron
> >
>=20
> > I recommend writing your explanation to the list again and CC Marcel.
>=20
> > Thanks
> > David

^ permalink raw reply	[flat|nested] 2+ messages in thread