Date: Fri, 18 Nov 2005 09:42:50 -0800 From: Maksim Yevmenkin <maksim.yevmenkin@savvis.net> To: Eric Anderson <anderson@centtech.com> Cc: bluetooth <bluetooth@freebsd.org> Subject: Re: No route to host for bluetooth devices Message-ID: <437E129A.9000204@savvis.net> In-Reply-To: <437DCBF8.1080000@centtech.com> References: <437B2E58.50709@centtech.com> <437B52FF.9040407@savvis.net> <437B5CE2.5000601@centtech.com> <437B93CF.4000403@savvis.net> <437BA490.1010704@centtech.com> <437BAF32.5030502@savvis.net> <437C8547.3060708@centtech.com> <437CC544.6080509@savvis.net> <437D32F7.10706@centtech.com> <437DCBF8.1080000@centtech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Eric, >>>> Well, here's more information. First, it's reproducable every time >>>> I boot up. Doing: >>>> /etc/rc.d/bluetooth start ubt0 >>>> does not fix it by itself, but doing: >>>> /etc/rc.d/bluetooth stop ubt0 >>>> /etc/rc.d/bluetooth start ubt0 >>>> does. >>> >>> now, i really puzzled. because device fails on to start at boot time, >>> /etc/rc.d/bluetooth should have backed out and removed all netgraph >>> nodes it tried to create (except device node and socket nodes). so i >>> do not understand why do you need to do 'stop' before 'start'. 'stop' >>> should really be a noop in this case. >>> >>> could you please do the following >>> >>> 1) do a fresh boot with bluetooth device turned on >>> >>> 2) after system boots (and bluetooth device failed to start) please >>> run as root >>> >>> # ngctl li >> >> There are 7 total nodes: >> Name: ngctl992 Type: socket ID: 0000001d Num hooks: 0 >> Name: ubt0l2cap Type: l2cap ID: 00000017 Num hooks: 3 >> Name: ubt0hci Type: hci ID: 00000013 Num hooks: 3 >> Name: btsock_l2c Type: btsock_l2c ID: 00000004 Num hooks: 1 >> Name: btsock_l2c_raw Type: btsock_l2c_raw ID: 00000003 Num hooks: 1 >> Name: btsock_hci_raw Type: btsock_hci_raw ID: 00000002 Num hooks: 1 >> Name: ubt0 Type: ubt ID: 00000001 Num hooks: 1 hmm... that does not make much sense to me. somehow you still have all nodes connected even if bluetooth device failed to initialize! that explains why do you need 'stop' command before 'start'. just a crazy idea. please double that you are not initializing device twice, i.e. you use new rc.d scripts and some leftovers from old system. or may be you have devd(8) configuration in both /etc in /usr/local/etc? >>>> I also tried a fresh boot, then switching the bluetooth off, waiting >>>> about 20 seconds, and flipping it back on, which *did* in fact work. >>>> I may not have waited long enough the previous time that failed. >>> >>> ah, ok. could you please check the /var/log/messages file to see if >>> you get a message saying ubt0 is detached/attached? >> >> Here's the snippet upon boot: >> >> Nov 17 19:31:32 neutrino kernel: ubt0: ALPS UGX, rev 1.10/11.68, addr 3 >> Nov 17 19:31:32 neutrino kernel: ubt0: ALPS UGX, rev 1.10/11.68, addr 3 >> Nov 17 19:31:32 neutrino kernel: ubt0: Interface 0 endpoints: >> interrupt=0x81, bulk-in=0x82, bulk-out=0x2 >> Nov 17 19:31:32 neutrino kernel: ubt0: Interface 1 (alt.config 5) >> endpoints: isoc-in=0x83, isoc-out=0x3; wMaxPacketSize=49; nframes=6, >> buffer size=294 [...] >> Nov 17 19:31:41 neutrino kernel: ng_hci_process_command_timeout: >> ubt0hci - unable to complete HCI command OGF=0x3, OCF=0x3. Timeout device failed to initialize and rc.d/bluetooth should have cleaned the nodes, but it did not happen >> Nov 17 19:31:45 neutrino sdpd[659]: Could not bind control socket. >> Permission denied (13) hmm... this is bad too. can you double check if you have sdpd running? >> now I'll run the bluetooth stop, which produces no output. >> >> ngctl li now looks like: >> There are 5 total nodes: >> Name: ngctl1015 Type: socket ID: 00000020 Num hooks: 0 >> Name: btsock_l2c Type: btsock_l2c ID: 00000004 Num hooks: 0 >> Name: btsock_l2c_raw Type: btsock_l2c_raw ID: 00000003 Num hooks: 0 >> Name: btsock_hci_raw Type: btsock_hci_raw ID: 00000002 Num hooks: 0 >> Name: ubt0 Type: ubt ID: 00000001 Num hooks: 0 that is fine. that is what the output should look like when device is failed to initialize. >> Now I ran bluetooth start, which produces no output, and nothing in >> /var/log/messages. >> >> ngctl li now looks like this: >> There are 7 total nodes: >> Name: ngctl1045 Type: socket ID: 0000002c Num hooks: 0 >> Name: ubt0l2cap Type: l2cap ID: 00000026 Num hooks: 3 >> Name: ubt0hci Type: hci ID: 00000022 Num hooks: 3 >> Name: btsock_l2c Type: btsock_l2c ID: 00000004 Num hooks: 1 >> Name: btsock_l2c_raw Type: btsock_l2c_raw ID: 00000003 Num hooks: 1 >> Name: btsock_hci_raw Type: btsock_hci_raw ID: 00000002 Num hooks: 1 >> Name: ubt0 Type: ubt ID: 00000001 Num hooks: 1 and that is fine too - this is what output should look like when all nodes are properly connected. >> Now I wiggle my mouse, and I see this in /var/log/messages: >> Nov 17 19:47:58 neutrino bthidd[603]: Accepted control connection from >> 00:07:61:31:27:15 >> Nov 17 19:47:58 neutrino bthidd[603]: Accepted interrupt connection >> from 00:07:61:31:27:15 >> >> and my mouse now works. >> >>>> Oddly enough, I never had a problem before now. I previously >>>> started the bluetooth stuff from rc.local. The only things I have >>>> changed are: updated to latest -current, removed inet6 from kernel, >>>> rebuilt world/kernel, switched to new rc.d bluetooth scripts. I can >>>> try anything you like. >>> >>> one thing you could try to do is to comment out ubt0 section in >>> /etc/devd.conf and go back to old style rc.bluetooth script to see if >>> you have the same problem. if you do - then its not bluetooth >>> related, if you dont - then its related to new bluetooth rc.d scripts. >> >> I can do that if you'd like.. yes please, if you can. > Something else I just tried: booted up, no mouse as usual. Ran > /etc/rc.d/bluetooth start ubt0, and got this error: > > # /etc/rc.d/bluetooth start ubt0 > /etc/rc.d/bluetooth: ERROR: Unable to setup Bluetooth stack for device ubt0 > > and mouse still does not work.. > > Then, ran it again: > # /etc/rc.d/bluetooth start ubt0 > > no error, and voila! my mouse works. Didn't run the 'stop' part at all, > just the 'start' twice. again the explanation for this is: after the boot device failed to initialize, but for whatever reason, all nodes are still connected. when you do the 'start' command it tries to connect nodes, but it fails because nodes are already connected. because it fails - it tries to clean up after itself and removes all the nodes. thus resetting back to defaults. the next 'start' runs fine, because now everything as it should be. we need to figure out why nodes are still connected after your device failed on boot. thanks, max
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?437E129A.9000204>