On 02/05/2015 06:06 PM, Jörg Krause wrote:
On Do, 2015-02-05 at 15:23 -0700, Stephen Warren wrote:
b) In ci_bounce(), the bounce buffer is only allocated if the
user-buffer is already aligned, and if a large-enough bounce buffer
wasn't previously allocated. If ci_req->b_buf was uninitialized it could
be non-zero (thus preventing the expected aligned allocation) yet not
actually aligned enough.
I can reproduce this issue now. After some "timeout sending packets to
usb ethernet" messages, the bounce buffer somehow gets corrupted.
ci_bounce() is called with an unaligned input buffer length
'req->length=66', but the bounce buffer length
'ci_req->b_len=1140305940' or in hex 'ci_req->b_len=0x43f7b014'. This
bounce buffer length is obviously an address, as the following
misaligned error message shows: "CACHE: Misaligned operation at range
[43f7b010, 43f7b070]".
Ah, I hadn't realized that was [start, length] rather than [start, end].
The question is: How is ci_req->b_len getting corrupted? Is it simply
never initialized, or does something trash that value later?
ci_ep_alloc_request() appears to calloc() the whole struct ci_req, so I
imagine an initialization/allocating error isn't happening.
The only issue there might be some code somehow creating its own struct
usb_request instead of calling into the controller's ->alloc_request()
function. I vaguely recall fixing some of those, but might have missed
some in protocols that I didn't test (i.e. anything other than USB Mass
Storage or DFU, although I might have very briefly tested netconsole once?).
I would suggest adding a whole ton of printfs() to catch where ci_reqs
are being allocated, and where ci_req->b_len is getting written in which
ci_req objects, and then mapping that back to the ci_req that the cache
alignment error message complains about. Sorry, this will be a bit painful.
If the ci_req is always at the same address on different boots of the
code, that will make it easier, especially if you have a debugger with a
data watchpoint, or can write some code to use any data watchpoint
self-hosted debug capability in your CPU.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
