All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johan Hedin <sua@home.se>
To: bluez-devel@lists.sourceforge.net
Subject: [Bluez-devel] HCI reset problem
Date: Sat, 2 Jul 2005 19:12:29 +0200	[thread overview]
Message-ID: <200507021912.29173.sua@home.se> (raw)

Hi everyone!

After spending a few days googling and browsing the e-mail archives of
bluez-devel, I need some expert help for my strange "HCI reset"/USB disconnect
problem.

This is what happens; A while after the bluetooth subsystem is started
(by started I mean that the kernel modules are loaded and that hcid and
sdpd are started), the USB dongle disconnects from the host and then
immediately reconnects again. If I have a rfcomm connection up when this
happens, I'm forced to do "rfcomm release", reload the rfcomm kernel module
and "rfcomm bind" again to be able to use /dev/rfcomm0.

The problem is 100% reproducible for me by establish a rfcomm connetion
to my cell phone and just type AT<enter> a couple of times in minicom and
then, disconnect... Even without any active rfcomm connection the
disconnect happens, it just takes a little bit longer. If I let my computer
run, the disconnet happens a couple of times per day without me doing
anyting.

My system is Fedora Core 4 (kernel 2.6.11) on a Dell Latitude X300 with
a Dell TrueMobile 300 Bluetooth built in USB dongle (CSR BlueCore02 chip).
I'm using the latest bluez-libs, bluez-utils and bluez-hcidump from bluez.org
and NOT the Fedora RPM:s (even though the problem is the same with the
Fedora supplied bluez packages)

hciconfig says the following:

[root@x300 ~]# hciconfig -a hci0 version features revision
hci0:   Type: USB
        BD Address: 00:10:C6:60:34:21 ACL MTU: 192:8 SCO MTU: 64:8
        HCI Ver: 1.2 (0x2) HCI Rev: 0x4f2 LMP Ver: 1.2 (0x2) LMP Subver: 0x4f2
        Manufacturer: Cambridge Silicon Radio (10)
        Features: 0xff 0xff 0x8f 0x78 0x18 0x18 0x00 0x80
                <3-slot packets> <5-slot packets> <encryption> <slot offset>
                <timing accuracy> <role switch> <hold mode> <sniff mode>
                <park state> <RSSI> <channel quality> <SCO link> <HV2 packets>
                <HV3 packets> <u-law log> <A-law log> <CVSD> <paging scheme>
                <power control> <transparent SCO> <broadcast encrypt>
                <enhanced iscan> <interlaced iscan> <interlaced pscan>
                <inquiry with RSSI> <AFH cap. slave> <AFH class. slave>
                <AFH cap. master> <AFH class. master> <extended features>
        Build 1266
        Chip version: BlueCore02-External
        Max key size: 128 bi
        SCO mapping:  HCI
        Panic code:   0x16
        Fault code:   0x1e


This is what I see when the reset happens (and yes, there are two output lines
from hcidump):

[root@x300 ~]# hcidump -t -X -V 
2005-07-02 14:09:10.093053 < HCI Command: Reset (0x03|0x0003) plen 0
2005-07-02 14:09:10.093053 < HCI Command: Reset (0x03|0x0003) plen 0


This is what the syslog says at the same moment (I have compiled hci_usb, 
rfcomm, l2cap and bluetooth with debug on):

Jul  2 14:09:10 x300 kernel: usb 3-2: USB disconnect, address 26
Jul  2 14:09:10 x300 kernel: hci_unregister_dev: e3bc4000 name hci0 type 1
Jul  2 14:09:10 x300 kernel: hci_unregister_sysfs: e3bc4000 name hci0 type 1
Jul  2 14:09:10 x300 kernel: hci_dev_do_close: hci0 e3bc4000
Jul  2 14:09:10 x300 kernel: hci_req_cancel: hci0 err 0x13
Jul  2 14:09:10 x300 kernel: inquiry_cache_flush: cache e3bc4174
Jul  2 14:09:10 x300 kernel: hci_conn_hash_flush: hdev hci0
Jul  2 14:09:10 x300 kernel: hci_sock_dev_event: hdev hci0 event 4
Jul  2 14:09:10 x300 kernel: hci_send_to_sock: hdev 00000000 len 8
Jul  2 14:09:10 x300 kernel: __hci_request: hci0 start
Jul  2 14:09:10 x300 kernel: hci_reset_req: hci0 0
Jul  2 14:09:10 x300 kernel: hci_send_cmd: hci0 ogf 0x3 ocf 0x3 plen 0
Jul  2 14:09:10 x300 kernel: hci_send_cmd: skb len 3
Jul  2 14:09:10 x300 hcid[21360]: HCI dev 0 down
Jul  2 14:09:10 x300 kernel: hci_cmd_task: hci0 cmd 1
Jul  2 14:09:10 x300 hcid[21360]: Stoping security manager 0
Jul  2 14:09:10 x300 kernel: hci_send_frame: hci0 type 1 len 3
Jul  2 14:09:10 x300 kernel: hci_send_to_sock: hdev e3bc4000 len 3
Jul  2 14:09:10 x300 kernel: hci_sock_recvmsg: sock ce652dc0, sk dba03200
Jul  2 14:09:10 x300 kernel: hci_sock_recvmsg: sock cf129440, sk d3c6dc00
Jul  2 14:09:10 x300 kernel: hci_sock_release: sock d28b2bc0 sk dbfec200
Jul  2 14:09:10 x300 kernel: __hci_request: hci0 end: err -110
Jul  2 14:09:10 x300 kernel: hci_sock_dev_event: hdev hci0 event 2
Jul  2 14:09:10 x300 kernel: hci_send_to_sock: hdev 00000000 len 8
Jul  2 14:09:10 x300 hcid[21360]: HCI dev 0 unregistered
Jul  2 14:09:10 x300 kernel: hci_sock_recvmsg: sock cf129440, sk d3c6dc00
Jul  2 14:09:10 x300 kernel: hci_sock_recvmsg: sock ce652dc0, sk dba03200

The reset shown above happend without any active rfcomm connection.

So, some questions I have:

1. What can cause a HCI reset being sent from the host to the device?

2. Is the USB disconnect a result of the HCI reset seen from hcidump or is
   the HCI reset a result of the USB disconnect (the syslog have one line
   saying hci_reset_req: hci0 0)?

3. If the HCI reset is sent as a result of some error reported by the device,
   shouldn't hcidump show some activity in the direction FROM the device TO
   the host?

4. Is this perhaps a USB problem and not a Bluetooth problem?


When I use my external Bluetooth dongle, I don't have the reset problem and
everything is working as normal. This is what hciconfig says about my external
dongle:

[root@x300 ~]# hciconfig -a hci1 version features revision
hci1:   Type: USB
        BD Address: 00:0A:9A:00:A2:56 ACL MTU: 339:4 SCO MTU: 64:0
        HCI Ver: 1.1 (0x1) HCI Rev: 0x93 LMP Ver: 1.1 (0x1) LMP Subver: 0x93
        Manufacturer: Transilica, Inc. (24)
        Features: 0xff 0xff 0x3d 0x00 0x00 0x00 0x00 0x00
                <3-slot packets> <5-slot packets> <encryption> <slot offset>
                <timing accuracy> <role switch> <hold mode> <sniff mode>
                <park state> <RSSI> <channel quality> <SCO link> <HV2 packets>
                <HV3 packets> <u-law log> <A-law log> <CVSD> <power control>
                <transparent SCO>
        Unsupported manufacturer


Do any of you spot my problem, or can you point me in some direction
so that I can do some more debugging (perhaps where in the source to look)?

Sorry for the rather long mail, but I wanted to get as much information in
as possible :-)

Thankful for any help!

Regards Johan


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

             reply	other threads:[~2005-07-02 17:12 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-02 17:12 Johan Hedin [this message]
2005-07-02 21:15 ` [Bluez-devel] HCI reset problem Ronny L Nilsson
2005-07-03 14:53   ` Johan Hedin
2005-07-06  0:10     ` Ronny L Nilsson
2005-07-06 20:28       ` Johan Hedin
2005-07-03 15:26 ` Marcel Holtmann
2005-07-03 16:09   ` Johan Hedin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200507021912.29173.sua@home.se \
    --to=sua@home.se \
    --cc=bluez-devel@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.