- 05 Jun, 2004 40 commits
-
-
Jens Axboe authored
Lets just remove it. It's been disabled some time ago, and there's no chance of it ever getting resurrected. PATA TCQ has so many technical short comings, that it was never really interesting I'm afraid. Signed-off-by:
Jens Axboe <axboe@suse.de> Signed-off-by:
Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Bartlomiej Zolnierkiewicz authored
Remove dead code from task_in_intr() and pre_task_mulout_intr() (CONFIG_IDE_TASKFILE_IO=n versions). Signed-off-by:
Bartlomiej Zolnierkiewicz <bzolnier@elka.pw.edu.pl> Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
- move common code to ide_do_rw_disk() (+ always print block number and rq->buffer) - use pr_debug() Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
Remove needless exports from ide.c, ide-probe.c and ide-proc.c. Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
From: Christoph Hellwig <hch@lst.de> To be useful for distribution kernels it needs to be a runtime option. The original patch is from Joerg Platte via the Debian kernel package, with some adjustments from me (and me too - Bart). Signed-off-by:
-
bk://kernel.bkbits.net/davem/sparc-2.6Linus Torvalds authored
into ppc970.osdl.org:/home/torvalds/v2.6/linux
-
http://lia64.bkbits.net/to-linus-2.5Linus Torvalds authored
into ppc970.osdl.org:/home/torvalds/v2.6/linux
-
-
Corey Minyard authored
Geert Uytterhoeven wrote: While compiling drivers/char/ipmi/ipmi_si_intf.c in 2.6.6-rc1 on m68k, I noticed a missing include (needed for disable_irq_nosync() and enable_irq()): Furthermore none of CONFIG_ACPI_INTERPETER, CONFIG_X86, and CONFIG_PCI were set, and thus IPMI_MEM_ADDR_SPACE and IPMI_IO_ADDR_SPACE are not defined, but they are used. Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
-
Dave Airlie authored
Adds support to the jedec probe for ST M50FW040, M50FW080 and M50FW016 all Firmware hubs for i8x0 chipsets, http://www.st.com/stonline/products/families/memories/fl_nor/fl_fwh.htm Cc: David Woodhouse <dwmw2@infradead.org> Signed-off-by:
-
Corey Minyard authored
Presently we get procfs warnings from ipmi_si.ko due to its failing to remove all of a /proc directory's contents prior to removing that directory. This patch tracks all proc entries for an IPMI interface and unregisters them all upon removal. Signed-off-by:
-
Benjamin Herrenschmidt authored
From: Colin Leroy <colin@colino.net> Paulus brought this up on IRC, it seems to be a bad DRM merge: The code #ifndef VMAP_4_ARGS if ( dev->agp->cant_use_aperture ) return -EINVAL; #endif in DRM(agp_acquire) should be removed altogether in a 2.6 kernel because its vmap() takes 4 arguments; however, only the guards seem to have been removed, which causes this function to erroneously fail if the AGP aperture can't be directly accessed by the CPU. Signed-off-by:Colin Leroy <colin@colino.net> Signed-off-by:
-
Benjamin Herrenschmidt authored
The attached patch fixes the EDID parsing for PPC on rivafb. It actually finds the EDID info in the OF Tree now. I grabbed this from BenHs Tree as of 2.6.5-rc3. The current code has no chance to work since it doesn't walk the device tree. This helps rivafb on PPC at least a bit further... Signed-off-by:
Guido Guenther <agx@sigxcpu.org> Signed-off-by:
-
Nick Piggin authored
David Mosberger noticed bw_pipe was way down on sched-domains kernels on SMP systems. That is due to two things: first, the previous wake-affine logic would *always* move a pipe wakee onto the waker's CPU. With the scheduler rework, this was toned down a lot (but extended to all types of wakeups). One of the ways this was damped was with the logic: don't move the wakee if its CPU is relatively idle compared to the waker's CPU. Without this, some workloads would pile everything up onto a few CPUs and get lots of idle time. However, the fix was a bit of a blunt hack: if the wakee runqueue was below 50% busy, and the waker's was above 50% busy, we wouldn't do the move. I think a better way to capture it is what this patch does: if the wakee runqueue is below 100% busy, and the sum of the two runqueue's loads is above 100% busy, and the wakee runqueue is less busy than the waker runqueue (ie. CPU utilisation would drop if we do the move), then we don't do the move. After I fixed this, I found things were still getting bounced around quite a bit. The reason is that we were attempting very aggressive idle balancing in order to cut down idle time in a dbt2-pgsql workload, which is particularly sensitive to idle. After having Mark Wong (markw@osdl.org) retest this load with this patch, it looks like we don't need to be so aggressive. I'm glad to be rid of this because it never sat too well with me. We should see slightly lower cost of schedule and slightly improved cache impact with this change too. Mark said: --- This looks pretty good: metric kernel 2334 2.6.7-rc2 2298 2.6.7-rc2-mm2 2329 2.6.7-rc2-mm2-sched-more-wakeaffine --- ie. within the noise. David said: --- Oooh, me likeee! Host OS Pipe AF UNIX --------- ------------- ---- ---- caldera.h Linux 2.6.6 3424 2057 (plain 2.6.6) caldera.h Linux 2.6.7-r 333. 1402 (original 2.6.7-rc1) caldera.h Linux 2.6.7-r 3086 4301 (2.6.7-rc1 with your patch) Pipe-bandwidth is still down about 10% but that may be due to unrelated changes (or perhaps warmup effects?). The AF UNIX bandwidth is just mindboggling. Moreover, with your patch 2.6.7-rc1 shows better context-switch times and lower communication latencies (more like the numbers you're getting on UP). So it seems like the overall balance of keeping things on the same CPU vs. distributing them across CPUs is improved. --- I also ran some tests on the NUMAQ. kernbench, dbench, hackbench, reaim were much the same. tbench was improved, very much so when clients < NR_CPU. Signed-off-by:Nick Piggin <nickpiggin@yahoo.com.au> Signed-off-by:
-
Neil Brown authored
This condtion on this loop is primarily to avoid the loop if it doesn't appear to be needed. However it optimises a little too much and there is a case where it skips the loop when it is really needed. This patch fixes it. Signed-off-by:
Neil Brown <neilb@cse.unsw.edu.au> Signed-off-by:
-
Jens Axboe authored
There's a bad length check in cdrom_get_random_writable(), it's off-by-4 since fh->data_len is the length of data _after_ that field (which is offset 4 bytes in the header). Check is pretty bogus anyways, so just kill it. Signed-Off-By:
-
Paul Fulghum authored
* Fix cleanup on driver init failure (call pci_unregister_driver if necessary) * Keep driver loaded if no hardware found (for dynid support) Signed-off-by:
-
Paul Fulghum authored
* Fix cleanup on driver init failure Signed-off-by:
-
Paul Fulghum authored
* Fix cleanup on driver init failure (call pci_unregister_driver if necessary) * Keep driver loaded if no hardware found (for dynid support) Signed-off-by:
-
Kevin Corry authored
dm-ioctl.c: Use a size_t* instead of an int* in list_version_get_needed(). size_t and int are not the same size on all architectures. Signed-off-by:
-
Andrew Morton authored
fs/nfs/direct.c: In function `nfs_file_direct_write': fs/nfs/direct.c:549: warning: initialization discards qualifiers from pointer target type Signed-off-by:
-
Rusty Russell authored
As pointed out by Paul Jackson <pj@sgi.com>, sometimes 99 chars is not enough. We currently get a page from sysfs: that code should check we haven't overrun it. Signed-off-by:
Rusty Russell <rusty@rustcorp.com.au> Signed-off-by:
Paul Jackson <pj@sgi.com> Signed-off-by:
-
Andi Kleen authored
Often users only report what syslogd reports with KERN_ALERT when a kernel crash occurs. Make an oops print mpre information with that (in particular the RIP) Patch for i386 and x86-64. Signed-off-by:
-
Neil Brown authored
This allows the number of "raid_disks" in a raid1 to be changed. This requires allocating a new pool of "r1bio" structures which a different number of bios, suspending IO, and swapping the new pool in place of the old. (and a few other related changes). Signed-off-by:
-
Neil Brown authored
It is possible to have raid1/4/5/6 arrays that do not use all the space on the drive. This can be done explicitly, or can happen info you, one by one, replace all the drives with larger devices. This patch extends the "SET_ARRAY_INFO" ioctl (which previously invalid on active arrays) allow some attributes of the array to be changed and implements changing of the "size" attribute. "size" is the amount of each device that is actually used. If "size" is increased, the new space will immediately be "resynced". Signed-off-by:
-
Neil Brown authored
If raid1 decides it needs to resync it will do so even if there is only one working device. This is pointless. With this patch we abort resync if there is nowhere to write to. Signed-off-by:
-
Neil Brown authored
If the superblock isn't persistent, we shouldn't allow room for it. From: Paul Clements <Paul.Clements@SteelEye.com> Signed-off-by:
-
Neil Brown authored
Normally the size is chosen as a multiple of the chunk size, but if the size is explicitly chosen, it might not be. So we force it. Signed-off-by:
-
Neil Brown authored
This isn't really needed at the moment, but it is more consistant with the interface and may be needed later. Signed-off-by:
-
Neil Brown authored
md_check_recovery only locks a device and does stuff when it thinks there is a real likelyhood that something needs doing. So the test at the top must cover all possibilities. But it didn't cover the possibility that the last outstanding request on a failed device had finished and so the device needed to be removed. As a result, a failed drive might not get removed from the personalities perspective on the array, and so it could never be removed from the array as a whole. With this patch, whenever ->nr_pending hits zero on a faulty device, MD_RECOVERY_NEEDED is set so that md_check_recovery will do stuff. Signed-off-by:
-
Neil Brown authored
md/multipath has two separate pieces of code for choosing a device to use, one when a request is first made and the other when a request is being re-tried after failure. This patch discards multipath_read_balance and uses multipath_map in both situations. Signed-off-by:
-
Neil Brown authored
Fix minor typos. From: "J. Bruce Fields" <bfields@fieldses.org> Signed-off-by:
-
Neil Brown authored
Fix error return in create. (See comment in xdr for createtype4 at end of rfc3530.) From: Andy Adamson <andros@citi.umich.edu> From: "J. Bruce Fields" <bfields@fieldses.org> Signed-off-by:
-
Neil Brown authored
Fix a somewhat bizarre corner case in clid processing: a clientid match isn't required for case 3. From: Andy Adamson <andros@citi.umich.edu> From: "J. Bruce Fields" <bfields@fieldses.org> Signed-off-by:
-
Neil Brown authored
Oops: we were claiming to support the TIME_CREATE attribute, when we don't really. From: Andy Adamson <andros@citi.umich.edu> From: "J. Bruce Fields" <bfields@fieldses.org> Signed-off-by:
-
Neil Brown authored
Fix oops in release_lockowner. We need to break out to two loops, not just one, and if the loop finds nothing, 'local' won't be NULL. So just put the body of the 'if' inside the loop. From: Andy Adamson <andros@citi.umich.edu> From: "J. Bruce Fields" <bfields@fieldses.org> Signed-off-by:
-
Neil Brown authored
rsc_lookup is a bit complicated: it either takes responsibility for the memory pointed to by handle.data and sets handle.data to NULL, or it leaves handle.data unchanged, in which case the caller is responsible for freeing handle.data. I forgot that the possibility of inserting a negative cache entry into the cache meant that this could happen even when rsc_lookup is called with set == 0. Note that the ip_map code has the same bug, not that it seems to matter much, since the memory in question in that case is always just a statically allocated string. From: "J. Bruce Fields" <bfields@fieldses.org> Signed-off-by:
-
Neil Brown authored
The server sunrpc code should take a reference on the relevant module before calling any authentication code. Also, it looks to me like the table of authops needs some locking. Finally, gss_svc_init wasn't checking the status of svc_auth_register, and gss_svc_shutdown wasn't calling svc_auth_unregister. From: "J. Bruce Fields" <bfields@fieldses.org> Signed-off-by:
-
