[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [bluetooth-dev] send_acl_packet error


Are you using the user mode version? 
The user mode version is only intended to be used for testing and debugging, for example at unplug fests. Maybe this wasn't clear in the previous releases, but it is emphasized in the README of the latest release.

There is no protection against concurrent use in the user mode version. cli() and sti() doesn't make any sense in user mode and if you take a look at btcommon.h you can see that these and other kernel mode functions are just dummies when compiling for user mode.


Axis Bluetooth Team

-----Original Message-----
From: Xavier DEBREUIL [mailto:xde@xxxxxxx.fr]
Sent: Wednesday, January 17, 2001 7:57 PM
To: Johan Zander
Cc: bluetooth-dev@xxxxxxx.com
Subject: Re: [bluetooth-dev] send_acl_packet error

I've just integrated Gordon's modification to the 20010108 version so that the
btduser could run.
I complete my ppp connexion but still got that problem.
Any more ideas ?
I see the cli and sti function added but the problem may occur elsewhere


Johan Zander wrote:
> This is a known problem in the older releases and is fixed in the latest release of the stack. The problem is due to race problems with ncp interrupting the sending of data. This has been redesigned and is now handled by tasks instead. (Check send_acl_data_task in hci.c)
> Regards,
> Johan
> Axis Bluetooth Team
> -----Original Message-----
> From: Xavier DEBREUIL [mailto:xde@xxxxxxx.fr]
> Sent: Wednesday, January 17, 2001 9:55 AM
> To: bluetooth-dev@xxxxxxx.com
> Subject: [bluetooth-dev] send_acl_packet error
> I am still using the 20001115 release between an ARM and and a PC. It seems that
> UART problems have gone away and I am connected through ppp to the network :
> PC <-ppp-> ARM BOARD <-ethernet-> NETWORK
> ppp over rf_comm
> Nevertheless, when I try to send or receive many data, the following erro
> occures :
>  send_acl_packet : negative cur_len... (-135)
> and afterwards, the connexion is stalled for a while ; but the stack is not
> halted or crashed and after a while data come again in my browser.
> What I find is that when the acl_num before is 4
> and the acl_num after is 9
> I always got this error...
> It seems that when the NCP event is treated too late (after the stack decides to
> fill the packet (5)), there is a shift.
> Has anyone encountered such a problem ?
> Thank you.
> Xavier
To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to majordomo@xxxxxxx.com