- 12 Aug, 2010 33 commits
-
-
David Howells authored
Don't try and #include <linux/slab.h> in lib/inflate.c from the bootloader code as linux/slab.h hauls in function defs that aren't available in the bootloader code and may also haul in conflicting functions. To fix this, make the inclusion of linux/slab.h contingent on NO_INFLATE_MALLOC as are the usages of kmalloc() and kfree(). In MN10300, this causes the following errors: In file included from include/linux/string.h:21, from include/linux/bitmap.h:8, from include/linux/nodemask.h:93, from include/linux/mmzone.h:16, from include/linux/gfp.h:4, from include/linux/slab.h:12, from arch/mn10300/boot/compressed/../../../../lib/inflate.c:106, from arch/mn10300/boot/compressed/misc.c:170: /warthog/am33/linux-2.6-mn10300/arch/mn10300/include/asm/string.h:19: error: conflicting types for 'memset' arch/mn10300/boot/compressed/misc.c:59: error: previous definition of 'memset' was here Signed-off-by:David Howells <dhowells@redhat.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
David Howells authored
Permit .GCC-command-line sections in modules. Otherwise modpost says things like: WARNING: drivers/mtd/chips/map_ram.o (.GCC-command-line): unexpected non-allocatable section. Did you forget to use "ax"/"aw" in a .S file? Note that for example <linux/init.h> contains section definitions for use in .S files. Signed-off-by:
-
David Howells authored
With the newer compilers, size_t and ssize_t are expected to be (un)signed int rather than (un)signed long. Signed-off-by:
-
David Howells authored
A change to the RTC routines in the MN10300 arch used set_rtc_mms() when it meant set_rtc_mmss(). This results in an error due to a reference of an undefined symbol. Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6Linus Torvalds authored
* 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6: [IA64] Fix rwsem: RWSEM_WAITING_BIAS must not be unsigned.
-
git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6Linus Torvalds authored
* 'drm-core-next' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6: (55 commits) io-mapping: move asm include inside the config option vgaarb: drop vga.h include drm/radeon: Add probing of clocks from device-tree drm/radeon: drop old and broken mesa warning drm/radeon: Fix pci_map_page() error checking drm: Remove count_lock for calling lastclose() after 58474713 (v2) drm/radeon/kms: allow FG_ALPHA_VALUE on r5xx drm/radeon/kms: another r6xx/r7xx CS checker fix DRM: Replace kmalloc/memset combos with kzalloc drm: expand gamma_set drm/edid: Split mode lists out to their own header for readability drm/edid: Rewrite mode parse to use the generic detailed block walk drm/edid: Add detailed block walk for VTB extensions drm/edid: Add detailed block walk for CEA extensions drm: Remove unused fields from drm_display_info drm: Use ENOENT consistently for the error return for an unmatched handle. drm/radeon/kms: mark 3D power states as performance drm: Only set DPMS once on the CRTC not after every encoder. drm/radeon/kms: add additional quirk for Acer rv620 laptop drm: Propagate error code from fb_create() ... Fix up trivial conflicts in drivers/gpu/drm/drm_edid.c
-
Tony Luck authored
Some nice improvements were made to rwsem in commit: 424acaae rwsem: wake queued readers when writer blocks on active read lock but this change overlooked that ia64 had defined RWSEM_WAITING_BIAS as an unsigned value, while the new code required a signed value (as it is in every other architecture). This fix suggested by the original patch author: Michel Lespinasse. Signed-off-by:
Tony Luck <tony.luck@intel.com>
-
git://git.secretlab.ca/git/linux-2.6Linus Torvalds authored
* 'next-devicetree' of git://git.secretlab.ca/git/linux-2.6: mmc_spi: Fix unterminated of_match_table of/sparc: fix build regression from of_device changes of/device: Replace struct of_device with struct platform_device
-
git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xenLinus Torvalds authored
* 'stable/xen-swiotlb-0.8.6' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen: x86: Detect whether we should use Xen SWIOTLB. pci-swiotlb-xen: Add glue code to setup dma_ops utilizing xen_swiotlb_* functions. swiotlb-xen: SWIOTLB library for Xen PV guest with PCI passthrough. xen/mmu: inhibit vmap aliases rather than trying to clear them out vmap: add flag to allow lazy unmap to be disabled at runtime xen: Add xen_create_contiguous_region xen: Rename the balloon lock xen: Allow unprivileged Xen domains to create iomap pages xen: use _PAGE_IOMAP in ioremap to do machine mappings Fix up trivial conflicts (adding both xen swiotlb and xen pci platform driver setup close to each other) in drivers/xen/{Kconfig,Makefile} and include/xen/xen-ops.h
-
Maxim Levitsky authored
mspro_block_remove() is called from detect thread that first calls the mspro_block_stop(), which stops the request queue. If we call del_gendisk() with the queue stopped we get a deadlock. Signed-off-by:
Maxim Levitsky <maximlevitsky@gmail.com> Cc: Alex Dubov <oakad@yahoo.com> Cc: <stable@kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Maxim Levitsky authored
Otherwise lockdep complains. Signed-off-by:
-
Adrian Hunter authored
- Fix mmc_test_alloc_mem. - Use nr_free_buffer_pages() instead of sysinfo.totalram to determine total lowmem pages. - Change variables containing memory sizes to unsigned long. - Limit maximum test area size to 128MiB because that is the maximum MMC high capacity erase size (the maxmium SD allocation unit size is just 4MiB) Signed-off-by:
Adrian Hunter <adrian.hunter@nokia.com> Signed-off-by:
-
Adrian Hunter authored
mmc_test provides tests aimed at testing SD/MMC hosts. This patch adds performance tests. It is advantageous to have performance tests in a kernel module like mmc_test for the following reasons: - transfer times can be measured very accurately - arbitrarily large transfers are possible - the effect of contiguous vs scattered pages can be determined The new tests are: 23. Best-case read performance 24. Best-case write performance 25. Best-case read performance into scattered pages 26. Best-case write performance from scattered pages 27. Single read performance by transfer size 28. Single write performance by transfer size 29. Single trim performance by transfer size 30. Consecutive read performance by transfer size 31. Consecutive write performance by transfer size 32. Consecutive trim performance by transfer size Signed-off-by:
-
Adrian Hunter authored
Secure discard is implemented by Secure Trim if the discard is unaligned or Secure Erase otherwise. Signed-off-by:
Jens Axboe <axboe@kernel.dk> Cc: Kyungmin Park <kmpark@infradead.org> Cc: Madhusudhan Chikkature <madhu.cr@ti.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Ben Gardiner <bengardiner@nanometrics.ca> Cc: <linux-mmc@vger.kernel.org> Signed-off-by:
-
Adrian Hunter authored
Secure discard is the same as discard except that all copies of the discarded sectors (perhaps created by garbage collection) must also be erased. Signed-off-by:
-
Adrian Hunter authored
Disable the data (busy) timeout for erases and set the MMC_CAP_ERASE capability. Signed-off-by:
-
Adrian Hunter authored
Enable MMC to service discard requests. In the case of SD and MMC cards that do not support trim, discards become erases. In the case of cards (MMC) that only allow erases in multiples of erase group size, round to the nearest completely discarded erase group. Signed-off-by:
-
Adrian Hunter authored
SD/MMC cards tend to support an erase operation. In addition, eMMC v4.4 cards can support secure erase, trim and secure trim operations that are all variants of the basic erase command. SD/MMC device attributes "erase_size" and "preferred_erase_size" have been added. "erase_size" is the minimum size, in bytes, of an erase operation. For MMC, "erase_size" is the erase group size reported by the card. Note that "erase_size" does not apply to trim or secure trim operations where the minimum size is always one 512 byte sector. For SD, "erase_size" is 512 if the card is block-addressed, 0 otherwise. SD/MMC cards can erase an arbitrarily large area up to and including the whole card. When erasing a large area it may be desirable to do it in smaller chunks for three reasons: 1. A single erase command will make all other I/O on the card wait. This is not a problem if the whole card is being erased, but erasing one partition will make I/O for another partition on the same card wait for the duration of the erase - which could be a several minutes. 2. To be able to inform the user of erase progress. 3. The erase timeout becomes too large to be very useful. Because the erase timeout contains a margin which is multiplied by the size of the erase area, the value can end up being several minutes for large areas. "erase_size" is not the most efficient unit to erase (especially for SD where it is just one sector), hence "preferred_erase_size" provides a good chunk size for erasing large areas. For MMC, "preferred_erase_size" is the high-capacity erase size if a card specifies one, otherwise it is based on the capacity of the card. For SD, "preferred_erase_size" is the allocation unit size specified by the card. "preferred_erase_size" is in bytes. Signed-off-by: -
Jan Kara authored
Commit 83ba7b07 ("writeback: simplify the write back thread queue") broke writeback_in_progress() as in that commit we started to remove work items from the list at the moment we start working on them and not at the moment they are finished. Thus if the flusher thread was doing some work but there was no other work queued, writeback_in_progress() returned false. This could in particular cause unnecessary queueing of background writeback from balance_dirty_pages() or writeout work from writeback_sb_if_idle(). This patch fixes the problem by introducing a bit in the bdi state which indicates that the flusher thread is processing some work and uses this bit for writeback_in_progress() test. NOTE: Both callsites of writeback_in_progress() (namely, writeback_inodes_sb_if_idle() and balance_dirty_pages()) would actually need a different information than what writeback_in_progress() provides. They would need to know whether *the kind of writeback they are going to submit* is already queued. But this information isn't that simple to provide so let's fix writeback_in_progress() for the time being. Signed-off-by:
Jan Kara <jack@suse.cz> Cc: Christoph Hellwig <hch@lst.de> Cc: Wu Fengguang <fengguang.wu@intel.com> Acked-by:
Jens Axboe <jaxboe@fusionio.com> Signed-off-by:
-
Wu Fengguang authored
Unify the logic for kupdate and non-kupdate cases. There won't be starvation because the inodes requeued into b_more_io will later be spliced _after_ the remaining inodes in b_io, hence won't stand in the way of other inodes in the next run. It avoids unnecessary redirty_tail() calls, hence the update of i_dirtied_when. The timestamp update is undesirable because it could later delay the inode's periodic writeback, or may exclude the inode from the data integrity sync operation (which checks timestamp to avoid extra work and livelock). === How the redirty_tail() comes about: It was a long story.. This redirty_tail() was introduced with wbc.more_io. The initial patch for more_io actually does not have the redirty_tail(), and when it's merged, several 100% iowait bug reports arised: reiserfs: http://lkml.org/lkml/2007/10/23/93 jfs: commit 29a424f2 JFS: clear PAGECACHE_TAG_DIRTY for no-write pages ext2: http://www.spinics.net/linux/lists/linux-ext4/msg04762.html They are all old bugs hidden in various filesystems that become "visible" with the more_io patch. At the time, the ext2 bug is thought to be "trivial", so not fixed. Instead the following updated more_io patch with redirty_tail() is merged: http://www.spinics.net/linux/lists/linux-ext4/msg04507.html This will in general prevent 100% on ext2 and possibly other unknown FS bugs. Signed-off-by:Wu Fengguang <fengguang.wu@intel.com> Cc: Dave Chinner <david@fromorbit.com> Cc: Martin Bligh <mbligh@google.com> Cc: Michael Rubin <mrubin@google.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Christoph Hellwig <hch@infradead.org> Cc: Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Wu Fengguang authored
This was not a bug, since b_io is empty for kupdate writeback. The next patch will do requeue_io() for non-kupdate writeback, so let's fix it. Signed-off-by:
-
Wu Fengguang authored
Avoid delaying writeback for an expire inode with lots of dirty pages, but no active dirtier at the moment. Previously we only do that for the kupdate case. Any filesystem that does delayed allocation or unwritten extent conversion after IO completion will cause this - for example, XFS. Signed-off-by:
-
Wu Fengguang authored
Document global_dirty_limits() and bdi_dirty_limit(). Signed-off-by:
-
Wu Fengguang authored
Split get_dirty_limits() into global_dirty_limits()+bdi_dirty_limit(), so that the latter can be avoided when under global dirty background threshold (which is the normal state for most systems). Signed-off-by:
-
Wu Fengguang authored
Reducing the number of times balance_dirty_pages calls global_page_state reduces the cache references and so improves write performance on a variety of workloads. 'perf stats' of simple fio write tests shows the reduction in cache access. Where the test is fio 'write,mmap,600Mb,pre_read' on AMD AthlonX2 with 3Gb memory (dirty_threshold approx 600 Mb) running each test 10 times, dropping the fasted & slowest values then taking the average & standard deviation average (s.d.) in millions (10^6) 2.6.31-rc8 648.6 (14.6) +patch 620.1 (16.5) Achieving this reduction is by dropping clip_bdi_dirty_limit as it rereads the counters to apply the dirty_threshold and moving this check up into balance_dirty_pages where it has already read the counters. Also by rearrange the for loop to only contain one copy of the limit tests allows the pdflush test after the loop to use the local copies of the counters rather than rereading them. In the common case with no throttling it now calls global_page_state 5 fewer times and bdi_stat 2 fewer. Fengguang: This patch slightly changes behavior by replacing clip_bdi_dirty_limit() with the explicit check (nr_reclaimable + nr_writeback >= dirty_thresh) to avoid exceeding the dirty limit. Since the bdi dirty limit is mostly accurate we don't need to do routinely clip. A simple dirty limit check would be enough. The check is necessary because, in principle we should throttle everything calling balance_dirty_pages() when we're over the total limit, as said by Peter. We now set and clear dirty_exceeded not only based on bdi dirty limits, but also on the global dirty limit. The global limit check is added in place of clip_bdi_dirty_limit() for safety and not intended as a behavior change. The bdi limits should be tight enough to keep all dirty pages under the global limit at most time; occasional small exceeding should be OK though. The change makes the logic more obvious: the global limit is the ultimate goal and shall be always imposed. We may now start background writeback work based on outdated conditions. That's safe because the bdi flush thread will (and have to) double check the states. It reduces overall overheads because the test based on old states still have good chance to be right. [akpm@linux-foundation.org] fix uninitialized dirty_exceeded Signed-off-by:
Richard Kennedy <richard@rsk.demon.co.uk> Signed-off-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Christoph Hellwig <hch@infradead.org> Cc: Dave Chinner <david@fromorbit.com> Cc: Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Florian Zumbiehl authored
parisc __ioremap(): fix off-by-one error in page alignment of allocation size for sizes where size%PAGE_SIZE==1. Signed-off-by:
Florian Zumbiehl <florz@florz.de> Cc: Kyle McMartin <kyle@mcmartin.ca> Acked-by:
Helge Deller <deller@gmx.de> Tested-by:
-
Roel Kluin authored
Don't dereference vma if it's NULL. Signed-off-by:
Roel Kluin <roel.kluin@gmail.com> Cc: Chen Liqin <liqin.chen@sunplusct.com> Cc: Lennox Wu <lennox.wu@gmail.com> Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Randy Dunlap authored
Fix kconfig dependency warning for PC8736x_GPIO by restricting it to X86_32. warning: (SCx200_GPIO && SCx200 || PC8736x_GPIO && X86) selects NSC_GPIO which has unmet direct dependencies (X86_32) NSC_GPIO is X86_32 only. The other driver (SCx200_GPIO) that selects NSC_GPIO is X86_32 only (indirectly, since SCx200 depends on X86_32), so limit this driver also. Signed-off-by:
Randy Dunlap <randy.dunlap@oracle.com> Cc: Jordan Crouse <jordan.crouse@amd.com> Cc: Jim Cromie <jim.cromie@gmail.com> Signed-off-by:
-
Randy Dunlap authored
Fix a fatal kernel-doc error due to a #define coming between a function's kernel-doc notation and the function signature. (kernel-doc cannot handle this) Signed-off-by:
-
Thomas Gleixner authored
The ACPI_PREEMPTION_POINT() logic was introduced in commit 8bd108d1 (ACPICA: add preemption point after each opcode parse). The follow up commits abe1dfab, 138d1569, c084ca70 tried to fix the preemption logic back and forth, but nobody noticed that the usage of in_atomic_preempt_off() in that context is wrong. The check which guards the call of cond_resched() is: if (!in_atomic_preempt_off() && !irqs_disabled()) in_atomic_preempt_off() is not intended for general use as the comment above the macro definition clearly says: * Check whether we were atomic before we did preempt_disable(): * (used by the scheduler, *after* releasing the kernel lock) On a CONFIG_PREEMPT=n kernel the usage of in_atomic_preempt_off() works by accident, but with CONFIG_PREEMPT=y it's just broken. The whole purpose of the ACPI_PREEMPTION_POINT() is to reduce the latency on a CONFIG_PREEMPT=n kernel, so make ACPI_PREEMPTION_POINT() depend on CONFIG_PREEMPT=n and remove the in_atomic_preempt_off() check. Addresses https://bugzilla.kernel.org/show_bug.cgi?id=16210 [akpm@linux-foundation.org: fix build] Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Cc: Len Brown <lenb@kernel.org> Cc: Francois Valenduc <francois.valenduc@tvcablenet.be> Cc: Lin Ming <ming.m.lin@intel.com> Cc: <stable@kernel.org> Signed-off-by:
-
Stefani Seibold authored
The current kfifo scatterlist implementation will not work with chained scatterlists. It assumes that struct scatterlist arrays are allocated contiguously, which is not the case when chained scatterlists (struct sg_table) are in use. Signed-off-by:
Stefani Seibold <stefani@seibold.net> Signed-off-by:
-
Dave Airlie authored
nouveau starting using these APIs, the first on non-x86 hw, and this include isn't required on anything with real amounts of vmalloc space. this fixes a build problem on powerpc. Signed-off-by:Dave Airlie <airlied@redhat.com>
-
Dave Airlie authored
We don't actually need this include on any platform. built on powerpc + x86, reported on m68k. Reported-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
-
- 11 Aug, 2010 7 commits
-
-
Benjamin Herrenschmidt authored
When we find no ROM we understand and a device-tree is present, see if we can retreive clock info from there. Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Dave Airlie authored
This never really got fixed in mesa, and the kernel deals with the problem just fine, so don't got reporting things that confuse people. Signed-off-by: -
Benjamin Herrenschmidt authored
0 is a valid DMA address from pci_map_page(), use pci_dma_mapping_error() instead to check for errors [airlied: fix warning + two other places with errors.] Signed-off-by:
-
Chris Wilson authored
When removing of the BKL the locking around lastclose() was rearranged and resulted in the holding of the open_count spinlock over the call into drm_lastclose(). The drivers were not ready for this path to be atomic - it may indeed involve long waits to release old objects and cleanup the GPU - and so we ended up scheduling whilst atomic. [ 54.625598] BUG: scheduling while atomic: X/3546/0x00000002 [ 54.625600] Modules linked in: sco bridge stp llc input_polldev rfcomm bnep l2cap crc16 sch_sfq ipv6 md_mod acpi_cpufreq mperf cryptd aes_x86_64 aes_generic xts gf128mul dm_crypt dm_mod btusb bluetooth usbhid hid zaurus cdc_ether usbnet mii cdc_wdm cdc_acm uvcvideo videodev v4l1_compat v4l2_compat_ioctl32 snd_hda_codec_conexant arc4 pcmcia ecb snd_hda_intel joydev sdhci_pci sdhci snd_hda_codec tpm_tis firewire_ohci mmc_core e1000e uhci_hcd thinkpad_acpi nvram yenta_socket pcmcia_rsrc pcmcia_core tpm wmi sr_mod firewire_core iwlagn ehci_hcd snd_hwdep snd_pcm usbcore tpm_bios thermal led_class snd_timer iwlcore snd soundcore ac snd_page_alloc pcspkr psmouse serio_raw battery sg mac80211 evdev cfg80211 i2c_i801 iTCO_wdt iTCO_vendor_support cdrom processor crc_itu_t rfkill xfs exportfs sd_mod crc_t10dif ahci libahci libata scsi_mod [last unloaded: scsi_wait_scan] [ 54.625663] Pid: 3546, comm: X Not tainted 2.6.35-04771-g17879857 #301 [ 54.625665] Call Trace: [ 54.625671] [<ffffffff8102d599>] __schedule_bug+0x57/0x5c [ 54.625675] [<ffffffff81384141>] schedule+0xe5/0x832 [ 54.625679] [<ffffffff81163e77>] ? put_dec+0x20/0x3c [ 54.625682] [<ffffffff81384dd4>] schedule_timeout+0x275/0x29f [ 54.625686] [<ffffffff810455e1>] ? process_timeout+0x0/0xb [ 54.625688] [<ffffffff81384e17>] schedule_timeout_uninterruptible+0x19/0x1b [ 54.625691] [<ffffffff81045893>] msleep+0x16/0x1d [ 54.625695] [<ffffffff812a2e53>] i9xx_crtc_dpms+0x273/0x2ae [ 54.625698] [<ffffffff812a18be>] intel_crtc_dpms+0x28/0xe7 [ 54.625702] [<ffffffff811ec0fa>] drm_helper_disable_unused_functions+0xf0/0x118 [ 54.625705] [<ffffffff811ecde3>] drm_crtc_helper_set_config+0x644/0x7c8 [ 54.625708] [<ffffffff811f12dd>] ? drm_copy_field+0x40/0x50 [ 54.625711] [<ffffffff811ebca2>] drm_fb_helper_force_kernel_mode+0x3e/0x85 [ 54.625713] [<ffffffff811ebcf2>] drm_fb_helper_restore+0x9/0x24 [ 54.625717] [<ffffffff81290a41>] i915_driver_lastclose+0x2b/0x5c [ 54.625720] [<ffffffff811f14a7>] drm_lastclose+0x44/0x2ad [ 54.625722] [<ffffffff811f1ed2>] drm_release+0x5c6/0x609 [ 54.625726] [<ffffffff810d1275>] fput+0x109/0x1c7 [ 54.625728] [<ffffffff810ce5e4>] filp_close+0x61/0x6b [ 54.625731] [<ffffffff810ce680>] sys_close+0x92/0xd4 [ 54.625734] [<ffffffff81002a2b>] system_call_fastpath+0x16/0x1b v2: The spinlock is actually superfluous as access to open_count is entirely serialised by drm_global_mutex and so can be dropped. The count_lock spinlock instead appears to be used to protect access to dev->buf_alloc and dev->buf_use. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Marek Olšák authored
This is a CS checker fix. I need this for FP16 alpha-test. Signed-off-by:
Marek Olšák <maraeo@gmail.com> Signed-off-by:
-
Alex Deucher authored
add default case for buffer formats Signed-off-by:
Alex Deucher <alexdeucher@gmail.com> Cc: Andre Maasikas <amaasikas@gmail.com> Signed-off-by:
-
Davidlohr Bueso authored
Currently most, if not all, memory allocation in drm_bufs.c is followed by initializing the memory with 0. Replace the use of kmalloc+memset with kzalloc. Signed-off-by:
Davidlohr Bueso <dave@gnu.org> Signed-off-by:
-
