- 28 Oct, 2006 16 commits
-
-
Jan Dittmer authored
Obvious fix. Signed-off-by:
Jan Dittmer <jdi@l4x.org> Acked-by:
Florin Malita <fmalita@gmail.com> Signed-off-by:
Adrian Bunk <bunk@stusta.de> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Andrey Panin authored
Fix this: > Subject : CONFIG_X86_VISWS=3Dy, CONFIG_SMP=3Dn compile error > References : http://lkml.org/lkml/2006/10/7/51 > Submitter : Jesper Juhl <jesper.juhl@gmail.com> > Caused-By : David Howells <dhowells@redhat.com> > commit 7d12e780 > Status : unknown Via undescribed means. Signed-off-by:
Andrey Panin <pazke@donpac.ru> Cc: Adrian Bunk <bunk@stusta.de> Signed-off-by:
-
Giridhar Pemmasani authored
If __vmalloc is called to allocate memory with GFP_ATOMIC in atomic context, the chain of calls results in __get_vm_area_node allocating memory for vm_struct with GFP_KERNEL, causing the 'sleeping from invalid context' warning. This patch fixes it by passing the gfp flags along so __get_vm_area_node allocates memory for vm_struct with the same flags. Signed-off-by:
-
Pavel Emelianov authored
blkdev_open() calls bc_acquire() to get a struct block_device. Since bc_acquire() may return NULL when system is out of memory an appropriate check is required. Signed-off-by:
Pavel Emelianov <xemul@openvz.org> Signed-off-by:
-
Yasunori Goto authored
Add __GFP_NOWARN flag to calling of __alloc_pages() in __kmalloc_section_memmap(). It can reduce noisy failure message. In ia64, section size is 1 GB, this means that order 8 pages are necessary for each section's memmap. It is often very hard requirement under heavy memory pressure as you know. So, __alloc_pages() gives up allocation and shows many noisy stack traces which means no page for each sections. (Current my environment shows 32 times of stack trace....) But, __kmalloc_section_memmap() calls vmalloc() after failure of it, and it can succeed allocation of memmap. So, its stack trace warning becomes just noisy. I suppose it shouldn't be shown. Signed-off-by:
Yasunori Goto <y-goto@jp.fujitsu.com> Signed-off-by:
-
Randy Dunlap authored
drivers/md/raid1.c:1479: warning: long long unsigned int format, long unsigned int arg (arg 4) drivers/md/raid10.c:1475: warning: long long unsigned int format, long unsigned int arg (arg 4) Signed-off-by:
Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by:
Neil Brown <neilb@suse.de> Signed-off-by:
-
NeilBrown authored
A recent fix which made sure ->degraded was initialised properly exposed a second bug - ->degraded wasn't been updated when drives failed or were hot-added. Signed-off-by:
-
NeilBrown authored
When "mdadm --grow --size=xxx" is used to resize an array (use more or less of each device), we check the new siza against the available space in each device. We already have that number recorded in rdev->size, so calculating it is pointless (and wrong in one obscure case). Signed-off-by:
-
NeilBrown authored
If save_raid_disk is >= 0, then the device could be a device that is already in sync that is being re-added. So we need to default this value to -1. Signed-off-by:
-
bibo,mao authored
efi_memory_present_wrapper() parameter start/end is physical address, but function memory_present parameter is PFN, this patch converts physical address to PFN. Signed-off-by:
bibo, mao <bibo.mao@intel.com> Cc: Andi Kleen <ak@suse.de> Signed-off-by:
-
Eric Sandeen authored
When running several fsx's and other filesystem stress tests, we found cases where an unmapped buffer was still being sent to submit_bh by the ext3 dirty data journaling code. I saw this happen in two ways, both related to another thread doing a truncate which would unmap the buffer in question. Either we would get into journal_dirty_data with a bh which was already unmapped (although journal_dirty_data_fn had checked for this earlier, the state was not locked at that point), or it would get unmapped in the middle of journal_dirty_data when we dropped locks to call sync_dirty_buffer. By re-checking for mapped state after we've acquired the bh state lock, we should avoid these races. If we find a buffer which is no longer mapped, we essentially ignore it, because journal_unmap_buffer has already decided that this buffer can go away. I've also added tracepoints in these two cases, and made a couple other tracepoint changes that I found useful in debugging this. Signed-off-by:
Eric Sandeen <esandeen@redhat.com> Cc: <linux-ext4@vger.kernel.org> Signed-off-by:
-
Eric Sandeen authored
When running several fsx's and other filesystem stress tests, we found cases where an unmapped buffer was still being sent to submit_bh by the ext3 dirty data journaling code. I saw this happen in two ways, both related to another thread doing a truncate which would unmap the buffer in question. Either we would get into journal_dirty_data with a bh which was already unmapped (although journal_dirty_data_fn had checked for this earlier, the state was not locked at that point), or it would get unmapped in the middle of journal_dirty_data when we dropped locks to call sync_dirty_buffer. By re-checking for mapped state after we've acquired the bh state lock, we should avoid these races. If we find a buffer which is no longer mapped, we essentially ignore it, because journal_unmap_buffer has already decided that this buffer can go away. I've also added tracepoints in these two cases, and made a couple other tracepoint changes that I found useful in debugging this. Signed-off-by:
-
Randy Dunlap authored
fs/ext4/resize.c:72: warning: long long unsigned int format, __u64 arg (arg 4) fs/ext4/resize.c:76: warning: long long unsigned int format, __u64 arg (arg 4) fs/ext4/resize.c:81: warning: long long unsigned int format, __u64 arg (arg 4) fs/ext4/resize.c:85: warning: long long unsigned int format, __u64 arg (arg 4) fs/ext4/resize.c:89: warning: long long unsigned int format, __u64 arg (arg 4) fs/ext4/resize.c:89: warning: long long unsigned int format, __u64 arg (arg 5) fs/ext4/resize.c:93: warning: long long unsigned int format, __u64 arg (arg 4) fs/ext4/resize.c:93: warning: long long unsigned int format, __u64 arg (arg 5) fs/ext4/resize.c:98: warning: long long unsigned int format, __u64 arg (arg 4) fs/ext4/resize.c:103: warning: long long unsigned int format, __u64 arg (arg 4) fs/ext4/resize.c:109: warning: long long unsigned int format, __u64 arg (arg 4) Signed-off-by:
-
Martin Bligh authored
If try_to_free_pages / balance_pgdat are called with a gfp_mask specifying GFP_IO and/or GFP_FS, they will reclaim the requisite number of pages, and the reset prev_priority to DEF_PRIORITY (or to some other high (ie: unurgent) value). However, another reclaimer without those gfp_mask flags set (say, GFP_NOIO) may still be struggling to reclaim pages. The concurrent overwrite of zone->prev_priority will cause this GFP_NOIO thread to unexpectedly cease deactivating mapped pages, thus causing reclaim difficulties. Fix this is to key the distress calculation not off zone->prev_priority, but also take into account the local caller's priority by using min(zone->prev_priority, sc->priority) Signed-off-by:
Martin J. Bligh <mbligh@google.com> Cc: Nick Piggin <nickpiggin@yahoo.com.au> Cc: <stable@kernel.org> Signed-off-by:
-
Martin Bligh authored
The temp_priority field in zone is racy, as we can walk through a reclaim path, and just before we copy it into prev_priority, it can be overwritten (say with DEF_PRIORITY) by another reclaimer. The same bug is contained in both try_to_free_pages and balance_pgdat, but it is fixed slightly differently. In balance_pgdat, we keep a separate priority record per zone in a local array. In try_to_free_pages there is no need to do this, as the priority level is the same for all zones that we reclaim from. Impact of this bug is that temp_priority is copied into prev_priority, and setting this artificially high causes reclaimers to set distress artificially low. They then fail to reclaim mapped pages, when they are, in fact, under severe memory pressure (their priority may be as low as 0). This causes the OOM killer to fire incorrectly. From: Andrew Morton <akpm@osdl.org> __zone_reclaim() isn't modifying zone->prev_priority. But zone->prev_priority is used in the decision whether or not to bring mapped pages onto the inactive list. Hence there's a risk here that __zone_reclaim() will fail because zone->prev_priority ir large (ie: low urgency) and lots of mapped pages end up stuck on the active list. Fix that up by decreasing (ie making more urgent) zone->prev_priority as __zone_reclaim() scans the zone's pages. This bug perhaps explains why ZONE_RECLAIM_PRIORITY was created. It should be possible to remove that now, and to just start out at DEF_PRIORITY? Cc: Nick Piggin <nickpiggin@yahoo.com.au> Cc: Christoph Lameter <clameter@engr.sgi.com> Cc: <stable@kernel.org> Signed-off-by:
-
Nick Piggin authored
- Consolidate page_cache_alloc - Fix splice: only the pagecache pages and filesystem data need to use mapping_gfp_mask. - Fix grab_cache_page_nowait: same as splice, also honour NUMA placement. Signed-off-by:
Nick Piggin <npiggin@suse.de> Cc: Jens Axboe <jens.axboe@oracle.com> Signed-off-by:
-
- 27 Oct, 2006 11 commits
-
-
Linus Torvalds authored
* master.kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6: [SPARC]: Fix bus_id[] string overflow.
-
Linus Torvalds authored
* master.kernel.org:/pub/scm/linux/kernel/git/gregkh/pci-2.6: PCI: Remove quirk_via_abnormal_poweroff PCI: reset pci device state to unknown state for resume PCI: x86-64: mmconfig missing printk levels PCI: fix pci_fixup_video as it blows up on sparc64 acpiphp: fix latch status
-
Jesper Juhl authored
Add description of 'raw' in comments for drivers/mtd/nand/nand_base.c::nand_write_page_syndrome() so 'make xmldocs' will not spew a warning at us. Signed-off-by:
Jesper Juhl <jesper.juhl@gmail.com> Acked-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Andrew Morton authored
The multithreaded-probing code has a problem: after one initcall level (eg, core_initcall) has been processed, we will then start processing the next level (postcore_initcall) while the kernel threads which are handling core_initcall are still executing. This breaks the guarantees which the layered initcalls previously gave us. IOW, we want to be multithreaded _within_ an initcall level, but not between different levels. Fix that up by causing the probing code to wait for all outstanding probes at one level to complete before we start processing the next level. Cc: Greg KH <greg@kroah.com> Signed-off-by:
-
Andrew Morton authored
Add a vmlinux.lds.h helper macro for defining the eight-level initcall table, teach all the architectures to use it. This is a prerequisite for a patch which performs initcall synchronisation for multithreaded-probing. Cc: Greg KH <greg@kroah.com> Signed-off-by:
Haavard Skinnemoen <hskinnemoen@atmel.com> Signed-off-by:
-
Karsten Wiese authored
My K8T800 mobo resumes fine from suspend to ram with and without patch applied against 2.6.18. quirk_via_abnormal_poweroff makes some boards not boot 2.6.18, so IMO patch should go to head, 2.6.18.2 and everywhere "ACPI: ACPICA 20060623" has been applied. Remove quirk_via_abnormal_poweroff Obsoleted by "ACPI: ACPICA 20060623": <snip> Implemented support for "ignored" bits in the ACPI registers. According to the ACPI specification, these bits should be preserved when writing the registers via a read/modify/write cycle. There are 3 bits preserved in this manner: PM1_CONTROL[0] (SCI_EN), PM1_CONTROL[9], and PM1_STATUS[11]. http://bugzilla.kernel.org/show_bug.cgi?id=3691 </snip> Signed-off-by:Karsten Wiese <fzu@wemgehoertderstaat.de> Cc: Bob Moore <robert.moore@intel.com> Cc: "Brown, Len" <len.brown@intel.com> Acked-by:
Dave Jones <davej@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Shaohua Li authored
Considering below scenario: 1.Unload a PCI device's driver, the device ->current remains in PCI_D0. 2.Do suspend/resume circle. After that, BIOS puts the device to D3. 3.Reload the device driver. The calling pci_set_power_state in the driver can't change the state to D0, as set_power_state thinks the device is already in D0. A bug is reported at http://bugzilla.kernel.org/show_bug.cgi?id=6024 Pat attached a patch at http://marc.theaimsgroup.com/?l=linux-pci&m=114049761428561&w=2 for this issue, but it's lost. As pci_set_power_state can handle D3 -> D0 correctly (restore config space), I simplified Patrick's patch. Signed-off-by:
Shaohua Li <shaohua.li@intel.com> Cc: Patrick Mochel <mochel@digitalimplant.org> Signed-off-by:
-
Dave Jones authored
Signed-off-by:
-
Eiichiro Oiwa authored
This reverts much of the original pci_fixup_video change and makes it work for all arches that need it. fixed, and tested on x86, x86_64 and IA64 dig. Signed-off-by:
Eiichiro Oiwa <eiichiro.oiwa.nm@hitachi.com> Acked-by:
David Miller <davem@davemloft.net> Signed-off-by:
-
MUNEDA Takahiro authored
pci_hotplug.h says: * @latch_status: if the latch (if any) is open or closed (1/0) However, acpiphp returns opposite value. This patch fixes this issue. I tested this patch on my ia64 machine that has some apciphp based hotplug slots. Signed-off-by:
MUNEDA Takahiro <muneda.takahiro@jp.fujitsu.com> Signed-off-by:
Kristen Carlson Accardi <kristen.c.accardi@intel.com> Signed-off-by:
-
David S. Miller authored
dp->path_component_name can be larger than ->bus_id[] so use a different naming scheme for this stuff. Noticed by Jurij Smakov. Signed-off-by:
-
- 26 Oct, 2006 13 commits
-
-
Linus Torvalds authored
* master.kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6: [SPARC64]: Fix memory corruption in pci_4u_free_consistent(). [SPARC64]: Fix central/FHC bus handling on Ex000 systems.
-
Linus Torvalds authored
* master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6: [BRIDGE]: correct print message typo [TCP] H-TCP: fix integer overflow [TCP] cubic: scaling error
-
Randy Dunlap authored
Correct message typo/spello. Signed-off-by:
-
Gavin McCullagh authored
When using H-TCP with a single flow on a 500Mbit connection (or less actually), alpha can exceed 65000, so alpha needs to be a u32. Signed-off-by:
Gavin McCullagh <gavin.mccullagh@nuim.ie> Signed-off-by:
Doug Leith <doug.leith@nuim.ie> Signed-off-by:
-
Stephen Hemminger authored
Doug Leith observed a discrepancy between the version of CUBIC described in the papers and the version in 2.6.18. A math error related to scaling causes Cubic to grow too slowly. Patch is from "Sangtae Ha" <sha2@ncsu.edu>. I validated that it does fix the problems. See the following to show behavior over 500ms 100 Mbit link. Sender (2.6.19-rc3) --- Bridge (2.6.18-rt7) ------- Receiver (2.6.19-rc3) 1G [netem] 100M http://developer.osdl.org/shemminger/tcp/2.6.19-rc3/cubic-orig.png http://developer.osdl.org/shemminger/tcp/2.6.19-rc3/cubic-fix.pngSigned-off-by:Stephen Hemminger <shemminger@osdl.org> Signed-off-by:
-
David S. Miller authored
The second argument to free_npages() was being incorrectly calculated, which would thus access far past the end of the arena->map[] bitmap. Signed-off-by: -
David S. Miller authored
1) probe_other_fhcs() wants to see only non-central FHC busses, so skip FHCs that don't sit off the root 2) Like SBUS, FHC can lack the appropriate address and size cell count properties, so add an of_busses[] entry and handlers for that. 3) Central FHC irq translator probing was buggy. We were trying to use dp->child in irq_trans_init but that linkage is not setup at this point. So instead, pass in the parent of "dp" and look for the child "fhc" with parent "central". Thanks to the tireless assistence of Ben Collins in tracking down these problems and testing out these fixes. Signed-off-by: -
Jeff Garzik authored
Merge branch 'upstream-fixes' of git://lost.foo-projects.org/~ahkok/git/netdev-2.6 into upstream-fixes
-
Haavard Skinnemoen authored
Sync atstk1002_defconfig with latest git, turn off non-existent drivers and enable a few more userspace-visible options like SysV IPC and inotify support. Signed-off-by:
-
Haavard Skinnemoen authored
The read[bwl] and write[bwl] functions are meant for accessing PCI devices. How this is achieved on AVR32 is unknown, as there are no systems with a PCI bridge available yet. On-chip peripheral access, however, should not depend on how we end up implementing PCI access, so using __raw_read[bwl]/__raw_write[bwl] is the right thing to do for on-chip peripherals. This patch converts the drivers for the static memory controller, interrupt controller, PIO controller and system manager to use __raw MMIO access. Signed-off-by:
-
Haavard Skinnemoen authored
Implement __raw_readsb and __raw_writesb. Export __raw_reads[bwl] and __raw_writes[bwl] for use by modules. Signed-off-by:
-
Ben Nizette authored
A number of new drivers require io{read,write}{8,16,32}{be,} family of io operations. These are provided for the AVR32 by this patch in the form of a series of macros. Access to the (memory mapped) io space through these macros is defined to be little endian only as little endian devices (such as PCI) are the main consumer of IO access. If high speed access is required, io{read,write}{16,32}be macros are supplied to perform native big endian access to this io space. Signed-off-by:Ben Nizette <ben@mallochdigital.com> Signed-off-by:
-
Haavard Skinnemoen authored
When calling e.g. atomic_sub_return with a large constant, the compiler may output an immediate that is too large for the sub instruction in the middle of the loop. Fix this by explicitly specifying the number of bits allowed in the constraint. Also stop atomic_add_return() and friends from falling back to their respective "sub" variants if the constant is too large to fit in an immediate. Signed-off-by:
-
