summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2009-12-18intel-iommu: Fix oops with intel_iommu=igfx_offDavid Woodhouse
commit 44cd613c0e4cd93079ea2a93aa06649d8ca0830a upstream. The hotplug notifier will call find_domain() to see if the device in question has been assigned an IOMMU domain. However, this should never be called for devices with a "dummy" domain, such as graphics devices when intel_iommu=igfx_off is set and the corresponding IOMMU isn't even initialised. If you do that, it'll oops as it dereferences the (-1) pointer. The notifier function should check iommu_no_mapping() for the device before doing anything else. Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-18intel-iommu: Check for an RMRR which ends before it starts.David Woodhouse
commit 5595b528b49a702c0428c0762bab60999648254c upstream. Some HP BIOSes report an RMRR region (a region which needs a 1:1 mapping in the IOMMU for a given device) which has an end address lower than its start address. Detect that and warn, rather than triggering the BUG() in dma_pte_clear_range(). Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-18intel-iommu: Apply BIOS sanity checks for interrupt remapping too.David Woodhouse
commit 6ecbf01c7ce4c0f4c3bdfa0e64ac6258328fda6c upstream. The BIOS errors where an IOMMU is reported either at zero or a bogus address are causing problems even when the IOMMU is disabled -- because interrupt remapping uses the same hardware. Ensure that the checks get applied for the interrupt remapping initialisation too. Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-18intel-iommu: Detect DMAR in hyperspace at probe time.Chris Wright
commit 2c99220810c1c79322034628b993573b088ff2da upstream. Many BIOSes will lie to us about the existence of an IOMMU, and claim that there is one at an address which actually returns all 0xFF. We need to detect this early, so that we know we don't have a viable IOMMU and can set up swiotlb before it's too late. Signed-off-by: Chris Wright <chrisw@sous-sol.org> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-18drm/i915: Fix LVDS stability issue on IronlakeZhenyu Wang
commit 1b3c7a47f993bf9ab6c4c7cc3bbf5588052b58f4 upstream. In disable sequence, all output ports on PCH have to be disabled before PCH transcoder, but LVDS port was left always enabled. This one fixes that by disable LVDS port properly during pipe disable process, and resolved stability issue seen on Ironlake. Also move panel fitting disable time just after pipe disable to align with the spec. Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-18drm/i915: PineView only has LVDS and CRT portsZhenyu Wang
commit 103a196f4224dc6872081305cf7f82ebf67aa7bd upstream. PineView only has 2 ports for LVDS and CRT. Don't enable other ports for it. Cc: Shaohua Li <shaohua.li@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-18drm/i915: Avoid NULL dereference with component_only tv_modesChris Wilson
commit d271817baecbccb47da0d9f28c285a0dae8a06b7 upstream. In commit d2d9f2324, the guard for a valid video mode was removed. This caused the regression: kernel crash during kms graphic boot on Intel GM4500 platform https://bugzilla.redhat.com/show_bug.cgi?id=540218 This patches changes the logic slightly not to rely on a coupled variable, but to just check whether the video_modes is valid before dereferencing. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Zhenyu Wang <zhenyu.z.wang@intel.com> [ickle: Actually reference the correct bug report] Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-18bcm63xx_enet: fix compilation failure after get_stats_count removalFlorian Fainelli
commit a3f92eea04101d9a8e14d50f8048cc5b7bca07a8 upstream. This patch converts bcm63xx_enet to uset get_sset_count like the other drivers do. Signed-off-by: Florian Fainelli <ffainelli@freebox.fr> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-18V4L/DVB (13116): gspca - ov519: Webcam 041e:4067 added.Rafal Milecki
commit 518c8df77c21b7d1690dd8b96eb0e54c4ec1c9c1 upstream. Signed-off-by: Rafal Milecki <zajec5@gmail.com> Signed-off-by: Jean-Francois Moine <moinejf@free.fr> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> Cc: Surbhi Palande <surbhi.palande@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-18asus-laptop: change light sens default values.Corentin Chary
commit d951d4cc84e8b5ddb8e0ab81cf6a72cc73fdd668 upstream. The light sensor disable brightness key and /sys/class/backlight/ control. There was a lot of report from users who didn't understand why they couldn't change their brightness, including: https://bugs.launchpad.net/bugs/222171 https://bugzilla.novell.com/show_bug.cgi?id=514747 http://bugzilla.kernel.org/show_bug.cgi?id=13671 http://bugzilla.kernel.org/show_bug.cgi?id=14432 Now the light sensor is disabled, and if the user want to enable it, the level should be ok. The funny thing is that comments where ok, not code. Cc: stable@kernel.org Cc: Thomas Renninger <trenn@suse.de> Cc: Peter Küppers <peter-mailbox@web.de> Cc: Michael Franzl <michaelfranzl@gmx.at> Cc: Ian Turner <vectro@vectro.org> Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-18acerhdf: add new BIOS versionsPeter Feuerer
commit 360657463679dee44f0b167ffa61f563b4fee101 upstream. Added new BIOS versions for following netbooks: Acer 1410, Gateway LT31, Packard Bell DOA150. As the Gateway LT31 machines have different register values for setting and checking the off-state, the "cmd_off" variable has been splitted up to "cmd_off" and "chk_off". Signed-off-by: Peter Feuerer <peter@piie.net> Cc: Borislav Petkov <petkovbb@gmail.com> Cc: Andreas Mohr <andi@lisas.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-18matroxfb: fix problems with display stabilityAlan Cox
commit 8c651311a3a08c1e4815de6933e00a760e498dae upstream. Regression caused in 2.6.23 and then despite repeated requests never fixed or dealt with (Petr promised to sort it in 2008 but seems to have forgotten). Enough is enough - remove the problem line that was added. If it upsets someone they've had two years to deal with it and at the very least it'll rattle their cage and wake them up. Addresses http://bugzilla.kernel.org/show_bug.cgi?id=9709 Signed-off-by: Alan Cox <alan@linux.intel.com> Reported-by: Damon <account@bugzilla.kernel.org.juxtaposition.net> Tested-by: Ruud van Melick <rvm1974@raketnet.nl> Cc: Petr Vandrovec <VANDROVE@vc.cvut.cz> Cc: Pekka Enberg <penberg@cs.helsinki.fi> Cc: Paul A. Clarke <pc@us.ibm.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>
2009-12-18ipw2100: fix rebooting hang with driver loadedZhu Yi
commit 52ce3e9a7db754b78cf2cbabc87013f921b25b28 upstream. Add PCI .shutdown method so that we can disable the device during shutdown or reboot. Without this, the reboot doesn't work well on some platforms. This fixes http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2124 Tested-by: pablo <pablolm2005@gmail.com> Signed-off-by: Zhu Yi <yi.zhu@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-18thinkpad-acpi: preserve rfkill state across suspend/resumeHenrique de Moraes Holschuh
commit 208b996b6c460285650d39b2330f8ef82c007d10 upstream. Since the rfkill rework in 2.6.31, the driver is always resuming with the radios disabled. Change thinkpad-acpi to ask the firmware to resume with the radios in the last state. This fixes the Bluetooth and WWAN rfkill switches. Note that it means we respect the firmware's oddities. Should the user toggle the hardware rfkill switch on and off, it might cause the radios to resume enabled. UWB is an unknown quantity since it has nowhere the same level of firmware support (no control over state storage in NVRAM, for example), and might need further fixing. Testers welcome. This change fixes a regression from 2.6.30. Reported-by: Jerone Young <jerone.young@canonical.com> Reported-by: Ian Molton <ian.molton@collabora.co.uk> Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Tested-by: Ian Molton <ian.molton@collabora.co.uk> Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-18thinkpad-acpi: fix default brightness_mode for R50e/R51Henrique de Moraes Holschuh
commit a9f8eacca4e9e8693de9b896c1fa7aadaa9402e8 upstream. According to a report, the R50e wants EC-based brightness control, even if it uses an Intel GPU. The current driver default was reported to not work at all. This bug can be worked around by the "brightness_mode=3" module parameter. Change the default of the R50e and R51 2xxx models (which use the same EC firmware, 1V) to TPACPI_BRGHT_Q_EC, but keep TPACPI_BRGHT_Q_ASK set for now, as I'd like to get more reports. This fixes a regression caused by commit 59fe4fe34d7afdf63208124f313be9056feaa2f4, "thinkpad-acpi: fix incorrect use of TPACPI_BRGHT_MODE_ECNVRAM" Kernel 2.6.31 also needs this fix. Reported-by: Ferenc Wagner <wferi@niif.hu> Tested-by: Ferenc Wagner <wferi@niif.hu> Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: stable@kernel.org Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-18drm/i915: Fix sync to vblank when VGA output is turned offLi Peng
commit 778c902640530371a169ad1c03566e7c51b09874 upstream In current vblank-wait implementation, if we turn off VGA output, drm_wait_vblank will still wait on the disabled pipe until timeout, because vblank on the pipe is assumed be enabled. This would cause slow system response on some system such as moblin. This patch resolve the issue by adding a drm helper function drm_vblank_off which explicitly clear vblank_enabled[crtc], wake up any waiting queue and save last vblank counter before turning off crtc. It also slightly change drm_vblank_get to ensure that we will will return immediately if trying to wait on a disabled pipe. Signed-off-by: Li Peng <peng.li@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> [anholt: hand-applied for conflicts with overlay changes] Signed-off-by: Eric Anholt <eric@anholt.net> Cc: Stefan Bader <stefan.bader@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-18ath9k: fix tx status reportingFelix Fietkau
This is a backport of upstream commit: e8c6342d989e241513baeba4b05a04b6b1f3bc8b This patch fixes a bug in ath9k's tx status check, which caused mac80211 to consider regularly transmitted unicast frames as un-acked. When checking the ts_status field for errors, it needs to be masked with ATH9K_TXERR_FILT, because this field also contains other fields like ATH9K_TX_ACKED. Without this patch, AP mode is pretty much unusable, as hostapd checks the ACK status for the frames that it injects. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-18ath9k: Fix maximum tx fifo settings for single stream devicesLuis R. Rodriguez
This is a backport of upstream commit: f4709fdf683e1ed37b321c258b614ebe39752bf3 Atheros single stream AR9285 and AR9271 have half the PCU TX FIFO buffer size of that of dual stream devices. Dual stream devices have a max PCU TX FIFO size of 8 KB while single stream devices have 4 KB. Single stream devices have an issue though and require hardware only to use half of the amount of its capable PCU TX FIFO size, 2 KB and this requires a change in software. Technically a change would not have been required (except for frame burst considerations of 128 bytes) if these devices would have been able to use the full 4 KB of the PCU TX FIFO size but our systems engineers recommend 2 KB to be used only. We enforce this through software by reducing the max frame triggger level to 2 KB. Fixing the max frame trigger level should then have a few benefits: * The PER will now be adjusted as designed for underruns when the max trigger level is reached. This should help alleviate the bus as the rate control algorithm chooses a slower rate which should ensure frames are transmitted properly under high system bus load. * The poll we use on our TX queues should now trigger and work as designed for single stream devices. The hardware passes data from each TX queue on the PCU TX FIFO queue respecting each queue's priority. The new trigger level ensures this seeding of the PCU TX FIFO queue occurs as designed which could mean avoiding false resets and actually reseting hw correctly when a TX queue is indeed stuck. * Some undocumented / unsupported behaviour could have been triggered when the max trigger level level was being set to 4 KB on single stream devices. Its not clear what this issue was to me yet. Cc: Kyungwan Nam <kyungwan.nam@atheros.com> Cc: Bennyam Malavazi <bennyam.malavazi@atheros.com> Cc: Stephen Chen <stephen.chen@atheros.com> Cc: Shan Palanisamy <shan.palanisamy@atheros.com> Cc: Paul Shaw <paul.shaw@atheros.com> Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-18ath9k: fix processing of TX PS null data framesLuis R. Rodriguez
This is a backport of upstream commit: e7824a50662f7f79b1a739f705b4d906c31cf221 When mac80211 was telling us to go into Powersave we listened and immediately turned RX off. This meant hardware would not see the ACKs from the AP we're associated with and hardware we'd end up retransmiting the null data frame in a loop helplessly. Fix this by keeping track of the transmitted nullfunc frames and only when we are sure the AP has sent back an ACK do we go ahead and shut RX off. Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: Vivek Natarajan <Vivek.Natarajan@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-18ath9k: Fix TX hang poll routineSujith
This is a backport of upstream commit: 332c556633b8c5fb4e890b1783122f2315526590 When TX is hung, the chip is reset. Ensure that the chip is awake by using the PS wrappers. Signed-off-by: Sujith <Sujith.Manoharan@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-18b43legacy: avoid PPC fault during resumeLarry Finger
commit 316a4d966cae3c2dec83ebb1ee1a3515f97b30ff upstream. For PPC architecture with PHY Revision < 3, a read of the register B43_MMIO_HWENABLED_LO will cause a CPU fault unless b43legacy_status() returns a value of 2 (B43legacy_STAT_STARTED); however, one finds that the driver is unable to associate after resuming from hibernation unless this routine returns 1. To satisfy both conditions, the routine is rewritten to return TRUE whenever b43legacy_status() returns a value < 2. This patch fixes the second problem listed in the postings for Red Hat Bugzilla #538523. 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>
2009-12-18b44 WOL setup: one-bit-off stack corruption kernel panic fixStanislav Brabec
[ Upstream commit: e0188829cb724e7d12a2d4e343b368ff1d6e1471 ] About 50% of shutdowns of b44 Ethernet adapter ends by kernel panic with kernels compiled with stack-protector. Checking b44_magic_pattern() return values, one call of b44_magic_pattern() returns 127. It means, that set_bit(128, pmask) was called on line 1509. It means that bit 0 of 17th byte of pmask was overwritten. But pmask has only 16 bytes. Stack corruption happens. It seems that set_bit() on line 1509 always writes one bit off. The fix does not only solve the stack corruption, but also makes Wake On LAN working on my onboard B44 on Asus A7V-333X mainboard. It seems that this problem affects all kernel versions since commit 725ad800 ([PATCH] b44: add wol for old nic) on 2006-06-20. Signed-off-by: Stanislav Brabec <sbrabec@suse.cz> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-18slc90e66: fix UDMA handlingBartlomiej Zolnierkiewicz
[ Upstream commit ee31527a02b0a8e1aa4a5e4084d2db5fa34737ed ] Fix checking of the currently programmed UDMA mode. Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-18dm crypt: make wipe message also wipe essiv keyMilan Broz
commit 542da317668c35036e8471822a564b609d05af66 upstream. The "wipe key" message is used to wipe the volume key from memory temporarily, for example when suspending to RAM. But the initialisation vector in ESSIV mode is calculated from the hashed volume key, so the wipe message should wipe this IV key too and reinitialise it when the volume key is reinstated. This patch adds an IV wipe method called from a wipe message callback. ESSIV is then reinitialised using the init function added by the last patch. Signed-off-by: Milan Broz <mbroz@redhat.com> Signed-off-by: Alasdair G Kergon <agk@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-18dm crypt: separate essiv allocation from initialisationMilan Broz
commit b95bf2d3d5a48b095bffe2a0cd8c40453cf59557 upstream. This patch separates the construction of IV from its initialisation. (For ESSIV it is a hash calculation based on volume key.) Constructor code now preallocates hash tfm and salt array and saves it in a private IV structure. The next patch requires this to reinitialise the wiped IV without reallocating memory when resuming a suspended device. Signed-off-by: Milan Broz <mbroz@redhat.com> Signed-off-by: Alasdair G Kergon <agk@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-18dm snapshot: cope with chunk size larger than originMikulas Patocka
commit 8e87b9b81b3c370f7e53c1ab6e1c3519ef37a644 upstream. Under some special conditions the snapshot hash_size is calculated as zero. This patch instead sets a minimum value of 64, the same as for the pending exception table. rounddown_pow_of_two(0) is an undefined operation (it expands to shift by -1). init_exception_table with an argument of 0 would fail with -ENOMEM. The way to trigger the problem is to create a snapshot with a chunk size that is larger than the origin device. Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: Alasdair G Kergon <agk@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-18dm: avoid _hash_lock deadlockMikulas Patocka
commit 6076905b5ef39e0ea58db32583c9e0036c05e47b upstream. Fix a reported deadlock if there are still unprocessed multipath events on a device that is being removed. _hash_lock is held during dev_remove while trying to send the outstanding events. Sending the events requests the _hash_lock again in dm_copy_name_and_uuid. This patch introduces a separate lock around regions that modify the link to the hash table (dm_set_mdptr) or the name or uuid so that dm_copy_name_and_uuid no longer needs _hash_lock. Additionally, dm_copy_name_and_uuid can only be called if md exists so we can drop the dm_get() and dm_put() which can lead to a BUG() while md is being freed. The deadlock: #0 [ffff8106298dfb48] schedule at ffffffff80063035 #1 [ffff8106298dfc20] __down_read at ffffffff8006475d #2 [ffff8106298dfc60] dm_copy_name_and_uuid at ffffffff8824f740 #3 [ffff8106298dfc90] dm_send_uevents at ffffffff88252685 #4 [ffff8106298dfcd0] event_callback at ffffffff8824c678 #5 [ffff8106298dfd00] dm_table_event at ffffffff8824dd01 #6 [ffff8106298dfd10] __hash_remove at ffffffff882507ad #7 [ffff8106298dfd30] dev_remove at ffffffff88250865 #8 [ffff8106298dfd60] ctl_ioctl at ffffffff88250d80 #9 [ffff8106298dfee0] do_ioctl at ffffffff800418c4 #10 [ffff8106298dff00] vfs_ioctl at ffffffff8002fab9 #11 [ffff8106298dff40] sys_ioctl at ffffffff8004bdaf #12 [ffff8106298dff80] tracesys at ffffffff8005d28d (via system_call) Reported-by: guy keren <choo@actcom.co.il> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: Alasdair G Kergon <agk@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-18dm crypt: restructure essiv error pathMilan Broz
commit 5861f1be00b3b70f8ab5e5a81392a6cf69666cd2 upstream. Use kzfree for salt deallocation because it is derived from the volume key. Use a common error path in ESSIV constructor. Required by a later patch which fixes the way key material is wiped from memory. Signed-off-by: Milan Broz <mbroz@redhat.com> Signed-off-by: Alasdair G Kergon <agk@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-18dm crypt: move private iv fields to structsMilan Broz
commit 6047359277517c4e56d8bfd6ea4966d7a3924151 upstream. Define private structures for IV so it's easy to add further attributes in a following patch which fixes the way key material is wiped from memory. Also move ESSIV destructor and remove unnecessary 'status' operation. There are no functional changes in this patch. Signed-off-by: Milan Broz <mbroz@redhat.com> Signed-off-by: Alasdair G Kergon <agk@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-18dm snapshot: only take lock for statustype info not tableMikulas Patocka
commit 94e76572b5dd37b1f0f4b3742ee8a565daead932 upstream. Take snapshot lock only for STATUSTYPE_INFO, not STATUSTYPE_TABLE. Commit 4c6fff445d7aa753957856278d4d93bcad6e2c14 (dm-snapshot-lock-snapshot-while-supplying-status.patch) introduced this use of the lock, but userspace applications using libdevmapper have been found to request STATUSTYPE_TABLE while the device is suspended and the lock is already held, leading to deadlock. Since the lock is not necessary in this case, don't try to take it. Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: Alasdair G Kergon <agk@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-18dm exception store: free tmp_store on persistent flag errorJulia Lawall
commit 613978f8711c7fd4d0aa856872375d2abd7c92ff upstream. Error handling code following a kmalloc should free the allocated data. Signed-off-by: Julia Lawall <julia@diku.dk> Signed-off-by: Alasdair G Kergon <agk@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-18xen: try harder to balloon up under memory pressure.Ian Campbell
commit bc2c0303226ec716854d3c208c7f84fe7aa35cd7 upstream. Currently if the balloon driver is unable to increase the guest's reservation it assumes the failure was due to reaching its full allocation, gives up on the ballooning operation and records the limit it reached as the "hard limit". The driver will not try again until the target is set again (even to the same value). However it is possible that ballooning has in fact failed due to memory pressure in the host and therefore it is desirable to keep attempting to reach the target in case memory becomes available. The most likely scenario is that some guests are ballooning down while others are ballooning up and therefore there is temporary memory pressure while things stabilise. You would not expect a well behaved toolstack to ask a domain to balloon to more than its allocation nor would you expect it to deliberately over-commit memory by setting balloon targets which exceed the total host memory. This patch drops the concept of a hard limit and causes the balloon driver to retry increasing the reservation on a timer in the same manner as when decreasing the reservation. Also if we partially succeed in increasing the reservation (i.e. receive less pages than we asked for) then we may as well keep those pages rather than returning them to Xen. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-18Xen balloon: fix totalram_pages counting.Gianluca Guida
commit 3d65c9488cadd2f11bd4d60c7266e639ece5d0d6 upstream. Change totalram_pages when a single page is added/removed to the ballooned list. This avoid totalram_pages to be set erroneously to max_pfn at boot. Signed-off-by: Gianluca Guida <gianluca.guida@citrix.com> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-18xen: explicitly create/destroy stop_machine workqueues outside ↵Ian Campbell
suspend/resume region. commit b4606f2165153833247823e8c04c5e88cb3d298b upstream. I have observed cases where the implicit stop_machine_destroy() done by stop_machine() hangs while destroying the workqueues, specifically in kthread_stop(). This seems to be because timer ticks are not restarted until after stop_machine() returns. Fortunately stop_machine provides a facility to pre-create/post-destroy the workqueues so use this to ensure that workqueues are only destroyed after everything is really up and running again. I only actually observed this failure with 2.6.30. It seems that newer kernels are somehow more robust against doing kthread_stop() without timer interrupts (I tried some backports of some likely looking candidates but did not track down the commit which added this robustness). However this change seems like a reasonable belt&braces thing to do. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-18xen: don't leak IRQs over suspend/resume.Ian Campbell
commit fed5ea87e02aaf902ff38c65b4514233db03dc09 upstream. On resume irq_info[*].evtchn is reset to 0 since event channel mappings are not preserved over suspend/resume. The other contents of irq_info is preserved to allow rebind_evtchn_irq() to function. However when a device resumes it will try to unbind from the previous IRQ (e.g. blkfront goes blkfront_resume() -> blkif_free() -> unbind_from_irqhandler() -> unbind_from_irq()). This will fail due to the check for VALID_EVTCHN in unbind_from_irq() and the IRQ is leaked. The device will then continue to resume and allocate a new IRQ, eventually leading to find_unbound_irq() panic()ing. Fix this by changing unbind_from_irq() to handle teardown of interrupts which have type!=IRQT_UNBOUND but are not currently bound to a specific event channel. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-18xen: improve error handling in do_suspend.Ian Campbell
commit 65f63384b391bf4d384327d8a7c6de9860290b5c upstream. The existing error handling has a few issues: - If freeze_processes() fails it exits with shutting_down = SHUTDOWN_SUSPEND. - If dpm_suspend_noirq() fails it exits without resuming xenbus. - If stop_machine() fails it exits without resuming xenbus or calling dpm_resume_end(). - xs_suspend()/xs_resume() and dpm_suspend_noirq()/dpm_resume_noirq() were not nested in the obvious way. Fix by ensuring each failure case goto's the correct label. Treat a failure of stop_machine() as a cancelled suspend in order to follow the correct resume path. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-18xen: don't call dpm_resume_noirq() with interrupts disabled.Jeremy Fitzhardinge
commit 922cc38ab71d1360978e65207e4a4f4988987127 upstream. dpm_resume_noirq() takes a mutex, so it can't be called from a no-interrupt context. Don't call it from within the stop-machine function, but just afterwards, since we're resuming anyway, regardless of what happened. Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-18xen/xenbus: make DEVICE_ATTR()s staticJeremy Fitzhardinge
commit db05fed0ad72f264e39bcb366795f7367384ec92 upstream. They don't need to be global, and may cause linker clashes. Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-18drm/i915: Add the missing clonemask for display port on IronlakeZhao Yakui
commit 652af9d74e1a3a10bb10f0d8e8f42ddac26bbc1a upstream. Add the missing clonemask for display port on Ironlake. Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-18drm/i915: Set the error code after failing to insert new offset into mm ht.Chris Wilson
commit 5618ca6abc2d6f475b258badc017a5254cf43d1b upstream. 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>
2009-12-18drm/radeon/kms: rs6xx/rs740: clamp vram to aperture sizeAlex Deucher
commit 0088dbdb809e8799cb8f26da5ac64b15201fa99d upstream. 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>
2009-12-18drm/radeon/kms: fix vram setup on rs600Alex Deucher
commit 722f29434e72188b2d20f9b41f4b5952073ed568 upstream. also fix up rs690 mem width. should fix fdo bug 25408 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>
2009-12-18drm/radeon/kms: fix legacy crtc2 dpmsAlex Deucher
commit 8de21525439e6b5bb8d8c81e49094d867bf82f6d upstream. noticed by Matthijs Kooijman on fdo bug 22140 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>
2009-12-18drm/radeon/kms: handle vblanks properly with dpms onAlex Deucher
commit 500b758725314ab1b5316eb0caa5b0fa26740e6b upstream. avivo chips Copied from pre-avivo code. 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>
2009-12-18drm/radeon/kms: Add quirk for HIS X1300 boardAlex Deucher
commit 4e3f9b78ff917cc5c833858fdb5d96bc262e0bf3 upstream. Board is DVI+VGA, not DVI+DVI 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>
2009-12-18powerpc/therm_adt746x: Record pwm invert bit at module load time]Darrick J. Wong
commit 1496e89ae2a0962748e55165a590fa3209c6f158 upstream. In commit 0512a9a8e277a9de2820211eef964473b714ae65, we unilaterally zero the "pwm invert" bit in the fan behavior configuration register. On my PowerBook G4, this results in the fans going to full speed at low temperature and shutting off at high temperature because the pwm invert bit is supposed to be set. Therefore, record the pwm invert bit at driver load time, and write the bit into the fan behavior control register. This restores correct behavior on my PBG4 and should work around the bit being set to the wrong value after suspend/resume (which is what the original patch was trying to fix). It also fixes a minor omission where the pwm invert bit correction is NOT performed when switching into automatic mode. Signed-off-by: Darrick J. Wong <djwong@us.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-18powerpc/windfarm: Add detection for second cpu pumpBolko Maass
commit 529586dc39b0ec47c6290c4e7bed6ea3ffd1d8fb upstream. Windfarm SMU control is explicitly missing support for a second CPU pump in G5 PowerMacs. Such machines actually exist (specifically Quads with a second pump), so this patch adds detection for it. Signed-off by: Bolko Maass <bmaass@math.uni-bremen.de> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-18rtl8187: Fix wrong rfkill switch mask for some modelsLarry Finger
commit 70d57139f932b9ca21026253d02af71cf53d764a upstream. There are different bits used to convey the setting of the rfkill switch to the driver. The current driver only supports one of these possibilities. These changes were derived from the latest version of the vendor driver. This patch fixes the regression noted in kernel Bugzilla #14743. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Reported-and-tested-by: Antti Kaijanmäki <antti@kaijanmaki.net> Tested-by: Hin-Tak Leung <hintak.leung@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-18Serial: Do not read IIR in serial8250_start_tx when UART_BUG_TXENIan Jackson
commit 68cb4f8e246bbbc649980be0628cae9265870a91 upstream. Do not read IIR in serial8250_start_tx when UART_BUG_TXEN Reading the IIR clears some oustanding interrupts so it is not safe. Instead, simply transmit immediately if the buffer is empty without regard to IIR. Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Jiri Kosina <jkosina@suse.cz> Cc: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-18Driver core: fix race in dev_driver_stringAlan Stern
commit 3589972e51fac1e02d0aaa576fa47f568cb94d40 upstream. This patch (as1310) works around a race in dev_driver_string(). If the device is unbound while the function is running, dev->driver might become NULL after we test it and before we dereference it. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: Oliver Neukum <oliver@neukum.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
generated by cgit v1.2.3 (git 2.0.4) at 2024-08-28 14:12:32 +0000