- 01 Apr, 2004 6 commits
-
-
Andrew Morton authored
From: Marcus Meissner <meissner@suse.de> After discussion on the glibc list the result was that=20 si_band is "long int" according to POSIX: http://www.opengroup.org/onlinepubs/007904975/basedefs/signal.h.html Ulrich Drepper refused a patch to fix glibc due to this reason: http://sources.redhat.com/ml/libc-alpha/2004-03/msg00254.html so here is the patch to fix it in the kernel. ppc64 and s390x were broken before and are fixed by this patch too.
-
Andrew Morton authored
From: David Gibson <david@gibson.dropbear.id.au> This patch adds a debugging message to the ppc64 hugepage code when we attempt to open the "low" (32-bit) hugepage window on PPC64, but can't because a (non-hugepage) mapping already exists in the region.
-
Andrew Morton authored
From: David Gibson <david@gibson.dropbear.id.au> On PowerPC64 the "low" hugepage range (at 2-3G for use by 32-bit processes) needs to be activated before it can be used. hugetlb_get_unmapped_area() automatically activates the range for hugepage mappings in 32-bit processes which are not MAP_FIXED. However for MAP_FIXED mmap()s, even at a suitable address will fail if the region is not already activated, because there is no suitable callback from the generic MAP_FIXED code path into the arch code. This patch corrects this problem and allows PPC64 to do MAP_FIXED hugepage mappings in the low hugepage range.
-
Andrew Morton authored
From: David Gibson <david@gibson.dropbear.id.au> Due to a misunderstanding of pmd_offset() the PPC64 hugepage code could end up looking at bogus pages as if they were PMD pages.
-
Andrew Morton authored
From: Anton Blanchard <anton@samba.org> From: Stephen Rothwell <sfr@canb.auug.org.au> This creates DMA_ERROR_CODE and uses it everywhere instead of PCI_DMA_ERROR_CODE as we really want the three DMA mapping API's to return a single error code. Also we now have dma_mapping_error and vio_dma_mapping_error - and this latter and pci_dma_mapping_error both just call the former. Also a small fix in the vscsi - dma_map_sg returns 0 to indicate an error.
-
Andrew Morton authored
From: Matt Porter <mporter@kernel.crashing.org> This fixes the build on non cache coherent PPC32 platforms.
-
- 31 Mar, 2004 2 commits
-
-
bk://kernel.bkbits.net/davem/net-2.6Linus Torvalds authored
into ppc970.osdl.org:/home/torvalds/v2.6/linux
-
http://jfs.bkbits.net/linux-2.5Linus Torvalds authored
into ppc970.osdl.org:/home/torvalds/v2.6/linux
-
- 01 Apr, 2004 1 commit
-
-
Dave Kleikamp authored
into austin.ibm.com:/shaggy/bk/jfs-2.5
-
- 31 Mar, 2004 4 commits
-
-
David S. Miller authored
into kernel.bkbits.net:/home/davem/net-2.6
-
Nivedita Singhvi authored
-
Hideaki Yoshifuji authored
-
http://xfs.org:8090/xfs-linux-2.6Linus Torvalds authored
into ppc970.osdl.org:/home/torvalds/v2.6/linux
-
- 01 Apr, 2004 16 commits
-
-
Timothy Shimmin authored
estimate. We must add in for the worst case of a log stripe taking us the full distance for a log stripe boundary. SGI Modid: xfs-linux:xfs-kern:169304a
-
Nathan Scott authored
SGI Modid: xfs-linux:xfs-kern:169300a
-
Nathan Scott authored
SGI Modid: xfs-linux:xfs-kern:169208a
-
Nathan Scott authored
else we panic. SGI Modid: xfs-linux:xfs-kern:169200a
-
Nathan Scott authored
SGI Modid: xfs-linux:xfs-kern:169199a
-
Christoph Hellwig authored
SGI Modid: xfs-linux:xfs-kern:169135a
-
Nathan Scott authored
SGI Modid: xfs-linux:xfs-kern:169048a
-
Nathan Scott authored
SGI Modid: xfs-linux:xfs-kern:169038a
-
Nathan Straz authored
SGI Modid: xfs-linux:xfs-kern:168809a
-
Nathan Scott authored
SGI Modid: xfs-linux:xfs-kern:168693a
-
Glen Overby authored
feature bit in sb_versionnum to use to indicate that the new feature bit field is to be used. SGI Modid: xfs-linux:xfs-kern:168665a
-
Glen Overby authored
Add XFS_ALLOCFREE_LOG_RES to IFREE log reservation. SGI Modid: xfs-linux:xfs-kern:168597a
-
Christoph Hellwig authored
SGI Modid: xfs-linux:xfs-kern:168167a
-
Eric Sandeen authored
previously saved FSTRANS state. Otherwise we can lose process flags. SGI Modid: xfs-linux:xfs-kern:168082a
-
Nathan Scott authored
take the iolock here, and readers no longer conflict with concurrent fsync activity. Kudos to Steve! SGI Modid: xfs-linux:xfs-kern:167949a
-
Nathan Scott authored
SGI Modid: xfs-linux:xfs-kern:167944a
-
- 31 Mar, 2004 11 commits
-
-
Linus Torvalds authored
-
Linus Torvalds authored
People need the global wake events even when not sleeping: they are used for lid open events at least on some laptops. As such, they should be enabled by default. You can disable them with "acpi_leave_gpes_disabled" if your machine doesn't need them, and you want to get a few less GPE's.
-
Harald Welte authored
-
Andrew Morton authored
Spotted by Suparna: if the first range check fails, we leak a ref on the io context.
-
Bart De Schuymer authored
Currently, to be able to send a reset in the FORWARD chain of iptables for bridged traffic, ip forwarding must be enabled. This causes confusion and in some situations people really don't want to enable ip forwarding. The patch below lets the user send reset packets for bridged frames in the FORWARD chain, with ip forwarding disabled (as long as there is a route).
-
bk://kernel.bkbits.net/davem/sparc-2.6Linus Torvalds authored
into ppc970.osdl.org:/home/torvalds/v2.6/linux
-
Adrian Bunk authored
In the ALSA cleanup for duplicate PCI ID's, they weren't exactly duplicated, resulting in problems in the au8810.c driver. This fixes the problem
-
bk://kernel.bkbits.net/wesolows/sparc32-2.6David S. Miller authored
into nuts.davemloft.net:/disk1/BK/sparc-2.6
-
David S. Miller authored
into nuts.davemloft.net:/disk1/BK/sparc-2.6
-
Jeff Garzik authored
The last fix apparently only worked for device 0, since the driver screwed up the port offsets (due to a wonky VIA hardware layout, really). This patch fixes device 1 detection for the users still seeing problems in -rc3.
-
Jeff Garzik authored
In both uniprocessor and SMP, the fealnx driver's TX-submit path can race against the interrupt handler, with disastrous results. Add the lock that needed to be there all along, to fix this. There's another problem in the RX path, that will be sent as a separate patch, as soon as we get that patch 100% nailed down, and acceptable for a Release Candidate.
-