From: amateur <ztl.post@gmail.com>
To: bluez-devel <bluez-devel@lists.sourceforge.net>
Subject: [Bluez-devel] Data Transmission Error with OHCI Host Controller
Date: Mon, 1 Jan 2007 20:51:15 +0800 [thread overview]
Message-ID: <20070101125115.GA4041@163.com> (raw)
Hi Guys,
I have a problem with bluez on a arm platform. Here is the detail:
On the arm embedded platform, I invoke this command
l2ping -s 667 BDADDR
to test the bluetooth L2CAP connection, where BDADDR is the bluetooth
address of my Linux/Bluez laptop. At the same time, I use
hcidump -x -R
on my laptop to monitor the bluetooth traffic. The problem is that the
data I sent from the embedded arm platform got corrupted on
receptioin. After a careful check, I found that the error has the
following pattern: Some bytes of the ACL data packet, which
corresponding to the L2CAP Echo Request Command, will have some 4
bytes of its content changed from valid data to 4 bytes of zero on
occasion. And this change-to-zero error may occur several times in a
ACL Packet sometimes. The distance between consecutive errors is
always a multiple of 64-bytes which is the maxPacketSize of the USB
pipe of the bluetooth dongle. The offset of the error position in the
ACL Packet is always 64*i+4-64*i+7(4 bytes), where 'i' is an integer.
I am really confused. I have checked the skb and urb associated with
the ACL Packet. And they both looks fine(content correct). So where
could the problem lies in? Has anyone have had such a problem before?
Any clue or hints are welcome!
Is this an known bug of OHCI HC driver usb-ohci in kernel 2.4.21? What
makes me more confused is that the Usb Storage Disk works great on the
embedded system.
I'm using linux-2.4.21 with patch-linux-2.4.21-mh10 and a cirrus edb9312
embedded arm platform which has a OHCI-Compatible USB Host Controller.
The bluetooth dongle is a CSR one which works normally on my laptop
PC.
Thank you in advance, guys.
Regards
Tianlei
--
For the fashion of Minas Tirith was such that it was built on seven levels,
each delved into a hill, and about each was set a wall, and in each wall
was a gate.
-- J.R.R. Tolkien, "The Return of the King"
[Quoted in "VMS Internals and Data Structures", V4.4, when
referring to system overview.]
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel
reply other threads:[~2007-01-01 12:51 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20070101125115.GA4041@163.com \
--to=ztl.post@gmail.com \
--cc=bluez-devel@lists.sourceforge.net \
--cc=tlzhao@nudt.edu.cn \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox