Date: Fri, 22 Nov 2002 18:56:21 -0800 From: "Maksim Yevmenkin" <Maksim.Yevmenkin@cw.com> To: "M. Warner Losh" <imp@bsdimp.com> Cc: <vova@sw.ru>, <shizukakudo_99@yahoo.com>, <freebsd-current@FreeBSD.ORG> Subject: RE: Bluetooth questions Message-ID: <45258A4365C6B24A9832BFE224837D552B1264@sjdcex01.int.exodus.net>
next in thread | raw e-mail | index | archive | help
Warner, > In message: <3DDD57A6.7712B1C5@exodus.net> > Maksim Yevmenkin <myevmenk@exodus.net> writes: > : PCCARD: 3COM and Xircom(*). Xircom card is a 16550A > : UART based card and may not work very well because of > : "sio" driver issues. The same is true for any 16550A > : UART based card. However if you can convince your > : system give separate IRQ for PCCARD and "sio" driver > : uses fast interrupts then this card might work well > : for you. I managed to do so on my not so -current > : and OLDCARD. >=20 > What's the issue with non-fast sio interrupts? It works great for me > on current with my 56k modem, modulo the message on boot about using > non-fast interrupt handler. Right now ISA interrupts aren't even > supported in NEWCARD, nor will they be unless there's some real issue > here... I see a lot of "silo overflow" errors under moderate load. As a result bytes get dropped on the floor. The Bluetooth spec defines extremely simple serial protocol (H4). It simply cannot tolerate UARTs that drop bytes. If at least one byte gets dropped the entire HCI frame is lost. If HCI frame gets dropped then "out of sync" condition exist and all bets are off. The only way to get back "in sync" is to send Reset to the device. After Reset device goes into standby state and all operational state is lost.=20 In some cases it is possible to get back "in sync" by just ignoring "broken" HCI frame and trying to pick up the next one. This might work for HCI data frames (however upper layers may not like it), but it does not work for HCI event frames, especially for Number_Of_Completed_Packets event. This event is used for flow control. The stack should not send new packets unless device told it to. So if NOCP event gets dropped the connection is stuck. Thanks, max To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45258A4365C6B24A9832BFE224837D552B1264>