Re: bluetooth / hcseriald panics -current.

Niki Denev wrote:
> Maksim Yevmenkin writes:
> 
>> Niki,
>>
>> could you please try the following patch?
>>
>> cvs diff: Diffing .
>> Index: ng_h4.c
>> ===================================================================
>> RCS file: /usr/local/cvs/sys/netgraph/bluetooth/drivers/h4/ng_h4.c,v
>> retrieving revision 1.7
>> diff -u -r1.7 ng_h4.c
>> --- ng_h4.c     23 Aug 2004 18:08:15 -0000      1.7
>> +++ ng_h4.c     13 Oct 2004 23:05:34 -0000
>> _at__at_ -209,11 +209,11 _at__at_
>>           * I'm not sure what is appropriate.
>>           */
>>
>> -       ttyflush(tp, FREAD | FWRITE);
>>          clist_alloc_cblocks(&tp->t_canq, 0, 0);
>>          clist_alloc_cblocks(&tp->t_rawq, 0, 0);
>>          clist_alloc_cblocks(&tp->t_outq,
>>                  MLEN + NG_H4_HIWATER, MLEN + NG_H4_HIWATER);
>> +       ttyflush(tp, FREAD | FWRITE);
>>   out:
>>          splx(s); /* XXX */
>>
> 
> it dropped in the debugger again, but the instruction ponter now
> is at sio.c line 2092
> do you need some other info?

stack trace?
what is the version of sio.c?

i'm trying to reproduce it on my system with xircom cbt adapter.

> 
>>
>> btw, you are probably going to have bad experience with serial 
>> bluetooth device. sio(4) driver is know to loose bytes (silo overflow 
>> problem) and this is NOT acceptable in bluetooth.
> 
> is there any hope regarding this problem?

it is (or at least it was last time i looked into this) an interrupt 
latency problem. basically other drivers block interrupts for too long. 
fifo gets overloaded and sio(4) drops chars. another problem is in the 
serial devices themselves. for whatever reason none of the serial 
devices actually looks at the fifo and tries to assert flow control to 
the sender (other bluetooth device) to prevent fifo overflow. i guess it 
is just assumed that cpu is fast enough to drain fifo in time.

max