Skip to contentSkip to conversation

Error 3c900 driver in 2.2.19?

DISCUSSION Roy Sigurd Karlsbakk 2 participants 5 messages Aug 28, 2001 1 message not in the archive

lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

#1 lore raw
Quoted 2 lines · Andrew Morton

Possibly, VM system changes have taken you over some threshold. Are you putting a lot of traffic through that machine?

There's <= 2500 messages (sendmail - usually <5 concurrently) going through per day, some 10.000 pop connections per day (mostly at working hours). The server's got some 256 megs of RAM, and is doing some small databases with postgresql and mysql in addition to the apache server. The server does not have any problems with swapping, as the text below should show.

As far as I can see from linux/mm/swap.c, it shouldn't have anything to do with freepages... Am I wrong?

roy

[root@server log]# free

             total       used       free     shared    buffers     cached
Mem:        257876     252976       4900      64120      65156     147368

-/+ buffers/cache: 40452 217424
Swap: 136512 268 136244

Quoted 47 lines

Have you tried altering the `freepages' setting?

Quoted 43 lines · Roy Sigurd Karlsbakk

But...

I haven't seen the problem before 2.2.19. Going back to 2.2.16 solved it

Quoted 36 lines · Andrew Morton

Well, it shouldn't hang - it should just fail to do anything for a while and then recover.

You can reserve more memory for the network driver by altering the contents of /proc/sys/vm/freepages. Try doubling everything in there.

Quoted 25 lines · Roy Sigurd Karlsbakk

Hi

I have a 3c900 card in a server, and after upgrading to 2.2.19 it started hanging every now and then, giving me the error message "kernel: eth0:
memory shortage". The card is this (as reported during boot)

3c59x.c:v0.99H 27May00 Donald Becker
http://cesdis.gsfc.nasa.gov/linux/drivers/vortex.html
eth0: 3Com 3c900 Boomerang 10Mbps Combo at 0xa800, 00:a0:24:ef:ef:50, IRQ 5
8K word-wide RAM 3:5 Rx:Tx split, 10baseT interface.
Enabling bus-master transmits and whole-frame receives.

Please cc: to me ([email protected]) and Jannik ([email protected]), as we're not on the list.

Best regards

roy

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

#2 lore raw
In reply to a message not in the archive
Quoted 16 lines · Roy Sigurd Karlsbakk
Quoted 2 lines · Andrew Morton

Possibly, VM system changes have taken you over some threshold. Are you putting a lot of traffic through that machine?

There's <= 2500 messages (sendmail - usually <5 concurrently) going through per day, some 10.000 pop connections per day (mostly at working hours). The server's got some 256 megs of RAM, and is doing some small databases with postgresql and mysql in addition to the apache server. The server does not have any problems with swapping, as the text below should show.

As far as I can see from linux/mm/swap.c, it shouldn't have anything to do with freepages... Am I wrong?

Quoted 8 lines

roy

[root@server log]# free

             total       used       free     shared    buffers     cached
Mem:        257876     252976       4900      64120      65156     147368

-/+ buffers/cache: 40452 217424
Swap: 136512 268 136244

Networking needs to allocate memory at interrupt time. This is referred to as "atomic allocation". The only way in which this can be successful is for the VM system to ensure that there is a pool of immediately-allocatable memory lying around.

The 2.2 kernel uses the tunables in /proc/sys/vm/freepages to decide how large that pool should be. Machines which sustain a high network load commonly require more memory than the default freepages setting provides. People who encounter network Rx allocation failures with 2.2 kernels do report that increasing the freepages tunables fixes the problem.

-

#3 lore raw
Quoted 31 lines · Andrew Morton
Quoted 16 lines · Roy Sigurd Karlsbakk
Quoted 2 lines · Andrew Morton

Possibly, VM system changes have taken you over some threshold. Are you putting a lot of traffic through that machine?

There's <= 2500 messages (sendmail - usually <5 concurrently) going through per day, some 10.000 pop connections per day (mostly at working hours). The server's got some 256 megs of RAM, and is doing some small databases with postgresql and mysql in addition to the apache server. The server does not have any problems with swapping, as the text below should show.

As far as I can see from linux/mm/swap.c, it shouldn't have anything to do with freepages... Am I wrong?

Quoted 8 lines

roy

[root@server log]# free

             total       used       free     shared    buffers     cached
Mem:        257876     252976       4900      64120      65156     147368

-/+ buffers/cache: 40452 217424
Swap: 136512 268 136244

Networking needs to allocate memory at interrupt time. This is referred to as "atomic allocation". The only way in which this can be successful is for the VM system to ensure that there is a pool of immediately-allocatable memory lying around.

Quoted 9 lines

The 2.2 kernel uses the tunables in /proc/sys/vm/freepages to decide how large that pool should be. Machines which sustain a high network load commonly require more memory than the default freepages setting provides. People who encounter network Rx allocation failures with 2.2 kernels do report that increasing the freepages tunables fixes the problem.

-

Thanks

But... Should the server hang after experiencing problems with this? On 2.2.19?

ory

#4 lore raw
In reply to Andrew Morton
Quoted 13 lines · Roy Sigurd Karlsbakk
Quoted 13 lines

Networking needs to allocate memory at interrupt time. This is referred to as "atomic allocation". The only way in which this can be successful is for the VM system to ensure that there is a pool of immediately-allocatable memory lying around.

The 2.2 kernel uses the tunables in /proc/sys/vm/freepages to decide how large that pool should be. Machines which sustain a high network load commonly require more memory than the default freepages setting provides. People who encounter network Rx allocation failures with 2.2 kernels do report that increasing the freepages tunables fixes the problem.

Quoted 8 lines
Quoted 2 lines

-

Thanks

But... Should the server hang after experiencing problems with this? On 2.2.19?

Absolutely not. If the network driver experiences 32 successive memory allocation failures it will fall back to a timer-driven mode where it tries to refill its buffer ring once per second. This code works.

If your machine is completely locking up and needs a reset then something is presumably not handling out-of-memory correctly.

What do you mean by "the server hangs"?

-

#5 lore raw
Quoted 28 lines · Andrew Morton
Quoted 13 lines · Roy Sigurd Karlsbakk
Quoted 13 lines

Networking needs to allocate memory at interrupt time. This is referred to as "atomic allocation". The only way in which this can be successful is for the VM system to ensure that there is a pool of immediately-allocatable memory lying around.

The 2.2 kernel uses the tunables in /proc/sys/vm/freepages to decide how large that pool should be. Machines which sustain a high network load commonly require more memory than the default freepages setting provides. People who encounter network Rx allocation failures with 2.2 kernels do report that increasing the freepages tunables fixes the problem.

Quoted 8 lines
Quoted 2 lines

-

Thanks

But... Should the server hang after experiencing problems with this? On 2.2.19?

Absolutely not. If the network driver experiences 32 successive memory allocation failures it will fall back to a timer-driven mode where it tries to refill its buffer ring once per second. This code works.

Quoted 4 lines

If your machine is completely locking up and needs a reset then something is presumably not handling out-of-memory correctly.

What do you mean by "the server hangs"?

The server locked up and needed a hard reboot

roy