Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 30 12月, 2009 1 次提交
  3. 16 12月, 2009 1 次提交
  5. 04 12月, 2009 1 次提交
  7. 30 11月, 2009 1 次提交
  9. 26 11月, 2009 1 次提交
  11. 14 11月, 2009 1 次提交
    • R
      r8169: Fix receive buffer length when MTU is between 1515 and 1536 · 8812304c
      由 Raimonds Cicans 提交于 
      In r8169 driver MTU is used to calculate receive buffer size.
Receive buffer size is used to configure hardware incoming packet filter.

For jumbo frames:
Receive buffer size = Max frame size = MTU + 14 (ethernet header) + 4
(vlan header) + 4 (ethernet checksum) = MTU + 22

Bug:
driver for all MTU up to 1536 use receive buffer size 1536

As you can see from formula, this mean all IP packets > 1536 - 22
(for vlan tagged, 1536 - 18 for not tagged) are dropped by hardware
filter.

Example:

host_good>  ifconfig eth0 mtu 1536
host_r8169> ifconfig eth0 mtu 1536
host_good>  ping host_r8169
Ok
host_good>  ping -s 1500 host_r8169
Fail
host_good>  ifconfig eth0 mtu 7000
host_r8169> ifconfig eth0 mtu 7000
host_good>  ping -s 1500 host_r8169
Ok

Bonus: got rid of magic number 8
Signed-off-by: NRaimonds Cicans <ray@apollo.lv>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8812304c
  13. 30 10月, 2009 1 次提交
  15. 24 10月, 2009 1 次提交
    • S
      r8169: fix Ethernet Hangup for RTL8110SC rev d · 05af2142
      由 Simon Wunderlich 提交于 
      The 8110SC rev d chip on our board shows a regression which the 8110SB chip
did not have. When inbound traffic is overflowing the receive descriptor queue,
"holes" in the ring buffer may occur which lead to a hangup until the buffer
is filled again. The packets are than completely processed, but the ring
remains porous and no packets are processed until the next overflow. Setting
the interface down and up can fix the problem temporary from userspace.

For some reason we don't know, this behaviour is not occuring if the RxVlan
bit for hardware VLAN untagging is set. There is another "Work around for
AMD plateform" in the current code which checks the VLAN status
word in receive descriptors, but does never come to effect when hardware
VLAN support is enabled. We assume that this is a bug in the chip.

The following patch fixes the problem. Without the patch we could reproduce
the hang within minutes (given other devices also generating lots of
interrupts), without we couldn't reproduce within a few days of long term
testing.

This version contains minor style adjustments and is sent with mutt which
will hopefully not destroy the formatting again.
Signed-off-by: NBernhard Schmidt <bernhard.schmidt@saxnet.de>
Signed-off-by: NSimon Wunderlich <simon.wunderlich@saxnet.de>
Acked-by: NFrancois Romieu <romieu@zoreil.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      05af2142
  17. 14 10月, 2009 2 次提交
  19. 07 9月, 2009 1 次提交
  21. 04 9月, 2009 1 次提交
  23. 01 9月, 2009 1 次提交
  25. 13 8月, 2009 6 次提交
  27. 27 7月, 2009 1 次提交
  29. 19 6月, 2009 1 次提交
  31. 18 6月, 2009 1 次提交
  33. 11 6月, 2009 1 次提交
  35. 09 6月, 2009 1 次提交
  37. 29 5月, 2009 1 次提交
  39. 27 5月, 2009 1 次提交
  41. 26 5月, 2009 1 次提交
    • D
      r8169: avoid losing MSI interrupts · f11a377b
      由 David Dillow 提交于 
      The 8169 chip only generates MSI interrupts when all enabled event
sources are quiescent and one or more sources transition to active. If
not all of the active events are acknowledged, or a new event becomes
active while the existing ones are cleared in the handler, we will not
see a new interrupt.

The current interrupt handler masks off the Rx and Tx events once the
NAPI handler has been scheduled, which opens a race window in which we
can get another Rx or Tx event and never ACK'ing it, stopping all
activity until the link is reset (ifconfig down/up). Fix this by always
ACK'ing all event sources, and loop in the handler until we have all
sources quiescent.
Signed-off-by: NDavid Dillow <dave@thedillows.org>
Tested-by: NMichael Buesch <mb@bu3sch.de>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f11a377b
  43. 20 5月, 2009 2 次提交
  45. 14 4月, 2009 1 次提交
    • R
      NET/r8169: Rework suspend and resume · 861ab440
      由 Rafael J. Wysocki 提交于 
      The recent changes of the PCI PM core allow us to simplify the
suspend and resume handling in a number of device drivers, since they
don't need to carry out the general PCI PM operations, such as
changing the power state of the device, during suspend and resume any
more.

Simplify the suspend and resume callbacks of r8169 using the
observation that the PCI PM core can take care of some operations
carried out by the driver.

Additionally, make the shutdown callback of r8169 only put the device
into a low power state if the system is going to be powered off
(kexec is known to have problems with network adapters that are put
into low power states on shutdown).

This patch has been tested on MSI Wind U100.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Tested-by: NBruno Prémont <bonbons@linux-vserver.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      861ab440
  47. 07 4月, 2009 2 次提交
  49. 02 4月, 2009 1 次提交
  51. 16 3月, 2009 2 次提交
  53. 02 3月, 2009 1 次提交
    • I
      r8169: read MAC address from EEPROM on init (2nd attempt) · 6709fe9a
      由 Ivan Vecera 提交于 
      This is 2nd attempt to implement the initialization/reading of MAC address
from EEPROM. The first used PCI's VPD and there were some problems, some
devices are not able to read EEPROM content by VPD. The 2nd one uses direct
access to EEPROM through bit-banging interface and my testing results seem
to be much better.

I tested 5 systems each with different Realtek NICs and I didn't find any
problem. AFAIK Francois's NICs also works fine.

Original description:
This fixes the problem when MAC address is set by ifconfig or by
ip link commands and this address is stored in the device after
reboot. The power-off is needed to get right MAC address.
This is problem when Xen daemon is running because it renames the device
name from ethX to pethX and sets its MAC address to FE:FF:FF:FF:FF:FF.
After reboot the device is still using FE:FF:FF:FF:FF:FF.
Signed-off-by: NIvan Vecera <ivecera@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6709fe9a
  55. 07 2月, 2009 1 次提交
  57. 22 1月, 2009 1 次提交
  59. 23 12月, 2008 1 次提交
  61. 21 11月, 2008 1 次提交