Date: Wed, 13 Oct 2004 17:01:41 -0700 From: Maksim Yevmenkin <maksim.yevmenkin@savvis.net> To: Niki Denev <nike_d@cytexbg.com> Cc: current@freebsd.org Subject: Re: bluetooth / hcseriald panics -current. Message-ID: <416DC1E5.1060904@savvis.net> In-Reply-To: <cone.1097710541.778981.578.1001@phobos.totalterror.net> References: <cone.1097691798.355655.4951.1001@niked.office.suresupport.com> <cone.1097705266.944205.768.1001@phobos.totalterror.net> <416DB569.4010805@savvis.net> <cone.1097710541.778981.578.1001@phobos.totalterror.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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 >> @@ -209,11 +209,11 @@ >> * 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?416DC1E5.1060904>