Signed-off-by: Daniel Klaffenbach <danielklaffenbach@gmail.com> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This was a missing piece from 41a5142 that dropped recognition of the
AGP module for the second B43 variant.
Reported-by: Stefan Bader <stefan.bader@canonical.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
page_order() is called by memory hotplug's user interface to check the
section is removable or not. (is_mem_section_removable())
It calls page_order() withoug holding zone->lock.
So, even if the caller does
if (PageBuddy(page))
ret = page_order(page) ...
The caller may hit BUG_ON().
For fixing this, there are 2 choices.
1. add zone->lock.
2. remove BUG_ON().
is_mem_section_removable() is used for some "advice" and doesn't need to
be 100% accurate. This is_removable() can be called via user program..
We don't want to take this important lock for long by user's request. So,
this patch removes BUG_ON().
There is a bug in commit 6dda9d55 ("page allocator: reduce fragmentation
in buddy allocator by adding buddies that are merging to the tail of the
free lists") that means a buddy at order MAX_ORDER is checked for merging.
A page of this order never exists so at times, an effectively random
piece of memory is being checked.
Alan Curry has reported that this is causing memory corruption in
userspace data on a PPC32 platform (http://lkml.org/lkml/2010/10/9/32).
It is not clear why this is happening. It could be a cache coherency
problem where pages mapped in both user and kernel space are getting
different cache lines due to the bad read from kernel space
(http://lkml.org/lkml/2010/10/13/179). It could also be that there are
some special registers being io-remapped at the end of the memmap array
and that a read has special meaning on them. Compiler bugs have been
ruled out because the assembly before and after the patch looks relatively
harmless.
This patch fixes the problem by ensuring we are not reading a possibly
invalid location of memory. It's not clear why the read causes corruption
but one way or the other it is a buggy read.
Signed-off-by: Mel Gorman <mel@csn.ul.ie> Cc: Corrado Zoccolo <czoccolo@gmail.com> Reported-by: Alan Curry <pacman@kosh.dhis.org> Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Cc: Christoph Lameter <cl@linux-foundation.org> Cc: Rik van Riel <riel@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The kernel build with CONFIG_OPROFILE and CPU_HOTPLUG enabled.
The oprofile is initialised using system timer in absence of hardware
counters supports. Oprofile isn't started from userland.
In this setup while doing a CPU offline the kernel hangs in infinite
for loop inside lock_hrtimer_base() function
This happens because as part of oprofile_cpu_notify(, it tries to
stop an hrtimer which was never started. These per-cpu hrtimers
are started when the oprfile is started.
echo 1 > /dev/oprofile/enable
This problem also existwhen the cpu is booted with maxcpus parameter
set. When bringing the remaining cpus online the timers are started
even if oprofile is not yet enabled.
This patch fix this issue by adding a state variable so that
these hrtimer start/stop is only attempted when oprofile is
started
For stable kernels v2.6.35.y and v2.6.36.y.
Reported-by: Jan Sebastien <s-jan@ti.com> Tested-by: sricharan <r.sricharan@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: Robert Richter <robert.richter@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
When a node contains only HighMem memory, slab_node(MPOL_BIND)
dereferences a NULL pointer.
[ This code seems to go back all the way to commit 19770b32609b: "mm:
filter based on a nodemask as well as a gfp_mask". Which was back in
April 2008, and it got merged into 2.6.26. - Linus ]
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Cc: Mel Gorman <mel@csn.ul.ie> Cc: Christoph Lameter <cl@linux.com> Cc: Lee Schermerhorn <lee.schermerhorn@hp.com> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This fixes a issue which was introduced by fe2cc53e ("uml: track and make
up lost ticks").
timeval_to_ns() returns long long and not int. Due to that UML's timer
did not work properlt and caused timer freezes.
Signed-off-by: Richard Weinberger <richard@nod.at> Acked-by: Pekka Enberg <penberg@kernel.org> Cc: Jeff Dike <jdike@addtoit.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The linker script cleanup that I did in commit 5d150a97f93 ("um: Clean up
linker script using standard macros.") (2.6.32) accidentally introduced an
ALIGN(PAGE_SIZE) when converting to use INIT_TEXT_SECTION; Richard
Weinberger reported that this causes the kernel to segfault with
CONFIG_STATIC_LINK=y.
I'm not certain why this extra alignment is a problem, but it seems likely
it is because previously
__init_begin = _stext = _text = _sinittext
and with the extra ALIGN(PAGE_SIZE), _sinittext becomes different from the
rest. So there is likely a bug here where something is assuming that
_sinittext is the same as one of those other symbols. But reverting the
accidental change fixes the regression, so it seems worth committing that
now.
Signed-off-by: Tim Abbott <tabbott@ksplice.com> Reported-by: Richard Weinberger <richard@nod.at> Cc: Jeff Dike <jdike@addtoit.com>
Tested by: Antoine Martin <antoine@nagafix.co.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
It's because there is no initialization code for a list_head contained in
the struct backing_dev_info under CONFIG_HOTPLUG_CPU, and the bug comes up
when block device drivers calling blk_alloc_queue() are used. In case of
me, I got them by using aoe.
When the driver was updated to be endian neutral (8e9c7716c)
the signed part of the s16 values was lost. This is because be16_to_cpu()
returns an unsigned value. This patch casts the values back to a s16
number prior to the the implicit cast up to an int.
Signed-off-by: Richard A. Smith <richard@laptop.org> Signed-off-by: Daniel Drake <dsd@laptop.org> Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
When the initialization code in hpet finds a memory resource and does not
find an IRQ, it does not unmap the memory resource previously mapped.
There are buggy BIOSes which report resources exactly like this and what
is worse the memory region bases point to normal RAM. This normally would
not matter since the space is not touched. But when PAT is turned on,
ioremap causes the page to be uncached and sets this bit in page->flags.
Then when the page is about to be used by the allocator, it is reported
as:
BUG: Bad page state in process md5sum pfn:3ed00
page:ffffea0000dbd800 count:0 mapcount:0 mapping:(null) index:0x0
page flags: 0x20000001000000(uncached)
Pid: 7956, comm: md5sum Not tainted 2.6.34-12-desktop #1
Call Trace:
[<ffffffff810df851>] bad_page+0xb1/0x100
[<ffffffff810dfa45>] prep_new_page+0x1a5/0x1c0
[<ffffffff810dfe01>] get_page_from_freelist+0x3a1/0x640
[<ffffffff810e01af>] __alloc_pages_nodemask+0x10f/0x6b0
...
2) there is no IRQ resource reported by HPET method. On the other
hand, the Intel HPET specs (1.0a) says (3.2.5.1):
_CRS (
// Report 1K of memory consumed by this Timer Block
memory range consumed
// Optional: only used if BIOS allocates Interrupts [1]
IRQs consumed
)
[1] For case where Timer Block is configured to consume IRQ0/IRQ8 AND
Legacy 8254/Legacy RTC hardware still exists, the device objects
associated with 8254 & RTC devices should not report IRQ0/IRQ8 as
"consumed resources".
So in theory we should check whether if it is the case and use those
interrupts instead.
Anyway the address reported by the BIOS here is bogus, so non-presence
of IRQ doesn't mean the "optional" part in point 2).
Since I got no reply previously, fix this by simply unmapping the space
when IRQ is not found and memory region was mapped previously. It would
be probably more safe to walk the resources again and unmap appropriately
depending on type. But as we now use only ioremap for both 2 memory
resource types, it is not necessarily needed right now.
Jaswinder Singh Rajput wrote:
> By executing Documentation/timers/hpet_example.c
>
> for polling, I requested for 3 iterations but it seems iteration work
> for only 2 as first expired time is always very small.
>
> # ./hpet_example poll /dev/hpet 10 3
> -hpet: executing poll
> hpet_poll: info.hi_flags 0x0
> hpet_poll: expired time = 0x13
> hpet_poll: revents = 0x1
> hpet_poll: data 0x1
> hpet_poll: expired time = 0x1868c
> hpet_poll: revents = 0x1
> hpet_poll: data 0x1
> hpet_poll: expired time = 0x18645
> hpet_poll: revents = 0x1
> hpet_poll: data 0x1
Clearing the HPET interrupt enable bit disables interrupt generation
but does not disable the timer, so the interrupt status bit will still
be set when the timer elapses. If another interrupt arrives before
the timer has been correctly programmed (due to some other device on
the same interrupt line, or CONFIG_DEBUG_SHIRQ), this results in an
extra unwanted interrupt event because the status bit is likely to be
set from comparator matches that happened before the device was opened.
Therefore, we have to ensure that the interrupt status bit is and
stays cleared until we actually program the timer.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Reported-by: Jaswinder Singh Rajput <jaswinderlinux@gmail.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: john stultz <johnstul@us.ibm.com> Cc: Bob Picco <bpicco@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
BugLink: https://launchpad.net/bugs/677652
The original reporter states that, in 2.6.35, headphones do not appear
to work, nor does inserting them mute the A52J's onboard speakers. Upon
inspecting the codec dump, it appears that the newly committed hp-laptop
quirk will suffice to enable this basic functionality. Testing was done
with an alsa-driver build from 2010-11-21.
Reported-and-tested-by: Joan Creus Signed-off-by: Daniel T Chen <crimsun@ubuntu.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Reported- and Tested-by: James Long <crogonint@yahoo.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
reiserfs_acl_chmod() can be called by reiserfs_set_attr() and then take
the reiserfs lock a second time. Thereafter it may call journal_begin()
that definitely requires the lock not to be nested in order to release
it before taking the journal mutex because the reiserfs lock depends on
the journal mutex already.
So, aviod nesting the lock in reiserfs_acl_chmod().
reiserfs_unpack() locks the inode mutex with reiserfs_mutex_lock_safe()
to protect against reiserfs lock dependency. However this protection
requires to have the reiserfs lock to be locked.
This is the case if reiserfs_unpack() is called by reiserfs_ioctl but
not from reiserfs_quota_on() when it tries to unpack tails of quota
files.
Fix the ordering of the two locks in reiserfs_unpack() to fix this
issue.
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com> Reported-by: Markus Gapp <markus.gapp@gmx.net> Reported-by: Jan Kara <jack@suse.cz> Cc: Jeff Mahoney <jeffm@suse.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Add missing consts to the sys_execve() declaration which result in the
following error:
arch/sh/kernel/process_32.c:303: error: conflicting types for 'sys_execve'
/warthog/nfs/linux-2.6-fscache/arch/sh/include/asm/syscalls_32.h:24: error: previous declaration of 'sys_execve' was here
Signed-off-by: Ken Kawasaki <ken_kawasaki@spring.nifty.jp> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Just makes sure that writes are not being aliased by the CPU cache and
do make it out to main memory.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=24977 Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
A physically mapped hardware status page is allocated at driver load
time but was never freed. Call the existing code to free this page at
driver unload time on hardware which uses this kind.
Signed-off-by: Keith Packard <keithp@keithp.com>
[ickle: call before tearing down registers on KMS-only path, as pointed
out by Dave Airlie] Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
After disabling the hotplug interrupts for VGA detection on Ironlake, be
sure to re-enable them again afterwards.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=30378 Signed-off-by: Yuanhan Liu <yuanhan.liu@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
There are cases when multiple texture units have to be enabled,
but not actually used to sample. This patch checks to see if
the lookup_disable bit is set and if so, skips the texture check.
On Sandybridge, the bit definition for hotplug on SDE has changed, so
update the code to new definition.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=30378 Signed-off-by: Yuanhan Liu <yuanhan.liu@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
In the case where we lock the page, and then find out that the page has
been thrown out of the page cache, we should just return VM_FAULT_NOPAGE.
This is what block_page_mkwrite() does in these situations.
NFSv4 open recovery is currently broken: since we do not clear the
state->flags states before attempting recovery, we end up with the
'can_open_cached()' function triggering. This again leads to no OPEN call
being put on the wire.
In the case of a server reboot, the state recovery thread starts by calling
nfs4_state_end_reclaim_reboot() in order to avoid edge conditions when
the server reboots while the client is in the middle of recovery.
However, if the client has already marked the nfs4_state as requiring
reboot recovery, then the above behaviour will cause the recovery thread to
treat the open as if it was part of such an edge condition: the open will
be recovered as if it was part of a lease expiration (and all the locks
will be lost).
Fix is to remove the call to nfs4_state_mark_reclaim_reboot from
nfs4_async_handle_error(), and nfs4_handle_exception(). Instead we leave it
to the recovery thread to do this for us.
If the server sends us an NFS4ERR_STALE_CLIENTID while the state management
thread is busy reclaiming state, we do want to treat all state that wasn't
reclaimed before the STALE_CLIENTID as if a network partition occurred (see
the edge conditions described in RFC3530 and RFC5661).
What we do not want to do is to send an nfs4_reclaim_complete(), since we
haven't yet even started reclaiming state after the server rebooted.
Commit c477d0447db08068a497e7beb892b2b2a7bff64b added support for RGMII
rx/tx delays except that it ends up clearing rx/tx delays bit for modes
differents that RGMII*ID. Due to this, ethernet is not working anymore
on my guruplug server +. This patch is fixing that.
Signed-off-by: Arnaud Patard <arnaud.patard@rtp-net.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This appears to be caused by the function rpc_verify_header() first
calling xprt_release(), then doing a call_refresh. If we release the
transport slot, we should _always_ jump back to call_reserve before
calling anything else.
In:
powerpc/mm: Fix pgtable cache cleanup with CONFIG_PPC_SUBPAGE_PROT
commit d28513bc7f675d28b479db666d572e078ecf182d
Author: David Gibson <david@gibson.dropbear.id.au>
subpage_protection() was changed to to take an mm rather a pgdir but it
didn't change calling site in hashpage_preload(). The change wasn't
noticed at compile time since hashpage_preload() used a void* as the
parameter to subpage_protection().
This is obviously wrong and can trigger the following crash when
CONFIG_SLAB, CONFIG_DEBUG_SLAB, CONFIG_PPC_64K_PAGES
CONFIG_PPC_SUBPAGE_PROT are enabled.
Reported-by: Jim Keniston <jkenisto@linux.vnet.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Michael Neuling <mikey@neuling.org>
cc: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The sticky PCM stream assignment introduced in 2.6.36 kernel seems
causing problems on AD codecs. At some time later, the streaming no
longer works by unknown reason. A simple workaround is to disable
sticky-assignment for these codecs.
This causes the connector to not be added since i2c init fails
for the adapter. Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=31688
Noticed by Ari Savolainen.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Cc: Ari Savolainen <ari.m.savolainen@gmail.com> Cc: Jean Delvare <khali@linux-fr.org> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
i2c_transfer returns negative errno on error and number of messages
processed on success. Just returning this value would give a poor
interface as it is not obvious that you must compare with 2 after reading
1 or n bytes and with 1 after writing 1 byte to determine if it was
successful. To avoid this error prone interface convert the error code
of a successful read/write to zero and all other non-negative values to
an negative error code.
This fixes a regression introduced by
via: Rationalize vt1636 detection
which resulted in no longer detecting a VT1636 chip and therefore has
broken the output in configurations which contain this chip.
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Acked-by: Jonathan Corbet <corbet@lwn.net> Cc: Joseph Chan <JosephChan@via.com.tw> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
In transparent data reception, avoid a NULL pointer dereference
in case an skbuff cannot be allocated, remove an inappropriate
call to the HDLC flush routine, and correct the accounting of
received bytes for continued buffers.
Signed-off-by: Tilman Schmidt <tilman@imap.cc> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Rework the handling of USB errors in AT response reads
to fix a possible infinite retry loop and a memory leak,
and silence a few overly verbose kernel messages.
Signed-off-by: Tilman Schmidt <tilman@imap.cc> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
I found this bug while poking around with a pure-gn AP.
Commit:
cfg80211/mac80211: Use more generic bitrate mask for rate control
Added some sanity checks to ensure that each tx rate index
is included in the configured mask and it would change any
rate indexes if it wasn't.
But, the current implementation doesn't take into account
that the invalid rate index "-1" has a special meaning
(= no further attempts) and it should not be "changed".
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Station addition in ieee80211_ibss_rx_queued_mgmt is not updating
sta->last_rx which is causing station expiry in ieee80211_ibss_work
path. So sta addition and deletion happens repeatedly.
Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Upon beacon loss we send probe requests after 30 seconds of idle
time and we wait for each probe response 1/2 second. We send a
total of 3 probe requests before giving up on the AP. In the case
that we reset the connection idle monitor we should reset the probe
requests count to 0. Right now this won't help in any way but
the next patch will.
This patch has fixes for stable kernel [2.6.35+].
Cc: Paul Stewart <pstew@google.com> Cc: Amod Bodas <amod.bodas@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch fixes stale mac80211_tx_control_flags for
filtered / retried frames.
Because ieee80211_handle_filtered_frame feeds skbs back
into the tx path, they have to be stripped of some tx
flags so they won't confuse the stack, driver or device.
Acked-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This code is modifying the station flags, and
as such should hold the flags lock so it can
do so atomically vs. other flags modifications
and readers. This issue was introduced when
this code was added in eccb8e8f, as it used
the wrong lock (thus not fixing the race that
was previously documented in a comment.)
Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The beacon monitor should be disabled when going off channel
to prevent spurious warnings and triggering connection
deterioration work such as sending probe requests. Re-enable
the beacon monitor once we come back to the home channel.
This patch has fixes for stable kernels [2.6.34+].
Cc: Paul Stewart <pstew@google.com> Cc: Amod Bodas <amod.bodas@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Some buggy APs do not respond to unicast probe requests
or send unicast probe requests very delayed so in the
worst case we should try to send broadcast probe requests,
otherwise we can get disconnected from these APs.
Even if drivers do not have filters to disregard probe
responses from foreign APs mac80211 will only process
probe responses from our associated AP for re-arming
connection monitoring.
We need to do this since the beacon monitor does not
push back the connection monitor by design so even if we
are getting beacons from these type of APs our connection
monitor currently relies heavily on the way the probe
requests are received on the AP. An example of an AP
affected by this is the Nexus One, but this has also been
observed with random APs.
We can probably optimize this later by using null funcs
instead of probe requests.
This patch has fixes for stable kernels [2.6.35+].
Cc: Paul Stewart <pstew@google.com> Cc: Amod Bodas <amod.bodas@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This will be used by other components next. The beacon
monitor was added as of 2.6.34 so these fixes are applicable
only to kernels >= 2.6.34.
Cc: Paul Stewart <pstew@google.com> Cc: Amod Bodas <amod.bodas@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This will be used in another place later. The connection
monitor was added as of 2.6.35 so these fixes will be
applicable to >= 2.6.35.
Cc: Paul Stewart <pstew@google.com> Cc: Amod Bodas <amod.bodas@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
When we go offchannel mac80211 currently leaves alive the
connection idle monitor. This should be instead postponed
until we come back to our home channel, otherwise by the
time we get back to the home channel we could be triggering
unecesary probe requests. For APs that do not respond to
unicast probe requests (Nexus One is a simple example) this
means we essentially get disconnected after the probes
fails.
This patch has stable fixes for kernels [2.6.35+]
Cc: Paul Stewart <pstew@google.com> Cc: Amod Bodas <amod.bodas@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The ave_beacon_signal value uses 1/16 dB unit and as such, must be
initialized with the signal level of the first Beacon frame multiplied
by 16. This fixes an issue where the initial CQM events are reported
incorrectly with a burst of events while the running average
approaches the correct value after the incorrect initialization. This
could cause user space -based roaming decision process to get quite
confused at the moment when we would like to go through authentication
and DHCP.
Signed-off-by: Jouni Malinen <j@w1.fi> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Association is dealt with as an atomic offchannel operation,
we do this because we don't know we are associated until we
get the associatin response from the AP. When we do get the
associatin response though we were never clearing the offchannel
state. This has a few implications, we told drivers we were
still offchannel, and the first configured TX power for the
channel does not take into account any power constraints.
For ath9k this meant ANI calibration would not start upon
association, and we'd have to wait until the first bgscan
to be triggered. There may be other issues this resolves
but I'm too lazy to comb the code to check.
Cc: Amod Bodas <amod.bodas@atheros.com> Cc: Vasanth Thiagarajan <vasanth.thiagarajan@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Be consistent and use the wk->chan instead of the
local->hw.conf.channel for the association done work.
This prevents any possible races against channel changes
while we run this work.
In the case that the race did happen we would be initializing
the bit rates for the new AP under the assumption of a wrong
channel and in the worst case, wrong band. This could lead
to trying to assuming we could use CCK frames on 5 GHz, for
example.
This patch has a fix for kernels >= v2.6.34
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch not only fixes a null-pointer de-reference
that would be triggered by a PLINK_OPEN frame with mis-
matching/incompatible mesh configuration, but also
responds correctly to non-compatible PLINK_OPEN frames
by generating a PLINK_CLOSE with the right reason code.
The original bug was detected by smatch.
( http://repo.or.cz/w/smatch.git )
net/mac80211/mesh_plink.c +574 mesh_rx_plink_frame(168)
error: we previously assumed 'sta' could be null.
Reviewed-and-Tested-by: Steve deRosier <steve@cozybit.com> Reviewed-and-Tested-by: Javier Cardona <javier@cozybit.com> Acked-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch fixes two problems with the minstrel_ht rate control
algorithms handling of A-MPDU frames:
1. The ampdu_len field of the tx status is not always initialized for
non-HT frames (and it would probably be unreasonable to require all
drivers to do so). This could cause rate control statistics to be
corrupted. We now trust the ampdu_len and ampdu_ack_len fields only when
the frame is marked with the IEEE80211_TX_STAT_AMPDU flag.
2. Successful transmission attempts where only recognized when the A-MPDU
subframe carrying the rate control status information was marked with the
IEEE80211_TX_STAT_ACK flag. If this information happed to be carried on a
frame that failed to be ACKed then the other subframes (which may have
succeeded) where not correctly registered. We now update rate control
statistics regardless of whether the subframe carrying the information was
ACKed or not.
Signed-off-by: Björn Smedman <bjorn.smedman@venatech.se> Acked-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
wireless: only use alpha2 regulatory information from country IE
removed some complex intersection we were always doing between the AP's
country IE info and what we got from CRDA. When CRDA sent us back a
regulatory domain we would do some sanity checks on that regulatory
domain response we just got. Part of these sanity checks included
checking that we already had performed an intersection for the
request of NL80211_REGDOM_SET_BY_COUNTRY_IE type.
This mean that cfg80211 was only processing country IEs for cases
where we already had an intersection, but since we removed enforcing
this this is no longer required, we should just apply the country
IE country hint with the data received from CRDA.
This patch has fixes intended for kernels >= 2.6.36.
Reported-by: Easwar Krishnan <easwar.krishnan@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Add missing unlocking of the wiphy in set_channel,
and don't try to unlock a non-existing wiphy in
set_cqm.
Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
When multiple interfaces are actively trying
to associate with the same BSS, they may both
find that the BSS isn't there and then try to
unlink it. This can cause errors since the
unlinking code can't currently deal with items
that have already been unlinked.
Normally this doesn't happen as most people
don't try to use multiple station interfaces
that associate at the same time too.
Fix this by using the list entry as a flag to
see if the item is still on a list.
Reported-by: Ben Greear <greearb@candelatech.com> Tested-by: Hun-Kyi Wynn <hkwynn@candelatech.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Cc: Ben Greear <greearb@candelatech.com> Cc: Kyungwan Nam <kyungwan.nam@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Tested-by: Ben Greear <greearb@candelatech.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
There was some locking for starting some parts of
RX but not for starting the PCU. Include this otherwise
we can content against stopping the PCU.
This can potentially lead to races against different
buffers on the PCU which can lead to to the DMA RX
engine writing to buffers which are already freed.
This is part of a series that will help resolve the bug:
Cc: Ben Greear <greearb@candelatech.com> Cc: Kyungwan Nam <kyungwan.nam@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Tested-by: Ben Greear <greearb@candelatech.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
index e581b1f..b3c9baf 100644
Bit 22 of AR_WA should be set to fix the situation where chip reset
is asynchronous to clock of analog shift registers, such that when
reset is released, it could mess up the values of analog shift registers
and cause some hw issue on AR9280.
This bit is write only, but the driver does a read-modify-write
on AR_WA without setting bit 22 in ar9002_hw_configpcipowersave()
during radio disable. This causes surprise removal of hw. It can
never recover from this state and the hw will become usable only
after a power on/off cycle, and sometimes only during a cold reboot.
This issue can be triggered by doing frequent roaming with the
simple/test-roam script available from the wifi-test project [1]
when roaming between APs quickly. When roaming there is a is a high
possibility that the device being put into idle (radio disable) state
by mac80211 during AUTH->ASSOC. A device hardware reset would fail
and the kernel would output:
[40251.363799] ath: AWAKE -> FULL-SLEEP
[40251.363815] ieee80211 phy17: device no longer idle - working
[40251.363817] ath: Marking phy17 as not-idle
[40251.363819] ath: FULL-SLEEP -> AWAKE
[40251.415978] pciehp 0000:00:1c.3:pcie04: Card not present on Slot(3)
[40251.419896] ath: ah->misc_mode 0x4
[40251.428138] pciehp 0000:00:1c.3:pcie04: Card present on Slot(3)
[40251.532247] ath: timeout (100000 us) on reg 0x9860: 0xffffffff & 0x00000001 != 0x00000000
[40251.532250] ath: Unable to reset channel (2462 MHz), reset status -5
[40251.532422] ath: Set channel: 5745 MHz
[40251.540639] ath: Failed to stop TX DMA in 100 msec after killing last frame
[40251.548826] ath: Failed to stop TX DMA in 100 msec after killing last frame
[40251.557023] ath: Failed to stop TX DMA in 100 msec after killing last frame
[40251.565211] ath: Failed to stop TX DMA in 100 msec after killing last frame
[40251.573415] ath: Failed to stop TX DMA in 100 msec after killing last frame
[40251.581603] ath: Failed to stop TX DMA in 100 msec after killing last frame
[40251.581606] ath: Failed to stop TX DMA. Resetting hardware!
[40251.592679] ath: DMA failed to stop in 10 ms AR_CR=0xffffffff AR_DIAG_SW=0xffffffff
[40251.703330] ath: timeout (100000 us) on reg 0x7000: 0xffffffff & 0x00000003 != 0x00000000
[40251.703333] ath: RTC stuck in MAC reset
[40251.703334] ath: Chip reset failed
[40251.703335] ath: Unable to reset hardware; reset status -22
This is currently only reproducible with some HB92 (Half Mini-PCIE)
cards but the fix applies to all AR9280 cards. This patch fixes this
issue by setting bit 22 during radio disable.
This patch has fixes for all kernels that has ath9k.
ath9k's entire logic with SC_OP_SCANNING is incorrect due to the
way mac80211 currently implements the scan complete callback and
we handle it in ath9k. This patch removes the flag completely in
preference for the SC_OP_OFFCHANNEL which is really what we wanted.
The scanning flag was used to ensure we reset ANI to the old values
when we go back to the home channel, but if we are offchannel we
use some defaults. The flag was also used to re-enable the TX monitor.
Without this patch we simply never re-enabled ANI and the TX monitor
after going offchannel. This means that after one background
scan we are prone to noise issues and if we had a TX hang we would
not recover. To get this to work properly we must enable ANI after
we have configured the beacon timers, otherwise hardware acts really
oddly.
This patch has stable fixes which apply down to [2.6.36+], there
*may* be a to fix this on older kernels but requires a bit of
work since this patch relies on the new mac80211 flag
IEEE80211_CONF_OFFCHANNEL which was introduced as of 2.6.36.
Cc: Paul Stewart <pstew@google.com> Cc: Amod Bodas <amod.bodas@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
ath9k locks for starting RX but not for stopping RX. We could
potentially run into a situation where tried to stop RX
but immediately started RX. This allows for races on the
the RX engine deciding what buffer we last left off on
and could potentially cause ath9k to DMA into already
free'd memory or in the worst case at a later time to
already given memory to other drivers.
Fix this by locking stopping RX.
This is part of a series that will help resolve the bug:
Cc: Ben Greear <greearb@candelatech.com> Cc: Kyungwan Nam <kyungwan.nam@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Tested-by: Ben Greear <greearb@candelatech.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Completing aggregate frames can lead to new buffers being pushed into
the tid queues due to software retransmission.
When the tx queues are being drained, all pending aggregates must be
completed before the tid queues get drained, otherwise buffers might be
leaked.
Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The real way to lock RX is to contend on the PCU
and reset, this will be fixed in the next patch but for
now just do the renames so that the next patch which changes
the locking order is crystal clear.
This is part of a series that will help resolve the bug:
Cc: Ben Greear <greearb@candelatech.com> Cc: Kyungwan Nam <kyungwan.nam@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Tested-by: Ben Greear <greearb@candelatech.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
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.
Signed-off-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Netgear WNDA3200 device uses ar7010 firmware but it is failed to set
correct firmware offset on firmware download which causes device initialization
failure.
Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This updates the initvals for the AR9003 2.2 chipsets. The initvals
are the initial register values we use for our registers upon hardware
reset. This synchs up the initvals to match what our latest recommendation
from our systems engineering team.
The description of changes in this update:
Improves ability to support very strong Rx conditions.
Enhances DFS support for AP-mode.
Improves performance of Tx carrier leak calibration.
Adds support for Japan channel 14 Tx filtering requirements.
Improves Tx power accuracy.
Impact:
Update required to address degraded throughput at very short range.
Update required for AP-mode DFS certification.
Update required to comply to IEEE Tx carrier leak specification.
May not meet expected +/- 2 dB Tx power accuracy without update.
The most important fix here would be the TX carrier leakage required
to comply with IEEE 802.11 specifications. The group of changes have
been tested all together in one release.
Cc: Yixiang Li <yixiang.li@atheros.com> Cc: Don Breslin <don.breslin@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Since aggregation is usually triggered by tx completion, a hardware
reset (because of beacon stuck, tx hang or baseband hang) can
significantly delay the transmission of the next AMPDU (until the next
tx completion event).
Fix this by rescheduling aggregation after such a reset.
Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
According to the hardware documentation, the MIC failure bit is only
valid if the frame was decrypted using a valid TKIP key and is not a
fragment.
In some setups I've seen hardware-reported MIC failures on an AP that
was configured for CCMP only, so it's clear that additional checks are
necessary.
Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
When we return to the home channel we were never reseting our beacon
timers, this was casued by the fact that the scanning flag was still
on even after we returned to our home channel. There are also other
reasons why we would get a reset and if we are not off channel
we always need to resynch our beacon timers, because a reset will
clear them.
This bug is a regression introduced on 2.6.36. The order of the
changes are as follows:
So 5ee08656 would have worked if a0daa0e7 was not committed but
it was so this means 5ee08656 was broken since it assumed that
when we were in the channel change routine the scan flag would
be lifted. As it turns out the scan flag will be set when we
are already on the home channel.
These issues will need to be considered for our solution on
reshifting the scan complete callback location on mac80211 on
current development kernel work.
This patch has stable fixes which apply down to [2.6.36+]
Cc: Paul Stewart <pstew@google.com> Cc: Amod Bodas <amod.bodas@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The patch titled "ath9k: Add new file init.c" shuffled some code
around but in dong so for some reason also removed the revision
check for disablign power save. Add this revision check again
so we can get power save re-enabled again by default on cards
newer than AR5416 and AR5418.
This patch has fixes for stable kernels [2.6.34+].
Cc: Paul Stewart <pstew@google.com> Cc: Amod Bodas <amod.bodas@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
If AR_KeyMiss is set in the rx descriptor and AR_RxFrameOK is unset,
the hardware could not locate a valid key during a decryption attempt.
In this case, the frame must not be reported as decrypted, otherwise
mac80211 sees only random garbage.
Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This helper only clears the SC_OP_WAIT_FOR_{BEACON,CAB} flags.
Remove it and clear these flags directly in the approptiate
places instead.
Changes-licensed-under: ISC Signed-off-by: Gabor Juhos <juhosg@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
introduced a regression which forgot to lift the beacon flag
after we received all broadcast and multicast data. This meant
we never went to sleep consuming about ~650mW on idle. This pretty
much broke power save completely.
This patch has fixes for stable kernels [2.6.32+].
Cc: Paul Stewart <pstew@google.com> Cc: Sameer Nanda <snanda@google.com> Cc: Gabor Juhos <juhosg@openwrt.org> Cc: Amod Bodas <amod.bodas@atheros.com> Signed-off-by: Senthil Balasubramanian <senthilkumar@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
projects / lisovros / linux_canprio.git / log