Re: Problems with Linux 2.2.14 and RTL8139 driver

From: Avery Pennarun (apenwarr@worldvisions.ca)
Date: Tue Jan 11 2000 - 17:21:32 EST


On Mon, Jan 10, 2000 at 11:25:58AM +0200, Arvids wrote:

> I have Linux 2.2.14 box with 3 Accton Cheetah 10/100 Ethernet cards (based
> on MPX5038). RTL8139 driver detects them as 'SMC1211TX EZCard 10/100' ( as
> I see from sources, rtl8139 driver knows only MPX5030, not MPX5038 chip).
> When the box is starting, sometimes I get such message: 'Jan 9 19:15:01
> linux kernel: eth2: Couldn't allocate a 65536 byte receive ring.' and the
> box goes up with only two interfaces. In the next restart usually all is
> OK. It seems that this problem is not a purely driver problem, because the
> problem arises from failed kmalloc call.

Problems like these have plagued Linux since the earliest times, and I'm sad
to say they still haven't been fixed.

The problem is due to memory fragmentation -- there aren't any _contiguous_
64k areas remaining and owned by the kernel at the time you do an 'ifconfig
up' of the RTL8139 card.

Two things you can try to fix this:

  - 'ifconfig up' the interface much earlier in your boot cycle, before
        much memory gets allocated and fragmented. You don't have to assign
        an IP address or set routes or anything, just 'ifconfig eth0 up'

  - change RX_BUF_LEN_IDX in linux/drivers/net/rtl8139.c to 0 instead of 3,
        reducing the memory usage from 64k to 8k.
        
Neither of these solutions is optimal. The first one is an ugly hack, and
the second probably reduces performance or increases the chance of a buffer
overrun (and thus lost packets). I did both of the above and this error
basically went away for me.

The problem would be alleviated at least a bit if the driver would allocate
memory immediately upon loading, rather than on ifconfig up. I can't see
much point in delaying the allocation -- if I have the card and I loaded the
driver, I'll probably want to use it.

Note that the rtl8139 driver is buggy anyway -- I can reliably make the card
stop responding by hitting it with too much traffic while, say, a fast IDE
drive is transferring a lot of data. I suspect it doesn't recover from
buffer overruns properly. 'ifconfig eth0 down up' fixes it (until the next
time).

Anyone interested in fixing the driver, please feel free to ask me for
details :)

Have fun,

Avery
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.rutgers.edu



This archive was generated by hypermail 2b29 : Sat Jan 15 2000 - 21:00:29 EST