Re: [PATCH] Bad rounding in timeval_to_jiffies [was: Re: Odd Timer behavior in 2.6 vs 2.4 (1 extra tick)]
On Wed, Apr 20, 2005 at 11:40:16PM -0400, Steven Rostedt wrote: Is 11 jiffies correct for 10ms? Consider the 1 jiffy case. How long does waiting one jiffy actually wait? j=01 2 +--+--+-- t A B C D If you start timing one jiffy from A, you're looking for j=1, so your timer expires close to D and you have waited one jiffy. If you start timing one jiffy from B, you're still looking for j=1. Your timer expires at the same point (D) but you've waited less than one jiffy. If you start timing one jiffy from C, it's the same - expires at D. This time, you've waited virtually no time at all. The problem is that when you add a timer, you don't have any idea which point you're going to be starting your timer at. This is why we always round up to the next jiffy when we convert times to jiffies - this ensures that you will get at _least_ the timeout you requested, which is in itself a very important guarantee. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core - 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/
[RFC/PATCH 20/22] W1: add w1_device_id/MODULE_DEVICE_TABLE for automatic driver loading
W1: support for automatic family drivers loading via hotplug:
- allow family drivers support list of families;
- export supported families through MODULE_DEVICE_TABLE.
Signed-off-by: Dmitry Torokhov [EMAIL PROTECTED]
---
drivers/w1/w1.c |6 --
drivers/w1/w1.h |3 ++-
drivers/w1/w1_sernum.c |9 -
drivers/w1/w1_thermal.c |9 -
include/linux/mod_devicetable.h |4
scripts/mod/file2alias.c| 16
6 files changed, 42 insertions(+), 5 deletions(-)
Index: dtor/drivers/w1/w1.c
===
--- dtor.orig/drivers/w1/w1.c
+++ dtor/drivers/w1/w1.c
@@ -58,9 +58,11 @@ static int w1_bus_match(struct device *d
*/
struct w1_slave *slave = to_w1_slave(dev);
struct w1_family *family = to_w1_family(drv);
+ struct w1_device_id *id;
- if (slave-reg_num.family == family-fid)
- return 1;
+ for (id = family-id_table; id-family; id++)
+ if (slave-reg_num.family == id-family)
+ return 1;
return 0;
}
Index: dtor/drivers/w1/w1.h
===
--- dtor.orig/drivers/w1/w1.h
+++ dtor/drivers/w1/w1.h
@@ -41,6 +41,7 @@ struct w1_reg_num
#include linux/completion.h
#include linux/device.h
+#include linux/mod_devicetable.h
#include asm/semaphore.h
@@ -118,7 +119,7 @@ void w1_remove_master_device(struct w1_m
struct w1_family {
struct device_driverdriver;
- u8 fid;
+ struct w1_device_id *id_table;
const char *name;
int (*join)(struct w1_slave *);
Index: dtor/drivers/w1/w1_thermal.c
===
--- dtor.orig/drivers/w1/w1_thermal.c
+++ dtor/drivers/w1/w1_thermal.c
@@ -50,11 +50,18 @@ static void w1_thermal_leave(struct w1_s
device_remove_file(slave-dev, w1_thermal_temperature_attr);
}
+static struct w1_device_id w1_thermal_ids[] = {
+ { .family = W1_FAMILY_THERMAL, },
+ { }
+};
+
+MODULE_DEVICE_TABLE(w1, w1_thermal_ids);
+
static struct w1_family w1_thermal_family = {
.driver = {
.name = thermal,
},
- .fid= W1_FAMILY_THERMAL,
+ .id_table = w1_thermal_ids,
.name = Digital Thermometer Driver,
.join = w1_thermal_join,
.leave = w1_thermal_leave,
Index: dtor/drivers/w1/w1_sernum.c
===
--- dtor.orig/drivers/w1/w1_sernum.c
+++ dtor/drivers/w1/w1_sernum.c
@@ -40,11 +40,18 @@ MODULE_DESCRIPTION(1-Wire Silicon Seria
* by W1 core.
*/
+static struct w1_device_id w1_serial_num_ids[] = {
+ { .family = W1_FAMILY_SERIAL_NUM, },
+ { }
+};
+
+MODULE_DEVICE_TABLE(w1, w1_serial_num_ids);
+
static struct w1_family w1_serial_num_family = {
.driver = {
.name = sernum,
},
- .fid= W1_FAMILY_SERIAL_NUM,
+ .id_table = w1_serial_num_ids,
.name = Serial Number Driver,
};
Index: dtor/scripts/mod/file2alias.c
===
--- dtor.orig/scripts/mod/file2alias.c
+++ dtor/scripts/mod/file2alias.c
@@ -25,6 +25,7 @@ typedef Elf64_Addrkernel_ulong_t;
#include stdint.h
#endif
+typedef uint64_t __u64;
typedef uint32_t __u32;
typedef uint16_t __u16;
typedef unsigned char __u8;
@@ -199,6 +200,18 @@ static int do_serio_entry(const char *fi
return 1;
}
+/* Looks like: w1:fidNsnN */
+static int do_w1_entry(const char *filename,
+ struct w1_device_id *id, char *alias)
+{
+ id-family = TO_NATIVE(id-family);
+ id-serial = TO_NATIVE(id-serial);
+
+ sprintf(alias, w1:fid%02Xsn%024llX, id-family, id-serial);
+
+ return 1;
+}
+
/* looks like: pnp:dD */
static int do_pnp_entry(const char *filename,
struct pnp_device_id *id, char *alias)
@@ -291,6 +304,9 @@ void handle_moddevtable(struct module *m
else if (sym_is(symname, __mod_serio_device_table))
do_table(symval, sym-st_size, sizeof(struct serio_device_id),
do_serio_entry, mod);
+ else if (sym_is(symname, __mod_w1_device_table))
+ do_table(symval, sym-st_size, sizeof(struct w1_device_id),
+do_w1_entry, mod);
else if (sym_is(symname, __mod_pnp_device_table))
do_table(symval, sym-st_size, sizeof(struct pnp_device_id),
do_pnp_entry, mod);
Index: dtor/include/linux/mod_devicetable.h
===
--- dtor.orig/include/linux/mod_devicetable.h
+++ dtor/include/linux/mod_devicetable.h
@@
Re: Linux 2.6.12-rc3
Linus Torvalds wrote:
Geert Uytterhoeven:
[PATCH] M68k: Update defconfigs for 2.6.11
[PATCH] M68k: Update defconfigs for 2.6.12-rc2
Why do I still get this error when trying to cross-compile for m68k?
toolchain:
Reading specs from
/usr/local/m68k-uclinux-tools/lib/gcc/m68k-uclinux/3.4.0/specs
Configured with: /usr/local/src/uclinux-tools/gcc-3.4.0/configure
--target=m68k-uclinux --prefix=/usr/local/m68k-uclinux-tools
--enable-languages=c,c++ --enable-multilib --enable-target-optspace
--with-gnu-ld --disable-nls --disable-__cxa_atexit --disable-c99
--disable-clocale
--disable-c-mbchar --disable-long-long --enable-threads=posix
--enable-cxx-flags=-D_ISOC99_SOURCE -D_BSD_SOURCE
Thread model: posix
gcc version 3.4.0
GNU ld version 2.14.90.0.8 20040114
(I tried an alternative toolchain with gcc 3.3.3 as well)
$ make mrproper
$ make ARCH=m68k CROSS_COMPILE=m68k-elf- mrproper
$ make ARCH=m68k CROSS_COMPILE=m68k-elf- defconfig
$ make ARCH=m68k CROSS_COMPILE=m68k-elf-
CHK include/linux/version.h
UPD include/linux/version.h
SYMLINK include/asm - include/asm-m68k
SPLIT include/linux/autoconf.h - include/config/*
HOSTCC scripts/kallsyms
HOSTCC scripts/conmakehash
CC arch/m68k/kernel/asm-offsets.s
In file included from include/linux/spinlock.h:12,
from include/linux/capability.h:45,
from include/linux/sched.h:7,
from arch/m68k/kernel/asm-offsets.c:12:
include/linux/thread_info.h:30: error: parse error before '{' token
include/linux/thread_info.h:35: error: parse error before '{' token
include/linux/thread_info.h: In function `test_and_set_thread_flag':
include/linux/thread_info.h:42: error: `current' undeclared (first use in this
function)
include/linux/thread_info.h:42: error: (Each undeclared identifier is reported
only once
include/linux/thread_info.h:42: error: for each function it appears in.)
include/linux/thread_info.h: In function `test_and_clear_thread_flag':
include/linux/thread_info.h:47: error: `current' undeclared (first use in this
function)
include/linux/thread_info.h: At top level:
include/linux/thread_info.h:50: error: parse error before '{' token
include/linux/thread_info.h:50: warning: type defaults to `int' in declaration
of `___res'
include/linux/thread_info.h:50: warning: data definition has no type or storage
class
include/linux/thread_info.h:50: error: parse error before '}' token
include/linux/thread_info.h: In function `set_ti_thread_flag':
include/linux/thread_info.h:57: error: structure has no member named `flags'
include/linux/thread_info.h:57: error: structure has no member named `flags'
include/linux/thread_info.h: In function `clear_ti_thread_flag':
include/linux/thread_info.h:62: error: structure has no member named `flags'
include/linux/thread_info.h:62: error: structure has no member named `flags'
include/linux/thread_info.h: In function `test_and_set_ti_thread_flag':
include/linux/thread_info.h:67: error: structure has no member named `flags'
include/linux/thread_info.h:67: error: structure has no member named `flags'
include/linux/thread_info.h: In function `test_and_clear_ti_thread_flag':
include/linux/thread_info.h:72: error: structure has no member named `flags'
include/linux/thread_info.h:72: error: structure has no member named `flags'
include/linux/thread_info.h: In function `test_ti_thread_flag':
include/linux/thread_info.h:77: error: structure has no member named `flags'
In file included from include/linux/spinlock.h:12,
from include/linux/capability.h:45,
from include/linux/sched.h:7,
from arch/m68k/kernel/asm-offsets.c:12:
include/linux/thread_info.h:80:41: macro set_need_resched passed 1 arguments,
but takes just 0
include/linux/thread_info.h: At top level:
include/linux/thread_info.h:81: error: syntax error before '{' token
include/linux/thread_info.h:85:43: macro clear_need_resched passed 1
arguments, but takes just 0
include/linux/thread_info.h:86: error: syntax error before '{' token
In file included from arch/m68k/kernel/asm-offsets.c:12:
include/linux/sched.h:1108: error: parse error before '{' token
include/linux/sched.h:1113: error: parse error before '{' token
include/linux/sched.h:1118: error: parse error before '{' token
include/linux/sched.h:1118: warning: type defaults to `int' in declaration of
`___res'
include/linux/sched.h:1118: warning: data definition has no type or storage
class
include/linux/sched.h:1118: error: parse error before '}' token
include/linux/sched.h:1118: warning: type defaults to `int' in declaration of
`__res'
include/linux/sched.h:1118: warning: data definition has no type or storage
class
include/linux/sched.h:1118: error: parse error before '}' token
include/linux/sched.h:1128: error: parse error before '{' token
include/linux/sched.h:1128: warning: type defaults to `int' in declaration of
`___res'
include/linux/sched.h:1128: warning: data definition has no type or
Re: Disk output lockup 2.6.12_rc2 2.6.11.7
Mikael Andersson wrote:
During heavy io-load a lockup occurs that appears to prevent any disk
output from taking place. fs is reiserfs on two device-mapper mirrored
200G maxtor disks. After the lockup occurs you can to things like 'ls',
but echo test.txt will hang.
fs is now ext3
A typical workload producing the error is doing:
rsync of large (1GB) over 100Mbit ethernet
simultaneous compilation / gunzip
Or almost anything that writes something to the disk.
I've disabled preemption, and tried with and without acpi enabled, with
and without smp support (it was smp by default so i switched it off).
Also tried with another nic (rtl8139) since i got an nv_stop_tx:
TransmitterStatus remained busy6 in the logs. I also tried 2.6.11.7
with the same result.
Tried converting to ext3, some problem, albeit the lockups are less
severe. More of the locked processes can be killed and echo test.txt
works. So _some_ io gets through.
The output from sysrq-T is somewhat less confusing though, it appears
then hung processes is somehow being hung in __generic_unplug_device, i
had a look at the assembler, but couldn't make heads or tails of it. the
code at __generic_unplug_device+19 was test %eax,%eax immediately
preceded by a callq to the test instruction. Obviously something magic
(by my eyes) is going on here.
Also tried 2.6.12_rc3-mm3
I'd really like to find a solution to this since it kinda borks the
nice an shiny machine if it can't handle large files without getting
into trouble.
I've been working on this for two days, have been trying to find
similar bug reports, trying a lot of different kernels and kernel
options to no avail.
I'm a little out of options right now, any ideas for something to try,
patches to test, or some help in understanding what's happening ?
kmirrord/0 D 81003f1bccd8 0 978 9 1731 977 (L-TLB)
Call Trace:
8016a2d6{cache_alloc_refill+1222}
804a2f9f{io_schedule+15}
--
kjournald D 81003e94bcd8 0 1748 1 2060 953 (L-TLB)
Call Trace:
802e9c13{__generic_unplug_device+19}
802e9cfd{generic_unplug_device+189}
--
rsync D 00701553dccf 0 6903 6901 (NOTLB)
Call Trace:
802e9c13{__generic_unplug_device+19}
802e9cfd{generic_unplug_device+189}
--
x86_64-pc-lin D 006dc7d23e49 0 13785 13742 (NOTLB)
Call Trace:
802e9cfd{generic_unplug_device+189}
8040e3ad{dm_unplug_all+29}
/Mikael Andersson
-
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: Linux 2.6.12-rc3
On Thu, 21 Apr 2005, Jan Dittmer wrote:
Linus Torvalds wrote:
Geert Uytterhoeven:
[PATCH] M68k: Update defconfigs for 2.6.11
[PATCH] M68k: Update defconfigs for 2.6.12-rc2
Why do I still get this error when trying to cross-compile for m68k?
Because to build m68k kernels, you (still :-( have to use the Linux/m68k CVS
repository, cfr. http://linux-m68k-cvs.ubb.ca/.
BTW, my patch queue is at
http://linux-m68k-cvs.ubb.ca/~geert/linux-m68k-2.6.x-merging/.
The main offender is POSTPONED/156-thread_info.diff.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
-
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/PATCH] unregister_node() for hotplug use
On Wed, 20 Apr 2005 14:35:10 +0200 Arjan van de Ven wrote: diff -puN drivers/base/node.c~numa_hp_base drivers/base/node.c --- linux-2.6.12-rc2-mm3/drivers/base/node.c~numa_hp_base 2005-04-14 20:49:37.0 +0900 +++ linux-2.6.12-rc2-mm3-kei/drivers/base/node.c2005-04-14 20:49:37.0 +0900 @@ -136,7 +136,7 @@ static SYSDEV_ATTR(distance, S_IRUGO, no +EXPORT_SYMBOL(register_node); +EXPORT_SYMBOL(unregister_node); +#endif /* CONFIG_HOTPLUG */ please make these EXPORT_SYMBOL_GPL; the rest of sysfs is too and this is very much deep kernel internals that are linux specific. OK, I will make that change. Thanks for the comments! Thanks, Keiichiro Tokunaga - 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/
COMPILE-ERROR: 'make prepare ARCH=um' fails on 2.6.11.7
Hello, 'make prepare ARCH=um' spits out some serious errors. 'make ARCH=um' works though - just takes ways longer ... Here are the 3 commands to reproduce plus the errornous output: - Stone:/usr/src/linux-2.6.11.7 # uname -a Linux Stone 2.6.11.7 #3 Wed Apr 20 14:03:23 CEST 2005 i686 athlon i386 GNU/Linux Stone:/usr/src/linux-2.6.11.7 # make mrproper CLEAN scripts/basic CLEAN scripts/kconfig CLEAN .config include/linux/autoconf.h Stone:/usr/src/linux-2.6.11.7 # make defconfig ARCH=um /dev/null /usr/src/linux-2.6.11.7/arch/um/defconfig:199: trying to assign nonexistent symbol KGDBOE /usr/src/linux-2.6.11.7/arch/um/defconfig:262: trying to assign nonexistent symbol REISER4_FS /usr/src/linux-2.6.11.7/arch/um/defconfig:282: trying to assign nonexistent symbol FSCACHE Stone:/usr/src/linux-2.6.11.7 # make prepare ARCH=um HOSTCC arch/um/sys-i386/util/mk_sc HOSTCC arch/um/kernel/skas/util/mk_ptregs-i386.o HOSTLD arch/um/kernel/skas/util/mk_ptregs CHK arch/um/include/skas_ptregs.h CHK arch/um/include/sysdep-i386/sc.h CHK arch/um/include/uml-config.h UPD arch/um/include/uml-config.h HOSTCC arch/um/util/mk_constants_kern.o HOSTCC arch/um/util/mk_constants_user.o HOSTCC arch/um/util/mk_task_kern.o In file included from include/linux/list.h:7, from include/linux/wait.h:23, from /usr/include/asm/semaphore.h:41, from include/linux/sched.h:19, from arch/um/util/mk_task_kern.c:1: include/linux/prefetch.h: In function `prefetch_range': include/linux/prefetch.h:64: error: `CONFIG_X86_L1_CACHE_SHIFT' undeclared (first use in this function) include/linux/prefetch.h:64: error: (Each undeclared identifier is reported only once include/linux/prefetch.h:64: error: for each function it appears in.) In file included from arch/um/util/mk_task_kern.c:1: include/linux/sched.h:23:25: asm/cputime.h: No such file or directory In file included from arch/um/util/mk_task_kern.c:1: include/linux/sched.h: At top level: include/linux/sched.h:318: error: parse error before cputime_t include/linux/sched.h:318: warning: no semicolon at end of struct or union include/linux/sched.h:332: error: parse error before '}' token include/linux/sched.h:597: error: parse error before cputime_t include/linux/sched.h:597: warning: no semicolon at end of struct or union include/linux/sched.h:598: warning: type defaults to `int' in declaration of `it_prof_value' include/linux/sched.h:598: warning: type defaults to `int' in declaration of `it_prof_incr' include/linux/sched.h:598: warning: data definition has no type or storage class include/linux/sched.h:600: error: parse error before utime include/linux/sched.h:600: warning: type defaults to `int' in declaration of `utime' include/linux/sched.h:600: warning: type defaults to `int' in declaration of `stime' include/linux/sched.h:600: warning: data definition has no type or storage class include/linux/sched.h:610: error: parse error before ':' token include/linux/sched.h:688: error: parse error before '}' token include/linux/sched.h: In function `process_group': include/linux/sched.h:692: error: dereferencing pointer to incomplete type include/linux/sched.h: In function `pid_alive': include/linux/sched.h:705: error: dereferencing pointer to incomplete type include/linux/sched.h: In function `dequeue_signal_lock': include/linux/sched.h:870: error: dereferencing pointer to incomplete type include/linux/sched.h:872: error: dereferencing pointer to incomplete type include/linux/sched.h: In function `on_sig_stack': include/linux/sched.h:912: error: dereferencing pointer to incomplete type include/linux/sched.h:912: error: dereferencing pointer to incomplete type include/linux/sched.h: In function `sas_ss_flags': include/linux/sched.h:917: error: dereferencing pointer to incomplete type include/linux/sched.h: In function `capable': include/linux/sched.h:928: error: dereferencing pointer to incomplete type include/linux/sched.h:929: error: dereferencing pointer to incomplete type include/linux/sched.h: In function `thread_group_empty': include/linux/sched.h:1026: error: dereferencing pointer to incomplete type include/linux/sched.h: In function `task_lock': include/linux/sched.h:1044: error: dereferencing pointer to incomplete type include/linux/sched.h: In function `task_unlock': include/linux/sched.h:1049: error: dereferencing pointer to incomplete type include/linux/sched.h: In function `set_tsk_thread_flag': include/linux/sched.h:1057: error: dereferencing pointer to incomplete type include/linux/sched.h: In function `clear_tsk_thread_flag': include/linux/sched.h:1062: error: dereferencing pointer to incomplete type include/linux/sched.h: In function `test_and_set_tsk_thread_flag': include/linux/sched.h:1067: error: dereferencing pointer to incomplete type include/linux/sched.h: In function `test_and_clear_tsk_thread_flag':
Re: Serious performance degradation on a RAID with kernel 2.6.10-bk7 and later
Hi! A small update. Patching mm/filemap.c is not necessary in order to get the improved performance! It's sufficient to remove roundup_pow_of_two from |get_init_ra_size ... So a simple one-liner changes to picture dramatically. But why ?!?!? roundup_pow_of_two() uses fls() and ia64 has buggy fls() implementation [ seems that David fixed it but patch is not in the mainline yet]: http://www.mail-archive.com/linux-ia64@vger.kernel.org/msg01196.html That would also explain why you couldn't reproduce the problem on ia32 Xeon machines. Bartlomiej - 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: /proc/cpuinfo format - arch dependent!
On Tue, Apr 19, 2005 at 09:24:17AM -0400, Lennart Sorensen wrote: If you change it now, how many tools would break? Maybe if you can list what statistics you think should be common to all systems, that could be presented in another file that is always the same format on each architecture. Certainly looking at arm and i386, other than the bogomips field there is nothing in common between their cpuinfo contents. THey don't even capitalize bogomips the same either. I doubt this is really doable. If all you want is the number of CPUs then something like sysconf(_SC_NPROCESSORS_CONF) should do. Which in glibc is implemented by counting the number of processor: records in /proc/cpuinfo, so simply Nico's parser seems to be insufficient. Ralf - 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: Development Model
On Tue, Apr 19, 2005 at 03:24:00PM -0400, Rik van Riel wrote: The current development model seems to go much smoother than anything I've seen before. It violates conventional wisdom and that psychological thing is the lion share of why some people feel uneasy about it. Dealing with the parallel work on 2.4 and 2.5 was very much like the attempt of drinking from a firehose, so I'm very happy only having only to deal with 2.6, not 2.7 also. Ralf - 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] introduce generic 64bit rotations and i386 asm optimized version
On Tue, Apr 19, 2005 at 10:20:38PM +0200, Domen Puncer wrote: Please keep using __inline__, not inline. Why? Couldn't find any threads about this, and even SubmittingPatches has: 'static inline' is preferred over 'static __inline__'... Unlike inline __inline__ will be recogniced by gcc even in -ansi mode. And inline is namespace pollution. Where there's no technical reason I prefer the non-underscore version, __inline__ is just looking too 1337 and eye-insulting. Of course all these thoughts are useless because these days usespace is not supposed to use kernel headers directly and the kernel isn't ANSI-clean anyway. Ralf - 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] kill old EH constants
On Wed, 20 Apr 2005, Linux Kernel Mailing List wrote:
tree 932c6f9689fd08a7a9d689cfbec8682ccde8175d
parent 84011ae88da62a20b3ae7b48e2ae3b1ef0fc810a
author [EMAIL PROTECTED] Mon, 11 Apr 2005 08:19:25 -0500
committer James Bottomley [EMAIL PROTECTED] Sun, 17 Apr 2005 06:14:52 -0500
[PATCH] kill old EH constants
Fix up two drivers that incorrectly were using the old return values for
their new-style EH methods and kill off scsi_obsolete.h that defined the
constants. The initio driver has all these constansts defined locally
and uses them internally, I'll fix that up some time later.
Signed-off-by: James Bottomley [EMAIL PROTECTED]
sun3_NCR5380.c still uses the following:
- SCSI_ABORT_SUCCESS
- SCSI_ABORT_ERROR
- SCSI_ABORT_SNOOZE
- SCSI_ABORT_BUSY
- SCSI_ABORT_NOT_RUNNING
- SCSI_RESET_SUCCESS
- SCSI_RESET_BUS_RESET
causing the driver to fail to build in 2.6.12-rc3. What should I replace them
by?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
-
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] kill old EH constants
On Thu, Apr 21, 2005 at 11:58:12AM +0200, Geert Uytterhoeven wrote: sun3_NCR5380.c still uses the following: - SCSI_ABORT_SUCCESS - SCSI_ABORT_ERROR - SCSI_ABORT_SNOOZE - SCSI_ABORT_BUSY - SCSI_ABORT_NOT_RUNNING - SCSI_RESET_SUCCESS - SCSI_RESET_BUS_RESET causing the driver to fail to build in 2.6.12-rc3. What should I replace them by? You must replace NCR5380_abort and NCR5380_bus_reset with real new-style EH routines. I'd suggest copying them from NCR5380.c or even better scrapping sun3_NCR5380.c in favour of that one completely. - 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: [2.6 patch] drivers/net/hamradio/baycom_epp.c: cleanups
On 4/20/05, Adrian Bunk [EMAIL PROTECTED] wrote: The times when tricky goto's produced better codes are long gone. This patch should express the same in a better way, please check whether I made any mistake. By the way, it solves compile errors with gcc-4: a lot of drivers/net/hamradio/baycom_epp.c:690: error: jump into statement expression regards, Benoit - 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: Git-commits mailing list feed.
On Thu, 2005-04-21 at 14:22 +1000, David Woodhouse wrote: As of some time in the fairly near future, the [EMAIL PROTECTED] mailing list will be carrying real commits from Linus' live git repository, instead of just testing patches. Have fun. with BK this was not possible, but could we please have -p added to the diff parameters with git ? It makes diffs a LOT more reasable! - 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/
strange incremental patch size [2.6.12-rc2 to 2.6.12-rc3]
Hi, These are the sizes of rc2 and rc3 patches # ls -la patch-2.6.12* -rw-r--r-- 1 root src 18011382 Apr 4 18:50 patch-2.6.12-rc2 -rw-r--r-- 1 root src 19979854 Apr 21 02:29 patch-2.6.12-rc3 Let us make an incremental patch from rc2 to rc3 # interdiff patch-2.6.12-rc2 patch-2.6.12-rc3 x Let us see how big it is. # ls -ld x -rw-r--r-- 1 root src 37421924 Apr 21 12:28 x How come interdiff from rc2 (18MB) to rc3 (20MB) gave me 37MB worth of patch-code ? I would expect something about 2MB but 40MB ? The patching with the incremental patch took very long compared to other rc2-rc3-type patches, that is how I noticed it. Regards, Maciej - 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] hpt366: HPT372N rev 2 controller fix
On Iau, 2005-04-21 at 06:54, Albert Lee wrote: A particular revision of the HPT372N oopses hpt366 consistently. It's a regression caused by Alan's changes in 2.6.9 to support the HPT372N using only PLL timings. The driver works correctly in prior versions, where the the PCI clock is used instead. This patch restores that behaviour for this particular revision. For some drives, if you are lucky. The problem is that the PLL code in the hpt366 driver is simply wrong. The -ac tree has some cleanup work in this area but hasn't fixed the PLL code yet. The vendor driver does handle this chip correctly. Linus please avoid this patch - better an oops than disk corruption. Alan - 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] Bad rounding in timeval_to_jiffies [was: Re: Odd Timer behavior in 2.6 vs 2.4 (1 extra tick)]
On Thu, 2005-04-21 at 09:51 +0100, Russell King wrote: [...] The problem is that when you add a timer, you don't have any idea which point you're going to be starting your timer at. This is why we always round up to the next jiffy when we convert times to jiffies - this ensures that you will get at _least_ the timeout you requested, which is in itself a very important guarantee. Thanks, I forgot about the guarantee of at least the time requested. I took this on because I noticed this in a driver I wrote. With the user passing in a timeval for a periodic condition. I noticed that this would drift quite a bit. I guess I need to write my own timeval_to_jiffies conversion so that i remove the added jiffy. For this case, I actually want a true rounded value to the closest jiffy. Thanks again, -- Steve - 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] swsusp: documentation updates
This updates documentation and fixes pointers in MAINTAINERS file. Signed-off-by: Pavel Machek [EMAIL PROTECTED] --- clean/Documentation/power/swsusp.txt2005-01-22 21:24:50.0 +0100 +++ linux/Documentation/power/swsusp.txt2005-04-17 21:06:32.0 +0200 @@ -164,11 +171,11 @@ should be held at that point and it must be safe to sleep there), and add: -if (current-flags PF_FREEZE) -refrigerator(PF_FREEZE); + try_to_freeze(PF_FREEZE); If the thread is needed for writing the image to storage, you should -instead set the PF_NOFREEZE process flag when creating the thread. +instead set the PF_NOFREEZE process flag when creating the thread (and +be very carefull). Q: What is the difference between between platform, shutdown and @@ -233,3 +240,81 @@ cat `cat /proc/[0-9]*/maps | grep / | sed 's:.* /:/:' | sort -u` /dev/null after resume. swapoff -a; swapon -a may also be usefull. + +Q: What happens to devices during swsusp? They seem to be resumed +during system suspend? + +A: That's correct. We need to resume them if we want to write image to +disk. Whole sequence goes like + + Suspend part + + running system, user asks for suspend-to-disk + + user processes are stopped + + suspend(PMSG_FREEZE): devices are frozen so that they don't interfere + with state snapshot + + state snapshot: copy of whole used memory is taken with interrupts disabled + + resume(): devices are woken up so that we can write image to swap + + write image to swap + + suspend(PMSG_SUSPEND): suspend devices so that we can power off + + turn the power off + + Resume part + ~~~ + (is actually pretty similar) + + running system, user asks for suspend-to-disk + + user processes are stopped (in common case there are none, but with resume-from-initrd, noone knows) + + read image from disk + + suspend(PMSG_FREEZE): devices are frozen so that they don't interfere + with image restoration + + image restoration: rewrite memory with image + + resume(): devices are woken up so that system can continue + + thaw all user processes + +Q: What is this 'Encrypt suspend image' for? + +A: First of all: it is not a replacement for dm-crypt encrypted swap. +It cannot protect your computer while it is suspended. Instead it does +protect from leaking sensitive data after resume from suspend. + +Think of the following: you suspend while an application is running +that keeps sensitive data in memory. The application itself prevents +the data from being swapped out. Suspend, however, must write these +data to swap to be able to resume later on. Without suspend encryption +your sensitive data are then stored in plaintext on disk. This means +that after resume your sensitive data are accessible to all +applications having direct access to the swap device which was used +for suspend. If you don't need swap after resume these data can remain +on disk virtually forever. Thus it can happen that your system gets +broken in weeks later and sensitive data which you thought were +encrypted and protected are retrieved and stolen from the swap device. +To prevent this situation you should use 'Encrypt suspend image'. + +During suspend a temporary key is created and this key is used to +encrypt the data written to disk. When, during resume, the data was +read back into memory the temporary key is destroyed which simply +means that all data written to disk during suspend are then +inaccessible so they can't be stolen later on. The only thing that +you must then take care of is that you call 'mkswap' for the swap +partition used for suspend as early as possible during regular +boot. This asserts that any temporary key from an oopsed suspend or +from a failed or aborted resume is erased from the swap device. + +As a rule of thumb use encrypted swap to protect your data while your +system is shut down or suspended. Additionally use the encrypted +suspend image to prevent sensitive data from being stolen after +resume. --- clean/MAINTAINERS 2005-04-21 12:00:27.0 +0200 +++ linux/MAINTAINERS 2005-04-21 12:02:36.0 +0200 @@ -2090,9 +2090,7 @@ SOFTWARE SUSPEND: P: Pavel Machek M: [EMAIL PROTECTED] -M: [EMAIL PROTECTED] -L: http://lister.fornax.hu/mailman/listinfo/swsusp -W: http://swsusp.sf.net/ +L: [EMAIL PROTECTED] S: Maintained SONIC NETWORK DRIVER -- Boycott Kodak -- for their patent abuse against Java. - 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: strange incremental patch size [2.6.12-rc2 to 2.6.12-rc3]
Maciej Soltysiak wrote: Hi, These are the sizes of rc2 and rc3 patches # ls -la patch-2.6.12* -rw-r--r-- 1 root src 18011382 Apr 4 18:50 patch-2.6.12-rc2 -rw-r--r-- 1 root src 19979854 Apr 21 02:29 patch-2.6.12-rc3 Let us make an incremental patch from rc2 to rc3 # interdiff patch-2.6.12-rc2 patch-2.6.12-rc3 x Let us see how big it is. # ls -ld x -rw-r--r-- 1 root src 37421924 Apr 21 12:28 x How come interdiff from rc2 (18MB) to rc3 (20MB) gave me 37MB worth of patch-code ? I would expect something about 2MB but 40MB ? The order in the patch changed a lot. The rc2 patch starts with the changes in the CREDITS file and the rc3 patch has those starting at line 151839. This is probably because Linus now uses different tools to produce these. Maybe you can somehow sort the rc2 patch in the same way as the rc3 patch (same file order) before using interdiff, that should solve it. Joost The patching with the incremental patch took very long compared to other rc2-rc3-type patches, that is how I noticed it. Regards, Maciej - 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/ smime.p7s Description: S/MIME Cryptographic Signature
Re: x86_64: Bug in new out of line put_user()
On Thu, Apr 21, 2005 at 01:10:09AM +0200, Alexander Nyberg wrote: The new out of line put_user() assembly on x86_64 changes %rcx without telling GCC about it causing things like: http://bugme.osdl.org/show_bug.cgi?id=4515 See to it that %rcx is not changed (made it consistent with get_user()). Damn. I actually fixed this before submission, but it looks like the old patch staid in the queue :-( Sorry for you having to debug it again. Linus, can can you please apply the patch? -Andi Signed-off-by: Alexander Nyberg [EMAIL PROTECTED] Index: test/arch/x86_64/lib/getuser.S === --- test.orig/arch/x86_64/lib/getuser.S 2005-04-20 23:55:35.0 +0200 +++ test/arch/x86_64/lib/getuser.S2005-04-21 00:54:16.0 +0200 @@ -78,9 +78,9 @@ __get_user_8: GET_THREAD_INFO(%r8) addq $7,%rcx - jc bad_get_user + jc 40f cmpq threadinfo_addr_limit(%r8),%rcx - jae bad_get_user + jae 40f subq$7,%rcx 4: movq (%rcx),%rdx xorl %eax,%eax Index: test/arch/x86_64/lib/putuser.S === --- test.orig/arch/x86_64/lib/putuser.S 2005-04-21 00:50:24.0 +0200 +++ test/arch/x86_64/lib/putuser.S2005-04-21 01:02:15.0 +0200 @@ -46,36 +46,45 @@ __put_user_2: GET_THREAD_INFO(%r8) addq $1,%rcx - jc bad_put_user + jc 20f cmpq threadinfo_addr_limit(%r8),%rcx - jae bad_put_user -2: movw %dx,-1(%rcx) + jae 20f +2: decq %rcx + movw %dx,(%rcx) xorl %eax,%eax ret +20: decq %rcx + jmp bad_put_user .p2align 4 .globl __put_user_4 __put_user_4: GET_THREAD_INFO(%r8) addq $3,%rcx - jc bad_put_user + jc 30f cmpq threadinfo_addr_limit(%r8),%rcx - jae bad_put_user -3: movl %edx,-3(%rcx) + jae 30f +3: subq $3,%rcx + movl %edx,(%rcx) xorl %eax,%eax ret +30: subq $3,%rcx + jmp bad_put_user .p2align 4 .globl __put_user_8 __put_user_8: GET_THREAD_INFO(%r8) addq $7,%rcx - jc bad_put_user + jc 40f cmpq threadinfo_addr_limit(%r8),%rcx - jae bad_put_user -4: movq %rdx,-7(%rcx) + jae 40f +4: subq $7,%rcx + movq %rdx,(%rcx) xorl %eax,%eax ret +40: subq $7,%rcx + jmp bad_put_user bad_put_user: movq $(-EFAULT),%rax - 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] X86_64: fix hpet for systems that don't support legacy replacement (v. A2)
On Tue, Apr 19, 2005 at 06:41:00PM -0700, john stultz wrote:
Andrew, All,
Currently the x86-64 HPET code assumes the entire HPET implementation
from the spec is present. This breaks on boxes that do not implement the
optional legacy timer replacement functionality portion of the spec.
This patch fixes this issue, allowing x86-64 systems that cannot use the
HPET for the timer interrupt and RTC to still use the HPET as a time
source. I've tested this patch on a system systems without HPET, with
HPET but without legacy timer replacement, as well as HPET with legacy
timer replacement.
I'm currently working on a similar patch for i386.
You should it get reviewed by Vojtech who wrote the original x86-64 HPET
code.
-Andi
Please consider for your tree.
thanks
-john
Changelog:
A0: First sent to lkml
A1: Implemented suggestions from Venkatesh
A2: Whitespace cleanup.
linux-2.6.12-rc2_hpet-nolegacy-fix_A2.patch
===
diff -Nru a/arch/x86_64/kernel/time.c b/arch/x86_64/kernel/time.c
--- a/arch/x86_64/kernel/time.c 2005-04-19 18:28:49 -07:00
+++ b/arch/x86_64/kernel/time.c 2005-04-19 18:28:49 -07:00
@@ -60,6 +60,7 @@
unsigned int cpu_khz;/* TSC clocks /
usec, not used here */
static unsigned long hpet_period;/* fsecs / HPET clock */
unsigned long hpet_tick; /* HPET clocks /
interrupt */
+static int hpet_use_timer;
unsigned long vxtime_hz = PIT_TICK_RATE;
int report_lost_ticks; /* command line option
*/
unsigned long long monotonic_base;
@@ -297,7 +298,7 @@
last_offset = vxtime.last;
base = monotonic_base;
- this_offset = hpet_readl(HPET_T0_CMP) - hpet_tick;
+ this_offset = hpet_readl(HPET_COUNTER);
} while (read_seqretry(xtime_lock, seq));
offset = (this_offset - last_offset);
@@ -373,7 +374,14 @@
write_seqlock(xtime_lock);
- if (vxtime.hpet_address) {
+ if (vxtime.hpet_address)
+ offset = hpet_readl(HPET_COUNTER);
+
+ if (hpet_use_timer) {
+ /* if we're using the hpet timer functionality,
+ * we can more accurately know the counter value
+ * when the timer interrupt occured.
+ */
offset = hpet_readl(HPET_T0_CMP) - hpet_tick;
delay = hpet_readl(HPET_COUNTER) - offset;
} else {
@@ -794,17 +802,18 @@
* Set up timer 0, as periodic with first interrupt to happen at hpet_tick,
* and period also hpet_tick.
*/
-
- hpet_writel(HPET_TN_ENABLE | HPET_TN_PERIODIC | HPET_TN_SETVAL |
+ if (hpet_use_timer) {
+ hpet_writel(HPET_TN_ENABLE | HPET_TN_PERIODIC | HPET_TN_SETVAL |
HPET_TN_32BIT, HPET_T0_CFG);
- hpet_writel(hpet_tick, HPET_T0_CMP);
- hpet_writel(hpet_tick, HPET_T0_CMP); /* AK: why twice? */
-
+ hpet_writel(hpet_tick, HPET_T0_CMP);
+ hpet_writel(hpet_tick, HPET_T0_CMP); /* AK: why twice? */
+ cfg |= HPET_CFG_LEGACY;
+ }
/*
* Go!
*/
- cfg |= HPET_CFG_ENABLE | HPET_CFG_LEGACY;
+ cfg |= HPET_CFG_ENABLE;
hpet_writel(cfg, HPET_CFG);
return 0;
@@ -825,8 +834,7 @@
id = hpet_readl(HPET_ID);
- if (!(id HPET_ID_VENDOR) || !(id HPET_ID_NUMBER) ||
- !(id HPET_ID_LEGSUP))
+ if (!(id HPET_ID_VENDOR) || !(id HPET_ID_NUMBER))
return -1;
hpet_period = hpet_readl(HPET_PERIOD);
@@ -836,6 +844,8 @@
hpet_tick = (10L * (USEC_PER_SEC / HZ) + hpet_period / 2) /
hpet_period;
+ hpet_use_timer = (id HPET_ID_LEGSUP);
+
return hpet_timer_stop_set_go(hpet_tick);
}
@@ -892,9 +902,11 @@
set_normalized_timespec(wall_to_monotonic,
-xtime.tv_sec, -xtime.tv_nsec);
- if (!hpet_init()) {
+ if (!hpet_init())
vxtime_hz = (1000L + hpet_period / 2) /
hpet_period;
+
+ if (hpet_use_timer) {
cpu_khz = hpet_calibrate_tsc();
timename = HPET;
} else {
@@ -940,12 +952,12 @@
if (oem_force_hpet_timer())
notsc = 1;
if (vxtime.hpet_address notsc) {
- timetype = HPET;
+ timetype = hpet_use_timer ? HPET : PIT/HPET;
vxtime.last = hpet_readl(HPET_T0_CMP) - hpet_tick;
vxtime.mode = VXTIME_HPET;
do_gettimeoffset = do_gettimeoffset_hpet;
} else {
- timetype = vxtime.hpet_address ? HPET/TSC : PIT/TSC;
+ timetype = hpet_use_timer ? HPET/TSC : PIT/TSC;
vxtime.mode = VXTIME_TSC;
}
-
To unsubscribe from this list: send the line unsubscribe
[patch] properly stop devices before poweroff
Without this patch, Linux provokes emergency disk shutdowns and similar nastiness. It was in SuSE kernels for some time, IIRC. Signed-off-by: Pavel Machek [EMAIL PROTECTED] --- clean/kernel/sys.c 2005-03-19 00:32:32.0 +0100 +++ linux/kernel/sys.c 2005-03-22 12:20:53.0 +0100 @@ -404,6 +404,7 @@ case LINUX_REBOOT_CMD_HALT: notifier_call_chain(reboot_notifier_list, SYS_HALT, NULL); system_state = SYSTEM_HALT; + device_suspend(PMSG_SUSPEND); device_shutdown(); printk(KERN_EMERG System halted.\n); machine_halt(); @@ -414,6 +415,7 @@ case LINUX_REBOOT_CMD_POWER_OFF: notifier_call_chain(reboot_notifier_list, SYS_POWER_OFF, NULL); system_state = SYSTEM_POWER_OFF; + device_suspend(PMSG_SUSPEND); device_shutdown(); printk(KERN_EMERG Power down.\n); machine_power_off(); @@ -430,6 +432,7 @@ notifier_call_chain(reboot_notifier_list, SYS_RESTART, buffer); system_state = SYSTEM_RESTART; + device_suspend(PMSG_FREEZE); device_shutdown(); printk(KERN_EMERG Restarting system with command '%s'.\n, buffer); machine_restart(buffer); -- Boycott Kodak -- for their patent abuse against Java. - 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] acpi: fix video docs
This fixes typos/formatting in video_extension.txt. Signed-off-by: Pavel Machek [EMAIL PROTECTED] --- clean/Documentation/power/video_extension.txt 2004-12-25 13:34:57.0 +0100 +++ linux/Documentation/power/video_extension.txt 2005-03-22 12:20:53.0 +0100 @@ -1,13 +1,16 @@ -This driver implement the ACPI Extensions For Display Adapters -for integrated graphics devices on motherboard, as specified in -ACPI 2.0 Specification, Appendix B, allowing to perform some basic -control like defining the video POST device, retrieving EDID information -or to setup a video output, etc. Note that this is an ref. implementation only. -It may or may not work for your integrated video device. +ACPI video extensions +~ + +This driver implement the ACPI Extensions For Display Adapters for +integrated graphics devices on motherboard, as specified in ACPI 2.0 +Specification, Appendix B, allowing to perform some basic control like +defining the video POST device, retrieving EDID information or to +setup a video output, etc. Note that this is an ref. implementation +only. It may or may not work for your integrated video device. Interfaces exposed to userland through /proc/acpi/video: -VGA/info : display the supported video bus device capability like ,Video ROM, CRT/LCD/TV. +VGA/info : display the supported video bus device capability like Video ROM, CRT/LCD/TV. VGA/ROM : Used to get a copy of the display devices' ROM data (up to 4k). VGA/POST_info : Used to determine what options are implemented. VGA/POST : Used to get/set POST device. @@ -15,7 +18,7 @@ Please refer ACPI spec B.4.1 _DOS VGA/CRT : CRT output VGA/LCD : LCD output -VGA/TV : TV output +VGA/TVO : TV output VGA/*/brightness : Used to get/set brightness of output device Notify event through /proc/acpi/event: -- Boycott Kodak -- for their patent abuse against Java. - 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] hp100: fix card names
Those cards really need A in their names. Otherwise it is pretty hard to find anything about them on the net. Signed-off-by: Pavel Machek [EMAIL PROTECTED] --- clean/drivers/net/hp100.c 2005-03-03 12:34:19.0 +0100 +++ linux/drivers/net/hp100.c 2005-03-22 12:20:53.0 +0100 @@ -13,8 +13,8 @@ ** This driver has only been tested with ** -- HP J2585B 10/100 Mbit/s PCI Busmaster ** -- HP J2585A 10/100 Mbit/s PCI -** -- HP J2970 10 Mbit/s PCI Combo 10base-T/BNC -** -- HP J2973 10 Mbit/s PCI 10base-T +** -- HP J2970A 10 Mbit/s PCI Combo 10base-T/BNC +** -- HP J2973A 10 Mbit/s PCI 10base-T ** -- HP J2573 10/100 ISA ** -- Compex ReadyLink ENET100-VG4 10/100 Mbit/s PCI / EISA ** -- Compex FreedomLine 100/VG 10/100 Mbit/s ISA / EISA / PCI -- Boycott Kodak -- for their patent abuse against Java. - 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] s-t-RAM: load gdt the right way
Sleep code uses wrong version of lgdt, that does the wrong thing when gdt is beyond 16MB or so... Signed-off-by: Pavel Machek [EMAIL PROTECTED] --- clean/arch/i386/kernel/acpi/wakeup.S2005-01-22 21:24:51.0 +0100 +++ linux/arch/i386/kernel/acpi/wakeup.S2005-04-14 22:29:45.0 +0200 @@ -74,8 +90,9 @@ movw%ax,%fs movw$0x0e00 + 'i', %fs:(0x12) - # need a gdt - lgdtreal_save_gdt - wakeup_code + # need a gdt -- use lgdtl to force 32-bit operands, in case + # the GDT is located past 16 megabytes + lgdtl real_save_gdt - wakeup_code movlreal_save_cr0 - wakeup_code, %eax movl%eax, %cr0 --- clean/arch/x86_64/kernel/acpi/wakeup.S 2005-01-22 21:24:51.0 +0100 +++ linux/arch/x86_64/kernel/acpi/wakeup.S 2005-04-14 22:34:18.0 +0200 @@ -67,7 +67,7 @@ shll$4, %eax addl$(gdta - wakeup_code), %eax movl%eax, gdt_48a +2 - wakeup_code - lgdt%ds:gdt_48a - wakeup_code # load gdt with whatever is + lgdtl %ds:gdt_48a - wakeup_code # load gdt with whatever is # appropriate movl$1, %eax# protected mode (PE) bit -- Boycott Kodak -- for their patent abuse against Java. - 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] swsusp: kill config_pm_disk
CONFIG_PM_DISK is long gone, but it still managed to survived at few places. Signed-off-by: Pavel Machek [EMAIL PROTECTED] --- clean/arch/i386/mm/init.c 2005-03-19 00:31:06.0 +0100 +++ linux/arch/i386/mm/init.c 2005-03-25 09:08:37.0 +0100 @@ -352,7 +352,7 @@ #endif } -#if defined(CONFIG_PM_DISK) || defined(CONFIG_SOFTWARE_SUSPEND) +#ifdef CONFIG_SOFTWARE_SUSPEND /* * Swap suspend friends need this for resume because things like the intel-agp * driver might have split up a kernel 4MB mapping. --- clean/mm/page_io.c 2005-04-05 10:55:35.0 +0200 +++ linux/mm/page_io.c 2005-04-05 10:57:21.0 +0200 @@ -127,7 +127,7 @@ return ret; } -#if defined(CONFIG_SOFTWARE_SUSPEND) || defined(CONFIG_PM_DISK) +#ifdef CONFIG_SOFTWARE_SUSPEND /* * A scruffy utility function to read or write an arbitrary swap page * and wait on the I/O. The caller must have a ref on the page. --- clean/arch/i386/defconfig 2005-03-19 00:31:05.0 +0100 +++ linux/arch/i386/defconfig 2005-03-25 09:08:37.0 +0100 @@ -126,7 +126,6 @@ # CONFIG_PM=y CONFIG_SOFTWARE_SUSPEND=y -# CONFIG_PM_DISK is not set # # ACPI (Advanced Configuration and Power Interface) Support -- Boycott Kodak -- for their patent abuse against Java. - 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: nVidia stuff again
Dave Airlie wrote: The main reasons they don't like open source is from where I'm standing, their IP lawyers and probably not being able to do sneaky hacks in the driver because people can see them.. Well . . . if *that* is a reason for disliking open source then the problem is solved. We don't really need the source for their driver with the sneaky hacks exposed. They could keep a proprietary driver with nasty hacks, and release a simplified one (basically the same code with those hacks removed) along with the specs. Open source developers can then add their own hacks if need be. Helge Hafting - 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/
journal_callback_set
Hi, I noticed, that starting from 2.6.10, the function (fs/jbd/transaction.c) void journal_callback_set(handle_t *handle, void (*func)(struct journal_callback *jcb, int error), struct journal_callback *jcb) along with the structure members of handle_s (include/linux/jbd.h) struct list_headh_jcb; and the following members of transaction_s spinlock_t t_jcb_lock; struct list_headt_jcb; has been removed. Since I didn't find any discussion of this on this list or anywhere else on the web, I wondered about the motivation behind this, and how code that references these function/members should be modified. Is it dangerous to reinclude the eliminated parts of the code? Please reply to me personnally, since I am not subscribed to the list. 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/
Re: Linux 2.6.12-rc3
Hi! And for the crazy people, the git archive on kernel.org is up and running under /pub/scm/linux/kernel/git/torvalds/linux-2.6.git. For the adventurous of you, the name of the 2.6.12-rc3 release is a very nice and readable: a2755a80f40e5794ddc20e00f781af9d6320fafb and eventually I'll try to make sure that I actually accompany all releases with the SHA1 git name of the release signed with a digital signature. As far as I can see... (working with pasky's version of git) You should put this into .git/remotes linus rsync://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Then RSYNC_FLAGS=-zavP git pull linus should do the right thing. [pasky, would it be possible to make some kind of progress indication default for long pulls?] One of the tools I don't have set up yet is the old shortlog script, so I did this really hacky conversion. You don't want to know, but let's say that I'm re-aquainting myself with 'sed' after a long time ;). But if some lines look like they got hacked up in the middle, rest assured that that's exactly what happened, and the long log should have the rest ... -- Boycott Kodak -- for their patent abuse against Java. - 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] properly stop devices before poweroff
On 21/04/2005 12:13:46 linux-kernel-owner wrote: Without this patch, Linux provokes emergency disk shutdowns and similar nastiness. It was in SuSE kernels for some time, IIRC. OMG! And I did try to raise that issue 10 months ago, see below: http://www.ussg.iu.edu/hypermail/linux/kernel/0406.0/0242.html - 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: Serious performance degradation on a RAID with kernel 2.6.10-bk7 and later
Hi, The fls() patch from David solves the problem :-)) Do you have an idea, when it will be in the mainline kernel?? Andreas Bartlomiej ZOLNIERKIEWICZ wrote: Hi! A small update. Patching mm/filemap.c is not necessary in order to get the improved performance! It's sufficient to remove roundup_pow_of_two from |get_init_ra_size ... So a simple one-liner changes to picture dramatically. But why ?!?!? roundup_pow_of_two() uses fls() and ia64 has buggy fls() implementation [ seems that David fixed it but patch is not in the mainline yet]: http://www.mail-archive.com/linux-ia64@vger.kernel.org/msg01196.html That would also explain why you couldn't reproduce the problem on ia32 Xeon machines. Bartlomiej - 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] properly stop devices before poweroff
Hi! Without this patch, Linux provokes emergency disk shutdowns and similar nastiness. It was in SuSE kernels for some time, IIRC. OMG! And I did try to raise that issue 10 months ago, see below: http://www.ussg.iu.edu/hypermail/linux/kernel/0406.0/0242.html Heh, verify that this patch works for you and it might finally get fixed... Pavel -- Boycott Kodak -- for their patent abuse against Java. - 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: [discuss] [Patch] X86_64 TASK_SIZE cleanup
On Thu, Apr 21, 2005 at 01:17:40AM +0800, Zou, Nanhai wrote: Hi Andi, What is your comment on this patch? There is at least one wrong change in there, you have a check for test_thread_flag(TIF_IA32) (flags MAP_32BIT) and that is wrong because MAP_32BIT is used from 64bit code -Andi - 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: [discuss] [Patch] X86_64 TASK_SIZE cleanup - more comments
Another comment: In general I am not too happy about the variable size TASK_SIZE. There was a patch for this earlier, but it broke 32bit emulation completely. And I think it needs auditing of all uses of TASK_SIZE, because I suspect there are more bugs lurking in it. The way hugetlb etc. mmap were supposed to be handled was to let the mmap succeed and then check in the mmap wrapper if any address is 4GB and free it. Probably that code has some problems or got broken (I think it worked at least in 2.4, but there might have been regressions later) -Andi - 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: x86-64 Uncorrected machine check panic on boot
On Tue, Apr 19, 2005 at 10:12:43PM +0900, Akinobu Mita wrote:
Hello,
I got the following Machine Check Exception on 4-way Opteron Server.
I've tried 2.6.11.7 and 2.6.12-rc2.
The kernel parameter nomce could help to boot it up.
Sounds like a bogus BIOS. It should disable these machine checks
for timeout on pci config access imho.
What 4way board did you use? Can you check if there is a BIOS
update?
-Andi
I wrote this panic messages by hand.
This panic seems to happen around arch/x86_64/pci/../../i386/pci/direct.c:28
==
Calling initcall 0x: netlink_proto_init...
NET: Registered protocol family 16
Calling initcall 0x: pcibus_class_init...
Calling initcall 0x: pci_driver_init
Calling initcall 0x: tty_class_init
Calling initcall 0x: mtrr_if_init
Calling initcall 0x: pci_direct_init
CPU3: Machine Check Exception: 7 Bank 3: b400083b
RIP 10: 802cfefe {pci_conf1_read+0xce/0x110}
TSC 85ece4f ADDR fdfc000cfe
kernel panic - not syncing: Uncorrected machine check
==
$ addr2line -e vmlinux 802cfee0
arch/x86_64/pci/../../i386/pci/direct.c:28
$ addr2line -e vmlinux 802cfee2
include/asm/io.h:81
$ addr2line -e vmlinux 802cfefe
include/asm/io.h:84
-
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: Linux 2.6.12-rc3
Hi! And for the crazy people, the git archive on kernel.org is up and running under /pub/scm/linux/kernel/git/torvalds/linux-2.6.git. For the adventurous of you, the name of the 2.6.12-rc3 release is a very nice and readable: a2755a80f40e5794ddc20e00f781af9d6320fafb and eventually I'll try to make sure that I actually accompany all releases with the SHA1 git name of the release signed with a digital signature. As far as I can see... (working with pasky's version of git) You should put this into .git/remotes linus rsync://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Then RSYNC_FLAGS=-zavP git pull linus should do the right thing. Well, not sure. I did git track linus git cancel but Makefile still contains -rc2. (Is git cancel right way to check out the tree?) and git diff -r linus: still contains some changes. [I did some experimental pull of scsi changes long time ago, is it that problem?] Pavel -- Boycott Kodak -- for their patent abuse against Java. - 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: Linux 2.6.12-rc3
On Thu, 2005-04-21 at 13:20 +0200, Pavel Machek wrote: Hi! And for the crazy people, the git archive on kernel.org is up and running under /pub/scm/linux/kernel/git/torvalds/linux-2.6.git. For the adventurous of you, the name of the 2.6.12-rc3 release is a very nice and readable: a2755a80f40e5794ddc20e00f781af9d6320fafb and eventually I'll try to make sure that I actually accompany all releases with the SHA1 git name of the release signed with a digital signature. As far as I can see... (working with pasky's version of git) You should put this into .git/remotes linus rsync://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Then RSYNC_FLAGS=-zavP git pull linus should do the right thing. From 0.5 or 0.6 you just have to do: git init rsync://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git [pasky, would it be possible to make some kind of progress indication default for long pulls?] Latest seems to do the rsync verbose. -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: nVidia stuff again
On Thu, 2005-04-21 at 09:12 +1000, Dave Airlie wrote: But *that's* the point people keep ignoring: the specs for programming the hardware, in some cases, reveals details about the hardware's implementation that nVidia does *not* want to release (in addition to suggesting their software tricks). Why is it that people *assume* that just the programming docs tells a person nothing about the hardware? We already know that knowing the registers of a card and what those registers do tells you implicit information about the card's design and also reveals implicit information about the design of software that works with the card. How complex the card's registers and programming interface is determines how much you can infer, and the more RISC like or simple the card is and the more that is handled in the driver, the more obviously the design can be inferred just from the programming specs. I think the programming specs for a 3D graphics card can tell you very little about it, the R200 specs are very good but I doubt anyone would have a clue how to design the internals of the card just from looking at them, and now that GPUs are getting more like CPUs in terms of shaders and programming languages the specs are getting less and less useful to tell what is actually going on Ha! That's the whole damn point Dave. Use your head. Just because ATI is getting more complex with their GPU does *not* mean nVidia is. Go back to my original example of the aic7xxx cards. The alternative to their simple hardware design is something like the BusLogic or QLogic cards that are far more complex. Your assuming that because the ATI cards are getting more complex and people are less able to discern their makeup just by reading the specs that the nVidia cards are doing the same, nVidia is telling you otherwise, and you are just blowing that off as though you know more about their cards than they do. Reality is that they *could* be telling the truth and the fact that their card is a more simplistic card than ATIs may be the very reason that ATI has ponied up specs and they haven't. Therefore, you can reliably discern absolutely *zero* information about the nVidia cards from a reference to ATI specs. The main reasons they don't like open source is from where I'm standing, their IP lawyers and probably not being able to do sneaky hacks in the driver because people can see them.. It's what you know, not what you think you know, that matters. I don't know why nVidia keeps their specs secret. All I know is what they tell the world. But what I do know is that it's *possible* they could be telling the truth, and I have no proof otherwise, regardless of any suspicions. -- Doug Ledford [EMAIL PROTECTED] http://people.redhat.com/dledford - 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: Linux 2.6.12-rc3
It's available both as a patch (against 2.6.11) and as a tar-ball, and Where IS the tarball? Not on www.kernel.org, that's for sure. -- Ralf Hildebrandt (i.A. des IT-Zentrum) [EMAIL PROTECTED] Charite - Universitätsmedizin BerlinTel. +49 (0)30-450 570-155 Gemeinsame Einrichtung von FU- und HU-BerlinFax. +49 (0)30-450 570-962 IT-Zentrum Standort CBF send no mail to [EMAIL PROTECTED] - 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: Git-commits mailing list feed.
On Thu, 2005-04-21 at 12:29 +0200, Arjan van de Ven wrote: with BK this was not possible, but could we please have -p added to the diff parameters with git ? It makes diffs a LOT more reasable! With BK this was not possible, but could you please provide your criticism in 'diff -up' form? I've done 'perl -pi -e s/-u/-up/ gitdiff-do' as a quick hack to provide what you want, but a saner fix to make gitdiff-do obey the same GIT_DIFF_CMD and GIT_DIFF_OPTS environment variables as show-diff.c would be a more useful answer. -- dwmw2 - 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/
Need AES benchmark on Intel 64 bit
Hi, can anybody help out? I don't have access to Intel 64 bit CPUs and need some microbenchmark results on Intel 64 bit. Usage guide for the attached archive: 'ref' contains the current generic AES implementation 'new' contains the 64 bit AES assembler implementation Do 'make' in both directories and run the resulting 'aes' on an otherwise idle system without any cpufreq (speedstep) stuff active. Preferrably do multiple runs to assert that the results are usable (a few ticks difference between runs are ok). The microbenchmark is set up to produce somewhat real life results with hot caches, thus the same data block is processed all the time. -- Andreas Steinmetz SPAMmers use [EMAIL PROTECTED] microbench.tgz Description: application/tar-gz
[PATCH] scan all enabled ports on ata_piix
Hi all,
on this ACER travelmate (ICH6 chipset) the BIOS somehow sets the
PIIX_PORT_ENABLED bit, but not the PIIX_PORT_PRESENT bit.
Appearently the BIOS did not do any device scan / initialisation, and
then, the ICH6 spec does not actually require it.
As the current code scans for PIIX_PORT_PRESENT | PIIX_PORT_ENABLED it
fails to detect any devices.
And as the spec is somewhat unclear at this point I'd vote for relaxing
the check to PIIX_PORT_ENABLED only.
It doesn't do any harm as any non-existing devices will be discarded
later on anyway.
Please apply.
Cheers,
Hannes
--
Dr. Hannes Reinecke [EMAIL PROTECTED]
SuSE Linux AG S390 zSeries
Maxfeldstraße 5 +49 911 74053 688
90409 Nürnberg http://www.suse.de
Subject: ata_piix does not find any devices on ACER laptop
From: Hannes Reinecke [EMAIL PROTECTED]
References: 78564
ICH6 spec defines the PORT_ bits as:
PORT_ENABLED (R/W):
0 = Disabled. The port is in the off state and cannot detect any
devices.
1 = Enabled. The port can transition between the on,
partial, and slumber states and can detect devices.
PORT_PRESENT (R/O) The status of this bit may change at any time. This
bit is cleared when the port is disabled via PORT_ENABLED. This bit is not
cleared upon surprise removal of a device.
So from a textual view it is not necessary that PORT_PRESENT _must_ be
set, especially if a device detection has to be done anyway. And, in
fact, this is the view that ACER has been taken with its new Laptops
(e.g. Travelmate 4150).
And the definition of PORT_ENABLED / PORT_PRESENT is mixed up, btw.
Signed-off-by: Hannes Reinecke [EMAIL PROTECTED]
Signed-off-by: Jens Axboe [EMAIL PROTECTED]
--- linux-2.6.11/drivers/scsi/ata_piix.c.orig 2005-04-20 15:09:20.0
+0200
+++ linux-2.6.11/drivers/scsi/ata_piix.c2005-04-21 14:13:49.0
+0200
@@ -50,8 +50,8 @@ enum {
PIIX_COMB_PATA_P0 = (1 1),
PIIX_COMB = (1 2), /* combined mode enabled? */
- PIIX_PORT_PRESENT = (1 0),
- PIIX_PORT_ENABLED = (1 4),
+ PIIX_PORT_ENABLED = (1 0),
+ PIIX_PORT_PRESENT = (1 4),
PIIX_80C_PRI= (1 5) | (1 4),
PIIX_80C_SEC= (1 7) | (1 6),
@@ -342,7 +342,9 @@ static void piix_pata_phy_reset(struct a
* None (inherited from caller).
*
* RETURNS:
- * Non-zero if device detected, zero otherwise.
+ * Non-zero if port is enabled, it may or may not have a device
+ * attached in that case (PRESENT bit would only be set if BIOS probe
+ * was done). Zero is returned if port is disabled.
*/
static int piix_sata_probe (struct ata_port *ap)
{
@@ -366,7 +368,7 @@ static int piix_sata_probe (struct ata_p
*/
for (i = 0; i 4; i++) {
- mask = (PIIX_PORT_PRESENT i) | (PIIX_PORT_ENABLED i);
+ mask = (PIIX_PORT_ENABLED i);
if ((orig_mask mask) == mask)
if (combined || (i == ap-hard_port_no))
[PATCH] zfcp: fix compile error
Jan Dittmer [EMAIL PROTECTED] wrote: 21.04.2005 10:49 [EMAIL PROTECTED]: [PATCH] zfcp: convert to compat_ioctl This does not seem to compile anymore with defconfig: CC drivers/s390/scsi/zfcp_aux.o /usr/src/ctest/rc/kernel/drivers/s390/scsi/zfcp_aux.c:63: warning: initialization from incompatible pointer type /usr/src/ctest/rc/kernel/drivers/s390/scsi/zfcp_aux.c:366: error: conflicting types for `zfcp_cfdc_dev_ioctl' Oops. Submitted patch was incorrect. Attached patch (against 2.6.12-rc3) will fix the problem. Sorry, for any inconvenience. Regards, Andreas zfcp: fix compile error Signed-off-by: Andreas Herrmann [EMAIL PROTECTED] diff -bBrauN linux-2.6.x/drivers/s390/scsi-orig/zfcp_aux.c linux-2.6.x/drivers/s390/scsi/zfcp_aux.c --- linux-2.6.x/drivers/s390/scsi-orig/zfcp_aux.c 2005-04-21 12:36:44.0 +0200 +++ linux-2.6.x/drivers/s390/scsi/zfcp_aux.c2005-04-21 12:40:48.0 +0200 @@ -52,7 +52,7 @@ static inline int zfcp_sg_list_copy_to_user(void __user *, struct zfcp_sg_list *, size_t); -static int zfcp_cfdc_dev_ioctl(struct file *, unsigned int, unsigned long); +static long zfcp_cfdc_dev_ioctl(struct file *, unsigned int, unsigned long); #define ZFCP_CFDC_IOC_MAGIC 0xDD #define ZFCP_CFDC_IOC \ diff -bBrauN linux-2.6.x/drivers/s390/scsi-orig/zfcp_def.h linux-2.6.x/drivers/s390/scsi/zfcp_def.h --- linux-2.6.x/drivers/s390/scsi-orig/zfcp_def.h 2005-04-21 12:36:44.0 +0200 +++ linux-2.6.x/drivers/s390/scsi/zfcp_def.h2005-04-21 12:41:56.0 +0200 @@ -61,7 +61,6 @@ #include linux/mempool.h #include linux/syscalls.h #include linux/ioctl.h -#include linux/ioctl32.h / DEBUG FLAGS */ - 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 scsi-misc-2.6 03/05] scsi: make scsi_queue_insert() use blk_requeue_request()
On Thu, 2005-04-21 at 08:10 +0200, Jens Axboe wrote: I wondered about this action recently myself. What is the point in requeueing this request, only to call scsi_run_queue() - blk_run_queue() - issue same request. If the point really is to reissue the request immediately, I can think of many ways more efficient than this :-) Well ... that's because the logic that decides whether to plug the queue or simply exit is in the scsi_request_fn(). That's what the comment is about. We could abstract the check into a function, but (unless you have any suggestions on rewording it) I thought the comment made what was going on reasonably clear. James - 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: nVidia stuff again
Ha! That's the whole damn point Dave. Use your head. Just because ATI is getting more complex with their GPU does *not* mean nVidia is. Go No I rely on things I read from hardware review websites and from the GPU manufacturers to wonder what they are doing, unless putting more transistors onto their chips is making them less complex, both ATI and Nvidia are implementing chips primarily to implement DirectX features (the biggest market), this means they are both heading toward the same thing, with 3D graphics doing things on the GPU vs doing them in the driver is going to be quite noticable you end up doing as much as possible in the hardware, also things like SLI are certainly more complex not less.. ATI are making their chips less complex from a programming point of view, the R300 for example has no fixed-function pipelines, for modern apps, the shader language is translated to the GPU by the driver, for older apps using the fixed-function pipeline the driver emulates it on top of the programmable interface.. what this comes down to in the end is that the register interfaces are probably converging, there are only so many ways you can send instructions to a GPU via DMA.. specs and they haven't. Therefore, you can reliably discern absolutely *zero* information about the nVidia cards from a reference to ATI specs. But we have some lowlevel knowledge for the Nvidia cards as well.. not detailed but you can pick directions from the presentations they make and marketing literature they release It's what you know, not what you think you know, that matters. I don't know why nVidia keeps their specs secret. All I know is what they tell the world. But what I do know is that it's *possible* they could be telling the truth, and I have no proof otherwise, regardless of any suspicions. Well when previously asked for the specs by other developers the answer before has been IP issues, it may not be totally true now, I think now they just don't want to support open source because they don't believe there is any money in it... ATI didn't release full specs for r200 because they were being nice, the Weather Channel said we won't use your chips unless we have an open source driver and one can only persume proceeded to purchase a lot of chips i.e. it made monetary sense to ATI at the time.. since then it hasn't ... The IP reasons come from the fact that the specs they did release didn't contain any information on how to program a lot of ATI proprietary features.. Also it is peculiar that ATI release 2D programming specs for their newer cards and give support to the 2D ATI driver in X, Nvidia support the 2D NV driver in X, why not the 3D?, Intel won't give out specs for their latest chipsets but they do provide an open source 2D and 3D driver via Tungsten Graphics... I'm thinking of doing up a bit of a presentation for KS on 3D drivers and the technical issues they bring to the kernel (without even mentioning licensing and derived works..) Dave. - 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: x86_64: Bug in new out of line put_user()
Hello, On Thu, 2005-04-21 at 01:10 +0200, Alexander Nyberg wrote: The new out of line put_user() assembly on x86_64 changes %rcx without telling GCC about it causing things like: http://bugme.osdl.org/show_bug.cgi?id=4515 Thank you, this patch fixes the message queue problem. Best regards, Nicolas See to it that %rcx is not changed (made it consistent with get_user()). Signed-off-by: Alexander Nyberg [EMAIL PROTECTED] Index: test/arch/x86_64/lib/getuser.S === --- test.orig/arch/x86_64/lib/getuser.S 2005-04-20 23:55:35.0 +0200 +++ test/arch/x86_64/lib/getuser.S2005-04-21 00:54:16.0 +0200 @@ -78,9 +78,9 @@ __get_user_8: GET_THREAD_INFO(%r8) addq $7,%rcx - jc bad_get_user + jc 40f cmpq threadinfo_addr_limit(%r8),%rcx - jae bad_get_user + jae 40f subq$7,%rcx 4: movq (%rcx),%rdx xorl %eax,%eax Index: test/arch/x86_64/lib/putuser.S === --- test.orig/arch/x86_64/lib/putuser.S 2005-04-21 00:50:24.0 +0200 +++ test/arch/x86_64/lib/putuser.S2005-04-21 01:02:15.0 +0200 @@ -46,36 +46,45 @@ __put_user_2: GET_THREAD_INFO(%r8) addq $1,%rcx - jc bad_put_user + jc 20f cmpq threadinfo_addr_limit(%r8),%rcx - jae bad_put_user -2: movw %dx,-1(%rcx) + jae 20f +2: decq %rcx + movw %dx,(%rcx) xorl %eax,%eax ret +20: decq %rcx + jmp bad_put_user .p2align 4 .globl __put_user_4 __put_user_4: GET_THREAD_INFO(%r8) addq $3,%rcx - jc bad_put_user + jc 30f cmpq threadinfo_addr_limit(%r8),%rcx - jae bad_put_user -3: movl %edx,-3(%rcx) + jae 30f +3: subq $3,%rcx + movl %edx,(%rcx) xorl %eax,%eax ret +30: subq $3,%rcx + jmp bad_put_user .p2align 4 .globl __put_user_8 __put_user_8: GET_THREAD_INFO(%r8) addq $7,%rcx - jc bad_put_user + jc 40f cmpq threadinfo_addr_limit(%r8),%rcx - jae bad_put_user -4: movq %rdx,-7(%rcx) + jae 40f +4: subq $7,%rcx + movq %rdx,(%rcx) xorl %eax,%eax ret +40: subq $7,%rcx + jmp bad_put_user bad_put_user: movq $(-EFAULT),%rax - 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/
fix for ISDN ippp filtering
Hi,
We do not longer use DLT_LINUX_SLL for activ/pass filters but
DLT_PPP_WITHDIRECTION
witch need 1 as outbound flag.
Please apply.
Signed-off-by: Karsten Keil [EMAIL PROTECTED]
diff -urN linux-2.6.12-rc2.org/drivers/isdn/i4l/isdn_ppp.c
linux-2.6.12-rc2/drivers/isdn/i4l/isdn_ppp.c
--- linux-2.6.12-rc2.org/drivers/isdn/i4l/isdn_ppp.c2005-04-20
16:01:07.070809128 +0200
+++ linux-2.6.12-rc2/drivers/isdn/i4l/isdn_ppp.c2005-04-20
18:31:28.533367073 +0200
@@ -1151,7 +1151,7 @@
{
u_int16_t *p = (u_int16_t *) skb-data;
- *p = 0; /* indicate inbound in DLT_LINUX_SLL */
+ *p = 0; /* indicate inbound */
}
if (is-pass_filter
@@ -1293,12 +1293,12 @@
/* check if we should pass this packet
* the filter instructions are constructed assuming
* a four-byte PPP header on each packet */
- skb_push(skb, 4);
+ *skb_push(skb, 4) = 1; /* indicate outbound */
{
u_int16_t *p = (u_int16_t *) skb-data;
- *p++ = htons(4); /* indicate outbound in DLT_LINUX_SLL */
+ p++;
*p = htons(proto);
}
@@ -1491,12 +1491,12 @@
* temporarily remove part of the fake header stuck on
* earlier.
*/
- skb_pull(skb, IPPP_MAX_HEADER - 4);
+ *skb_pull(skb, IPPP_MAX_HEADER - 4) = 1; /* indicate outbound */
{
u_int16_t *p = (u_int16_t *) skb-data;
- *p++ = htons(4);/* indicate outbound in DLT_LINUX_SLL */
+ p++;
*p = htons(proto);
}
--
Karsten Keil
SuSE Labs
ISDN development
-
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/PATCH 0/22] W1: sysfs, lifetime and other fixes
On Thu, 2005-04-21 at 02:07 -0500, Dmitry Torokhov wrote: Hi, Hello, Dmitry. I happened to take a look into drivers/w1 and found there bunch of thigs that IMO should be changed: - custom-made refcounting is racy Why do you think so? Did you find exactly the place which races against something? - lifetime rules need to be better enforced Hmm, I misunderstand you. - family framework is insufficient for many advanced w1 devices No, family framework is just indication which family is used. Feel free to implement additional methods for various devices and store them in driver's private areas like ipaq does. - custom-made hotplug notification over netlink should be removed in favor of standard hotplug notification It is not hotplug, and your changes broke it completely. I'm waiting for connector to be included or discarded, so I can move w1 on top of it's interface or move connector's bits into the w1 subsystem. - sysfs attributes have unnecessary prefixes (like w1_master) or not needed at all (w1_master_pointer) Yep, some of them can be suspicious from the first point of view. Please consider series of patches below. Unfortunately I do not have any W1 equipment so it was only compile-tested. Please also note that lifetime and locking rules were changed on object-by-object base so mid-series some stuff may appear broken but as far as I can see the end result shoudl work pretty well. I can test your changes next week, but I already have too many objections to apply the whole patch set. w1-whitespace.patch Whitespace fixes. w1-formatting.patch Some formatting changes to bring the code in line with CodingStyle guidelines. Both above look ok, although they will not apply after patches already sent to Greg but not yet in the tree are applied. w1-master-attr-group.patch Use attribute_group to create master device attributes to guarantee proper cleanup in case of failure. Also, hide most of attribute define ugliness in macros. Yep, I like it. w1-slave-attr-group.patc Add 2 default attributes family and serial to slave devices, every 1-Wire slave has them. Use attribute_group to handle. The rest of slave attributes are left as is - will be dealt with later. Serial number is already there in bus_id, family is there too. Why do you need separate files? w1-lists-cleanup.patch List handling cleanup. Most of the list_for_each_safe users don't need *_safe variant, *_entry variant is better suited in most places. Also, checking retrieved list element for null is a bit pointless... Yep, it is correct. w1-drop-owner.patch Drop owner field from w1_master and w1_slave structures. Just having it there does not magically fixes lifetime rules. They do not even pretend, I still do not understand what is lifetime rules? w1-bus-ops.patch Cleanup bus operations code: - have bus operatiions accept w1_master instead of unsigned long and drop data field from w1_bus_master so the structure can be statically allocated by driver implementing it; - rename w1_bus_master to w1_bus_ops to avoid confusion with w1_master; - separate master registering and allocation so drivers can setup proper link between private data and master and set useable master's name. I strongly object against such changes. 1. w1 was designed in the way that w1 bus master drivers do not know about other w1 world. It is very simple and very low-level abstraction, that only understands how to do low-level functions. It is not needed do know about w1_master structure and even about it's existence. 2. All renaming are superfluous, I'm not against it, but completely do not understand it's merits. 3. You broke netlink allocation routing - it may fail and it is not fatal. w1-fold-w1-int.patch Fold w1_int.c into w1.c - there is no point in artificially separating code for master devices between 2 files. w1_int.c was created to store external interface implementation, why do you want to move it into w1 core code? It will only soil the code... w1-drop-netlink.patch Drop custom-made hotplug over netlink notification from w1 core. Standard hotplug mechanism should work just fine (patch will follow). netlink notification was not created for hotplug. Also I'm against w1 hotplug support, since hotplug is quite rarely used in embedded platforms where the majority of w1 devices live. I mean not to completely forget this idea, but implement it in the way it will not hurt existing model. w1-drop-control-thread.patch Drop control thread from w1 core, whatever it does can also be done in the context of w1_remove_master_device. Also, pin the module when registering new master device to make sure that w1 core is not unloaded until last device is gone. This simplifies logic a lot. Why do you think master can be removed in safe context only? I have feature requests for both adding/removing and exporting master
Re: fix for ISDN ippp filtering
Karsten Keil wrote: Hi, We do not longer use DLT_LINUX_SLL for activ/pass filters but DLT_PPP_WITHDIRECTION witch need 1 as outbound flag. Please apply. Won't this break compatibility with old ipppd binaries? Regards Patrick - 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: Linux 2.6.12-rc3
Compile error on x86_64: CC [M] drivers/usb/image/microtek.o drivers/usb/image/microtek.c: In function `mts_scsi_abort': drivers/usb/image/microtek.c:338: error: `FAILURE' undeclared (first use in this function) drivers/usb/image/microtek.c:338: error: (Each undeclared identifier is reported only once drivers/usb/image/microtek.c:338: error: for each function it appears in.) make[3]: *** [drivers/usb/image/microtek.o] Error 1 make[2]: *** [drivers/usb/image] Error 2 make[1]: *** [drivers/usb] Error 2 make: *** [drivers] Error 2 -- Andreas Steinmetz SPAMmers use [EMAIL PROTECTED] - 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: nVidia stuff again
On Thu, Apr 21, 2005 at 08:15:02AM -0400, Doug Ledford wrote: Ha! That's the whole damn point Dave. Use your head. Just because ATI is getting more complex with their GPU does *not* mean nVidia is. Go back to my original example of the aic7xxx cards. The alternative to their simple hardware design is something like the BusLogic or QLogic cards that are far more complex. Your assuming that because the ATI cards are getting more complex and people are less able to discern their makeup just by reading the specs that the nVidia cards are doing the same, nVidia is telling you otherwise, and you are just blowing that off as though you know more about their cards than they do. Reality is that they *could* be telling the truth and the fact that their card is a more simplistic card than ATIs may be the very reason that ATI has ponied up specs and they haven't. Therefore, you can reliably discern absolutely *zero* information about the nVidia cards from a reference to ATI specs. Certainly possible. Maybe all their real IP is in the code, although if that was true, letting opensource peope ahve the programing spec and have to do their own drivers wouldn't expose that IP. I have no idea. It's what you know, not what you think you know, that matters. I don't know why nVidia keeps their specs secret. All I know is what they tell the world. But what I do know is that it's *possible* they could be telling the truth, and I have no proof otherwise, regardless of any suspicions. At least as far as I have understood things, the 3D hardware in the old SGIs was very simple. Lots and lots of multiple and add units which the drivers then used in clever ways to implement fast 3D. nvidia certainly employs many ex-SGI people, so perhaps internally it is still based on that idea, although I doubt it's quite that simple anymore. Len Sorensen - 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 2.6.12-rc2] aoe [1/6]: improve allowed interfaces configuration
Bodo Eggert [EMAIL PROTECTED] [EMAIL PROTECTED] writes: Ed L Cashin [EMAIL PROTECTED] wrote: +++ b/Documentation/aoe/aoe.txt 2005-04-20 11:42:20.0 -0400 + When the aoe driver is a module, use Is there any reason for this inconsistent behaviour? Yes, the /sys/module/aoe area is only present when the aoe driver is a module. It would be nicer if there were a sysfs area where I could put this file regardless of whether the driver is a module or built into the kernel. I could probably create one, but I got the file in /sys/module/aoe/parameters for free when I used module_param_string. + /sys/module/aoe/parameters/aoe_iflist instead of ^^^ Why does the module name need to be part of the attribute? That's redundant. That's redundant. Yes. That's true. Redundancy isn't always bad, though, and using the aoe_ prefix lets the kernel parameter for the built-in aoe driver be the same as the parameter for the modular driver. -- Ed L Cashin [EMAIL PROTECTED] - 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] kill old EH constants
On Thu, 21 Apr 2005, Christoph Hellwig wrote: On Thu, Apr 21, 2005 at 11:58:12AM +0200, Geert Uytterhoeven wrote: sun3_NCR5380.c still uses the following: - SCSI_ABORT_SUCCESS - SCSI_ABORT_ERROR - SCSI_ABORT_SNOOZE - SCSI_ABORT_BUSY - SCSI_ABORT_NOT_RUNNING - SCSI_RESET_SUCCESS - SCSI_RESET_BUS_RESET causing the driver to fail to build in 2.6.12-rc3. What should I replace them by? You must replace NCR5380_abort and NCR5380_bus_reset with real new-style EH routines. I'd suggest copying them from NCR5380.c or even better scrapping sun3_NCR5380.c in favour of that one completely. Trust me, there's reasons we don't use NCR5380.c (primarily, this has to due with the order of operations necessary to keep the DMA controller happpy, which required changing the flow of several functions (admittedly, I haven't looked into this again since the new-style driver change)). That being said, it seems the first option needs done. I suppose I'll add fixing those two routines to my long list of backlogged sun3 stuff which needs doing. -- Sam - 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: strange incremental patch size [2.6.12-rc2 to 2.6.12-rc3]
On Thu, Apr 21, 2005 at 12:32:59PM +0200, Maciej Soltysiak wrote: Hi, These are the sizes of rc2 and rc3 patches # ls -la patch-2.6.12* -rw-r--r-- 1 root src 18011382 Apr 4 18:50 patch-2.6.12-rc2 -rw-r--r-- 1 root src 19979854 Apr 21 02:29 patch-2.6.12-rc3 Let us make an incremental patch from rc2 to rc3 # interdiff patch-2.6.12-rc2 patch-2.6.12-rc3 x Let us see how big it is. # ls -ld x -rw-r--r-- 1 root src 37421924 Apr 21 12:28 x How come interdiff from rc2 (18MB) to rc3 (20MB) gave me 37MB worth of patch-code ? I would expect something about 2MB but 40MB ? Try interdiff -p1? -- Daniel Jacobowitz CodeSourcery, LLC - 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/
Kdump Testing
Hi, I tested the kdump tool on x235 and x206 machines and found this problem where on kernel Panic, system instead of booting into the panic kernel jumps into BIOS and machine restarts. (I have given the hardware specifications at the bottom of the mail) Software: - 2.6.12-rc2-mm1 - kexec-tools-1.101 - Five kdump user space patches [http://marc.theaimsgroup.com/?l=linux-kernelm=111201661400892w=2] Test Procedure: - Built first kernel for 1M location with CONFIG_KEXEC enabled. - Booted into first kernel with command line options [EMAIL PROTECTED] - Built second kernel for 16M location with CONFIG_CRASH_DUMP, and CONFIG_PROC_VMCORE enabled. - Loaded second kernel with following kexec command. kexec -p vmlinux-16M --args-linux --crash-dump --append=root=root-dev init 1 - Inserted a module or echo into sysrq-trigger to invoke panic. - System jumps into BIOS directly instead of booting into secondary kernel. Summary Observation: - Earlier I was able to make kdump work on x330 machine by removing maxcpus=1 (as specified in kdump.txt) option during loading panic kernel, through kexec tool. But this work around doesn't seems to work with the hardware x235 and x206. On kernel panic machine jumps to BIOS rather than to panic kernel without displaying any error message. HARDWARE SPECIFICATIONS A) Hardware x330: - SMP, 2way, Pentium III (Coppermine) 1 GHz, 1.3G RAM - Network Interface (e100) - Disk I/O SCSI storage controller: Adaptec Ultra160 --- B)Hardware x235 - SMP, 2way, Xeon TM 2.8GHz, 1.5g RAM - Network Interface (Tigon3) - Disk I/O SCSI storage controller: IBM Serve RAID - C)Hardware x206 - SMP, 1way, Pentium IV 2.8GHz, 2g RAM - Network Interface (e1000) - Disk I/O SCSI storage controller: Adaptec Ultra320 - 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/
noddy question involving /dev/vc/0 and /dev/fb/0 on 2.6.7.11
hi, please reply cc to me as well because i am not on these lists (well i am but the receive post options are switched off), thank you. i have a noddy question where what used to work under 2.4.27 (echo 'hello world' /dev/vc/0) now doesn't work on 2.6.7.11, even though echo 'garbage' /dev/fb/0 does - just like it used to on 2.4.27. this is with an arm embedded system i'm developing for (CLPS711x derivative) and i have it set up so that the console is on the serial port. i have ported the framebuffer device over to 2.6, and have it working (echo garbage /dev/fb/0 shows up garbage in the top left corner). what kernel options do i need such that echo 'hello world' /dev/vc/0 will work and i get my lovely flashing cursor back? many thanks, l. -- -- a href=http://lkcl.net;http://lkcl.net/a -- - 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: fix for ISDN ippp filtering
On Thu, Apr 21, 2005 at 03:17:21PM +0200, Patrick McHardy wrote: Karsten Keil wrote: Hi, We do not longer use DLT_LINUX_SLL for activ/pass filters but DLT_PPP_WITHDIRECTION witch need 1 as outbound flag. Please apply. Won't this break compatibility with old ipppd binaries? Not really, since such a version was never in our I4L CVS and never released by isdn4linux. It was my fault that this wrong temporary attempt to solve the filtering problem was pushed into the kernel. The new version is still compatible to the old filtering using DLT_PPP (with libpcap 0.7x version) with was the previous version. The DLT_LINUX_SLL solution did break compatibility and was rejected because of this for PPP, but I did miss to revert the ISDN kernel part in time, so it simple do not work today. -- Karsten Keil SuSE Labs ISDN development - 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/
Suspend/Resume
Hi, I've been trying for the last few days to get my D810 to suspend and resume in linux. I'm doing it from klaptop in kde using Fedora Core 3, but I've now compiled my own linux-2.6.12-rc2-mm3 kernel since I've seen some ACPI changes going in. At 2.6.11 it would seem to suspend ok, but when doing the resume it would come back and have I/O errors.. causing the computer to freeze for a few seconds, then run for a second, then freeze again, etc.. the HDD light would stay on solid, and at the tty1 I saw something like ata1: command 0xc8 timeout... I/O error... So apparently something isn't getting starting back up. Thinking it might be the HDD not spinning, I powered off, but DID hear it spin down. Running what I compiled, 2.6.12-rc2-mm3, the suspend happens a little faster but the resume comes to a blank screen, then immediately reboots without any messages that I can see. I'm very interested in getting this to work and will do whatever someone needs to gather information. I may need to ask basic kernel info questions when asked to do something as I haven't done much trouble shooting at this low a level before but I'm game. From googling around this is a problem for many and I would like to help resolve it. If I need to take this message to another mailing list or another individual working on ACPI stuff or something just let me know. Any ideas? Thanks, Davy - 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: Linux 2.6.12-rc3: Oops on IDE flash disk eject
As already reported to lkml and IDE maintainer for 2.6.12-rc2: Oops on 'cardctl eject' of an IDE flash disk (Pretec ATA Flash 16MB). 2.6.11.2 works fine. System: Linux (none) 2.6.12-rc3-gringo #1 Thu Apr 21 15:45:08 CEST 2005 x86_64 unknown unknown GNU/Linux Kernel messages from startup to and including Oops as well as config are attached. -- Andreas Steinmetz SPAMmers use [EMAIL PROTECTED] Bootdata ok (command line is BOOT_IMAGE=2.6.12rc2 ro root=301 hdb=none hdc=cdrom hdd=none elevator=cfq psmouse.rate=20 report_lost_ticks iommu=off init=/bin/bash) Linux version 2.6.12-rc3-gringo ([EMAIL PROTECTED]) (gcc version 3.4.3) #1 Thu Apr 21 15:45:08 CEST 2005 BIOS-provided physical RAM map: BIOS-e820: - 0009f800 (usable) BIOS-e820: 0009f800 - 000a (reserved) BIOS-e820: 000d8000 - 0010 (reserved) BIOS-e820: 0010 - 3ff7 (usable) BIOS-e820: 3ff7 - 3ff7a000 (ACPI data) BIOS-e820: 3ff7a000 - 3ff8 (ACPI NVS) BIOS-e820: 3ff8 - 4000 (reserved) BIOS-e820: fffe - 0001 (reserved) ACPI: RSDP (v000 PTLTD ) @ 0x000f6a60 ACPI: RSDT (v001 PTLTDRSDT 0x0604 LTP 0x) @ 0x3ff73fde ACPI: FADT (v002 AMDK8 PTLTW0x0604 PTL_ 0x000f4240) @ 0x3ff79e56 ACPI: SSDT (v001 PTLTD POWERNOW 0x0604 LTP 0x0001) @ 0x3ff79eda ACPI: MADT (v001 PTLTD APIC 0x0604 LTP 0x) @ 0x3ff79fb0 ACPI: DSDT (v001 VIA PTL_ACPI 0x0604 MSFT 0x010e) @ 0x On node 0 totalpages: 262000 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 257904 pages, LIFO batch:16 HighMem zone: 0 pages, LIFO batch:1 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 15:4 APIC version 16 ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: IOAPIC (id[0x01] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 1, version 3, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Setting APIC routing to flat Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 4000 (gap: 4000:bffe) Built 1 zonelists Kernel command line: BOOT_IMAGE=2.6.12rc2 ro root=301 hdb=none hdc=cdrom hdd=none elevator=cfq psmouse.rate=20 report_lost_ticks iommu=off init=/bin/bash console=tty0 ide_setup: hdb=none ide_setup: hdc=cdrom ide_setup: hdd=none Initializing CPU#0 PID hash table entries: 4096 (order: 12, 131072 bytes) time.c: Using 1.193182 MHz PIT timer. time.c: Detected 1801.076 MHz processor. time.c: Using PIT/TSC based timekeeping. Console: colour VGA+ 80x50 time.c: Lost 3 timer tick(s)! rip vfs_caches_init_early+0x0/0xa0) Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes) Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes) Memory: 1024468k/1048000k available (2958k kernel code, 22832k reserved, 1639k data, 164k init) Calibrating delay loop... 3547.13 BogoMIPS (lpj=1773568) Security Framework v1.0.0 initialized SELinux: Initializing. SELinux: Starting in permissive mode selinux_register_security: Registering secondary module capability Capability LSM initialized as secondary Mount-cache hash table entries: 256 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 1024K (64 bytes/line) CPU: AMD Athlon(tm) 64 Processor 3000+ stepping 0a time.c: Lost 86 timer tick(s)! rip acpi_os_write_port+0x1a/0x36) Using local APIC NMI watchdog using perfctr0 Using local APIC timer interrupts. Detected 12.507 MHz APIC timer. time.c: Lost 55 timer tick(s)! rip setup_boot_APIC_clock+0x112/0x120) NET: Registered protocol family 16 PCI: Using configuration type 1 mtrr: v2.0 (20020519) ACPI: Subsystem revision 20050309 ACPI: Interpreter enabled ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (:00) PCI: Probing PCI hardware (bus 00) PCI: Via IRQ fixup Boot video device is :01:00.0 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: PCI Interrupt Link [ALKA] (IRQs 16 17 18 19 20 21 22 23) *10, disabled. ACPI: PCI Interrupt Link [ALKB] (IRQs 16 17 18 19 20 21 22 23) *10, disabled. ACPI: PCI Interrupt Link [ALKC] (IRQs 22) *11, disabled. ACPI: PCI Interrupt Link [ALKD] (IRQs 21) *11, disabled. ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 7 9 12 14 15) *10 ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 7 *10 12 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 7 *11 12 14 15) ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 7 9 10 *11 12 14 15) ACPI: Embedded Controller [EC] (gpe 11) time.c: Lost 8 timer tick(s)! rip acpi_os_write_port+0x1a/0x36) time.c: Lost 8 timer tick(s)! rip acpi_os_write_port+0x1a/0x36) Linux Plug and Play Support v0.97 (c) Adam Belay
Re: [RFC/PATCH 0/22] W1: sysfs, lifetime and other fixes
Hi Evgeniy,
On 4/21/05, Evgeniy Polyakov [EMAIL PROTECTED] wrote:
On Thu, 2005-04-21 at 02:07 -0500, Dmitry Torokhov wrote:
Hi,
Hello, Dmitry.
I happened to take a look into drivers/w1 and found there bunch of thigs
that IMO should be changed:
- custom-made refcounting is racy
Why do you think so?
Did you find exactly the place which races against something?
- lifetime rules need to be better enforced
Hmm, I misunderstand you.
Consider thie following:
451 while (atomic_read(sl-refcnt)) {
452 printk(KERN_INFO Waiting for %s to become free:
refcnt=%d.\n,
453 sl-name, atomic_read(sl-refcnt));
454
455 if (msleep_interruptible(1000))
456 flush_signals(current);
457 }
458
459 sysfs_remove_bin_file (sl-dev.kobj, sl-attr_bin);
460 device_remove_file(sl-dev, sl-attr_name);
461 device_remove_file(sl-dev, sl-attr_val);
462 device_unregister(sl-dev);
463 w1_family_put(sl-family);
.. And caller does kfree(sl);
Now, if application opens slave's sysfs attribute while other thread
exited the loop and is about to remove attributes, then you will kfree
object that is in use and who knows what will happen. This is example
of both refcounting being racey and lifetime rules being violated.
- family framework is insufficient for many advanced w1 devices
No, family framework is just indication which family is used.
Feel free to implement additional methods for various devices
and store them in driver's private areas like ipaq does.
OK, that is what I am aying. But why do you need that attribute with
variable name and a bin attribute that is not really bin but just a
dump for all kind of data (looks like debug one).
- custom-made hotplug notification over netlink should be removed in favor
of standard hotplug notification
It is not hotplug, and your changes broke it completely.
I'm waiting for connector to be included or discarded, so I can move
w1 on top of it's interface or move connector's bits into the w1
subsystem.
You will not be able to cram all 1-wire devices into unified
interface. You will need to build classes on top of it and you might
use connector (I am not sure) bit not on w1 bus level.
...
w1-slave-attr-group.patc
Add 2 default attributes family and serial to slave devices, every
1-Wire slave has them. Use attribute_group to handle. The rest of slave
attributes are left as is - will be dealt with later.
Serial number is already there in bus_id, family is there too.
Why do you need separate files?
Yeah, could probably drop them.
...
w1-drop-owner.patch
Drop owner field from w1_master and w1_slave structures. Just having it
there does not magically fixes lifetime rules.
They do not even pretend, I still do not understand what is lifetime
rules?
So there is no point in having them, right?
w1-bus-ops.patch
Cleanup bus operations code:
- have bus operatiions accept w1_master instead of unsigned long and
drop data field from w1_bus_master so the structure can be statically
allocated by driver implementing it;
- rename w1_bus_master to w1_bus_ops to avoid confusion with w1_master;
- separate master registering and allocation so drivers can setup proper
link between private data and master and set useable master's name.
I strongly object against such changes.
1. w1 was designed in the way that w1 bus master drivers do not
know about other w1 world. It is very simple and very low-level
abstraction,
that only understands how to do low-level functions. It is not needed
do know about w1_master structure and even about it's existence.
Well, it does need to know about w1_bus_master structure, which is
pretty much the same. And it allows having static bus_ops allocation
and removes need for casting from unsigned longs...
2. All renaming are superfluous, I'm not against it, but completely do
not
understand it's merits.
Because now it represents operations only, data field has been
dropped. I my head hurt when I see w1_master and w1_bus_muster
together as 2 separate objects both representing the same piece of
hardware.
3. You broke netlink allocation routing - it may fail and it is not
fatal.
Because it is going away in later patcehs ;)
w1-fold-w1-int.patch
Fold w1_int.c into w1.c - there is no point in artificially separating
code for master devices between 2 files.
w1_int.c was created to store external interface implementation,
why do you want to move it into w1 core code?
It will only soil the code...
Because I do not understand why code creating master devices is
separate from code creating master device's attributes.
w1-drop-netlink.patch
Drop custom-made hotplug over netlink notification from w1 core.
Standard hotplug mechanism should work just fine (patch will follow).
netlink
Re: nVidia stuff again
Lennart Sorensen wrote: On Thu, Apr 21, 2005 at 08:15:02AM -0400, Doug Ledford wrote: Ha! That's the whole damn point Dave. Use your head. Just because ATI is getting more complex with their GPU does *not* mean nVidia is. Go back to my original example of the aic7xxx cards. The alternative to their simple hardware design is something like the BusLogic or QLogic cards that are far more complex. Your assuming that because the ATI cards are getting more complex and people are less able to discern their makeup just by reading the specs that the nVidia cards are doing the same, nVidia is telling you otherwise, and you are just blowing that off as though you know more about their cards than they do. Reality is that they *could* be telling the truth and the fact that their card is a more simplistic card than ATIs may be the very reason that ATI has ponied up specs and they haven't. Therefore, you can reliably discern absolutely *zero* information about the nVidia cards from a reference to ATI specs. Certainly possible. Maybe all their real IP is in the code, although if that was true, letting opensource peope ahve the programing spec and have to do their own drivers wouldn't expose that IP. I have no idea. Even without opening up the code, but with programming specs there are many graphics driver guys out there, given the specs out it would not be too hard to have a decent driver, without the Nvidia IP. In that case there would be no question of IP violation. Or maybe somebody can do a clean room implementation provided Nvidia agrees to some NDA, and the resultant work is acceptable to Nvidia provided that it is free of their IP.. Many hardware vendors do resort to these to get their hardware working properly under Linux, and in some cases, the Linux driver has proved to be a better driver than their Windows counterparts, albeit with lesser gimmicks/features. Manu - 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/
Avoiding maps fragmentation Was: Leaks in mmap address space: 2.6.11.4
Looks like I have to answer myself here with you guys all busy
gitting...
I posted two sample programs last week that showed that large
application can run out of memory a lot quicker on 2.6 than on 2.4.
The reason is that the /proc/*/maps space fragments a lot faster
on 2.6 than with 2.4 kernels.
2.4 started searching for unused space from the mmap base up to the
stack, 2.6 starts search from the end of the last mapped area
(mm-free_area_cache).
The difference in the two algorithms is obvious (apart from the
efficiency which is undoubtedly better in 2.6):
Whereas 2.4 naturally started to fill small holes closer to the base thus
leaving larger areas open towards the stack, 2.6 will place small maps
all over the mappable area thus closing up potential large holes inefficiently.
The attached patch is left as a hack so that you guys can come up (please;-)
with a neater solution but something ought to be done that saves large
holes from small map clutter...
Wolfgang
PS: Patch^H^H^H^H^H Ugly_Hack is against 2.6.11.7 and only 'fixes' the
two architectures I'm interested in (i386 and x86_64)
diff -ru linux-2.6.11.7.orig/arch/x86_64/kernel/sys_x86_64.c
linux-2.6.11.7/arch/x86_64/kernel/sys_x86_64.c
--- linux-2.6.11.7.orig/arch/x86_64/kernel/sys_x86_64.c 2005-03-02
02:38:13.0 -0500
+++ linux-2.6.11.7/arch/x86_64/kernel/sys_x86_64.c 2005-04-21
09:27:38.0 -0400
@@ -112,8 +112,8 @@
(!vma || addr + len = vma-vm_start))
return addr;
}
- addr = mm-free_area_cache;
- if (addr begin)
+ /* addr = mm-free_area_cache;
+ if (addr begin) */
addr = begin;
start_addr = addr;
diff -ru linux-2.6.11.7.orig/mm/mmap.c linux-2.6.11.7/mm/mmap.c
--- linux-2.6.11.7.orig/mm/mmap.c 2005-03-02 02:38:12.0 -0500
+++ linux-2.6.11.7/mm/mmap.c2005-04-21 09:32:06.0 -0400
@@ -1173,7 +1173,7 @@
(!vma || addr + len = vma-vm_start))
return addr;
}
- start_addr = addr = mm-free_area_cache;
+ start_addr = addr = TASK_UNMAPPED_BASE; /* mm-free_area_cache; */
full_search:
for (vma = find_vma(mm, addr); ; vma = vma-vm_next) {
Wolfgang Wander writes:
Here is another program that illustrates the problem which this time
in C and without using glibc allocation schemes.
--
Wolfgang Wander writes:
Hi,
we are running some pretty large applications in 32bit mode on 64bit
AMD kernels (8GB Ram, Dual AMD64 CPUs, SMP). Kernel is 2.6.11.4 or
2.4.21.
Some of these applications run consistently out of memory but only
on 2.6 machines. In fact large memory allocations that libc answers
with private mmaps seem to contribute to the problem: 2.4 kernels
are able to combine these mmaps to large chunks whereas 2.6
generates a rather fragmented /proc/self/maps table.
The following C++ program reproduces the error (compiled statically
on a 32bit machine to get exactly the same executable for 2.4 and
2.6 environments):
-
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] Bad rounding in timeval_to_jiffies [was: Re: Odd Timer behavior in 2.6 vs 2.4 (1 extra tick)]
On Thu, 21 Apr 2005, Steven Rostedt wrote: Thanks, I forgot about the guarantee of at least the time requested. I took this on because I noticed this in a driver I wrote. With the user passing in a timeval for a periodic condition. I noticed that this would drift quite a bit. Your user is doing things wrong. If he wants a non-drifting clock, he should look at _realtime_ and then always re-calculate the how long do I want to sleep from that. Because even if the kernel was able to do all offsets with nanosecond precision and wake you up _exactly_, you'd still be drifting because of the time spent in between calls (and scheduling events etc). I guess I need to write my own timeval_to_jiffies conversion so that i remove the added jiffy. For this case, I actually want a true rounded value to the closest jiffy. No, if you're looking at reliable wall-clock time, you really need to use wall-clock, not successive time offsets. The time offsets will always drift: you can make the drift small enough that your particular application doesn't happen to care (or, quite often - make it drift in a _direction_ you don't happen to care about), but it's still wrong. If you calculate the expected timeout from the time-of-day in the caller, your drift not only goes away, but you'll actually be able to handle things like oops, the machine is under load so I missed an event. Yes, it gets slightly more complicated (and a _lot_ more complicated if your app needs to do something special for the missed case, like dropping data and re-syncing, which is common in things like video or sound streaming), but the fact is, it's just the right thing to do. Linus - 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 2.6.12-rc2] aoe [1/6]: improve allowed interfaces configuration
On Thu, Apr 21, 2005 at 09:36:17AM -0400, Ed L Cashin wrote: Bodo Eggert [EMAIL PROTECTED] [EMAIL PROTECTED] writes: Ed L Cashin [EMAIL PROTECTED] wrote: +++ b/Documentation/aoe/aoe.txt 2005-04-20 11:42:20.0 -0400 + When the aoe driver is a module, use Is there any reason for this inconsistent behaviour? Yes, the /sys/module/aoe area is only present when the aoe driver is a module. Not true, have you looked in /sys/module lately? :) It would be nicer if there were a sysfs area where I could put this file regardless of whether the driver is a module or built into the kernel. That's the place for it. It will be there if the driver is built as a module or into the kernel. thanks, greg k-h - 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] properly stop devices before poweroff
On 21/04/2005 12:38:29 linux-kernel-owner wrote: Without this patch, Linux provokes emergency disk shutdowns and similar nastiness. It was in SuSE kernels for some time, IIRC. OMG! And I did try to raise that issue 10 months ago, see below: http://www.ussg.iu.edu/hypermail/linux/kernel/0406.0/0242.html Heh, verify that this patch works for you and it might finally get fixed... I can't hear the difference between normal and emergency shutdown, and information I found does not suggest they are recorded amongst s.m.a.r.t attributes. Power_Cycle_Count, Load_Cycle_Count and Power-Off_Retract_Count seem to be in sync, although common sense would suggests that the last one should possibly not increment on a clean shutdown. I will experiment a bit when I find some spare time. - 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: [Gelato-technical] Re: Serious performance degradation on a RAID with kernel 2.6.10-bk7 and later
Tony and Andrew, I just checked 2.6.12-rc3 and the fls() fix is indeed missing. Do you know what happened? --david On Thu, 21 Apr 2005 13:30:50 +0200, Andreas Hirstius [EMAIL PROTECTED] said: Andreas Hi, The fls() patch from David solves the problem :-)) Andreas Do you have an idea, when it will be in the mainline Andreas kernel?? Andreas Andreas Andreas Bartlomiej ZOLNIERKIEWICZ wrote: Hi! A small update. Patching mm/filemap.c is not necessary in order to get the improved performance! It's sufficient to remove roundup_pow_of_two from |get_init_ra_size ... So a simple one-liner changes to picture dramatically. But why ?!?!? roundup_pow_of_two() uses fls() and ia64 has buggy fls() implementation [ seems that David fixed it but patch is not in the mainline yet]: http://www.mail-archive.com/linux-ia64@vger.kernel.org/msg01196.html That would also explain why you couldn't reproduce the problem on ia32 Xeon machines. Bartlomiej Andreas ___ Andreas Gelato-technical mailing list Andreas [EMAIL PROTECTED] Andreas https://www.gelato.unsw.edu.au/mailman/listinfo/gelato-technical - 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/
Which Docbook stylesheets?
kestrel linux-2.6.11.7 # make htmldocs *** You need to install DocBook stylesheets *** * app-text/docbook-dsssl-stylesheets Latest version available: 1.77-r2 Latest version installed: 1.77-r2 Size of downloaded files: 385 kB Homepage:http://docbook.sourceforge.net Description: DSSSL Stylesheets for DocBook. License: as-is * app-text/docbook-xsl-stylesheets Latest version available: 1.66.1 Latest version installed: 1.66.1 Size of downloaded files: 1,514 kB Homepage:http://docbook.sourceforge.net/ Description: XSL Stylesheets for Docbook License: || ( as-is BSD ) Which stylesheets? CL - 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: FW: [RFC] SAS domain layout for Linux sysfs
On 04/21/05 10:50, Christoph Hellwig wrote: On Thu, Apr 21, 2005 at 09:13:17AM -0500, Miller, Mike (OS Dev) wrote: Hi Christoph and James, Luben submitted this RFC back on Apr 13. There have been no responses either public or private. Does this proposal seem adequate? Is there something else that should be added? I'm trying to write a spec for interfacing with this SAS domain and was hoping for some type of feedback. No, I don't like it at all. I don't want to comment before I have understood all the implications and some good suggestion, though. Hopefully this weekend. Hi Christoph, Do you mind telling us, why you don't like it at all? Initial thoughts would suffice. Thanks, Luben - 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: Linux 2.6.12-rc3: Oops on IDE flash disk eject
The following patch fixes the Oops though I don't know if this is the
correct solution.
--- linux-2.6.12-rc3/drivers/ide/ide.c.ast
+++ linux-2.6.12-rc3/drivers/ide/ide.c
@@ -2082,7 +2082,8 @@
static int ide_drive_remove(struct device * dev)
{
ide_drive_t * drive = container_of(dev,ide_drive_t,gendev);
- DRIVER(drive)-cleanup(drive);
+ if(DRIVER(drive))
+ DRIVER(drive)-cleanup(drive);
return 0;
}
--
Andreas Steinmetz SPAMmers use [EMAIL PROTECTED]
-
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/
docbook stylesheets complaints when they are installed
kestrel linux-2.6.11.7 # make htmldocs *** You need to install DocBook stylesheets *** * app-text/docbook-dsssl-stylesheets Latest version available: 1.77-r2 Latest version installed: 1.77-r2 ^^^ Size of downloaded files: 385 kB Homepage:http://docbook.sourceforge.net Description: DSSSL Stylesheets for DocBook. License: as-is * app-text/docbook-xsl-stylesheets Latest version available: 1.66.1 Latest version installed: 1.66.1 ^^ Size of downloaded files: 1,514 kB Homepage:http://docbook.sourceforge.net/ Description: XSL Stylesheets for Docbook License: || ( as-is BSD ) Is this a symptom of linux kernel mis-detecting the docbook stylesheets? CL - 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/PATCH] unregister_node() for hotplug use
On Wed, 20 Apr 2005 10:32:35 -0700 Greg KH wrote:
On Wed, Apr 20, 2005 at 09:07:44PM +0900, Keiichiro Tokunaga wrote:
This is to add a generic function 'unregister_node()'.
It is used to remove objects of a node going away for
hotplug. If CONFIG_HOTPLUG=y, it becomes available.
This is against 2.6.12-rc2-mm3.
Please CC: this kind of stuff to the driver core maintainer, otherwise
it can get dropped...
I will for sure CC appropriate maintainers next time...
Anyway, comments below:
diff -puN drivers/base/node.c~numa_hp_base drivers/base/node.c
--- linux-2.6.12-rc2-mm3/drivers/base/node.c~numa_hp_base 2005-04-14
20:49:37.0 +0900
+++ linux-2.6.12-rc2-mm3-kei/drivers/base/node.c2005-04-14
20:49:37.0 +0900
@@ -136,7 +136,7 @@ static SYSDEV_ATTR(distance, S_IRUGO, no
*
* Initialize and register the node device.
*/
-int __init register_node(struct node *node, int num, struct node *parent)
+int __devinit register_node(struct node *node, int num, struct node
*parent)
{
int error;
@@ -145,6 +145,9 @@ int __init register_node(struct node *no
error = sysdev_register(node-sysdev);
if (!error){
+ /*
+* If you add new object here, delete it when unregistering.
+*/
Comment really isn't needed.
I removed the comments.
+/*
+ * unregister_node - Remove objects of a node going away from sysfs.
+ * @node - node going away
+ *
+ * This is used only for hotplug.
+ */
If you are going to create function comments, at least use the proper
kerneldoc format.
I removed it. I thought about its necessity again and
it seems that the comments isn't really necessary because
the purpose of the function is obvious anyway.
+#ifdef CONFIG_HOTPLUG
You don't provide function prototype for when CONFIG_HOTPLUG is not
enabled.
+void unregister_node(struct node *node)
+{
+ if (node == NULL)
+ return;
How can this happen?
It's a redundant check, so I removed it.
+
+ sysdev_remove_file(node-sysdev, attr_cpumap);
+ sysdev_remove_file(node-sysdev, attr_meminfo);
+ sysdev_remove_file(node-sysdev, attr_numastat);
+ sysdev_remove_file(node-sysdev, attr_distance);
+
+ sysdev_unregister(node-sysdev);
+}
+EXPORT_SYMBOL(register_node);
+EXPORT_SYMBOL(unregister_node);
All of sysfs and the driver core are EXPORT_SYMBOL_GPL(). Please follow
that convention.
OK, I made that change.
+#endif /* CONFIG_HOTPLUG */
-int __init register_node_type(void)
+static int __init register_node_type(void)
Are you sure no one calls this?
Yes, no one calls this today.
{
return sysdev_class_register(node_class);
}
diff -puN include/linux/node.h~numa_hp_base include/linux/node.h
--- linux-2.6.12-rc2-mm3/include/linux/node.h~numa_hp_base 2005-04-14
20:49:37.0 +0900
+++ linux-2.6.12-rc2-mm3-kei/include/linux/node.h 2005-04-14
20:49:37.0 +0900
@@ -21,12 +21,16 @@
#include linux/sysdev.h
#include linux/cpumask.h
+#include linux/module.h
Why?
struct node {
struct sys_device sysdev;
};
-extern int register_node(struct node *, int, struct node *);
+extern int __devinit register_node(struct node *, int, struct node *);
__devinit is not needed on a function prototype.
+#ifdef CONFIG_HOTPLUG
+extern void unregister_node(struct node *node);
+#endif
Not needed for a function prototype.
I corrected them. Thanks for all the comments!
I am attaching the updated patch. Please take a look.
Thanks,
Keiichiro Tokunaga
Signed-off-by: Keiichiro Tokunaga [EMAIL PROTECTED]
---
linux-2.6.12-rc2-mm3-kei/drivers/base/node.c | 21 +++--
linux-2.6.12-rc2-mm3-kei/include/linux/node.h |1 +
2 files changed, 20 insertions(+), 2 deletions(-)
diff -puN drivers/base/node.c~numa_hp_base drivers/base/node.c
--- linux-2.6.12-rc2-mm3/drivers/base/node.c~numa_hp_base 2005-04-14
20:49:37.0 +0900
+++ linux-2.6.12-rc2-mm3-kei/drivers/base/node.c2005-04-21
19:20:41.0 +0900
@@ -136,7 +136,7 @@ static SYSDEV_ATTR(distance, S_IRUGO, no
*
* Initialize and register the node device.
*/
-int __init register_node(struct node *node, int num, struct node *parent)
+int __devinit register_node(struct node *node, int num, struct node *parent)
{
int error;
@@ -153,8 +153,25 @@ int __init register_node(struct node *no
return error;
}
+#ifdef CONFIG_HOTPLUG
+void unregister_node(struct node *node)
+{
+ sysdev_remove_file(node-sysdev, attr_cpumap);
+ sysdev_remove_file(node-sysdev, attr_meminfo);
+ sysdev_remove_file(node-sysdev, attr_numastat);
+ sysdev_remove_file(node-sysdev, attr_distance);
+
+ sysdev_unregister(node-sysdev);
+}
+EXPORT_SYMBOL_GPL(register_node);
+EXPORT_SYMBOL_GPL(unregister_node);
+#else /* !CONFIG_HOTPLUG */
+void
Re: [PATCH] Bad rounding in timeval_to_jiffies [was: Re: Odd Timer behavior in 2.6 vs 2.4 (1 extra tick)]
On Thu, 2005-04-21 at 07:58 -0700, Linus Torvalds wrote: On Thu, 21 Apr 2005, Steven Rostedt wrote: Thanks, I forgot about the guarantee of at least the time requested. I took this on because I noticed this in a driver I wrote. With the user passing in a timeval for a periodic condition. I noticed that this would drift quite a bit. Your user is doing things wrong. If he wants a non-drifting clock, he should look at _realtime_ and then always re-calculate the how long do I want to sleep from that. Because even if the kernel was able to do all offsets with nanosecond precision and wake you up _exactly_, you'd still be drifting because of the time spent in between calls (and scheduling events etc). It's even stranger than this. I'm working on a custom kernel for a customer based off of Ingo's RT patches. They want to be able to make a process run for a percentage of the CPU. So you can make a process run 10 jiffies out of every 100. Using Ingo's RT patch helps to keep the latencies down from interrupts. I guess I need to write my own timeval_to_jiffies conversion so that i remove the added jiffy. For this case, I actually want a true rounded value to the closest jiffy. No, if you're looking at reliable wall-clock time, you really need to use wall-clock, not successive time offsets. The time offsets will always drift: you can make the drift small enough that your particular application doesn't happen to care (or, quite often - make it drift in a _direction_ you don't happen to care about), but it's still wrong. The customer understands that the precision would be in jiffies, and hopefully better, when/if I can get the high res timers patch working with this as well. The problem arises with the API using timeval to determine the percentage and period. With the added jiffy, the calculations are wrong. If you calculate the expected timeout from the time-of-day in the caller, your drift not only goes away, but you'll actually be able to handle things like oops, the machine is under load so I missed an event. Hopefully there is never a missed event (this is checked for though), since the process would be running at the highest priority. It's OK for the process to come in late, as long as it runs the required amount within the given period. Yes, it gets slightly more complicated (and a _lot_ more complicated if your app needs to do something special for the missed case, like dropping data and re-syncing, which is common in things like video or sound streaming), but the fact is, it's just the right thing to do. This project is much more complicated than what I've mentioned here, but it shows what I need. Currently we are using jiffies as the timer, but eventually we will be using a better source and the whole timeval_to_jiffies conversion wouldn't matter. -- Steve - 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 2.6.12-rc2] aoe [1/6]: improve allowed interfaces configuration
Greg KH [EMAIL PROTECTED] writes: On Thu, Apr 21, 2005 at 09:36:17AM -0400, Ed L Cashin wrote: Bodo Eggert [EMAIL PROTECTED] [EMAIL PROTECTED] writes: Ed L Cashin [EMAIL PROTECTED] wrote: +++ b/Documentation/aoe/aoe.txt 2005-04-20 11:42:20.0 -0400 + When the aoe driver is a module, use Is there any reason for this inconsistent behaviour? Yes, the /sys/module/aoe area is only present when the aoe driver is a module. Not true, have you looked in /sys/module lately? :) It would be nicer if there were a sysfs area where I could put this file regardless of whether the driver is a module or built into the kernel. That's the place for it. It will be there if the driver is built as a module or into the kernel. Wow! Well, that's very convenient for driver writers, so I'm pleased, and I can update the docs. It surprises me, though, to find out that /sys/module is for things other than modules. The correction below follows and depends on patch 1 of the six. fix docs: built-in driver can use files in /sys/module Signed-off-by: Ed L. Cashin [EMAIL PROTECTED] diff -urNp a-exp/linux/Documentation/aoe/aoe.txt b-exp/linux/Documentation/aoe/aoe.txt --- a-exp/linux/Documentation/aoe/aoe.txt 2005-04-21 11:25:48.0 -0400 +++ b-exp/linux/Documentation/aoe/aoe.txt 2005-04-21 11:25:49.0 -0400 @@ -102,12 +102,11 @@ USING SYSFS e4.8eth1 up e4.9eth1 up - When the aoe driver is a module, use - /sys/module/aoe/parameters/aoe_iflist instead of - /dev/etherd/interfaces to limit AoE traffic to the network - interfaces in the given whitespace-separated list. Unlike the old - character device, the sysfs entry can be read from as well as - written to. + Use /sys/module/aoe/parameters/aoe_iflist (or better, the driver + option discussed below) instead of /dev/etherd/interfaces to limit + AoE traffic to the network interfaces in the given + whitespace-separated list. Unlike the old character device, the + sysfs entry can be read from as well as written to. It's helpful to trigger discovery after setting the list of allowed interfaces. The aoetools package provides an aoe-discover script -- Ed L Cashin [EMAIL PROTECTED]
RE: [discuss] [Patch] X86_64 TASK_SIZE cleanup
Isn't that a !test_thread_flag(TIF_IA32) (flags MAP_32BIT) in my patch? Zou Nan hai -Original Message- From: Andi Kleen [mailto:[EMAIL PROTECTED] Sent: Thursday, April 21, 2005 7:51 PM To: Zou, Nanhai Cc: Andi Kleen; [EMAIL PROTECTED]; linux-kernel@vger.kernel.org; Siddha, Suresh B Subject: Re: [discuss] [Patch] X86_64 TASK_SIZE cleanup On Thu, Apr 21, 2005 at 01:17:40AM +0800, Zou, Nanhai wrote: Hi Andi, What is your comment on this patch? There is at least one wrong change in there, you have a check for test_thread_flag(TIF_IA32) (flags MAP_32BIT) and that is wrong because MAP_32BIT is used from 64bit code -Andi - 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: Linux 2.6.12-rc3
On Thu, 21 Apr 2005 14:19:10 +0200 Ralf Hildebrandt wrote: | It's available both as a patch (against 2.6.11) and as a tar-ball, and | Where IS the tarball? Not on www.kernel.org, that's for sure. in http://www.kernel.org/pub/linux/kernel/v2.6/testing/ --- ~Randy - 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] Bad rounding in timeval_to_jiffies [was: Re: Odd Timer behavior in 2.6 vs 2.4 (1 extra tick)]
Linus Torvalds wrote: If you calculate the expected timeout from the time-of-day in the caller, your drift not only goes away, but you'll actually be able to handle things like oops, the machine is under load so I missed an event. Does mainline have a high precision monotonic wallclock that is not affected by time-of-day changes? Something like nano/mico seconds since boot? Chris - 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: Need AES benchmark on Intel 64 bit
Andreas Steinmetz wrote: Hi, can anybody help out? I don't have access to Intel 64 bit CPUs and need some microbenchmark results on Intel 64 bit. Usage guide for the attached archive: 'ref' contains the current generic AES implementation 'new' contains the 64 bit AES assembler implementation This is on a 3.6GHz Nocona: wmf:~/src/aes/ref ./aes schedule128 1213 schedule192 1443 schedule256 1736 enc asm 128 1020 dec asm 128 1049 enc asm 192 1352 dec asm 192 1387 enc asm 256 1541 dec asm 256 1578 wmf:~/src/aes/ref ./aes schedule128 1214 schedule192 1442 schedule256 1736 enc asm 128 1021 dec asm 128 1049 enc asm 192 1352 dec asm 192 1388 enc asm 256 1541 dec asm 256 1579 wmf:~/src/aes/new ./aes schedule128 1276 schedule192 1520 schedule256 1822 enc asm 128 790 dec asm 128 795 enc asm 192 936 dec asm 192 937 enc asm 256 1087 dec asm 256 1086 wmf:~/src/aes/new ./aes schedule128 1276 schedule192 1520 schedule256 1821 enc asm 128 791 dec asm 128 796 enc asm 192 936 dec asm 192 937 enc asm 256 1087 dec asm 256 1086 Wes Felter - [EMAIL PROTECTED] - 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 2.6.12-rc2] aoe [1/6]: improve allowed interfaces configuration
On Thu, Apr 21, 2005 at 11:30:06AM -0400, Ed L Cashin wrote: Greg KH [EMAIL PROTECTED] writes: On Thu, Apr 21, 2005 at 09:36:17AM -0400, Ed L Cashin wrote: Bodo Eggert [EMAIL PROTECTED] [EMAIL PROTECTED] writes: Ed L Cashin [EMAIL PROTECTED] wrote: +++ b/Documentation/aoe/aoe.txt 2005-04-20 11:42:20.0 -0400 + When the aoe driver is a module, use Is there any reason for this inconsistent behaviour? Yes, the /sys/module/aoe area is only present when the aoe driver is a module. Not true, have you looked in /sys/module lately? :) It would be nicer if there were a sysfs area where I could put this file regardless of whether the driver is a module or built into the kernel. That's the place for it. It will be there if the driver is built as a module or into the kernel. Wow! Well, that's very convenient for driver writers, so I'm pleased, and I can update the docs. It surprises me, though, to find out that /sys/module is for things other than modules. It's not for things other than modules, it's filling a real need that you yourself just pointed out. Namely, we need to be able to have access to module paramaters in a consistant place, no matter if the driver is built into the kernel or not. Man, you try to be nice to people... :) thanks, greg k-h - 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/PATCH 0/22] W1: sysfs, lifetime and other fixes
One more thing... On 4/21/05, Evgeniy Polyakov [EMAIL PROTECTED] wrote: On Thu, 2005-04-21 at 02:07 -0500, Dmitry Torokhov wrote: w1-master-drop-attrs.patch Get rid of unneeded master device attributes: - 'pointer' and 'attempts' are meaningless for userspace; - information provided by 'slaves' and 'slave_count' can be gathered from other sysfs bits; - w1_slave_found has to be rearranged now that slave_count field is gone. attempts is usefull for broken lines. It simply increments with every search i.e. every 10 secondsby default and does not provide indication of the quality of the wire. -- Dmitry - 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: [discuss] [Patch] X86_64 TASK_SIZE cleanup - more comments
Hi Andi, PPC64 IA64 and S390 use variable size TASK_SIZE for 32 bit and 64 bit program. I feel it is hard to maintain if we try to audit TASK_SIZE use everywhere, because most of them are in generic code. And maintaining those audit code in separate place is also a problem. E.g. in current 32 bit emulation code TASK_SIZE is defined as 0xfff in elf loading, but defined as 0xe000 in mmaping. How did that earlier patch break applications? Thanks Zou Nan hai -Original Message- From: Andi Kleen [mailto:[EMAIL PROTECTED] Sent: Thursday, April 21, 2005 7:54 PM To: Zou, Nanhai Cc: Andi Kleen; [EMAIL PROTECTED]; linux-kernel@vger.kernel.org; Siddha, Suresh B Subject: Re: [discuss] [Patch] X86_64 TASK_SIZE cleanup - more comments Another comment: In general I am not too happy about the variable size TASK_SIZE. There was a patch for this earlier, but it broke 32bit emulation completely. And I think it needs auditing of all uses of TASK_SIZE, because I suspect there are more bugs lurking in it. The way hugetlb etc. mmap were supposed to be handled was to let the mmap succeed and then check in the mmap wrapper if any address is 4GB and free it. Probably that code has some problems or got broken (I think it worked at least in 2.4, but there might have been regressions later) -Andi - 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] Bad rounding in timeval_to_jiffies [was: Re: Odd Timer behavior in 2.6 vs 2.4 (1 extra tick)]
On Thu, 21 Apr 2005, Chris Friesen wrote: Does mainline have a high precision monotonic wallclock that is not affected by time-of-day changes? Something like nano/mico seconds since boot? High precision? No. We do have jiffies since boot. We don't actually expose it anywhere, although you _can_ get it's standardized version, aka centi-seconds per boot from things like /proc/uptime. (Not high-performance, but such an interface _could_ be. It's one of the few things we could trivially map into the system call page, and have accessible to user space with just a simple read - faster even than the fast gettimeofday implementations). The thing is, most people who want the time of day want a real time with some precision. Getting approximate uptime really really _really_ fast might be useful for some things, but I don't know how many. Linus - 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: [Lse-tech] Re: [RFC PATCH] Dynamic sched domains aka Isolated cpusets
On Wed, Apr 20, 2005 at 12:09:46PM -0700, Paul Jackson wrote: Earlier, I wrote to Dinakar: What are your invariants, and how can you assure yourself and us that your code preserves these invariants? Ok, Let me begin at the beginning and attempt to define what I am doing here 1. I need a method to isolate a random set of cpus in such a way that only the set of processes that are specifically assigned can make use of these CPUs 2. I need to ensure that the sched load balance code does not pull any tasks other than the assigned ones onto these cpus 3. I need to be able to create multiple such groupings of cpus that are disjoint from the rest and run only specified tasks 4. I need a user interface to specify which random set of cpus form such a grouping of disjoint cpus 5. I need to be able to dynamically create and destroy these grouping of disjoint cpus 6. I need to be able to add/remove cpus to/from this grouping Now if you try to fit these requirements onto cpusets, keeping in mind that it already has an user interface and some of the frame work required to create disjoint groupings of cpus 1. An exclusive cpuset ensures that the cpus it has are disjoint from all other cpusets except its parent and children 2. So now I need a way to disassociate the cpus of an exclusive cpuset from its parent, so that this set of cpus are truly disjoint from the rest of the system. 3. After I have done (2) above, I now need to build two set of sched domains corresponding to the cpus of this exclusive cpuset and the remaining cpus of its parent 4. Ensure that the current rules of non-isolated cpusets are all preserved such that if this feature is not used, all other features work as before This is exactly what I have tried to do. 1. Maintain a flag to indicate whether a cpuset is isolated 2. Maintain an isolated_map for every cpuset. This contains a cache of all cpus associated with isolated children 3. To isolate a cpuset x, x has to be an exclusive cpuset and its parent has to be an isolated cpuset 4. On isolating a cpuset by issuing /bin/echo 1 cpu_isolated It ensures that conditions in (3) are satisfied and then removes the cpus of the current cpuset from the parent cpus_allowed mask. (It also puts the cpus of the current cpuset into the isolated_map of its parent) This ensures that only the current cpuset and its children will have access to the now isolated cpus. It also rebuilds the sched domains into two new domains consisting of a. All cpus in the parent-cpus_allowed b. All cpus in current-cpus_allowed 5. Similarly on setting isolated off on a isolated cpuset, (or on doing an rmdir on an isolated cpuset) It adds all of the cpus of the current cpuset into its parent cpuset's cpus_allowed mask and removes them from it's parent's isolated_map This ensures that all of the cpus in the current cpuset are now visible to the parent cpuset. It now rebuilds only one sched domain consisting of all of the cpus in its parent's cpus_allowed mask. 6. You can also modify the cpus present in an isolated cpuset x provided that x does not have any children that are also isolated. 7. On adding or removing cpus from an isolated cpuset that does not have any isolated children, it reworks the parent cpuset's cpus_allowed and isolated_map masks and rebuilds the sched domains appropriately 8. Since the function update_cpu_domains, which does all of the above updations to the parent cpuset's masks, is always called with cpuset_sem held, it ensures that all these changes are atomic. He removes cpus 4-5 from batch and adds them to cint Could you spell out the exact steps the user would take, for this part of your example? What does the user do, what does the kernel do in response, and what state the cpusets end up in, after each action of the user? cpuset cpus isolated cpus_allowed isolated_map top 0-7 1 0 0-7 top/lowlat 0-11 0-1 0 top/others 2-71 4-72-3 top/others/cint 2-3 1 2-3 0 top/others/batch 4-7 0 4-7 0 At this point to remove cpus 4-5 from batch and add them to cint, the admin would do the following steps # Remove cpus 4-5 from batch # batch is not a isolated cpuset and hence this step # has no other implications /bin/echo 6-7 /top/others/batch/cpus cpuset cpus isolated cpus_allowed isolated_map top 0-7 1 0 0-7 top/lowlat 0-11 0-1 0 top/others 2-71 4-72-3 top/others/cint 2-3 1 2-3 0
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc3-V0.7.46-00
On Thu, 21 Apr 2005, Ingo Molnar wrote: i have released the -V0.7.46-00 Real-Time Preemption patch, which can be downloaded from the usual place: http://redhat.com/~mingo/realtime-preempt/ this is a merge to 2.6.12-rc3, plus the 'ping localhost' fix from [EMAIL PROTECTED] there are still some unsolved slowdowns probably related to the recent plist.h changes. You may want to consider rolling it out for a bit , till I have time to fix this .. Daniel - 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: Linux 2.6.12-rc3
Dear diary, on Thu, Apr 21, 2005 at 02:03:27PM CEST, I got a letter where Pavel Machek [EMAIL PROTECTED] told me that... You should put this into .git/remotes linus rsync://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git (git addremote is preferred for that :-) Then RSYNC_FLAGS=-zavP git pull linus -v is passed to rsync by default. I'll gladly add other reasonable rsync flags (I don't call printing each considered file reasonable; fsck or wget-like progressbar would be ideal). Well, not sure. I did git track linus git cancel but Makefile still contains -rc2. (Is git cancel right way to check out the tree?) No. git cancel does what it says - cancels your local changes to the working tree. git track will only set that next time you pull from linus, the changes will be automatically merged. (Note that this will change with the big UI change.) Either do git track linus git pull or git merge linus to get Linus' changes if you didn't pull yet. and git diff -r linus: still contains some changes. [I did some experimental pull of scsi changes long time ago, is it that problem?] If you don't have your HEAD on Linus' branch, it will do a tree merge instead of fast-forward; that is, it will not just move your HEAD on to match Linus' HEAD, but it will make a regular merge and then ask you to do a merge commit. -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor - 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/
/sys/module (was Re: [PATCH 2.6.12-rc2] aoe [1/6]: improve allowed interfaces configuration)
Greg KH [EMAIL PROTECTED] writes: ... It's not for things other than modules, it's filling a real need that you yourself just pointed out. Namely, we need to be able to have access to module paramaters in a consistant place, no matter if the driver is built into the kernel or not. Man, you try to be nice to people... :) It wasn't a complaint --- like I said, I'm pleased! I just wanted to serve as a datum: one guy was surprised. I wanted to put the interfaces list configuration into sysfs, but I didn't really know how or where to put it, so I procrastinated. Then I created the module parameter and was pleased to see it show up in sysfs. I had read about module parameters before, but I had forgotten about that feature, or maybe it's newer than the docs I read. Thanks for working so hard to make sysfs useful. -- Ed L Cashin [EMAIL PROTECTED] - 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] minor syctl fix in vsyscall_init
On 13 Apr 2005 20:29:13 +0200, Andi Kleen [EMAIL PROTECTED] wrote: On Wed, Apr 13, 2005 at 10:45:18AM -0700, Matt Tolentino wrote: Andi, If CONFIG_SYCTL is not enabled then the x86-64 tree fails to build due to use of a symbol that is not compiled in. Don't bother compiling in the sysctl register call if not building with sysctl. Thanks. Actually it would be better to fix up sysctl.h to define dummy functions in this case. I thought it did that already in fact Yes it already does that, but kernel_root_table2 is not defined when CONFIG_SYSCTL is not set (the problem isn't with register_sysctl_table). With 2.6.12-rc3: arch/x86_64/kernel/vsyscall.c: In function `vsyscall_init': arch/x86_64/kernel/vsyscall.c:221: error: `kernel_root_table2' undeclared (first use in this function) If you prefer, i can send a patch which sets kernel_table_root2 to NULL when CONFIG_SYSCTL is not set. Or maybe there a better fix (btw is sysctl_vsyscall needed when !CONFIG_SYSCTL ?). regards, Benoit - 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 2.6.12-rc2] aoe [1/6]: improve allowed interfaces configuration
On Thu, 21 Apr 2005 11:30:06 -0400 Ed L Cashin wrote: | Greg KH [EMAIL PROTECTED] writes: | | On Thu, Apr 21, 2005 at 09:36:17AM -0400, Ed L Cashin wrote: | Bodo Eggert [EMAIL PROTECTED] [EMAIL PROTECTED] writes: | | Ed L Cashin [EMAIL PROTECTED] wrote: | | +++ b/Documentation/aoe/aoe.txt 2005-04-20 11:42:20.0 -0400 | | + When the aoe driver is a module, use | | Is there any reason for this inconsistent behaviour? | | Yes, the /sys/module/aoe area is only present when the aoe driver is a | module. | | Not true, have you looked in /sys/module lately? :) | | It would be nicer if there were a sysfs area where I could | put this file regardless of whether the driver is a module or built | into the kernel. | | That's the place for it. It will be there if the driver is built as a | module or into the kernel. | | Wow! Well, that's very convenient for driver writers, so I'm pleased, | and I can update the docs. It surprises me, though, to find out that | /sys/module is for things other than modules. Just depends on your definition of a module. AOE (or just about any device driver) can be considered logically as a module. You seem to be equating module with loadable module vs. a builtin module. The good news is that /sys/module works for loadable or builtin modules. --- ~Randy - 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: Linux 2.6.12-rc3
On Thu, Apr 21, 2005 at 11:10:15AM +0200, Geert Uytterhoeven wrote: On Thu, 21 Apr 2005, Jan Dittmer wrote: Linus Torvalds wrote: Geert Uytterhoeven: [PATCH] M68k: Update defconfigs for 2.6.11 [PATCH] M68k: Update defconfigs for 2.6.12-rc2 Why do I still get this error when trying to cross-compile for m68k? Because to build m68k kernels, you (still :-( have to use the Linux/m68k CVS repository, cfr. http://linux-m68k-cvs.ubb.ca/. BTW, my patch queue is at http://linux-m68k-cvs.ubb.ca/~geert/linux-m68k-2.6.x-merging/. The main offender is POSTPONED/156-thread_info.diff. I think I have a sane splitup of that stuff. If you have time to review - yell - 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/
Gentoo livecd - unionfs module problem
Hi! i´m working on a linux livecd gentoo-based using the linux-live scripts. Ok, then, i use the gentoo kernel 2.6.11 with squashfs support (not module, incore) and i compile the unionfs.ko module. I gzip the module unionfs.ko and i copy it to the: kernel-modules/'uname -r'/ directory for a future use by the linux-live scripts. Then, the scipts copy unionfs.ko.gz to the initrd. The problem is: when the initrd boots and it try to load the module (from /tmp when it´s already gunzipped) returns this message: insmod: cannot open module '/tmp/unionfs.ko' : Invalid module format(-1): Exec format error but if i try to load the module on the gentoo distribution before create the .iso and burn´it (on the hard-disk) there´s no problem (i load it with the same 'busybox' binary that uses the linuxrc script) Then, errors, kernel panic, goodbye... Help! Please... Thanks !!! ---nevy--- - 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: Linux 2.6.12-rc3: various swsusp problems
Hi Pavel, there's some problems with swsusp in 2.6.12-rc3 (x86_64): 1. Is it necessary to print the following message during regular boot? swsusp: Suspend partition has wrong signature? It is a bit annoying and I believe it will confuse some swsusp users. 2. PCMCIA related hangs during swsusp. swsusp hangs after freeing memory when either cardmgr is running or pcmcia cards are *physically* inserted. It is insufficient to do a 'cardctl eject' the cards must be removed, too, for swsusp not to hang. I do suspect some problem with the 'pccardd' kernel threads. 3. Sometimes during the search for the suspend hang reason the system went during suspend into a lightshow of: eth0: Too much work at interrupt! and some line that ends in: release_console_sem+0x13d/0x1c0) The start of the line is not readable as it just flickers by in the eth0 message limbo. NIC is a built in RTL-8169 Gigabit Ethernet (rev 10). Oh, no chance for a serial console capture as there's no built in serial device in this laptop. -- Andreas Steinmetz SPAMmers use [EMAIL PROTECTED] - 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/
[RFC PATCH] Dynamic sched domains aka Isolated cpusets (v0.2)
Based on the Paul's feedback, I have simplified and cleaned up the
code quite a bit.
o I have taken care of most of the nits, except for the output
format change for cpusets with isolated children.
o Also most of my documentation has been part of my earlier mails
and I have not yet added them to cpusets.txt.
o I still havent looked at the memory side of things.
o Most of the changes are in the cpusets code and almost none
in the sched code. (I'll do that next week)
o Hopefully my earlier mails regarding the design have clarified
many of the questions that were raised
So here goes version 0.2
-rw-r--r--1 root root16548 Apr 21 20:54 cpuset.o.orig
-rw-r--r--1 root root17548 Apr 21 22:09 cpuset.o.sd-v0.2
Around ~6% increase in kernel text size of cpuset.o
include/linux/init.h |2
include/linux/sched.h |1
kernel/cpuset.c | 153 +-
kernel/sched.c| 111
4 files changed, 216 insertions(+), 51 deletions(-)
diff -Naurp linux-2.6.12-rc1-mm1.orig/include/linux/init.h
linux-2.6.12-rc1-mm1/include/linux/init.h
--- linux-2.6.12-rc1-mm1.orig/include/linux/init.h 2005-03-18
07:03:49.0 +0530
+++ linux-2.6.12-rc1-mm1/include/linux/init.h 2005-04-21 21:54:06.0
+0530
@@ -217,7 +217,7 @@ void __init parse_early_param(void);
#define __initdata_or_module __initdata
#endif /*CONFIG_MODULES*/
-#ifdef CONFIG_HOTPLUG
+#if defined(CONFIG_HOTPLUG) || defined(CONFIG_CPUSETS)
#define __devinit
#define __devinitdata
#define __devexit
diff -Naurp linux-2.6.12-rc1-mm1.orig/include/linux/sched.h
linux-2.6.12-rc1-mm1/include/linux/sched.h
--- linux-2.6.12-rc1-mm1.orig/include/linux/sched.h 2005-04-21
21:50:26.0 +0530
+++ linux-2.6.12-rc1-mm1/include/linux/sched.h 2005-04-21 21:53:57.0
+0530
@@ -155,6 +155,7 @@ typedef struct task_struct task_t;
extern void sched_init(void);
extern void sched_init_smp(void);
extern void init_idle(task_t *idle, int cpu);
+extern void rebuild_sched_domains(cpumask_t span1, cpumask_t span2);
extern cpumask_t nohz_cpu_mask;
diff -Naurp linux-2.6.12-rc1-mm1.orig/kernel/cpuset.c
linux-2.6.12-rc1-mm1/kernel/cpuset.c
--- linux-2.6.12-rc1-mm1.orig/kernel/cpuset.c 2005-04-21 21:50:26.0
+0530
+++ linux-2.6.12-rc1-mm1/kernel/cpuset.c2005-04-21 22:00:36.0
+0530
@@ -57,7 +57,13 @@
struct cpuset {
unsigned long flags;/* unsigned long so bitops work */
- cpumask_t cpus_allowed; /* CPUs allowed to tasks in cpuset */
+ /*
+* CPUs allowed to tasks in cpuset and
+* not part of any isolated children
+*/
+ cpumask_t cpus_allowed;
+
+ cpumask_t isolated_map; /* CPUs associated with isolated
children */
nodemask_t mems_allowed;/* Memory Nodes allowed to tasks */
atomic_t count; /* count tasks using this cpuset */
@@ -82,6 +88,7 @@ struct cpuset {
/* bits in struct cpuset flags field */
typedef enum {
CS_CPU_EXCLUSIVE,
+ CS_CPU_ISOLATED,
CS_MEM_EXCLUSIVE,
CS_REMOVED,
CS_NOTIFY_ON_RELEASE
@@ -93,6 +100,11 @@ static inline int is_cpu_exclusive(const
return !!test_bit(CS_CPU_EXCLUSIVE, cs-flags);
}
+static inline int is_cpu_isolated(const struct cpuset *cs)
+{
+ return !!test_bit(CS_CPU_ISOLATED, cs-flags);
+}
+
static inline int is_mem_exclusive(const struct cpuset *cs)
{
return !!test_bit(CS_MEM_EXCLUSIVE, cs-flags);
@@ -127,8 +139,10 @@ static inline int notify_on_release(cons
static atomic_t cpuset_mems_generation = ATOMIC_INIT(1);
static struct cpuset top_cpuset = {
- .flags = ((1 CS_CPU_EXCLUSIVE) | (1 CS_MEM_EXCLUSIVE)),
+ .flags = ((1 CS_CPU_EXCLUSIVE) | (1 CS_CPU_ISOLATED) |
+ (1 CS_MEM_EXCLUSIVE)),
.cpus_allowed = CPU_MASK_ALL,
+ .isolated_map = CPU_MASK_NONE,
.mems_allowed = NODE_MASK_ALL,
.count = ATOMIC_INIT(0),
.sibling = LIST_HEAD_INIT(top_cpuset.sibling),
@@ -543,9 +557,14 @@ static void refresh_mems(void)
static int is_cpuset_subset(const struct cpuset *p, const struct cpuset *q)
{
- return cpus_subset(p-cpus_allowed, q-cpus_allowed)
+ cpumask_t all_map;
+
+ cpus_or(all_map, q-cpus_allowed, q-isolated_map);
+
+ return cpus_subset(p-cpus_allowed, all_map)
nodes_subset(p-mems_allowed, q-mems_allowed)
is_cpu_exclusive(p) = is_cpu_exclusive(q)
+ is_cpu_isolated(p) = is_cpu_isolated(q)
is_mem_exclusive(p) = is_mem_exclusive(q);
}
@@ -587,6 +606,11 @@ static int validate_change(const struct
if (!is_cpuset_subset(trial, par))
return -EACCES;
+ /* An isolated cpuset has to be exclusive */
+ if ((is_cpu_isolated(trial) !is_cpu_exclusive(cur))
+
Mercurial distributed SCM v0.2
This is my continuing attempt to make an SCM suitable for kernel hacking. It supports a distribution model similar to BK and Monotone but is orders of magnitude simpler than both (about 1k lines of code). http://selenic.com/mercurial/ New in this version: - much improved command line tool - installation instructions - commit log editing - experimental network pull support Some example usage: Setting up a Mercurial project: $ cd linux/ $ hg init # creates .hg $ hg status # show differences between repo and working dir $ hg addremove# add all unknown files and remove all missing files $ hg commit # commit all changes, edit changelog entry Mercurial commands: $ hg history # show changesets $ hg log Makefile # show commits per file $ hg checkout # check out the tip revision $ hg checkout hash # check out a specified changeset $ hg add foo # add a new file for the next commit $ hg remove bar # mark a file as removed Branching and merging: $ cd .. $ cp -al linux linux-work # create a new hardlink branch $ cd linux-work $ make changes $ hg commit $ cd ../linux $ hg merge ../linux-work# pull changesets from linux-work Network support (highly experimental): # export your .hg directory as a directory on your webserver foo$ ln -s .hg ~/public_html/hg-linux # merge changes from a remote machine bar$ hg merge http://foo/~user/hg-linux This is just a proof of concept of grabbing byte ranges, and is not expected to perform well yet. -- Mathematics is the supreme nostalgia of our time. - 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: [Gelato-technical] Re: Serious performance degradation on a RAID with kernel 2.6.10-bk7 and later
I just checked 2.6.12-rc3 and the fls() fix is indeed missing. Do you know what happened? If BitKeeper were still in use, I'd have dropped that patch into my release tree and asked Linus to pull ... but it's not, and I was stalled. I should have a git tree up and running in the next couple of days. I'll make sure that the fls fix goes in early. -Tony - 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: Need AES benchmark on Intel 64 bit
On Thu, Apr 21, 2005 at 02:28:54PM +0200, Andreas Steinmetz wrote: Hi, can anybody help out? I don't have access to Intel 64 bit CPUs and need some microbenchmark results on Intel 64 bit. Usage guide for the attached archive: 'ref' contains the current generic AES implementation 'new' contains the 64 bit AES assembler implementation Do 'make' in both directories and run the resulting 'aes' on an otherwise idle system without any cpufreq (speedstep) stuff active. Preferrably do multiple runs to assert that the results are usable (a few ticks difference between runs are ok). The microbenchmark is set up to produce somewhat real life results with hot caches, thus the same data block is processed all the time. ref: schedule128 1535 schedule192 1817 schedule256 2167 enc asm 128 1166 dec asm 128 1163 enc asm 192 1361 dec asm 192 1378 enc asm 256 1570 dec asm 256 1594 schedule128 1535 schedule192 1817 schedule256 2170 enc asm 128 1166 dec asm 128 1164 enc asm 192 1361 dec asm 192 1382 enc asm 256 1579 dec asm 256 1599 new: schedule128 1542 schedule192 1823 schedule256 2177 enc asm 128 1034 dec asm 128 1018 enc asm 192 1212 dec asm 192 1213 enc asm 256 1409 dec asm 256 1401 schedule128 1547 schedule192 1828 schedule256 2182 enc asm 128 1036 dec asm 128 1024 enc asm 192 1217 dec asm 192 1222 enc asm 256 1412 dec asm 256 1395 subsequent runs present the same picture. 'new' seems slightly higher scores on schedule*, but lower scores on the other tests. Dual 2.8 Xeon w/HT... processor : 3 vendor_id : GenuineIntel cpu family : 15 model : 4 model name : Intel(R) Xeon(TM) CPU 2.80GHz stepping: 1 cpu MHz : 2793.079 cache size : 1024 KB physical id : 3 siblings: 2 fpu : yes fpu_exception : yes cpuid level : 3 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm pni monitor ds_cpl cid cx16 xtpr bogomips: 5570.56 clflush size: 64 cache_alignment : 128 address sizes : 36 bits physical, 48 bits virtual power management: Dave - 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: [Gelato-technical] Re: Serious performance degradation on a RAID with kernel 2.6.10-bk7 and later
On Thu, 21 Apr 2005 10:19:28 -0700, Luck, Tony [EMAIL PROTECTED] said: I just checked 2.6.12-rc3 and the fls() fix is indeed missing. Do you know what happened? Tony If BitKeeper were still in use, I'd have dropped that patch Tony into my release tree and asked Linus to pull ... but it's Tony not, and I was stalled. I should have a git tree up and Tony running in the next couple of days. I'll make sure that the Tony fls fix goes in early. Yeah, I'm facing the same issue. I started playing with git last night. Apart from disk-space usage, it's very nice, though I really hope someone puts together a web-interface on top of git soon so we can seek what changed when and by whom. --david - 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.6.12-rc3 compile error in aic7xxx_osm.c
drivers/scsi/aic7xxx/aic7xxx_osm.c: In function `ahc_linux_init': drivers/scsi/aic7xxx/aic7xxx_osm.c:3608: parse error before `int' drivers/scsi/aic7xxx/aic7xxx_osm.c:3609: `rc' undeclared (first use in this function) drivers/scsi/aic7xxx/aic7xxx_osm.c:3609: (Each undeclared identifier is reported only once drivers/scsi/aic7xxx/aic7xxx_osm.c:3609: for each function it appears in.) drivers/scsi/aic7xxx/aic7xxx_osm.c: At top level: drivers/scsi/aic7xxx/aic7xxx_osm.c:744: warning: `ahc_linux_detect' defined but not used - 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: [Gelato-technical] Re: Serious performance degradation on a RAID with kernel 2.6.10-bk7 and later
Yeah, I'm facing the same issue. I started playing with git last night. Apart from disk-space usage, it's very nice, though I really hope someone puts together a web-interface on top of git soon so we can seek what changed when and by whom. Disk space issues? A complete git repository of the Linux kernel with all changesets back to 2.4.0 takes just over 3G ... which is big compared to BK, but 3G of disk only costs about $1 (for IDE ... if you want 15K rpm SCSI, then you'll pay a lot more). Network bandwidth is likely to be a bigger problem. There's a prototype web i/f at http://grmso.net:8090/ that's already looking fairly slick. -Tony - 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/
SATA/ATAPI
Hi, I know there has been some talking about SATA/ATAPI being experimental and might not work at all under kernel-2.6.x. One of my linux boxes has a Plextor DVD-RW drive with a SATA interface. The kernel sees this drive (ata3) but apparently doesn't tie it to a sdx device. The box also have a SATA harddisk, which is working just fine. The relevant dmesg output is pasted below. Is there anything I can do to help the development of SATA/ATAPI devices? libata version 1.10 loaded. sata_promise version 1.01 ACPI: PCI interrupt :00:08.0[A] - GSI 18 (level, low) - IRQ 18 ata1: SATA max UDMA/133 cmd 0xF8804200 ctl 0xF8804238 bmdma 0x0 irq 18 ata2: SATA max UDMA/133 cmd 0xF8804280 ctl 0xF88042B8 bmdma 0x0 irq 18 ata1: dev 0 cfg 49:2f00 82:7c6b 83:7b09 84:4003 85:7c69 86:3a01 87:4003 88:407f ata1: dev 0 ATA, max UDMA/133, 240121728 sectors: ata1: dev 0 configured for UDMA/133 scsi0 : sata_promise ata2: no device found (phy stat ) scsi1 : sata_promise Vendor: ATA Model: Maxtor 6Y120M0Rev: YAR5 Type: Direct-Access ANSI SCSI revision: 05 sata_via version 1.1 ACPI: PCI interrupt :00:0f.0[B] - GSI 20 (level, low) - IRQ 20 sata_via(:00:0f.0): routed to hard irq line 4 ata3: SATA max UDMA/133 cmd 0xE800 ctl 0xE402 bmdma 0xD400 irq 20 ata4: SATA max UDMA/133 cmd 0xE000 ctl 0xD802 bmdma 0xD408 irq 20 ata3: dev 0 cfg 49:0f00 82: 83: 84: 85: 86: 87: 88:0007 ata3: dev 0 ATAPI, max UDMA/33 ata3: dev 0 configured for UDMA/33 scsi2 : sata_via ata4: no device found (phy stat ) scsi3 : sata_via SCSI device sda: 240121728 512-byte hdwr sectors (122942 MB) SCSI device sda: drive cache: write back SCSI device sda: 240121728 512-byte hdwr sectors (122942 MB) SCSI device sda: drive cache: write back sda: sda1 sda2 sda3 sda5 sda6 sda7 Attached scsi disk sda at scsi0, channel 0, id 0, lun 0 -- Regards, Tais M. Hansen OSD ___ If people had understood how patents would be granted when most of today's ideas were invented and had taken out patents, the industry would be at a complete standstill today. -Bill Gates (1991) pgp2lSFQp2sGj.pgp Description: PGP signature
RE: [Gelato-technical] Re: Serious performance degradation on a RAID with kernel 2.6.10-bk7 and later
On Thu, 21 Apr 2005 10:41:52 -0700, Luck, Tony [EMAIL PROTECTED] said: Tony Disk space issues? A complete git repository of the Linux Tony kernel with all changesets back to 2.4.0 takes just over 3G Tony ... which is big compared to BK, but 3G of disk only costs Tony about $1 (for IDE ... if you want 15K rpm SCSI, then you'll Tony pay a lot more). Network bandwidth is likely to be a bigger Tony problem. Ever heard that data is a gas? My disks always fill up in no time at all, no matter how big they are. I agree that network bandwidth is an bigger issue, though. Tony There's a prototype web i/f at http://grmso.net:8090/ that's Tony already looking fairly slick. Indeed. Plus it has a cool name, too. Thanks for the pointer. --david - 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/
