- 03 Feb, 2012 40 commits
-
-
Stanislaw Gruszka authored
commit b3ef051d upstream. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=784345Reported-by:
Francis Moreau <francis.moro@gmail.com> Reported-and-tested-by:
Christian D <chrisudeussen@gmail.com> Reported-and-tested-by:
Jimmy Dorff <jdorff@phy.duke.edu> Reported-and-tested-by: collura@ieee.org Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Ryan Mallon authored
commit bf9c05d5 upstream. The assignment of handle in vmw_framebuffer_create_handle doesn't actually do anything useful and is incorrectly assigning an integer value to a pointer argument. It appears that this is a typo and should be dereferencing handle rather than assigning to it directly. This fixes a bug where an undefined handle value is potentially returned to user-space. Signed-off-by:
Ryan Mallon <rmallon@gmail.com> Reviewed-by: Jakob Bornecrantz<jakob@vmware.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Johannes Berg authored
commit b49ba04a upstream. When an interrupt comes in, we read the reason bits and collect them into "trans_pcie->inta". This happens with the spinlock held. However, there's a bug resetting this variable -- that happens after the spinlock has been released. This means that it is possible for interrupts to be missed if the reset happens after some other interrupt reasons were already added to the variable. I found this by code inspection, looking for a reason that we sometimes see random commands time out. It seems possible that this causes such behaviour, but I can't say for sure right now since it happens extremely infrequently on my test systems. Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Lucas Kannebley Tavares authored
commit 26aa38ca upstream. There was an error on the jsm driver that would cause it to be unable to recover after a second error is detected. At the first error, the device recovers properly: [72521.485691] EEH: Detected PCI bus error on device 0003:02:00.0 [72521.485695] EEH: This PCI device has failed 1 times in the last hour: ... [72532.035693] ttyn3 at MMIO 0x0 (irq = 49) is a jsm [72532.105689] jsm: Port 3 added However, at the second error, it cascades until EEH disables the device: [72631.229549] Call Trace: ... [72641.725687] jsm: Port 3 added [72641.725695] EEH: Detected PCI bus error on device 0003:02:00.0 [72641.725698] EEH: This PCI device has failed 3 times in the last hour: It was caused because the PCI state was not being saved after the first restore. Therefore, at the second recovery the PCI state would not be restored. Signed-off-by:
Lucas Kannebley Tavares <lucaskt@linux.vnet.ibm.com> Signed-off-by:
Breno Leitao <brenohl@br.ibm.com> Acked-by:
Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com> Signed-off-by:
-
Rabin Vincent authored
commit ef605fdb upstream. Protect against pl011_console_write() and the interrupt for the console UART running concurrently on different CPUs. Otherwise the console_write could spin for a long time waiting for the UART to become not busy, while the other CPU continuously services UART interrupts and keeps the UART busy. The checks for sysrq and oops_in_progress are taken from 8250.c. Signed-off-by:
Rabin Vincent <rabin.vincent@stericsson.com> Reviewed-by:
Srinidhi Kasagar <srinidhi.kasagar@stericsson.com> Reviewed-by:
Bibek Basu <bibek.basu@stericsson.com> Reviewed-by:
Shreshtha Kumar Sahu <shreshthakumar.sahu@stericsson.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Jiri Slaby authored
commit 0eee50af upstream. Commit 74c21077 (serial: Use block_til_ready helper) and its fixup 3f582b8c (serial: fix termios settings in open) introduced a regression on UV systems. The serial eventually freezes while being used. It's completely unpredictable and sometimes needs a heap of traffic to happen first. To reproduce this, yast installation was used as it turned out to be pretty reliable in reproducing. Especially during installation process where one doesn't have an SSH daemon running. And no monitor as the HW is completely headless. So this was fun to find. Given the machine doesn't boot on vanilla before 2.6.36 final. (And the commits above are older.) Unless there is some bad race in the code, the hardware seems to be pretty broken. Otherwise pure MSR read should not cause such a bug, or? So to prevent the bug, revert to the old behavior. I.e. read modem status only if we really have to -- for non-CLOCAL set serials. Non-CLOCAL works on this hardware OK, I tried. See? I don't. And document that shit. Signed-off-by:
Jiri Slaby <jslaby@suse.cz> References: https://lkml.org/lkml/2011/12/6/573 References: https://bugzilla.novell.com/show_bug.cgi?id=718518Signed-off-by:
-
Eric W. Biederman authored
commit 6d443d84 upstream. Calling edge_remove_sysfs_attrs from edge_disconnect is too late as the device has already been removed from sysfs. Do the simple and obvious thing and make edge_remove_sysfs_attrs the port_remove method. Signed-off-by:
Eric W. Biederman <ebiederm@xmission.com> Reported-by:
Wolfgang Frisch <wfpub@roembden.net> Signed-off-by:
-
Felipe Balbi authored
commit 68d8a781 upstream. The way our code was written, we should never have a DWC3_EP_PENDING_REQUEST flag set out of a Data Phase and the code in __dwc3_gadget_ep0_queue() did not reflect that situation properly. Tidy up that case to avoid any possible mistakes when starting requests for IRQs which are long gone. Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Dan Williams authored
commit 074cc735 upstream. More ports we now know how to talk to. Signed-off-by:
Dan Williams <dcbw@redhat.com> Signed-off-by:
-
Bjørn Mork authored
commit e8537bd2 upstream. using a separate read and write mutex for locking is sufficient to make the driver accept simultaneous read and write. This improves useability a lot. Signed-off-by:
Bjørn Mork <bjorn@mork.no> Cc: Oliver Neukum <oneukum@suse.de> Signed-off-by:
-
Bjørn Mork authored
commit c428b70c upstream. wdm_in_callback() will also touch this field, so we cannot change it without locking Signed-off-by:
Oliver Neukum <oneukum@suse.de> Signed-off-by:
-
Alan Cox authored
commit 2353f806 upstream. 0x04d8, 0x000a: Hornby Elite Signed-off-by:
Alan Cox <alan@linux.intel.com> Signed-off-by:
-
Peter Naulls authored
commit fc216ec3 upstream. I tested this against 2.6.39 in the Ubuntu kernel, however I see the IDs are not in latest 3.2 git. This adds IDs for the FTDI controller in the Rainforest Automation Zigbee dongle. Signed-off-by:
Peter Naulls <peter@chocky.org> Signed-off-by:
-
Peter Korsgaard authored
commit 55f13aea upstream. Port A for JTAG, port B for serial. Signed-off-by:
Peter Korsgaard <jacmet@sunsite.dk> Signed-off-by:
-
Johan Hovold authored
commit 108e02b1 upstream. Fix regression introduced by commit b1ffb4c8 ("USB: Fix Corruption issue in USB ftdi driver ftdi_sio.c") which caused the termios settings to no longer be initialised at open. Consequently it was no longer possible to set the port to the default speed of 9600 baud without first changing to another baud rate and back again. Reported-by:
Roland Ramthun <mail@roland-ramthun.de> Signed-off-by:
Johan Hovold <jhovold@gmail.com> Tested-by:
-
Johan Hovold authored
commit eb833a9e upstream. Return EINVAL if new baud_base does not match the current one. The baud_base is device specific and can not be changed. This restores the old (pre-2005) behaviour which was changed due to a misunderstanding regarding this fact (see https://lkml.org/lkml/2005/1/20/84). Reported-by:
Torbjörn Lofterud <torbjorn@pi.nxs.se> Signed-off-by:
-
Kentaro Matsuyama authored
commit e423d740 upstream. Add vendor and product ID for USB 3G/LTE modem of docomo L-02C Signed-off-by:
Kentaro Matsuyama <kentaro.matsuyama@gmail.com> Signed-off-by:
-
nagalakshmi.nandigama@lsi.com authored
commit 2cb6fc8c upstream. Removed redundant calling of _scsih_probe_devices() from _scsih_probe as it is getting called from _scsih_scan_finished. Also moved the function scsi_scan_host(shost) to get called after the volumes on warp drive are reported to the OS. Otherwise by the time the (ioc->hide_drives) flags is set, the volumes on warp drive are reported to the OS already. Also modified the initialization of reply queues only in case of driver load time in the function _base_make_ioc_operational(). Signed-off-by:
Nagalakshmi Nandigama <nagalakshmi.nandigama@lsi.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com> Signed-off-by:
-
David Vrabel authored
commit 7a7546b3 upstream. If NR_CPUS < 256 then arch_spinlock_t is only 16 bits wide but struct xen_spinlock is 32 bits. When a spin lock is contended and xl->spinners is modified the two bytes immediately after the spin lock would be corrupted. This is a regression caused by 84eb950d (x86, ticketlock: Clean up types and accessors) which reduced the size of arch_spinlock_t. Fix this by making xl->spinners a u8 if NR_CPUS < 256. A BUILD_BUG_ON() is also added to check the sizes of the two structures are compatible. In many cases this was not noticable as there would often be padding bytes after the lock (e.g., if any of CONFIG_GENERIC_LOCKBREAK, CONFIG_DEBUG_SPINLOCK, or CONFIG_DEBUG_LOCK_ALLOC were enabled). The bnx2 driver is affected. In struct bnx2, phy_lock and indirect_lock may have no padding after them. Contention on phy_lock would corrupt indirect_lock making it appear locked and the driver would deadlock. Signed-off-by:
David Vrabel <david.vrabel@citrix.com> Signed-off-by:
Jeremy Fitzhardinge <jeremy@goop.org> Acked-by:
Ian Campbell <ian.campbell@citrix.com> Signed-off-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by:
-
Eric W. Biederman authored
commit ce597919 upstream. Recently an OOPS was observed from the usb serial io_ti driver when it tried to remove sysfs directories. Upon investigation it turns out this driver was always buggy and that a recent sysfs change had stopped guarding itself against removing attributes from sysfs directories that had already been removed. :( Historically we have been silent about attempting to files from nonexistent sysfs directories and have politely returned error codes. That has resulted in people writing broken code that ignores the error codes. Issue a kernel WARNING and a stack backtrace to make it clear in no uncertain terms that abusing sysfs is not ok, and the callers need to fix their code. This change transforms the io_ti OOPS into a more comprehensible error message and stack backtrace. Signed-off-by:
-
Will Deacon authored
commit 612539e8 upstream. On v7, we use the same cache maintenance instructions for data lines as for unified lines. This was not the case for v6, where HARVARD_CACHE was defined to indicate the L1 cache topology. This patch removes the erroneous compile-time check for HARVARD_CACHE in proc-v7.S, ensuring that we perform I-side invalidation at boot. Reported-and-Acked-by:
Shawn Guo <shawn.guo@linaro.org> Acked-by:
Catalin Marinas <Catalin.Marinas@arm.com> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Srinidhi KASAGAR authored
commit d65015f7 upstream. This applies ARM errata 764369 for all ux500 platforms. Signed-off-by:
-
Nicolas Ferre authored
commit 3e90772f upstream. Currently setting it to PQFP changes subtype to BGA as subtypes are swapped in at91rm9200_set_type(). Wrong subtype causes GPIO bank D not to work at all. After this fix, subtype is still set as unknown. But board code should fill it in with proper value. Another information is thus printed. Bug discovery and first implementation made by Veli-Pekka Peltola. Signed-off-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Acked-by:
Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Signed-off-by:
-
Eric Anholt authored
commit 04115a9d upstream. Signed-off-by:
Eric Anholt <eric@anholt.net> Reviewed-by:
Keith Packard <keithp@keithp.com> Reviewed-by:
Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by:
Kenneth Graunke <kenneth@whitecape.org> Signed-off-by:
-
Paulo Zanoni authored
commit ba68e086 upstream. This is a revert of 81a14b46. We already set the mode polarity using the SDVO commands with struct intel_sdvo_dtd. We have at least 3 bugs that get fixed with this patch. The documentation, despite not clear, can also be interpreted in a way that suggests this patch is needed. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=15766 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42174 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43333Reviewed-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Daniel Vetter authored
commit 4cd53c0c upstream. Two things seem to do the trick on my ivb machine here: - prevent the gt from powering down while waiting for seqno notification interrupts by grabbing the force_wake in get_irq (and dropping it in put_irq again). - ordering writes from the ring's CS by reading a CS register, ACTHD seems to work. Only the blt&bsd ring on ivb seem to be massively affected by this, but for paranoia do this dance also on the render ring and on snb (i.e. all gpus with forcewake). Tested with Eric's glCopyPixels loop which without this patch scores a missed irq every few seconds. This patch needs my forcewake rework to use a spinlock instead of dev->struct_mutex. After crawling through docs a lot I've found the following nugget: Internal doc "SNB GT PM Programming Guide", Section 4.3.1: "GT does not generate interrupts while in RC6 (by design)" So it looks like rc6 and irq generation are indeed related. v2: Improve the comment per Eugeni Dodonov's suggestion. v3: Add the documentation snipped. Also restrict the w/a to ivb only for -fixes, as suggested by Keith Packard. Cc: Eric Anholt <eric@anholt.net> Cc: Kenneth Graunke <kenneth@whitecape.org> Cc: Eugeni Dodonov <eugeni.dodonov@intel.com> Tested-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Takashi Iwai authored
commit b3a81520 upstream. The very same problem is seen on Haier W18 laptop with ALC861 as seen on ASUS A6Rp, which was fixed by the commit 3b25eb69. Now we just need to add a new SSID entry pointing to the same fixup. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=42656Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Takashi Iwai authored
commit 3b25eb69 upstream. The refactoring of Realtek codec driver in 3.2 kernel caused a regression for ASUS A6Rp laptop; it doesn't give any output. The reason was that this machine has a secret master mute (or EAPD) control via NID 0x0f VREF. Setting VREF50 on this node makes the sound working again. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=42588Signed-off-by:
-
Gustavo Maciel Dias Vieira authored
commit a6a600d1 upstream. HP laptop models with buggy BIOS are apparently frequent, including machines with different codecs. Set the polarity of the mute led based on the SSID and include an entry for the HP Mini 110-3100. Signed-off-by:
Gustavo Maciel Dias Vieira <gustavo@sagui.org> Tested-by:
Predrag Ivanovic <predivan@open.telekom.rs> Signed-off-by:
-
Andreas Schwab authored
commit 2a353506 upstream. Passing the address of a variable as an operand to an asm statement doesn't mark the value of this variable as used, so gcc may optimize its initialisation away. Fix this by using the "m" constraint instead. Signed-off-by:
Andreas Schwab <schwab@linux-m68k.org> Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
-
Andreas Herrmann authored
commit 5b68edc9 upstream. We've decided to provide CPU family specific container files (starting with CPU family 15h). E.g. for family 15h we have to load microcode_amd_fam15h.bin instead of microcode_amd.bin Rationale is that starting with family 15h patch size is larger than 2KB which was hard coded as maximum patch size in various microcode loaders (not just Linux). Container files which include patches larger than 2KB cause different kinds of trouble with such old patch loaders. Thus we have to ensure that the default container file provides only patches with size less than 2KB. Signed-off-by:
Andreas Herrmann <andreas.herrmann3@amd.com> Cc: Borislav Petkov <borislav.petkov@amd.com> Cc: <stable@kernel.org> Link: http://lkml.kernel.org/r/20120120164412.GD24508@alberich.amd.com [ documented the naming convention and tidied the code a bit. ] Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Russ Anderson authored
commit 5a51467b upstream. uv_gpa_to_soc_phys_ram() was inadvertently ignoring the shift values. This fix takes the shift into account. Signed-off-by:
Russ Anderson <rja@sgi.com> Link: http://lkml.kernel.org/r/20120119020753.GA7228@sgi.comSigned-off-by:
-
Cliff Wickman authored
commit d2ebc71d upstream. Initialize two spinlocks in tlb_uv.c and also properly define/initialize the uv_irq_lock. The lack of explicit initialization seems to be functionally harmless, but it is diagnosed when these are turned on: CONFIG_DEBUG_SPINLOCK=y CONFIG_DEBUG_MUTEXES=y CONFIG_DEBUG_LOCK_ALLOC=y CONFIG_LOCKDEP=y Signed-off-by:
Cliff Wickman <cpw@sgi.com> Cc: Dimitri Sivanich <sivanich@sgi.com> Link: http://lkml.kernel.org/r/E1RnXd1-0003wU-PM@eag09.americas.sgi.com [ Added the uv_irq_lock initialization fix by Dimitri Sivanich ] Signed-off-by:
-
Stefan Berger authored
commit a927b813 upstream. This patch adds a delay after aborting a command. Some TPMs need this and will not process the subsequent command correctly otherwise. It's worth noting that a TPM randomly failing to process a command, maps to randomly failing suspend/resume operations. Signed-off-by:
Stefan Berger <stefanb@linux.vnet.ibm.com> Signed-off-by:
Rajiv Andrade <srajiv@linux.vnet.ibm.com> Signed-off-by:
-
Alexey Dobriyan authored
commit 51fc6dc8 upstream. For rounds 16--79, W[i] only depends on W[i - 2], W[i - 7], W[i - 15] and W[i - 16]. Consequently, keeping all W[80] array on stack is unnecessary, only 16 values are really needed. Using W[16] instead of W[80] greatly reduces stack usage (~750 bytes to ~340 bytes on x86_64). Line by line explanation: * BLEND_OP array is "circular" now, all indexes have to be modulo 16. Round number is positive, so remainder operation should be without surprises. * initial full message scheduling is trimmed to first 16 values which come from data block, the rest is calculated before it's needed. * original loop body is unrolled version of new SHA512_0_15 and SHA512_16_79 macros, unrolling was done to not do explicit variable renaming. Otherwise it's the very same code after preprocessing. See sha1_transform() code which does the same trick. Patch survives in-tree crypto test and original bugreport test (ping flood with hmac(sha512). See FIPS 180-2 for SHA-512 definition http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdfSigned-off-by:
Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Alexey Dobriyan authored
commit 84e31fdb upstream. commit f9e2bca6 aka "crypto: sha512 - Move message schedule W[80] to static percpu area" created global message schedule area. If sha512_update will ever be entered twice, hash will be silently calculated incorrectly. Probably the easiest way to notice incorrect hashes being calculated is to run 2 ping floods over AH with hmac(sha512): #!/usr/sbin/setkey -f flush; spdflush; add IP1 IP2 ah 25 -A hmac-sha512 0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000025; add IP2 IP1 ah 52 -A hmac-sha512 0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000052; spdadd IP1 IP2 any -P out ipsec ah/transport//require; spdadd IP2 IP1 any -P in ipsec ah/transport//require; XfrmInStateProtoError will start ticking with -EBADMSG being returned from ah_input(). This never happens with, say, hmac(sha1). With patch applied (on BOTH sides), XfrmInStateProtoError does not tick with multiple bidirectional ping flood streams like it doesn't tick with SHA-1. After this patch sha512_transform() will start using ~750 bytes of stack on x86_64. This is OK for simple loads, for something more heavy, stack reduction will be done separatedly. Signed-off-by:
-
Jan Kara authored
commit 353b67d8 upstream. When we reach cleanup_journal_tail(), there is no guarantee that checkpointed buffers are on a stable storage - especially if buffers were written out by log_do_checkpoint(), they are likely to be only in disk's caches. Thus when we update journal superblock, effectively removing old transaction from journal, this write of superblock can get to stable storage before those checkpointed buffers which can result in filesystem corruption after a crash. A similar problem can happen if we replay the journal and wipe it before flushing disk's caches. Thus we must unconditionally issue a cache flush before we update journal superblock in these cases. The fix is slightly complicated by the fact that we have to get log tail before we issue cache flush but we can store it in the journal superblock only after the cache flush. Otherwise we risk races where new tail is written before appropriate cache flush is finished. I managed to reproduce the corruption using somewhat tweaked Chris Mason's barrier-test scheduler. Also this should fix occasional reports of 'Bit already freed' filesystem errors which are totally unreproducible but inspection of several fs images I've gathered over time points to a problem like this. Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
Johannes Berg authored
commit bc4934bc upstream. When deauth is requested while an auth or assoc work item is in progress, we currently delete it without regard for any state it might need to clean up. Fix it by cleaning up for those items. In the case Pontus found, the problem manifested itself as such: authenticate with 00:23:69:aa:dd:7b (try 1) authenticated failed to insert Dummy STA entry for the AP (error -17) deauthenticating from 00:23:69:aa:dd:7b by local choice (reason=2) It could also happen differently if the driver uses the tx_sync callback. We can't just call the ->done() method of the work items because that will lock up due to the locking in cfg80211. This fix isn't very clean, but that seems acceptable since I have patches pending to remove this code completely. Reported-by:
Pontus Fuchs <pontus.fuchs@gmail.com> Tested-by:
-
Stanislaw Gruszka authored
commit f96b08a7 upstream. This patch workaround live deadlock problem caused by infinite loop in brcms_c_wait_for_tx_completion(). I do not consider the patch as the proper fix, which should fix the real reason of tx queue flush failure, but patch helps with system lockup. Reference: https://bugzilla.kernel.org/show_bug.cgi?id=42576Reported-and-tested-by:
Patrick <ragamuffin@datacomm.ch> Signed-off-by:
-
Mark Brown authored
commit a14304ed upstream. We should be allowing a 5ms delay after the charge pump is started in order to ensure it has finished ramping. Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by:
-
