An error occurred fetching the project authors.
- 02 Aug, 2004 23 commits
-
-
Christoph Hellwig authored
Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Christoph Hellwig authored
ACKed by the pmac folks a while ago. Also moves the Kconfig entry to where it belongs. Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Alan Cox authored
Revert the recent fdomain_cs config dependency "fix" and fix the linkage error with ifdeffery instead. Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Maciej W. Rozycki authored
Maciej has moved. Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Bjorn Helgaas authored
The "vector" terminology is architecture-dependent. The PCI MSI interface actually deals with Linux IRQ numbers (i.e., things you can pass to request_irq()), and we shouldn't confuse things by calling them "vectors" just because we're using MSI rather than an IOSAPIC. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Roland Dreier authored
Second half of MSI rewrite: fix the API and update documentation. Split enabling MSI and MSI-X to separate pci_enable_msi()/pci_disable_msi() and pci_enable_msix()/pci_disable_msix() functions. free_irq() no longer has the side effect of freeing interrupt vectors (so a device driver can do multiple request_irq()/free_irq() cycles on the same MSI/MSI_X vector). From: Tom L. Nguyen <tom.l.nguyen@intel.com> Signed-off-by: Roland Dreier <roland@topspin.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Roland Dreier authored
First half of the MSI rewrite: pure cleanup. Use proper pci_read_config_xxx() and pci_write_config_xxx() functions instead of accessing raw dev->bus->ops. Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Jesse Barnes authored
On a system with a lot of nodes, 4 lines of output per node is a lot to have to sit through as the system comes up, especially if you're on the other end of a slow serial link. The information is valuable though, so keep it around for the system logger. This patch makes the printks for the memory stats use KERN_DEBUG instead of the default loglevel. Signed-off-by: Jesse Barnes <jbarnes@sgi.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Alexey Dobriyan authored
Fix menuconfig inability to show help texts when there is menu item with letter "H" highlighted on the screen. Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Andrew Morton authored
Change the oom-killer so that it spits a sysrq-m output into the logs, and shows the gfp_mask of the failing allocation attempt. Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Kumar Gala authored
The following patch adds completes the CPU support for the MPC8555 PowerPC. Additionally, it adds support for the MPC8555 CDS reference board. This is another PowerPC in the Freescale MPC85xx family. * Add support for MPC8555 CPU and reference board Signed-off-by: Kumar Gala <kumar.gala@freescale.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Kumar Gala authored
The following patch adds completes the CPU support for the MPC8560 PowerPC. Additionally, it adds support for the MPC8560 ADS reference board and fixes up some build issues with the SBC8560 board. Signed-off-by: Kumar Gala <kumar.gala@freescale.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
David Gibson authored
This patch removes a redundant #include of processor.h from arch/ppc64/boot/div64.S. I came across this because, at least with the binutils versions I have currently installed, the 32-bit assembler used for the bootstrap code objects to the // comments that recently went into processor.h. Signed-off-by: David Gibson <dwg@au.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Paul Mackerras authored
Rewrite/cleanup of the SLB management code. This removes nearly all the SLB related code from arch/ppc64/kernel/stab.c and puts a rewritten version in arch/ppc64/mm, where it better belongs. The main SLB miss path is in assembler and the other routines have been cleaned up and streamlined. Notable changes: - Ugly bitfields no longer used for generating SLB entries. - slb_allocate() (the main SLB miss routine) is now in assembler, and all the data it uses is stored in the PACA. - The mm context is now copied into the PACA at context switch time, to avoid looking up the thread struct on SLB miss. - An SLB miss will now never (directly) result in a call to do_page_fault. If we get a miss on a totally bogus address the handler will now put in an SLB referencing VSID 0. This will never have any pages, so we'll get the (fatal) page fault shortly afterwards. This simplifies the SLB entry and exit paths. - The round-robin pointer in the PACA now references the last-used instead of next-to-use SLB slot, which simplifies the asm for updating it slightly. - Unify do_slb_bolted with the general SLB miss path. There is now one SLB miss handler, in assembler, and called with only the low-level exception prolog (EXCEPTION_PROLOG_[PI]SERIES rather than EXCEPTION_PROLOG_COMMON) and minimal extra save/restore logic. - Streamlines the exception entry/exit path of the SLB miss handler to shave a few cycles off. The most significant change is that the RI bit is left off throughout the whole handler, which avoids an extra mtmsrd to turn it back off on the exit path. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Paul Mackerras <paulus@samba.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Srivatsa Vaddagiri authored
Patch below fixes a cpu_up race in PPC64. Signed-off-by: Srivatsa Vaddagiri <vatsa@in.ibm.com> Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Anton Blanchard authored
In migrate_irqs_away we werent converting a virtual irq to a real one. We ended up passing the wrong irq numbers to the hypervisor and migration of affinitised irqs on cpu hot unplug didnt work. Also clarify the rtas_stop_self printk. Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
David Gibson authored
Both arch/ppc64/kernel/ras.c and arch/ppc64/kernel/rtasd.c have a spinlock variable declared static called "log_lock". Since the code in these files interact quit a lot, having two different locks with identical names is manifestly confusing. This patch renames both locks to something a little clearer. In the case of ras.c it also renames the buffer protected by the lock to a more usefullly greppable name. Signed-off-by: David Gibson <dwg@au.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Paul Mackerras authored
Moves a misplaced of_node_put(). In the existing code, the node in question is used just after its refcount is decremented. Signed-off-by: John Rose <johnrose@austin.ibm.com> Signed-off-by: Paul Mackerras <paulus@samba.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
John Rose authored
The patch below removes the unused member "pci_io_offset" from struct pci_controller. If there are no problems, please apply. Signed-off-by: John Rose <johnrose@austin.ibm.com> Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Dave Hansen authored
lmb_end_of_DRAM() returns the address of the end of RAM, not the starting address of the last page. We've been accessing mem_map[] out of bounds for quite a while. But, it's just a read, so it's probably never caused a real problem. But, during my port of CONFIG_NONLINEAR to ppc64, I have a check to make sure that all __va() calls are given with valid physical addresses. This code tripped that check. Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Dave Hansen authored
arch/ppc64/kernel/prom.c: In function `__make_room': arch/ppc64/kernel/prom.c:1415: warning: unused variable `offset' Signed-off-by: Dave Hansen <haveblue@us.ibm.com> Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Tim Schmielau authored
BSD accounting cross-platform compatibility is a new feature of 2.6.8 and thus not crucial, but it'd be nice not to have kernels writing wrong file formats out in the wild. The endianness detection logic I wanted to suppose for userspace turned out to be bogus. So just do it the simple way and store endianness info together with the version number. Signed-off-by: Tim Schmielau <tim@physik3.uni-rostock.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Anton Blanchard authored
The per cpu schedule counters need to be summed up over all possible cpus. When testing hotplug cpu remove I saw the sum of the online cpu count for nr_uninterruptible go negative which made the load average go nuts. Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
- 01 Aug, 2004 6 commits
-
-
Benjamin Herrenschmidt authored
The latest versions of Motorola erratas for the MPC745x CPUs (and 744x) adds a couple of nasty ones for which we really want workarounds in the kernel. One is to disable the BTIC branch target cache on some revs (too bad for performances...) and the other one is to force cacheable memory pages to always be marked as SMP coherent even on UP systems (I didn't measure significant perfs impact with this one). Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
bk://kernel.bkbits.net/davem/tg3-2.6Linus Torvalds authored
into ppc970.osdl.org:/home/torvalds/v2.6/linux
-
David S. Miller authored
-
bk://gkernel.bkbits.net/net-drivers-2.6Linus Torvalds authored
into ppc970.osdl.org:/home/torvalds/v2.6/linux
-
Chris Wright authored
If regs.len is smaller than reglen it's possible to copy more bytes out than the user asked for. Signed-off-by: Chris Wright <chrisw@osdl.org>
-
bk://kernel.bkbits.net/davem/net-2.6Linus Torvalds authored
into ppc970.osdl.org:/home/torvalds/v2.6/linux
-
- 31 Jul, 2004 11 commits
-
-
James Morris authored
Below is an updated version of patch from Fruhwirth which integrates the Gladman AES code into the crypto API. I've tried to ensure that this is done as simply as possible: the user gets the asm version by default if it's suitable. I've also now added the alternate GPL licensing provided by Brian Gladman, and licensed the code as GPL. Signed-off-by: James Morris <jmorris@redhat.com> Signed-off-by: David S. Miller <davem@redhat.com>
-
Bert Hubert authored
The missing break causes the packet to be tested against both encapsulation types, one will always fail. Signed-off-by: bert hubert <ahu@ds9a.nl> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@redhat.com>
-
Herbert Xu authored
I'm looking through the xfrm_alloc_spi stuff and noticed that the netlink alloc_spi function takes the range in host order while the PFKEY alloc_spi function takes them in network order. First I thought that I stuffed up since I was the one who changed the code in the netlink interface to take them in host order :) But reading RFC 2367 seems to indicate otherwise. It says that all fields are host order unless specified otherwise. And the spirange fields are not specified to be network order at all. Looking at the existing PFKEY users: User Space ---------- Openswan - Doesn't use PFKEY for this. Racoon - Puts zeros in there so it doesn't care. However its test-pfkey program stores things in host order. ISAKMPD - Stores things in host order. So the conclusion is that we can and should change our PFKEY implementation to use host order for these fields. This patch does exactly that. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@redhat.com>
-
Herbert Xu authored
xfrm_alloc_spi will always succeed if minspi < maxspi, even if minspi + 1 == maxspi. If the range is already occupied this will obviously lead to breakage. Of course this is very unlikely to occur in reality due to the size of the range. Although with IPCOMP it might actually happen on a very large server. The fix is obivous. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@redhat.com>
-
Herbert Xu authored
This is the patch referred to in the netlink_get_spi thread. I was actually wrong about the reason for this patch though. Firstly it's the SPI check that is redundant and not the find_acq() call. And it's redundant because of the find_acq() patch, not because of the fact that this is in xfrm_state_add(). Now that find_acq() only returns SAs with SPIs, we don't need to check this in xfrm_state_add() anymore. We do still need the call though to clean up leftover larval states. Another side-effect of the change is that we can move the existence check above find_acq() since find_acq() will never return any SAs matching the SPI we're trying to add (It doesn't need to because if an SA with a matching SPI existed, it would've been returned by state_lookup() already). Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@redhat.com>
-
Herbert Xu authored
The issue is that two successive calls to netlink_get_spi is returning the same SA. Since netlink_get_spi is meant to be a creation operation this is incorrect. The netlink_get_spi operation is modelled off the PFKEY SADB_GETSPI command which is specified in RFC 2367. The purpose of SADB_GETSPI is to create a new larval SA that can then be filled in by SADB_UPDATE. Its semantics does not allow two SADB_GETSPI calls to return the same SA, even if there is no SADB_UPDATE call in between. The reason the second netlink_get_spi is returning the same SA is because in find_acq(), the code is looking at all larval states as opposed to only larval states with an SPI of zero. Since the only other caller of find_acq() -- xfrm_state_add() intentionally ignores all return values with a non-zero SPI, it is safe to not look at SAs with non-zero SPIs at all in find_acq(). The following patch does exactly that. In fact, the find_acq() call in xfrm_state_add() is a remnant from the days when we had xfrm_state_replace() instead of xfrm_state_add() and xfrm_state_update(). It can now be safely removed. I'll post a separate patch for that. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@redhat.com>
-
http://linux-mh.bkbits.net/bluetooth-2.6David S. Miller authored
into nuts.davemloft.net:/disk1/BK/net-2.6
-
Marcel Holtmann authored
The problem is that after a successful connection between the Windows Bluetooth stack and the Linux Bluez stack, no packets from the device ever reach the PC running Windows XP Service Pack 2. That is, a ping from the PC never receives a response, and a ping from BlueZ never reaches the PC. Linux packet statistics show that the PC packets are received, but all return traffic seems to be routed over the loopback interface. Immediately after creating the BNEP connection with BlueZ, the Windows Bluetooth stack sends a BNEP_FILTER_NET_TYPE_SET_MSG with an effective length of zero. BlueZ interprets this message to mean that no filter ranges should be allowed. The code zeros the first entry in the filter list, which is than interpreted as meaning that no ranges of acceptable packets are available. This interpretation is wrong and leads to all packets being rejected by BNEP. The Bluetooth BNEP specification clearly states the following: The length (in octets) of this message is 4+4*N, where N is the number of disjoint ranges of Networking protocol types that form the complete set. Note that N=0 (empty set) denotes a reset to default filters (if any) supported by the remote device. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
David S. Miller authored
into nuts.davemloft.net:/disk1/BK/net-2.6
-
Marcel Holtmann authored
For the USB dongles from ISSC the first command must be a HCI_Reset, because otherwise the inquiry procedures won't work. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
bk://cifs.bkbits.net/linux-2.5cifsLinus Torvalds authored
into ppc970.osdl.org:/home/torvalds/v2.6/linux
-