I made some more investigations by some klogd debug messages on the console (klogd -c 7). The last messages I get from there are (the third line is specific debug printk output by my code): [...] l2cap_sig_channel: code 0x0b len 4 id 0x02 l2cap_information_rsp: type 0x0002 result 0x01 ident 2 36 03 02 00 l2cap_build_conf_req: sk cf9c2000 l2cap_build_cmd: conn c80b7d00, code 0x04, ident 0x03, len 4 l2cap_send_cmd: code 0x04 scheduling while atomic: swapper/0x00000001/0 [<c030b03d>] schedule+0x9cd/0xd60 l2cap_recv_acldata: conn c80b7d00 len 17 flags 0x2 So it looks like the problem is not directly located within the l2cap_connect_rsp() function where I issue an information request. I guess the problem occurs later after the information response when I try to issue another configuration request. During another test with a bigger file that I tried to send over bluetooth, I got a bunch of those »scheduling while atomic« messages that ran over the screen. I just unplugged the hardware Bluetooth module and after that I got some more messages: Pid: 1845, comm: khubd EIP: 0060:[<c030c6ff>] CPU: 0 EIP is at _spin_lock+0x5f/0x80 EFLAGS: 00200202 Not tainted (2.6.15-23-686) EAX: 00000001 EBX: d1ac842 ECX: ffffff00 EDX: 00000000 ESI: de43e000 EDI: ce5daf40 EBP: de8fa9c0 DS: 007b ES: 007b CR0: 8005003b CR2: 0804d500 CR3: 173d7000 CR4: 00000690 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. Martin -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
