Re: [PATCH] e100 rx: or s and el bits

[David Acker <dacker@roinet.com>]

David Acker wrote:
> 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.
> 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.

So far my testing has shown both the original and the new version of the 
S-bit patch work in that no corruption seemed to occur over long term 
runs.  The previous S-bit patch may have only worked due to something 
specific about how my PCI companion chip handles I/O to low memory 
addresses (from dereferencing a link address of 0).  Perhaps the e100 
handles the NULL link as well, but given that the manual does not seem 
to state what happens when the hardware encounters a buffer with a link 
of 0, I think Milton's fix is the proper way to do it.  The old eepro 
driver did set both bits although it did it with a hardcoded constant.

I will continue testing with slab debug on but that will take longer. 
Has anyone tried this on other platforms?
-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/