[realtek] Multicast problem with RealTek?

[Steve Smoot]

Hi,
  I have a linux box I am using to process digital video.
  The box uses the Asus P4S333, with the RealTek (something), using the
sis900 driver under Linux kernel 2.4.19 compiled with sis900 and multicast
  The port works fine under regular TCP/IP.  It works fine, if I receive
one stream (~ 5 Mbps)  of multicast content.
  However, if I start to receive a bunch of streams (happens with 4, after
a bit, happens nearly immediately with 10), then the interface has
problems.
  In particular /var/log/messags says:
Jan 27 22:10:30 Fl-snaps-1 kernel: NETDEV WATCHDOG: eth1: transmit timed
out
Jan 27 22:10:30 Fl-snaps-1 kernel: eth1: Transmit timeout, status 00000004
00000000
  and in fact PINGs fail on the device (eth1), and multicast traffic stops
coming in.

  I've done a bunch to debug this - certainly dont see how it could be my
app, since it works on another box, and works with a small number of
packets/streams.  (though of course it is possible).
  I hope its not the linux kernel itself, since I sort of assumed multicast
itself is stable under linux.
  That leads me to the realtek.  Does anything present itself as a possible
culprit to anyone?  Or any obvious debug efforts?  From the error messages
my app gets  before it fails, I suspect the data I see is corrupt (it's
sort of hard to be certain tho).
  I've looked at the sis900.c changes in between 2.4.19 and 2.4.20 and
2.4.21-pre3, and they seem to fix some resource bugs on the transmit
side, but nothing on the receive.  But it's all new to me.
  Any suggestions will be much appreciated.

-s

root # more /proc/net/dev
Inter-|   Receive                                                |  Transmit
 face |bytes    packets errs drop fifo frame compressed multicast|bytes    packets errs drop fifo colls carrier compressed
    lo:  224224    3646    0    0    0     0          0         0   224224    3646    0    0    0     0       0          0
  eth0:2956927186 79306224   12 267062    0     0          0         0 68500808  102422  228    0    4   123     224          0
  eth1:3289149352 10828207    0    3    0     0          0  10081240  1098527   10240  307 21153    0   666     308          0

looks fine to me.

I've tried leaving the 1 stream going for a long time - seems stable - this
does a join then ~8 sec later a leave, then repeats.

I've tried a routine that listed to one stream for 8 sec, leaves,, then
after 2 sec another (etc).  It went for a while (minutes) but did
eventually flake the interface.

root # mii-tool -v eth1
eth1: negotiated 100baseTx-FD, link ok
  product info: vendor 00:05:7d, model 4 rev 1
  basic mode:   autonegotiation enabled
  basic status: autonegotiation complete, link ok
  capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
  advertising:  100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
  link partner: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD

root # ifconfig eth1
eth1      Link encap:Ethernet  HWaddr 00:E0:18:BE:91:44
          inet addr:10.121.1.31  Bcast:10.121.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:11398661 errors:0 dropped:3 overruns:0 frame:0
          TX packets:11109 errors:307 dropped:21281 overruns:0 carrier:308
          collisions:666 txqueuelen:100
          RX bytes:4141803712 (3949.9 Mb)  TX bytes:1614505 (1.5 Mb)
          Interrupt:5 Base address:0xa000