- 08 Mar, 2005 40 commits
-
-
Paul Mundt authored
Somewhere along the line dcache disabling decided it wanted to stop itself from compiling. So we fix it. Signed-off-by:
Paul Mundt <lethal@linux-sh.org> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Paul Mundt authored
There were a couple of cli()/sti() users left, so we get rid of them.. Hopefully this is the last of this mess. Signed-off-by:
James Nelson <james4765@cwazy.co.uk> Signed-off-by:
-
Paul Mundt authored
TMU0 initialization was broken when the timer was already started by someone else (for instance, a boot loader). This fixes it. Signed-off-by:
Andy Sturges <andy.sturges@st.com> Signed-off-by:
Richard Curnow <rc@rc0.org.uk> Signed-off-by:
-
Paul Mundt authored
This fixes up a few minor IDE issues on sh64. We also enable cayman on-board IDE in the SuperIO. Signed-off-by:
-
Paul Mundt authored
Convert sh64 to use generic hardirqs. Signed-off-by:
-
Paul Mundt authored
This adds support for modules. Signed-off-by:
-
Paul Mundt authored
This adds support for the iomap interface to sh64. As a result of this, we can also clean up a lot of the sh64 common I/O routines. We also add a board-specific ioport_map() for the cayman so we can use iomap generically. Signed-off-by:
-
Paul Mundt authored
Update for the cayman defconfig. We also drop the generic arch/sh64/defconfig as it has very little hope of being kept up to date, so we use the cayman one instead. Signed-off-by:
-
Paul Mundt authored
The BYTES_PER_WORD assumption doesn't work out on sh64 when we are using a 32-bit ABI. We want slab caches to be forced to a minimum alignment of 8-bytes, as it was before Anton's change. This was also already discussed at length with Manfred in this thread: http://marc.theaimsgroup.com/?l=linux-kernel&m=110227138116749&w=2Signed-off-by:
-
Paul Mundt authored
Fairly self explanatory.. Signed-off-by:
-
Paul Mundt authored
This provides a port of checkstack for sh64 for the simple frames allocated as an immediate with a single instruction. Stack frame creation on sh64 happens in a couple of different ways, when the frame size is less than 511 bytes an addi or addi.l is typically used, generally along the lines of something like: addi{,.l} r15, -IMM_FRAME_SIZE, r15 For larger frames, this ends up getting split up into a movi/sub pair: movi IMM_FRAME_SIZE, rX sub r15, rX, r15 We currently don't handle the split pair case, as basically any register can be used, and there is no easy way to determine what happens without scanning the prologue multiple times and using some sort of register cache (we already do something similar for the sh64 stack unwinder, but it would be preferable not to do this in perl..). This does have limited usefulness in that we are not easily able to check for huge frames without manual inspection, but this is still useful enough in the general case to be worth doing for the addi/addi.l case as long as people are aware of this caveat. It may be worth revisiting at a later point to try and catch the larger users though. Signed-off-by: -
Yoichi Yuasa authored
This patch adds spare timer initialization for NEC VR41xx. Signed-off-by:
Yoichi Yuasa <yuasa@hh.iij4u.or.jp> Signed-off-by:
-
Paul Mackerras authored
This patch is from John Rose <johnrose@austin.ibm.com>. EEH scans the system I/O adapters at boot for EEH-capabilities. If no EEH-capable adapters are found, the subsystem is marked disabled for the life of the system. EEH should allow dynamic enabling of the EEH subsystem when hotplug-adding an adapter. Signed-off-by:
John Rose <johnrose@austin.ibm.com> Signed-off-by:
Paul Mackerras <paulus@samba.org> Signed-off-by:
-
Paul Mackerras authored
This patch is from John Rose <johnrose@austin.ibm.com>. Upon DLPAR addition of a PCI Host Brige to a system with purely virtual I/O, set pci_io_base as necessary. Signed-off-by:
-
Paul Mackerras authored
This patch is from Ananth N Mavinakayanahalli <ananth@in.ibm.com>. While processing a kprobe, we were currently not handling all available trap variants available on PowerPC. This lead to the breakage of BUG() handling in ppc64. Signed-off-by:
-
Paul Mackerras authored
This patch is from Thomas Gleixner <tglx@linutronix.de>. Convert the initializers of hw_interrupt_type structures to C99 initializers. Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Paul Mackerras authored
This patch is from Amos Waterland <apw@us.ibm.com>. In pmac_setup.c, the function init_boot_display as currently written only makes sense with CONFIG_BOOTX_TEXT enabled, and causes a link error if it is not enabled. Signed-off-by:
Amos Waterland <apw@us.ibm.com> Signed-off-by:
-
Paul Mackerras authored
This patch is from Jake Moilanen <moilanen@austin.ibm.com>, reformatted by me. The `assigned-addresses' property in the Open Firmware device tree nodes for PCI devices has 64 bits of PCI bus address, but we were only using 32. This patch fixes it so we use all 64. Signed-off-by:
Jake Moilanen <moilanen@austin.ibm.com> Signed-off-by:
-
Paul Mackerras authored
This patch is from Brian King <brking@us.ibm.com>. When working with a PCI-X Mode 2 adapter on a PCI-X Mode 1 PPC64 system, the current code used to determine the config space size of a device results in a PCI Master abort and an EEH error, resulting in the device being taken offline. This patch checks OF to see if the PCI bridge supports PCI-X Mode 2 and fails config accesses beyond 256 bytes if it does not. Signed-off-by:
Brian King <brking@us.ibm.com> Signed-off-by:
-
Colin Leroy authored
This patch lets therm_adt746x handle the latest powerbooks. In these ones, Apple doesn't put the i2c bus number in the "reg" property of the fan node. Instead, we can get the bus number from the fan node path, which looks like "/proc/device-tree/.../i2c-bus@1/.../fan". Here's a patch that handles both old and new form. Signed-off-by:
Colin Leroy <colin@colino.net> Signed-off-by:
-
Mark A. Greer authored
Radstone PPC7D are ppc7447A VME boards with Marvell Discovery-II, dual GigE, dual PMC, 6 serial ports, keyboard/mouse, USB and optional SCSI/VGA. This patch adds support for the PPC7D platform. Signed-off-by:
James Chapman <jchapman@katalix.com> Signed-off-by:
Mark A. Greer <mgreer@mvista.com> Signed-off-by:
-
Jeff Mahoney authored
This patch changes reiserfs to use the VFS level private inode flags, and eliminates the old reiserfs private inode flag. Signed-off-by:
Jeff Mahoney <jeffm@suse.com> Signed-off-by:
-
Jeff Mahoney authored
This patch moves the assignment of i_priv_object to a static inline. This is in preparation for selinux support in reiserfs. Signed-off-by:
-
Jeff Mahoney authored
This patch applies the IS_PRIVATE test to the selinux internal inode loop. Signed-off-by:
-
Jeff Mahoney authored
This patch series adds SELinux support to reiserfs. This patch adds an S_PRIVATE flag to inode->i_flags to mark an inode as filesystem-internal. As such, it should be excepted from the security infrastructure to allow the filesystem to perform its own access control. Signed-off-by:
Stephen Smalley <sds@tycho.nsa.gov> Acked-by:
Chris Wright <chrisw@osdl.org> Signed-off-by:
-
Nigel Cunningham authored
Here's a patch I've prepared which improves the speed at which memory is freed prior to suspend. It should be a big gain for swsusp. For suspend2, it isn't used much, but has shown big improvements when I set a very low image size limit and had memory quite full. 1GB P4, 2.6.11+Suspend2 2.1.8. Soft image size limit set to 2MB to emulate Pavel's implementation (eat as much memory as we can). Without patch: Freed 16545 pages in 4000 jiffies = 16.16 MB/s Freed 83281 pages in 14060 jiffies = 23.14 MB/s Freed 237754 pages in 41482 jiffies = 22.39 MB/s With patch: Freed 52257 pages in 6700 jiffies = 30.46 MB/s Freed 105693 pages in 11035 jiffies = 37.41 MB/s Freed 239007 pages in 18284 jiffies = 51.06 MB/s With a less aggressive image size limit (200MB): Without the patch: Freed 14600 pages in 1749 jiffies = 32.61 MB/s (Anomolous!) Freed 88563 pages in 14719 jiffies = 23.50 MB/s Freed 205734 pages in 32389 jiffies = 24.81 MB/s With the patch: Freed 68252 pages in 496 jiffies = 537.52 MB/s Freed 116464 pages in 569 jiffies = 798.54 MB/s Freed 209699 pages in 705 jiffies = 1161.89 MB/s The later pages take more work to get, which accounts for the slower MB/s with smaller numbers of pages to free. Without the patch, though, getting the easier pages also takes longer because we do a far greater number of invocations of shrink_all_memory in order to get the same number of pages. Signed-Off-By:
Nigel Cunningham <ncunningham@cyclades.com> Acked-By:
Pavel Machek <pavel@ucw.cz> Signed-off-by:
-
Christoph Hellwig authored
This way we actually shake dentries before inodes and thus mark more inodes reclaimable once we shake them. Signed-off-by:
-
Hugh Dickins authored
A small change to the tests for "Bad page state", to avoid one class of the page_remove_rmap BUG reports, giving more information while letting the system continue: check page_mapcount (_mapcount != -1) rather than page_mapped (_mapcount >= 0). And how does _mapcount go bad? In the case under study, it looks sure now that an overheating(?) Pentium III sometimes gets confused by a pair of instructions in the no-buddy-bitmap __free_pages_bulk, and clears the PG_private bit from the _mapcount field while buddying around - changing PG_private value changes the bit cleared from _mapcount. Bad page state mapcount:-4096 would have tracked this down much sooner, and will be recognizable if other cpus show the same aberrant reaction to 2.6.11. The page_remove_rmap BUG does need to be replaced by more permissive and informative handling, but I'm not yet ready to to finalize such a patch. Please admit Colin Harrison to the Order of the Iridescent Penguin, for his tireless testing. Signed-off-by:
Hugh Dickins <hugh@veritas.com> Signed-off-by:
-
Marcelo Tosatti authored
Use find_*_page helpers in swap code instead handcoding it. Signed-off-by:
Marcelo Tosatti <marcelo.tosatti@cyclades.com> Acked-by:
-
Oleg Nesterov authored
On top of "[PATCH 2/2] readahead: improve sequential read detection". Signed-off-by:
Oleg Nesterov <oleg@tv-sign.ru> Signed-off-by:
-
Oleg Nesterov authored
1. Current code can't always detect sequential reading, in case when read size is not PAGE_CACHE_SIZE aligned. If application reads the file by 4096+512 chunks, we have: 1st read: first read detected, prev_page = 2. 2nd read: offset == 2, the read is considered random. page_cache_readahead() should treat prev_page == offset as sequential access. In this case it is better to ++offset, because of blockable_page_cache_readahead(offset, size). 2. If application reads 4096 bytes with *ppos == 512, we have to read 2 pages, but req_size == 1 in do_generic_mapping_read(). Usually it's not a problem. But in random read case it results in unnecessary page cache misses. ~$ time dd conv=notrunc if=/tmp/GIG of=/tmp/dummy bs=$((4096+512)) 2.6.11-clean: real=370.35 user=0.16 sys=14.66 2.6.11-patched: real=234.49 user=0.19 sys=12.41 Signed-off-by:
-
Oleg Nesterov authored
Currently page_cache_readahead() treats ra->size == 0 (first read) and ra->size == -1 (ra_off was called) separately, but does exactly the same in both cases. With this patch we may assume that the reading starts in 'ra_off()' state, so we don't need to consider the first read as a special case. file_ra_state_init() sets ra->prev_page = -1; ra->size = 0; When the page_cache_readahead() is called for the first time it sets ra->size to nonzero value either via get_init_ra_size() or ra_off(). So ra->size == 0 implies that ra->prev_page == -1. I am ignoring the case when readahead is disabled via ra->ra_pages == 0. page_cache_readahead detects sub-page sized reads: if (offset == ra->prev_page && req_size == 1 && ra->size != 0) But if offset == ra->prev_page, then ra->size == 0 can happen only if offset == -1, so there is no need to check ra->size here. If application starts reading 16Tb file from the last page then readahead can't help. First offset==0 read or first sequential detection: if ((ra->size == 0 && offset == 0) || (ra->size == -1 && sequential) could be changed to: if ((ra->size == 0 && sequential) || (ra->size == -1 && sequential) which means: if (sequential && (ra->size == 0 || ra->size == -1)) Random case detection: if (!sequential || (ra->size == 0)) But if sequential == 1, then ra->size can't be 0, this case is already handled before. Now we have: if (offset == ra->prev_page && req_size == 1) /* sub-page reads */ if (sequential && (ra->size == 0 || ra->size == -1)) /* first offset==0 read or first sequential */ if (!sequential) /* random case */ Now ->size is checked only in one place, so ra_off() can set ra->size = 0, and we can just test ->size against 0. Signed-off-by:
-
Oleg Nesterov authored
I think that do_page_cache_readahead() can be inlined in blockable_page_cache_readahead(), this makes the code a bit more readable in my opinion. Also makes check_ra_success() static inline. Signed-off-by:
-
Oleg Nesterov authored
This patch introduces make_ahead_window() function for simplification of page_cache_readahead. Signed-off-by:
-
Oleg Nesterov authored
get_next_ra_size() can get all info from file_ra_state. Signed-off-by:
-
Oleg Nesterov authored
There is no point in setting ra->prev_page before 'goto out', it will be overwritten anyway. Signed-off-by:
-
Hugh Dickins authored
Ingo's patch to reduce scheduling latencies, by checking for lockbreak in copy_page_range, was in the -VP and -mm patchsets some months ago; but got preempted by the 4level rework, and not reinstated since. Restore it now in copy_pte_range - which mercifully makes it easier. Signed-off-by:
-
Gordon Jin authored
This patch fixes 2 cornercases of overflow caused by argument len in sys_mincore(): Case 1: len is so large that will overflow to 0 after page alignment. E.g. len=(size_t)(-1), i.e. 0xff...ff. Expected result: it's overflow and return ENOMEM. Current result: len is aligned to 0, then treated the same as len=0 and return succeed. This cornercase has been fixed in do_mmap_pgoff(), and here sys_mincore() also needs this fix. Case 2: len is a large number but will not overflow after alignment. But start+len will overflow. E.g. len=(size_t)(-PAGE_SIZE), and start>0. Expected result: it's overflow and return ENOMEM. Current result: return EINVAL. Looks like considering len as a non-positive value, probably influenced by manpage. But since the type of len is size_t, i.e. unsigned, it shouldn't be considered as non-positive value. I've also reported this inconsistency to manpage mincore. Signed-off-by:
Gordon Jin <gordon.jin@intel.com> Signed-off-by:
-
Prasanna Meda authored
- Race in mempool_resize: memcpy can copy at the end of the kmalloced elements. - When new_min_nr is same as min_nr, instead of reallocate and copy, just return, changed '<' to '<='. - Changed while condition to the same sense of if condition from '>' to '<'; it is easy to think with only one of the left and right brains at a time. Signed-off-by:
Prasanna Meda <pmeda@akamai.com> Signed-off-by:
-
Dave Hansen authored
Appended is a patch which stops using the zone->zone_mem_map to calculate the buddy and combined page pointers. It uses the fact that the mem_map array is guaranteed to be contigious for the surrounding (1 << MAX_ORDER) pages. The relative positions of the pages in the physical address space to provide the alignement; which conicidentally fixes the issue where zones are not aligned at MAX_ORDER. There is a very comprehensive comment in the new code explaining the mathematical relationship between a page and its buddy so I won't reproduce it here. This kind of approach is required for CONFIG_NONLINEAR systems where the mem_map is not contiguous within a zone, and the zone->zone_mem_map is not used at all. This patch has been boot-tested on a large variety of systems and architectures: my P4 laptop, 16-way NUMAQ, 16-way Summit, 4-way x86 SMP, ppc64 LPAR, x86_64, and several ia64 configurations. It has been performance-tested on a 16-way NUMAQ. SDET shows a very slight (within margin of error) performance gain. Kernbench shows an approximately ~1% decrease in system time with this patch applied. So, it has a likely positive performance impact. However, the patch has the potential to have a negative performance impact on systems with an expensive page_to_pfn() implementation. But, I think the NUMAQ has one of the more expensive ones around, and it doesn't seem mind too much. Signed-off-by:
Andy Whitcroft <apw@shadowen.org> Signed-off-by:
Dave Hansen <haveblue@us.ibm.com> Signed-off-by:
-
