Re: Problem with sockets an 2.6.21-rc5 kernel
On Mon, Mar 26, 2007 at 11:03:21PM +0200, Jose Alberto Reguero ([EMAIL PROTECTED]) wrote: 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. -- Evgeniy Polyakov - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with sockets an 2.6.21-rc5 kernel
El Martes, 27 de Marzo de 2007, Evgeniy Polyakov escribió: On Mon, Mar 26, 2007 at 11:03:21PM +0200, Jose Alberto Reguero ([EMAIL PROTECTED]) wrote: 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. Jose Alberto - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with sockets an 2.6.21-rc5 kernel
On Tue, Mar 27, 2007 at 04:29:11PM +0200, Jose Alberto Reguero ([EMAIL PROTECTED]) wrote: El Martes, 27 de Marzo de 2007, Evgeniy Polyakov escribió: On Mon, Mar 26, 2007 at 11:03:21PM +0200, Jose Alberto Reguero ([EMAIL PROTECTED]) wrote: 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 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with sockets an 2.6.21-rc5 kernel
El Martes, 27 de Marzo de 2007, Evgeniy Polyakov escribió: On Tue, Mar 27, 2007 at 04:29:11PM +0200, Jose Alberto Reguero ([EMAIL PROTECTED]) wrote: El Martes, 27 de Marzo de 2007, Evgeniy Polyakov escribió: On Mon, Mar 26, 2007 at 11:03:21PM +0200, Jose Alberto Reguero ([EMAIL PROTECTED]) wrote: 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 The first time i try the kernel driver was with kernel 2.6.21-rc4, and don't work. I can help to debug the problem, with some help. I have a M2V motherboard with built-in Attansic(R) L1 Ethernet Network Driver and a Athlon 64 X2 Dual Core processor. Jose Alberto - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with sockets an 2.6.21-rc5 kernel
El Martes, 27 de Marzo de 2007, Jose Alberto Reguero escribió: El Martes, 27 de Marzo de 2007, Evgeniy Polyakov escribió: On Tue, Mar 27, 2007 at 04:29:11PM +0200, Jose Alberto Reguero ([EMAIL PROTECTED]) wrote: El Martes, 27 de Marzo de 2007, Evgeniy Polyakov escribió: On Mon, Mar 26, 2007 at 11:03:21PM +0200, Jose Alberto Reguero ([EMAIL PROTECTED]) wrote: 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 The first time i try the kernel driver was with kernel 2.6.21-rc4, and don't work. I can help to debug the problem, with some help. I have a M2V motherboard with built-in Attansic(R) L1 Ethernet Network Driver and a Athlon 64 X2 Dual Core processor. Jose Alberto I found that the original driver has its own ether_crc_le function, that return the value inverted. The attached patch solve the problem. Jose Alberto --- linux-2.6.21-rc5/drivers/net/atl1/atl1_hw.c 2007-03-26 00:56:23.0 +0200 +++ linux-2.6.21-rc5.new/drivers/net/atl1/atl1_hw.c 2007-03-27 20:14:23.0 +0200 @@ -334,7 +334,6 @@ int i; crc32 = ether_crc_le(6, mc_addr); - crc32 = ~crc32; for (i = 0; i 32; i++) value |= (((crc32 i) 1) (31 - i));
Re: Problem with sockets an 2.6.21-rc5 kernel
El Martes, 27 de Marzo de 2007, Jose Alberto Reguero escribió: El Martes, 27 de Marzo de 2007, Jose Alberto Reguero escribió: El Martes, 27 de Marzo de 2007, Evgeniy Polyakov escribió: On Tue, Mar 27, 2007 at 04:29:11PM +0200, Jose Alberto Reguero ([EMAIL PROTECTED]) wrote: El Martes, 27 de Marzo de 2007, Evgeniy Polyakov escribió: On Mon, Mar 26, 2007 at 11:03:21PM +0200, Jose Alberto Reguero ([EMAIL PROTECTED]) wrote: 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 The first time i try the kernel driver was with kernel 2.6.21-rc4, and don't work. I can help to debug the problem, with some help. I have a M2V motherboard with built-in Attansic(R) L1 Ethernet Network Driver and a Athlon 64 X2 Dual Core processor. Jose Alberto I found that the original driver has its own ether_crc_le function, that return the value inverted. The attached patch solve the problem. Jose Alberto if yu you want to apply it in the case that you need it: Signed-off-by: Jose Alberto Reguero [EMAIL PROTECTED] Jose Alberto - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Problem with sockets an 2.6.21-rc5 kernel
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?
Thanks.
Jose Alberto
client.py
Description: application/python
#include sys/socket.h
#include netinet/in.h
#include string.h
main()
{
int sock = socket (AF_INET, SOCK_DGRAM, IPPROTO_UDP);
struct sockaddr_in ClientAddr;
memset(ClientAddr, 0, sizeof(ClientAddr));
ClientAddr.sin_family = AF_INET;
ClientAddr.sin_addr.s_addr = inet_addr(227.234.253.9);
int port = 15922;
ClientAddr.sin_port = htons((short) port);
char str[] = Hello, world;
sendto(sock, str, strlen(str), 0, (struct sockaddr *)ClientAddr, sizeof(ClientAddr));
close(sock);
}
#include sys/socket.h
#include netinet/in.h
#include arpa/inet.h
#include string.h
#include stdio.h
main()
{
struct sockaddr_in ServerAddr;
int sock = socket (AF_INET, SOCK_DGRAM, IPPROTO_UDP);
int reuse = 1;
setsockopt(sock, SOL_SOCKET, SO_REUSEADDR, reuse, sizeof(int));
memset(ServerAddr, 0, sizeof(ServerAddr));
ServerAddr.sin_family = AF_INET;
ServerAddr.sin_addr.s_addr = htonl(INADDR_ANY);
int port = 15922;
ServerAddr.sin_port = htons((short) port);
bind(sock, (struct sockaddr *)ServerAddr, sizeof(ServerAddr));
struct ip_mreq mreq;
memset(mreq, 0, sizeof(mreq));
mreq.imr_multiaddr.s_addr = inet_addr(227.234.253.9);
mreq.imr_interface.s_addr = htonl(INADDR_ANY);
setsockopt(sock, IPPROTO_IP, IP_ADD_MEMBERSHIP, mreq, sizeof(mreq));
char str[100];
memset(str, 0, sizeof(str));
recv(sock, str, 100, 0);
printf(:%s:\n, str);
close (sock);
}
server.py
Description: application/python
