- 11 Nov, 2005 40 commits
-
-
Hironobu Ishii authored
Part of a patch was accidentally reverted, this corrects an inconsistent spinlock use in the IPMI message handler. Signed-off-by: Hironobu Ishii <hishii@soft.fujitsu.com> Signed-off-by: Corey Minyard <minyard@acm.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Linus Torvalds authored
-
Jeff Garzik authored
Recent TCP changes broke the build. Signed-off-by: Jeff Garzik <jgarzik@pobox.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Dmitry Torokhov authored
Signed-off-by: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Paul Mackerras authored
We needed the VDSO symbols in the arch/ppc asm-offsets.c, and there were a few usages of _systemcfg still left lying around. Signed-off-by: Paul Mackerras <paulus@samba.org>
-
Paul Mackerras authored
When we created the instructions to read/write SPRs in xmon, we were setting up a ppc64-style procedure descriptor and calling that, which doesn't work in 32-bit. For 32-bit a function pointer just points to the instructions of the function. This fixes it to do the right thing for both 32-bit and 64-bit. Signed-off-by: Paul Mackerras <paulus@samba.org>
-
Paul Mackerras authored
32-bit SMP powermacs weren't booting with ARCH=powerpc because the boot cpu wasn't saving away the state of various control registers, but the secondary CPUs were loading them from the uninitialized state. This adds the necessary save-state call. Signed-off-by: Paul Mackerras <paulus@samba.org>
-
Benjamin Herrenschmidt authored
This patch moves the vdso's to arch/powerpc, adds support for the 32 bits vdso to the 32 bits kernel, rename systemcfg (finally !), and adds some new (still untested) routines to both vdso's: clock_gettime() with support for CLOCK_REALTIME and CLOCK_MONOTONIC, clock_getres() (same clocks) and get_tbfreq() for glibc to retreive the timebase frequency. Tom,Steve: The implementation of get_tbfreq() I've done for 32 bits returns a long long (r3, r4) not a long. This is such that if we ever add support for >4Ghz timebases on ppc32, the userland interface won't have to change. I have tested gettimeofday() using some glibc patches in both ppc32 and ppc64 kernels using 32 bits userland (I haven't had a chance to test a 64 bits userland yet, but the implementation didn't change and was tested earlier). I haven't tested yet the new functions. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
-
David Woodhouse authored
This removes a stray debugging printk which offended Anton. Signed-off-by: David Woodhouse <dwmw2@infradead.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
-
David Gibson authored
Since the udbg code in ppc64 has no ppc32 equivalent, move it straight over into arch/powerpc (and include/asm-powerpc for udbg.h). In time, we probably want to meld the various bits and pieces of 32-bit early debugging code into udbg, but for now only include it on CONFIG_PPC64=y builds. The only change during the move is to standardise the protecting #ifdef/#define in udbg.h, and move its banner comment above the initial #ifdef (which seems to be normal practice). Built and booted on POWER5 LPAR (ARCH=powerpc and ARCH=ppc64). Built for 32bit multiplatform (ARCH=powerpc). Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Paul Mackerras <paulus@samba.org>
-
Anton Blanchard authored
The definitions in sparsemem.h arent sufficient. We currently sell machines with 2TB of RAM, and in order to give us room for a few years growth lets set it to 16TB. Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
-
Anton Blanchard authored
Convert to sparsemem and remove all the discontigmem code in the process. This has a few advantages: - The old numa_memory_lookup_table can go away - All the arch specific discontigmem magic can go away We also remove the triple pass of memory properties and instead create a list of per node extents that we iterate through. A final cleanup would be to change our lmb code to store extents per node, then we can reuse that information in the numa code. Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
-
Anton Blanchard authored
Remove ppc64 specific version of nr_cpus_node and use the generic one provided. Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
-
Anton Blanchard authored
Remove an unused numa define and move a discontigmem specific define inside the relevant ifdef. I will submit a separate patch to remove them from other architectures, but the ppc64 patches to follow depend on this. Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
-
Anton Blanchard authored
The kprobes code is doing ".previous .text". While the assembler doesnt warn at the moment (and it seems to work), it might in the future. Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
-
Anton Blanchard authored
We have been printing the raw ppc64_firmware_features during boot. Since we can work it out from the device tree, lets remove it. Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
-
Anton Blanchard authored
If we dont have permission to read some information from the hypervisor, lparcfg outputs a warning on the console. Now that lparcfg is world readable this is a problem. Dont warn in the case of H_Authority, remove some unnecessary function prototypes and fix whitespace damage in a structure as well. Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
-
Kumar Gala authored
The bit position in the status register corresponding to the PCI DMA interrupt was incorrect. Additionally, we did not have a define for the PCI DMA interrupt. Signed-off-by: Kumar Gala <galak@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
-
-
Jeff Garzik authored
Current upstream 'allmodconfig' build is broken. This is the obvious patch... Signed-off-by: Jeff Garzik <jgarzik@pobox.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Linus Torvalds authored
-
Andrew Morton authored
Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Steve French authored
Signed-off-by: Steve French <sfrench@us.ibm.com>
-
Steve French authored
Signed-off-by: Steve French <sfrench@us.ibm.com>
-
Steve French authored
-
Steve French authored
Signed-off-by: Steve French <sfrench@us.ibm.com>
-
Stephen Hemminger authored
Use "hints" to speed up the SACK processing. Various forms of this have been used by TCP developers (Web100, STCP, BIC) to avoid the 2x linear search of outstanding segments. Signed-off-by: Stephen Hemminger <shemminger@osdl.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Stephen Hemminger authored
Minor spelling fixes for TCP code. Signed-off-by: Stephen Hemminger <shemminger@osdl.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
John Heffner authored
This is a patch for discussion addressing some receive buffer growing issues. This is partially related to the thread "Possible BUG in IPv4 TCP window handling..." last week. Specifically it addresses the problem of an interaction between rcvbuf moderation (receiver autotuning) and rcv_ssthresh. The problem occurs when sending small packets to a receiver with a larger MTU. (A very common case I have is a host with a 1500 byte MTU sending to a host with a 9k MTU.) In such a case, the rcv_ssthresh code is targeting a window size corresponding to filling up the current rcvbuf, not taking into account that the new rcvbuf moderation may increase the rcvbuf size. One hunk makes rcv_ssthresh use tcp_rmem[2] as the size target rather than rcvbuf. The other changes the behavior when it overflows its memory bounds with in-order data so that it tries to grow rcvbuf (the same as with out-of-order data). These changes should help my problem of mixed MTUs, and should also help the case from last week's thread I think. (In both cases though you still need tcp_rmem[2] to be set much larger than the TCP window.) One question is if this is too aggressive at trying to increase rcvbuf if it's under memory stress. Orignally-from: John Heffner <jheffner@psc.edu> Signed-off-by: Stephen Hemminger <shemminger@osdl.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Stephen Hemminger authored
This is an updated version of the RFC3465 ABC patch originally for Linux 2.6.11-rc4 by Yee-Ting Li. ABC is a way of counting bytes ack'd rather than packets when updating congestion control. The orignal ABC described in the RFC applied to a Reno style algorithm. For advanced congestion control there is little change after leaving slow start. Signed-off-by: Stephen Hemminger <shemminger@osdl.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Stephen Hemminger authored
Move all the code that does linear TCP slowstart to one inline function to ease later patch to add ABC support. Signed-off-by: Stephen Hemminger <shemminger@osdl.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Stephen Hemminger authored
Simplify the code that comuputes microsecond rtt estimate used by TCP Vegas. Move the callback out of the RTT sampler and into the end of the ack cleanup. Signed-off-by: Stephen Hemminger <shemminger@osdl.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Stephen Hemminger authored
TCP peformance with TSO over networks with delay is awful. On a 100Mbit link with 150ms delay, we get 4Mbits/sec with TSO and 50Mbits/sec without TSO. The problem is with TSO, we intentionally do not keep the maximum number of packets in flight to fill the window, we hold out to until we can send a MSS chunk. But, we also don't update the congestion window unless we have filled, as per RFC2861. This patch replaces the check for the congestion window being full with something smarter that accounts for TSO. Signed-off-by: Stephen Hemminger <shemminger@osdl.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jesse Barnes authored
After much testing and agony, I've discovered that my previous ohci1394 quirk for Toshiba laptops is not 100% reliable. It apparently fails to do the interrupt line change either correctly or in time, since in about 2 out of 5 boots, the kernel's irqdebug code will *still* disable irq 11 when the ohci1394 driver is loaded (at pci_enable_device time I think). This patch switches things around a little in the workaround. First, it removes the mdelay. I didn't see a need for it and my testing has shown that it's not necessary for the quirk to work. Secondly, instead of trying to change the interrupt line to what ACPI tells us it should be, this patch makes the quirk use the value in the PCI_INTERRUPT_LINE register. On this laptop at least, that seems to be the right thing to do, though additional testing on other laptops and/or with actual firewire devices would be appreciated. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Rajesh Shah authored
Signed-off-by: Rajesh Shah <rajesh.shah@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Ashok Raj authored
MSI hardcoded delivery mode to use logical delivery mode. Recently x86_64 moved to use physical mode addressing to support physflat mode. With this mode enabled noticed that my eth with MSI werent working. msi_address_init() was hardcoded to use logical mode for i386 and x86_64. So when we switch to use physical mode, things stopped working. Since anyway we dont use lowest priority delivery with MSI, its always directed to just a single CPU. Its safe and simpler to use physical mode always, even when we use logical delivery mode for IPI's or other ioapic RTE's. Signed-off-by: Ashok Raj <ashok.raj@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Adrian Bunk authored
This patch contains the following cleanups: - access.c should #include "pci.h" for getting the prototypes of it's global functions - hotplug/shpchp_pci.c: make the needlessly global function program_fw_provided_values() static Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Grant Coady authored
pci_ids cleanup: fixup bt87x.c: two macro defined IDs missed in prior cleanup. Caught by Chun-Chung Chen <cjj@u.washington.edu>: "In the patch for bt87x.c, you seemed have missed the two occurrences of BT_DEVICE on line 897 and line 898." Signed-off-by: Grant Coady <gcoady@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
John Rose authored
This patch contains the driver bits for enabling DLPAR and PCI Hotplug for the new OF-based PCI probe. This functionality was regressed when the new PCI approach was introduced. Please apply if appropriate. Signed-off-by: John Rose <johnrose@austin.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-