aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2010-08-13ipmi: fix ACPI detection with regspacingYinghai Lu
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>
2010-08-13rtl8180: avoid potential NULL deref in rtl8180_beacon_workJohn W. Linville
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>
2010-08-13iwlwifi: fix TX tracerJohannes Berg
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>
2010-08-13drivers/video/w100fb.c: ignore void return value / fix build failurePeter Huewe
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>
2010-08-13mm: fix corruption of hibernation caused by reusing swap during image savingKAMEZAWA Hiroyuki
commit 966cca029f739716fbcc8068b8c6dfe381f86fc3 upstream. Since 2.6.31, swap_map[]'s refcounting was changed to show that a used swap entry is just for swap-cache, can be reused. Then, while scanning free entry in swap_map[], a swap entry may be able to be reclaimed and reused. It was caused by commit c9e444103b5e7a5 ("mm: reuse unused swap entry if necessary"). But this caused deta corruption at resume. The scenario is - Assume a clean-swap cache, but mapped. - at hibernation_snapshot[], clean-swap-cache is saved as clean-swap-cache and swap_map[] is marked as SWAP_HAS_CACHE. - then, save_image() is called. And reuse SWAP_HAS_CACHE entry to save image, and break the contents. After resume: - the memory reclaim runs and finds clean-not-referenced-swap-cache and discards it because it's marked as clean. But here, the contents on disk and swap-cache is inconsistent. Hance memory is corrupted. This patch avoids the bug by not reclaiming swap-entry during hibernation. This is a quick fix for backporting. Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: Rafael J. Wysocki <rjw@sisk.pl> Reported-by: Ondreg Zary <linux@rainbow-software.org> Tested-by: Ondreg Zary <linux@rainbow-software.org> Tested-by: Andrea Gelmini <andrea.gelmini@gmail.com> Acked-by: Hugh Dickins <hughd@google.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>
2010-08-13Char: nozomi, set tty->driver_data appropriatelyJiri Slaby
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>
2010-08-13Char: nozomi, fix tty->count countingJiri Slaby
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>
2010-08-13ALSA: hda - Add PC-beep whitelist for an Intel boardTakashi Iwai
commit e096c8e6d5ed965f346d94befbbec2275dde3621 upstream. An Intel board needs a white-list entry to enable PC-beep. Otherwise the driver misdetects (due to bogus BIOS info) and ignores the PC-beep on 2.6.35. Reported-and-tested-by: Leandro Lucarella <luca@llucax.com.ar> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-13x86, mtrr: Use stop machine context to rendezvous all the cpu'sSuresh Siddha
commit 68f202e4e87cfab4439568bf397fcc5c7cf8d729 upstream. Use the stop machine context rather than IPI's to rendezvous all the cpus for MTRR initialization that happens during cpu bringup or for MTRR modifications during runtime. This avoids deadlock scenario (reported by Prarit) like: cpu A holds a read_lock (tasklist_lock for example) with irqs enabled cpu B waits for the same lock with irqs disabled using write_lock_irq cpu C doing set_mtrr() (during AP bringup for example), which will try to rendezvous all the cpus using IPI's This will result in C and A come to the rendezvous point and waiting for B. B is stuck forever waiting for the lock and thus not reaching the rendezvous point. Using stop cpu (run in the process context of per cpu based keventd) to do this rendezvous, avoids this deadlock scenario. Also make sure all the cpu's are in the rendezvous handler before we proceed with the local_irq_save() on each cpu. This lock step disabling irqs on all the cpus will avoid other deadlock scenarios (for example involving with the blocking smp_call_function's etc). [ This problem is very old. Marking -stable only for 2.6.35 as the stop_one_cpu_nowait() API is present only in 2.6.35. Any older kernel interested in this fix need to do some more work in backporting this patch. ] Reported-by: Prarit Bhargava <prarit@redhat.com> Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> LKML-Reference: <1280515602.2682.10.camel@sbsiddha-MOBL3.sc.intel.com> Acked-by: Prarit Bhargava <prarit@redhat.com> Signed-off-by: H. Peter Anvin <hpa@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-13solos-pci: Fix race condition in tasklet RX handlingDavid Woodhouse
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>
2010-08-13PCI: disable MSI on VIA K8M800Tejun Heo
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>
2010-08-13PCI: Do not run NVidia quirks related to MSI with MSI disabledRafael J. Wysocki
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>
2010-08-13serial: add support for OX16PCI958 cardLytochkin Boris
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>
2010-08-13staging: hv: Fix Kconfig dependency of hv_blkvscHaiyang Zhang
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>
2010-08-13Staging: panel: Prevent double-calling of parport_release - fix oops.Peter Huewe
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>
2010-08-13Staging: line6: needs to select SND_PCMRandy Dunlap
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>
2010-08-13staging: rt2870: Add USB ID for Belkin F6D4050 v2Larry Finger
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>
2010-08-13x86: Add memory modify constraints to xchg() and cmpxchg()H. Peter Anvin
commit 113fc5a6e8c2288619ff7e8187a6f556b7e0d372 upstream. xchg() and cmpxchg() modify their memory operands, not merely read them. For some versions of gcc the "memory" clobber has apparently dealt with the situation, but not for all. Originally-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: H. Peter Anvin <hpa@zytor.com> Cc: Glauber Costa <glommer@redhat.com> Cc: Avi Kivity <avi@redhat.com> Cc: Peter Palfrader <peter@palfrader.org> Cc: Greg KH <gregkh@suse.de> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Zachary Amsden <zamsden@redhat.com> Cc: Marcelo Tosatti <mtosatti@redhat.com> LKML-Reference: <4C4F7277.8050306@zytor.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-13pcmcia: avoid buffer overflow in pcmcia_setup_isa_irqDominik Brodowski
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>
2010-08-13x86/PCI: use host bridge _CRS info on ASRock ALiveSATA2-GLANBjorn Helgaas
commit 2491762cfb475dbdfa3db11ebea6de49f58b7fac upstream. This DMI quirk turns on "pci=use_crs" for the ALiveSATA2-GLAN because amd_bus.c doesn't handle this system correctly. The system has a single HyperTransport I/O chain, but has two PCI host bridges to buses 00 and 80. amd_bus.c learns the MMIO range associated with buses 00-ff and that this range is routed to the HT chain hosted at node 0, link 0: bus: [00, ff] on node 0 link 0 bus: 00 index 1 [mem 0x80000000-0xfcffffffff] This includes the address space for both bus 00 and bus 80, and amd_bus.c assumes it's all routed to bus 00. We find device 80:01.0, which BIOS left in the middle of that space, but we don't find a bridge from bus 00 to bus 80, so we conclude that 80:01.0 is unreachable from bus 00, and we move it from the original, working, address to something outside the bus 00 aperture, which does not work: pci 0000:80:01.0: reg 10: [mem 0xfebfc000-0xfebfffff 64bit] pci 0000:80:01.0: BAR 0: assigned [mem 0xfd00000000-0xfd00003fff 64bit] The BIOS told us everything we need to know to handle this correctly, so we're better off if we just pay attention, which lets us leave the 80:01.0 device at the original, working, address: ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-7f]) pci_root PNP0A03:00: host bridge window [mem 0x80000000-0xff37ffff] ACPI: PCI Root Bridge [PCI1] (domain 0000 [bus 80-ff]) pci_root PNP0A08:00: host bridge window [mem 0xfebfc000-0xfebfffff] This was a regression between 2.6.33 and 2.6.34. In 2.6.33, amd_bus.c was used only when we found multiple HT chains. 3e3da00c01d050, which enabled amd_bus.c even on systems with a single HT chain, caused this failure. This quirk was written by Graham. If we ever enable "pci=use_crs" for machines from 2006 or earlir, this quirk should be removed. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=16007 Reported-by: Graham Ramsey <ramsey.graham@ntlworld.com> Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-13x86, kmmio/mmiotrace: Fix double free of kmmio_fault_pagesMarcin Slusarz
commit 8b8f79b927b6b302bb65fb8c56e7a19be5fbdbef upstream. After every iounmap mmiotrace has to free kmmio_fault_pages, but it can't do it directly, so it defers freeing by RCU. It usually works, but when mmiotraced code calls ioremap-iounmap multiple times without sleeping between (so RCU won't kick in and start freeing) it can be given the same virtual address, so at every iounmap mmiotrace will schedule the same pages for release. Obviously it will explode on second free. Fix it by marking kmmio_fault_pages which are scheduled for release and not adding them second time. Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com> Tested-by: Marcin Kocielnicki <koriakin@0x04.net> Tested-by: Shinpei KATO <shinpei@il.is.s.u-tokyo.ac.jp> Acked-by: Pekka Paalanen <pq@iki.fi> Cc: Stuart Bennett <stuart@freedesktop.org> Cc: Marcin Kocielnicki <koriakin@0x04.net> Cc: nouveau@lists.freedesktop.org LKML-Reference: <20100613215654.GA3829@joi.lan> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-13powerpc: fix build with make 3.82Sam Ravnborg
commit e32e78c5ee8aadef020fbaecbe6fb741ed9029fd upstream. Thomas Backlund reported that the powerpc build broke with make 3.82. It failed with the following message: arch/powerpc/Makefile:183: *** mixed implicit and normal rules. Stop. The fix is to avoid mixing non-wildcard and wildcard targets. Reported-by: Thomas Backlund <tmb@mandriva.org> Tested-by: Thomas Backlund <tmb@mandriva.org> Cc: Michal Marek <mmarek@suse.cz> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-13perf, powerpc: fsl_emb: Restore setting perf_sample_data.periodScott Wood
commit 69e77a8b0426ded5d924eea7dbe4eca51e09f530 upstream. Commit 6b95ed345b9faa4ab3598a82991968f2e9f851bb changed from a struct initializer to perf_sample_data_init(), but the setting of the .period member was left out. Signed-off-by: Scott Wood <scottwood@freescale.com> Signed-off-by: Paul Mackerras <paulus@samba.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-13ata_piix: fix locking around SIDPR accessTejun Heo
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>
2010-08-13x86, vmware: Preset lpj values when on VMware.Alok Kataria
commit 9f242dc10e0c3c1eb32d8c83c18650a35fd7f80d upstream. When running on VMware's platform, we have seen situations where the AP's try to calibrate the lpj values and fail to get good calibration runs becasue of timing issues. As a result delays don't work correctly on all cpus. The solutions is to set preset_lpj value based on the current tsc frequency value. This is similar to what KVM does as well. Signed-off-by: Alok N Kataria <akataria@vmware.com> LKML-Reference: <1280790637.14933.29.camel@ank32.eng.vmware.com> Signed-off-by: H. Peter Anvin <hpa@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-10Linux 2.6.35.1v2.6.35.1Greg Kroah-Hartman
2010-08-10drm/i915: Check overlay stride errata for i830 and i845Chris Wilson
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>
2010-08-10drm/i915: Unset cursor if out-of-bounds upon mode change (v4)Chris Wilson
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>
2010-08-10drm/radeon/kms: handle the case of no active displays properly in the ↵Alex Deucher
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>
2010-08-10drm/radeon/kms/r7xx: add workaround for hw issue with HDP flushAlex Deucher
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>
2010-08-10drm/radeon: fall back to GTT if bo creation/validation in VRAM fails.Michel Dänzer
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>
2010-08-10drm/radeon: add new pci idsAlex Deucher
commit 1297c05a8dfb568c689f057d51a65eebe5ddc86f upstream. New evergreen and r7xx ids. 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>
2010-08-10xen: drop xen_sched_clock in favour of using plain wallclock timeJeremy Fitzhardinge
commit 8a22b9996b001c88f2bfb54c6de6a05fc39e177a upstream. xen_sched_clock only counts unstolen time. In principle this should be useful to the Linux scheduler so that it knows how much time a process actually consumed. But in practice this doesn't work very well as the scheduler expects the sched_clock time to be synchronized between cpus. It also uses sched_clock to measure the time a task spends sleeping, in which case "unstolen time" isn't meaningful. So just use plain xen_clocksource_read to return wallclock nanoseconds for sched_clock. Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-10SCSI: enclosure: fix error path - actually return ERR_PTR() on errorJames Bottomley
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>
2010-08-10CRED: Fix RCU warning due to previous patch fixing __task_cred()'s checksDavid Howells
commit 694f690d27dadccc8cb9d90532e76593b61fe098 upstream. Commit 8f92054e7ca1 ("CRED: Fix __task_cred()'s lockdep check and banner comment") fixed the lockdep checks on __task_cred(). This has shown up a place in the signalling code where a lock should be held - namely that check_kill_permission() requires its callers to hold the RCU lock. Fix group_send_sig_info() to get the RCU read lock around its call to check_kill_permission(). Without this patch, the following warning can occur: =================================================== [ INFO: suspicious rcu_dereference_check() usage. ] --------------------------------------------------- kernel/signal.c:660 invoked rcu_dereference_check() without protection! ... Reported-by: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Oleg Nesterov <oleg@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-10mac80211: avoid scheduling while atomic in mesh_rx_plink_frameJohn W. Linville
commit c937019761a758f2749b1f3a032b7a91fb044753 upstream. While mesh_rx_plink_frame holds sta->lock... mesh_rx_plink_frame -> mesh_plink_inc_estab_count -> ieee80211_bss_info_change_notify ...but ieee80211_bss_info_change_notify is allowed to sleep. A driver taking advantage of that allowance can cause a scheduling while atomic bug. Similar paths exist for mesh_plink_dec_estab_count, so work around those as well. http://bugzilla.kernel.org/show_bug.cgi?id=16099 Also, correct a minor kerneldoc comment error (mismatched function names). Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-08-10cfg80211: don't get expired BSSesJohannes Berg
commit ccb6c1360f8dd43303c659db718e7e0b24175db5 upstream. When kernel-internal users use cfg80211_get_bss() to get a reference to a BSS struct, they may end up getting one that would have been removed from the list if there had been any userspace access to the list. This leads to inconsistencies and problems. Fix it by making cfg80211_get_bss() ignore BSSes that cfg80211_bss_expire() would remove. Fixes http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2180 Reported-by: Jiajia Zheng <jiajia.zheng@intel.com> Tested-by: Jiajia Zheng <jiajia.zheng@intel.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>
2010-08-10cfg80211: ignore spurious deauthJohannes Berg
commit 643f82e32f14faf0d0944c804203a6681b6b0a1e upstream. Ever since mac80211/drivers are no longer fully in charge of keeping track of the auth status, trying to make them do so will fail. Instead of warning and reporting the deauthentication to userspace, cfg80211 must simply ignore it so that spurious deauthentications, e.g. before starting authentication, aren't seen by userspace as actual deauthentications. Reported-by: Paul Stewart <pstew@google.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>
2010-08-10ssb: Handle alternate SSPROM locationLarry Finger
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>
2010-08-10iwlwifi: fix scan abortStanislaw Gruszka
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>
2010-08-10ath9k_hw: fix antenna diversity on AR9285Felix Fietkau
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>
2010-08-10ath9k: fix yet another buffer leak in the tx aggregation codeFelix Fietkau
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>
2010-08-10ath9k: fix TSF after reset on AR913xFelix Fietkau
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>
2010-08-10ath9k: another fix for the A-MPDU buffer leakFelix Fietkau
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>
2010-08-10ath9k: fix a buffer leak in A-MPDU completionFelix Fietkau
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>
2010-08-10ath9k: fix retry count for A-MPDU rate control status reportsFelix Fietkau
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>
2010-08-10ath9k_hw: fix an off-by-one error in the PDADC boundaries calculationFelix Fietkau
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>
2010-08-10ath9k_hw: fix a sign error in the IQ calibration codeFelix Fietkau
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>
2010-08-10ath9k_hw: prevent a fast channel change after a rx DMA stuck issueFelix Fietkau
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>
2010-08-10ath9k: fix a potential buffer leak in the STA teardown pathFelix Fietkau
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>