On Tue, Mar 27, 2007 at 04:29:11PM +0200, Jose Alberto Reguero (jareguero@telefonica.net) wrote:

El Martes, 27 de Marzo de 2007, Evgeniy Polyakov escribió:

quoted

On Mon, Mar 26, 2007 at 11:03:21PM +0200, Jose Alberto Reguero 

(jareguero@telefonica.net) wrote:

quoted

quoted

I had two python programs, server.py and client.py(attached)

With server.py in  a kernel 2.6.21-rc5 x86_64 and client.py in the same
machine,  server.py get the message.

With server.py in  a kerner 2.6.21-rc5 x86_64 and client.py in another
machine, server.py don't get the message.

The same with the programs in c(attached).

With kernel 2.6.20.3 the programs work well.

There are something wrong in the programs?

Besides full absence of error checks and coding style issues it does not
seem to contain errors.

And, btw, C program work with 2.6.21-rc5 (git tree
e0f2e3a06be513352cb4955313ed7e55909acd84) on x86_64.

server.c application compiled with Debian 4.1.1-21 compiler on x86_64
sucessfully received message from 2.6.18-3 machine.

Thanks. I thought it was a kernel BUG. It is a alt1 driver BUG(Attansic(R) L1 
Ethernet Network Driver). The error happens with the atl1 driver that comes 
with kernel 2.6.21-rc5. With he original driver from ASUS for M2V motherboard 
modified to compile with kernel 2.6.21-rc5 there is no problems.

Did it work with in-kernel driver?
There is only one remotely related change in the driver:

-	mta = ioread32((hw + REG_RX_HASH_TABLE) + (hash_reg << 2));
+	mta = ioread32((hw->hw_addr + REG_RX_HASH_TABLE) + (hash_reg << 2));

If it worked before, then spurious ioread() from outside of our
univercity could lead to good/bad mta value (likely zero or ~0), so appropriate 
multicast list update could succeed.

If your programs never worked with this new driver, then it can not be
easily solved without hardware specifications.

I added Jay Cliburn who submitted the driver to Cc list.

Jose Alberto

-- 
	Evgeniy Polyakov