[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [bluetooth-dev] USB/Stack changes


> > > 4) I get timeouts on pretty much all hci ctrl transfers. This 
> > > is because
> > > the return result and the wake up occur before the sleep 
> > > occurs.  I don't
> > > have a great fix for this yet other than to ignore the 
> > > timeouts since they
> > > are harmless.
> > > 
> > 
> > I don't think we have experienced this problem, however 
> I'll have a look on it.
> The USB interface is probably faster.  Basically you write a 
> command out.
> Before the writing of the command returns, there is an 
> interrupt and the
> event packet is received and processed.  The wakeup occurs, 
> but it hasn't
> gone to sleep yet!  

sounds reasonable, do you have any suggestions on how to solve it in that case ? One way might be to check cmd_num before the write and just before the sleep, if unchanged then the command complete has already occured and a sleep won't be necessary... 

> More stuff:
> 1) What the is up with the trash buffer in the
> WAIT_FOR_ACL_HDR?  Because the trash buffer is picked up, the
> in_buf->buf_ptr is then NULL and the memcpy freezes the machine.  This
> took my FOREVER to find.  I commented it out which fixes the 
> problem.  I
> am a little suprised that the stack works at all! :)  This bug occurs
> anytime you have a mutlipart l2cap message.

I know... we found that a couple of days ago aswell but wanted to wait until the next release of the stack (today), I guess most people are running ericsson HW using 800 bytes packets thus no fragmentation was done... :)

> 2) How do you detect tty_hangup on the lower tty?  For 
> instance I unplug
> the usb device and a disconnection occurs.  This hangs up the 
> lower tty.
> This SHOULD somehow trigger a hangup on the upper tty, which 
> then closes
> pppd. Any thoughts?

For example in the serial driver which currently is used with the stack.

do_serial_hangup() is called from the scheduler tqueue when the interrupt routine has signalled that a hangup has occurred.  The path of hangup processing is:
  	serial interrupt routine -> (scheduler tqueue) ->
 	do_serial_hangup() -> tty->hangup() -> do_tty_hangup()	-> rs_hangup()

In do_tty_hangup flush_buffer and close are called upon the driver (serial driver) and the line discipline (BT stack)
Then SIGHUP is sent to pppd which will terminate...

This means that it is the physical transport driver that is responsible of calling tty_hangup(), in your case the USB driver,
or am I wrong ?

These parts are something that we'd appreciate all the help we can get, do you have any other stuff that you may want to comment ?


> ----                                                          
> Mark Douglas Corner                                      
> mcorner@xxxxxxx.edu