Re: Bluetooth questions
On Fri, 22 Nov 2002, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Maksim Yevmenkin [EMAIL PROTECTED] writes: : : In message: [EMAIL PROTECTED] : Maksim Yevmenkin [EMAIL PROTECTED] writes: : : 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. : : OK. That makes sense. Part of the problem even with even fast : interrupt handlers is that interrupts are masked for way way too much : code in -current, as compared to -stable. What baud rate are you : running at? I'm running at 56k, which isn't the full datarate for : 115200 baud that could be used. Even with a fast interrupt, you'd get : SIO overflows in current, at least according to some reports. 56k is a silly speed to use. Why not use the normal speed of 57600 bps or the faster speed of 115200 bps? I haven't got around to updating the 57600 in the example in /etc/rc.serial although this example became bad about 7 years ago just before 56k modems became normal. IIRC, I only had a 14400 bps modem when I wrote the example. I haven't noticed many problems with the fast interrupt handler case. External interrupt latency is certainly pessimized by 500% or so, and non-i/o internal overheads are pessimized by 200% or so, but i/o overheads are still dominant on anything faster than a 486 or maybe a Pentium-1. For the non-fast interrupt case, part of the problem is that the interrupt handler is not marked MPSAFE although it probably is MPFSAFE, so it has the same latency problems as most other interrupt handlers -- almost everything is blocked by Giant, and Giant can easily be held for 10 msec or so (e.g., in the mii tick code when it is run as a non-MPSAFE timeout). In RELENG_4, non-fast tty interrupts are only blocked by spltty(), so the latency problems are mostly isolated to a few low-quality drivers (e.g., syscons normally busy-waits for several msec in its tty interrupt handler to program LEDs). : everything is set to 115200, but i think the hardware does : something funny with the divisor and internal rate is much : higher. with OLDCARD i managed to run Xircom card with fast : interrupts and acually got about 50 KBytes/sec. USB devices : give me about 60KBytes/sec. Does the hardware also do something funny with the input fifo size (which would make it non-16550 compatible)? Speeds faster than the nominal speed break things even if the interrupt handler can keep up, by generating more input than fits in buffers in upper layers. Fifos larger than the nominal size may break flow control in related ways. But silo overflows mean problems at the interrupt layer. OLDCARD on -current? Chances are there's either an 8x the normal or 'custom'. With the settings on current, Let's assume a 8x is 921600 baud. That means that each bit is 1us, so each byte is 10us (1 start + 8 bits + 1 stop). The FIFO is 16 bytes (unless this part is a 16650 or something like that), which is set to go off at MEDH, which is 8 bytes from empty. This puts the upper bound of interrupt latency at 80us or so. This should work for the fast interrupt case even on a 486/33, since it's the same as for 1x with an unbuffered UART which worked fine in FreeBSD-1.x (for 2 ports 4 with 4 data streams and 4 * 11520 interrupts/second). However, the pessimizations since FreeBSD-1.x make probably make this marginal at best even with 1 port, and DMA can easily block ISA accesses and increase latency to much more than 80 usec (160-200 usec seems to be a normal upper bound on PCI latency when PCI timers ares slightly misconfigured). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Bluetooth questions
In message: [EMAIL PROTECTED] Maksim Yevmenkin [EMAIL PROTECTED] writes: : : In message: [EMAIL PROTECTED] : Maksim Yevmenkin [EMAIL PROTECTED] writes: : : 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. : : OK. That makes sense. Part of the problem even with even fast : interrupt handlers is that interrupts are masked for way way too much : code in -current, as compared to -stable. What baud rate are you : running at? I'm running at 56k, which isn't the full datarate for : 115200 baud that could be used. Even with a fast interrupt, you'd get : SIO overflows in current, at least according to some reports. : : everything is set to 115200, but i think the hardware does : something funny with the divisor and internal rate is much : higher. with OLDCARD i managed to run Xircom card with fast : interrupts and acually got about 50 KBytes/sec. USB devices : give me about 60KBytes/sec. OLDCARD on -current? of course :) my code for -current only. Chances are there's either an 8x the normal or 'custom'. With the settings on current, Let's assume a 8x is 921600 baud. That means that each bit is 1us, so each byte is 10us (1 start + 8 bits + 1 stop). The FIFO is 16 bytes (unless this part is a 16650 or something like that), which is set to go off at MEDH, which is 8 bytes from empty. This puts the upper bound of interrupt latency at 80us or so. you are right. it is probably 921600 baud as maximal Bluetooth link speed si 723.2 kbit/s. i also do recall someone from CSR (Bluetooth chip manufacturer) said that they have cards with 1.5 mbit UARTs and have no problem at all. another problem here is that UART based cards do not implement flow control, i.e. when RX FIFO is full the card does not assert flow control to remote peer to say i'm full. it just *assumed* that PC should be fast enough to get data out of RX FIFO before it overflows :( Uggg. It looks like I gotta find a way to have ISA interrupts work, even with NEWCARD... :-( looks like it. max To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Bluetooth questions
On Fri, 22 Nov 2002, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Maksim Yevmenkin [EMAIL PROTECTED] writes: : : In message: [EMAIL PROTECTED] : Maksim Yevmenkin [EMAIL PROTECTED] writes: : : 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. : : OK. That makes sense. Part of the problem even with even fast : interrupt handlers is that interrupts are masked for way way too much : code in -current, as compared to -stable. What baud rate are you : running at? I'm running at 56k, which isn't the full datarate for : 115200 baud that could be used. Even with a fast interrupt, you'd get : SIO overflows in current, at least according to some reports. 56k is a silly speed to use. Why not use the normal speed of 57600 bps or the faster speed of 115200 bps? I haven't got around to updating the 57600 in the example in /etc/rc.serial although this example became bad about 7 years ago just before 56k modems became normal. IIRC, I only had a 14400 bps modem when I wrote the example. I haven't noticed many problems with the fast interrupt handler case. External interrupt latency is certainly pessimized by 500% or so, and non-i/o internal overheads are pessimized by 200% or so, but i/o overheads are still dominant on anything faster than a 486 or maybe a Pentium-1. For the non-fast interrupt case, part of the problem is that the interrupt handler is not marked MPSAFE although it probably is MPFSAFE, so it has the same latency problems as most other interrupt handlers -- almost everything is blocked by Giant, and Giant can easily be held for 10 msec or so (e.g., in the mii tick code when it is run as a non-MPSAFE timeout). In RELENG_4, non-fast tty interrupts are only blocked by spltty(), so the latency problems are mostly isolated to a few low-quality drivers (e.g., syscons normally busy-waits for several msec in its tty interrupt handler to program LEDs). : everything is set to 115200, but i think the hardware does : something funny with the divisor and internal rate is much : higher. with OLDCARD i managed to run Xircom card with fast : interrupts and acually got about 50 KBytes/sec. USB devices : give me about 60KBytes/sec. Does the hardware also do something funny with the input fifo size (which would make it non-16550 compatible)? Speeds faster than the nominal speed break things even if the interrupt handler can keep up, by generating more input than fits in buffers in upper layers. Fifos larger than the nominal size may break flow control in related ways. But silo overflows mean problems at the interrupt layer. i do not think so. the card seem to have onboard memory of at least 512 bytes, because it re-assembles baseband packes and send them back to me in 512 bytes chunks. so it seems baseband puts bytes into memory buffer and then card feeds the bytes to PC via UART. i've never seen a tty buffer overflow messages. long time ago i wrote TTY driver for Granch serial card (for 4.x) and i'm pretty sure the card was doing 2mbit/s (its max speed) without any problem. BTW -current has driver for it. it is called if_sbni (i think). but if_sbni driver is a network one (from card manufacturer) and a little bit slower then serial one (because of overflow on Ethernet checksum etc.). OLDCARD on -current? Chances are there's either an 8x the normal or 'custom'. With the settings on current, Let's assume a 8x is 921600 baud. That means that each bit is 1us, so each byte is 10us (1 start + 8 bits + 1 stop). The FIFO is 16 bytes (unless this part is a 16650 or something like that), which is set to go off at MEDH, which is 8 bytes from empty. This puts the upper bound of interrupt latency at 80us or so. This should work for the fast interrupt case even on a 486/33, since it's the same as for 1x with an unbuffered UART which worked fine in FreeBSD-1.x (for 2 ports 4 with 4 data streams and 4 * 11520 interrupts/second). However, the pessimizations since FreeBSD-1.x make probably make this marginal at best even with 1 port, and DMA can easily block ISA accesses and increase latency to much more than 80 usec (160-200 usec seems to be a normal upper bound on PCI latency when PCI timers ares slightly misconfigured). it worked for me on -current :) max To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Bluetooth questions
In message: [EMAIL PROTECTED] Bruce Evans [EMAIL PROTECTED] writes: : 56k is a silly speed to use. Why not use the normal speed of 57600 : bps or the faster speed of 115200 bps? I haven't got around to updating : the 57600 in the example in /etc/rc.serial although this example became : bad about 7 years ago just before 56k modems became normal. IIRC, I : only had a 14400 bps modem when I wrote the example. I've used a 56k modem, which doesn't give a sustained speed higher than about 56k :-). That's what I ment. : For the non-fast interrupt case, part of the problem is that the : interrupt handler is not marked MPSAFE although it probably is MPFSAFE, : so it has the same latency problems as most other interrupt handlers : -- almost everything is blocked by Giant, and Giant can easily be held : for 10 msec or so (e.g., in the mii tick code when it is run as a : non-MPSAFE timeout). In RELENG_4, non-fast tty interrupts are only : blocked by spltty(), so the latency problems are mostly isolated to : a few low-quality drivers (e.g., syscons normally busy-waits for : several msec in its tty interrupt handler to program LEDs). I'll have to try that. : : everything is set to 115200, but i think the hardware does : : something funny with the divisor and internal rate is much : : higher. with OLDCARD i managed to run Xircom card with fast : : interrupts and acually got about 50 KBytes/sec. USB devices : : give me about 60KBytes/sec. : : Does the hardware also do something funny with the input fifo size : (which would make it non-16550 compatible)? Speeds faster than the : nominal speed break things even if the interrupt handler can keep up, : by generating more input than fits in buffers in upper layers. Fifos : larger than the nominal size may break flow control in related ways. : But silo overflows mean problems at the interrupt layer. Most of the 16650, 16750 and 16850 chips require special care to enable the larget fifo, iirc, so that the compatibility problems don't happen. You are right about the buffer sizes in the intermeidate layers being sized for bursts of 16 bytes, not bursts of, say, 100 bytes. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Bluetooth questions
On Sat, 23 Nov 2002, M. Warner Losh wrote:
In message: [EMAIL PROTECTED]
Bruce Evans [EMAIL PROTECTED] writes:
: 56k is a silly speed to use. Why not use the normal speed of 57600
: bps or the faster speed of 115200 bps? I haven't got around to updating
: the 57600 in the example in /etc/rc.serial although this example became
: bad about 7 years ago just before 56k modems became normal. IIRC, I
: only had a 14400 bps modem when I wrote the example.
I've used a 56k modem, which doesn't give a sustained speed higher
than about 56k :-). That's what I ment.
Burst rates can be higher though.
: For the non-fast interrupt case, part of the problem is that the
: interrupt handler is not marked MPSAFE although it probably is MPFSAFE,
: so it has the same latency problems as most other interrupt handlers
: -- almost everything is blocked by Giant, and Giant can easily be held
: for 10 msec or so (e.g., in the mii tick code when it is run as a
: non-MPSAFE timeout). In RELENG_4, non-fast tty interrupts are only
: blocked by spltty(), so the latency problems are mostly isolated to
: a few low-quality drivers (e.g., syscons normally busy-waits for
: several msec in its tty interrupt handler to program LEDs).
I'll have to try that.
I use this, but haven't actually tested the non-fast case. In theory
things should just work the locking requirements for fast interrupt
handlers are stronger than Giant.
Index: sio.c
===
RCS file: /home/ncvs/src/sys/dev/sio/sio.c,v
retrieving revision 1.382
diff -u -2 -r1.382 sio.c
--- sio.c 11 Oct 2002 20:22:20 - 1.382
+++ sio.c 17 Oct 2002 20:18:53 -
@@ -1117,5 +1146,6 @@
if (ret) {
ret = BUS_SETUP_INTR(device_get_parent(dev), dev,
-com-irqres, INTR_TYPE_TTY,
+com-irqres,
+INTR_TYPE_TTY | INTR_MPSAFE,
siointr, com, com-cookie);
if (ret == 0)
: Does the hardware also do something funny with the input fifo size
: (which would make it non-16550 compatible)? Speeds faster than the
: nominal speed break things even if the interrupt handler can keep up,
: by generating more input than fits in buffers in upper layers. Fifos
: larger than the nominal size may break flow control in related ways.
: But silo overflows mean problems at the interrupt layer.
Most of the 16650, 16750 and 16850 chips require special care to
enable the larget fifo, iirc, so that the compatibility problems don't
happen.
They are enabled by driver flags which should only be used if they help
since they driver doesn't really understand them and at least the original
16650 has broken-as-designed hardware flow control. T he driver doesn't
understand its brokenness and enables it, unlike the Linux driver which
at least used to ignore the possiblility of hardware flow control. The
brokenness is that flow control is invoked when the input fifo trigger
level is reached, so throughput is degraded if the sender actually notices
the flow control in time, and the senders time is wasted by unnecessary
interrupts for flow control.
You are right about the buffer sizes in the intermeidate
layers being sized for bursts of 16 bytes, not bursts of, say, 100
bytes.
Actually, they are sized for bursts related to hz without any knowledge
of the burst size. Setting hz to a large value gives interrupt-level
buffers of size 128 (it would be lower but is clamped to 128, which
more or less corresponds to clamping the timeout period to 1/200 (not
1/hz)). 128 works OK if and only the driver's SWI isn't blocked (by
Giant?) for too long and the burst length is significantly less than
128. Using the default hz gives interrupt-level buffer sizes of 512
at 115200 bps and 256 at 57600 bps so there is more slop for large
fifos.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Bluetooth questions
Shizuka Kudo wrote: --- Maksim Yevmenkin [EMAIL PROTECTED] wrote: 2. If I loaded netgraph, ng_ubt at loader prompt and had the dongle plugged in already, the system failed to attach. I could, however, un-plug then re-insert the dongle to make the driver attached successfully. hmm... i have not tried that. will try today. i have kernel compiled with 'options NETGRAPH'. everything works just fine if i load ng_ubt from loader prompt and boot with dongle attached. I tried complying kernel with 'options NETGRAPH' and loading ng_ubt at loader prompt. However, I still saw the same behaviour. I even tried without ACPI with no luck. you are right :( i tried it and it dit not work either. the problem is that Netgraph node type is not registered yet and ng_make_node_common() is failing with EINVAL. i will try to make a path for you this weekend. hmm... device was detected but driver failed to create Netgraph node. i wonder if it is an ordering issue. perhaps Netgraph was not initialized at this point yet? thanks, max To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Bluetooth questions
In message: [EMAIL PROTECTED] Maksim Yevmenkin [EMAIL PROTECTED] 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. 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... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Bluetooth questions
Warner, In message: [EMAIL PROTECTED] Maksim Yevmenkin [EMAIL PROTECTED] 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. 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. 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 [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Bluetooth questions
In message: [EMAIL PROTECTED] Maksim Yevmenkin [EMAIL PROTECTED] writes: : 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. OK. That makes sense. Part of the problem even with even fast interrupt handlers is that interrupts are masked for way way too much code in -current, as compared to -stable. What baud rate are you running at? I'm running at 56k, which isn't the full datarate for 115200 baud that could be used. Even with a fast interrupt, you'd get SIO overflows in current, at least according to some reports. Hmmm, maybe I should get one of these cards, or one a normal sio cards and run them at 115200 baud. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Bluetooth questions
In message: [EMAIL PROTECTED] Maksim Yevmenkin [EMAIL PROTECTED] writes: : 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. OK. That makes sense. Part of the problem even with even fast interrupt handlers is that interrupts are masked for way way too much code in -current, as compared to -stable. What baud rate are you running at? I'm running at 56k, which isn't the full datarate for 115200 baud that could be used. Even with a fast interrupt, you'd get SIO overflows in current, at least according to some reports. everything is set to 115200, but i think the hardware does something funny with the divisor and internal rate is much higher. with OLDCARD i managed to run Xircom card with fast interrupts and acually got about 50 KBytes/sec. USB devices give me about 60KBytes/sec. Hmmm, maybe I should get one of these cards, or one a normal sio cards and run them at 115200 baud. good idea. thanks, max To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Bluetooth questions
In message: [EMAIL PROTECTED] Maksim Yevmenkin [EMAIL PROTECTED] writes: : : In message: [EMAIL PROTECTED] : Maksim Yevmenkin [EMAIL PROTECTED] writes: : : 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. : : OK. That makes sense. Part of the problem even with even fast : interrupt handlers is that interrupts are masked for way way too much : code in -current, as compared to -stable. What baud rate are you : running at? I'm running at 56k, which isn't the full datarate for : 115200 baud that could be used. Even with a fast interrupt, you'd get : SIO overflows in current, at least according to some reports. : : everything is set to 115200, but i think the hardware does : something funny with the divisor and internal rate is much : higher. with OLDCARD i managed to run Xircom card with fast : interrupts and acually got about 50 KBytes/sec. USB devices : give me about 60KBytes/sec. OLDCARD on -current? Chances are there's either an 8x the normal or 'custom'. With the settings on current, Let's assume a 8x is 921600 baud. That means that each bit is 1us, so each byte is 10us (1 start + 8 bits + 1 stop). The FIFO is 16 bytes (unless this part is a 16650 or something like that), which is set to go off at MEDH, which is 8 bytes from empty. This puts the upper bound of interrupt latency at 80us or so. Uggg. It looks like I gotta find a way to have ISA interrupts work, even with NEWCARD... :-( Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Bluetooth questions
Hi all, I just cvsup-ed in the latest Bluetooth stack and rebuild world/kernel. My bluetooth USB dongle attached OK except with the following issue observed 1. The Mitsumi USB driver attached OK after I manually loaded ng_ubt and plugged in the dongle 2. If I loaded netgraph, ng_ubt at loader prompt and had the dongle plugged in already, the system failed to attach. I could, however, un-plug then re-insert the dongle to make the driver attached successfully. I haven't tested any functions yet, but will try tomorrow connecting to my mobile phone after finding how to proceed. Here's the dmesg extract. If a full dmesg is required, I can attach it in a separate message. By the way, the latest ACPI 20021118 diff from Wasaki-san works fine here with a intel Celeron 1.2G on 815ep. uhci0: Intel 82801BA/BAM (ICH2) USB controller USB-A port 0xd000-0xd01f irq 11 at device 31.2 on pci0 usb0: Intel 82801BA/BAM (ICH2) USB controller USB-A on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ubt0: Mitsumi product 0x641f, rev 1.10/1.14, addr 2 ubt0: Interface 0 endpoints: interrupt=0x81, bulk-in=0x82, bulk-out=0x2 ubt0: Interface 1 (alt.config 5) endpoints: isoc-in=0x83, isoc-out=0x3; wMaxPacketSize=49; nframes=6, buffer size=294 ubt0: Could not create Netgraph node device_probe_and_attach: ubt0 attach returned 6 ubt0: Mitsumi product 0x641f, rev 1.10/1.14, addr 2 ubt0: Interface 0 endpoints: interrupt=0x81, bulk-in=0x82, bulk-out=0x2 ubt0: Interface 1 (alt.config 5) endpoints: isoc-in=0x83, isoc-out=0x3; wMaxPacketSize=49; nframes=6, buffer size=294 ubt0: Could not create Netgraph node device_probe_and_attach: ubt0 attach returned 6 ubt0: Mitsumi product 0x641f, rev 1.10/1.14, addr 2 ubt0: Interface 0 endpoints: interrupt=0x81, bulk-in=0x82, bulk-out=0x2 ubt0: Interface 1 (alt.config 5) endpoints: isoc-in=0x83, isoc-out=0x3; wMaxPacketSize=49; nframes=6, buffer size=294 ubt0: Could not create Netgraph node device_probe_and_attach: ubt0 attach returned 6 --- ubt0 failed to attach ugen0: Mitsumi product 0x641f, rev 1.10/1.14, addr 2 --- fall back to ugen0 ... start_init: trying /sbin/init splash: image decoder found: logo_saver ugen0: at uhub0 port 2 (addr 2) disconnected --- I unplugged the dongle after bootup ugen0: detached ubt0: Mitsumi product 0x641f, rev 1.10/1.14, addr 2 --- dongle re-inserted and attached ubt0: Interface 0 endpoints: interrupt=0x81, bulk-in=0x82, bulk-out=0x2 ubt0: Interface 1 (alt.config 5) endpoints: isoc-in=0x83, isoc-out=0x3; wMaxPacketSize=49; nframes=6, buffer size=294 __ Do you Yahoo!? Yahoo! Mail Plus Powerful. Affordable. Sign up now. http://mailplus.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Bluetooth questions
÷ Thu, 21.11.2002, × 22:28, Maksim Yevmenkin ÎÁÐÉÓÁÌ: Another bluetooth question: Is Nokia 6310(i) cell phone supported by FreeBSD bluetooth stack ? (of course most interesting as cell modem) What bluetooth adapters (USB/PCMCI/CF) known as work well with FreeBSD. -- Vladimir B. Grebenschikov [EMAIL PROTECTED] SWsoft Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Bluetooth questions
Hello Vladimir B. Grebenschikov wrote: ÷ Thu, 21.11.2002, × 22:28, Maksim Yevmenkin ÎÁÐÉÓÁÌ: Another bluetooth question: Is Nokia 6310(i) cell phone supported by FreeBSD bluetooth stack ? (of course most interesting as cell modem) You have got to try it for yourself :) I have received successful reports about Nokia 7650, so there is a pretty good chance you can make it work :) You most likely can use your Bluetooth enabled cell phone as a wireless modem. You need to download and install rfcommd from ports/. I have recently get Ericsson T68 and the basic stuff works. I did not try wireless modem because I do not have this service with my provider. It is still somewhat expensive +$8 a month + traffic. What bluetooth adapters (USB/PCMCI/CF) known as work well with FreeBSD. USB dongles: 3COM, EPoX, Mitsumi, MSI and TDK. also if your USB dongle has CSR chip in it then it pretty much guaranteed to be supported. 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. max -- Vladimir B. Grebenschikov [EMAIL PROTECTED] SWsoft Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
