04 Nov, 2010
2 commits
-
Signed-off-by: Sjur Braendeland
Signed-off-by: David S. Miller -
The SMSC911x supports 128 x 8-bit EEPROMs. Increase the EEPROM size
so more than just the MAC address can be stored.Signed-off-by: John Faith
Signed-off-by: David S. Miller
02 Nov, 2010
4 commits
-
Stopping TX queues at driver load time is not necessary.
Signed-off-by: Casey Leedom
Signed-off-by: David S. Miller -
Remove racy queue stopping after device registration.
Signed-off-by: Dimitris Michailidis
Signed-off-by: David S. Miller -
Remove racy queue stopping after device registration.
Signed-off-by: Divy Le Ray
Signed-off-by: David S. Miller -
Crash is triggered by commit e6484930d7 ("net: allocate tx queues in
register_netdevice"), which moved tx netqueue creation into register_netdev.
So now calling netif_stop_queue() before register_netdev causes an oops.
Move netif_stop_queue() after net device registration to fix crash.Signed-off-by: Dmitry Artamonow
Signed-off-by: Denis Kirjanov
Signed-off-by: David S. Miller
01 Nov, 2010
13 commits
-
Touching the queue state before register_netdev is not
allowed, and besides the queue state before ->open()
is "don't care"Reported-by: Josh Boyer
Reported-by: Stephen Rothwell
Signed-off-by: David S. Miller -
Since usbnet already took usb runtime pm, we have to
enable runtime pm for usb interface of usbnet, otherwise
usb_autopm_get_interface may return failure and cause
'ifconfig usb0 up' failed if USB_SUSPEND(RUNTIME_PM) is
enabled.Cc: David Brownell
Cc: Greg Kroah-Hartman
Cc: "David S. Miller"
Cc: Ben Hutchings
Cc: Joe Perches
Cc: Oliver Neukum
Cc: Andy Shevchenko
Cc: stable@kernel.org
Signed-off-by: Ming Lei
Signed-off-by: David S. Miller -
I'm a bit unsure about this patch. I'm unable to parse both statements.
Cc: netdev@vger.kernel.org
Signed-off-by: Uwe Kleine-König
Signed-off-by: David S. Miller -
Update bnx2x version number.
Signed-off-by: Yaniv Rosner
Signed-off-by: Eilon Greenstein
Signed-off-by: David S. Miller -
Resetting 8073 during common init is required on boards in which the
8073 reset pin is not asserted by default.Signed-off-by: Yaniv Rosner
Signed-off-by: Eilon Greenstein
Signed-off-by: David S. Miller -
Enabling CL37 BAM on BCM8073 by default may lead to link issues since
not all switches support it. So enable CL37 BAM only if explicitly
selected.Signed-off-by: Yaniv Rosner
Signed-off-by: Eilon Greenstein
Signed-off-by: David S. Miller -
On BCM8726 based designs, the ports are swapped, hence the reset needs
to be asserted through port0 and not port1.Signed-off-by: Yaniv Rosner
Signed-off-by: Eilon Greenstein
Signed-off-by: David S. Miller -
When using latch indication for link change notification, need to
clear it when port is unloaded, otherwise it might generate false
indication on next load.Signed-off-by: Yaniv Rosner
Signed-off-by: Eilon Greenstein
Signed-off-by: David S. Miller -
On E2 flavor, dual-port mode, the port argument used for some
functions is needed as the global port number rather than the port per
path.Signed-off-by: Yaniv Rosner
Signed-off-by: Eilon Greenstein
Signed-off-by: David S. Miller -
BCM848x3 requires additional of 50ms after reset done indication,
instead of fixed time of 200msSigned-off-by: Yaniv Rosner
Signed-off-by: Eilon Greenstein
Signed-off-by: David S. Miller -
Fix delay during BMAC reset from 10usec to 1ms.
Signed-off-by: Yaniv Rosner
Signed-off-by: Eilon Greenstein
Signed-off-by: David S. Miller -
Its now illegal to call netif_stop_queue() before register_netdev()
Signed-off-by: Eric Dumazet
Cc: Amit Kumar Salecha
Signed-off-by: David S. Miller -
Its now illegal to call netif_stop_queue() before register_netdev()
Signed-off-by: Eric Dumazet
Cc: Guo-Fu Tseng
Signed-off-by: David S. Miller
31 Oct, 2010
8 commits
-
Structure mISDN_devinfo is copied to userland with the field "name"
that has the last elements unitialized. It leads to leaking of
contents of kernel stack memory.Signed-off-by: Vasiliy Kulikov
Signed-off-by: David S. Miller -
My old mail address doesn't exist anymore. This changes all occurrences
to my new address.Signed-off-by: Hans J. Koch
Signed-off-by: David S. Miller -
pcnet_cs:
add new_id: "corega Ether CF-TD" 10Base-T PCMCIA card.Signed-off-by: Ken Kawasaki
Signed-off-by: David S. Miller -
This patch fixes the following section mismatch warning:
WARNING: drivers/net/can/pch_can.o(.data+0x18):
Section mismatch in reference from the variable pch_can_pcidev
to the variable .devinit.rodata:pch_pci_tbl
The variable pch_can_pcidev references
the variable __devinitconst pch_pci_tblThis is actually a false positive which is fixed by giving the offending
variable a whitelisted name, it's renamed to "pch_can_pci_driver".
This makes sense because the variable is of the type "struct pci_driver".Signed-off-by: Marc Kleine-Budde
Acked-by: Uwe Kleine-König
Signed-off-by: David S. Miller -
This patch fixes the following sparse warning:
drivers/net/can/pch_can.c:231:26: warning: incorrect type in argument 1 (different address spaces)
drivers/net/can/pch_can.c:231:26: expected unsigned int [usertype] *addr
drivers/net/can/pch_can.c:231:26: got unsigned int [noderef] *Let pch_can_bit_{set,clear} first parameter be a void __iomem pointer.
Signed-off-by: Marc Kleine-Budde
Signed-off-by: David S. Miller -
We should not stop the egress queue during probe because it is wrong.
Signed-off-by: Denis Kirjanov
Signed-off-by: David S. Miller -
Noticed by sparse:
drivers/net/vmxnet3/vmxnet3_drv.c:876:38: warning: cast from restricted __be16
drivers/net/vmxnet3/vmxnet3_drv.c:876:38: warning: cast from restricted __be16
drivers/net/vmxnet3/vmxnet3_drv.c:876:24: warning: restricted __be16 degrades to integerSigned-off-by: Harvey Harrison
Signed-off-by: David S. Miller -
readl/writel swap to little-endian internally.
Signed-off-by: Harvey Harrison
Signed-off-by: David S. Miller
30 Oct, 2010
5 commits
-
The marvell 88ec048's official part number is 88e1318s. This patch renames
definitions in the driver to reflect this.In addition, a minor bug fix has been added to write back the MSCR1 register
value properly.Signed-off-by: Cyril Chemparathy
Signed-off-by: David S. Miller -
On module removal, the sdio version of b43 generates the following warning:
[ 851.560519] ------------[ cut here ]------------
[ 851.560531] WARNING: at drivers/mmc/core/core.c:237 mmc_wait_for_cmd+0x88/0x90()
[ 851.560534] Hardware name: 20552PG
[ 851.560536] Modules linked in: b43(-) ssb mmc_block binfmt_misc rfcomm sco bnep ppdev l2cap ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ipt_REJECT xt_tcpudp iptable_filter ip_tables x_tables bridge stp kvm_intel kvm arc4 iwlagn snd_hda_codec_conexant snd_hda_intel snd_hda_codec iwlcore snd_hwdep snd_pcm thinkpad_acpi mac80211 snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq r852 joydev snd_timer sm_common pcmcia nand snd_seq_device cfg80211 sdhci_pci btusb psmouse tpm_tis yenta_socket nand_ids lp snd pcmcia_rsrc nand_ecc bluetooth sdhci tpm pcmcia_core parport mtd snd_page_alloc serio_raw tpm_bios soundcore nvram led_class sha256_generic aes_i586 aes_generic dm_crypt i915 drm_kms_helper drm ahci intel_agp i2c_algo_bit intel_gtt e1000e libahci video agpgart output
[ 851.560620] Pid: 2504, comm: rmmod Not tainted 2.6.36-titan0+ #1
[ 851.560622] Call Trace:
[ 851.560631] [] warn_slowpath_common+0x72/0xa0
[ 851.560636] [] ? mmc_wait_for_cmd+0x88/0x90
[ 851.560641] [] ? mmc_wait_for_cmd+0x88/0x90
[ 851.560645] [] warn_slowpath_null+0x22/0x30
[ 851.560649] [] mmc_wait_for_cmd+0x88/0x90
[ 851.560655] [] ? device_release+0x25/0x80
[ 851.560660] [] mmc_io_rw_direct_host+0xa0/0x150
[ 851.560665] [] mmc_io_rw_direct+0x30/0x40
[ 851.560669] [] sdio_disable_func+0x37/0xa0
[ 851.560683] [] b43_sdio_remove+0x30/0x50 [b43]
[ 851.560687] [] sdio_bus_remove+0x1c/0x60
[ 851.560692] [] ? blocking_notifier_call_chain+0x1f/0x30
[ 851.560697] [] __device_release_driver+0x51/0xb0
[ 851.560701] [] driver_detach+0x8f/0xa0
[ 851.560705] [] bus_remove_driver+0x63/0xa0
[ 851.560709] [] driver_unregister+0x49/0x80
[ 851.560713] [] ? driver_unregister+0x49/0x80
[ 851.560718] [] sdio_unregister_driver+0x17/0x20
[ 851.560727] [] b43_sdio_exit+0x12/0x20 [b43]
[ 851.560734] [] b43_exit+0x17/0x3c [b43]
[ 851.560740] [] sys_delete_module+0x13d/0x200
[ 851.560747] [] ? do_munmap+0x212/0x300
[ 851.560752] [] sysenter_do_call+0x12/0x28
[ 851.560757] ---[ end trace 31e14488072d2f7d ]---
[ 851.560759] ------------[ cut here ]------------The warning is caused by b43 not claiming the device before calling
sdio_disable_func().Signed-off-by: Larry Finger
Reported-by: Arnd Hannemann
Tested-by: Arnd Hannemann
Cc: Stable
Signed-off-by: John W. Linville -
For the SD8686, we cannot rely on the scratch register to read the firmware
load status, because the same register is used for storing RX packet length.
Broaden the check to account for this.The module can now be unloaded/reloaded successfully.
Based on the implementation from libertas_tf.
Signed-off-by: Daniel Drake
Acked-by: Dan Williams
Signed-off-by: Steve deRosier
Signed-off-by: John W. Linville -
The index variable to access the rate flags should be obtained from the
inner loop counter which corresponds to the rate table structure.This
fixes the invalid rate selection i.e when the supported basic rate is
invalid on a particular band and also the following warning message.
Thanks to Raj for finding this out.Call Trace:
[] warn_slowpath_common+0x7a/0xb0
[] warn_slowpath_null+0x15/0x20
[] ath_get_rate+0x595/0x5b0 [ath9k]
[] ? cpumask_next_and+0x36/0x50
[] rate_control_get_rate+0x86/0x160 [mac80211]
[] invoke_tx_handlers+0x81c/0x12d0 [mac80211]
[] ieee80211_tx+0x89/0x2b0 [mac80211]
[] ? pskb_expand_head+0x1cc/0x1f0
[] ieee80211_xmit+0xb5/0x1c0 [mac80211]
[] ieee80211_tx_skb+0x4f/0x60 [mac80211]
[] ieee80211_send_nullfunc+0x46/0x60 [mac80211]
[] ieee80211_offchannel_stop_station+0x107/0x150
[mac80211][] ? pskb_expand_head+0x1cc/0x1f0
[] ieee80211_xmit+0xb5/0x1c0 [mac80211]
[] ieee80211_tx_skb+0x4f/0x60 [mac80211]
[] ieee80211_send_nullfunc+0x46/0x60 [mac80211]
[] ieee80211_offchannel_stop_station+0x107/0x150
[mac80211][] ieee80211_scan_work+0x146/0x600 [mac80211]
[] ? schedule+0x2f5/0x8e0
[] ? ieee80211_scan_work+0x0/0x600 [mac80211]
[] process_one_work+0x10f/0x380
[] worker_thread+0x162/0x340
[] ? worker_thread+0x0/0x340
Cc: stable@kernel.org
Signed-off-by: Mohammed Shafi Shajakhan
Signed-off-by: John W. Linville
29 Oct, 2010
8 commits
-
This patch enables and disables the rx and tx bits in the MAC control reg
by using a single write operation.
This also solves a possible problem (spotted on SPEAr platforms) at 10Mbps
where two consecutive writes to a MAC control register can take more than
4 phy_clk cycles.Signed-off-by: Armando Visconti
Acked-by: Giuseppe Cavallaro
Signed-off-by: David S. Miller -
drivers/net/atarilance.c: In function ‘addr_accessible’:
drivers/net/atarilance.c:413: warning: comparison of distinct pointer types lacks a cast
drivers/net/atarilance.c:450: warning: comparison of distinct pointer types lacks a castSigned-off-by: Geert Uytterhoeven
Signed-off-by: David S. Miller -
Reset the whole hw instead of freeing hw resources
consumed by each pci function.Signed-off-by: Rajesh Borundia
Signed-off-by: Amit Kumar Salecha
Signed-off-by: David S. Miller -
Crash is triggered by commit e6484930d7 ("net: allocate tx queues in
register_netdevice"), which moved tx netqueue creation into register_netdev.
So now calling netif_stop_queue() before register_netdev causes an oops.
Move netif_stop_queue() after net device registration to fix crash.Signed-off-by: Dmitry Artamonow
Signed-off-by: David S. Miller -
I got a few of these panics (on 2.6.36-rc7) when running high
number of netperf sessions:BUG: unable to handle kernel paging request at 0000100000000000
IP: [] skb_release_data+0xa0/0xd0
Oops: 0000 [#1] SMP
Pid: 2155, comm: vhost-2115 Not tainted 2.6.36-rc7-ORG #1 49Y6512 /System x3650 M2 -[7947AC1]-
RIP: 0010:[] [] skb_release_data+0xa0/0xd0
RSP: 0018:ffff880001803738 EFLAGS: 00010206
RAX: ffff880179b0fc00 RBX: ffff880178b441c0 RCX: 0000000000000000
RSP: 0018:ffff880001803738 EFLAGS: 00010206
RAX: ffff880179b0fc00 RBX: ffff880178b441c0 RCX: 0000000000000000
RDX: ffff880179b0fd40 RSI: 0000000000000000 RDI: 0000100000000000
RBP: ffff880001803748 R08: 0000000000000001 R09: ffff88017f117000
R10: ffff88017b990608 R11: ffff88017f117090 R12: ffff880178b441c0
R13: ffff88017f117090 R14: 0000000000000000 R15: ffff880178b441c0
FS: 0000000000000000(0000) GS:ffff880001800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000100000000000 CR3: 000000017ea64000 CR4: 00000000000026e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process vhost-2115 (pid: 2155, threadinfo ffff88017d872000, task ffff88017e954680)
Stack:
ffff880178b441c0 0000000000000007 ffff880001803768 ffffffff81312119
0000000000000000 0000000000000002 ffff880001803778 ffffffff813121f9
ffff880001803818 ffffffffa012d14c ffffffffa02de076 ffff880001803700
Call Trace:[] __kfree_skb+0x19/0xa0
[] kfree_skb+0x19/0x40
[] free_tx_desc+0x2fc/0x350 [cxgb3]
[] ? vhost_poll_wakeup+0x16/0x20 [vhost_net]
[] t3_eth_xmit+0x28b/0x380 [cxgb3]
[] dev_hard_start_xmit+0x377/0x5a0
[] sch_direct_xmit+0xfa/0x1d0
[] dev_queue_xmit+0x139/0x450
[] neigh_resolve_output+0x125/0x340
[] ip_finish_output+0x14c/0x320
[] ip_output+0xae/0xc0
[] ip_forward_finish+0x3f/0x50
[] ip_forward+0x1ff/0x400
[] ip_rcv_finish+0x119/0x3e0
[] ip_rcv+0x22d/0x300
[] __netif_receive_skb+0x29b/0x570
[] ? netif_receive_skb+0x0/0x80
[] netif_receive_skb+0x78/0x80
[] br_handle_frame_finish+0x198/0x260 [bridge]
[] br_nf_pre_routing_finish+0x238/0x380 [bridge]
[] ? nf_hook_slow+0x6c/0x100
[] ? br_nf_pre_routing_finish+0x0/0x380 [bridge]
[] br_nf_pre_routing+0x698/0x7a0 [bridge]
[] nf_iterate+0x64/0xa0
[] ? br_handle_frame_finish+0x0/0x260 [bridge]
[] nf_hook_slow+0x6c/0x100
[] ? br_handle_frame_finish+0x0/0x260 [bridge]
[] br_handle_frame+0x191/0x240 [bridge]
[] ? br_handle_frame+0x0/0x240 [bridge]
[] __netif_receive_skb+0x1a3/0x570
[] ? dma_issue_pending_all+0x76/0xa0
[] process_backlog+0x102/0x200
[] net_rx_action+0x100/0x220
[] __do_softirq+0xaf/0x140
[] call_softirq+0x1c/0x30
[] ? do_softirq+0x65/0xa0
[] netif_rx_ni+0x28/0x30
[] tun_sendmsg+0x2cd/0x4b0 [tun]
[] handle_tx+0x1df/0x340 [vhost_net]
[] handle_tx_kick+0x10/0x20 [vhost_net]
[] vhost_worker+0xbb/0x130 [vhost_net]
[] ? vhost_worker+0x0/0x130 [vhost_net]
[] ? vhost_worker+0x0/0x130 [vhost_net]
[] kthread+0x96/0xa0
[] kernel_thread_helper+0x4/0x10
[] ? kthread+0x0/0xa0
[] ? kernel_thread_helper+0x0/0x10
Code: 8b 94 24 d0 00 00 00 49 8b 84 24 d8 00 00 00 48 8d 14 10 0f b7 0a 39 d9 7f d1 48 8b 7a 10 48 85 ff 74 20 48 c7 42 10 00 00 00 00 8b 1f e8 e8 fb ff ff 48 85 db 48 89 df 75 f0 49 8b 84 24 d8Patch below fixes the panic. cxgb4 and cxgb4vf already have this fix.
Signed-off-by: Krishna Kumar
Signed-off-by: David S. Miller -
Along the same lines as "cxgb4: fix crash due to manipulating queues
before registration" (8f6d9f40476895571df039b6f1f5230ec7faebad), before
commit "net: allocate tx queues in register_netdevice"
netif_tx_stop_all_queues and related functions could be used between
device allocation and registration but now only after registration.
cxgb4 has such a call before registration and crashes now. Move it
after register_netdev.Signed-off-by: Nishanth Aravamudan
Cc: eric.dumazet@gmail.com
Cc: sonnyrao@us.ibm.com
Cc: Divy Le Ray
Cc: Dimitris Michailidis
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Tested-by: Nishanth Aravamudan
Acked-by: Divy Le Ray
Signed-off-by: David S. Miller -
The __NS8390_init tries to start the device queue before the
device is registered. This results in an oops (snipped):[ 2.865493] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
[ 2.866106] IP: [] netif_start_queue+0xb/0x12 [8390]
[ 2.881267] Call Trace:
[ 2.881437] [] __NS8390_init+0x102/0x15a [8390]
[ 2.881999] [] NS8390_init+0x9/0xb [8390]
[ 2.882237] [] ne2k_pci_init_one+0x297/0x354 [ne2k_pci]
[ 2.882955] [] local_pci_probe+0x12/0x16
[ 2.883308] [] pci_device_probe+0xc3/0xef
[ 2.884049] [] driver_probe_device+0xbe/0x14b
[ 2.884937] [] __driver_attach+0x46/0x62
[ 2.885170] [] bus_for_each_dev+0x49/0x78
[ 2.885781] [] driver_attach+0x1c/0x1e
[ 2.886089] [] bus_add_driver+0xba/0x227
[ 2.886330] [] driver_register+0x9e/0x115
[ 2.886933] [] __pci_register_driver+0x50/0xac
[ 2.887785] [] ne2k_pci_init+0x2c/0x2e [ne2k_pci]
[ 2.888093] [] do_one_initcall+0x7c/0x130
[ 2.888693] [] sys_init_module+0x99/0x1da
[ 2.888946] [] system_call_fastpath+0x16/0x1bThis happens because the netif_start_queue sets respective bit on the dev->_tx
array which is not yet allocated.As far as I understand the code removing the netif_start_queue from __NS8390_init
is OK, since queue will be started later on device open. Plz, correct me if I'm wrong.Found in the Dave's current tree, so he's in Cc.
Signed-off-by: Pavel Emelyanov
Signed-off-by: David S. Miller -
Introduced by commit:e6484930d7c73d324bccda7d43d131088da697b9
net: allocate tx queues in register_netdeviceSigned-off-by: Emil Tantilov
Acked-by: Greg Rose
Tested-by: Jeff Pieper
Signed-off-by: Jeff Kirsher
Signed-off-by: David S. Miller
