On Thursday, June 08, 2006 at 22:15 +0200, Martin Röhricht wrote:
> So I assume I don't get any information out of the register values,
> right? But what seems to be quite interesting is the message about the
> spin_lock -- so I will investigate further on any calls to spin_locks.
>
> If anybody knows how to solve this issue, feel free to post any
> suggestions.
WOW, I think I fixed it!!!
The preamble: For handling an incoming information response I had major
problems to find the corresponding socket (that I used earlier to
initiate the request) because the fields in an information request in
Bluetooth's L2CAP layer do not provide appropriate information that may
help to retrieve the socket. Finally I found out (some weeks ago) that I
can get the socket by using one of the existing functions:
sk = l2cap_get_chan_by_ident(&conn->chan_list, cmd->ident)
This code worked on a single processor with a non-preemptible kernel as
expected.
Today I found out that this socket gets locked by using this function
call ("if (s) bh_lock_sock(s);"):
static inline struct sock *l2cap_get_chan_by_ident(struct
l2cap_chan_list *l, u8 ident)
{
struct sock *s;
read_lock(&l->lock);
s = __l2cap_get_chan_by_ident(l, ident);
if (s) bh_lock_sock(s);
read_unlock(&l->lock);
return s;
}
And this tiny little line of code caused my kernel to deadlock as I had
to unlock the socket. So I inserted a call
bh_unlock_sock(sk);
at the end of l2cap_information_rsp() and it seems to work and makes
sense to me ;-)
Ufff, that was a nice lesson ...
Martin
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
