Bug 112501 - UDP Multicast sendto blocked forever
UDP Multicast sendto blocked forever
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeffrey Moyer
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2003-12-21 09:17 EST by yuval yeret
Modified: 2007-11-30 17:06 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-01-14 08:18:45 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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

  None (edit)
Description yuval yeret 2003-12-21 09:17:04 EST
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:

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 03:44:30 EST
Created attachment 96765 [details]
multicast traffic generation file
Comment 2 yuval yeret 2004-01-05 03:44:51 EST
Created attachment 96766 [details]
unicast packet generation script
Comment 3 yuval yeret 2004-01-05 03:45:23 EST
btw with 2.4.20-18 this works OK

Comment 4 Jeffrey Moyer 2004-01-13 10:10:31 EST
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 03:21:48 EST
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 Jeffrey Moyer 2004-01-14 08:18:45 EST
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 04:35:26 EDT
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.