- 26 4月, 2007 4 次提交
-
-
由 Arnaldo Carvalho de Melo 提交于
One less thing for drivers writers to worry about. Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Arnaldo Carvalho de Melo 提交于
Now all the _type_trans routines are consistent in this regard. Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Arnaldo Carvalho de Melo 提交于
Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Arnaldo Carvalho de Melo 提交于
Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 25 4月, 2007 4 次提交
-
-
由 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>
-
由 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>
-
由 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>
-
由 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>
-
- 24 4月, 2007 1 次提交
-
-
由 S.Çağlar Onur 提交于
USRobotics Wireless Adapter (Model 5423) works well with current zd1211rw driver also (i have tested 2.6.18, 2.6.20 and 2.6.21-rc7). It just needs its ID added to the list of devices. Signed-off-by: NS.Çağlar Onur <caglar@pardus.org.tr> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 22 4月, 2007 3 次提交
-
-
由 Marcel van Nies 提交于
Signed-off-by: NMarcel van Nies <morcles@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Marcel van Nies 提交于
Signed-off-by: NMarcel van Nies <morcles@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Marcel van Nies 提交于
The MAC address assignment at module loading is simply forgotten. The bug at module unloading is caused by an incorrect call. The bug at module unloading does not only happen for sunqe, sunlance and sunhme (sbus) suffer from it too. I've tested this on my SS20. Signed-off-by: NMarcel van Nies <morcles@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 20 4月, 2007 12 次提交
-
-
由 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>
-
由 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>
-
由 Stephen Hemminger 提交于
Signed-off-by: NStephen Hemminger <shemminger@linux-foundation.org> Signed-off-by: NJeff Garzik <jeff@garzik.org>
-
由 Stephen Hemminger 提交于
The Yukon FE (100mbit only) chips do not support large packets. Signed-off-by: NStephen Hemminger <shemminger@linux-foundation.org> Signed-off-by: NJeff Garzik <jeff@garzik.org>
-
由 Stephen Hemminger 提交于
The Yukon EC Ultra chips have transmit settings for store and forward and PCI buffering. By setting these appropriately, normal performance goes from 750Mbytes/sec to 940Mbytes/sec (non-jumbo). It is also possible to do Jumbo mode, but it means turning off TSO and checksum offload so the performance gets worse. There isn't enough buffering for checksum offload to work. Signed-off-by: NStephen Hemminger <shemminger@linux-foundation.org> Signed-off-by: NJeff Garzik <jeff@garzik.org>
-
由 Stephen Hemminger 提交于
Need to make sure and disable ASF on all chip types. Otherwise, there may be random reboots. Signed-off-by: NStephen Hemminger <shemminger@linux-foundation.org> Signed-off-by: NJeff Garzik <jeff@garzik.org>
-
由 Stephen Hemminger 提交于
There should never be descriptor error unless hardware or driver is buggy. But if an error occurs, print useful information, clear irq, and recover. Signed-off-by: NStephen Hemminger <shemminger@linux-foundation.org> Signed-off-by: NJeff Garzik <jeff@garzik.org>
-
由 Stephen Hemminger 提交于
This device is having all sorts of problems that lead to data corruption and system instability. It gets receive status and data out of order, it generates descriptor and TSO errors, etc. Until the problems are resolved, it should not be used by anyone who cares about there system. Signed-off-by: NStephen Hemminger <shemminger@linux-foundation.org> Signed-off-by: NJeff Garzik <jeff@garzik.org>
-
由 Dave Jiang 提交于
Gianfar needs crc32 to be selected to compile. Signed-off-by: NDave Jiang <djiang@mvista.com> -- drivers/net/Kconfig | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) -- Signed-off-by: NJeff Garzik <jeff@garzik.org>
-
由 Linas Vepstas 提交于
The basic structure of "normal" UDP/IP/Ethernet frames (that actually work): - It starts with the Ethernet header (dest MAC, src MAC, etc.) - The next part is occupied by the IP header (version info, length of packet, id=0, fragment offset=0, checksum, from / to address, etc.) - Then comes the UDP header (src / dest port, length, checksum) - Actual payload - Ethernet checksum Now what's different for IP fragment: - The IP header has id set to some value (same for all fragments), offset is set appropriately (i.e. 0 for first fragment, following according to size of other fragments), size is the length of the frame. - UDP header is unchanged. I.e. length is according to full UDP datagram, not just the part within the actual frame! But this is only true within the first frame: all following frames don't have a valid UDP-header at all. The spidernet silicon seems to be quite intelligent: It's able to compute (IP / UDP / Ethernet) checksums on the fly and tests if frames are conforming to RFC -- at least conforming to RFC on complete frames. But IP fragments are different as explained above: I.e. for IP fragments containing part of a UDP datagram it sees incompatible length in the headers for IP and UDP in the first frame and, thus, skips this frame. But the content *is* correct for IP fragments. For all following frames it finds (most probably) no valid UDP header at all. But this *is* also correct for IP fragments. The Linux IP-stack seems to be clever in this point. It expects the spidernet to calculate the checksum (since the module claims to be able to do so) and marks the skb's for "normal" frames accordingly (ip_summed set to CHECKSUM_HW). But for the IP fragments it does not expect the driver to be capable to handle the frames appropriately. Thus all checksums are allready computed. This is also flaged within the skb (ip_summed set to CHECKSUM_NONE). Unfortunately the spidernet driver ignores that hints. It tries to send the IP fragments of UDP datagrams as normal UDP/IP frames. Since they have different structure the silicon detects them the be not "well-formed" and skips them. The following one-liner against 2.6.21-rc2 changes this behavior. If the IP-stack claims to have done the checksumming, the driver should not try to checksum (and analyze) the frame but send it as is. Signed-off-by: NNorbert Eicker <n.eicker@fz-juelich.de> Signed-off-by: NLinas Vepstas <linas@austin.ibm.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NJeff Garzik <jeff@garzik.org>
-
由 Divy Le Ray 提交于
Remove assumption that PHY interrupts use GPIOs 3 and 5. Deal with PHY interrupts connected to any GPIO pins. Signed-off-by: NDivy Le Ray <divy@chelsio.com> Signed-off-by: NJeff Garzik <jeff@garzik.org>
-
由 Divy Le Ray 提交于
Reuse the incoming skb when a clientless abort req is recieved. The release of RDMA connections HW resources might be deferred in low memory situations. Ensure that no further activity is passed up to the RDMA driver for these connections. Signed-off-by: NDivy Le Ray <divy@chelsio.com> Signed-off-by: NJeff Garzik <jeff@garzik.org>
-
- 11 4月, 2007 14 次提交
-
-
由 Brice Goglin 提交于
Update the myri10ge driver version number to 1.3.0-1.233. Signed-off-by: NBrice Goglin <brice@myri.com> Signed-off-by: NJeff Garzik <jeff@garzik.org>
-
由 Brice Goglin 提交于
Add the Intel 5000 southbridge (aka Intel 6310/6311/6321ESB) PCIe ports and the Intel E30x0 chipsets to the whitelist of aligned PCIe completion. Signed-off-by: NBrice Goglin <brice@myri.com> Signed-off-by: NJeff Garzik <jeff@garzik.org>
-
由 Brice Goglin 提交于
Simpler way of dealing with the firmware 4KB boundary crossing restriction for rx buffers. This fixes a variety of memory corruption issues when using an "uncommon" MTU with a 16KB page size. Signed-off-by: NBrice Goglin <brice@myri.com> Signed-off-by: NJeff Garzik <jeff@garzik.org>
-
由 Divy Le Ray 提交于
Remove specific CPL handler. Add missing CPL handler. Add missing register setting when the interface is brought up. Signed-off-by: NDivy Le Ray <divy@chelsio.com> Signed-off-by: NJeff Garzik <jeff@garzik.org>
-
由 Divy Le Ray 提交于
The MAC watchdog was failing if the peer interface was brought down. Signed-off-by: NDivy Le Ray <divy@chelsio.com> Signed-off-by: NJeff Garzik <jeff@garzik.org>
-
由 Divy Le Ray 提交于
Fix a deadlock when the interface s configured down and the watchdog tack is sleeping on rtnl_lock. Signed-off-by: NDivy Le Ray <divy@chelsio.com> Signed-off-by: NJeff Garzik <jeff@garzik.org>
-
由 Stephen Hemminger 提交于
Need to rework wake on lan code to setup properly and get activated on shutdown (and suspend), not when ethtool is run. This does not need to go to stable queue because wake on lan was not even included in 2.6.20 (or earlier versions). Signed-off-by: NStephen Hemminger <shemminger@linux-foundation.org> Signed-off-by: NJeff Garzik <jeff@garzik.org>
-
由 Stephen Hemminger 提交于
The workaround Yukon EC-U wasn't comparing with correct version and wasn't doing correct setup. Without it, 88e8056 throws all sorts of errors. Signed-off-by: NStephen Hemminger <shemminger@linux-foundation.org> Signed-off-by: NJeff Garzik <jeff@garzik.org>
-
由 Stephen Hemminger 提交于
Some of these chips are disabled until clock is enabled. This fixes: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=404107Signed-off-by: NStephen Hemminger <shemminger@linux-foundation.org> Signed-off-by: NJeff Garzik <jeff@garzik.org>
-
由 Stephen Hemminger 提交于
Driver needs to turn off carrier when down. Signed-off-by: NStephen Hemminger <shemminger@linux-foundation.org> Signed-off-by: NJeff Garzik <jeff@garzik.org>
-
由 Stephen Hemminger 提交于
Driver needs to turn off carrier when down, otherwise it can confuse bonding and bridging and looks like carrier is on immediately when it is brought back up. Signed-off-by: NStephen Hemminger <shemminger@linux-foundation.org> Signed-off-by: NJeff Garzik <jeff@garzik.org>
-
由 Larry Finger 提交于
The specifications for loopback_gain calculation and for G PHY initialization have been updated. This patch implements them and fixes a machine check error that occurs for PPC architecture with a phy->rev of 1. Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Larry Finger 提交于
In 802.11b/g mode, bcm43xx actively scans channels 1-14 no matter what locale has been set, either in the sprom or by the locale option. This behaviorviolates regulatory rules everywhere in the world except Japan. This patch changes the default range to the correct value if the locale has been set, and to channels 1-13 if no locale has been set. Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Daniel Drake 提交于
Due to conflicting/confusing defines in the vendor driver, we were reading E2P_PHY_REG from the wrong location. CR157 patching was slightly incorrect in that the vendor driver only patches in an 8-bit value, whereas we were patching 24 bits. Additionally, CR157 patching was happening on both zd1211 and zd1211b, but this should only happen on zd1211. Signed-off-by: NDaniel Drake <dsd@gentoo.org> Signed-off-by: NUlrich Kunitz <kune@deine-taler.de> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 10 4月, 2007 2 次提交
-
-
由 Daniel Drake 提交于
zd1211rw currently detects AL2230S-based devices as AL2230, and hence programs the RF incorrectly. Transmit silently fails on this misconfiguration. After this patch, AL2230S devices are rejected with an error message, to avoid any confusion with an apparent driver bug. Signed-off-by: NDaniel Drake <dsd@gentoo.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Herbert Xu 提交于
The spin_lock calls made in dev->open and dev->close must disable BH since open/close are made in process context. Conversely, the call in dev->hard_start_xmit does not need to disable BH since it is already executing with BH disabled. Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-