Hi Marcel, Please read further explanation in the lines below... Thanks, Doron > >> -----Original Message----- > >> From: David Herrmann [mailto:dh.herrmann@xxxxxxxxxxxxxx] > >> 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@xxxxxx> > 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 then > > > CONNECT events with the same handle number. > > > 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. > > > My bug may be related to something else. I will try to investigate > > further but currently don't have time. > > > BR, > > Doron > > > > > I recommend writing your explanation to the list again and CC Marcel. > > > Thanks > > David -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
