Hi Marcel, Max, the list

I have a "buggy" user-space program (attached, careful - it IS buggy:-)), 
communicating over rfcomm, that quite often hangs itself in the 
uninterruptible (D) state.

Ok, the program IS buggy, but, I think, it shouldn't hang in "D" and 
render the entire Bluetooth subsystem unusable?

How: it forks, the child tries to connect to a non-existing peer, at this 
time the parent issues ioctl(HCIDEVDOWN); ioctl(HCIDEVUP); the DOWN wakes 
the child up and it dows ioctl(HCIDEVDOWN) too. That's it. On the 
USB-analyser I see an incomplete HCI Reset, interrupted by the "Read local 
supported features" - from the UP. (screenshot attached)

The question is, of course, where (apart from the program) is the bug? I 
have to say, that the bluletooth module is connected to an "unsupported" 
USB controller, the driver for which I am debugging. I thought, naturally, 
that the bug is there. But now I am not sure. Is this really the case? If 
yes, what might it be doing wrong? Or is it rfcomm?

Thanks
Guennadi
---------------------------------
Guennadi Liakhovetski, Ph.D.
DSA Daten- und Systemtechnik GmbH
Pascalstr. 28
D-52076 Aachen
Germany