[Bluez-devel] hci_acl_tx_to: hci0 ACL tx timeout

[Bluez-devel] hci_acl_tx_to: hci0 ACL tx timeout

[James Cameron]

Problem: connection via bnep0 eventually freezes, and one of the two
hosts displays in dmesg;

hci_acl_tx_to: hci0 ACL tx timeout
hci_acl_tx_to: hci0 killing stalled ACL connection F5:E5:01:72:02:00

What does this mean?  Is there something I can do to prevent it?  Or
something I can do to gather more information to help explain it?

I've been experimenting with a couple of USB modules, establishing
connections with pand and routing laptop to gateway IP traffic over
bnep0.

Some months ago, I had tried the same thing, but with 2.4.24.  The "ACL
tx timeout" would occur generally within ten minutes if lots of data was
transferred.  Now I'm trying it with 2.6.6, and it had been working fine
for many hours before it happened again, with no heavy data transfer.

I've reviewed kernel ChangeLog-2.6.7 for each of the Bluetooth or BlueZ
changes, but none of the changes seem to cover this problem.  I've
surfed Google for "ACL tx timeout", but nothing springs up as a
solution.

I'm using bluez-utils 2.7, and uhci_hcd.

-- 
James Cameron


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] hci_acl_tx_to: hci0 ACL tx timeout

[Marcel Holtmann]

Hi James,

> Problem: connection via bnep0 eventually freezes, and one of the two
> hosts displays in dmesg;
> 
> hci_acl_tx_to: hci0 ACL tx timeout
> hci_acl_tx_to: hci0 killing stalled ACL connection F5:E5:01:72:02:00
> 
> What does this mean?  Is there something I can do to prevent it?  Or
> something I can do to gather more information to help explain it?
> 
> I've been experimenting with a couple of USB modules, establishing
> connections with pand and routing laptop to gateway IP traffic over
> bnep0.
> 
> Some months ago, I had tried the same thing, but with 2.4.24.  The "ACL
> tx timeout" would occur generally within ten minutes if lots of data was
> transferred.  Now I'm trying it with 2.6.6, and it had been working fine
> for many hours before it happened again, with no heavy data transfer.
> 
> I've reviewed kernel ChangeLog-2.6.7 for each of the Bluetooth or BlueZ
> changes, but none of the changes seem to cover this problem.  I've
> surfed Google for "ACL tx timeout", but nothing springs up as a
> solution.

I can't give you a definitv answer for that problem, but it seems that
some Bluetooth dongles are not working very nice under heavy load. This
is actually not a chip problem, because I saw chips working in one
dongle and in another one it produces such timeouts.

You can of course try to increase the ACL tx timeout and see if it still
occurs. Do all of your dongles use the same Bluetooth chip?

Regards

Marcel




-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] hci_acl_tx_to: hci0 ACL tx timeout

[James Cameron]

On Wed, Jun 30, 2004 at 01:40:57PM +0200, Marcel Holtmann wrote:
> I can't give you a definitv answer for that problem, but it seems that
> some Bluetooth dongles are not working very nice under heavy load. This
> is actually not a chip problem, because I saw chips working in one
> dongle and in another one it produces such timeouts.

Thanks.  I saw a load correlation before, but not with 2.6.6.

> You can of course try to increase the ACL tx timeout and see if it still
> occurs. 

Oh!  How can I increase that?  I've checked hcitool and hciconfig man
pages, and found how to change MTU and buffer size.

> Do all of your dongles use the same Bluetooth chip?

Both dongles were purchased from the same source, and both look
identical apart from the ba.

I'm not sure how to get the identity of the chip, but hciconfig -a says
at the end ...

        Manufacturer: Cambridge Silicon Radio (10)

-- 
James Cameron


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] hci_acl_tx_to: hci0 ACL tx timeout

[Marcel Holtmann]

Hi James,

> > I can't give you a definitv answer for that problem, but it seems that
> > some Bluetooth dongles are not working very nice under heavy load. This
> > is actually not a chip problem, because I saw chips working in one
> > dongle and in another one it produces such timeouts.
> 
> Thanks.  I saw a load correlation before, but not with 2.6.6.

I really think this is buggy hardware in the USB dongle or in the USB
host controller. Maybe it is also only a software problem and related to
the USB subsystem. I don't know.

> > You can of course try to increase the ACL tx timeout and see if it still
> > occurs. 
> 
> Oh!  How can I increase that?  I've checked hcitool and hciconfig man
> pages, and found how to change MTU and buffer size.

Forget about that comment. I checked the kernel code and I don't think
that increasing the timeout to more than 45 seconds makes sense.

        /* ACL tx timeout must be longer than maximum
         * link supervision timeout (40.9 seconds) */
        if (!hdev->acl_cnt && (jiffies - hdev->acl_last_tx) > (HZ * 45))
                hci_acl_tx_to(hdev);

> > Do all of your dongles use the same Bluetooth chip?
> 
> Both dongles were purchased from the same source, and both look
> identical apart from the ba.
> 
> I'm not sure how to get the identity of the chip, but hciconfig -a says
> at the end ...
> 
>         Manufacturer: Cambridge Silicon Radio (10)

If it is CSR based you can try "hciconfig hci0 revision".

Regards

Marcel




-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] hci_acl_tx_to: hci0 ACL tx timeout

[James Cameron]

On Wed, Jun 30, 2004 at 02:43:39PM +0200, Marcel Holtmann wrote:
> I really think this is buggy hardware in the USB dongle or in the USB
> host controller. Maybe it is also only a software problem and related to
> the USB subsystem. I don't know.

Well, tell me what to try to determine where the cause is.  Surely it
should be possible to instrument the kernel functions to gather more
information about the problem?  Then we can say "yes, it's the
hardware", or something else.

> If it is CSR based you can try "hciconfig hci0 revision".

hci0:   Type: USB
        BD Address: 00:02:72:01:E5:FF ACL MTU: 192:8  SCO MTU: 64:8
        HCI 16.4
        Chip version: BlueCore02
        Max key size: 56 bit
        SCO mapping:  HCI

Does that help?  (any good?)

-- 
James Cameron                         http://quozl.netrek.org/
HP Open Source, Volunteer             http://opensource.hp.com/
PPTP Client Project, Release Engineer http://pptpclient.sourceforge.net/

Re: [Bluez-devel] hci_acl_tx_to: hci0 ACL tx timeout

[Marcel Holtmann]

Hi James,

> > I really think this is buggy hardware in the USB dongle or in the USB
> > host controller. Maybe it is also only a software problem and related to
> > the USB subsystem. I don't know.
> 
> Well, tell me what to try to determine where the cause is.  Surely it
> should be possible to instrument the kernel functions to gather more
> information about the problem?  Then we can say "yes, it's the
> hardware", or something else.

you can try to change the number of max bulk urb's to have 2 on rx and 2
on tx. May this helps (drivers/bluetooth/hci_usb.c).

Or disable CONFIG_BT_HCIUSB_SCO so no USB bandwith is consumed for ISOC
transfers.

> > If it is CSR based you can try "hciconfig hci0 revision".
> 
> hci0:   Type: USB
>         BD Address: 00:02:72:01:E5:FF ACL MTU: 192:8  SCO MTU: 64:8
>         HCI 16.4
>         Chip version: BlueCore02
>         Max key size: 56 bit
>         SCO mapping:  HCI
> 
> Does that help?  (any good?)

This chip should actually work fine.

Regards

Marcel




-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel