- 19 May, 2013 40 commits
-
-
Wei Yongjun authored
commit 35623715 upstream. Fix to return -ENODEV in the chip not found error handling case instead of 0, as done elsewhere in this function. Signed-off-by:
Wei Yongjun <yongjun_wei@trendmicro.com.cn> Cc: Jingoo Han <jg1.han@samsung.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Jonghwan Choi <jhbird.choi@samsung.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Inderpal Singh authored
commit 08858461 upstream. The kernel crashes while resuming from AFTR idle mode. It happens because L2 cache was not going into retention state. This patch configures the USE_RETENTION bit of ARM_L2_OPTION register so that it does not depend on MANUAL_L2RSTDISABLE_CONTROL of ARM_COMMON_OPTION register for L2RSTDISABLE signal. Signed-off-by:
Inderpal Singh <inderpal.singh@linaro.org> Tested-by:
Chander Kashyap <chander.kashyap@linaro.org> Signed-off-by:
Olof Johansson <olof@lixom.net> Signed-off-by:
-
Geert Uytterhoeven authored
commit 22ee3b57 upstream. If gcc (e.g. 4.1.2) decides not to inline vsock_init_tables(), this will cause a section mismatch: WARNING: net/vmw_vsock/vsock.o(.text+0x1bc): Section mismatch in reference from the function __vsock_core_init() to the function .init.text:vsock_init_tables() The function __vsock_core_init() references the function __init vsock_init_tables(). This is often because __vsock_core_init lacks a __init annotation or the annotation of vsock_init_tables is wrong. This may cause crashes if VSOCKETS=y and VMWARE_VMCI_VSOCKETS=m. Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Philipp Reisner authored
commit 7c689e63 upstream. With an automatic after split-brain recovery policy of "after-sb-1pri call-pri-lost-after-sb", when trying to drbd_set_role() to R_SECONDARY, we run into a deadlock. This was first recognized and supposedly fixed by 2009-06-10 "Fixed a deadlock when using automatic split brain recovery when both nodes are" replacing drbd_set_role() with drbd_change_state() in that code-path, but the first hunk of that patch forgets to remove the drbd_set_role(). We apparently only ever tested the "two primaries" case. Signed-off-by:
Philipp Reisner <philipp.reisner@linbit.com> Signed-off-by:
Lars Ellenberg <lars.ellenberg@linbit.com> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Lars Ellenberg authored
commit 94ad0a10 upstream. We forgot to free the disk_conf, so for each attach/detach cycle we leaked 336 bytes. Signed-off-by:
-
Philipp Reisner authored
commit ef57f9e6 upstream. Signed-off-by:
-
Guenter Roeck authored
commit 60403f7a upstream. A race condition exists when registering the first watchdog device. Sequence of events: - watchdog_register_device calls watchdog_dev_register - watchdog_dev_register creates the watchdog misc device by calling misc_register. At that time, the matching character device (/dev/watchdog0) does not yet exist, and old_wdd is not set either. - Userspace gets an event and opens /dev/watchdog - watchdog_open is called and sets wdd = old_wdd, which is still NULL, and tries to dereference it. This causes the kernel to panic. Seen with systemd trying to open /dev/watchdog immediately after it was created. Reported-by:
Arkadiusz Miskiewicz <arekm@maven.pl> Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Tested-by:
Wim Van Sebroeck <wim@iguana.be> Signed-off-by:
-
Tomoya MORINAGA authored
commit 5c1ef591 upstream. pdc_desc_get() is called from pd_prep_slave_sg, and the function is called from interrupt context(e.g. Uart driver "pch_uart.c"). In fact, I saw kernel error message. So, GFP_ATOMIC must be used not GFP_NOIO. Signed-off-by:
Tomoya MORINAGA <tomoya.rohm@gmail.com> Signed-off-by:
Vinod Koul <vinod.koul@intel.com> Signed-off-by:
-
Cong Wang authored
[ Upstream commit 84c4a9df ] We forget to call dev_put() on error path in xfrm6_fill_dst(), its caller doesn't handle this. Signed-off-by:
Cong Wang <amwang@redhat.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: Steffen Klassert <steffen.klassert@secunet.com> Cc: David S. Miller <davem@davemloft.net> Signed-off-by:
-
Amerigo Wang authored
[ Upstream commit 5dbd5068 ] There is a hole in struct ip6_tnl_parm2, so we have to zero the struct on stack before copying it to user-space. Cc: David S. Miller <davem@davemloft.net> Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit f77d6021 ] We have seen multiple NULL dereferences in __inet6_lookup_established() After analysis, I found that inet6_sk() could be NULL while the check for sk_family == AF_INET6 was true. Bug was added in linux-2.6.29 when RCU lookups were introduced in UDP and TCP stacks. Once an IPv6 socket, using SLAB_DESTROY_BY_RCU is inserted in a hash table, we no longer can clear pinet6 field. This patch extends logic used in commit fcbdf09d ("net: fix nulls list corruptions in sk_prot_alloc") TCP/UDP/UDPLite IPv6 protocols provide their own .clear_sk() method to make sure we do not clear pinet6 field. At socket clone phase, we do not really care, as cloning the parent (non NULL) pinet6 is not adding a fatal race. Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
Jiri Pirko authored
[ Upstream commit 233c7df0 ] Currently, if macvlan in passthru mode is created and data are rxed and you remove this device, following panic happens: NULL pointer dereference at 0000000000000198 IP: [<ffffffffa0196058>] macvlan_handle_frame+0x153/0x1f7 [macvlan] I'm using following script to trigger this: <script> while [ 1 ] do ip link add link e1 name macvtap0 type macvtap mode passthru ip link set e1 up ip link set macvtap0 up IFINDEX=`ip link |grep macvtap0 | cut -f 1 -d ':'` cat /dev/tap$IFINDEX >/dev/null & ip link del dev macvtap0 done </script> I run this script while "ping -f" is running on another machine to send packets to e1 rx. Reason of the panic is that list_first_entry() is blindly called in macvlan_handle_frame() even if the list was empty. vlan is set to incorrect pointer which leads to the crash. I'm fixing this by protecting port->vlans list by rcu and by preventing from getting incorrect pointer in case the list is empty. Introduced by: commit eb06acdc "macvlan: Introduce 'passthru' mode to takeover the underlying device" Signed-off-by:
Jiri Pirko <jiri@resnulli.us> Acked-by:
-
Josh Boyer authored
[ Upstream commit 4f924b2a ] Protect the SIOCGCM* ioctl macros with parenthesis. Reported-by:
Paul Wouters <pwouters@redhat.com> Signed-off-by:
Josh Boyer <jwboyer@redhat.com> Signed-off-by:
-
Sergei Shtylyov authored
[ Upstream commit 4b264a16 ] 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:
Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by:
-
Sergei Shtylyov authored
[ Upstream commit c81400be ] When unloading the driver that drives an EISA board, a message similar to the following one is displayed: Trying to free nonexistent resource <0000000000013000-000000000001301f> Then an user is unable to reload the driver because the resource it requested in the previous load hasn't been freed. This happens most probably due to a typo in vortex_eisa_remove() which calls release_region() with 'dev->base_addr' instead of 'edev->base_addr'... Reported-by:
Matthew Whitehead <tedheadster@gmail.com> Tested-by:
Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by:
-
Konstantin Khlebnikov authored
[ Upstream commit b56141ab ] This patch fixes race between inet_frag_lru_move() and inet_frag_lru_add() which was introduced in commit 3ef0eb0d ("net: frag, move LRU list maintenance outside of rwlock") One cpu already added new fragment queue into hash but not into LRU. Other cpu found it in hash and tries to move it to the end of LRU. This leads to NULL pointer dereference inside of list_move_tail(). Another possible race condition is between inet_frag_lru_move() and inet_frag_lru_del(): move can happens after deletion. This patch initializes LRU list head before adding fragment into hash and inet_frag_lru_move() doesn't touches it if it's empty. I saw this kernel oops two times in a couple of days. [119482.128853] BUG: unable to handle kernel NULL pointer dereference at (null) [119482.132693] IP: [<ffffffff812ede89>] __list_del_entry+0x29/0xd0 [119482.136456] PGD 2148f6067 PUD 215ab9067 PMD 0 [119482.140221] Oops: 0000 [#1] SMP [119482.144008] Modules linked in: vfat msdos fat 8021q fuse nfsd auth_rpcgss nfs_acl nfs lockd sunrpc ppp_async ppp_generic bridge slhc stp llc w83627ehf hwmon_vid snd_hda_codec_hdmi snd_hda_codec_realtek kvm_amd k10temp kvm snd_hda_intel snd_hda_codec edac_core radeon snd_hwdep ath9k snd_pcm ath9k_common snd_page_alloc ath9k_hw snd_timer snd soundcore drm_kms_helper ath ttm r8169 mii [119482.152692] CPU 3 [119482.152721] Pid: 20, comm: ksoftirqd/3 Not tainted 3.9.0-zurg-00001-g9f95269 #132 To Be Filled By O.E.M. To Be Filled By O.E.M./RS880D [119482.161478] RIP: 0010:[<ffffffff812ede89>] [<ffffffff812ede89>] __list_del_entry+0x29/0xd0 [119482.166004] RSP: 0018:ffff880216d5db58 EFLAGS: 00010207 [119482.170568] RAX: 0000000000000000 RBX: ffff88020882b9c0 RCX: dead000000200200 [119482.175189] RDX: 0000000000000000 RSI: 0000000000000880 RDI: ffff88020882ba00 [119482.179860] RBP: ffff880216d5db58 R08: ffffffff8155c7f0 R09: 0000000000000014 [119482.184570] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88020882ba00 [119482.189337] R13: ffffffff81c8d780 R14: ffff880204357f00 R15: 00000000000005a0 [119482.194140] FS: 00007f58124dc700(0000) GS:ffff88021fcc0000(0000) knlGS:0000000000000000 [119482.198928] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [119482.203711] CR2: 0000000000000000 CR3: 00000002155f0000 CR4: 00000000000007e0 [119482.208533] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [119482.213371] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [119482.218221] Process ksoftirqd/3 (pid: 20, threadinfo ffff880216d5c000, task ffff880216d3a9a0) [119482.223113] Stack: [119482.228004] ffff880216d5dbd8 ffffffff8155dcda 0000000000000000 ffff000200000001 [119482.233038] ffff8802153c1f00 ffff880000289440 ffff880200000014 ffff88007bc72000 [119482.238083] 00000000000079d5 ffff88007bc72f44 ffffffff00000002 ffff880204357f00 [119482.243090] Call Trace: [119482.248009] [<ffffffff8155dcda>] ip_defrag+0x8fa/0xd10 [119482.252921] [<ffffffff815a8013>] ipv4_conntrack_defrag+0x83/0xe0 [119482.257803] [<ffffffff8154485b>] nf_iterate+0x8b/0xa0 [119482.262658] [<ffffffff8155c7f0>] ? inet_del_offload+0x40/0x40 [119482.267527] [<ffffffff815448e4>] nf_hook_slow+0x74/0x130 [119482.272412] [<ffffffff8155c7f0>] ? inet_del_offload+0x40/0x40 [119482.277302] [<ffffffff8155d068>] ip_rcv+0x268/0x320 [119482.282147] [<ffffffff81519992>] __netif_receive_skb_core+0x612/0x7e0 [119482.286998] [<ffffffff81519b78>] __netif_receive_skb+0x18/0x60 [119482.291826] [<ffffffff8151a650>] process_backlog+0xa0/0x160 [119482.296648] [<ffffffff81519f29>] net_rx_action+0x139/0x220 [119482.301403] [<ffffffff81053707>] __do_softirq+0xe7/0x220 [119482.306103] [<ffffffff81053868>] run_ksoftirqd+0x28/0x40 [119482.310809] [<ffffffff81074f5f>] smpboot_thread_fn+0xff/0x1a0 [119482.315515] [<ffffffff81074e60>] ? lg_local_lock_cpu+0x40/0x40 [119482.320219] [<ffffffff8106d870>] kthread+0xc0/0xd0 [119482.324858] [<ffffffff8106d7b0>] ? insert_kthread_work+0x40/0x40 [119482.329460] [<ffffffff816c32dc>] ret_from_fork+0x7c/0xb0 [119482.334057] [<ffffffff8106d7b0>] ? insert_kthread_work+0x40/0x40 [119482.338661] Code: 00 00 55 48 8b 17 48 b9 00 01 10 00 00 00 ad de 48 8b 47 08 48 89 e5 48 39 ca 74 29 48 b9 00 02 20 00 00 00 ad de 48 39 c8 74 7a <4c> 8b 00 4c 39 c7 75 53 4c 8b 42 08 4c 39 c7 75 2b 48 89 42 08 [119482.343787] RIP [<ffffffff812ede89>] __list_del_entry+0x29/0xd0 [119482.348675] RSP <ffff880216d5db58> [119482.353493] CR2: 0000000000000000 Oops happened on this path: ip_defrag() -> ip_frag_queue() -> inet_frag_lru_move() -> list_move_tail() -> __list_del_entry() Signed-off-by:
Konstantin Khlebnikov <khlebnikov@openvz.org> Cc: Jesper Dangaard Brouer <brouer@redhat.com> Cc: Florian Westphal <fw@strlen.de> Cc: Eric Dumazet <edumazet@google.com> Cc: David S. Miller <davem@davemloft.net> Acked-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
Jesper Dangaard Brouer <brouer@redhat.com> Signed-off-by:
-
stephen hemminger authored
[ Upstream commit 77d21f23 ] Programs using virtio headers outside of kernel will no longer build because u16 type does not exist in userspace. All user ABI must use __u16 typedef instead. Bug introduce by: commit 986a4f4d Author: Jason Wang <jasowang@redhat.com> Date: Fri Dec 7 07:04:56 2012 +0000 virtio_net: multiqueue support Signed-off-by:
Stephen Hemminger <stephen@networkplumber.org> Signed-off-by:
-
Daniel Borkmann authored
[ Upstream commit 8da3056c ] Jakub reported that it is fairly easy to trigger the BUG() macro from user space with TPACKET_V3's RX_RING by just giving a wrong header status flag. We already had a similar situation in commit 7f5c3e3a (``af_packet: remove BUG statement in tpacket_destruct_skb'') where this was the case in the TX_RING side that could be triggered from user space. So really, don't use BUG() or BUG_ON() unless there's really no way out, and i.e. don't use it for consistency checking when there's user space involved, no excuses, especially not if you're slapping the user with WARN + dump_stack + BUG all at once. The two functions are of concern: prb_retire_current_block() [when block status != TP_STATUS_KERNEL] prb_open_block() [when block_status != TP_STATUS_KERNEL] Calls to prb_open_block() are guarded by ealier checks if block_status is really TP_STATUS_KERNEL (racy!), but the first one BUG() is easily triggable from user space. System behaves still stable after they are removed. Also remove that yoda condition entirely, since it's already guarded. Reported-by:
Jakub Zawadzki <darkjames-ws@darkjames.pl> Signed-off-by:
Daniel Borkmann <dborkman@redhat.com> Signed-off-by:
-
holger@eitzenberger.org authored
[ Upstream commit c5060cec ] There is bug in the receive path of the asix driver at the time a packet is received larger than MTU size and DF bit set: BUG: unable to handle kernel paging request at 0000004000000001 IP: [<ffffffff8126f65b>] skb_release_head_state+0x2d/0xd2 ... Call Trace: <IRQ> [<ffffffff8126f86d>] ? skb_release_all+0x9/0x1e [<ffffffff8126f8ad>] ? __kfree_skb+0x9/0x6f [<ffffffffa00b4200>] ? asix_rx_fixup_internal+0xff/0x1ae [asix] [<ffffffffa00fb3dc>] ? usbnet_bh+0x4f/0x226 [usbnet] ... It is easily reproducable by setting an MTU of 512 e. g. and sending something like ping -s 1472 -c 1 -M do $SELF from another box. And this is because the rx->ax_skb is freed on error, but rx->ax_skb is not reset, and the size is not reset to zero in this case. And since the skb is added again to the usbnet->done skb queue it is accessing already freed memory, resulting in the BUG when freeing a 2nd time. I therefore think the value 0x0000004000000001 show in the trace is more or less random data. Signed-off-by:
Holger Eitzenberger <holger@eitzenberger.org> Signed-off-by:
-
stephen hemminger authored
[ Upstream commit 83401eb4 ] A bridge should only send topology change notice if it is not the root bridge. It is possible for message age timer to elect itself as a new root bridge, and still have a topology change timer running but waiting for bridge lock on other CPU. Solve the race by checking if we are root bridge before continuing. This was the root cause of the cases where br_send_tcn_bpdu would OOPS. Reported-by:
JerryKang <jerry.kang@samsung.com> Signed-off-by:
-
Bjørn Mork authored
[ Upstream commit b29d3145 ] Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
-
Patrick McHardy authored
[ Upstream commit 6708c9e5 ] Signed-off-by:
Patrick McHardy <kaber@trash.net> Signed-off-by:
-
Jamal Hadi Salim authored
[ Upstream commit 0dcffd09 ] Deal with changes in newer xtables while maintaining backward compatibility. Thanks to Jan Engelhardt for suggestions. Signed-off-by:
Jamal Hadi Salim <jhs@mojatatu.com> Signed-off-by:
-
Matthew Whitehead authored
[ Upstream commit 3b54912f ] The venerable 3c509 driver only sets its device parent in one case, the ISAPnP one. It does this with the SET_NETDEV_DEV function. It should register with the device hierarchy in two additional cases: standard (non-PnP) ISA and EISA. - Currently they appear here: /sys/devices/virtual/net/eth0 (standard ISA) /sys/devices/virtual/net/eth1 (EISA) - Rather, they should instead be here: /sys/devices/isa/3c509.0/net/eth0 (standard ISA) /sys/devices/pci0000:00/0000:00:07.0/00:04/net/eth1 (EISA) Tested on ISA and EISA boards. Signed-off-by:
-
Yuchung Cheng authored
[ Upstream commit cd75eff6 ] Linux immediately returns SYNACK on (spurious) SYN retransmits, but keeps the SYNACK timer running independently. Thus the timer may fire right after the SYNACK retransmit and causes a SYN-SYNACK cross-fire burst. Adopt the fast retransmit/recovery idea in established state by re-arming the SYNACK timer after the fast (SYNACK) retransmit. The timer may fire late up to 500ms due to the current SYNACK timer wheel, but it's OK to be conservative when network is congested. Eric's new listener design should address this issue. Signed-off-by:
Yuchung Cheng <ycheng@google.com> Acked-by:
Neal Cardwell <ncardwell@google.com> Signed-off-by:
-
Chen Gang authored
[ Upstream commit 2c1bbbff ] Change MAC802154_CHAN_NONE from ~(u8)0 to 0xff, or the comparison in mac802154_wpan_xmit() for ``chan == MAC802154_CHAN_NONE'' will not succeed. This bug can be boiled down to ``u8 foo = 0xff; if (foo == ~(u8)0) [...] else [...]'' where the condition will always take the else branch. Signed-off-by:
Chen Gang <gang.chen@asianux.com> Signed-off-by:
-
Gao feng authored
[ Upstream commit 3811ae76 ] We forget to release the reference of tun device in tun_recvmsg. bug introduced in commit 54f968d6 (tuntap: move socket to tun_file) Signed-off-by:
Gao feng <gaofeng@cn.fujitsu.com> Acked-by:
Jason Wang <jasowang@redhat.com> Signed-off-by:
-
Ben Hutchings authored
[ Upstream commit 89cc80a4 ] efx_mcdi_get_board_cfg() uses a buffer for the firmware response that is only large enough to hold subtypes for the originally defined set of NVRAM partitions. Longer responses are truncated, and we may read off the end of the buffer when copying out subtypes for additional partitions. In particular, this can result in the MTD partition for an FPGA bitfile being named e.g. 'eth5 sfc_fpga:00' when it should be 'eth5 sfc_fpga:01'. This means the firmware update tool (sfupdate) can't tell which bitfile should be written to the partition. Correct the response buffer size. Signed-off-by:
Ben Hutchings <bhutchings@solarflare.com> Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit 09316255 ] Before escaping RCU protected section and adding packet into prequeue, make sure the dst is refcounted. Reported-by:
Mike Galbraith <bitbucket@online.de> Signed-off-by:
-
Jani Nikula authored
commit 1ffc5289 upstream. Similar to commit 88afe715 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Sun Dec 16 12:15:41 2012 +0000 drm/i915: Clear the stolen fb before enabling but on the resume path. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=57191Reported-and-tested-by:
Nikolay Amiantov <nikoamia@gmail.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Daniel Vetter authored
commit a9b054e8 upstream. Since we know that locking is broken in that case and it's more important to not flood the dmesg with random gunk. Reported-and-tested-by:
Borislav Petkov <bp@suse.de> References: http://lkml.kernel.org/r/20130502000206.GH15623@pd.tnic Cc: Dave Airlie <airlied@gmail.com> Cc: Borislav Petkov <bp@alien8.de> Signed-off-by:
-
Daniel Vetter authored
commit 3a359f0b upstream. In commit 9e8944ab Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu Nov 15 11:32:17 2012 +0000 drm: Introduce an iterator over holes in the drm_mm range manager helpers and iterators for hole handling have been introduced with some debug BUG_ONs sprinkled over. Unfortunately this broke the mm dumper which unconditionally tried to compute the size of the very first hole. While at it unify the code a bit with the hole dumping in the loop. v2: Extract a hole dump helper. Reported-by:
Christopher Harvey <charvey@matrox.com> Cc: Christopher Harvey <charvey@matrox.com> Cc: Dave Airlie <airlied@redhat.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Acked-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Christopher Harvey authored
commit 9f1d0366 upstream. Higher bits of the base address of framebuffers weren't being programmed properly. This caused framebuffers that didn't happen to be allocated at a low enough address to not be displayed properly. Signed-off-by:
Mathieu Larouche <mathieu.larouche@matrox.com> Acked-by:
Julia Lemire <jlemire@matrox.com> Tested-by:
-
Christopher Harvey authored
commit fb70a669 upstream. The original line, WREG_DAC(MGA1064_PIX_CLK_CTL_CLK_DIS, tmp); wrote tmp into MGA1064_PIX_CLK_CTL_CLK_DIS, where MGA1064_PIX_CLK_CTL_CLK_DIS is an offset into MGA1064_PIX_CLK_CTL. Change the line to write properly into MGA1064_PIX_CLK_CTL. There were other chunks of code nearby that use the same pattern (but work correctly), so this patch updates them all to use this new (slightly more efficient) write pattern. The WREG_DAC macro was causing the DAC_INDEX register to be set to the same value twice. WREG8(DAC_DATA, foo) takes advantage of the fact that DAC_INDEX is already at the value we want. Signed-off-by:
-
Stanislaw Gruszka authored
commit dd9c4640 upstream. Jake reported that since commit 1672c0e3 "mac80211: start auth/assoc timeout on frame status", he is unable to connect to his AP, which is configured to use passive channel. After switch to passive channel 4965 firmware drops any TX packet until it receives beacon. Before commit 1672c0e3 we waited on channel and retransmit packet after 200ms, that makes we receive beacon on the meantime and association process succeed. New mac80211 behaviour cause that any ASSOC frame fail immediately on iwl4965 and we can not associate. This patch restore old mac80211 behaviour for iwl4965, by removing IEEE80211_HW_REPORTS_TX_ACK_STATUS feature. This feature will be added again to iwl4965 driver, when different, more complex workaround for this firmware issue, will be added to the driver. Bisected-by:
Jake Edge <jake@lwn.net> Reported-and-tested-by:
Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Thommy Jakobsson authored
commit 73b82bf0 upstream. Add handling of rx descriptor underflow. This fixes a fault that could happen on slow machines, where data is received faster than the CPU can handle. In such a case the device will use up all rx descriptors and refuse to send any more data before confirming that it is ok. This patch enables necessary interrupt to discover such a situation and will handle them by dropping everything in the ring buffer. Reviewed-by:
Michael Buesch <m@bues.ch> Signed-off-by:
Thommy Jakobsson <thommyj@gmail.com> Signed-off-by:
-
Chris Metcalf authored
commit c539914d upstream. The Tilera hypervisor shipped in releases up through MDE 4.1 launches the client operating system (i.e. Linux) at privilege level 1 (PL1). Starting with MDE 4.2, as part of the work to enable KVM, the Tilera hypervisor launches Linux at PL2 instead. This commit makes the KERNEL_PL option default to 2 for tilegx, while still saying at 1 for tilepro, which doesn't have an updated hypervisor. It also explains how and when you might want to choose another value. In addition, we change a small buglet in the on-chip Ethernet driver, where we were failing to use the KERNEL_PL constant in an API call. To make the transition cleaner, this change also provides the updated hv_init() API for the new hypervisor that supports announcing Linux's compiled-in PL, so the hypervisor can generate a suitable error in the case of a mismatched hypervisor and Linux binary. Signed-off-by:
Chris Metcalf <cmetcalf@tilera.com> Signed-off-by:
-
Daniel Drake authored
commit ccd384b1 upstream. A small bug in this code was causing the ALLMULTI filter to be set when in fact we were just wanting to program a selective multicast list to the hardware. Fix that bug and remove a redundant if condition in the code that follows. This fixes wakeup behaviour when multicast WOL is enabled. Previously, all multicast packets would wake up the system. Now, only those that the host intended to receive trigger wakeups. Signed-off-by:
Daniel Drake <dsd@laptop.org> Acked-by:
Bing Zhao <bzhao@marvell.com> Signed-off-by:
-
Amitkumar Karwar authored
commit f16fdc9d upstream. After unregister_netdevice() call the request is queued and reg_state is changed to NETREG_UNREGISTERING. As we check for NETREG_UNREGISTERED state, free_netdev() never gets executed causing memory leak. Initialize "dev->destructor" to free_netdev() to free device data after unregistration. Reported-by:
Amitkumar Karwar <akarwar@marvell.com> Signed-off-by:
-
Bing Zhao authored
commit 48795424 upstream. When the XO-4 with 8787 wireless is woken up due to wake-on-WLAN mwifiex is often flooded with "not allowed while suspended" messages and the interface is unusable. [ 202.171609] int: sdio_ireg = 0x1 [ 202.180700] info: mwifiex_process_hs_config: auto cancelling host sleep since there is interrupt from the firmware [ 202.201880] event: wakeup device... [ 202.211452] event: hs_deactivated [ 202.514638] info: --- Rx: Data packet --- [ 202.514753] data: 4294957544 BSS(0-0): Data <= kernel [ 202.514825] PREP_CMD: device in suspended state [ 202.514839] data: dequeuing the packet ec7248c0 ec4869c0 [ 202.514886] mwifiex_write_data_sync: not allowed while suspended [ 202.514886] host_to_card, write iomem (1) failed: -1 [ 202.514917] mwifiex_write_data_sync: not allowed while suspended [ 202.514936] host_to_card, write iomem (2) failed: -1 [ 202.514949] mwifiex_write_data_sync: not allowed while suspended [ 202.514965] host_to_card, write iomem (3) failed: -1 [ 202.514976] mwifiex_write_data_async failed: 0xFFFFFFFF This can be readily reproduced when putting the XO-4 in a loop where it goes to sleep due to inactivity, but then wakes up due to an incoming ping. The error is hit within an hour or two. This issue happens when an interrupt comes in early while host sleep is still activated. Driver handles this case by auto cancelling host sleep. However is_suspended flag is still set which prevents any cmd or data from being sent to firmware. Fix it by clearing is_suspended flag in this path. Reported-by:
-
