[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bluetooth-dev] Ericsson EBDK do not work using stackv20001115, help appreciated
#LIU YONG# wrote:
> hello, thanks for your help.
> i have turned on the BT_DATAFLOW_DEBUG, but couldn't see any debugging
> message. i read from the source code, the debugging messages are printed by
> the printk function. will it work under usermode?
It looks like bt_write_lower_driver is always called from a kernel context,
even in user mode. If you don't see any debug messages in /var/log/messages
then perhaps the bluetooth printk's aren't being logged with a high enough
priority. In this case you can either change /etc/syslog.conf to include a line
like this (and then either reboot or use man syslog to find out how to put the
change into effect):
Or you can modify src/btdebug.c:print_data like this and then recompile:
printk(KERN_INFO /*<---- add this macro */ "...");
Hopefully one of these will work out for you ;).
> i also tried to create a connection by calling the lp_connect_req function
> in the HCI directly, but got the "Invalid HCI command parameters" message.
> is there any alternative to connect 2 BT devices?
I always used the old con <parms> command prior to 11/15. In usermode for 11/15
I think I used rf_conn. The AXIS developers might know another way.
> so many questions...
> best regards,
> liu yong
> -----Original Message-----
> From: Gordon McNutt
> To: #LIU YONG#
> Sent: 12/27/2000 1:45 AM
> Subject: Re: [bluetooth-dev] Ericsson EBDK do not work using stackv20001115,
> help appreciated
> #LIU YONG# wrote:
> > hello, the stack version i am using is 20001115. the h/w is EBDK,
> P7B. O/S
> > is redhat 6.2 (upgraded to 2.2.18 kernel).
> > (pls correct me if i am wrong.)
> > i think this "invalid hci command parameters" message is sent by the
> > controller as the response to the create_connection command sent by
> > host. i studied a bit of the code, and found that the the packet type
> > to create_connection is 0xcc18, but i couldn't find the corresponding
> > type specified in the spec.
> The 0xcc18 is a bitmask. Check out page 550 of the Core Spec v 1.0 B.
> table shows the bits which can be set in the packet type field. The AXIS
> is setting all the bits which aren't reserved, which comes out to
> Perhaps you can turn on the BT_DATAFLOW_DEBUG in btdebug.h and have a
> look at
> the actual packet being sent to the host controller. Then you can
> compare that
> with a known good one like this:
> bt_write_lower_driver : (17) /* Create ACL Connection */
> 0x01 0x05 0x04 0x0d 0xb4 0xdb 0x15 0x20 0x39 0x1a 0x18 0xcc 0x00 0x00
> 0x00 0x00
> > wish you a merry christmas!!
> Thank you. I hope yours went well also.
To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to firstname.lastname@example.org