Bug 105915

Description of problem:

When Jumbo frame is enabled (i.e. MTU=9000) for acenic network card,
the interface becomes unable to receive packets after switching on/off
Jumbo frame and/or up/down interface.

The root cause is that driver/net/acenic.c does not update its internal
parameters properly after these operations.

By setting these parameters properly, the problem would be fixed.
Patch will be attached.

Version-Release number of selected component (if applicable):
2.4.21-3.EL

How reproducible:
Often after the following procedure.

Steps to Reproduce:
Set up two hosts (sender and receiver).

1) Problem with up/down interface

1ï¼Change MTU to 9000 on receiver host
   # ifconfig eth0 mtu 9000

2ï¼Change MTU to 9000 on sender host
   # ifconfig eth0 mtu 9000

3ï¼Down the interface on receiver
   # ifconfig eth0 down

4ï¼Up the the interface on receiver
   # ifconfig eth0 mtu 9000 up

5ï¼Send TCP packets from sender to receiver
   # scp  file  receiver:~/ 

6. Interface on receiver stucks


2) Problem with changing MTU

1ï¼Change MTU to 9000 on receiver host
   # ifconfig eth0 mtu 9000

2ï¼Change MTU to 9000 on sender host
   # ifconfig eth0 mtu 9000

3ï¼Send TCP packets from sender to receiver
   # scp  file  receiver:~/ 

4ï¼Change MTU on receiver to 1500
   # ifconfig eth0 mtu 1500

5ï¼Send TCP packets from sender to receiver
   # scp  file  receiver:~/ 

6ï¼Change MTU on receiver to 9000
   # ifconfig eth0 mtu 9000

7ï¼Send TCP packets from sender to receiver
   # scp  file  receiver:~/ 

8. Interface on receiver stucks
    
Actual results:
The interface stucks.

Expected results:
The interface should work after such operations.


Additional info:

Acenic driver has separate buffers for receiving normal frames and
jumbo frames.
The buffers are reloaded at initialization and buffer shortage.
The driver checks ap->jumbo to determine which buffer to be reloaded.

For jumbo frame, the number of current buffers are kept in ap->cur_jumbo_bufs.
When ap->cur_jumbo_bufs becomes smaller than RX_LOW_JUMBO_THRES,
the driver reloads RX_JUMBO_SIZE buffers with ace_load_jumbo_rx_ring().

The problems arises when interface is down/up and/or when MTU is changed.

1) Problem on changing MTU

When MTU is changed from 9000 to 1500, ace_set_rxtx_parms(dev, 0) is
executed. Then buffers are flushed and the number of buffers becomes 0.
NIC raises E_RESET_JUMBO_RNG event interrupt.
At this event, ace_handle_event() sets ap->jumbo to 0 but does not
update ap->cur_jumbo_bufs.
Let R1 be the ap->cur_jumbo_bufs value at this point.

If MTU is changed again to 9000, ace_load_jumbo_rx_ring() is executed
and buffers are reloaded.
At this time, the actual number of buffers are RX_JUMBO_SIZE.
But ap->cur_jumbo_bufs is RX_JUMBO_SIZE plus R1.

With this inconsistency, after receiving packets, actual free buffers
can be 0 while ap->cur_jumbo_bufs is larger than RX_LOW_JUMBO_THRES.
While the buffers are never reloaded unless ap->cur_jumbo_bufs becomes
smaller than RX_LOW_JUMBO_THRES, the driver never declements
ap->cur_jumbo_bufs if packet is not received.
Thus, the driver can not receive any packets.

2) Problem on up/down interface

When the interface is downed at MTU=9000, E_RESET_JUMBO_RNG event occurs
as same way as MTU is changed.
ace_handle_event() sets ap->jumbo to 0 but does not change dev->mtu.

If the interface is up again, ace_open() initialize driver parameters.
It does not change ap->jumbo value nor dev->mtu.
At this point, dev->mtu is 9000 but the driver are set up for normal frames.
So the buffer reload is done for normal frames and jumbo frame buffer
can not be received.