From owner-freebsd-current@FreeBSD.ORG Thu Oct 14 00:02:29 2004 Return-Path: <owner-freebsd-current@FreeBSD.ORG> Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8A24B16A4CE for <current@freebsd.org>; Thu, 14 Oct 2004 00:02:29 +0000 (GMT) Received: from mailgate1b.savvis.net (mailgate1b.savvis.net [216.91.182.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 01BC043D53 for <current@freebsd.org>; Thu, 14 Oct 2004 00:02:29 +0000 (GMT) (envelope-from Maksim.Yevmenkin@savvis.net) Received: from out001.email.savvis.net (out001.apptix.savvis.net [216.91.32.44])i9E01utC016029; Wed, 13 Oct 2004 19:01:56 -0500 Received: from s228130hz1ew03.apptix-01.savvis.net ([10.146.4.28]) by out001.email.savvis.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 13 Oct 2004 19:01:52 -0500 Received: from [10.254.186.111] ([66.35.239.94]) by s228130hz1ew03.apptix-01.savvis.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 13 Oct 2004 19:01:49 -0500 Message-ID: <416DC1E5.1060904@savvis.net> Date: Wed, 13 Oct 2004 17:01:41 -0700 From: Maksim Yevmenkin <maksim.yevmenkin@savvis.net> User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040822 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Niki Denev <nike_d@cytexbg.com> 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> In-Reply-To: <cone.1097710541.778981.578.1001@phobos.totalterror.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Oct 2004 00:01:49.0270 (UTC) FILETIME=[00A18760:01C4B181] X-ECS-MailScanner: No virus is found cc: current@freebsd.org Subject: Re: bluetooth / hcseriald panics -current. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org> List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>, <mailto:freebsd-current-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current> List-Post: <mailto:freebsd-current@freebsd.org> List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help> List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>, <mailto:freebsd-current-request@freebsd.org?subject=subscribe> X-List-Received-Date: Thu, 14 Oct 2004 00:02:29 -0000 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