13 Aug, 2010
14 commits
-
* git://git.infradead.org/battery-2.6:
intel_mid_battery: Fix battery scaling
intel_mid_battery: Fix the argument order to intel_scu_ipc_command
olpc_battery: Fix build failure caused by sysfs changes
Add s3c-adc-battery driver
Intel MID platform battery driverFix up trivial conflicts (battery drivers added from different branches)
in drivers/power/{Kconfig,Makefile} -
The current computation, introduced with f12a15be63, of FSEC_PER_SEC using
the multiplication of (FSEC_PER_NSEC * NSEC_PER_SEC) is performed only
with 32bit integers on small machines, resulting in an overflow and a
*very* short intervals being programmed. An interrupt storm follows.Note that we also have to specify FSEC_PER_SEC as being long long to
overcome the same limitations.Signed-off-by: Chris Wilson
Signed-off-by: John Stultz
Cc: Thomas Gleixner
Acked-by: Ingo Molnar
Acked-by: H. Peter Anvin
Signed-off-by: Linus Torvalds -
The tv_nsec is a long and when added to the shifted interval it can wrap
and become negative which later causes looping problems in the
getrawmonotonic(). The edge case occurs when the system has slept for
a short period of time of ~2 seconds.A trace printk of the values in this patch illustrate the problem:
ftrace time stamp: log
43.716079: logarithmic_accumulation: raw: 3d0913 tv_nsec d687faa
43.718513: logarithmic_accumulation: raw: 3d0913 tv_nsec da588bd
43.722161: logarithmic_accumulation: raw: 3d0913 tv_nsec de291d0
46.349925: logarithmic_accumulation: raw: 7a122600 tv_nsec e1f9ae3
46.349930: logarithmic_accumulation: raw: 1e848980 tv_nsec 8831c0e3The kernel starts looping at 46.349925 in the getrawmonotonic() due to
the negative value from adding the raw value to tv_nsec.A simple solution is to accumulate into a u64, and then normalize it
to a timespec_t.Signed-off-by: Jason Wessel
[ Reworked variable names and simplified some of the code. - John ]
Signed-off-by: John Stultz
Cc: Thomas Gleixner
Cc: H. Peter Anvin
Signed-off-by: Linus Torvalds -
Use no_printk() for disabled gdbstub debugging functions to maintain side
effect checking.Signed-off-by: David Howells
Signed-off-by: Linus Torvalds -
Add a dummy printk function for the maintenance of unused printks through gcc
format checking, and also so that side-effect checking is maintained too.Signed-off-by: David Howells
Signed-off-by: Linus Torvalds -
Don't try and #include 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 hereSigned-off-by: David Howells
Signed-off-by: Linus Torvalds -
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 contains
section definitions for use in .S files.Signed-off-by: David Howells
Signed-off-by: Linus Torvalds -
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
Signed-off-by: Linus Torvalds -
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: David Howells
Signed-off-by: Linus Torvalds -
* '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. -
* '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
-
Some nice improvements were made to rwsem in commit:
424acaaeb3a3932d64a9b4bd59df6cf72c22d8f3
rwsem: wake queued readers when writer blocks on active read lockbut 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
-
* '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 -
* '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 mappingsFix 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
12 Aug, 2010
26 commits
-
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
Cc: Alex Dubov
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Otherwise lockdep complains.
Signed-off-by: Maxim Levitsky
Cc: Alex Dubov
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
- 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
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
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 determinedThe 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 sizeSigned-off-by: Adrian Hunter
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Secure discard is implemented by Secure Trim if the discard is unaligned
or Secure Erase otherwise.Signed-off-by: Adrian Hunter
Acked-by: Jens Axboe
Cc: Kyungmin Park
Cc: Madhusudhan Chikkature
Cc: Christoph Hellwig
Cc: Ben Gardiner
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
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
Acked-by: Jens Axboe
Cc: Kyungmin Park
Cc: Madhusudhan Chikkature
Cc: Christoph Hellwig
Cc: Ben Gardiner
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Disable the data (busy) timeout for erases and set the MMC_CAP_ERASE
capability.Signed-off-by: Adrian Hunter
Acked-by: Jens Axboe
Cc: Kyungmin Park
Cc: Madhusudhan Chikkature
Cc: Christoph Hellwig
Cc: Ben Gardiner
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
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
Acked-by: Jens Axboe
Cc: Kyungmin Park
Cc: Madhusudhan Chikkature
Cc: Christoph Hellwig
Cc: Ben Gardiner
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
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: Adrian Hunter
Acked-by: Jens Axboe
Cc: Kyungmin Park
Cc: Madhusudhan Chikkature
Cc: Christoph Hellwig
Cc: Ben Gardiner
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Commit 83ba7b071f3 ("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
Cc: Christoph Hellwig
Cc: Wu Fengguang
Acked-by: Jens Axboe
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
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/93jfs:
commit 29a424f28390752a4ca2349633aaacc6be494db5
JFS: clear PAGECACHE_TAG_DIRTY for no-write pagesext2:
http://www.spinics.net/linux/lists/linux-ext4/msg04762.htmlThey 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
Cc: Dave Chinner
Cc: Martin Bligh
Cc: Michael Rubin
Cc: Peter Zijlstra
Cc: Christoph Hellwig
Cc: Jens Axboe
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
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
Cc: Dave Chinner
Cc: Martin Bligh
Cc: Michael Rubin
Cc: Peter Zijlstra
Cc: Christoph Hellwig
Cc: Jens Axboe
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
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
Acked-by: Jan Kara
Cc: Dave Chinner
Cc: Christoph Hellwig
Cc: Dave Chinner
Cc: Jens Axboe
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Document global_dirty_limits() and bdi_dirty_limit().
Signed-off-by: Wu Fengguang
Cc: Christoph Hellwig
Cc: Dave Chinner
Cc: Jens Axboe
Cc: Peter Zijlstra
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
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
Cc: Peter Zijlstra
Cc: Christoph Hellwig
Cc: Dave Chinner
Cc: Jens Axboe
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
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 deviationaverage (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
Signed-off-by: Wu Fengguang
Cc: Jan Kara
Acked-by: Peter Zijlstra
Cc: Christoph Hellwig
Cc: Dave Chinner
Cc: Jens Axboe
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
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
Cc: Kyle McMartin
Acked-by: Helge Deller
Tested-by: Helge Deller
Cc: "James E.J. Bottomley"
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Don't dereference vma if it's NULL.
Signed-off-by: Roel Kluin
Cc: Chen Liqin
Cc: Lennox Wu
Cc: Arnd Bergmann
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
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
Cc: Jordan Crouse
Cc: Jim Cromie
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
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: Randy Dunlap
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
The ACPI_PREEMPTION_POINT() logic was introduced in commit 8bd108d
(ACPICA: add preemption point after each opcode parse). The follow up
commits abe1dfab6, 138d15692, 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
Cc: Len Brown
Cc: Francois Valenduc
Cc: Lin Ming
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
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
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
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
-
We don't actually need this include on any platform.
built on powerpc + x86, reported on m68k.
Reported-by: Geert Uytterhoeven
Signed-off-by: Dave Airlie -
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
Signed-off-by: Dave Airlie -
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: Dave Airlie
