- 24 5月, 2013 1 次提交
-
-
由 David S. Miller 提交于
This reverts commits: c573972c 1a590434 da2e2c21 They were meant for net-next not net. Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 23 5月, 2013 9 次提交
-
-
由 Emilio López 提交于
Commit bfd428da ("net: ethernet: sun: initialize variables directly") dropped the only loop that was using i but did not remove the actual variable, therefore causing a warning when building. This patch drops the now redundant line. Reported-by: NStephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: NEmilio López <emilio@elopez.com.ar> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Emilio López 提交于
Commit e998fd41 ("net: ethernet: korina: initialize variables directly") dropped the only loop that was using i but did not remove the actual variable, therefore causing a warning when building. This patch drops the now redundant line. Signed-off-by: NEmilio López <emilio@elopez.com.ar> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Emilio López 提交于
Commit 3b0aaef8 ("net: ethernet: apple: initialize variables directly") dropped the only loop that was using i but did not remove the actual variable, therefore causing a warning when building. This patch drops the now redundant line. Signed-off-by: NEmilio López <emilio@elopez.com.ar> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Shawn Guo 提交于
MVF is a family while MVF600 is a particular SoC in the family. We generally prefer to use SoC rather than family name in compatible string to define a particular type of fec device. And this is how fec_dt_ids works for all those IMX fec variants. Let's change mvf to mvf600 to have it work in the same way. Signed-off-by: NShawn Guo <shawn.guo@linaro.org> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Shahed Shaikh 提交于
o After change in EPORT features of 82xx adapter, netdev->features needs to be updated to reflect EPORT feature updates but driver was manipulating netdev->features at wrong place. o This patch uses netdev_update_features() and .ndo_fix_features() to update netdev->features properly. Signed-off-by: NShahed Shaikh <shahed.shaikh@qlogic.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Sony Chacko 提交于
Code is removed because netdev->trans_start updates made by the driver will be ignored by the kernel. Signed-off-by: NSony Chacko <sony.chacko@qlogic.com> Signed-off-by: NShahed Shaikh <shahed.shaikh@qlogic.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Sony Chacko 提交于
Fix error paths in probe to assign proper error codes to probe return value. Signed-off-by: NSony Chacko <sony.chacko@qlogic.com> Signed-off-by: NShahed Shaikh <shahed.shaikh@qlogic.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Nithin Sujir 提交于
Signed-off-by: NNithin Nayak Sujir <nsujir@broadcom.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Nithin Sujir 提交于
After resetting the device, the driver waits for a signature to be updated to know that firmware has completed initialization. However, the call to tg3_poll_fw() is being done too late and we're writing to the GRC_MODE register before it has completely initialized, causing contention with firmware. This logic has existed since day one but is causing PCIE link to go down randomly at startup on one platform once every few hundred reboots. Move the tg3_poll_fw() up to before we write to the GRC_MODE register after reset. Signed-off-by: NNithin Nayak Sujir <nsujir@broadcom.com> Signed-off-by: NMichael Chan <mchan@broadcom.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 21 5月, 2013 1 次提交
-
-
由 stephen hemminger 提交于
This patch cures transmit timeout's with DHCP observed while running under KVM. When the transmit ring is cleaned out, the Byte Queue Limit values need to be reset. Signed-off-by: NStephen Hemminger <stephen@networkplumber.org> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 20 5月, 2013 2 次提交
-
-
由 Yuval Mintz 提交于
Starting with commit 91226790 `bnx2x: use FW 7.8.17', the bnx2x driver no longer requests the FW to perform IP checksums for IPv4 packets. This behaviour needs to be revised for 57710/57711 chips - when using GSO, if the driver will not set the IP checksum flag then packets will be transmitted by the chip without a valid IP checksum, resulting in a drop of all such packets on the receiver-side. Signed-off-by: NYuval Mintz <yuvalmin@broadcom.com> Signed-off-by: NDmitry Kravkov <dmitry@broadcom.com> Signed-off-by: NEilon Greenstein <eilong@broadcom.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 françois romieu 提交于
8168evl offloaded checksums are wrong since commit e5195c1f ("r8169: fix 8168evl frame padding.") pads small packets to 60 bytes (without ethernet checksum). Typical symptoms appear as UDP checksums which are wrong by the count of added bytes. It isn't worth compensating. Let the driver checksum. Due to the skb length changes, TSO code is moved before the Tx descriptor gets written. Signed-off-by: NFrancois Romieu <romieu@fr.zoreil.com> Tested-by: NHolger Hoffstätte <holger.hoffstaette@googlemail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 18 5月, 2013 1 次提交
-
-
由 Wei Yongjun 提交于
Add the missing iounmap() before return from gianfar_ptp_probe() in the error handling case. Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 17 5月, 2013 1 次提交
-
-
由 Russell King 提交于
When the interface is shutdown, the mv643xx_eth driver hits the following lockdep dump: ================================= [ INFO: inconsistent lock state ] 3.8.0+ #303 Not tainted --------------------------------- inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage. NetworkManager/3449 [HC0[0]:SC0[0]:HE1:SE1] takes: (_xmit_ETHER#2){+.?...}, at: [<c02828e4>] txq_reclaim+0x60/0x230 {IN-SOFTIRQ-W} state was registered at: [<c007e93c>] mark_irqflags+0xf8/0x1c4 [<c007ee60>] __lock_acquire+0x458/0x9a4 [<c007f8b0>] lock_acquire+0x60/0x74 [<c03ea914>] _raw_spin_lock+0x40/0x50 [<c0334040>] sch_direct_xmit+0xa4/0x2e4 [<c0320880>] dev_queue_xmit+0x174/0x508 [<c03953b0>] ip6_finish_output2+0xd0/0x3c4 [<c03b15bc>] mld_sendpack+0x190/0x368 [<c03b3204>] mld_ifc_timer_expire+0xc/0x58 [<c005133c>] call_timer_fn+0x6c/0xe0 [<c0051588>] run_timer_softirq+0x1d8/0x210 [<c004c004>] __do_softirq+0xe0/0x1b4 [<c004c448>] irq_exit+0x64/0x6c [<c000f1e0>] handle_IRQ+0x34/0x84 [<c000e0d0>] __irq_usr+0x30/0x80 irq event stamp: 160603 hardirqs last enabled at (160603): [<c00c736c>] kfree+0xa8/0xe8 hardirqs last disabled at (160602): [<c00c72e0>] kfree+0x1c/0xe8 softirqs last enabled at (160304): [<c028260c>] mib_counters_update+0x5ec/0x60c softirqs last disabled at (160302): [<c03eab8c>] _raw_spin_lock_bh+0x14/0x54 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(_xmit_ETHER#2); <Interrupt> lock(_xmit_ETHER#2); *** DEADLOCK *** 1 lock held by NetworkManager/3449: #0: (rtnl_mutex){+.+.+.}, at: [<c032e664>] rtnetlink_rcv+0xc/0x24 stack backtrace: [<c0013e34>] (unwind_backtrace+0x0/0xf8) from [<c007e12c>] (print_usage_bug+0x150/0x1d4) [<c007e12c>] (print_usage_bug+0x150/0x1d4) from [<c007e3f8>] (mark_lock_irq+0x248/0x290) [<c007e3f8>] (mark_lock_irq+0x248/0x290) from [<c007e598>] (mark_lock+0x158/0x404) [<c007e598>] (mark_lock+0x158/0x404) from [<c007e97c>] (mark_irqflags+0x138/0x1c4) [<c007e97c>] (mark_irqflags+0x138/0x1c4) from [<c007ee60>] (__lock_acquire+0x458/0x9a4) [<c007ee60>] (__lock_acquire+0x458/0x9a4) from [<c007f8b0>] (lock_acquire+0x60/0x74) [<c007f8b0>] (lock_acquire+0x60/0x74) from [<c03ea914>] (_raw_spin_lock+0x40/0x50) [<c03ea914>] (_raw_spin_lock+0x40/0x50) from [<c02828e4>] (txq_reclaim+0x60/0x230) [<c02828e4>] (txq_reclaim+0x60/0x230) from [<c0282ad8>] (txq_deinit+0x24/0xcc) [<c0282ad8>] (txq_deinit+0x24/0xcc) from [<c0282d28>] (mv643xx_eth_stop+0x1a8/0x1bc) [<c0282d28>] (mv643xx_eth_stop+0x1a8/0x1bc) from [<c031e314>] (__dev_close_many+0x88/0xcc) [<c031e314>] (__dev_close_many+0x88/0xcc) from [<c031e380>] (__dev_close+0x28/0x3c) [<c031e380>] (__dev_close+0x28/0x3c) from [<c0320fa0>] (__dev_change_flags+0x7c/0x134) [<c0320fa0>] (__dev_change_flags+0x7c/0x134) from [<c03210e0>] (dev_change_flags+0x10/0x48) [<c03210e0>] (dev_change_flags+0x10/0x48) from [<c032da1c>] (do_setlink+0x1a0/0x730) [<c032da1c>] (do_setlink+0x1a0/0x730) from [<c032f524>] (rtnl_newlink+0x304/0x4b0) [<c032f524>] (rtnl_newlink+0x304/0x4b0) from [<c032ef8c>] (rtnetlink_rcv_msg+0x25c/0x2a0) [<c032ef8c>] (rtnetlink_rcv_msg+0x25c/0x2a0) from [<c03383a0>] (netlink_rcv_skb+0xbc/0xd8) [<c03383a0>] (netlink_rcv_skb+0xbc/0xd8) from [<c032e674>] (rtnetlink_rcv+0x1c/0x24) [<c032e674>] (rtnetlink_rcv+0x1c/0x24) from [<c03361d8>] (netlink_unicast_kernel+0x88/0xd4) [<c03361d8>] (netlink_unicast_kernel+0x88/0xd4) from [<c0337dd0>] (netlink_unicast+0x138/0x180) [<c0337dd0>] (netlink_unicast+0x138/0x180) from [<c0338020>] (netlink_sendmsg+0x208/0x32c) [<c0338020>] (netlink_sendmsg+0x208/0x32c) from [<c030ab48>] (sock_sendmsg+0x84/0xa4) [<c030ab48>] (sock_sendmsg+0x84/0xa4) from [<c030aef4>] (__sys_sendmsg+0x2ac/0x2c4) [<c030aef4>] (__sys_sendmsg+0x2ac/0x2c4) from [<c030c8ec>] (sys_sendmsg+0x3c/0x68) [<c030c8ec>] (sys_sendmsg+0x3c/0x68) from [<c000e2e0>] (ret_fast_syscall+0x0/0x3c) It seems that txq_reclaim() takes the netif tx lock: __netif_tx_lock(nq, smp_processor_id()); in a context outside of softirq context, and thus is susceptible to deadlock should an interrupt occur. Use __netif_tx_lock_bh()/__netif_tx_unlock_bh() instead. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 16 5月, 2013 3 次提交
-
-
由 Fabio Estevam 提交于
commit 54309fa6 ("net: fec: fix kernel oops when plug/unplug cable many times") introduced the following 'if' block in the beginning of fec_start(): if (netif_running(ndev)) { netif_device_detach(ndev); napi_disable(&fep->napi); netif_stop_queue(ndev); netif_tx_lock_bh(ndev); } Then later in the end of fec_restart() there is another block that calls the opposite of each one of these functions. The correct approach would be to also call them with in the reverse order, so that we have as result: if (netif_running(ndev)) { netif_tx_unlock_bh(ndev); netif_wake_queue(ndev); napi_enable(&fep->napi); netif_device_attach(ndev); } Suggested-by: NEric Dumazet <eric.dumazet@gmail.com> Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Fabio Estevam 提交于
fec_restart() runs in softirq context and we should use the netif_tx_lock_bh/netif_tx_unlock_bh() variants to avoid the following warning that happens since commit 54309fa6 ("net: fec: fix kernel oops when plug/unplug cable many times"): [ 9.753168] ================================= [ 9.757540] [ INFO: inconsistent lock state ] [ 9.761921] 3.10.0-rc1-next-20130514 #13 Not tainted [ 9.766897] --------------------------------- [ 9.771264] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. [ 9.777288] swapper/0 [HC0[0]:SC1[3]:HE1:SE0] takes: [ 9.782261] (_xmit_ETHER#2){+.?...}, at: [<c03c24a4>] sch_direct_xmit+0xa0/0x2d4 [ 9.789879] {SOFTIRQ-ON-W} state was registered at: [ 9.794769] [<c0059c60>] __lock_acquire+0x528/0x1bc0 [ 9.799953] [<c005b838>] lock_acquire+0xa0/0x108 [ 9.804780] [<c0441320>] _raw_spin_lock+0x28/0x38 [ 9.809702] [<c02f9fc8>] fec_restart+0x5d0/0x664 [ 9.814542] [<c02fa738>] fec_enet_adjust_link+0xa8/0xc0 [ 9.819978] [<c02f7a28>] phy_state_machine+0x2fc/0x370 [ 9.825323] [<c0035ee0>] process_one_work+0x1c0/0x4a0 [ 9.830589] [<c0036594>] worker_thread+0x138/0x394 [ 9.835587] [<c003c620>] kthread+0xa4/0xb0 [ 9.839890] [<c000e820>] ret_from_fork+0x14/0x34 [ 9.844728] irq event stamp: 185984 [ 9.848226] hardirqs last enabled at (185984): [<c00232b0>] local_bh_enable_ip+0x84/0xf0 [ 9.856450] hardirqs last disabled at (185983): [<c0023270>] local_bh_enable_ip+0x44/0xf0 [ 9.864667] softirqs last enabled at (185966): [<c0023470>] irq_enter+0x64/0x68 [ 9.872099] softirqs last disabled at (185967): [<c0023510>] irq_exit+0x9c/0xd8 [ 9.879440] [ 9.879440] other info that might help us debug this: [ 9.885981] Possible unsafe locking scenario: [ 9.885981] [ 9.891912] CPU0 [ 9.894364] ---- [ 9.896814] lock(_xmit_ETHER#2); [ 9.900259] <Interrupt> [ 9.902884] lock(_xmit_ETHER#2); [ 9.906500] [ 9.906500] *** DEADLOCK *** Reported-by: NShawn Guo <shawn.guo@linaro.org> Suggested-by: NEric Dumazet <eric.dumazet@gmail.com> Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Dan Carpenter 提交于
The bug here is this code from ipg_nic_hard_start_xmit(): txfd->tfc &= cpu_to_le64(~IPG_TFC_TFDDONE); IPG_TFC_TFDDONE is 0x0000000080000000 so it's an unsigned int. The negated value is 0x7fffffff but 0xffffffff7fffffff was intended. The other values in this file don't need to be changed but I did it for consistency. Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 15 5月, 2013 7 次提交
-
-
由 Nicolas Ferre 提交于
Commit 749a2b66 (net/macb: clear tx/rx completion flags in ISR) introduces clear-on-write on ISR register. This behavior is not always implemented when using Cadence MACB/GEM and is breaking other platforms. We are using the Design Configuration Register 1 information and a capability property to actually activate this clear-on-write behavior on ISR. Reported-by: NHein Tibosch <hein_tibosch@yahoo.es> Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com> Tested-by: NHein Tibosch <hein_tibosch@yahoo.es> Acked-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Andrew Lunn 提交于
3.10-rc1 issues the following warning: netif_napi_add() called with weight 128 on device eth%d This patch reduce the weight to 64, using NAPI_POLL_WEIGHT. Signed-off-by: NAndrew Lunn <andrew@lunn.ch> Acked-by: NEric Dumazet <edumazet@google.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Sarveshwar Bandi 提交于
Fix to avoid double insertion of vlan tags into the packet while handling an asic workaroud (issue introduced by net next Commit bc0c3405) Signed-off-by: NSarveshwar Bandi <sarveshwar.bandi@emulex.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Ben Hutchings 提交于
efx_start_datapath() asserts that we can fit 2 RX scatter buffers plus a software structure, each appropriately aligned, into a single page. Where L1_CACHE_BYTES == 256 and PAGE_SIZE == 4096, which is the case on s390, this assertion fails. The current scatter buffer size is also not a multiple of 64 or 128, which are more common cache line sizes. If we can make both the start and end of a scatter buffer cache-aligned, this will reduce the need for read-modify-write operations on inter- processor links. Fix the alignment by reducing EFX_RX_USR_BUF_SIZE to 2048 - 256 == 1792. (We could use 2048 - L1_CACHE_BYTES, but EFX_RX_USR_BUF_SIZE also affects user-level networking where a larger amount of housekeeping data may be needed. Although this version of the driver does not support user-level networking, I prefer to keep scattering behaviour consistent with the out-of-tree version.) This still doesn't fix the s390 build because like most architectures it has NET_IP_ALIGN == 2. When NET_IP_ALIGN != 0 we cannot achieve cache line alignment at either the start or end of a scatter buffer, so there is actually no point in padding the buffers to a multiple of the cache line size. All we need is 4-byte alignment of the network header, so do that. Adjust the assertions accordingly. Reported-by: NGeert Uytterhoeven <geert@linux-m68k.org> Reported-by: NHeiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: NBen Hutchings <bhutchings@solarflare.com> Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Ben Hutchings 提交于
The two architectures that define CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS (powerpc and x86) now both define NET_IP_ALIGN as 0, so there is no need for this optimisation any more. Signed-off-by: NBen Hutchings <bhutchings@solarflare.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Michael Chan 提交于
The 5725 family of devices (asic rev 5762), corrupts TSO packets where the buffer is within MSS bytes of a 4G boundary (4G, 8G etc.). Detect this condition and trigger the workaround path. Cc: <stable@vger.kernel.org> Signed-off-by: NMichael Chan <mchan@broadcom.com> Signed-off-by: NNithin Nayak Sujir <nsujir@broadcom.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Nithin Sujir 提交于
On the 5718, 5719 and 5720 serdes devices, powering down function 0 results in all the other ports being powered down. Add code to skip function 0 power down. v2: - Modify tg3_phy_power_bug() function to use a switch instead of a complicated if statement. Suggested by Joe Perches. Cc: <stable@vger.kernel.org> Signed-off-by: NMichael Chan <mchan@broadcom.com> Signed-off-by: NNithin Nayak Sujir <nsujir@broadcom.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 14 5月, 2013 2 次提交
-
-
由 Wei Yongjun 提交于
Add the missing iounmap() before return from bnad_init() in the error handling case. Introduced by commit 01b54b14 (bna: tx rx cleanup fix). Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
qlge allocates chunks from a page that it maps and unmaps that page when the last chunk is released. When the driver is unloaded or the card is removed, all chunks are released and the page is unmapped for the last chunk. However, when the last chunk of a page is not allocated and the device is removed, that page is not unmapped. In fact, its last reference is not put and there's also a page leak. This bug prevents a device from being properly hotplugged. When the DMA API debug option is enabled, the following messages show the pending DMA allocation after we remove the driver. This patch fixes the bug by unmapping and putting the page from the ring if its last chunk has not been allocated. pci 0005:98:00.0: DMA-API: device driver has pending DMA allocations while released from device [count=1] One of leaked entries details: [device address=0x0000000060a80000] [size=65536 bytes] [mapped with DMA_FROM_DEVICE] [mapped as page] ------------[ cut here ]------------ WARNING: at lib/dma-debug.c:746 Modules linked in: qlge(-) rpadlpar_io rpaphp pci_hotplug fuse [last unloaded: qlge] NIP: c0000000003fc3ec LR: c0000000003fc3e8 CTR: c00000000054de60 REGS: c0000003ee9c74e0 TRAP: 0700 Tainted: G O (3.7.2) MSR: 8000000000029032 <SF,EE,ME,IR,DR,RI> CR: 28002424 XER: 00000001 SOFTE: 1 CFAR: c0000000007a39c8 TASK = c0000003ee8d5c90[8406] 'rmmod' THREAD: c0000003ee9c4000 CPU: 31 GPR00: c0000000003fc3e8 c0000003ee9c7760 c000000000c789f8 00000000000000ee GPR04: 0000000000000000 00000000000000ef 0000000000004000 0000000000010000 GPR08: 00000000000000be c000000000b22088 c000000000c4c218 00000000007c0000 GPR12: 0000000028002422 c00000000ff26c80 0000000000000000 000001001b0f1b40 GPR16: 00000000100cb9d8 0000000010093088 c000000000cdf910 0000000000000001 GPR20: 0000000000000000 c000000000dbfc00 0000000000000000 c000000000dbfb80 GPR24: c0000003fafc9d80 0000000000000001 000000000001ff80 c0000003f38f7888 GPR28: c000000000ddfc00 0000000000000400 c000000000bd7790 c000000000ddfb80 NIP [c0000000003fc3ec] .dma_debug_device_change+0x22c/0x2b0 LR [c0000000003fc3e8] .dma_debug_device_change+0x228/0x2b0 Call Trace: [c0000003ee9c7760] [c0000000003fc3e8] .dma_debug_device_change+0x228/0x2b0 (unreliable) [c0000003ee9c7840] [c00000000079a098] .notifier_call_chain+0x78/0xf0 [c0000003ee9c78e0] [c0000000000acc20] .__blocking_notifier_call_chain+0x70/0xb0 [c0000003ee9c7990] [c0000000004a9580] .__device_release_driver+0x100/0x140 [c0000003ee9c7a20] [c0000000004a9708] .driver_detach+0x148/0x150 [c0000003ee9c7ac0] [c0000000004a8144] .bus_remove_driver+0xc4/0x150 [c0000003ee9c7b60] [c0000000004aa58c] .driver_unregister+0x8c/0xe0 [c0000003ee9c7bf0] [c0000000004090b4] .pci_unregister_driver+0x34/0xf0 [c0000003ee9c7ca0] [d000000002231194] .qlge_exit+0x1c/0x34 [qlge] [c0000003ee9c7d20] [c0000000000e36d8] .SyS_delete_module+0x1e8/0x290 [c0000003ee9c7e30] [c0000000000098d4] syscall_exit+0x0/0x94 Instruction dump: 7f26cb78 e818003a e87e81a0 e8f80028 e9180030 796b1f24 78001f24 7d6a5a14 7d2a002a e94b0020 483a7595 60000000 <0fe00000> 2fb80000 40de0048 80120050 ---[ end trace 4294f9abdb01031d ]--- Mapped at: [<d000000002222f54>] .ql_update_lbq+0x384/0x580 [qlge] [<d000000002227bd0>] .ql_clean_inbound_rx_ring+0x300/0xc60 [qlge] [<d0000000022288cc>] .ql_napi_poll_msix+0x39c/0x5a0 [qlge] [<c0000000006b3c50>] .net_rx_action+0x170/0x300 [<c000000000081840>] .__do_softirq+0x170/0x300 Signed-off-by: NThadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com> Acked-by: NJitendra Kalsaria <Jitendra.kalsaria@qlogic.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 12 5月, 2013 13 次提交
-
-
由 Petri Gynther 提交于
Fix EMAC soft reset on 460EX/GT to select the right PHY clock source before and after the soft reset. EMAC with PHY should use the clock from PHY during soft reset. EMAC without PHY should use the internal clock during soft reset. PPC460EX/GT Embedded Processor Advanced User's Manual section 28.10.1 Mode Register 0 (EMACx_MR0) states: Note: The PHY must provide a TX Clk in order to perform a soft reset of the EMAC. If none is present, select the internal clock (SDR0_ETH_CFG[EMACx_PHY_CLK] = 1). After a soft reset, select the external clock. Without the fix, 460EX/GT-based boards with RGMII PHYs attached to EMACs experience EMAC interrupt storm and system watchdog reset when issuing "ifconfig eth0 down" + "ifconfig eth0 up" a few times. The system enters endless loop of serving emac_irq() with EMACx_ISR register stuck at value 0x10000000 (Rx parity error). With the fix, the above issue is no longer observed. Signed-off-by: NPetri Gynther <pgynther@google.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Sergei Shtylyov 提交于
The driver wrongly claimed I/O ports at an address returned by pci_iomap() -- even if it was passed an MMIO address. Fix this by claiming/releasing all PCI resources in the PCI driver's probe()/remove() methods instead and get rid of 'must_free_region' flag weirdness (why would Cardbus claim anything for us?). Signed-off-by: NSergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Geert Uytterhoeven 提交于
If NO_DMA=y: drivers/built-in.o: In function `macb_free_consistent': drivers/net/ethernet/cadence/macb.c:878: undefined reference to `dma_free_coherent' drivers/net/ethernet/cadence/macb.c:883: undefined reference to `dma_free_coherent' drivers/net/ethernet/cadence/macb.c:888: undefined reference to `dma_free_coherent' drivers/built-in.o: In function `macb_alloc_consistent': drivers/net/ethernet/cadence/macb.c:905: undefined reference to `dma_alloc_coherent' drivers/built-in.o: In function `macb_tx_interrupt': drivers/net/ethernet/cadence/macb.c:515: undefined reference to `dma_unmap_single' drivers/built-in.o: In function `macb_tx_error_task': drivers/net/ethernet/cadence/macb.c:457: undefined reference to `dma_unmap_single' drivers/built-in.o: In function `macb_start_xmit': drivers/net/ethernet/cadence/macb.c:838: undefined reference to `dma_map_single' Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org> Cc: Nicolas Ferre <nicolas.ferre@atmel.com> Cc: David S. Miller <davem@davemloft.net> Cc: netdev@vger.kernel.org Acked-by: NNicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Geert Uytterhoeven 提交于
If NO_DMA=y: drivers/built-in.o: In function `at91ether_start': drivers/net/ethernet/cadence/at91_ether.c:49: undefined reference to `dma_alloc_coherent' drivers/net/ethernet/cadence/at91_ether.c:60: undefined reference to `dma_free_coherent' drivers/built-in.o: In function `at91ether_interrupt': drivers/net/ethernet/cadence/at91_ether.c:250: undefined reference to `dma_unmap_single' drivers/built-in.o: In function `at91ether_start_xmit': drivers/net/ethernet/cadence/at91_ether.c:169: undefined reference to `dma_map_single' drivers/built-in.o: In function `at91ether_close': drivers/net/ethernet/cadence/at91_ether.c:145: undefined reference to `dma_free_coherent' Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org> Cc: Nicolas Ferre <nicolas.ferre@atmel.com> Cc: David S. Miller <davem@davemloft.net> Cc: netdev@vger.kernel.org Acked-by: NNicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Geert Uytterhoeven 提交于
If NO_DMA=y: drivers/built-in.o: In function `dma_free_tx_skbufs': drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:1141: undefined reference to `dma_unmap_single' drivers/built-in.o: In function `dma_free_rx_skbufs': drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:1120: undefined reference to `dma_unmap_single' drivers/built-in.o: In function `free_dma_desc_resources': drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:1159: undefined reference to `dma_free_coherent' drivers/built-in.o: In function `stmmac_init_rx_buffers': drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:980: undefined reference to `dma_map_single' drivers/built-in.o: In function `init_dma_desc_rings': drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:1015: undefined reference to `dma_alloc_coherent' drivers/built-in.o: In function `stmmac_tx_clean': drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:1250: undefined reference to `dma_unmap_single' drivers/built-in.o: In function `stmmac_rx': drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2044: undefined reference to `dma_unmap_single' drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2082: undefined reference to `dma_unmap_single' drivers/built-in.o: In function `stmmac_rx_refill': drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:1967: undefined reference to `dma_map_single' drivers/built-in.o: In function `stmmac_xmit': drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:1845: undefined reference to `dma_map_single' drivers/built-in.o: In function `skb_frag_dma_map': include/linux/skbuff.h:2184: undefined reference to `dma_map_page' drivers/built-in.o: In function `stmmac_jumbo_frm': drivers/net/ethernet/stmicro/stmmac/ring_mode.c:40: undefined reference to `dma_map_single' drivers/built-in.o: In function `stmmac_jumbo_frm': drivers/net/ethernet/stmicro/stmmac/chain_mode.c:48: undefined reference to `dma_map_single' drivers/net/ethernet/stmicro/stmmac/chain_mode.c:55: undefined reference to `dma_map_single' Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org> Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com> Cc: David S. Miller <davem@davemloft.net> Cc: netdev@vger.kernel.org Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Geert Uytterhoeven 提交于
If NO_DMA=y: drivers/built-in.o: In function `xgmac_xmit': drivers/net/ethernet/calxeda/xgmac.c:1102: undefined reference to `dma_mapping_error' Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org> Cc: Rob Herring <rob.herring@calxeda.com> Cc: David S. Miller <davem@davemloft.net> Cc: netdev@vger.kernel.org Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Rony Efraim 提交于
Make sure that the following steps are taken: - drop packets sent by the VF with vlan tag - block packets with vlan tag which are steered to the VF - drop/block tagged packets when the policy is priority-tagged - make sure VLAN stripping for received packets is set - make sure force UP bit for the VF QP is set Use enum values for all the above instead of numerical bit offsets. Signed-off-by: NRony Efraim <ronye@mellanox.com> Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Or Gerlitz 提交于
Commits e6b6a231 "net/mlx4: Add VF MAC spoof checking support" and 3f7fb021 "net/mlx4: Add set VF default vlan ID and priority support" missed reporting in the device capabilities dump when these features are actually supported. Also two too noisy debug messages which produce message on every QP opened by a VF, were left in the code, fix that. Signed-off-by: NRony Efraim <ronye@mellanox.com> Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Shawn Guo 提交于
Commit 4c09eed9 (net: fec: Enable imx6 enet checksum acceleration.) enables hardware checksum acceleration unconditionally for all fec variants. This is inappropriate, because some variants like imx5 have no such support on hardware. Consequently, fec is broken on these platforms. Fix it by enabling hardware checksum only on imx6q-fec type of controllers. Signed-off-by: NShawn Guo <shawn.guo@linaro.org> Reviewed-by: NJim Baxter <jim_baxter@mentor.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Rajesh Borundia 提交于
o VF driver that has enabled asynchronous link events may not set BIT_8 in the request, if it does not require link state in the response. Signed-off-by: NPratik Pujar <pratik.pujar@qlogic.com> Signed-off-by: NRajesh Borundia <rajesh.borundia@qlogic.com> Signed-off-by: NShahed Shaikh <shahed.shaikh@qlogic.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Rajesh Borundia 提交于
o Fix mailbox response poll time to maximum 5 seconds which includes mailbox response time as well as time required for processing AEN if any. o Driver need to read firmware control mailbox register instead of host control mailbox register. Signed-off-by: NJitendra Kalsaria <jitendra.kalsaria@qlogic.com> Signed-off-by: NRajesh Borundia <rajesh.borundia@qlogic.com> Signed-off-by: NShahed Shaikh <shahed.shaikh@qlogic.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Manish Chopra 提交于
o In order to perform reset recovery during diagnostics tests, current device status information need to be preserved. This patch makes the required changes in diagnostics routines Signed-off-by: NManish Chopra <manish.chopra@qlogic.com> Signed-off-by: NShahed Shaikh <shahed.shaikh@qlogic.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Sony Chacko 提交于
o When transmit timeout happens, recovery attempt should start with adapter soft reset. If soft reset fails to resume traffic, firmware dump will be collected and driver will perform a hard reset of the adapter. Reset recovery on 83xx was failing after a hard reset. This patch fixes that issue. Signed-off-by: NSony Chacko <sony.chacko@qlogic.com> Signed-off-by: NShahed Shaikh <shahed.shaikh@qlogic.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-