Age | Commit message (Collapse) | Author |
|
commit 556ab45f9a775bfa4762bacc0a4afb5b44b067bc upstream.
On some platforms (MacPro3,1) the BIOS assigns the ioatdma device to the
incorrect iommu causing faults when the driver initializes. Add a quirk
to catch this misconfiguration and try falling back to untranslated
operation (which works in the MacPro3,1 case).
Assuming there are other platforms with misconfigured iommus teach the
ioatdma driver to treat initialization failures as non-fatal (just fail
the driver load and emit a warning instead of triggering a BUG_ON).
This can be classified as a boot regression since 2.6.32 on affected
platforms since the ioatdma module did not autoload prior to that
kernel.
Acked-by: David Woodhouse <David.Woodhouse@intel.com>
Reported-by: Chris Li <lkml@chrisli.org>
Tested-by: Chris Li <lkml@chrisli.org>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 2d0bb1c1f4524befe9f0fcf0d0cd3081a451223f upstream.
Based on patches from Sonny Rao and Milton Miller...
Combined the patches to fix up clean_tx_irq and clean_rx_irq.
The PowerPC architecture does not require loads to independent bytes
to be ordered without adding an explicit barrier.
In ixgbe_clean_rx_irq we load the status bit then load the packet data.
With packet split disabled if these loads go out of order we get a
stale packet, but we will notice the bad sequence numbers and drop it.
The problem occurs with packet split enabled where the TCP/IP header
and data are in different descriptors. If the reads go out of order
we may have data that doesn't match the TCP/IP header. Since we use
hardware checksumming this bad data is never verified and it makes it
all the way to the application.
This bug was found during stress testing and adding this barrier has
been shown to fix it. The bug can manifest as a data integrity issue
(bad payload data) or as a BUG in skb_pull().
This was a nasty bug to hunt down, if people agree with the fix I think
it's a candidate for stable.
Previously Submitted to e1000-devel only for ixgbe
http://marc.info/?l=e1000-devel&m=126593062701537&w=3
We've now seen this problem hit with other device drivers (e1000e mostly)
So I'm resubmitting with fixes for other Intel Device Drivers with
similar issues.
CC: Milton Miller <miltonm@bga.com>
CC: Anton Blanchard <anton@samba.org>
CC: Sonny Rao <sonnyrao@us.ibm.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 51e9ac77035a3dfcb6fc0a88a0d80b6f99b5edb1 upstream.
If the 'bio_split' path in raid10-read is used while
resync/recovery is happening it is possible to deadlock.
Fix this be elevating ->nr_waiting for the duration of both
parts of the split request.
This fixes a bug that has been present since 2.6.22
but has only started manifesting recently for unknown reasons.
It is suitable for and -stable since then.
Reported-by: Justin Bronder <jsbronder@gentoo.org>
Tested-by: Justin Bronder <jsbronder@gentoo.org>
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit bb4f1e9d0e2ef93de8e36ca0f5f26625fcd70b7d upstream.
Move the deletion of sysfs attributes from reconfig_mutex to
open_mutex didn't really help as a process can try to take
open_mutex while holding reconfig_mutex, so the same deadlock can
happen, just requiring one more process to be involved in the chain.
I looks like I cannot easily use locking to wait for the sysfs
deletion to complete, so don't.
The only things that we cannot do while the deletions are still
pending is other things which can change the sysfs namespace: run,
takeover, stop. Each of these can fail with -EBUSY.
So set a flag while doing a sysfs deletion, and fail run, takeover,
stop if that flag is set.
This is suitable for 2.6.35.x
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 147e0b6a639ac581ca3bf627bedc3f4a6d3eca66 upstream.
Commit b821eaa5 "md: remove ->changed and related code" moved
revalidate_disk() under open_mutex, and lockdep noticed.
[ INFO: possible circular locking dependency detected ]
2.6.32-mdadm-locking #1
-------------------------------------------------------
mdadm/3640 is trying to acquire lock:
(&bdev->bd_mutex){+.+.+.}, at: [<ffffffff811acecb>] revalidate_disk+0x5b/0x90
but task is already holding lock:
(&mddev->open_mutex){+.+...}, at: [<ffffffffa055e07a>] do_md_stop+0x4a/0x4d0 [md_mod]
which lock already depends on the new lock.
It is suitable for 2.6.35.x
Reported-by: Przemyslaw Czarnowski <przemyslaw.hawrylewicz.czarnowski@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 110712828365ccafcc61a7f4db44c31ed4cf8793 upstream.
ide_cd_error_cmd() can complete an erroneous request with leftover
buffers. Signal this with its return value so that the request is not
accessed after its completion in the irq handler and we oops.
Signed-off-by: Borislav Petkov <bp@alien8.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit d9e1b6c45059ccfff647a120769ae86da78dfdc4 upstream.
After the commit that changed ipmi_si detecting sequence from SMBIOS/ACPI
to ACPI/SMBIOS,
| commit 754d453185275951d39792865927ec494fa1ebd8
| Author: Matthew Garrett <mjg@redhat.com>
| Date: Wed May 26 14:43:47 2010 -0700
|
| ipmi: change device discovery order
|
| The ipmi spec provides an ordering for si discovery. Change the driver to
| match, with the exception of preferring smbios to SPMI as HPs (at least)
| contain accurate information in the former but not the latter.
ipmi_si can not be initialized.
[ 138.799739] calling init_ipmi_devintf+0x0/0x109 @ 1
[ 138.805050] ipmi device interface
[ 138.818131] initcall init_ipmi_devintf+0x0/0x109 returned 0 after 12797 usecs
[ 138.822998] calling init_ipmi_si+0x0/0xa90 @ 1
[ 138.840276] IPMI System Interface driver.
[ 138.846137] ipmi_si: probing via ACPI
[ 138.849225] ipmi_si 00:09: [io 0x0ca2] regsize 1 spacing 1 irq 0
[ 138.864438] ipmi_si: Adding ACPI-specified kcs state machine
[ 138.870893] ipmi_si: probing via SMBIOS
[ 138.880945] ipmi_si: Adding SMBIOS-specified kcs state machineipmi_si: duplicate interface
[ 138.896511] ipmi_si: probing via SPMI
[ 138.899861] ipmi_si: Adding SPMI-specified kcs state machineipmi_si: duplicate interface
[ 138.917095] ipmi_si: Trying ACPI-specified kcs state machine at i/o address 0xca2, slave address 0x0, irq 0
[ 138.928658] ipmi_si: Interface detection failed
[ 138.953411] initcall init_ipmi_si+0x0/0xa90 returned 0 after 110847 usecs
in smbios has
DMI/SMBIOS
Handle 0x00C5, DMI type 38, 18 bytes
IPMI Device Information
Interface Type: KCS (Keyboard Control Style)
Specification Version: 2.0
I2C Slave Address: 0x00
NV Storage Device: Not Present
Base Address: 0x0000000000000CA2 (I/O)
Register Spacing: 32-bit Boundaries
in DSDT has
Device (BMC)
{
Name (_HID, EisaId ("IPI0001"))
Method (_STA, 0, NotSerialized)
{
If (LEqual (OSN, Zero))
{
Return (Zero)
}
Return (0x0F)
}
Name (_STR, Unicode ("IPMI_KCS"))
Name (_UID, Zero)
Name (_CRS, ResourceTemplate ()
{
IO (Decode16,
0x0CA2, // Range Minimum
0x0CA2, // Range Maximum
0x00, // Alignment
0x01, // Length
)
IO (Decode16,
0x0CA6, // Range Minimum
0x0CA6, // Range Maximum
0x00, // Alignment
0x01, // Length
)
})
Method (_IFT, 0, NotSerialized)
{
Return (One)
}
Method (_SRV, 0, NotSerialized)
{
Return (0x0200)
}
}
so the reg spacing should be 4 instead of 1.
Try to calculate regspacing for this kind of system.
Observed on a Sun Fire X4800. Other OSes work and pass certification.
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>
Acked-by: Matthew Garrett <mjg@redhat.com>
Cc: Len Brown <len.brown@intel.com>
Cc: Myron Stowe <myron.stowe@hp.com>
Cc: Corey Minyard <minyard@acm.org>
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>
|
|
commit 8f1d2d2be73a98c21e68fe2a26f633892d4abdd1 upstream.
ieee80211_beacon_get can return NULL...
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit e95b743536937a72e1560c85696b425c5d1a1c18 upstream.
The TX tracing code copies with the wrong length,
which will typically copy too little data. Fix
this by using the correct length variable.
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>
|
|
commit fa260c00c1aa5c657793a7221e40d2400df5afd8 upstream.
Fix a build failure "error: void value not ignored as it ought to be"
by removing an assignment of a void return value. The functionality of
the code is not changed.
Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
Acked-by: Henrik Kretzschmar <henne@nachtwindheim.de>
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>
|
|
commit bf9c1fca9ae9a79ed209e7ab2c10b3862f3f6f72 upstream.
Sorry, one more fix, this one depends on the other, so this is rather 2/2.
--
tty->driver_data is used all over the code, but never set. This
results in oopses like:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000130
IP: [<ffffffff814a0040>] mutex_lock+0x10/0x40
...
Pid: 2157, comm: modem-manager Not tainted 2.6.34.1-0.1-desktop #1 2768DR7/2768DR7
RIP: 0010:[<ffffffff814a0040>] [<ffffffff814a0040>] mutex_lock+0x10/0x40
RSP: 0018:ffff88007b16fa50 EFLAGS: 00010286
RAX: 0000000000000000 RBX: 0000000000000130 RCX: 0000000000000003
RDX: 0000000000000003 RSI: 0000000000000286 RDI: 0000000000000130
RBP: 0000000000001000 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000130
R13: 0000000000000001 R14: 0000000000000000 R15: ffff88007b16feb4
...
Call Trace:
[<ffffffffa077690d>] ntty_write_room+0x4d/0x90 [nozomi]
...
Set tty->driver_data to the computed port in .install to not recompute it in
every place where needed. Switch .open to use driver_data too.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit ee78bb95b7bea08b7774a02073ea2bb45611a9e1 upstream.
Currently ntty_install omits to increment tty count and we get the
following warnings:
Warning: dev (noz2) tty->count(0) != #fd's(1) in tty_open
So to fix that, add one tty->count++ there.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 1f6ea6e511e5ec730d8e88651da1b7b6e8fd1333 upstream.
We were seeing faults in the solos-pci receive tasklet when packets
arrived for a VCC which was currently being closed:
[18842.727906] EIP: [<e082f490>] br2684_push+0x19/0x234 [br2684] SS:ESP 0068:dfb89d14
[18845.090712] [<c13ecff3>] ? do_page_fault+0x0/0x2e1
[18845.120042] [<e082f490>] ? br2684_push+0x19/0x234 [br2684]
[18845.153530] [<e084fa13>] solos_bh+0x28b/0x7c8 [solos_pci]
[18845.186488] [<e084f711>] ? solos_irq+0x2d/0x51 [solos_pci]
[18845.219960] [<c100387b>] ? handle_irq+0x3b/0x48
[18845.247732] [<c10265cb>] ? irq_exit+0x34/0x57
[18845.274437] [<c1025720>] tasklet_action+0x42/0x69
[18845.303247] [<c102643f>] __do_softirq+0x8e/0x129
[18845.331540] [<c10264ff>] do_softirq+0x25/0x2a
[18845.358274] [<c102664c>] _local_bh_enable_ip+0x5e/0x6a
[18845.389677] [<c102666d>] local_bh_enable+0xb/0xe
[18845.417944] [<e08490a8>] ppp_unregister_channel+0x32/0xbb [ppp_generic]
[18845.458193] [<e08731ad>] pppox_unbind_sock+0x18/0x1f [pppox]
This patch uses an RCU-inspired approach to fix it. In the RX tasklet's
find_vcc() function we first refuse to use a VCC which already has the
ATM_VF_READY bit cleared. And in the VCC close function, we synchronise
with the tasklet to ensure that it can't still be using the VCC before
we continue and allow the VCC to be destroyed.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Tested-by: Nathan Williams <nathan@traverse.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 549e15611b4ac1de51ef0e0a79c2704f50a638a2 upstream.
MSI delivery from on-board ahci controller doesn't work on K8M800. At
this point, it's unclear whether the culprit is with the ahci
controller or the host bridge. Given the track record and considering
the rather minimal impact of MSI, disabling it seems reasonable.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Rainer Hurtado Navarro <publio.escipion.el.africano@gmail.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 3d2a531804d16cd8df6dbbb0429c6f143e756049 upstream.
There is no reason to run NVidia-specific quirks related to HT MSI
mappings with MSI disabled via pci=nomsi, so make
__nv_msi_ht_cap_quirk() return immediately in that case.
This allows at least one machine to boot 100% of the time with
pci=nomsi (it still doesn't boot reliably without that).
Addresses https://bugzilla.kernel.org/show_bug.cgi?id=16443 .
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit e847003f00d5eca3e3b3a6a1199f82b51293faf6 upstream.
Signed-off-by: Lytochkin Boris <lytboris@gmail.com>
Tested-by: Lytochkin Boris <lytboris@gmail.com>
Signed-off-by: Alexander Beregalov <a.beregalov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 54d2379c20d814ced657cbc2c4ead8d1f8389fa2 upstream.
LBDAF is not available nor necessary on 64BIT kernel. This patch
fixed the dependency for hv_blkvsc module on 64BIT kernel.
Thanks vrataj2 [vrataj2@comcast.net] for reporting this problem.
Reported-by: vrataj2 <vrataj2@comcast.net>
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: Hank Janssen <hjanssen@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 060132ae42cce3f9d2fd34d9a17b98362b44b9f9 upstream.
This patch prevents the code from calling parport_release and
parport_unregister_device twice with the same arguments - and thus fixes an oops.
Rationale:
After the first call the parport is already released and the
handle isn't valid anymore and calling parport_release and
parport_unregister_device twice isn't a good idea.
Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
Acked-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit e928c077e5cdcd72ee762125b37232aec1ff49f3 upstream.
line6 uses snd_pcm*() functions, so it should select SND_PCM.
ERROR: "snd_pcm_period_elapsed" [drivers/staging/line6/line6usb.ko] undefined!
ERROR: "snd_pcm_set_ops" [drivers/staging/line6/line6usb.ko] undefined!
ERROR: "snd_pcm_lib_free_pages" [drivers/staging/line6/line6usb.ko] undefined!
ERROR: "snd_pcm_lib_ioctl" [drivers/staging/line6/line6usb.ko] undefined!
ERROR: "snd_pcm_lib_malloc_pages" [drivers/staging/line6/line6usb.ko] undefined!
ERROR: "snd_pcm_hw_constraint_ratdens" [drivers/staging/line6/line6usb.ko] undefined!
ERROR: "snd_pcm_format_physical_width" [drivers/staging/line6/line6usb.ko] undefined!
ERROR: "snd_pcm_lib_preallocate_pages_for_all" [drivers/staging/line6/line6usb.ko] undefined!
ERROR: "snd_pcm_new" [drivers/staging/line6/line6usb.ko] undefined!
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Cc: Markus Grabner <grabner@icg.tugraz.at>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 5d92fe3387d086fc2f10426fbdb6b86d6cce5a47 upstream.
Device missing from current tables.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Tested-by: Rod Huffaker <rod.huffaker@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 127c03cdbad9bd5af5d7f33bd31a1015a90cb77f upstream.
NR_IRQS may be as low as 16, causing a (harmless?) buffer overflow in
pcmcia_setup_isa_irq():
static u8 pcmcia_used_irq[NR_IRQS];
...
if ((try < 32) && pcmcia_used_irq[irq])
continue;
This is read-only, so if this address would be non-zero, it would just
mean we would not attempt an IRQ >= NR_IRQS -- which would fail anyway!
And as request_irq() fails for an irq >= NR_IRQS, the setting code path:
pcmcia_used_irq[irq]++;
is never reached as well.
Reported-by: Christoph Fritz <chf.fritz@googlemail.com>
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: Christoph Fritz <chf.fritz@googlemail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 213373cf974fe69e78ec894b07f45ae2f5a3a078 upstream.
SIDPR window registers are shared across ports and as each access is
done in two steps, accesses to different ports under EH may race.
This primarily is caused by incorrect host locking in EH context and
should be fixed by defining locking requirements for each EH operation
which can be used during EH and enforcing them but for now work around
the problem by adding a dedicated SIDPR lock and grabbing it for each
SIDPR access.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Mark Knecht <markknecht@gmail.com>
Reported-by: Paul Check <paul@thechecks.ca>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit a1efd14a99483a4fb9308902397ed86b69454c99 upstream.
Apparently i830 and i845 cannot handle any stride that is not a multiple
of 256, unlike their brethren which do support 64 byte aligned strides.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit cda4b7d3a5b1dcbc0d8e7bad52134347798e9047 upstream.
The docs warn that to position the cursor such that no part of it is
visible on the pipe is an undefined operation. Avoid such circumstances
upon changing the mode, or at any other time, by unsetting the cursor if
it moves out of bounds.
"For normal high resolution display modes, the cursor must have at least a
single pixel positioned over the active screen.” (p143, p148 of the hardware
registers docs).
Fixes:
Bug 24748 - [965G] Graphics crashes when resolution is changed with KMS
enabled
https://bugs.freedesktop.org/show_bug.cgi?id=24748
v2: Only update the cursor registers if they change.
v3: Fix the unsigned comparision of x,y against width,height.
v4: Always set CUR.BASE or else the cursor may become corrupt.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reported-by: Christian Eggers <ceggers@gmx.de>
Cc: Christopher James Halse Rogers <chalserogers@gmail.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
bandwidth code
commit e06b14ee91a2ddefc9a67443a6cd8ee0fa800115 upstream.
Logic was:
if (mode0 && mode1)
else if (mode0)
else
Should be:
if (mode0 && mode1)
else if (mode0)
else if (mode1)
Otherwise we may end up calculating the priority regs with
unitialized values.
Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=16492
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 812d046915f48236657f02c06d7dc47140e9ceda upstream.
Use of HDP_*_COHERENCY_FLUSH_CNTL can cause a hang in certain
situations. Add workaround.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit e376573f7267390f4e1bdc552564b6fb913bce76 upstream.
This fixes a problem where on low VRAM cards we'd run out of space for validation.
[airlied: Tested on my M7, Thinkpad T42, compiz works with no problems.]
Signed-off-by: Michel Dänzer <daenzer@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit a91c1be21704113b023919826c6d531da46656ef upstream.
we also need to clean up and free the cdev.
Reported-by: Jani Nikula <ext-jani.1.nikula@nokia.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 9d1ac34ec3a67713308ae0883c3359c557f14d17 upstream.
In kernel Bugzilla #15825 (2 users), in a wireless mailing list thread
(http://lists.infradead.org/pipermail/b43-dev/2010-May/000124.html), and on a
netbook owned by John Linville
(http://marc.info/?l=linux-wireless&m=127230751408818&w=4), there are reports
of ssb failing to detect an SPROM at the normal location. After studying the
MMIO trace dump for the Broadcom wl driver, it was determined that the affected
boxes had a relocated SPROM.
This patch fixes all systems that have reported this problem.
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>
|
|
commit d28232b461b8d54b09e59325dbac8b0913ce2049 upstream.
Fix possible double priv->mutex lock introduced by commit
a69b03e941abae00380fc6bc1877fb797a1b31e6
"iwlwifi: cancel scan watchdog in iwl_bg_abort_scan" .
We can not call cancel_delayed_work_sync(&priv->scan_check) with
priv->mutex locked because workqueue function iwl_bg_scan_check()
take that lock internally.
We do not need to synchronize when canceling priv->scan_check work.
We can avoid races (sending double abort command or send no
command at all) using STATUS_SCAN_ABORT bit. Moreover
current iwl_bg_scan_check() code seems to be broken, as
we should not send abort commands when currently aborting.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 601e0cb165e65dc185b31fe7ebd2c0169ea47306 upstream.
On AR9285, the antenna switch configuration register uses more than just
16 bits. Because of an arbitrary mask applied to the EEPROM value that
stores this configuration, diversity was broken in some cases, leading
to a significant degradation in signal strength.
Fix this by changing the callback to return a 32 bit value and remove
the arbitrary mask.
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>
|
|
commit 4cee78614cfa046a26c4fbf313d5bbacb3ad8efc upstream.
When an aggregation session is being cleaned up, while the tx status
for some frames is being processed, the TID is flushed and its buffers
are sent out.
Unfortunately that left the pending un-acked frames unprocessed, thus
leaking buffers. Fix this by reordering the code so that those frames
are processed first, before the TID is flushed.
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>
|
|
commit f860d526eb2939a1c37128900b5af2b6f3ff7f20 upstream.
When issuing a reset, the TSF value is lost in the hardware because of
the 913x specific cold reset. As with some AR9280 cards, the TSF needs
to be preserved in software here.
Additionally, there's an issue that frequently prevents a successful
TSF write directly after the chip reset. In this case, repeating the
TSF write after the initval-writes usually works.
This patch detects failed TSF writes and recovers from them, taking
into account the delay caused by the initval writes.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Reported-by: Björn Smedman <bjorn.smedman@venatech.se>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 31e79a5954b78fbed15de2c8974d5a2b6019199a upstream.
The patch 'ath9k: fix a buffer leak in A-MPDU completion' addressed the
issue of running out of buffers/descriptors in the tx path if a STA is
deleted while tx status feedback is still pending.
The remaining issue is that the skbs of the buffers are not reclaimed,
leaving a memory leak.
This patch fixes this issue by running the buffers through
ath_tx_complete_buf(), ensuring that the pending frames counter is also
updated.
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>
|
|
commit 73e194639d90594d06d0c10019c0ab4638869135 upstream.
When ath_tx_complete_aggr() is called, it's responsible for returning
all buffers in the linked list. This was not done when the STA lookup
failed, leading to a race condition that could leak a few buffers when
a STA just disconnected.
Fix this by immediately returning all buffers to the free list in this case.
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>
|
|
commit 78c4653a2274479547e259e1f416d2b3d04c42a8 upstream.
The 'bf_retries' field of the ath_buf structure was used for both
software retries (AMPDU subframes) and hardware retries (legacy
frames). This led to a wrong retry count being reported for the A-MPDU
rate control stats.
This patch changes the code to no longer use bf_retries for reporting
retry counts, but instead always using the real on-chip retry count
from the ath_tx_status.
Additionally, if the first subframe of an A-MPDU was not acked, the tx
status report is submitted along with the first acked subframe, which
may not contain the correct rates in the tx info.
This is easily corrected by saving the tx rate info before looping over
subframes, and then copying it back once the A-MPDU status report is
submitted.
In my tests this change improves throughput visibly.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Reported-by: Björn Smedman <bjorn.smedman@venatech.se>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 03b4776c408d2f4bf3a5d204e223724d154716d1 upstream.
PDADC values were only generated for values surrounding the target
index, however not for the target index itself, leading to a minor
error in the generated curve.
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>
|
|
commit 23399016d9583d799ca98ce443a1410b13c3e96e upstream.
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>
|
|
commit 9cc2f3e881dcda5466c55ffe8dd0a9d1433469cb upstream.
If the receive path gets stuck, a full hardware reset is necessary to
recover from it. If this happens during a scan, the whole scan might fail,
as each channel change bypasses the full reset sequence.
Fix this by resetting the fast channel change flag if stopping the
receive path fails.
This will reduce the number of error messages that look like this:
ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x40000020
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>
|
|
commit 2b40994cabd2f545d5c11d3a65dcee6f6f9155f8 upstream.
It looks like it might be possible for a TID to be paused, while still
holding some queued buffers, however ath_tx_node_cleanup currently only
iterates over active TIDs.
Fix this by always checking every allocated TID for the STA that is being
cleaned up.
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>
|
|
commit 4c85ab11ca56da1aa59b58c80cc6a356515cc645 upstream.
https://bugzilla.kernel.org/show_bug.cgi?id=16476
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Acked-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 5fa8517f038d51d571981fb495206cc30ed91b06 upstream.
The 82576 expects the second rx queue in any pool to receive L2 switch
loop back packets sent from the second tx queue in another pool. The
82576 VF driver does not enable the second rx queue so if the PF driver
sends packets destined to a VF from its second tx queue then the VF
driver will never see them. In SR-IOV mode limit the number of tx queues
used by the PF driver to one. This patch fixes a bug reported in which
the PF cannot communciate with the VF and should be considered for 2.6.34
stable.
Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit ff847ac2d3e90edd94674c28bade25ae1e6a2e49 upstream.
The MAC-PHY interconnect on 82577/82578 uses a power management feature
(called K1) which must be disabled when in 1Gbps due to a hardware issue on
these parts. The #define bit setting used to enable/disable K1 is
incorrect and can cause PHY register accesses to stop working altogether
until the next device reset. This patch sets the register correctly.
This issue is present in kernels since 2.6.32.
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 36f2407fe52c55566221f8c68c8fb808abffd2f5 upstream.
Should e1000_test_msi() fail to see an msi interrupt, it attempts to
fallback to legacy INTx interrupts. But an error in the code may prevent
this from happening correctly.
Before calling e1000_test_msi_interrupt(), e1000_test_msi() disables SERR
by clearing the SERR bit from the just read PCI_COMMAND bits as it writes
them back out.
Upon return from calling e1000_test_msi_interrupt(), it re-enables SERR
by writing out the version of PCI_COMMAND it had previously read.
The problem with this is that e1000_test_msi_interrupt() calls
pci_disable_msi(), which eventually ends up in pci_intx(). And because
pci_intx() was called with enable set to 1, the INTX_DISABLE bit gets
cleared from PCI_COMMAND, which is what we want. But when we get back to
e1000_test_msi(), the INTX_DISABLE bit gets inadvertently re-set because
of the attempt by e1000_test_msi() to re-enable SERR.
The solution is to have e1000_test_msi() re-read the PCI_COMMAND bits as
part of its attempt to re-enable SERR.
During debugging/testing of this issue I found that not all the systems
I ran on had the SERR bit set to begin with. And on some of the systems
the same could be said for the INTX_DISABLE bit. Needless to say these
latter systems didn't have a problem falling back to legacy INTx
interrupts with the code as is.
Signed-off-by: Dean Nelson <dnelson@redhat.com>
Tested-by: Emil Tantilov <emil.s.tantilov@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 592970675c9522bde588b945388c7995c8b51328 upstream.
Use newly introduced netif_notify_peers() method to ensure a gratuitous ARP is
generated after a migration.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Stephen Hemminger <shemminger@linux-foundation.org>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: David S. Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Cc: xen-devel@lists.xensource.com
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 962b70a1eb22c467b95756a290c694e73da17f41 upstream.
The bitwise AND is of higher precedence, make that explicit.
Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit bc57117856cf1e581135810b37d3b75f9d1749f5 upstream.
Exit early when setting scrub rate on unknown/unsupported families.
Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
Acked-by: Doug Thompson <dougthompson@xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 9975a5f22a4fcc8d08035c65439900a983f891ad upstream.
The correct check is to verify whether in high range we're below 4GB
and not to extract the DctSelBaseAddr again. See "2.8.5 Routing DRAM
Requests" in the F10h BKDG.
Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
Acked-by: Doug Thompson <dougthompson@xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 4b4fd27c0b5ec638a1f06ced9226fd95229dbbf0 upstream.
avoid potential stack overflow by correctly checking count parameter
Reported-by: Ilja <ilja@netric.org>
Signed-off-by: Helge Deller <deller@gmx.de>
Acked-by: Kyle McMartin <kyle@mcmartin.ca>
Cc: James E.J. Bottomley <jejb@parisc-linux.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
* master.kernel.org:/home/rmk/linux-2.6-arm:
cyber2000fb: fix console in truecolor modes
cyber2000fb: fix machine hang on module load
SA1111: Eliminate use after free
ARM: Fix Versatile/Realview/VExpress MMC card detection sense
ARM: 6279/1: highmem: fix SMP preemption bug in kmap_high_l1_vipt
ARM: Add barriers to io{read,write}{8,16,32} accessors as well
ARM: 6273/1: Add barriers to the I/O accessors if ARM_DMA_MEM_BUFFERABLE
ARM: 6272/1: Convert L2x0 to use the IO relaxed operations
ARM: 6271/1: Introduce *_relaxed() I/O accessors
ARM: 6275/1: ux500: don't use writeb() in uncompress.h
ARM: 6270/1: clean files in arch/arm/boot/compressed/
ARM: Fix csum_partial_copy_from_user()
|