- 06 Jan, 2010 40 commits
-
-
Sujith authored
commit e8009e98 upstream. When TX DMA termination has failed, the HW has to be reset completely. Doing a fast channel change in this case is insufficient. Also, change the debug level of a couple of messages to FATAL. Signed-off-by:
Sujith <Sujith.Manoharan@atheros.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Luis R. Rodriguez authored
commit 5f70a88f upstream. When we remove a IBSS/AP/Mesh interface we stop DMA but to do this we should ensure hardware is on. Awaken the device prior to these calls. This should ensure DMA is stopped upon suspend and plain device removal. Signed-off-by:
Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by:
-
Bob Copeland authored
commit 242ab7ad upstream. The calibration period is now invoked by triggering a software interrupt from within the ISR by ath5k_hw_calibration_poll() instead of via a timer. However, the calibration interval isn't initialized before interrupts are enabled, so we can have a situation where an interrupt occurs before the interval is assigned, so the interval is actually negative. As a result, the ISR will arm a software interrupt to schedule the tasklet, and then rearm it when the SWI is processed, and so on, leading to a softlockup at modprobe time. Move the initialization order around so the calibration interval is set before interrupts are active. Another possible fix is to schedule the tasklet directly from the poll routine, but I think there are additional plans for the SWI. Signed-off-by:
Bob Copeland <me@bobcopeland.com> Signed-off-by:
-
Johannes Berg authored
commit 3bdb2d48 upstream. Joseph Nahmias reported, in http://bugs.debian.org/562016, that he was getting the following warning (with some log around the issue): ath0: direct probe to AP 00:11:95:77:e0:b0 (try 1) ath0: direct probe responded ath0: authenticate with AP 00:11:95:77:e0:b0 (try 1) ath0: authenticated ath0: associate with AP 00:11:95:77:e0:b0 (try 1) ath0: deauthenticating from 00:11:95:77:e0:b0 by local choice (reason=3) ath0: direct probe to AP 00:11:95:77:e0:b0 (try 1) ath0: RX AssocResp from 00:11:95:77:e0:b0 (capab=0x421 status=0 aid=2) ath0: associated ------------[ cut here ]------------ WARNING: at net/wireless/mlme.c:97 cfg80211_send_rx_assoc+0x14d/0x152 [cfg80211]() Hardware name: 7658CTO ... Pid: 761, comm: phy0 Not tainted 2.6.32-trunk-686 #1 Call Trace: [<c1030a5d>] ? warn_slowpath_common+0x5e/0x8a [<c1030a93>] ? warn_slowpath_null+0xa/0xc [<f86cafc7>] ? cfg80211_send_rx_assoc+0x14d/0x152 ... ath0: link becomes ready ath0: deauthenticating from 00:11:95:77:e0:b0 by local choice (reason=3) ath0: no IPv6 routers present ath0: link is not ready ath0: direct probe to AP 00:11:95:77:e0:b0 (try 1) ath0: direct probe responded ath0: authenticate with AP 00:11:95:77:e0:b0 (try 1) ath0: authenticated ath0: associate with AP 00:11:95:77:e0:b0 (try 1) ath0: RX ReassocResp from 00:11:95:77:e0:b0 (capab=0x421 status=0 aid=2) ath0: associated It is not clear to me how the first "direct probe" here happens, but this seems to be a race condition, if the user requests to deauth after requesting assoc, but before the assoc response is received. In that case, it may happen that mac80211 tries to report the assoc success to cfg80211, but gets blocked on the wdev lock that is held because the user is requesting the deauth. The result is that we run into a warning. This is mostly harmless, but maybe cause an unexpected event to be sent to userspace; we'd send an assoc success event although userspace was no longer expecting that. To fix this, remove the warning and check whether the race happened and in that case abort processing. Reported-by:
Joseph Nahmias <joe@nahmias.net> Cc: 562016-quiet@bugs.debian.org Signed-off-by:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
-
Sujith authored
commit 450aae3d upstream. Currently, in IBSS mode, a single creator would go into a loop trying to merge/scan. This happens because the IBSS timer is rearmed on finishing a scan and the subsequent timer invocation requests another scan immediately. This patch fixes this issue by checking if we have just completed a scan run trying to merge with other IBSS networks. Signed-off-by:
-
Johannes Berg authored
commit 0183826b upstream. My commit 77fdaa12 Author: Johannes Berg <johannes@sipsolutions.net> Date: Tue Jul 7 03:45:17 2009 +0200 mac80211: rework MLME for multiple authentications inadvertedly broke WMM because it removed, along with a bunch of other now useless initialisations, the line initialising sdata->u.mgd.wmm_last_param_set to -1 which would make it adopt any WMM parameter set. If, as is usually the case, the AP uses WMM parameter set sequence number zero, we'd never update it until the AP changes the sequence number. Add the missing initialisation back to get the WMM settings from the AP applied locally. Signed-off-by:
-
Luis R. Rodriguez authored
commit 24feda00 upstream. mac80211 does not propagate failed hardware reconfiguration requests. For suspend and resume this is important due to all the possible issues that can come out of the suspend <-> resume cycle. Not propagating the error means cfg80211 will assume the resume for the device went through fine and mac80211 will continue on trying to poke at the hardware, enable timers, queue work, and so on for a device which is completley unfunctional. The least we can do is to propagate device start issues and warn when this occurs upon resume. A side effect of this patch is we also now propagate the start errors upon harware reconfigurations (non-suspend), but this should also be desirable anyway, there is not point in continuing to reconfigure a device if mac80211 was unable to start the device. For further details refer to the thread: http://marc.info/?t=126151038700001&r=1&w=2Signed-off-by:
-
Zhu Yi authored
commit 6c853da3 upstream. Allocate priv->rx_packets[IWM_RX_ID_HASH + 1] because the max array index is IWM_RX_ID_HASH according to IWM_RX_ID_GET_HASH(). Signed-off-by:
Zhu Yi <yi.zhu@intel.com> Signed-off-by:
-
Daniel Mack authored
commit 45b24168 upstream. The libertas driver copies the SSID buffer back to the wireless core and appends a trailing NULL character for termination. This is a) unnecessary because the buffer is allocated with kzalloc and is hence already NULLed when this function is called, and b) for priv->curbssparams.ssid_len == 32, it writes back one byte too much which causes memory corruptions. Fix this by removing the extra write. Signed-off-by:
Daniel Mack <daniel@caiaq.de> Cc: Stephen Hemminger <shemminger@vyatta.com> Cc: Maithili Hinge <maithili@marvell.com> Cc: Kiran Divekar <dkiran@marvell.com> Cc: Michael Hirsch <m.hirsch@raumfeld.com> Cc: netdev@vger.kernel.org Cc: libertas-dev@lists.infradead.org Cc: linux-wireless@lists.infradead.org Acked-by:
Holger Schurig <holgerschurig@gmail.com> Acked-by:
Dan Williams <dcbw@redhat.com> Signed-off-by:
-
Marcelo Tosatti authored
commit 6e24a6ef upstream. The vcpus are initialized with irr_pending set to false, but loading the LAPIC registers with pending IRR fails to reset the irr_pending variable. Signed-off-by:
Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by:
Avi Kivity <avi@redhat.com> Signed-off-by:
-
Marcelo Tosatti authored
commit fb341f57 upstream. The invlpg prefault optimization breaks Windows 2008 R2 occasionally. The visible effect is that the invlpg handler instantiates a pte which is, microseconds later, written with a different gfn by another vcpu. The OS could have other mechanisms to prevent a present translation from being used, which the hypervisor is unaware of. While the documentation states that the cpu is at liberty to prefetch tlb entries, it looks like this is not heeded, so remove tlb prefetch from invlpg. Signed-off-by:
-
Dan Williams authored
commit a6d52d70 upstream. Put the ioat2 and ioat3 state machines in the halted state with all errors cleared. The ioat1 init path is not disturbed for stability, there are no reported ioat1 initiaization issues. Reported-by:
Roland Dreier <rdreier@cisco.com> Tested-by:
Simon Horman <horms@verge.net.au> Signed-off-by:
Dan Williams <dan.j.williams@intel.com> Signed-off-by:
-
Dan Williams authored
commit cd78809f upstream. When continuing a pq calculation the driver needs 3 extra sources. The driver can perform a 3 source calculation with a single descriptor, but needs an extended descriptor to process up to 8 sources in one operation. However, in the p-disabled case only one extra source is needed. When continuing a p-disabled operation there are occasions (i.e. 0 < src_cnt % 8 < 3) where the tail operation does not need an extended descriptor. Properly account for this fact otherwise invalid 'dmacount' values will be written to hardware usually causing the channel to halt with 'invalid descriptor' errors. Signed-off-by:
-
Joerg Roedel authored
commit 0f764806 upstream. The assumption that acpi_table_parse passes the return value of the hanlder function to the caller proved wrong recently. The return value of the handler function is totally ignored. This makes the initialization code for AMD IOMMU buggy in a way that could cause a kernel panic on initialization. This patch fixes the issue in the AMD IOMMU driver. Signed-off-by:
Joerg Roedel <joerg.roedel@amd.com> Signed-off-by:
-
Jeff Layton authored
commit a2934c7b upstream. The scenario is this: The kernel gets EREMOTE and starts chasing a DFS referral at mount time. The tcon reference is put, which puts the session reference too, but neither pointer is zeroed out. The mount gets retried (goto try_mount_again) with new mount info. Session setup fails fails and rc ends up being non-zero. The code then falls through to the end and tries to put the previously freed tcon pointer again. Oops at: cifs_put_smb_ses+0x14/0xd0 Fix this by moving the initialization of the rc variable and the tcon, pSesInfo and srvTcp pointers below the try_mount_again label. Also, add a FreeXid() before the goto to prevent xid "leaks". Signed-off-by:
Jeff Layton <jlayton@redhat.com> Reported-by:
Gustavo Carvalho Homem <gustavo@angulosolido.pt> Signed-off-by:
Steve French <sfrench@us.ibm.com> Signed-off-by:
-
Ingo Molnar authored
commit a8fe9ea2 upstream. Stephen Rothwell reported the following build warning: lib/dma-debug.c: In function 'dma_debug_device_change': lib/dma-debug.c:680: warning: 'return' with no value, in function returning non-void Introduced by commit f797d988 ("dma-debug: Do not add notifier when dma debugging is disabled"). Return 0 [notify-done] when disabled. (this is standard bus notifier behavior.) Signed-off-by:
Shaun Ruffell <sruffell@digium.com> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Shaun Ruffell authored
commit f797d988 upstream. If CONFIG_HAVE_DMA_API_DEBUG is defined and "dma_debug=off" is specified on the kernel command line, when you detach a driver from a device you can cause the following NULL pointer dereference: BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<c0580d35>] dma_debug_device_change+0x5d/0x117 The problem is that the dma_debug_device_change notifier function is added to the bus notifier chain even though the dma_entry_hash array was never initialized. If dma debugging is disabled, this patch both prevents dma_debug_device_change notifiers from being added to the chain, and additionally ensures that the dma_debug_device_change notifier function is a no-op. Signed-off-by:
-
Nicolas Ferre authored
commit 4297a462 upstream. Correct a typo error in locking calls. Signed-off-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by:
-
NeilBrown authored
commit cbd19983 upstream. evms configures md arrays by: open device send ioctl close device for each different ioctl needed. Since 2.6.29, the device can disappear after the 'close' unless a significant configuration has happened to the device. The change made by "SET_ARRAY_INFO" can too minor to stop the device from disappearing, but important enough that losing the change is bad. So: make sure SET_ARRAY_INFO sets mddev->ctime, and keep the device active as long as ctime is non-zero (it gets zeroed with lots of other things when the array is stopped). This is suitable for -stable kernels since 2.6.29. Signed-off-by:
NeilBrown <neilb@suse.de> Signed-off-by:
-
Mike Travis authored
commit 39d30770 upstream. The wrong address was being used to write the SCIR led regs on remote hubs. Also, there was an inconsistency between how BIOS and the kernel indexed these regs. Standardize on using the lower 6 bits of the APIC ID as the index. This patch fixes the problem of writing to an errant address to a cpu # >= 64. Signed-off-by:
Mike Travis <travis@sgi.com> Reviewed-by:
Jack Steiner <steiner@sgi.com> Cc: Robin Holt <holt@sgi.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> LKML-Reference: <4B3922F9.3060905@sgi.com> [ v2: fix a number of annoying checkpatch artifacts and whitespace noise ] Signed-off-by:
-
Julia Lawall authored
commit 6057912d upstream. sizeof(dev->dev_addr) is the size of a pointer. A few lines above, the size of this field is obtained using netdev->addr_len for a call to memcpy, so do the same here. A simplified version of the semantic patch that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ expression *x; expression f; type T; @@ *f(...,(T)x,...) // </smpl> Signed-off-by:
Julia Lawall <julia@diku.dk> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Alan Stern authored
commit da307123 upstream. This patch (as1315) fixes some bugs in the USB core authorization code: usb_deauthorize_device() should deallocate the device strings instead of leaking them, and it should invoke usb_destroy_configuration() (which does proper reference counting) instead of freeing the config information directly. usb_authorize_device() shouldn't change the device strings until it knows that the authorization will succeed, and it should autosuspend the device at the end (having autoresumed the device at the start). Because the device strings can be changed, the sysfs routines to display the strings must protect the string pointers by locking the device. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> CC: Inaky Perez-Gonzalez <inaky@linux.intel.com> Acked-by:
David Vrabel <david.vrabel@csr.com> Signed-off-by:
-
Alan Stern authored
commit 8d8558d1 upstream. This patch (as1314) renames usb_configure_device() and usb_configure_device_otg() in the hub driver. Neither name is appropriate because these routines enumerate devices, they don't configure them. That's handled by usb_choose_configuration() and usb_set_configuration(). Signed-off-by:
-
Oliver Neukum authored
commit 652fd781 upstream. The device must be marked busy as it receives data. Signed-off-by:
Oliver Neukum <oliver@neukum.org> Tested-by:
Matthew Garrett <mjg@redhat.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
-
Sergei Shtylyov authored
commit 17be5c5f upstream. Gadget stalling a zero-length SETUP request results in this error message: SetupEnd came in a wrong ep0stage idle In order to avoid it, always set the CSR0.DataEnd bit after detecting a zero- length request. Add the missing '\n' to the error message itself as well... Signed-off-by:
Sergei Shtylyov <sshtylyov@ru.mvista.com> Acked-by:
Anand Gadiyar <gadiyar@ti.com> Signed-off-by:
Felipe Balbi <felipe.balbi@nokia.com> Signed-off-by:
-
pancho horrillo authored
commit 37e9066b upstream. brightness status is reported by the Apple Cinema Displays as an 'unsigned char' (u8) value, but the code used 'char' instead. Note that he driver was developed on the PowerPC architecture, where the two types are synonymous, which is not always the case. Fixed that. Otherwise the driver will interpret brightness levels > 127 as negative, and fail to load. Signed-off-by:
pancho horrillo <pancho@pancho.name> Signed-off-by:
-
Donny Kurnia authored
commit c983202b upstream. I made this patch for usbserial driver to add the support for EVDO modem Haier CE100. The bugs report for this is here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/490068 This patch based on these post: http://blankblondtank.wordpress.com/2009/09/04/mengoptimalkan-koneksi-modem-haier-ce-100-cdma-di-linux/ http://tantos.web.id/blogs/how-to-internet-connection-using-cdma-evdo-modem-and-karmic-koala-ubuntu-9-10 I hope this patch can help other that have the Haier C100 modem, mostly in my country, Indonesia. Signed-off-by:
Donny Kurnia <donnykurnia@gmail.com> Signed-off-by:
-
Clemens Ladisch authored
commit ac06c067 upstream. While converting emi62 to use request_firmware(), the driver was also changed to use the ihex helper functions. However, this broke the loading of the FPGA firmware because the code tries to access the addr field of the EOF record which works with a plain array that has an empty last record but not with the ihex helper functions where the end of the data is signaled with a NULL record pointer, resulting in: BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<f80d248c>] emi62_load_firmware+0x33c/0x740 [emi62] This can be fixed by changing the loop condition to test the return value of ihex_next_binrec() directly (like in emi26.c). Signed-off-by:
Clemens Ladisch <clemens@ladisch.de> Reported-and-tested-by:
Der Mickster <retroeffective@gmail.com> Acked-by:
David Woodhouse <David.Woodhouse@intel.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Dave Airlie authored
commit 794f3141 upstream. drivers/gpu/drm/radeon/radeon_test.c:45: undefined reference to `__udivdi3' Reported-by:
Mr. James W. Laferriere <babydr@baby-dragons.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Eric Millbrandt authored
commit 48e3cbb3 upstream. This patch fixes a bug where "virtual" registers were being written to the ac97 bus. This was causing unrelated registers to become corrupted (headphone 0x04, touchscreen 0x78, etc). This patch duplicates protection that was included in the wm9713 driver. Signed-off-by:
Eric Millbrandt <emillbrandt@dekaresearch.com> Acked-by:
Liam Girdwood <lrg@slimlogic.co.uk> Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by:
-
Neil Campbell authored
commit bb7f20b1 upstream. This patch fixes the handling of VSX alignment faults in little-endian mode (the current code assumes the processor is in big-endian mode). The patch also makes the handlers clear the top 8 bytes of the register when handling an 8 byte VSX load. This is based on 2.6.32. Signed-off-by:
Neil Campbell <neilc@linux.vnet.ibm.com> Acked-by:
Michael Neuling <mikey@neuling.org> Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Zhao Yakui authored
commit 13c199c0 upstream. On some laptops it will return NOTIFY_OK(non-zero) when calling the ACPI LID notifier. Then it is used as the result of ACPI LID resume function, which will complain the following warning message in course of suspend/resume: >PM: Device PNP0C0D:00 failed to resume: error 1 This patch is to eliminate the above warning message. http://bugzilla.kernel.org/show_bug.cgi?id=14782Signed-off-by:
Zhao Yakui <yakui.zhao@intel.com> Signed-off-by:
Len Brown <len.brown@intel.com> Signed-off-by:
-
Alexey Starikovskiy authored
commit 55b313f2 upstream. MSI strings should be ORed, not ANDed. Reference: http://bugzilla.kernel.org/show_bug.cgi?id=14446Signed-off-by:
Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by:
-
Stefan Bader authored
commit bdc731bc upstream. BugLink: https://bugs.launchpad.net/ubuntu/+bug/435958 The module alias currently matches any Acer computer but when loaded the BIOS checks will only succeed on Aspire One models. This causes a invalid BIOS warning for all other models (seen on Aspire 4810T). This is not fatal but worries users that see this message. Limiting the moule alias to models starting with AOA or DOA for Packard Bell. Signed-off-by:
Stefan Bader <stefan.bader@canonical.com> Acked-by:
Borislav Petkov <petkovbb@gmail.com> Acked-by:
Peter Feuerer <peter@piie.net> Signed-off-by:
-
Takashi Iwai authored
commit 035eb0cf upstream. Some model quirks missed the corresponding capsrc_nids. This resulted in non-working capture source selection. Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Clemens Ladisch authored
commit 3e85fd61 upstream. When allocating the PCM buffer, use vmalloc_user() instead of vmalloc(). Otherwise, it would be possible for applications to play the previous contents of the kernel memory to the speakers, or to read it directly if the buffer is exported to userspace. Signed-off-by:
-
Guennadi Liakhovetski authored
commit 48c03ce7 upstream. The wm8974 datasheet defines BUFIOEN as bit 2. Signed-off-by:
Guennadi Liakhovetski <g.liakhovetski@gmx.de> Acked-by:
-
Bartlomiej Zolnierkiewicz authored
commit 509426bd upstream. adev->dma_mode stores the transfer mode value not UDMA mode number so the condition in cmd64x_set_dmamode() is always true and the higher UDMA clock is always selected. This can potentially result in data corruption when UDMA33 device is used, when 40-wire cable is used or when the error recovery code decides to lower the device speed down. The issue was introduced in the commit 6a40da02 ("libata cmd64x: whack into a shape that looks like the documentation") which goes back to kernel 2.6.20. Signed-off-by:
Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> Signed-off-by:
Jeff Garzik <jgarzik@redhat.com> Signed-off-by:
-
Sergei Shtylyov authored
commit 256ace9b upstream. The clock turnaround code still doesn't work for several reasons: - 'USE_DPLL' flag in 'ap->host->private_data' is never initialized or updated, so the driver can only set the chip to the DPLL clock mode, not the PCI mode; - the driver doesn't serialize access to the channels depending on the current clock mode like the vendor drivers, so the clock turnaround is only executed "optionally", not always as it should be; - the wrong ports are written to when hpt3x2n_set_clock() is called for the secondary channel; - hpt3x2n_set_clock() can inadvertently enable the disabled channels when resetting the channel state machines. Signed-off-by:
-
Thomas Gleixner authored
commit bb6eddf7 upstream. Xiaotian Feng triggered a list corruption in the clock events list on CPU hotplug and debugged the root cause. If a CPU registers more than one per cpu clock event device, then only the active clock event device is removed on CPU_DEAD. The unused devices are kept in the clock events device list. On CPU up the clock event devices are registered again, which means that we list_add an already enqueued list_head. That results in list corruption. Resolve this by removing all devices which are associated to the dead CPU on CPU_DEAD. Reported-by:
Xiaotian Feng <dfeng@redhat.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Tested-by:
-
