Support for Xircom CreditCard Bluetooth adapter?

[Maksim Yevmenkin]

Lukas,

> On Tue, 17 Jun 2003, Lukas Ertl wrote:
> 
> > On Tue, 17 Jun 2003, Maksim Yevmenkin wrote:
> >
> > > > today I got hold of a Xircom CreditCard Bluetooth adapter. When I put
> it
> > >
> > > i have the same card. this is 16550 UART based card. the sio(4) driver
> > > will recognize it as serial port/modem. i can make it work with OLDCARD.
> >
> > Ah, this is good news. The freeze might be related to NEWCARD.
> 
> Yes, it was obviously NEWCARD. An OLDCARD kernel does not freeze anymore.

i had many problems with sio(4) and NEWCARD :( another problem is that
NEWCARD assigns the same shared IRQ to all devices you plug into PCCARD
slot. that is why sio(4) complains about not being able to use "fast 
interrupts". on my laptop the same IRQ gets shared between USB and NIC
in the docking station :(
 
> > > IMPORTANT: due to problems with sio(4) driver (buffer overrun errors
> even
> > > under light load) you probably will not be able to use this card.
> bluetooth
> > > H4 link *must* be reliable. i can only do very limited testing before
> sio(4)
> > > starts complaining about buffer overrun errors and bluetooth links
> becomes
> > > broken.
> >
> > Hm, I'll try it and report my experiences, thanks!
> 
> Well, it seems you're right. First of all, I'm able to connect to my Nokia
> 6310i and initiate a PPP dialup connection with rfcomm_pppd - this really
> rocks! Windows XP wasn't even able to setup the card and install the drivers
> correctly - this must be the first time that I have some hardware that
> is supported by FreeBSD but not by Windows :-)

:) 

> But then, after a few minutes, the connection drops :-/ - it might have to
> do with what you said about sio(4), I get some messages like
> 
> sio4: 1 more silo overflow (total 2)

right - that is exactly the symptoms :( i think it is just plain stupid to
use UARTs as bluetooth transport layer. they are byte oriented, not packet. 
bluetooth spec defines UART transport layer (chapter H4) in a very simple
way. the host (PC) is not allowed to drop even single byte from H4 stream.
if at least one byte is dropped then H4 stream is corrupted and there is no
way to repare it. the spec calls this "ouf of sync" and says that a "reset"
must be sent to the device. that is the only way to get device into "known"
state. "reset" means that device will forget all its operational state, i.e.
baseband connections etc. we do not do it, because in some cases it is
possible to get back "in sync" with the device (i.e. drop entire data packet).
however if you drop HCI event packet (Number_Of_Completed_Packets event in
particular) then you are out of luck :(
 
> Is there anything I can do to assist you in debugging it?

the problem is with sio(4) driver - not bluetooth. it is known problem and
it has been around for a while. interrupt routine is not called fast enough
to drain FIFO, so it overflows. sio(4) driver has the same problem even when
you run ppp(8). of course ppp *was* designed for serial lines and *can*
tolerate dropped bytes. 

i can see two ways:

- fix sio(4) driver to make sure it does not drop bytes

- write special driver for the card. it is basically will be subset of sio(4)
  driver without all extra stuff that sio(4) does (i.e. serial console etc.)
  it also could bypass H4 line discipline and connect directly to the stack
  (just like ng_bt3c(4) driver does).

thanks,
max


__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com