--- Quote Start ---
originally posted by graham615+feb 22 2006, 12:16 pm--><div class='quotetop'>quote (graham615 @ feb 22 2006, 12:16 pm)</div>
--- quote start ---
<!--quotebegin-tuck@Feb 16 2006, 01:39 PM
i saw the same thing; however, i never got around to debugging it. unfortunately web is low on the dev priority now. if i get around to it and figure it out i will post details. if you figure it out please post details of the fix/workaround/config as i would be interested.
good luck.
tuck
<div align='right'><{post_snapback}> (index.php?act=findpost&pid=12749)
--- quote end ---
--- Quote End ---
Tuck:
Here is what I have so far.....
I turned on the eCos asserts and tracing:
Anyway...enabling asserts in eCos unmasks the following assert:
ASSERT FAIL: <3> if_lan91cxx(868)lan91cxx_send() odd length
Breaking and examining the code shows that there are four buffers in the
driver that contains the packet. Their lengths are 54, 71, 63, and 27.
Accorfing to the assert, only the last one can be of an odd length.
Because the device interface is 16 bits, the driver load two bytes at a time
and increments the counter by two. If the packet is of an odd length, a
flag is set and the odd byte is written to complete the packet. At each of
the odd buffers, the last (odd) character is my missing '\n' and explains
why the server is not delivering my pages as I would expect.
Now that I know the source of the failure, I will determine the root cause
and propose a solution. I think by writing even chunks from the ring buffer to the device is the solution. Perhaps a new routine to only write an odd length at the end of a packet. Right now I am developing under windows to get XML-RPC and XMLHttpResponse support up and running. I will port more as I learn more.
Thanks for your reply.
Graham....
<div align='right'><{post_snapback}> (index.php?act=findpost&pid=12883)</div>
[/b]
--- Quote End ---
Excellent!
I would go for a modification in the driver code. If you patch up the ring buffer in X
network stack then there are still other network stacks that could have issues. Seems to me like the driver doesn't properly handle the scatter gather list if it can only reassemble very specific types of SG lists (ones where the individual nodes can only be even length except for the last).
I would do a look behind like this:
@@ line 869
if(i && sg_list.len & 1)
{
//correct my len for next iter
sg_list.len++;
//correct my current pointer.
sdata = (unsigned short *)sg_list.buf+1;
//Get the last byte of the last buffer and shift it one byte left.
short data = *sg_list.buf.len -1];
data = data << 8;
//Add in the first byte from my buffer.
data |= *sg_list.buf;
//Send this off.
put_data(sc, *sdata);
len--;
}
I don't have time to really check this code over, but you can probably get the gist if I have errors. The only other thing I would be concerned about is modifying the sg_list[i].len in which case you could maintain a boolean indicating weather the last iteration handled a odd item
bool oddHandled = false;
for(...
...
if(i && sg_list.len & 1 && !oddHandled)
{
oddHandled = true;
...
}
else
oddHandled = false;
That way the sg list wouldn't be tampered with (incase it is inspected/used after the call).
Tuck
--Edit
Oh and after that first if block you would need to handle if the current len is odd
if(i != (sg_len - 1) && (len & 1))
len--;
Honored Contributor
