* Serge E. Hallyn ([EMAIL PROTECTED]) wrote:
===
--- linux-2.6.22-rc2-mm1.orig/kernel/exit.c
+++ linux-2.6.22-rc2-mm1/kernel/exit.c
@@ -924,10 +924,12 @@ fastcall void do_exit(long code)
if (unlikely(tsk-audit_context))
The pseudo_palette has room for 16 entries only, but in truecolor mode, it
attempts to write 256.
Signed-off-by: Antonino Daplas [EMAIL PROTECTED]
Acked-by: Tero Roponen [EMAIL PROTECTED]
---
Tero Roponen wrote:
On Thu, 31 May 2007, Antonino A. Daplas wrote:
On Wed, 2007-05-30 at 19:33
* Arnaldo Carvalho de Melo ([EMAIL PROTECTED]) wrote:
The fix for the fix needed a fix: allocate_msrs() was using
for_each_online_cpu(), but nmi_setup uses for_each_possible_cpu(), and
in my test machine, a Dell Poweredge 1950 I have 2 dual core Xeons,
which makes for 4 possible cores, but
On Wed, 30 May 2007 17:09:56 -0700 (PDT) Christoph Lameter wrote:
On Wed, 30 May 2007, Randy Dunlap wrote:
OK. I would write the file to disk and view it with an editor.
Then at each occurrence of /exit.text/, see if it's inside an __init
function...
Ahh okay. cscope will do that
* Linus Torvalds [EMAIL PROTECTED] wrote:
I agree. What would be a good interface to allocate fds in such
area? We don't want to replicate syscalls, so maybe a special new
dup function?
I'd do it with something like newfd = dup2(fd, NONLINEAR_FD) or
similar, and just have
On Wed, May 30 2007, Phillip Susi wrote:
That would be the exactly how I understand Documentation/block/barrier.txt:
In other words, I/O barrier requests have the following two properties.
1. Request ordering
...
2. Forced flushing to physical medium
So, I/O barriers need to guarantee
On Thu, May 31 2007, David Chinner wrote:
IOWs, there are two parts to the problem:
1 - guaranteeing I/O ordering
2 - guaranteeing blocks are on persistent storage.
Right now, a single barrier I/O is used to provide both of these
guarantees. In most cases, all we really need
On Wed, May 30, 2007 at 09:09:26PM -0700, William Lee Irwin III wrote:
It's not all that tricky.
On Thu, May 31, 2007 at 11:18:28AM +0530, Srivatsa Vaddagiri wrote:
Hmm ..the fact that each task runs for a minimum of 1 tick seems to
complicate the matters to me (when doing group fairness
On Wed, May 30, 2007 at 02:59:57PM +0200, Michal Marek wrote:
* 32bit struct xfs_fsop_bulkreq has different size and layout of
members, no matter the alignment. Move the code out of the #else
branch (why was it there in the first place?). Define _32 variants of
the ioctl constants.
*
On Tuesday, 29 May 2007 02:39, Herbert Xu wrote:
On Mon, May 28, 2007 at 08:21:29PM +0200, Rafael J. Wysocki wrote:
Well, it looks like we have to fix this one separately.
Can you please tell me what to do to make cryptd run?
If you build it as a module then just loading it should be
On Tuesday May 29, [EMAIL PROTECTED] wrote:
But then I think a problem remains after your patch that if the page is
partially truncated after you test that it is uptodate and resample i_size,
then the page tail can be zero filled and then you'll again get back a
nul tail from read(2), don't
On Wed, 30 May 2007 14:40:02 -0700,
Williams, Dan J [EMAIL PROTECTED] wrote:
With the patch non-dma-architectures that try to build code with true
dependencies on the DMA api will fail to link i.e.:
CONFIG_DMA_ENGINE=y CONFIG_HAS_DMA=n ASYNC_MEMCPY=y
CC init/version.o
LD
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc3/2.6.22-rc3-mm1/
- Merged the convert-cpusets-to-container-infrastructure patches. These
will probably be dropped and redone.
Boilerplate:
- See the `hot-fixes' directory for any important updates to this patchset.
-
On Thursday, 31 May 2007 08:54, Rafael J. Wysocki wrote:
On Tuesday, 29 May 2007 02:39, Herbert Xu wrote:
On Mon, May 28, 2007 at 08:21:29PM +0200, Rafael J. Wysocki wrote:
Well, it looks like we have to fix this one separately.
Can you please tell me what to do to make cryptd run?
On Thu, May 31, 2007 at 08:26:45AM +0200, Jens Axboe wrote:
On Thu, May 31 2007, David Chinner wrote:
IOWs, there are two parts to the problem:
1 - guaranteeing I/O ordering
2 - guaranteeing blocks are on persistent storage.
Right now, a single barrier I/O is used to provide
On Wednesday 30 May 2007, Michal Marek wrote:
--- linux-2.6.orig/fs/xfs/linux-2.6/xfs_ioctl32.c
+++ linux-2.6/fs/xfs/linux-2.6/xfs_ioctl32.c
@@ -109,35 +109,249 @@ STATIC unsigned long xfs_ioctl32_geom_v1
return (unsigned long)p;
}
-#else
+typedef struct xfs_inogrp32 {
+
On Thu, May 31 2007, David Chinner wrote:
On Thu, May 31, 2007 at 08:26:45AM +0200, Jens Axboe wrote:
On Thu, May 31 2007, David Chinner wrote:
IOWs, there are two parts to the problem:
1 - guaranteeing I/O ordering
2 - guaranteeing blocks are on persistent storage.
On Thursday, 31 May 2007 09:04, Rafael J. Wysocki wrote:
On Thursday, 31 May 2007 08:54, Rafael J. Wysocki wrote:
On Tuesday, 29 May 2007 02:39, Herbert Xu wrote:
On Mon, May 28, 2007 at 08:21:29PM +0200, Rafael J. Wysocki wrote:
Well, it looks like we have to fix this one
On Thu, 31 May 2007, Antonino A. Daplas wrote:
On Wed, 2007-05-30 at 22:04 +0400, Alexey Dobriyan wrote:
2) palette in neofb_par is u32 palette[16]; which is 4x16 = 64 bytes.
struct fb_info::pseudo_palette is assigned to it in neo_alloc_fb_info().
Yet, we check at the beginning of
When Zach Amsden added PARAVIRT_LAZY_FLUSH I didn't realize how often
it would get called. We only need to do something if we're actually
in lazy mode.
Before:
Time for one context switch via pipe: 10509 (9863 - 18761)
Time for one Copy-on-Write fault: 71796 (20625 - 207750)
Time to exec client
Some hypercalls can be batched: lazy_hcall is the wrapper which
determines this, so it's pretty harmless to use lazy_hcall() instead of
hcall().
Before:
Time for one context switch via pipe: 6745 (6521 - 13966)
After:
Time for one context switch via pipe: 5406 (5170 - 7467)
Signed-off-by: Rusty
1) When the Guest sets the new TLS entries, we don't need to re-verify
the whole GDT.
2) We also don't need to copy all the GDT entries if only the TLS
entries have changed.
Before:
Time for one context switch via pipe: 5406 (5170 - 7467)
After:
Time for one context switch via pipe: 4916
From 30d6996860f7e5589d1bce10404bbcfd6592c9de Mon Sep 17 00:00:00 2001
From: Denis Cheng [EMAIL PROTECTED]
Date: Thu, 31 May 2007 15:21:58 +0800
Subject: [PATCH] since the definition of dst_discard_in and
dst_discard_out are the same,
they should merged into one
Signed-off-by: Denis Cheng
On Thu, 31 May 2007 08:13:03 +0200
Ingo Molnar [EMAIL PROTECTED] wrote:
* Linus Torvalds [EMAIL PROTECTED] wrote:
I agree. What would be a good interface to allocate fds in such
area? We don't want to replicate syscalls, so maybe a special new
dup function?
I'd do it with
That looks good to me.
Thanks,
Roland
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Hi.
On Wed, 2007-05-30 at 17:09 -0700, Randy Dunlap wrote:
On Sat, May 26, 2007 at 04:32:54PM +1000, Nigel Cunningham wrote:
Hi Nigel,
As promised I took another look at the patch and at what Randy had
prepared to fix the IA64 compilation error. I did some more work on it,
On Wed, May 30, 2007 at 04:16:55PM -0700, Jeremy Fitzhardinge wrote:
Eric W. Biederman wrote:
I think we should start there and be prepared to munge the ELF
magic number if there are problems. Placing ELF notes is going
to require a little work but mostly it should be a matter of
copying
On Thu, May 31, 2007 at 09:13:44AM +0200, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki [EMAIL PROTECTED]
Make cryptd actually run and mark it as nonfreezable.
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
Patch applied. Thanks a lot!
--
Visit Openswan at
Arnd Bergmann wrote:
On Wednesday 30 May 2007, Chris Wedgwood wrote:
On Wed, May 30, 2007 at 02:59:55PM +0200, Michal Marek wrote:
+typedef struct xfs_fsop_geom_v132 {
wouldn't xfs_fsop_geom_v1_32
...
and xfs_fsop_geom_v1_32_t
^
read better there?
Actually, the
Ingo Molnar writes:
looking over the list of our new generic APIs (see further below) i
think there are three important things that are needed for an API to
become widely used:
1) it should solve a real problem (ha ;-), it should be intuitive to
humans and it should fit into existing
Hey all,
I altered Karuna's cref tool to print the number of seconds it would
take to check the cross-references for a chunk. The results look good
for chunkfs: on my laptop /home file system and a 1 GB chunk size, the
per-chunk cross-reference check time would be an average of 5 seconds
and a
On Wed, May 30, 2007 at 11:36:47PM -0700, William Lee Irwin III wrote:
On Thu, May 31, 2007 at 11:18:28AM +0530, Srivatsa Vaddagiri wrote:
Hmm ..the fact that each task runs for a minimum of 1 tick seems to
complicate the matters to me (when doing group fairness given a single
level
From: Rankle_ [EMAIL PROTECTED]
Date: Thu, 31 May 2007 15:26:54 +0800
From 30d6996860f7e5589d1bce10404bbcfd6592c9de Mon Sep 17 00:00:00 2001
From: Denis Cheng [EMAIL PROTECTED]
Date: Thu, 31 May 2007 15:21:58 +0800
Subject: [PATCH] since the definition of dst_discard_in and
dst_discard_out
Andrew Morton wrote:
On Wed, 30 May 2007 19:42:26 +0400
Pavel Emelianov [EMAIL PROTECTED] wrote:
[snip]
+#ifdef CONFIG_RSS_CONTAINER
+unsigned long try_to_free_pages_in_container(struct rss_container *cnt)
+{
+struct scan_control sc = {
+.gfp_mask = GFP_KERNEL,
+
On Wed, May 30, 2007 at 11:36:47PM -0700, William Lee Irwin III wrote:
Temporarily, yes. All this only works when averaged out.
On Thu, May 31, 2007 at 02:03:53PM +0530, Srivatsa Vaddagiri wrote:
So essentially when we calculate delta_mine component for each of those
1000 tasks, we will find
On Thu, May 31, 2007 at 02:03:53PM +0530, Srivatsa Vaddagiri wrote:
Its -wait_runtime will drop less significantly, which lets it be
inserted in rb-tree much to the left of those 1000 tasks (and which indirectly
lets it gain back its fair share during subsequent schedule cycles).
Hmm ..is
David Chinner wrote:
On Wed, May 30, 2007 at 02:59:57PM +0200, Michal Marek wrote:
+typedef struct xfs_bstat32 {
+__u64 bs_ino; /* inode number */
+__u16 bs_mode;/* type and mode*/
+__u16 bs_nlink;
--- slub.orig/init/Kconfig2007-05-30 16:35:05.0 -0700
+++ slub/init/Kconfig 2007-05-30 16:35:45.0 -0700
@@ -65,6 +65,13 @@ endmenu
menu General setup
+config STABLE
+ bool Stable kernel
+ help
+ If the kernel is configured to be a stable kernel then
Andrew Morton wrote:
+#else
+static inline int container_rss_prepare(struct page *pg,
+struct vm_area_struct *vma, struct page_container **pc)
+{
+*pc = NULL; /* to make gcc happy */
eh? What is gcc's problem here?
When this line is missed and CONFIG_RSS_COUNTER is n the
From: Stefan Richter [EMAIL PROTECTED]
Date: Thu, 31 May 2007 10:54:36 +0200
b) Of course nobody wants STABLE=n. :-) How about:
config RELEASE
bool Build for release
help
If the kernel is declared as a release build here, then
various checks that are only of
* Ingo Molnar [EMAIL PROTECTED] wrote:
it's both a flexibility and a speedup thing as well:
flexibility: for libraries to be able to open files and keep them open
comes up regularly. For example currently glibc is quite wasteful in a
number of common networking related functions (Ulrich,
menu General setup
+config STABLE
+bool Stable kernel
[...]
a) Why in Kconfig, why not in Makefile?
b) Of course nobody wants STABLE=n. :-) How about:
config RELEASE
bool Build for release
help
If the kernel is declared as a release build here, then
On Thu, 2007-05-31 at 09:17 +0200, Geert Uytterhoeven wrote:
On Thu, 31 May 2007, Antonino A. Daplas wrote:
On Wed, 2007-05-30 at 22:04 +0400, Alexey Dobriyan wrote:
2) palette in neofb_par is u32 palette[16]; which is 4x16 = 64 bytes.
struct fb_info::pseudo_palette is assigned to it
Linus, please pull from [the linus branch at]:
master.kernel.org:/pub/scm/linux/kernel/git/perex/alsa.git linus
gitweb interface:
http://www.kernel.org/git/?p=linux/kernel/git/perex/alsa.git
The GNU patch is available at:
On Thu, May 31, 2007 at 02:03:53PM +0530, Srivatsa Vaddagiri wrote:
Its -wait_runtime will drop less significantly, which lets it be
inserted in rb-tree much to the left of those 1000 tasks (and which
indirectly lets it gain back its fair share during subsequent
schedule cycles).
Hmm ..is
On Wed, 2007-05-30 at 12:39 -0700, Matthew Helsley wrote:
On Wed, 2007-05-30 at 14:49 +0200, Peter Zijlstra wrote:
plain text document attachment (lockstat-output.patch)
Present all this fancy new lock statistics information:
*warning, _wide_ output ahead*
(output edited for purpose
On 30/05/07, Lee Revell [EMAIL PROTECTED] wrote:
On 5/30/07, Daniel J Blueman [EMAIL PROTECTED] wrote:
I have a SanDisk Extreme IV 4GB CF card, capable of 40MB/s read, but
am seeing 30MB/s read [1], connected directly to the IDE bus on my
ICH8 controller.
How do you know it's capable of
Hi Mark,
Thanks for the reply; here is the raw identification data:
# hdparm --Istdout /dev/sdb
/dev/sdb:
045a 3fff c837 0010 003f
2020 2020 2020 5644 5334 3142
5434 4456 3038 474a 0003 3bf5 0034 5634
344f 4139 3641 4844 5437 3232 3532 3544
4c41 3338 3020 2020 2020
On 5/31/07, David Miller [EMAIL PROTECTED] wrote:
Your email client has changed all of the tab characters into spaces,
corrupting the patch.
Please configure your email client to not perform any text formatting.
Please test this, by emailing the patch to yourself and trying to
apply it,
Ok, I've incorporated Paul and Geert's suggestions, and split the patch into
two parts. See next two messages.
Rob
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Signed-off-by: Rob Landley [EMAIL PROTECTED]
--
Equivalent to:
git-mv sx.txt stallion.txt specialix.txt rocket.txt riscom8.txt \
computone.txt hayes-esp.txt moxa-smartio serial
diff --git a/Documentation/computone.txt b/Documentation/serial/computone.txt
similarity index 100%
rename
Signed-off-by: Rob Landley [EMAIL PROTECTED]
Amiga part Acked-by: Geert Uytterhoeven [EMAIL PROTECTED]
Move architecture-specific Documentation into a common subdirectory.
--
Equivalent to:
cd Documentation
mkdir -p arch/amiga
git-mv zorro.txt m68k/README.buddha arch/amiga
git-mv arm
Vaidyanathan Srinivasan wrote:
Andrew Morton wrote:
On Wed, 30 May 2007 19:42:26 +0400
Pavel Emelianov [EMAIL PROTECTED] wrote:
[snip]
+#ifdef CONFIG_RSS_CONTAINER
+unsigned long try_to_free_pages_in_container(struct rss_container *cnt)
+{
+ struct scan_control sc = {
+
On Thu, May 31, 2007 at 02:15:34AM -0700, William Lee Irwin III wrote:
Yes, the larger number of schedulable entities and hence slower
convergence to groupwise weightings is a disadvantage of the flattening.
A hybrid scheme seems reasonable enough.
Cool! This puts me back on track to
* Eric Dumazet [EMAIL PROTECTED] wrote:
speedup: i suggested O_ANY 6 years ago as a speedup to Apache -
non-linear fds are cheaper to allocate/map:
http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg23820.html
(i definitely remember having written code for that too, but
* Ingo Molnar [EMAIL PROTECTED] wrote:
(i definitely remember having written code for that too, but i cannot
find that in the archives. hm.) In theory we could avoid _all_
fd-bitmap overhead as well and use a per-process list/pool of struct
file buffers plus a maximum-fd field as the
On Thu, May 31 2007, Ingo Molnar wrote:
* Ingo Molnar [EMAIL PROTECTED] wrote:
(i definitely remember having written code for that too, but i cannot
find that in the archives. hm.) In theory we could avoid _all_
fd-bitmap overhead as well and use a per-process list/pool of struct
Venki Pallipadi [EMAIL PROTECTED] writes:
If this does not work:
Another option is to use 'deferrable timer' here which will be called at
same as before time when CPU is busy and on idle CPU it will be delayed until
CPU comes out of idle due to any other events.
That would sound like a good
J. Bruce Fields [EMAIL PROTECTED] wrote:
Yes. I need to get the server lock first, before going to the VFS locking
routines.
That doesn't really answer the question. The NFS client has similar
requirements, but it doesn't have to duplicate the per-inode lists of
granted locks, for
static void distribute_fair_add(struct rq *rq, s64 delta)
{
struct task_struct *curr = rq-curr;
s64 delta_fair = 0;
if (!(sysctl_sched_load_smoothing 32))
return;
if (rq-nr_running) {
delta_fair = div64_s(delta, rq-nr_running);
/*
* The currently
* Albert Cahalan [EMAIL PROTECTED] wrote:
Ingo Molnar writes:
looking over the list of our new generic APIs (see further below) i
think there are three important things that are needed for an API to
become widely used:
1) it should solve a real problem (ha ;-), it should be intuitive
* Li Yu [EMAIL PROTECTED] wrote:
static void distribute_fair_add(struct rq *rq, s64 delta)
{
struct task_struct *curr = rq-curr;
s64 delta_fair = 0;
if (!(sysctl_sched_load_smoothing 32))
return;
if (rq-nr_running) {
delta_fair = div64_s(delta,
On Wed, May 30, 2007 at 03:25:05PM -0400, Len Brown wrote:
Any reason to not just replace ACPI_RSD_TABLE_SIZE with ARRAY_SIZE?
Probably because ARRAY_SIZE doesn't exist in ACPICA, which is
where this code comes from...
When we change syntax in ACPICA files in Linux to make it more
This is a set of fixes to the initial revision of the zs driver port to
the serial subsystem. They include an update to the recovery delay, and
the race on interrupt handler registration. As well as a number of style
fixes throughout.
Signed-off-by: Maciej W. Rozycki [EMAIL PROTECTED]
---
The linux/serial_core.h header refers to handle_sysrq(), but does not
include linux/sysrq.h which provides a declaration of the function.
This may result in an implicit declaration and a warning if the actual one
is seen later on.
Signed-off-by: Maciej W. Rozycki [EMAIL PROTECTED]
---
On Tue, May 29, 2007 at 08:59:37AM +1000, Trent Waddington wrote:
Someone finally noticed that my program that uses ptrace only works on
i386..
and, by the looks of it, there is no portable way to refer to the
registers of a
user_regs_struct when inspecting a system call.
Correct.
I will
On Thu, May 31, 2007 at 06:32:29AM +0200, Tino Keitel wrote:
rtc_cmos 00:09: rtc core: registered rtc_cmos as rtc0
rtc_cmos: probe of 00:09 failed with error -16
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
Try unsetting CONFIG_RTC - you can't use the legacy driver at the same
On 5/29/07, Ralf Baechle [EMAIL PROTECTED] wrote:
Also consider that some architectures pass parts of the arguments in
registers which on yet others are passed in memory. Sometimes padding
arguments are needed and many more oddities. Similar for results.
Inescapably such a program is a perment
Andrew Morton wrote:
On Wed, 30 May 2007 19:42:26 +0400
Pavel Emelianov [EMAIL PROTECTED] wrote:
Implement try_to_free_pages_in_container() to free the
pages in container that has run out of memory.
The scan_control-isolate_pages() function is set to
isolate_pages_in_container() that
Hi,
This patch removes the -sendfile() hook from the file_operations
structure, and replaces the sys_sendfile() mechanism to be based on
-splice_read() instead. There should be no functional changes.
Work to be done:
- The ext2 xip support needs a splice_read() implementation, currently I
On Thu, 31 May 2007 11:02:52 +0200
Ingo Molnar [EMAIL PROTECTED] wrote:
* Ingo Molnar [EMAIL PROTECTED] wrote:
it's both a flexibility and a speedup thing as well:
flexibility: for libraries to be able to open files and keep them open
comes up regularly. For example currently glibc
On Thu, 31 May 2007 12:33:16 +0200
Jens Axboe [EMAIL PROTECTED] wrote:
Hi,
This patch removes the -sendfile() hook from the file_operations
structure, and replaces the sys_sendfile() mechanism to be based on
-splice_read() instead. There should be no functional changes.
- retval =
On Thu, May 31 2007, Jens Axboe wrote:
Hi,
This patch removes the -sendfile() hook from the file_operations
structure, and replaces the sys_sendfile() mechanism to be based on
-splice_read() instead. There should be no functional changes.
Forgot to mention, that the modified kernel of
* Eric Dumazet [EMAIL PROTECTED] wrote:
I tried your bench and found two problems :
- You scan half of the bitmap
[...]
Try to close not a 'middle fd', but a really low one (10 for example),
and latencie is doubled.
that was intentional. I really didnt want to fabricate a worst-case
On Thu, May 31 2007, Eric Dumazet wrote:
On Thu, 31 May 2007 12:33:16 +0200
Jens Axboe [EMAIL PROTECTED] wrote:
Hi,
This patch removes the -sendfile() hook from the file_operations
structure, and replaces the sys_sendfile() mechanism to be based on
-splice_read() instead. There
On Thu, May 31, 2007 at 12:33:16PM +0200, Jens Axboe wrote:
- nfds: The -rq_sendfile_ok optimization is gone for now. I can't
determine the value of it, but I'm assuming it's there for a reason.
Any chance this can be converted to splice, or use something else than
-sendfile()? CC'ed
Hi, today one of my servers locked up, and after powercycling it
I've found this in syslog. I'll upgrade the machine to latest stable
todayy but decided to report the bug anyway.
May 30 01:15:56 server kernel: invalid opcode: [#3]
May 30 01:15:56 server kernel: SMP
May 30 01:15:56 server
Please pull from:
master.kernel.org:/pub/scm/linux/kernel/git/lethal/sh-2.6.git
Which contains:
Andrew Morton (1):
sh: support older gcc's
Evgeniy Polyakov (1):
sh: trivial build cleanups.
Manuel Lauss (2):
sh: Trivial fix for dma-api compile failure.
sh: Fix
Jens Axboe wrote:
Work to be done:
- The ext2 xip support needs a splice_read() implementation, currently I
just if 0'ed out the send xip_file_sendfile(). CC'ed Carsten, who
seems to be the author of this code.
Yup. Will do the splice_read implementation for xip. Do you want to
see it in
On Thu, May 31 2007, Christoph Hellwig wrote:
On Thu, May 31, 2007 at 12:33:16PM +0200, Jens Axboe wrote:
- nfds: The -rq_sendfile_ok optimization is gone for now. I can't
determine the value of it, but I'm assuming it's there for a reason.
Any chance this can be converted to splice, or
On Thu, May 31 2007, Carsten Otte wrote:
Jens Axboe wrote:
Work to be done:
- The ext2 xip support needs a splice_read() implementation, currently I
just if 0'ed out the send xip_file_sendfile(). CC'ed Carsten, who
seems to be the author of this code.
Yup. Will do the splice_read
2007/5/30, Phillip Susi [EMAIL PROTECTED]:
Stefan Bader wrote:
Since drive a supports barrier request we don't get -EOPNOTSUPP but
the request with block y might get written before block x since the
disk are independent. I guess the chances of this are quite low since
at some point a
What was the verdict here? Were you satisfied with this or do you need a change?
Pierre Ossman wrote:
Andrew Morton wrote:
Whatever. I think you can work it out ;)
Bare with me, I just woke up ;)
while (driver_probe_done() || (ROOT_DEV = name_to_dev_t(...)) == 0)
perhaps?
The
On x86_64 kernel, level triggered irq migration gets initiated in the context
of that interrupt(after executing the irq handler) and following steps are
followed to do the irq migration.
1. mask IOAPIC RTE entry; // write to IOAPIC RTE
2. EOI; // processor EOI write
3.
This patch fixes several whitespace issues.
Signed-off-by: Thomas Klein [EMAIL PROTECTED]
---
diff -Nurp -X dontdiff linux-2.6.22-rc3/drivers/net/ehea/ehea.h
patched_kernel/drivers/net/ehea/ehea.h
--- linux-2.6.22-rc3/drivers/net/ehea/ehea.h2007-05-30 12:13:36.0
+0200
+++
After there were no technical concerns about this patch I'm resending it with
all whitespace issues fixed which were mentioned by Stephen Rothwell.
This patch enables the receive side processing to aggregate TCP packets within
the HEA device driver. It analyses the packets already received after
Nick Piggin [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
Nick Piggin [EMAIL PROTECTED] writes:
However we
could still set_page_dirty of a block device page without buffers
via an mmap.
After the page is made dirty via mmap we have:
sys_write - ... - block_prepare_write - ... -
On Thursday 31 May 2007 13:34:21 Eric W. Biederman wrote:
On x86_64 kernel, level triggered irq migration gets initiated in the context
of that interrupt(after executing the irq handler) and following steps are
followed to do the irq migration.
What's the confidence level in the patch? Is it
Paul Mundt wrote:
Please pull from:
master.kernel.org:/pub/scm/linux/kernel/git/lethal/sh-2.6.git
Which contains:
Out of curiosity, who maintains sh64?
It has a couple irq handlers that have not been updated since the Oct
2006 update that changed every irq handler in the kernel:
Yeah, that is a very sensible idea.
Possible further checks that might make sense:
- panic() anywhere in drivers/*
- externs in .c files without asmlinkage
- general checking that everything in a fully visible {} block is the right
indentation
Here are some more warnings I would
On Wed, 30 May 2007 23:58:23 -0700,
Andrew Morton [EMAIL PROTECTED] wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc3/2.6.22-rc3-mm1/
With
+dma-mapping-prevent-dma-dependent-code-from-linking-on.patch
scsi fails to build on !HAS_DMA architectures:
Funnily enough I have just today with an app I have which uses 1.2GB
of textures :-)
Realistic app which is something users really run?
Also do the other constraints above apply?
If you use pci_alloc_coherent() then it will already take care of the rules
above btw (e.g. DTRT when the machine
On Thu, May 31, 2007 at 02:09:22PM +0200, Cornelia Huck wrote:
I split those functions out into a new file. Builds on s390 and i386.
Why not just put #ifdef CONFIG_HAS_DMA / #endif around the pair of
functions? I don't see the need to add a new Kconfig symbol and a new
file for this.
-
To
On Thu, 31 May 2007 06:15:57 -0600,
Matthew Wilcox [EMAIL PROTECTED] wrote:
On Thu, May 31, 2007 at 02:09:22PM +0200, Cornelia Huck wrote:
I split those functions out into a new file. Builds on s390 and i386.
Why not just put #ifdef CONFIG_HAS_DMA / #endif around the pair of
functions? I
Daniel J Blueman wrote:
Hi Mark,
Thanks for the reply; here is the raw identification data:
# hdparm --Istdout /dev/sdb
/dev/sdb:
045a 3fff c837 0010 003f
2020 2020 2020 5644 5334 3142
5434 4456 3038 474a 0003 3bf5 0034 5634
344f 4139 3641 4844 5437 3232 3532 3544
On Wed, 30 May 2007 20:57:38 +0100 (BST)
Hugh Dickins [EMAIL PROTECTED] wrote:
I've taken a look at last. It looks like a good fix to a real problem,
but may I suggest a simpler version? The anon_vma isn't usually held
by a refcount, but by having a vma on its linked list: why not just
put
On Thursday May 31, [EMAIL PROTECTED] wrote:
On Thu, May 31 2007, Christoph Hellwig wrote:
On Thu, May 31, 2007 at 12:33:16PM +0200, Jens Axboe wrote:
- nfds: The -rq_sendfile_ok optimization is gone for now. I can't
determine the value of it, but I'm assuming it's there for a reason.
Neil Brown wrote:
On Monday May 28, [EMAIL PROTECTED] wrote:
There are two things I'm not sure you covered.
First, disks which don't support flush but do have a cache dirty
status bit you can poll at times like shutdown. If there are no drivers
which support these, it can be ignored.
On Thu, May 31 2007, Neil Brown wrote:
On Thursday May 31, [EMAIL PROTECTED] wrote:
On Thu, May 31 2007, Christoph Hellwig wrote:
On Thu, May 31, 2007 at 12:33:16PM +0200, Jens Axboe wrote:
- nfds: The -rq_sendfile_ok optimization is gone for now. I can't
determine the value of it,
On Wed, 30 May 2007, Robert Hancock wrote:
Parag Warudkar wrote:
Robert Hancock wrote:
0-3319MB
4096-8832MB
leaving 64MB of memory at the top of RAM uncached. What do you want to
bet that something important (kernel code?) is getting loaded there..
So essentially it's a BIOS problem,
1 - 100 of 908 matches
Mail list logo
