- 07 Feb, 2006 2 commits
-
-
Lennert Buytenhek authored
sis900 defines 'cfgpmcsr' as an I/O space register, but CFGPMCSR is in fact a config space register, and there is no register at offset 0x44 in I/O space, so delete the enum. Signed-off-by:
Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by:
Jeff Garzik <jgarzik@pobox.com>
-
Jesse Brandeburg authored
e100 seems to have had a long standing bug where e100_init_hw was being called when it should not have been. This caused a panic due to recent changes that rely on correct set up in the driver, and more robust error paths. Signed-off-by:
Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by:
-
- 06 Feb, 2006 4 commits
-
-
-
Russ Anderson authored
After converting the cpu physical address to shub2 physical addressing, the address was run through TO_PHYS() which clobbered a high node offset bit causing the BTE to fail on shub2 nodes with large memory. This fix corrects that problem. Signed-off-by: Russ Anderson (rja@sgi.com) Signed-off-by:Tony Luck <tony.luck@intel.com>
-
Tony Luck authored
-
Herbert Xu authored
When we pull the PPP protocol off the skb, we forgot to update the hardware RX checksum. This may lead to messages such as dsl0: hw csum failure. Similarly, we need to clear the hardware checksum flag when we use the existing packet to store the decompressed result. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
- 05 Feb, 2006 34 commits
-
-
Greg KH authored
I thought we had fixed up all non-gpl USB drivers, and was wrong to do this. Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Linus Torvalds authored
The non-NUMA case would do an unmatched "free_alien_cache()" on an alien pointer that had never been allocated. It might not matter from a code generation standpoint (since in the non-NUMA case, the code doesn't actually _do_ anything), but it not only results in a compiler warning, it's really really ugly too. Fix the compiler warning by just having a matching dummy allocation. That also avoids an unnecessary #ifdef in the code. Signed-off-by: -
Linus Torvalds authored
-
Linus Torvalds authored
-
Robb, Sam authored
On a system where libintl.h is present, but the NLS functionality is supplied by a separate library instead of the system C library, an attempt to "make config" or "make menuconfig" will fail with link errors, ex: scripts/kconfig/mconf.o:mconf.c:(.text+0xf63): undefined reference to `_libintl_gettext' This patch attempts to correct the problem by detecting whether or not NLS support requires linking with libintl. Signed-off-by:Samuel J Robb <sam.robb@timesys.com> Cc: Roman Zippel <zippel@linux-m68k.org> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
-
Adrian Bunk authored
Due to the usage of set_64bit in include/asm-i386/pgtable-3level.h, HIGHMEM64G must depend on X86_CMPXCHG64. Signed-off-by:
Adrian Bunk <bunk@stusta.de> Signed-off-by:
-
Takashi Iwai authored
Fix gcc4.1 compile warnings "value computed is not used" with set_current_state() and set_task_state() on i386/SMP and x86-64. Signed-off-by:
Takashi Iwai <tiwai@suse.de> Cc: Nick Piggin <nickpiggin@yahoo.com.au> Cc: Andi Kleen <ak@muc.de> Signed-off-by:
-
Chuck Ebbert authored
Show first field of kernel version in register dumps like x86_64 does. Changes output from e.g.: (2.6.16-rc1) to: (2.6.16-rc1 #12) Signed-off-by:
Chuck Ebbert <76306.1226@compuserve.com> Signed-off-by:
-
Chuck Ebbert authored
i386 CPU init code accesses freed init memory when booting a newly-started processor after CPU hotplug. The cpu_devs array is searched to find the vendor and it contains pointers to freed data. Fix that by: 1. Zeroing entries for freed vendor data after bootup. 2. Changing Transmeta, NSC and UMC to all __init[data]. 3. Printing a warning (once only) and setting this_cpu to a safe default when the vendor is not found. This does not change behavior for AMD systems. They were broken already but no error was reported. Signed-off-by: -
Ulrich Drepper authored
Signed-off-by:
Ulrich Drepper <drepper@redhat.com> Signed-off-by:
-
Trond Myklebust authored
When walking a path, the LOOKUP_CONTINUE flag is used by some filesystems (for instance NFS) in order to determine whether or not it is looking up the last component of the path. It this is the case, it may have to look at the intent information in order to perform various tasks such as atomic open. A problem currently occurs when link_path_walk() hits a symlink. In this case LOOKUP_CONTINUE may be cleared prematurely when we hit the end of the path passed by __vfs_follow_link() (i.e. the end of the symlink path) rather than when we hit the end of the path passed by the user. The solution is to have link_path_walk() clear LOOKUP_CONTINUE if and only if that flag was unset when we entered the function. Signed-off-by:
Trond Myklebust <Trond.Myklebust@netapp.com> Cc: Al Viro <viro@ftp.linux.org.uk> Cc: Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Ravikiran G Thirumalai authored
This fixes locking and bugs in cpu_down and cpu_up paths of the NUMA slab allocator. Sonny Rao <sonny@burdell.org> reported problems sometime back on POWER5 boxes, when the last cpu on the nodes were being offlined. We could not reproduce the same on x86_64 because the cpumask (node_to_cpumask) was not being updated on cpu down. Since that issue is now fixed, we can reproduce Sonny's problems on x86_64 NUMA, and here is the fix. The problem earlier was on CPU_DOWN, if it was the last cpu on the node to go down, the array_caches (shared, alien) and the kmem_list3 of the node were being freed (kfree) with the kmem_list3 lock held. If the l3 or the array_caches were to come from the same cache being cleared, we hit on badness. This patch cleans up the locking in cpu_up and cpu_down path. We cannot really free l3 on cpu down because, there is no node offlining yet and even though a cpu is not yet up, node local memory can be allocated for it. So l3s are usually allocated at keme_cache_create and destroyed at kmem_cache_destroy. Hence, we don't need cachep->spinlock protection to get to the cachep->nodelist[nodeid] either. Patch survived onlining and offlining on a 4 core 2 node Tyan box with a 4 dbench process running all the time. Signed-off-by:
Alok N Kataria <alokk@calsoftinc.com> Signed-off-by:
Ravikiran Thirumalai <kiran@scalex86.org> Cc: Christoph Lameter <christoph@lameter.com> Signed-off-by:
-
Ravikiran G Thirumalai authored
Earlier, we had to disable on chip interrupts while taking the cachep->spinlock because, at cache_grow, on every addition of a slab to a slab cache, we incremented colour_next which was protected by the cachep->spinlock, and cache_grow could occur at interrupt context. Since, now we protect the per-node colour_next with the node's list_lock, we do not need to disable on chip interrupts while taking the per-cache spinlock, but we just need to disable interrupts when taking the per-node kmem_list3 list_lock. Signed-off-by:
Shai Fultheim <shai@scalex86.org> Cc: Christoph Lameter <christoph@lameter.com> Signed-off-by:
-
Ravikiran G Thirumalai authored
colour_next is used as an index to add a colouring offset to a new slab in the cache (colour_off * colour_next). Now with the NUMA aware slab allocator, it makes sense to colour slabs added on the same node sequentially with colour_next. This patch moves the colouring index "colour_next" per-node by placing it on kmem_list3 rather than kmem_cache. This also helps simplify locking for CPU up and down paths. Signed-off-by:
-
Christoph Lameter authored
I just spent some time researching a Bus Error. Turns out that the huge page fault handler can return VM_FAULT_SIGBUS for various conditions where no huge page is available. Add a note explaining the reasoning in the source. Signed-off-by:
Christoph Lameter <clameter@sgi.com> Acked-by:
William Lee Irwin III <wli@holomorphy.com> Cc: Hugh Dickins <hugh@veritas.com> Signed-off-by:
-
Andrew Morton authored
Ben points out that: When writing files out using O_SYNC, jbd's 1 jiffy delay results in a significant drop in throughput as the disk sits idle. The patch below results in a 4-5x performance improvement (from 6.5MB/s to ~24-30MB/s on my IDE test box) when writing out files using O_SYNC. So optimise the batching code by omitting it entirely if the process which is doing a sync write is the same as the one which did the most recent sync write. If that's true, we're unlikely to get any other processes joining the transaction. (Has been in -mm for ages - it took me a long time to get on to performance testing it) Numbers, on write-cache-disabled IDE: /usr/bin/time -p synctest -n 10 -uf -t 1 -p 1 dir-name Unpatched: 40 seconds Patched: 35 seconds Batching disabled: 35 seconds This is the problematic single-process-doing-fsync case. With multiple fsyncing processes the numbers are AFACIT unaltered by the patch. Aside: performance testing and instrumentation shows that the transaction batching almost doesn't help (testing with synctest -n 1 -uf -t 100 -p 10 dir-name on non-writeback-caching IDE). This is because by the time one process is running a synchronous commit, a bunch of other processes already have a transaction handle open, so they're all going to batch into the same transaction anyway. The batching seems to offer maybe 5-10% speedup with this workload, but I'm pretty sure it was more important than that when it was first developed 4-odd years ago... Cc: "Stephen C. Tweedie" <sct@redhat.com> Cc: Benjamin LaHaise <bcrl@kvack.org> Signed-off-by:
-
Andrew Morton authored
With CONFIG_REISERFS_FS_XATTR=y, CONFIG_REISERFS_FS_POSIX_ACL=n: fs/reiserfs/xattr.c: In function `reiserfs_check_acl': fs/reiserfs/xattr.c:1330: called object is not a function Cc: Chris Mason <mason@suse.com> Cc: Jeff Mahoney <jeffm@suse.com> Signed-off-by:
-
Hugh Dickins authored
dump_stack() on page allocation failure presently has an irritating habit of shouting just "====" at everyone: please stop it. Signed-off-by:
Hugh Dickins <hugh@veritas.com> Signed-off-by:
-
Stephen Smalley authored
Make SELinux depend on SECURITY_NETWORK (which depends on SECURITY), as it requires the socket hooks for proper operation even in the local case. Signed-off-by:
Stephen Smalley <sds@tycho.nsa.gov> Acked-by:
James Morris <jmorris@namei.org> Signed-off-by:
-
Dave Jones authored
It may suck something awful, but it shouldn't taint the kernel. Signed-off-by:
Dave Jones <davej@redhat.com> Signed-off-by:
-
Phillip Susi authored
The pktcdvd driver uses a compile time macro constant to define the maximum supported packet length. I changed this from 32 sectors to 128 sectors because that allows over 100 MB of additional usable space on a 700 MB cdrw, and increases throughput. Note that you need a modified cdrwtool program that can format a CDRW disc with larger packets to benefit from this change. Signed-off-by:
Peter Osterlund <petero2@telia.com> Signed-off-by:
-
Peter Osterlund authored
Allocate memory for read-gathering at open time, when it is known just how much memory is needed. This avoids wasting kernel memory when the real packet size is smaller than the maximum packet size supported by the driver. This is always the case when using DVD discs. Signed-off-by:
-
Adrian Bunk authored
Unless the help text is outdated, this seems to be logical. Signed-off-by:
-
Peter Osterlund authored
The version information is not useful for a driver that is maintained in Linus' kernel tree. Signed-off-by:
-
Phillip Susi authored
The pktcdvd driver was using an 8 bit field to store the packet length obtained from the disc track info. This causes it to overflow packet length values of 128KB or more. I changed the field to 32 bits to fix this. The pktcdvd driver defaulted to its maximum allowed packet length when it detected a 0 in the track info field. I changed this to fail the operation and refuse to access the media. This seems more sane than attempting to access it with a value that almost certainly will not work. Signed-off-by:
-
Chuck Ebbert authored
migration_cost prints after every CPU hotplug event. Make it print only once at boot. Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Stephen Smalley authored
Update my contact info. Please apply. Signed-off-by:
-
Miklos Szeredi authored
The last fix for this function in fact opened up a much more often triggering race. It was uncommented tricky code, that was buggy. Add comment, make it less tricky and fix bug. Signed-off-by:
Miklos Szeredi <miklos@szeredi.hu> Signed-off-by:
-
Markus Lidel authored
Fix http://bugzilla.kernel.org/show_bug.cgi?id=5923 When a scsi command failed, an oops would result. Back-to-back SMART queries would make the Seagate drives unhappy. The second SMART query would timeout, and the command would be aborted. Acked-by:
Markus Lidel <Markus.Lidel@shadowconnect.com> Cc: Kenny Simpson <theonetruekenny@yahoo.com> Cc: <stable@kernel.org> Signed-off-by:
-
Tejun Heo authored
q->ordcolor must not be flipped on SOFTBARRIER. Signed-off-by:
Tejun Heo <htejun@gmail.com> Acked-by:
Jens Axboe <axboe@suse.de> Signed-off-by:
-
Jens Axboe authored
Previously, if a fs request which was being drained failed and got requeued, blk_do_ordered() didn't allow it to be reissued, which causes queue stall. This patch makes blk_do_ordered() use the sequence of each request to determine whether a request can be issued or not. This fixes the bug and simplifies code. Signed-off-by:
-
Eric Dumazet authored
percpu_data blindly allocates bootmem memory to store NR_CPUS instances of cpudata, instead of allocating memory only for possible cpus. As a preparation for changing that, we need to convert various 0 -> NR_CPUS loops to use for_each_cpu(). (The above only applies to users of asm-generic/percpu.h. powerpc has gone it alone and is presently only allocating memory for present CPUs, so it's currently corrupting memory). Signed-off-by:
Eric Dumazet <dada1@cosmosbay.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: James Bottomley <James.Bottomley@steeleye.com> Acked-by:
-
Linus Torvalds authored
This reverts commit 10f4dc8b. Quoth Andi Kleen: "Kiran decided that it makes the problem worse than it was before. Fixing it fully requires more work which is too much for 2.6.16. So please revert that commit for now." Signed-off-by:
-
David S. Miller authored
Signed-off-by:
-
