- 12 4月, 2013 1 次提交
-
-
由 nikolay@redhat.com 提交于
In commit 471cb5a3 ("bonding: remove usage of dev->master") a bug was introduced which causes a NULL pointer dereference. If a bond device is in mode 6 (ALB) and a slave is added it will dereference a NULL pointer in bond_slave_netdev_event(). This is because in bond_enslave we have bond_alb_init_slave() which changes the MAC address of the slave and causes a NETDEV_CHANGEADDR. Then we have in bond_slave_netdev_event(): struct slave *slave = bond_slave_get_rtnl(slave_dev); struct bonding *bond = slave->bond; bond_slave_get_rtnl() dereferences slave_dev->rx_handler_data which at that time is NULL since netdev_rx_handler_register() is called later. This is fixed by checking if slave is NULL before dereferencing it. v2: Comment style changed. Signed-off-by: NNikolay Aleksandrov <nikolay@redhat.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 11 4月, 2013 2 次提交
-
-
由 Yuval Mintz 提交于
The cnic module is responsible for initializing various bnx2x structs via callbacks provided by the bnx2x module. One such struct is the queue object for the FCoE queue. If a device is working in AFEX mode and its configuration allows FCoE yet the cnic module is not loaded, it's very likely a null pointer dereference will occur, as the bnx2x will erroneously access the FCoE's queue object. Prevent said access until cnic properly registers itself. Signed-off-by: NYuval Mintz <yuvalmin@broadcom.com> Signed-off-by: NAriel Elior <ariele@broadcom.com> Signed-off-by: NEilon Greenstein <eilong@broadcom.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Neil Horman 提交于
e100 uses pci_map_single, but fails to check for a dma mapping error after its use, resulting in a stack trace: [ 46.656594] ------------[ cut here ]------------ [ 46.657004] WARNING: at lib/dma-debug.c:933 check_unmap+0x47b/0x950() [ 46.657004] Hardware name: To Be Filled By O.E.M. [ 46.657004] e100 0000:00:0e.0: DMA-API: device driver failed to check map error[device address=0x000000007a4540fa] [size=90 bytes] [mapped as single] [ 46.657004] Modules linked in: [ 46.657004] w83627hf hwmon_vid snd_via82xx ppdev snd_ac97_codec ac97_bus snd_seq snd_pcm snd_mpu401 snd_mpu401_uart ns558 snd_rawmidi gameport parport_pc e100 snd_seq_device parport snd_page_alloc snd_timer snd soundcore skge shpchp k8temp mii edac_core i2c_viapro edac_mce_amd nfsd auth_rpcgss nfs_acl lockd sunrpc binfmt_misc uinput ata_generic pata_acpi radeon i2c_algo_bit drm_kms_helper ttm firewire_ohci drm firewire_core pata_via sata_via i2c_core sata_promise crc_itu_t [ 46.657004] Pid: 792, comm: ip Not tainted 3.8.0-0.rc6.git0.1.fc19.x86_64 #1 [ 46.657004] Call Trace: [ 46.657004] <IRQ> [<ffffffff81065ed0>] warn_slowpath_common+0x70/0xa0 [ 46.657004] [<ffffffff81065f4c>] warn_slowpath_fmt+0x4c/0x50 [ 46.657004] [<ffffffff81364cfb>] check_unmap+0x47b/0x950 [ 46.657004] [<ffffffff8136522f>] debug_dma_unmap_page+0x5f/0x70 [ 46.657004] [<ffffffffa030f0f0>] ? e100_tx_clean+0x30/0x210 [e100] [ 46.657004] [<ffffffffa030f1a8>] e100_tx_clean+0xe8/0x210 [e100] [ 46.657004] [<ffffffffa030fc6f>] e100_poll+0x56f/0x6c0 [e100] [ 46.657004] [<ffffffff8159dce1>] ? net_rx_action+0xa1/0x370 [ 46.657004] [<ffffffff8159ddb2>] net_rx_action+0x172/0x370 [ 46.657004] [<ffffffff810703bf>] __do_softirq+0xef/0x3d0 [ 46.657004] [<ffffffff816e4ebc>] call_softirq+0x1c/0x30 [ 46.657004] [<ffffffff8101c485>] do_softirq+0x85/0xc0 [ 46.657004] [<ffffffff81070885>] irq_exit+0xd5/0xe0 [ 46.657004] [<ffffffff816e5756>] do_IRQ+0x56/0xc0 [ 46.657004] [<ffffffff816dacb2>] common_interrupt+0x72/0x72 [ 46.657004] <EOI> [<ffffffff816da1eb>] ? _raw_spin_unlock_irqrestore+0x3b/0x70 [ 46.657004] [<ffffffff816d124d>] __slab_free+0x58/0x38b [ 46.657004] [<ffffffff81214424>] ? fsnotify_clear_marks_by_inode+0x34/0x120 [ 46.657004] [<ffffffff811b0417>] ? kmem_cache_free+0x97/0x320 [ 46.657004] [<ffffffff8157fc14>] ? sock_destroy_inode+0x34/0x40 [ 46.657004] [<ffffffff8157fc14>] ? sock_destroy_inode+0x34/0x40 [ 46.657004] [<ffffffff811b0692>] kmem_cache_free+0x312/0x320 [ 46.657004] [<ffffffff8157fc14>] sock_destroy_inode+0x34/0x40 [ 46.657004] [<ffffffff811e8c28>] destroy_inode+0x38/0x60 [ 46.657004] [<ffffffff811e8d5e>] evict+0x10e/0x1a0 [ 46.657004] [<ffffffff811e9605>] iput+0xf5/0x180 [ 46.657004] [<ffffffff811e4338>] dput+0x248/0x310 [ 46.657004] [<ffffffff811ce0e1>] __fput+0x171/0x240 [ 46.657004] [<ffffffff811ce26e>] ____fput+0xe/0x10 [ 46.657004] [<ffffffff8108d54c>] task_work_run+0xac/0xe0 [ 46.657004] [<ffffffff8106c6ed>] do_exit+0x26d/0xc30 [ 46.657004] [<ffffffff8109eccc>] ? finish_task_switch+0x7c/0x120 [ 46.657004] [<ffffffff816dad58>] ? retint_swapgs+0x13/0x1b [ 46.657004] [<ffffffff8106d139>] do_group_exit+0x49/0xc0 [ 46.657004] [<ffffffff8106d1c4>] sys_exit_group+0x14/0x20 [ 46.657004] [<ffffffff816e3b19>] system_call_fastpath+0x16/0x1b [ 46.657004] ---[ end trace 4468c44e2156e7d1 ]--- [ 46.657004] Mapped at: [ 46.657004] [<ffffffff813663d1>] debug_dma_map_page+0x91/0x140 [ 46.657004] [<ffffffffa030e8eb>] e100_xmit_prepare+0x12b/0x1c0 [e100] [ 46.657004] [<ffffffffa030c924>] e100_exec_cb+0x84/0x140 [e100] [ 46.657004] [<ffffffffa030e56a>] e100_xmit_frame+0x3a/0x190 [e100] [ 46.657004] [<ffffffff8159ee89>] dev_hard_start_xmit+0x259/0x6c0 Easy fix, modify the cb paramter to e100_exec_cb to return an error, and do the dma_mapping_error check in the obvious place This was reported previously here: http://article.gmane.org/gmane.linux.network/257893 But nobody stepped up and fixed it. CC: Josh Boyer <jwboyer@redhat.com> CC: e1000-devel@lists.sourceforge.net Signed-off-by: NNeil Horman <nhorman@tuxdriver.com> Reported-by: NMichal Jaegermann <michal@harddata.com> Tested-by: NAaron Brown <aaron.f.brown@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 09 4月, 2013 5 次提交
-
-
由 nikolay@redhat.com 提交于
While the bonding module is unloading, it is considered that after rtnl_link_unregister all bond devices are destroyed but since no synchronization mechanism exists, a new bond device can be created via bonding_masters before unregister_pernet_subsys which would lead to multiple problems (e.g. NULL pointer dereference, wrong RIP, list corruption). This patch fixes the issue by removing any bond devices left in the netns after bonding_masters is removed from sysfs. Signed-off-by: NNikolay Aleksandrov <nikolay@redhat.com> Acked-by: NVeaceslav Falico <vfalico@redhat.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 nikolay@redhat.com 提交于
This reverts commit 4de79c73. This patch introduces a new bug which causes access to freed memory. In bond_uninit: list_del(&bond->bond_list); bond_list is linked in bond_net's dev_list which is freed by unregister_pernet_subsys. Signed-off-by: NNikolay Aleksandrov <nikolay@redhat.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 willy tarreau 提交于
It seems that the reason why the dev features were ignored was because they were enabled after registeration. Signed-off-by: NWilly Tarreau <w@1wt.eu> Acked-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Haiyang Zhang 提交于
In some cases, the VM_PKT_COMP message can arrive later than RNDIS completion message, which will free the packet memory. This may cause panic due to access to freed memory in netvsc_send_completion(). This patch fixes this problem by removing rndis_filter_send_request_completion() from the code path. The function was a no-op. Reported-by: NLong Li <longli@microsoft.com> Tested-by: NLong Li <longli@microsoft.com> Signed-off-by: NHaiyang Zhang <haiyangz@microsoft.com> Reviewed-by: NK. Y. Srinivasan <kys@microsoft.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Haiyang Zhang 提交于
The warning about local_bh_enable inside IRQ happens when disconnecting a virtual NIC. The reason for the warning is -- netif_tx_disable() is called when the NIC is disconnected. And it's called within irq context. netif_tx_disable() calls local_bh_enable() which displays warning if in irq. The fix is to remove the unnecessary netif_tx_disable & wake_queue() in the netvsc_linkstatus_callback(). Reported-by: NRichard Genoud <richard.genoud@gmail.com> Tested-by: NLong Li <longli@microsoft.com> Tested-by: NRichard Genoud <richard.genoud@gmail.com> Signed-off-by: NHaiyang Zhang <haiyangz@microsoft.com> Reviewed-by: NK. Y. Srinivasan <kys@microsoft.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 08 4月, 2013 1 次提交
-
-
由 Yaniv Rosner 提交于
Check KR2 recovery time at the beginning of the work-around function. Signed-off-by: NYaniv Rosner <yanivr@broadcom.com> Signed-off-by: NEilon Greenstein <eilong@broadcom.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 05 4月, 2013 4 次提交
-
-
由 Jakub Kicinski 提交于
ixgbe_notify_dca cannot be called before driver registration because it expects driver's klist_devices to be allocated and initialized. While on it make sure debugfs files are removed when registration fails. Cc: stable <stable@vger.kernel.org> Signed-off-by: NJakub Kicinski <jakub.kicinski@intel.com> Tested-by: NPhil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Veaceslav Falico 提交于
We have a race condition if we try to rmmod bonding and simultaneously add a bond master through sysfs. In bonding_exit() we first remove the devices (through rtnl_link_unregister() ) and only after that we remove the sysfs. If we manage to add a device through sysfs after that the devices were removed - we'll end up with that device/sysfs structure and with the module unloaded. Fix this by first removing the sysfs and only after that calling rtnl_link_unregister(). Signed-off-by: NVeaceslav Falico <vfalico@redhat.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Hannes Frederic Sowa 提交于
The limit of 0x3c00 is taken from the windows driver. Suggested-by: NHuang, Xiong <xiong@qca.qualcomm.com> Cc: Huang, Xiong <xiong@qca.qualcomm.com> Cc: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: NHannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 hayeswang 提交于
It would cause no link after suspending or shutdowning when the nic changes the speed to 10M and connects to a link partner which forces the speed to 100M. Check the link partner ability to determine which speed to set. Signed-off-by: NHayes Wang <hayeswang@realtek.com> Acked-by: NFrancois Romieu <romieu@fr.zoreil.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 04 4月, 2013 8 次提交
-
-
由 Gabor Juhos 提交于
The rt2800pci driver supports the built-in wireless MAC of the Ralink RT3x5x SoCs. However building the driver for these SoCs leads to the following error: LD init/built-in.o drivers/built-in.o: In function `rt2800pci_rxdone_tasklet': <...>/drivers/net/wireless/rt2x00/rt2800pci.c:1012: undefined reference to `rt2x00pci_rxdone' drivers/built-in.o:(.rodata+0x4780): undefined reference to `rt2x00pci_initialize' drivers/built-in.o:(.rodata+0x4784): undefined reference to `rt2x00pci_uninitialize' drivers/built-in.o:(.rodata+0x47bc): undefined reference to `rt2x00pci_flush_queue' drivers/built-in.o:(.rodata+0x4818): undefined reference to `rt2x00pci_regbusy_read' make[5]: *** [vmlinux] Error 1 The missing functions are provided by the rt2x00pci module. This module is only selected by the rt2800pci driver if PCI support is enabled in the kernel, because some parts of the rt2x00pci code depends on PCI support. PCI support is not available on the RT3x5x SoCs because those have no PCI host controller at all. Move the non PCI specific code from rt2x00pci into a separate module. This makes it possible to use that code even if PCI support is disabled. The affected functions are used by all of the rt2x00 PCI drivers so select the new module for those drivers. Signed-off-by: NGabor Juhos <juhosg@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Tim Gardner 提交于
BugLink: http://bugs.launchpad.net/bugs/1128840 It appears that when this register read fails it never recovers, so I think there is no need to repeat the same error message ad infinitum. Cc: Ivo van Doorn <IvDoorn@gmail.com> Cc: Gertjan van Wingerde <gwingerde@gmail.com> Cc: Helmut Schaa <helmut.schaa@googlemail.com> Cc: "John W. Linville" <linville@tuxdriver.com> Cc: linux-wireless@vger.kernel.org Cc: users@rt2x00.serialmonkey.com Cc: netdev@vger.kernel.org Cc: stable@vger.kernel.org Signed-off-by: NTim Gardner <tim.gardner@canonical.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Robert Shade 提交于
ath_complete_reset will not be called if ath9k_hw_reset is unsuccessful, so we need to re-enable intertupts to balence the previous ath_prepare_reset call. Also schedule a reset as a best effort method to recover the chip from whatever state caused the channel change failure. Fixes https://bugzilla.kernel.org/show_bug.cgi?id=55771Signed-off-by: NRobert Shade <robert.shade@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Franky Lin 提交于
Nvram contains critical initialization parameter for firmware to run. Host driver should not proceed if nvram fails to be downloaded to dongle. Reviewed-by: NPiotr Haber <phaber@broadcom.com> Reviewed-by: NArend van Spriel <arend@broadcom.com> Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com> Signed-off-by: NFranky Lin <frankyl@broadcom.com> Signed-off-by: NArend van Spriel <arend@broadcom.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Hante Meuleman 提交于
When multiple cipher suites have been programmed then the lowest suite is to be retured. This fixes issue when AP mode is using CCMP and TKIP WPA combination where rekeying will fail. Reviewed-by: NArend Van Spriel <arend@broadcom.com> Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com> Reviewed-by: NPiotr Haber <phaber@broadcom.com> Signed-off-by: NHante Meuleman <meuleman@broadcom.com> Signed-off-by: NArend van Spriel <arend@broadcom.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Hante Meuleman 提交于
on stop_ap the dongle was not properly shutdown. As a result it was not possible to restart AP or STA after AP operation without restarting the device. This patch will fix that. Reviewed-by: NArend Van Spriel <arend@broadcom.com> Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com> Reviewed-by: NPiotr Haber <phaber@broadcom.com> Signed-off-by: NHante Meuleman <meuleman@broadcom.com> Signed-off-by: NArend van Spriel <arend@broadcom.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Hante Meuleman 提交于
tx and rx michael tkip keys are always swapped in case being configured per mac. This is wrong for AP. The swap should only be done for STA mode. Reviewed-by: NArend Van Spriel <arend@broadcom.com> Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com> Reviewed-by: NPiotr Haber <phaber@broadcom.com> Signed-off-by: NHante Meuleman <meuleman@broadcom.com> Signed-off-by: NArend van Spriel <arend@broadcom.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Bing Zhao 提交于
We are waiting on first scan command of internal scan request before association, so we should complete on last internal scan command response. Cc: <stable@vger.kernel.org> # 3.8 Tested-by: NDaniel Drake <dsd@laptop.org> Tested-by: NMarco Cesarano <marco@marvell.com> Signed-off-by: NBing Zhao <bzhao@marvell.com> Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 03 4月, 2013 2 次提交
-
-
由 Yan Burman 提交于
Commit 6bbb6d99 "net/mlx4_en: Optimize Rx fast path filter checks" introduced a regression under which the MAC address read from the card was not converted correctly (the most significant byte was not handled), fix that. Reviewed-by: NOr Gerlitz <ogerlitz@mellanox.com> Signed-off-by: NYan Burman <yanb@mellanox.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Veaceslav Falico 提交于
Now that netdev_rx_handler_unregister contains synchronize_net(), we need to call it outside of bond->lock, cause it might sleep. Also, remove the already unneded synchronize_net(). Signed-off-by: NVeaceslav Falico <vfalico@redhat.com> Acked-by: NEric Dumazet <edumazet@google.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 02 4月, 2013 1 次提交
-
-
由 Stone Piao 提交于
Limit the channel number in scan request, or the driver scan config structure memory will be overflowed. Cc: <stable@vger.kernel.org> # 3.5+ Signed-off-by: NStone Piao <piaoyun@marvell.com> Signed-off-by: NBing Zhao <bzhao@marvell.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 01 4月, 2013 4 次提交
-
-
由 Joseph CHANG 提交于
Fix bug for DM9000 revision B which contain a DSP PHY DM9000B use DSP PHY instead previouse DM9000 revisions' analog PHY, So need extra change in initialization, For explicity PHY Reset and PHY init parameter, and first DM9000_NCR reset need NCR_MAC_LBK bit by dm9000_probe(). Following DM9000_NCR reset cause by dm9000_open() clear the NCR_MAC_LBK bit. Without this fix, Power-up FIFO pointers error happen around 2% rate among Davicom's customers' boards. With this fix, All above cases can be solved. Signed-off-by: NJoseph CHANG <josright123@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Sergei Shtylyov 提交于
The 'link' field of 'struct sh_eth_private' has type 'enum phy_state' while the 'link' field of 'struct phy_device' is merely *int* (having values 0 and 1) and the former field gets assigned from the latter. Make the field match, getting rid of incorrectly used PHY_DOWN value in assignments/comparisons. Signed-off-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Sergei Shtylyov 提交于
At least on Renesas R8A7778, EESR.ECI interrupt seems to fire regardless of its mask in EESIPR register. I can 100% reproduce it with the following scenario: target is booted with 'ip=on' option, and so IP-Config opens SoC Ether device but doesn't get a proper reply and then succeeds with on-board SMC chip; then I login and try to bring up the SoC Ether device with 'ifconfig', and I get an ECI interrupt once request_irq() is called by sh_eth_open() (while interrupt mask in EESIPR register is all 0), if that interrupt is accompanied by a pending EESR.FRC (frame receive completion) interrupt, I get kernel oops in sh_eth_rx() because sh_eth_ring_init() hasn't been called yet! The solution I worked out is the following: in sh_eth_interrupt(), mask the interrupt status from EESR register with the interrupt mask from EESIPR register in order not to handle the disabled interrupts -- but forcing EESIPR.M_ECI bit in this mask set because we always need to fully handle EESR.ECI interrupt in sh_eth_error() in order to quench it (as it doesn't get cleared by just writing 1 to the this bit as all the other interrupts). While at it, remove unneeded initializer for 'intr_status' variable and give it *unsigned long* type, matching the type of sh_eth_read()'s result; fix comment. Signed-off-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com> Reviewed-by: NMax Filippov <max.filippov@cogentembedded.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Sergei Shtylyov 提交于
The code handling the absent LINK signal (or the absent PSR register -- which reflects the state of this signal) is quite naive and has probably never really worked. It's probably enough to say that this code is executed only on the LINK change interrupt (sic!) but even if we actually have the signal and choose to ignore it (it might be connected to PHY's link/activity LED output as on the Renesas BOCK-W board), sh_eth_adjust_link() on which this code relies to update 'mdp->link' gets executed later than the LINK change interrupt where it is checked, and so RX/TX never get enabled via ECMR register. So, ignore the LINK changed interrupt iff LINK signal is absent (or just chosen not to be used) or PSR register is absent, and enable/disable RX/TX directly in sh_eth_adjust_link() in this case. Signed-off-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 30 3月, 2013 8 次提交
-
-
According to the Datasheet (page 52): 15-12 Reserved 11-0 RXBC Receive Byte Count This field indicates the present received frame byte size. The code has a bug: rxh = ks8851_rdreg32(ks, KS_RXFHSR); rxstat = rxh & 0xffff; rxlen = rxh >> 16; // BUG!!! 0xFFF mask should be applied Signed-off-by: NMax Nekludov <Max.Nekludov@us.elster.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Hannes Frederic Sowa 提交于
Usage of pci-msi results in corrupted dma packet transfers to the host. Reported-by: Nrebelyouth <rebelyouth.hacklab@gmail.com> Cc: Huang, Xiong <xiong@qca.qualcomm.com> Tested-by: NChristian Sünkenberg <christian.suenkenberg@student.kit.edu> Signed-off-by: NHannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Rob Herring 提交于
WOL is broken because the magic packet status bit is getting set rather than the enable bit. The PMT interrupt is not getting serviced because the PMT interrupt is also enabled on the global interrupt, but not cleared by the global interrupt and the global interrupt is higher priority. This fixes both of these issues to get WOL working. There's still a problem with receive after resume, but at least now we can wake-up. Signed-off-by: NRob Herring <rob.herring@calxeda.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Rob Herring 提交于
If skb allocation for the rx ring fails repeatedly, we can reach a point were the ring is empty. In this condition, the driver is out of sync with the h/w. While this has always been possible, the removal of the skb recycling seems to have made triggering this problem easier. Signed-off-by: NRob Herring <rob.herring@calxeda.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Steve Glendinning 提交于
This patch enables RX of jumbo frames for LAN7500. Previously the driver would transmit jumbo frames succesfully but would drop received jumbo frames (incrementing the interface errors count). With this patch applied the device can succesfully receive jumbo frames up to MTU 9000 (9014 bytes on the wire including ethernet header). Signed-off-by: NSteve Glendinning <steve.glendinning@shawell.net> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 nikolay@redhat.com 提交于
Currently if either arp_interval or miimon is disabled, they both get disabled, and upon disabling they get executed once more which is not the proper behaviour. Also when doing a no-op and disabling an already disabled one, the other again gets disabled. Also fix the error messages with the proper valid ranges, and a small typo fix in the up delay error message (outputting "down delay", instead of "up delay"). Signed-off-by: NNikolay Aleksandrov <nikolay@redhat.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Mirko Lindner 提交于
The sky2 driver sets the Rx Upper Threshold for Pause Packet generation to a wrong value which leads to only 2kB of RAM remaining space. This can lead to Rx overflow errors even with activated flow-control. Fix: We should increase the value to 8192/8 Signed-off-by: NMirko Lindner <mlindner@marvell.com> Acked-by: NStephen Hemminger <stephen@networkplumber.org> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Mirko Lindner 提交于
The sky2 driver doesn't count the Receive Overflows because the MAC interrupt for this event is not set in the MAC's interrupt mask. The MAC's interrupt mask is set only for Transmit FIFO Underruns. Fix: The correct setting should be (GM_IS_TX_FF_UR | GM_IS_RX_FF_OR) Otherwise the Receive Overflow event will not generate any interrupt. The Receive Overflow interrupt is handled correctly Signed-off-by: NMirko Lindner <mlindner@marvell.com> Acked-by: NStephen Hemminger <stephen@networkplumber.org> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 28 3月, 2013 4 次提交
-
-
由 Johannes Berg 提交于
Alex Romosan reported that since the mac80211 changes in "mac80211: start auth/assoc timeout on frame status" and the subsequent fixes in "mac80211: fix auth/assoc timeout handling" (commits 1672c0e3 and 89afe614) there's sometimes an issue connecting to a 5 GHz network with the iwlwifi DVM driver. The reason appears to be that since these commits any bad TX status makes mac80211 immediately try again, causing all of the authentication attempts to be quickly rejected by the firmware as it hasn't heard a beacon yet. Before, it would wait for the timeout regardless of status. To fix this, invoke the passive-no-RX workaround when not associated yet as well. This will cause the first frame to get lost, but then the driver will stop the queues and the second attempt will only be transmitted after hearing a beacon, thus delaying it appropriately to not make the firmware reject it again. Reported-by: NAlex Romosan <romosan@sycorax.lbl.gov> Tested-by: NAlex Romosan <romosan@sycorax.lbl.gov> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Kees Cook 提交于
Commit 184b8904 ("tg3: Use VPD fw version when present") introduced VPD parsing that contained a potential length overflow. Limit the hardware's reported firmware string length (max 255 bytes) to stay inside the driver's firmware string length (32 bytes). On overflow, truncate the formatted firmware string instead of potentially overwriting portions of the tg3 struct. http://cansecwest.com/slides/2013/PrivateCore%20CSW%202013.pdfSigned-off-by: NKees Cook <keescook@chromium.org> Reported-by: NOded Horovitz <oded@privatecore.com> Reported-by: NBrad Spengler <spender@grsecurity.net> Cc: stable@vger.kernel.org Cc: Matt Carlson <mcarlson@broadcom.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Mugunthan V N 提交于
To restart tx queue use netif_wake_queue() intead of netif_start_queue() so that net schedule will restart transmission immediately which will increase network performance while doing huge data transfers. Reported-by: NDan Franke <dan.franke@schneider-electric.com> Suggested-by: NSriramakrishnan A G <srk@ti.com> Signed-off-by: NMugunthan V N <mugunthanvnm@ti.com> Acked-by: NEric Dumazet <edumazet@google.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Mugunthan V N 提交于
To restart tx queue use netif_wake_queue() intead of netif_start_queue() so that net schedule will restart transmission immediately which will increase network performance while doing huge data transfers. Reported-by: NDan Franke <dan.franke@schneider-electric.com> Suggested-by: NSriramakrishnan A G <srk@ti.com> Signed-off-by: NMugunthan V N <mugunthanvnm@ti.com> Acked-by: NEric Dumazet <edumazet@google.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-