Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 161
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 26 4月, 2007 10 次提交
  3. 25 4月, 2007 5 次提交
    • M
      [BNX2]: Fix occasional NETDEV WATCHDOG on 5709. · 68c9f75a
      由 Michael Chan 提交于 
      Tweak a register setting to prevent the tx mailbox from halting.

Update version to 1.5.8.
Signed-off-by: NMichael Chan <mchan@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      68c9f75a
    • A
      drivers/net/hamradio/baycom_ser_fdx build fix · 5efb764c
      由 Andrew Morton 提交于 
      sparc64:

drivers/net/hamradio/baycom_ser_fdx.c: In function `ser12_open':
drivers/net/hamradio/baycom_ser_fdx.c:417: error: `NR_IRQS' undeclared (first us
e in this function)
drivers/net/hamradio/baycom_ser_fdx.c:417: error: (Each undeclared identifier is
 reported only once
drivers/net/hamradio/baycom_ser_fdx.c:417: error: for each function it appears i
n.)

Cc: Folkert van Heusden <folkert@vanheusden.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NJeff Garzik <jeff@garzik.org>
      5efb764c
    • D
      usb-net/pegasus: fix pegasus carrier detection · c43c49bd
      由 Dan Williams 提交于 
      Broken by 4a1728a2 which switched the
return semantics of read_mii_word() but didn't fix usage of
read_mii_word() to conform to the new semantics.

Setting carrier to off based on the NO_CARRIER flag is also incorrect as
that flag only triggers on TX failure and therefore isn't correct when
no frames are being transmitted.  Since there is already a 2*HZ MII
carrier check going on, defer to that.

Add a TRUST_LINK_STATUS feature flag for adapters where the LINK_STATUS
flag is actually correct, and use that rather than the NO_CARRIER flag.
Signed-off-by: NDan Williams <dcbw@redhat.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>
      c43c49bd
    • N
      sis900: Allocate rx replacement buffer before rx operation · b748d9e3
      由 Neil Horman 提交于 
      	The sis900 driver appears to have a bug in which the receive routine
passes the skbuff holding the received frame to the network stack before
refilling the buffer in the rx ring.  If a new skbuff cannot be allocated, the
driver simply leaves a hole in the rx ring, which causes the driver to stop
receiving frames and become non-recoverable without an rmmod/insmod according to
reporters.  This patch reverses that order, attempting to allocate a replacement
buffer first, and receiving the new frame only if one can be allocated.  If no
skbuff can be allocated, the current skbuf in the rx ring is recycled, dropping
the current frame, but keeping the NIC operational.
Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>
      b748d9e3
    • A
      [netdrvr] depca: handle platform_device_add() failure · d91c088b
      由 Andrea Righi 提交于 
      The following patch fixes a kernel bug in depca_platform_probe().

We don't use a dynamic pointer for pldev->dev.platform_data, so it seems
that the correct way to proceed if platform_device_add(pldev) fails is
to explicitly set the pldev->dev.platform_data pointer to NULL, before
calling the platform_device_put(pldev), or it will be kfree'ed by
platform_device_release().
Signed-off-by: NJeff Garzik <jeff@garzik.org>
      d91c088b
  5. 24 4月, 2007 15 次提交
  7. 22 4月, 2007 4 次提交
  9. 21 4月, 2007 3 次提交
  11. 20 4月, 2007 3 次提交
    • L
      Revert "e1000: fix NAPI performance on 4-port adapters" · 46fcc86d
      由 Linus Torvalds 提交于 
      This reverts commit 60cba200.  It's been
linked to lockups of the e1000 hardware, see for example

	https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229603

but it's likely that the commit itself is not really introducing the
bug, but just allowing an unrelated problem to rear its ugly head (ie
one current working theory is that the code exposes us to a hardware
race condition by decreasing the amount of time we spend in each NAPI
poll cycle).

We'll revert it until root cause is known.  Intel has a repeatable
reproduction on two different machines and bus traces of the hardware
doing something bad.
Acked-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
Cc: Jeff Garzik <jeff@garzik.org>
Cc: David S. Miller <davem@davemloft.net>
Cc: Greg KH <gregkh@suse.de>
Cc: Dave Jones <davej@redhat.com>
Cc: Auke Kok <auke-jan.h.kok@intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      46fcc86d
    • A
      pata_sis: Fix oops on boot · f3769e9d
      由 Alan Cox 提交于 
      A small number of SiS setups require special handling (not many judging
by how long this dumb bug survived). A couple of Fedora 7 devel testers
hit an Oops on pata_sis loading which is caused by terminal confusion
between chipset as 'the chipset we have found' and chipset as 'array
iterator'
Signed-off-by: NAlan Cox <alan@redhat.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>
      f3769e9d
    • P
      [PPP]: Fix skbuff.c:BUG due incorrect logic in process_input_packet() · 7c5050e3
      由 Paul Mackerras 提交于 
      From: Paul Mackerras <paulus@samba.org>

This fixes:

Subject: kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6

process_input_packet() treats the case where the first byte is 0xff
(PPP_ALLSTATIONS) but the second byte is 0x03 (PPP_UI) as indicating a
packet with a PPP protocol number of 0xff.  Arguably that's wrong
since PPP protocol 0xff is reserved, and the RFC does envision the
possibility of receiving frames where the control field has values
other than 0x03.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7c5050e3