lkml.org 
[lkml]   [2007]   [May]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] e100 rx: or s and el bits
Milton Miller wrote:
> In commit d52df4a35af569071fda3f4eb08e47cc7023f094, the description
> talks about emulating another driver by setting addtional bits and
> the being unable to test when submitted. Seeing the & operator to
> set more bits made me suspicious, and indeed the bits are defined
> in positive logic:
>
> cb_s = 0x4000,
> cb_el = 0x8000,
>
> So anding those together would be 0. I'm guessing they should
> be or'd, but don't have hardware here to test, much like the
> committed patch. In fact, I'll let someone else do the compile
> test too. I'll update the comment.
>

I wonder if this worked for me because the hardware also spun on the
link field being NULL? Since the RU base is also set to 0, the
calculated physical address would be 0 as well. I would imagine if the
hardware tried to read/write to very low addresses across PCI, there
would be issues. I will retest with a small receive pool to try to hit
the problem.

It seems to apply to a pretty recent git pull from linus's tree. I
manually merged this into the 2.6.18.4 kernel we are using. With the
original in kernel driver (just EL bit, no S bit), I had two tests that
would always end in horrible memory corruption on a PXA255 based system.
One is a 12 hour bidirectional TCP test using iperf with the ethernet
port sending packets to a wireless card and vice versa. The other is a
similar configuration running a 12 hour UDP test sending 20
megabits/second in each direction. Even through the original S-bit
patch seems broken, we have had days of continuous traffic through it
without issue where previously we could never go more than 6 hours.

I will let folks know how it goes. In the UDP test, the ethernet side
often gets ahead of the available buffers due to CPU and PCI usage by
the wireless card and its driver.

I will also run these tests with the new patch and with a smaller
receive pool (default is 256) to make the pool run out more often.


-Ack
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2007-05-01 17:05    [W:0.237 / U:0.056 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site