- 27 Sep, 2004 5 commits
-
-
Patrick McHardy authored
Signed-off-by:Patrick McHardy <kaber@trash.net>
-
Patrick McHardy authored
Signed-off-by: -
Patrick McHardy authored
Signed-off-by: -
Patrick McHardy authored
Signed-off-by: -
Patrick McHardy authored
Signed-off-by:
-
- 25 Sep, 2004 8 commits
-
-
bk://are.twiddle.net/axp-2.6/Linus Torvalds authored
into ppc970.osdl.org:/home/torvalds/v2.6/linux
-
Richard Henderson authored
-
Richard Henderson authored
to be linked unconditionally.
-
Benjamin Herrenschmidt authored
The current 32 bits translation of the SI_TIMER is wrong on ppc64, causing the tst-timer4 testcase of glibc to fail in 32 bits. This patch fixes it. Signed-off-by:
Olaf Hering <olh@suse.de> Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Matthew Wilcox authored
The "blocked_list" used for POSIX deadlock detection should only contain POSIX locks, or posix_locks_deadlock() can get confused. As I've noted before (but never posted a patch), we should probably stop checking for deadlock. POSIX says it's optional for an implementation to check for deadlock, and since the change to match on tgid, we can report a deadlock when none exists. [ Further explanation for Linus: POSIX locks and BSD locks don't block each other, so checking that the blocker is a POSIX lock also implies that the waiter is a POSIX lock. ]
-
Linus Torvalds authored
We need to convert from bytes to blocks, and we also need to handle the fact that old smbd's will round up the disk usage bytecount to even multiples of 1MB, and gracefully fall back on an estimate based on the file size instead in that case. Acked by Samuel Thibault who noted the problem in the first place, and Jeremy Allison wrt smbd behavior. Signed-off-by: -
Richard Henderson authored
into kanga.twiddle.home:/home/rth/work/linux/axp-2.6
-
Richard Henderson authored
-
- 24 Sep, 2004 1 commit
-
-
bk://bk.arm.linux.org.uk/linux-2.6-rmkLinus Torvalds authored
into ppc970.osdl.org:/home/torvalds/v2.6/linux
-
- 25 Sep, 2004 1 commit
-
-
Russell King authored
The recent addition of linux/bitops.h inside linux/kernel.h has created a circular dependency: asm/system.h -> linux/kernel.h -> linux/bitops.h -> asm/bitops.h -> asm/system.h which results in an unbuildable kernel. We appear not to need linux/kernel.h in asm/system.h, but do need linux/linkage.h, so make this the case.
-
- 24 Sep, 2004 25 commits
-
-
bk://kernel.bkbits.net/davem/nf-2.6Linus Torvalds authored
into ppc970.osdl.org:/home/torvalds/v2.6/linux
-
David S. Miller authored
into kernel.bkbits.net:/home/davem/sparc-2.6
-
Patrick McHardy authored
Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
into nuts.davemloft.net:/disk1/BK/nf-2.6
-
David S. Miller authored
Else we risk an OOPS. Signed-off-by: -
David S. Miller authored
-
Linus Torvalds authored
Otherwise modules that get loaded dynamically will not be able to resolve the iomap functions, if no built-in drivers caused it to be linked in at compile-time.
-
Linus Torvalds authored
It missed the new vmlinux.strip file.
-
Linus Torvalds authored
-
Maximilian Attems authored
# CONFIG_PCI is not set CONFIG_EISA=y drivers/net/3c59x.c: In function `vortex_ioctl': drivers/net/3c59x.c:2916: warning: dereferencing `void *' pointer drivers/net/3c59x.c:2916: error: request for member `current_state' in something not a structure or union Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
-
Christoph Lameter authored
Quiet mmtimer on non-SGI boxes (previously it printed "mmtimer: unable to determine clock frequency"). Signed-off-by:
Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by:
Christoph Lameter <clameter@sgi.com> Signed-off-by:
-
Jeff Dike authored
From: Doug Dumitru <doug@easyco.com> I have been fighting a buffering error when sending large amounts of data out pty devices from UML. I have tried a couple of patches that did not really fix the problem (and were rightly rejected by the group), but have finally found the real bug. In /arch/um/drivers/line.c there is a function "buffer_data" that is responsible for storing data into the lines ring buffer. The function is "supposed" to return the number of characters actually buffered. Unfortunately, in the case where the buffer wraps, the "len" variable is decremented by "end" before it is used as the return parameter. Signed-off-by:
Paolo 'Blaisorblade' Giarrusso <blaisorblade_spam@yahoo.it> Signed-off-by:
Jeff Dike <jdike@addtoit.com> Signed-off-by:
-
Jeff Dike authored
Make sure we print ERRNO and not always -1. Signed-off-by:
-
Jeff Dike authored
Simple corrections to some error messages, which list wrong limits for UBD devices and such. Signed-off-by:
-
Jeff Dike authored
Output a nice error message for people who need mem > 256M but don't increase on the host /proc/sys/vm/max_map_count, telling them to do so. Signed-off-by:
-
Jeff Dike authored
Signed-off-by:
-
Jeff Dike authored
From: "D. Bahi" @ enterasys.com - remove an unneeded line from the dynamic linker script. Signed-off-by:
-
Jeff Dike authored
This makes UML load at 0x8048000 rather than 0xa0000000 when CONFIG_MODE_SKAS is on and CONFIG_MODE_TT is off. This will make it more valgrind-friendly, and also allow much greater physical memory sizes without needing to use highmem. Signed-off-by:
-
Jeff Dike authored
Signed-off-by:
-
Jeff Dike authored
__wrap_free is now careful about freeing to the same allocator that allocated the buffer. Signed-off-by:
-
Jeff Dike authored
Tidied up some whitespace in arch/um/Makefile. Added -DUM_FASTCALL to Makefile-i386. make clean descends into util in order to get rid of the binaries there. Signed-off-by:
-
Jeff Dike authored
arch/um/uml.lds.S has already been moved to arch/um/kernel. dyn.lds.S has just been forgotten, so fix this. Signed-off-by:
-
Li Shaohua authored
Unconditionally enabling interrupts is upsetting the ACPI time resume code. Signed-off-by:
Li Shaohua <shaohua.li@intel.com> Signed-off-by:
-
Grzegorz Jaskiewicz authored
Fix various gcc-4.0 compilation errors. Signed-off-by: Grzegorz Jaskiewicz <gj at pointblue.com.pl> Signed-off-by:
-
Nathan Scott authored
The following patch to the generic direct IO code fixes a problem we've come across that affects the way XFS interacts with it. Between 2.6.5 and 2.6.6 several changes to direct IO were made, in particular the fallback-to-buffered path was introduced in that timeframe. Those changes split the locking done within direct-io.c into two cases - generic filesystems and blkdev/XFS. There is no locking done for the second case, and we also never set the create parameter to the get_blocks call (via direct_io_worker ->do_direct_IO->get_more_blocks) for that case. This meant that XFS was accidentally no longer being told when a direct IO write was being performed, which in turn meant that XFS would (often - depending on the inode's size and bmap) tell get_more_blocks that it was mapping to a hole. It also means that currently all direct writes into XFS are falling back to buffered writes. Further, skipping the i_alloc_sem locking entirely is not correct for us, we are relying on that aspect of the generic locking. The fallback behaviour from direct to buffered is "silent", so we didn't actually pick up on these problems until just recently, unfortunately. The approach I've taken here is to split the blkdev/XFS case into two, and corrected the new third case behaviour for the functionality XFS provides. The generic behavior used by other filesystems remains unchanged, as does direct IO to the block device, and XFS now becomes fully functional. Signed-off-by:
-
