Bug 112501 - UDP Multicast sendto blocked forever
Summary: UDP Multicast sendto blocked forever
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel
Version: 3.0
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jeff Moyer
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-12-21 14:17 UTC by yuval yeret
Modified: 2007-11-30 22:06 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-01-14 13:18:45 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
multicast traffic generation file (380 bytes, text/plain)
2004-01-05 08:44 UTC, yuval yeret
no flags Details
unicast packet generation script (379 bytes, text/plain)
2004-01-05 08:44 UTC, yuval yeret
no flags Details

Description yuval yeret 2003-12-21 14:17:04 UTC
Description of problem:
multicast sendto stuck from time to time.


Version-Release number of selected component (if applicable):
2.4.21-4 kernel
Intel e1000 5.0.43 drivers


How reproducible:


Steps to Reproduce:
1. run a program that uses multicast significantly (e.g. Spread 
http://www.spread.org ). Load it for a long time. 
2. from time to time the program will appear non-responsive. Might be 
related to transient problems in the network / link / route through 
which multicast is routed. 

strace will show it stuck forever on a sendto system call, with the 
destination address being a multicast address. 
  
Actual results:
Stuck


Expected results:
Continue to run. UDP sendto should be non-blocking no matter the 
state of the link / route

Additional info:

(gdb) bt
#0  0xb7525312 in __libc_sendto () at __libc_sendto:-1
#1  0xb75dbfbe in sendto (fd=5, buf=0x804e948, n=75, flags=0, addr=
      {__sockaddr__ = 0x804e87c, __sockaddr_at__ = 0x804e87c, 
__sockaddr_ax25__ = 0x804e87c, __sockaddr_dl__ = 0x804e87c, 
__sockaddr_eon__ = 0x804e87c, __sockaddr_in__ = 0x804e87c, 
__sockaddr_in6__ = 0x804e87c, __sockaddr_inarp__ = 0x804e87c, 
__sockaddr_ipx__ = 0x804e87c, __sockaddr_iso__ = 0x804e87c, 
__sockaddr_ns__ = 0x804e87c, __sockaddr_un__ = 0x804e87c, 
__sockaddr_x25__ = 0x804e87c}, addr_len=16) at wrapsyscall.c:222

Comment 1 yuval yeret 2004-01-05 08:44:30 UTC
Created attachment 96765 [details]
multicast traffic generation file

Comment 2 yuval yeret 2004-01-05 08:44:51 UTC
Created attachment 96766 [details]
unicast packet generation script

Comment 3 yuval yeret 2004-01-05 08:45:23 UTC
btw with 2.4.20-18 this works OK



Comment 4 Jeff Moyer 2004-01-13 15:10:31 UTC
I have been unable to reproduce this problem.  Note that UDP sendto
can and will block, depeneding on system load, memory pressure, etc. 
If this problem is readily reproducable, please post more information,
such as the output from alt-sysrq-m and alt-sysrq-t when the process
is hung, and the exact steps to reproduce the problem (i.e. how many
instances of what program do you run with what switches).


Comment 5 yuval yeret 2004-01-14 08:21:48 UTC
The main combination that causes this is:
RHEL3 kernel + Intel e1000 2.X drivers from Intel + link down 
I think the scenario is quite clear above and I attached the program 
I used and the switches I used to run it. 



Comment 6 Jeff Moyer 2004-01-14 13:18:45 UTC
We do not support third party modules.  Contact intel with this
information, or contact our support staff for further help.

Comment 7 Laurent Deniel 2007-04-16 08:35:26 UTC
Same problem with stock e1000 driver from RHEL.

Please refer to service request #1155558


Note You need to log in before you can comment on or make changes to this bug.