lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 11 Jun 2007 10:58:44 -0500
From:	Milton Miller <>
To:	Milton Miller <>
Cc:	Jeff Garzik <>, Jeff Garzik <>,, David Acker <>,,
	Jesse Brandeburg <>,
	"Kok, Auke" <>,
	Jeff Kirsher <>,
	Scott Feldman <>,
	John Ronciak <>
Subject: Re: [PATCH] fix e100 rx path on ARM (was [PATCH] e100 rx: or s and el bits)

On Jun 6, 2007, at 4:28 AM, Milton Miller wrote:

> On Jun 5, 2007, at 9:26 PM, Kok, Auke wrote:
>> Kok, Auke wrote:
>>> Hmm git-revert seems to do the job right. I checked it with git-show 
>>> | patch -p1 -R and the results look OK. The two patches on top of 
>>> the one we want to revert are unrelated enough to apply (manually it 
>>> shows some fuzz, but otherwise it's OK).
>>> Jeff, please `git-revert d52df4a35af569071fda3f4eb08e47cc7023f094` 
>>> to revert the following patch for now:
>>> ---
>>> commit  d52df4a35af569071fda3f4eb08e47cc7023f094
>>> Author: Scott Feldman <>
>>> Date:   Wed Nov 9 02:18:52 2005 -0500
>>>      [netdrvr e100] experiment with doing RX in a similar manner to 
>>> eepro100
>>>      I was going to say that eepro100's speedo_rx_link() does the 
>>> same DMA
>>>      abuse as e100, but then I noticed one little detail: eepro100 
>>> sets  both
>>>      EL (end of list) and S (suspend) bits in the RFD as it chains 
>>> it  to the
>>>      RFD list.  e100 was only setting the EL bit.  Hmmm, that's  
>>> interesting.
>>>      That means that if HW reads a RFD with the S-bit set,  it'll 
>>> process
>>>      that RFD and then suspend the receive unit.  The  receive unit 
>>> will
>>>      resume when SW clears the S-bit.  There is no need  for SW to 
>>> restart
>>>      the receive unit.  Which means a lot of the receive  unit state 
>>> tracking
>>>      code in the driver goes away.
>>>      So here's a patch against 2.6.14.  (Sorry for inlining it; the 
>>> mailer
>>>      I'm using now will mess with the word wrap).  I can't test this 
>>> on
>>>      XScale (unless someone has an e100 module for Gumstix :) .  It 
>>> should
>>>      be doing exactly what eepro100 does with RFDs.  I don't believe 
>>> this
>>>      change will introduce a performance hit because the S-bit and 
>>> EL-bit  go
>>>      hand-in-hand meaning if we're going to suspend because of the 
>>> S- bit,
>>>      we're on the last resource anyway, so we'll have to wait for SW 
>>>  to
>>>      replenish.
>>>      (cherry picked from 29e79da9495261119e3b2e4e7c72507348e75976 
>>> commit)
>>> ---
>> A little bit more is needed to explain why we're reverting it for 
>> now. Jeff, please insert this into the revert commit.
>> Auke
>> --
>> This patch attempted to fix e100 for non-cache coherent memory 
>> architectures by using the cb style code that eepro100 had and using 
>> the EL and s bits from the RFD list. Unfortunately the hardware 
>> doesn't work exactly like this and therefore this patch actually 
>> breaks e100 on those systems.
> on all systems.  (Both the &| typo and the removed restart logic).
>> Reverting the change brings it back to the previously known good 
>> state for 2.6.22. The pending rewrite in progress to this code can 
>> then be safely merged later.
>> Signed-off-by: Auke Kok <>

Jeff I don't see this in netdev upstream-fixes.  Are you waiting on 
Auke to respond to this?


To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists