[PATCH] radix_tree.h trivial comment correction
There is an unmatched parenthesis in the locking commentary of radix_tree.h
which is trivially fixed by the patch below.
Signed-off-by: Tim Pepper <[EMAIL PROTECTED]>
Cc: Nick Piggin <[EMAIL PROTECTED]>
---
diff --git a/include/linux/radix-tree.h b/include/linux/radix-tree.h
--- a/include/linux/radix-tree.h
+++ b/include/linux/radix-tree.h
@@ -91,7 +91,7 @@ do {
\
*
* For API usage, in general,
* - any function _modifying_ the tree or tags (inserting or deleting
- * items, setting or clearing tags must exclude other modifications, and
+ * items, setting or clearing tags) must exclude other modifications, and
* exclude any functions reading the tree.
* - any function _reading_ the tree or tags (looking up items or tags,
* gang lookups) must exclude modifications to the tree, but may occur
-
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/
[PATCH] radix_tree.h trivial comment correction
There is an unmatched parenthesis in the locking commentary of radix_tree.h
which is trivially fixed by the patch below.
Signed-off-by: Tim Pepper [EMAIL PROTECTED]
Cc: Nick Piggin [EMAIL PROTECTED]
---
diff --git a/include/linux/radix-tree.h b/include/linux/radix-tree.h
--- a/include/linux/radix-tree.h
+++ b/include/linux/radix-tree.h
@@ -91,7 +91,7 @@ do {
\
*
* For API usage, in general,
* - any function _modifying_ the tree or tags (inserting or deleting
- * items, setting or clearing tags must exclude other modifications, and
+ * items, setting or clearing tags) must exclude other modifications, and
* exclude any functions reading the tree.
* - any function _reading_ the tree or tags (looking up items or tags,
* gang lookups) must exclude modifications to the tree, but may occur
-
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/
Re: [PATCH] lockdep: Avoid /proc/lockdep & lock_stat infinite output
On Tue 09 Oct at 13:14:49 +0200 [EMAIL PROTECTED] said:
> FWIW I had to do Tim's bits too. Just moving all output from the start
> into the show method didn't fix it.
Yes. The way the original lockdep_proc.c code was doing its pointers
around its seq data was definitely wrong, regardless of the output
outside of _show().
> -static void *l_start(struct seq_file *m, loff_t *pos)
> +static void *l_next(struct seq_file *m, void *v, loff_t *pos)
> {
> - struct lock_class *class = m->private;
> -
> - if (>lock_entry == all_lock_classes.next)
> - seq_printf(m, "all lock classes:\n");
> -
> - return class;
> + (*pos)++;
> + return l_start(m, pos);
> }
Isn't this is going to make l_start/l_next() approach O(n^2) when they can
be more like O(n)? It appears to be the case that _next() will always
get a valid *v, so you can just step immediately to the next element.
The _start() seems to be the only place where you'd actually need to
search based on *pos.
The below moves the headers out of the _start() functions, but by using
SEQ_START_TOKEN (as appears to be the trend in other seq_file users)
to differentiate. This means *pos==0 then is the header and *pos==1..n
are the lock class elements 0..(n-1), which again appears to be what
others are doing.
Both /proc/lockdep and /proc/lock_stat output may loop infinitely.
When a read() requests an amount of data smaller than the amount of data
that the seq_file's foo_show() outputs, the output starts looping and
outputs the "stuck" element's data infinitely. There may be multiple
sequential calls to foo_start(), foo_next()/foo_show(), and foo_stop()
for a single open with sequential read of the file. The _start() does not
have to start with the 0th element and _show() might be called multiple
times in a row for the same element for a given open/read of the seq_file.
Also header output should not be happening in _start(). All output should
be in _show(), which SEQ_START_TOKEN is meant to help. Having output in
_start() may also negatively impact seq_file's seq_read() and traverse()
accounting.
Signed-off-by: Tim Pepper <[EMAIL PROTECTED]>
Cc: Peter Zijlstra <[EMAIL PROTECTED]>
Cc: Ingo Molnar <[EMAIL PROTECTED]>
Cc: Al Viro <[EMAIL PROTECTED]>
---
Compared to my previous version this now also has output only happening
in _show(). Compared to Peter's version with output only in _show(),
this is more efficient in its _next().
--- linux-2.6.23-rc9.orig/kernel/lockdep_proc.c
+++ linux-2.6.23-rc9/kernel/lockdep_proc.c
@@ -25,28 +25,38 @@
static void *l_next(struct seq_file *m, void *v, loff_t *pos)
{
- struct lock_class *class = v;
+ struct lock_class *class;
(*pos)++;
+ if (v == SEQ_START_TOKEN)
+ class = m->private;
+ else {
+ class = v;
+
+ if (class->lock_entry.next != _lock_classes)
+ class = list_entry(class->lock_entry.next,
+ struct lock_class, lock_entry);
+ else
+ class = NULL;
+ }
- if (class->lock_entry.next != _lock_classes)
- class = list_entry(class->lock_entry.next, struct lock_class,
- lock_entry);
- else
- class = NULL;
- m->private = class;
return class;
}
static void *l_start(struct seq_file *m, loff_t *pos)
{
- struct lock_class *class = m->private;
+ struct lock_class *class;
+ loff_t i = 0;
- if (>lock_entry == all_lock_classes.next)
- seq_printf(m, "all lock classes:\n");
+ if (*pos == 0)
+ return SEQ_START_TOKEN;
+ list_for_each_entry(class, _lock_classes, lock_entry) {
+ if (++i == *pos)
+ return class;
+ }
+ return NULL;
- return class;
}
static void l_stop(struct seq_file *m, void *v)
@@ -101,10 +111,15 @@ static void print_name(struct seq_file *
static int l_show(struct seq_file *m, void *v)
{
unsigned long nr_forward_deps, nr_backward_deps;
- struct lock_class *class = m->private;
+ struct lock_class *class = v;
struct lock_list *entry;
char c1, c2, c3, c4;
+ if (v == SEQ_START_TOKEN) {
+ seq_printf(m, "all lock classes:\n");
+ return 0;
+ }
+
seq_printf(m, "%p", class->key);
#ifdef CONFIG_DEBUG_LOCKDEP
seq_printf(m, " OPS:%8ld", class->ops);
@@ -523,10 +538,11 @@ static void *ls_start(struct seq_file *m
{
struct lock_stat_seq *data = m->private;
- if (data->iter == data->stats)
- seq_header(m);
+ if (*pos == 0)
+ return SEQ
Re: [PATCH] lockdep: Avoid /proc/lockdep lock_stat infinite output
On Tue 09 Oct at 13:14:49 +0200 [EMAIL PROTECTED] said:
FWIW I had to do Tim's bits too. Just moving all output from the start
into the show method didn't fix it.
Yes. The way the original lockdep_proc.c code was doing its pointers
around its seq data was definitely wrong, regardless of the output
outside of _show().
-static void *l_start(struct seq_file *m, loff_t *pos)
+static void *l_next(struct seq_file *m, void *v, loff_t *pos)
{
- struct lock_class *class = m-private;
-
- if (class-lock_entry == all_lock_classes.next)
- seq_printf(m, all lock classes:\n);
-
- return class;
+ (*pos)++;
+ return l_start(m, pos);
}
Isn't this is going to make l_start/l_next() approach O(n^2) when they can
be more like O(n)? It appears to be the case that _next() will always
get a valid *v, so you can just step immediately to the next element.
The _start() seems to be the only place where you'd actually need to
search based on *pos.
The below moves the headers out of the _start() functions, but by using
SEQ_START_TOKEN (as appears to be the trend in other seq_file users)
to differentiate. This means *pos==0 then is the header and *pos==1..n
are the lock class elements 0..(n-1), which again appears to be what
others are doing.
Both /proc/lockdep and /proc/lock_stat output may loop infinitely.
When a read() requests an amount of data smaller than the amount of data
that the seq_file's foo_show() outputs, the output starts looping and
outputs the stuck element's data infinitely. There may be multiple
sequential calls to foo_start(), foo_next()/foo_show(), and foo_stop()
for a single open with sequential read of the file. The _start() does not
have to start with the 0th element and _show() might be called multiple
times in a row for the same element for a given open/read of the seq_file.
Also header output should not be happening in _start(). All output should
be in _show(), which SEQ_START_TOKEN is meant to help. Having output in
_start() may also negatively impact seq_file's seq_read() and traverse()
accounting.
Signed-off-by: Tim Pepper [EMAIL PROTECTED]
Cc: Peter Zijlstra [EMAIL PROTECTED]
Cc: Ingo Molnar [EMAIL PROTECTED]
Cc: Al Viro [EMAIL PROTECTED]
---
Compared to my previous version this now also has output only happening
in _show(). Compared to Peter's version with output only in _show(),
this is more efficient in its _next().
--- linux-2.6.23-rc9.orig/kernel/lockdep_proc.c
+++ linux-2.6.23-rc9/kernel/lockdep_proc.c
@@ -25,28 +25,38 @@
static void *l_next(struct seq_file *m, void *v, loff_t *pos)
{
- struct lock_class *class = v;
+ struct lock_class *class;
(*pos)++;
+ if (v == SEQ_START_TOKEN)
+ class = m-private;
+ else {
+ class = v;
+
+ if (class-lock_entry.next != all_lock_classes)
+ class = list_entry(class-lock_entry.next,
+ struct lock_class, lock_entry);
+ else
+ class = NULL;
+ }
- if (class-lock_entry.next != all_lock_classes)
- class = list_entry(class-lock_entry.next, struct lock_class,
- lock_entry);
- else
- class = NULL;
- m-private = class;
return class;
}
static void *l_start(struct seq_file *m, loff_t *pos)
{
- struct lock_class *class = m-private;
+ struct lock_class *class;
+ loff_t i = 0;
- if (class-lock_entry == all_lock_classes.next)
- seq_printf(m, all lock classes:\n);
+ if (*pos == 0)
+ return SEQ_START_TOKEN;
+ list_for_each_entry(class, all_lock_classes, lock_entry) {
+ if (++i == *pos)
+ return class;
+ }
+ return NULL;
- return class;
}
static void l_stop(struct seq_file *m, void *v)
@@ -101,10 +111,15 @@ static void print_name(struct seq_file *
static int l_show(struct seq_file *m, void *v)
{
unsigned long nr_forward_deps, nr_backward_deps;
- struct lock_class *class = m-private;
+ struct lock_class *class = v;
struct lock_list *entry;
char c1, c2, c3, c4;
+ if (v == SEQ_START_TOKEN) {
+ seq_printf(m, all lock classes:\n);
+ return 0;
+ }
+
seq_printf(m, %p, class-key);
#ifdef CONFIG_DEBUG_LOCKDEP
seq_printf(m, OPS:%8ld, class-ops);
@@ -523,10 +538,11 @@ static void *ls_start(struct seq_file *m
{
struct lock_stat_seq *data = m-private;
- if (data-iter == data-stats)
- seq_header(m);
+ if (*pos == 0)
+ return SEQ_START_TOKEN;
- if (data-iter == data-iter_end)
+ data-iter = data-stats + *pos;
+ if (data-iter = data-iter_end)
data-iter = NULL;
return data-iter;
@@ -538,8
Re: [PATCH] lockdep: Avoid /proc/lockdep & lock_stat infinite output
On Tue 09 Oct at 02:30:11 +0100 [EMAIL PROTECTED] said: > On Mon, Oct 08, 2007 at 06:15:51PM -0700, Tim Pepper wrote: > > > > - if (>lock_entry == all_lock_classes.next) > > + if (*pos == 0) > > seq_printf(m, "all lock classes:\n"); > > Do not generate output outside of ->show() and you won't have these > problems. That's where your infinite output crap comes from. > > IOW, NAK - fix the underlying problem. Aaah...OK. Can we add something like the following then: Document that output must only come from _show() and SEQ_START_TOKEN is how a _start() indicates a header is to be printed. Signed-off-by: Tim Pepper <[EMAIL PROTECTED]> Cc: Al Viro <[EMAIL PROTECTED]> --- --- linux-2.6.orig/include/linux/seq_file.h +++ linux-2.6.23-rc9/include/linux/seq_file.h @@ -36,9 +36,10 @@ ssize_t seq_read(struct file *, char __u loff_t seq_lseek(struct file *, loff_t, int); int seq_release(struct inode *, struct file *); int seq_escape(struct seq_file *, const char *, const char *); + +/* these may only be called from a (*show) function */ int seq_putc(struct seq_file *m, char c); int seq_puts(struct seq_file *m, const char *s); - int seq_printf(struct seq_file *, const char *, ...) __attribute__ ((format (printf,2,3))); @@ -48,6 +49,11 @@ int single_open(struct file *, int (*)(s int single_release(struct inode *, struct file *); int seq_release_private(struct inode *, struct file *); +/* + * return SEQ_START_TOKEN in your (*start) function and test for + * (v == SEQ_START_TOKEN) in * your (*show) funtion in order to + * print a header before your seq data + */ #define SEQ_START_TOKEN ((void *)1) /* - 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/
[PATCH] lockdep: Avoid /proc/lockdep & lock_stat infinite output
When a read() requests an amount of data smaller than the amount of data
that the seq_file's foo_show() outputs, the output starts looping and
outputs the "stuck" element's data infinitely. There may be multiple
sequential calls to foo_start(), foo_next()/foo_show(), and foo_stop()
for a single open with sequential read of the file. The _start() does not
have to start with the 0th element and _show() might be called multiple
times in a row for the same element for a given open/read of the seq_file.
Signed-off-by: Tim Pepper <[EMAIL PROTECTED]>
Cc: Peter Zijlstra <[EMAIL PROTECTED]>
Cc: Ingo Molnar <[EMAIL PROTECTED]>
---
Assuming people are fine with this, it should probably find its way
to stable.
If you haven't seen the infinite output: it's easy to trigger with a
simple 'cat /proc/lockdep' generally for me, a cat /proc/lock_stat piped
to a file or for either of them a dd with the default bs=512 (or smaller)
should do the job also.
With this change to the lock_stat handler the data->iter member no longer
attempts to hold state across calls, so it could be taken out of the
lock_stat_seq struct and replace by a local variable in each function
but that isn't a clear win to me so I just left it.
--- linux-2.6.23-rc9.orig/kernel/lockdep_proc.c
+++ linux-2.6.23-rc9/kernel/lockdep_proc.c
@@ -34,19 +34,23 @@ static void *l_next(struct seq_file *m,
lock_entry);
else
class = NULL;
- m->private = class;
return class;
}
static void *l_start(struct seq_file *m, loff_t *pos)
{
- struct lock_class *class = m->private;
+ struct lock_class *class;
+ loff_t i = 0;
- if (>lock_entry == all_lock_classes.next)
+ if (*pos == 0)
seq_printf(m, "all lock classes:\n");
+ list_for_each_entry(class, _lock_classes, lock_entry) {
+ if (i++ == *pos)
+ return class;
+ }
+ return NULL;
- return class;
}
static void l_stop(struct seq_file *m, void *v)
@@ -101,7 +105,7 @@ static void print_name(struct seq_file *
static int l_show(struct seq_file *m, void *v)
{
unsigned long nr_forward_deps, nr_backward_deps;
- struct lock_class *class = m->private;
+ struct lock_class *class = v;
struct lock_list *entry;
char c1, c2, c3, c4;
@@ -523,12 +527,15 @@ static void *ls_start(struct seq_file *m
{
struct lock_stat_seq *data = m->private;
- if (data->iter == data->stats)
- seq_header(m);
+ data->iter = data->stats;
+ data->iter += *pos;
- if (data->iter == data->iter_end)
+ if (data->iter >= data->iter_end)
data->iter = NULL;
+ if (data->iter == data->stats)
+ seq_header(m);
+
return data->iter;
}
-
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/
[PATCH] lockdep: Avoid /proc/lockdep lock_stat infinite output
When a read() requests an amount of data smaller than the amount of data
that the seq_file's foo_show() outputs, the output starts looping and
outputs the stuck element's data infinitely. There may be multiple
sequential calls to foo_start(), foo_next()/foo_show(), and foo_stop()
for a single open with sequential read of the file. The _start() does not
have to start with the 0th element and _show() might be called multiple
times in a row for the same element for a given open/read of the seq_file.
Signed-off-by: Tim Pepper [EMAIL PROTECTED]
Cc: Peter Zijlstra [EMAIL PROTECTED]
Cc: Ingo Molnar [EMAIL PROTECTED]
---
Assuming people are fine with this, it should probably find its way
to stable.
If you haven't seen the infinite output: it's easy to trigger with a
simple 'cat /proc/lockdep' generally for me, a cat /proc/lock_stat piped
to a file or for either of them a dd with the default bs=512 (or smaller)
should do the job also.
With this change to the lock_stat handler the data-iter member no longer
attempts to hold state across calls, so it could be taken out of the
lock_stat_seq struct and replace by a local variable in each function
but that isn't a clear win to me so I just left it.
--- linux-2.6.23-rc9.orig/kernel/lockdep_proc.c
+++ linux-2.6.23-rc9/kernel/lockdep_proc.c
@@ -34,19 +34,23 @@ static void *l_next(struct seq_file *m,
lock_entry);
else
class = NULL;
- m-private = class;
return class;
}
static void *l_start(struct seq_file *m, loff_t *pos)
{
- struct lock_class *class = m-private;
+ struct lock_class *class;
+ loff_t i = 0;
- if (class-lock_entry == all_lock_classes.next)
+ if (*pos == 0)
seq_printf(m, all lock classes:\n);
+ list_for_each_entry(class, all_lock_classes, lock_entry) {
+ if (i++ == *pos)
+ return class;
+ }
+ return NULL;
- return class;
}
static void l_stop(struct seq_file *m, void *v)
@@ -101,7 +105,7 @@ static void print_name(struct seq_file *
static int l_show(struct seq_file *m, void *v)
{
unsigned long nr_forward_deps, nr_backward_deps;
- struct lock_class *class = m-private;
+ struct lock_class *class = v;
struct lock_list *entry;
char c1, c2, c3, c4;
@@ -523,12 +527,15 @@ static void *ls_start(struct seq_file *m
{
struct lock_stat_seq *data = m-private;
- if (data-iter == data-stats)
- seq_header(m);
+ data-iter = data-stats;
+ data-iter += *pos;
- if (data-iter == data-iter_end)
+ if (data-iter = data-iter_end)
data-iter = NULL;
+ if (data-iter == data-stats)
+ seq_header(m);
+
return data-iter;
}
-
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/
Re: [PATCH] lockdep: Avoid /proc/lockdep lock_stat infinite output
On Tue 09 Oct at 02:30:11 +0100 [EMAIL PROTECTED] said: On Mon, Oct 08, 2007 at 06:15:51PM -0700, Tim Pepper wrote: - if (class-lock_entry == all_lock_classes.next) + if (*pos == 0) seq_printf(m, all lock classes:\n); Do not generate output outside of -show() and you won't have these problems. That's where your infinite output crap comes from. IOW, NAK - fix the underlying problem. Aaah...OK. Can we add something like the following then: Document that output must only come from _show() and SEQ_START_TOKEN is how a _start() indicates a header is to be printed. Signed-off-by: Tim Pepper [EMAIL PROTECTED] Cc: Al Viro [EMAIL PROTECTED] --- --- linux-2.6.orig/include/linux/seq_file.h +++ linux-2.6.23-rc9/include/linux/seq_file.h @@ -36,9 +36,10 @@ ssize_t seq_read(struct file *, char __u loff_t seq_lseek(struct file *, loff_t, int); int seq_release(struct inode *, struct file *); int seq_escape(struct seq_file *, const char *, const char *); + +/* these may only be called from a (*show) function */ int seq_putc(struct seq_file *m, char c); int seq_puts(struct seq_file *m, const char *s); - int seq_printf(struct seq_file *, const char *, ...) __attribute__ ((format (printf,2,3))); @@ -48,6 +49,11 @@ int single_open(struct file *, int (*)(s int single_release(struct inode *, struct file *); int seq_release_private(struct inode *, struct file *); +/* + * return SEQ_START_TOKEN in your (*start) function and test for + * (v == SEQ_START_TOKEN) in * your (*show) funtion in order to + * print a header before your seq data + */ #define SEQ_START_TOKEN ((void *)1) /* - 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/
Re: [RFT][PATCH] mm: drop behind
On 7/9/07, Peter Zijlstra <[EMAIL PROTECTED]> wrote: Use the read-ahead code to provide hints to page reclaim. This patch has the potential to solve the streaming-IO trashes my desktop problem. It tries to aggressively reclaim pages that were loaded in a strong sequential pattern and have been consumed. Thereby limiting the damage to the current resident set. Interesting... Would it make sense to tie this into (finally) making POSIX_FADV_NOREUSE something more than a noop? Tim - 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/
Re: [RFT][PATCH] mm: drop behind
On 7/9/07, Peter Zijlstra [EMAIL PROTECTED] wrote: Use the read-ahead code to provide hints to page reclaim. This patch has the potential to solve the streaming-IO trashes my desktop problem. It tries to aggressively reclaim pages that were loaded in a strong sequential pattern and have been consumed. Thereby limiting the damage to the current resident set. Interesting... Would it make sense to tie this into (finally) making POSIX_FADV_NOREUSE something more than a noop? Tim - 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/
Re: [RFC] pci_bus conversion to struct device
On 1/18/07, Greg KH <[EMAIL PROTECTED]> wrote: Hm, only ia64 enables that option. Matthew, do you care about those files? Given the ia64 nature, unless benh was truly wanting to do something or ppc64, IBM's big NUMA boxes are pretty unlikely to care. Tim - 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/
Re: [RFC] pci_bus conversion to struct device
On 1/18/07, Greg KH [EMAIL PROTECTED] wrote: Hm, only ia64 enables that option. Matthew, do you care about those files? Given the ia64 nature, unless benh was truly wanting to do something or ppc64, IBM's big NUMA boxes are pretty unlikely to care. Tim - 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/
Re: OT: character encodings (was: Linux 2.6.20-rc4)
On 1/8/07, Pavel Machek <[EMAIL PROTECTED]> wrote: On Sun 2007-01-07 22:30:55, Alan wrote: > I think that would be a good idea - and add it to the coding/docs specs > that documentation is UTF-8. Code should IMHO say 7bit though. Yes, yes, please. I have been flamed when someone tried to do 8bit patch, and I was trying to NAK it... Could this get put in Documentation/CodingStyle? And an item added to the kernel janitors' list to fix up 8bit files? Last I looked trying to decided if there was a standard here I found a mish-mash of encodings based output of file vs Linus' git tree. - 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/
Re: OT: character encodings (was: Linux 2.6.20-rc4)
On 1/8/07, Pavel Machek [EMAIL PROTECTED] wrote: On Sun 2007-01-07 22:30:55, Alan wrote: I think that would be a good idea - and add it to the coding/docs specs that documentation is UTF-8. Code should IMHO say 7bit though. Yes, yes, please. I have been flamed when someone tried to do 8bit patch, and I was trying to NAK it... Could this get put in Documentation/CodingStyle? And an item added to the kernel janitors' list to fix up 8bit files? Last I looked trying to decided if there was a standard here I found a mish-mash of encodings based output of file vs Linus' git tree. - 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/
Re: [PATCH] Fix sparsemem on Cell (take 3)
On 1/7/07, Dave Hansen <[EMAIL PROTECTED]> wrote: On Fri, 2007-01-05 at 22:52 -0600, John Rose wrote: > Could this break ia64, given that it uses memmap_init_zone()? You are right, I think it does. Boot tested OK on ia64 with this latest version of the patch. (forgot to click plain text on gmail the first time..sorry if you got html mail or repeat) Tim - 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/
Re: [PATCH] Fix sparsemem on Cell (take 3)
On 1/7/07, Dave Hansen [EMAIL PROTECTED] wrote: On Fri, 2007-01-05 at 22:52 -0600, John Rose wrote: Could this break ia64, given that it uses memmap_init_zone()? You are right, I think it does. Boot tested OK on ia64 with this latest version of the patch. (forgot to click plain text on gmail the first time..sorry if you got html mail or repeat) Tim - 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/
Re: b_dev vs. b_rdev confusion
On Tue, 19 Jun 2001 [EMAIL PROTECTED] wrote: > All of the md code looks like it copies the buffer head, setting > b_dev=b_rdev="real device" in the new bh and leaving b_dev==b_rdev="logical > device" in the original bh. I'm assuming they do this for a reason, but > it would be nice from a performance standpoint to just touch b_rdev and > b_end_io and be done. Is there something I'm missing which necessitates the > copy? Oops...I take that back. In the md code for raid1, raid5 and multipath I see copies, but not in lvm or linear. Tim - 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/
Re: b_dev vs. b_rdev confusion
On Tue, 19 Jun 2001 [EMAIL PROTECTED] wrote: All of the md code looks like it copies the buffer head, setting b_dev=b_rdev=real device in the new bh and leaving b_dev==b_rdev=logical device in the original bh. I'm assuming they do this for a reason, but it would be nice from a performance standpoint to just touch b_rdev and b_end_io and be done. Is there something I'm missing which necessitates the copy? Oops...I take that back. In the md code for raid1, raid5 and multipath I see copies, but not in lvm or linear. Tim - 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/
2.4.3 irq routing conflict (VIA chipset)
I know there was a thread on this previously and I was thinking it had been resolved (or was that only for a specific mobo mfg?). When I finally got my VIA chipset machine up to date with a 2.4.3 kernel I noticed the following on boot up: PCI: Found IRQ 11 for device 00:0a.0 IRQ routing conflict in pirq table for device 00:0a.0 The only device on irq 11 is an agp voodoo3 card. I don't seem to see any negative effects (unless what I believe is an unrelated scsi error is tied to this somehow). Should I just disregard this message and assume it's a mobo quirk? The mobo in question is an AOpen AX59Pro with the current bios. I can run any test code or send futher system info if desired... Tim -- * tpepper@linuxninja dot org * Venimus, Vidimus, * * http://www.linuxninja.org/~tpepper * Dolavimus * - 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/
2.4.3 irq routing conflict (VIA chipset)
I know there was a thread on this previously and I was thinking it had been resolved (or was that only for a specific mobo mfg?). When I finally got my VIA chipset machine up to date with a 2.4.3 kernel I noticed the following on boot up: PCI: Found IRQ 11 for device 00:0a.0 IRQ routing conflict in pirq table for device 00:0a.0 The only device on irq 11 is an agp voodoo3 card. I don't seem to see any negative effects (unless what I believe is an unrelated scsi error is tied to this somehow). Should I just disregard this message and assume it's a mobo quirk? The mobo in question is an AOpen AX59Pro with the current bios. I can run any test code or send futher system info if desired... Tim -- * tpepper@linuxninja dot org * Venimus, Vidimus, * * http://www.linuxninja.org/~tpepper * Dolavimus * - 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/
