Re: Question about Reiser4

[William Heimbigner]

William Heimbigner wrote:

>  Eric Hopper wrote:
> >   I know that this whole effort has been put in disarray by the
> >   prosecution of Hans Reiser, but I'm curious as to its status. 
> 
>  It was in disarray well before.  Many of the reiser4 features,

>  like filesystem plugins, make more technical sense in the Linux
>  VFS, but made more business sense for Namesys as a reiserfs 4
>  thing.  That lead to a stalemate.
>
 Shouldn't it be a matter of stability though? 


A lot of other things matter.  Things like a willingness to
maintain the code after it gets merged, or at least turning
the code into something the community is willing to maintain
if the original developers stop maintaining it.


 Benchmarks suggest that reiser4 is a good file system; reiser4 is the
 successor to the already-accepted reiserfs; we've got experimental ext4
 support but no reiser4 support, etc.


Namesys kind of abandoned reiserfs after work on reiser4
started.  Taking in a new code base on such a track record
is not a good idea when the code is not in a shape where
the community wants to maintain it.


 I don't see why something like plugins should matter. If it works enough
 to be marked as experimental, why shouldn't reiser4 support be included?
 It's a pain for me personally to have to patch any kernel with reiser4
 support so I can use the reiser4 fs.


You basically have three options:

1) keep patching every time you upgrade the kernel

2) use another filesystem

3) become the new reiser4 maintainer and turn the code
   into something that Linus is willing to accept


I suppose. I have a feeling there's an underlying issue behind "code 
standards" (and even then, I think that code standards is ultimately an 
excuse for not integrating reiser4 support into the kernel, but that's 
just my opinion). However, is the code really in such a shape that the 
community doesn't want to maintain it? Obviously there's a significant 
number of people interested in reiser4 - if there weren't, questions like 
this wouldn't keep getting asked.


William Heimbigner
[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: Question about Reiser4

[Rik van Riel]

William Heimbigner wrote:

Eric Hopper wrote:

 I know that this whole effort has been put in disarray by the
 prosecution of Hans Reiser, but I'm curious as to its status. 


It was in disarray well before.  Many of the reiser4 features,
like filesystem plugins, make more technical sense in the Linux
VFS, but made more business sense for Namesys as a reiserfs 4
thing.  That lead to a stalemate.

Shouldn't it be a matter of stability though? 


A lot of other things matter.  Things like a willingness to
maintain the code after it gets merged, or at least turning
the code into something the community is willing to maintain
if the original developers stop maintaining it.

Benchmarks suggest that 
reiser4 is a good file system; reiser4 is the successor to the 
already-accepted reiserfs; we've got experimental ext4 support but no 
reiser4 support, etc.


Namesys kind of abandoned reiserfs after work on reiser4
started.  Taking in a new code base on such a track record
is not a good idea when the code is not in a shape where
the community wants to maintain it.

I don't see why something like plugins should matter. If it works enough 
to be marked as experimental, why shouldn't reiser4 support be included?
It's a pain for me personally to have to patch any kernel with reiser4 
support so I can use the reiser4 fs.


You basically have three options:

1) keep patching every time you upgrade the kernel

2) use another filesystem

3) become the new reiser4 maintainer and turn the code
   into something that Linus is willing to accept

--
Politics is the struggle between those who want to make their country
the best in the world, and those who believe it already is.  Each group
calls the other unpatriotic.
-
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: regression with gammu on 2.6.21-rc7

[Greg KH]

On Fri, Apr 20, 2007 at 10:58:53AM +0200, Wolfgang Erig wrote:
> Hello,
> 
> I have a regression with 2.6.21-rc7-g80d74d51.
> The utility "gammu" to talk to my mobile does not work anymore.
> With 2.6.20 gammu runs fine.
> 
> Distribution is the latest Debian/testing
> 
> Wolfgang
> 
> $ gammu --backup backup
> Press Ctrl+C to break...
> I/O possible
> $ uname -a
> Linux max 2.6.21-rc7-g80d74d51 #9 SMP Wed Apr 18 21:41:41 CEST 2007 i686 
> GNU/Linux
> $ tail messages 
> Apr 20 08:04:36 max kernel: ACPI: PCI Interrupt :00:1b.0[A] -> GSI 16 
> (level, low) -> IRQ 16
> Apr 20 08:04:36 max kernel: extern: link up, 100Mbps, full-duplex, lpa 0x45E1
> Apr 20 08:04:36 max kernel: intern:  setting half-duplex.
> Apr 20 08:09:02 max kernel: usb 2-2: USB disconnect, address 3
> Apr 20 08:09:02 max kernel: pl2303 ttyUSB0: pl2303 converter now disconnected 
> from ttyUSB0
> Apr 20 08:09:02 max kernel: pl2303 2-2:1.0: device disconnected
> Apr 20 08:10:24 max kernel: usb 2-2: new full speed USB device using uhci_hcd 
> and address 4
> Apr 20 08:10:25 max kernel: usb 2-2: configuration #1 chosen from 1 choice
> Apr 20 08:10:25 max kernel: pl2303 2-2:1.0: pl2303 converter detected
> Apr 20 08:10:25 max kernel: usb 2-2: pl2303 converter now attached to ttyUSB0

That looks ok, I'm guessing you yanked it out and then back in?

Or is the problem that the device was removed?

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] use spinlock instead of binary mutex in CDU-31A driver

[Matthias Kaehlcke]

El Mon, Apr 23, 2007 at 01:25:58AM +0200 Andi Kleen ha dit:

> Matthias Kaehlcke <[EMAIL PROTECTED]> writes:
> 
> > -static DECLARE_MUTEX(sony_sem);/* Semaphore for drive hardware 
> > access */
> > +static DEFINE_MUTEX(sony_mtx); /* Mutex for drive hardware 
> > access */
> 
> That's not a spinlock.  Also normally some rationale is added to the
> description for a change?

sorry i messed up the description of the change, i meant mutex instead
of spinlock (in the last days i reported some spinlock related bugs
...). 

the rationale is that according to http://lwn.net/Articles/167034/
binary semaphores that aren't given in interrupt context or
locked and unlocked by different processes should be replaced by
mutexes

thanks for your comments

-- 
Matthias Kaehlcke
Linux Application Developer
Barcelona

  La posibilidad de realizar un suenyo es lo
 que hace que la vida sea interesante
 .''`.
using free software / Debian GNU/Linux | http://debian.org  : :'  :
`. `'`
gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4  `-
-
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] CFS scheduler, -v5

[Markus Trippelsdorf]

On Mon, Apr 23, 2007 at 03:12:29AM +0200, Ingo Molnar wrote:
> 
> i'm pleased to announce release -v5 of the CFS scheduler patchset. The 
> patch against v2.6.21-rc7 and v2.6.20.7 can be downloaded from:
...
>  - feature: add initial sys_sched_yield_to() implementation. Not hooked 
>into the futex code yet, but testers are encouraged to give the 
>syscalls a try, on i686 the new syscall is __NR_yield_to==320, on 
>x86_64 it's __NR_yield_to==280. The prototype is 
>sys_sched_yield_to(pid_t), as suggested by Ulrich Drepper.

The new version does not link here (amd64,smp):

  LD  .tmp_vmlinux1
  arch/x86_64/kernel/built-in.o:(.rodata+0x1dd8): undefined reference to
  `sys_yield_to'

-- 
Markus
-
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] CFS scheduler, -v5

[Markus Trippelsdorf]

On Mon, Apr 23, 2007 at 07:16:59AM +0200, Markus Trippelsdorf wrote:
> On Mon, Apr 23, 2007 at 03:12:29AM +0200, Ingo Molnar wrote:
> > 
> > i'm pleased to announce release -v5 of the CFS scheduler patchset. The 
> > patch against v2.6.21-rc7 and v2.6.20.7 can be downloaded from:
> ...
> >  - feature: add initial sys_sched_yield_to() implementation. Not hooked 
> >into the futex code yet, but testers are encouraged to give the 
> >syscalls a try, on i686 the new syscall is __NR_yield_to==320, on 
> >x86_64 it's __NR_yield_to==280. The prototype is 
> >sys_sched_yield_to(pid_t), as suggested by Ulrich Drepper.
> 
> The new version does not link here (amd64,smp):
> 
>   LD  .tmp_vmlinux1
>   arch/x86_64/kernel/built-in.o:(.rodata+0x1dd8): undefined reference to
>   `sys_yield_to'

Changing  sys_yield_to to sys_sched_yield_to in include/asm-x86_64/unistd.h
fixes the problem.
-- 
Markus
-
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: SATA errors/messages after upgrade to 2.6.20.7

[Jeff Garzik]

[EMAIL PROTECTED] wrote:


It is a Samsung HD501LJ SATA drive connected to 631xESB/632xESB controller.
Reading and writing every block of the drive does not generate any other
errors/failures. This is observed in 2.6.20.7 like a clockwork on any
badblocks -v run or rebuild of a MD raid1 array onto the disk. 


It, however, was not observed on 2.6.18 in 182 badblocks -v runs followed by
rebuild of MD raid1 array.

Any idea what it might be?

Apr 23 14:45:34 stdsrv-x86-64bit kernel: ata4.00: exception Emask 0x0 SAct 0x1 
SErr 0x0 action 0x0
Apr 23 14:45:34 stdsrv-x86-64bit kernel: ata4.00: (irq_stat 0x4008)
Apr 23 14:45:34 stdsrv-x86-64bit kernel: ata4.00: cmd 
60/80:00:14:16:c4/00:00:05:00:00/40 tag 0 cdb 0x0 data 65536 in
Apr 23 14:45:34 stdsrv-x86-64bit kernel:  res 
51/40:00:40:16:c4/6f:00:05:00:00/40 Emask 0x9 (media error)


Does 'smartctl -d ata -t long /dev/X' return errors?

Media error is typically just that...

Jeff



-
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 2/2] x86_64: Remove CONFIG_PHYSICAL_START and CONFIG_RELOCATABLE

[Eric W. Biederman]

Now that the vmlinux is marked as relocatable there is no reason to
retain the CONFIG_PHYSICAL_START option, as we can put the binary we
have at any 2MB aligned address in memory.

With CONFIG_PHYSICAL_START gone the handful of code lines that depend
on CONFIG_RELOCATABLE no longer make sense to be conditional and can
be removed.

The big win of this patch (besides Kconfig simplicity) is that the
nasty BUILD_BUG_ON test for people misaligning their kernel when using
CONFIG_PHYSICAL_START can be removed as this case can only happen with
CONFIG_PHYSICAL_START selected.

Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
---
 arch/x86_64/Kconfig|   55 +---
 arch/x86_64/Makefile   |2 -
 arch/x86_64/boot/compressed/head.S |   13 +
 arch/x86_64/boot/setup.S   |4 --
 arch/x86_64/defconfig  |2 -
 arch/x86_64/kernel/head64.c|7 
 include/asm-x86_64/page.h  |2 +-
 7 files changed, 3 insertions(+), 82 deletions(-)

diff --git a/arch/x86_64/Kconfig b/arch/x86_64/Kconfig
index 773b487..713c1ad 100644
--- a/arch/x86_64/Kconfig
+++ b/arch/x86_64/Kconfig
@@ -565,62 +565,9 @@ config CRASH_DUMP
   which are loaded in the main kernel with kexec-tools into
   a specially reserved region and then later executed after
   a crash by kdump/kexec. The crash dump kernel must be compiled
- to a memory address not used by the main kernel or BIOS using
- PHYSICAL_START.
+ to a memory address not used by the main kernel or BIOS
   For more details see Documentation/kdump/kdump.txt
 
-config RELOCATABLE
-   bool "Build a relocatable kernel(EXPERIMENTAL)"
-   depends on EXPERIMENTAL
-   help
- Builds a relocatable kernel. This enables loading and running
- a kernel binary from a different physical address than it has
- been compiled for.
-
- One use is for the kexec on panic case where the recovery kernel
- must live at a different physical address than the primary
- kernel.
-
- Note: If CONFIG_RELOCATABLE=y, then kernel run from the address
- it has been loaded at and compile time physical address
- (CONFIG_PHYSICAL_START) is ignored.
-
-config PHYSICAL_START
-   hex "Physical address where the kernel is loaded" if (EMBEDDED || 
CRASH_DUMP)
-   default "0x20"
-   help
- This gives the physical address where the kernel is loaded. It
- should be aligned to 2MB boundary.
-
- If kernel is a not relocatable (CONFIG_RELOCATABLE=n) then
- bzImage will decompress itself to above physical address and
- run from there. Otherwise, bzImage will run from the address where
- it has been loaded by the boot loader and will ignore above physical
- address.
-
- In normal kdump cases one does not have to set/change this option
- as now bzImage can be compiled as a completely relocatable image
- (CONFIG_RELOCATABLE=y) and be used to load and run from a different
- address. This option is mainly useful for the folks who don't want
- to use a bzImage for capturing the crash dump and want to use a
- vmlinux instead.
-
- So if you are using bzImage for capturing the crash dump, leave
- the value here unchanged to 0x20 and set CONFIG_RELOCATABLE=y.
- Otherwise if you plan to use vmlinux for capturing the crash dump
- change this value to start of the reserved region (Typically 16MB
- 0x100). In other words, it can be set based on the "X" value as
- specified in the "[EMAIL PROTECTED]" command line boot parameter
- passed to the panic-ed kernel. Typically this parameter is set as
- [EMAIL PROTECTED] Please take a look at
- Documentation/kdump/kdump.txt for more details about crash dumps.
-
- Usage of bzImage for capturing the crash dump is advantageous as
- one does not have to build two kernels. Same kernel can be used
- as production kernel and capture kernel.
-
- Don't change this unless you know what you are doing.
-
 config SECCOMP
bool "Enable seccomp to safely compute untrusted bytecode"
depends on PROC_FS
diff --git a/arch/x86_64/Makefile b/arch/x86_64/Makefile
index 5ae79ab..5d96f4f 100644
--- a/arch/x86_64/Makefile
+++ b/arch/x86_64/Makefile
@@ -124,7 +124,6 @@ define archhelp
   echo  '  isoimage - Create a boot CD-ROM image'
 endef
 
-ifeq ($(CONFIG_RELOCATABLE),y)
 define cmd_vmlinux__
   $(LD) $(LDFLAGS) $(LDFLAGS_vmlinux) -o $@ \
   -T $(vmlinux-lds) $(vmlinux-init)\
@@ -132,7 +131,6 @@ define cmd_vmlinux__
   $(filter-out $(vmlinux-lds) $(vmlinux-init) $(vmlinux-main) FORCE ,$^) \
   && scripts/mketrel $@
 endef
-endif
 
 CLEAN_FILES += arch/$(ARCH)/boot/fdimage \
   

[PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header.

[Eric W. Biederman]

Currently because vmlinux does not reflect that the kernel is relocatable
we still have to support CONFIG_PHYSICAL_START.  So this patch adds a small
c program to do what we cannot do with a linker script, set the elf header
type to ET_DYN.

This should remove the last obstacle to removing CONFIG_PHYSICAL_START
on x86_64.

Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
---
 arch/x86_64/Kconfig  |4 +++
 arch/x86_64/Makefile |   10 +++
 scripts/Makefile |   11 ---
 scripts/mketrel.c|   70 ++
 4 files changed, 90 insertions(+), 5 deletions(-)
 create mode 100644 scripts/mketrel.c

diff --git a/arch/x86_64/Kconfig b/arch/x86_64/Kconfig
index 16d9bf3..773b487 100644
--- a/arch/x86_64/Kconfig
+++ b/arch/x86_64/Kconfig
@@ -121,6 +121,10 @@ config ARCH_HAS_ILOG2_U64
bool
default n
 
+config ELF_RELOCATABLE
+   bool
+   default y
+
 source "init/Kconfig"
 
 
diff --git a/arch/x86_64/Makefile b/arch/x86_64/Makefile
index 9dd91b2..5ae79ab 100644
--- a/arch/x86_64/Makefile
+++ b/arch/x86_64/Makefile
@@ -124,6 +124,16 @@ define archhelp
   echo  '  isoimage - Create a boot CD-ROM image'
 endef
 
+ifeq ($(CONFIG_RELOCATABLE),y)
+define cmd_vmlinux__
+  $(LD) $(LDFLAGS) $(LDFLAGS_vmlinux) -o $@ \
+  -T $(vmlinux-lds) $(vmlinux-init)\
+  --start-group $(vmlinux-main) --end-group\
+  $(filter-out $(vmlinux-lds) $(vmlinux-init) $(vmlinux-main) FORCE ,$^) \
+  && scripts/mketrel $@
+endef
+endif
+
 CLEAN_FILES += arch/$(ARCH)/boot/fdimage \
   arch/$(ARCH)/boot/image.iso \
   arch/$(ARCH)/boot/mtools.conf
diff --git a/scripts/Makefile b/scripts/Makefile
index 1c73c5a..ddba550 100644
--- a/scripts/Makefile
+++ b/scripts/Makefile
@@ -7,11 +7,12 @@
 # conmakehash:   Create chartable
 # conmakehash:  Create arrays for initializing the kernel console tables
 
-hostprogs-$(CONFIG_KALLSYMS) += kallsyms
-hostprogs-$(CONFIG_LOGO) += pnmtologo
-hostprogs-$(CONFIG_VT)   += conmakehash
-hostprogs-$(CONFIG_PROM_CONSOLE) += conmakehash
-hostprogs-$(CONFIG_IKCONFIG) += bin2c
+hostprogs-$(CONFIG_KALLSYMS)+= kallsyms
+hostprogs-$(CONFIG_LOGO)+= pnmtologo
+hostprogs-$(CONFIG_VT)  += conmakehash
+hostprogs-$(CONFIG_PROM_CONSOLE)+= conmakehash
+hostprogs-$(CONFIG_IKCONFIG)+= bin2c
+hostprogs-$(CONFIG_ELF_RELOCATABLE) += mketrel
 
 always := $(hostprogs-y) $(hostprogs-m)
 
diff --git a/scripts/mketrel.c b/scripts/mketrel.c
new file mode 100644
index 000..effa312
--- /dev/null
+++ b/scripts/mketrel.c
@@ -0,0 +1,70 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static int fd;
+unsigned char e_ident[EI_NIDENT];
+
+void die(const char * str, ...)
+{
+   va_list args;
+   va_start(args, str);
+   vfprintf(stderr, str, args);
+   fputc('\n', stderr);
+   exit(1);
+}
+
+void file_open(const char *name)
+{
+   if ((fd = open(name, O_RDWR, 0)) < 0)
+   die("Unable to open `%s': %m", name);
+}
+
+static void mketrel(void)
+{
+   unsigned char e_type[2];
+   if (read(fd, _ident, sizeof(e_ident)) != sizeof(e_ident))
+   die("Cannot read ELF header: %s\n", strerror(errno));
+
+   if (memcmp(e_ident, ELFMAG, 4) != 0)
+   die("No ELF magic\n");
+
+   if ((e_ident[EI_CLASS] != ELFCLASS64) &&
+   (e_ident[EI_CLASS] != ELFCLASS32))
+   die("Unrecognized ELF class: %x\n", e_ident[EI_CLASS]);
+   
+   if ((e_ident[EI_DATA] != ELFDATA2LSB) &&
+   (e_ident[EI_DATA] != ELFDATA2MSB))
+   die("Unrecognized ELF data encoding: %x\n", e_ident[EI_DATA]);
+
+   if (e_ident[EI_VERSION] != EV_CURRENT)
+   die("Unknown ELF version: %d\n", e_ident[EI_VERSION]);
+
+   if (e_ident[EI_DATA] == ELFDATA2LSB) {
+   e_type[0] = ET_REL & 0xff;
+   e_type[1] = ET_REL >> 8;
+   } else {
+   e_type[1] = ET_REL & 0xff;
+   e_type[0] = ET_REL >> 8;
+   }
+
+   if (write(fd, _type, sizeof(e_type)) != sizeof(e_type))
+   die("Cannot write ELF type: %s\n", strerror(errno));
+}
+
+int main(int argc, char **argv)
+{
+   if (argc != 2)
+   die("Usage: mketrel: vmlinux");
+   file_open(argv[1]);
+   mketrel();
+   close(fd);
+   return 0;
+}
-- 
1.5.1.1.181.g2de0

-
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: Fix potential overflow in perfctr reservation

[YOSHIFUJI Hideaki / 吉藤英明]

Hello.

In article <[EMAIL PROTECTED]> (at Sun, 22 Apr 2007 01:09:17 -0700), Andrew 
Morton <[EMAIL PROTECTED]> says:

> > [PATCH] x86: Fix potential overflow in perfctr reservation
:
> The created a warning storm:
> 
> 
> arch/i386/kernel/nmi.c: In function 'avail_to_resrv_perfctr_nmi_bit':
> arch/i386/kernel/nmi.c:129: warning: passing argument 2 of 
> 'constant_test_bit' from incompatible pointer type
> arch/i386/kernel/nmi.c:129: warning: passing argument 2 of 
> 'variable_test_bit' from incompatible pointer type
:
> diff -puN 
> arch/i386/kernel/nmi.c~fix-x86-fix-potential-overflow-in-perfctr-reservation 
> arch/i386/kernel/nmi.c
> --- 
> a/arch/i386/kernel/nmi.c~fix-x86-fix-potential-overflow-in-perfctr-reservation
> +++ a/arch/i386/kernel/nmi.c
> @@ -126,7 +126,7 @@ int avail_to_resrv_perfctr_nmi_bit(unsig
>   int cpu;
>   BUG_ON(counter > NMI_MAX_COUNTER_BITS);
>   for_each_possible_cpu (cpu) {
> - if (test_bit(counter, _cpu(perfctr_nmi_owner, cpu)))
> + if (test_bit(counter, per_cpu(perfctr_nmi_owner, cpu)))
>   return 0;
>   }
>   return 1;
:
> 
> I worry rather a lot about how well runtime tested this very late change
> was, and whether it works correctly even with this fix applied.  Perhaps
> we should jsut revert?

Is DEFINE_PER_CPU(type, var[num]) is really valid?
I guess it should be DEFINE_PER_CPU(type[num], var), no?


[I386] NMI: Fix per_cpu() usage.

Per-cpu array should be declared as DEFINE_PER_CPU(type[size], name),
not as DEFINE_PER_CPU(type, name[size]).

Signed-off-by: YOSHIFUJI Hideaki <[EMAIL PROTECTED]>

diff --git a/arch/i386/kernel/nmi.c b/arch/i386/kernel/nmi.c
index 9f1e8c1..eddb4f7 100644
--- a/arch/i386/kernel/nmi.c
+++ b/arch/i386/kernel/nmi.c
@@ -48,8 +48,8 @@ int nmi_watchdog_enabled;
 #define NMI_MAX_COUNTER_BITS 66
 #define NMI_MAX_COUNTER_LONGS BITS_TO_LONGS(NMI_MAX_COUNTER_BITS)
 
-static DEFINE_PER_CPU(unsigned long, perfctr_nmi_owner[NMI_MAX_COUNTER_LONGS]);
-static DEFINE_PER_CPU(unsigned long, evntsel_nmi_owner[NMI_MAX_COUNTER_LONGS]);
+static DEFINE_PER_CPU(unsigned long [NMI_MAX_COUNTER_LONGS], 
perfctr_nmi_owner);
+static DEFINE_PER_CPU(unsigned long [NMI_MAX_COUNTER_LONGS], 
evntsel_nmi_owner);
 
 static cpumask_t backtrace_mask = CPU_MASK_NONE;
 /* nmi_active:
@@ -126,7 +126,7 @@ int avail_to_resrv_perfctr_nmi_bit(unsigned int counter)
int cpu;
BUG_ON(counter > NMI_MAX_COUNTER_BITS);
for_each_possible_cpu (cpu) {
-   if (test_bit(counter, _cpu(perfctr_nmi_owner, cpu)))
+   if (test_bit(counter, per_cpu(perfctr_nmi_owner, cpu)))
return 0;
}
return 1;
@@ -142,7 +142,7 @@ int avail_to_resrv_perfctr_nmi(unsigned int msr)
BUG_ON(counter > NMI_MAX_COUNTER_BITS);
 
for_each_possible_cpu (cpu) {
-   if (test_bit(counter, _cpu(perfctr_nmi_owner, cpu)))
+   if (test_bit(counter, per_cpu(perfctr_nmi_owner, cpu)))
return 0;
}
return 1;
@@ -157,7 +157,7 @@ static int __reserve_perfctr_nmi(int cpu, unsigned int msr)
counter = nmi_perfctr_msr_to_bit(msr);
BUG_ON(counter > NMI_MAX_COUNTER_BITS);
 
-   if (!test_and_set_bit(counter, _cpu(perfctr_nmi_owner, cpu)))
+   if (!test_and_set_bit(counter, per_cpu(perfctr_nmi_owner, cpu)))
return 1;
return 0;
 }
@@ -171,7 +171,7 @@ static void __release_perfctr_nmi(int cpu, unsigned int msr)
counter = nmi_perfctr_msr_to_bit(msr);
BUG_ON(counter > NMI_MAX_COUNTER_BITS);
 
-   clear_bit(counter, _cpu(perfctr_nmi_owner, cpu));
+   clear_bit(counter, per_cpu(perfctr_nmi_owner, cpu));
 }
 
 int reserve_perfctr_nmi(unsigned int msr)
@@ -207,7 +207,7 @@ int __reserve_evntsel_nmi(int cpu, unsigned int msr)
counter = nmi_evntsel_msr_to_bit(msr);
BUG_ON(counter > NMI_MAX_COUNTER_BITS);
 
-   if (!test_and_set_bit(counter, _cpu(evntsel_nmi_owner, cpu)[0]))
+   if (!test_and_set_bit(counter, per_cpu(evntsel_nmi_owner, cpu)))
return 1;
return 0;
 }
@@ -221,7 +221,7 @@ static void __release_evntsel_nmi(int cpu, unsigned int msr)
counter = nmi_evntsel_msr_to_bit(msr);
BUG_ON(counter > NMI_MAX_COUNTER_BITS);
 
-   clear_bit(counter, _cpu(evntsel_nmi_owner, cpu)[0]);
+   clear_bit(counter, per_cpu(evntsel_nmi_owner, cpu));
 }
 
 int reserve_evntsel_nmi(unsigned int msr)

-- 
YOSHIFUJI Hideaki @ USAGI Project  <[EMAIL PROTECTED]>
GPG-FP  : 9022 65EB 1ECF 3AD1 0BDF  80D8 4807 F894 E062 0EEA
-
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] fault injection: fix failslab with CONFIG_NUMA

[Pekka J Enberg]

On Sun, 22 Apr 2007, Akinobu Mita wrote:
> Currently failslab injects failures into cache_alloc().
> But with enabling CONFIG_NUMA it's not enough to let actual
> slab allocator functions (kmalloc, kmem_cache_alloc, ...) return NULL.
> 
> This patch moves fault injection hook inside of __cache_alloc() and
> __cache_alloc_node(). These are lower call path than cache_alloc()
> and enable to inject faulures to slab allocators with CONFIG_NUMA.

Looks good to me.

Acked-by: Pekka Enberg <[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] lazy freeing of memory through MADV_FREE

[Nick Piggin]

Jakub Jelinek wrote:

On Fri, Apr 20, 2007 at 07:52:44PM -0400, Rik van Riel wrote:


It turns out that Nick's patch does not improve peak
performance much, but it does prevent the decline when
running with 16 threads on my quad core CPU!

We _definately_ want both patches, there's a huge benefit
in having them both.

Here are the transactions/seconds for each combination:

  vanilla   new glibc  madv_free kernel   madv_free + mmap_sem
threads

1 610 609 596545
2103211361196   1200
4107011282014   2024
8100010881665   2087
1677910731310   1999



FYI, I have uploaded a testing glibc that uses MADV_FREE and falls back
to MADV_DONTUSE if MADV_FREE is not available, to
http://people.redhat.com/jakub/glibc/2.5.90-21.1/


Hmm, I wonder how glibc malloc stacks up to tcmalloc on this test
(after the mmap_sem patch as well).

I'll try running that as well!

--
SUSE Labs, Novell Inc.
-
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: How to make mmap'ed kernel buffer non-cacheable

[Nick Piggin]

Bhuvan Kumar MITTAL wrote:

Hi Alan,

I believe that dma_alloc_coherent will mark the kernel buffer as uncached at alocation time. 
But that is not my intention. I have mapped some user space memory to the kernel buffer and I wish to ensure that the contents of both are coherent and correctly ordered. 


In other words I wish to flush the contents of the kernel buffer to user space 
as soon as new data is available in my kernel buffer. How to do that? Will 
doing mysnc from the user space help?


msync is only for pagecache. If you modify user mapped RAM from the kernel, or 
wish
to read user modified RAM from the kernel, you should issue a flush_dcache_page 
after
and before, respectively. See Documentation/cachetlb.h.

Does that fix it? What are the details of your platform?

--
SUSE Labs, Novell Inc.
-
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] lazy freeing of memory through MADV_FREE

[Rik van Riel]

Nick Piggin wrote:


So where is the down_write coming from in this workload, I wonder?
Heap management? What syscalls?


Trying to answer this question, I straced the mysql threads that
showed up in top when running a single threaded sysbench workload.

There were no mmap, munmap, brk, mprotect or madvise system calls
in the trace.

MySQL has me puzzled, but it seems to have some other people
interested too.

I think I'll go play a bit with ebizzy now, to see how other
workloads are affected by our kernel changes.
-
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: How to make mmap'ed kernel buffer non-cacheable

[Bhuvan Kumar MITTAL]

Hi Alan,

I believe that dma_alloc_coherent will mark the kernel buffer as uncached at 
alocation time. 
But that is not my intention. I have mapped some user space memory to the 
kernel buffer and I wish to ensure that the contents of both are coherent and 
correctly ordered. 

In other words I wish to flush the contents of the kernel buffer to user space 
as soon as new data is available in my kernel buffer. How to do that? Will 
doing mysnc from the user space help?

Rather than flushing everytime (or msyncing) I intend to make my user-to-kernel 
mapping as non cacheable so that multiple flushing can be avoided.

Bhuvan 

> Hi,
>   I am working on an audio device driver development on Linux. I have a 
> kernel buffer which I have mapped to user space using mmap call from user 
> space. My problem is that the data which comes to the kernel buffer is 
> getting dropped in user space and I get only 50-60% of the data which is 
> randomly ordered. The user to kernel level buffer address translation code is 
> fine and I suspect this data dropping is occurring coz the kernel buffer is 
> cacheable. Please suggest me some way of making the entire buffer non 
> cacheable. I am stuck on this for quite a while now. 

The dma mapping API (or the PCI equivalent) provide the neccessary
behaviours for DMA receive, DMA send and consistent memory space in a
portable fashion.

That may not be done using uncachable memory in all cases as not all
processors even support uncacheable memory spaces.

If you are using the ALSA core routines (snd_dma_alloc_coherent) then
ALSA already uses dma_alloc_coherent to ensure the memory is allocated
for the appropriate use and will be kernel marked uncached.

-
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 -mm 2/3] freezer: Introduce freezer_flags

[Satyam Sharma]

Hi Rafael,


+/*
+ * Per task flags used by the freezer
+ *
+ * They should not be referred to directly outside of this file.
+ */
+#define TFF_NOFREEZE   0   /* task should not be frozen */
+#define TFF_FREEZE 8   /* task should go to the refrigerator ASAP */
+#define TFF_SKIP   9   /* do not count this task as freezable */
+#define TFF_FROZEN 10  /* task is frozen */


Aren't NOFREEZE and SKIP doing the same thing? One of them appears
superfluous. I'm looking at 21-rc6-mm1 and vfork(2) seems to be its
only user. Seeing how vfork(2) used it, can't the call to
freezer_do_not_count() be replaced with a call to freezer_exempt()?
Similarly, the freezer_count() after the wait_for_completion might
just as well be a clear of the NOFREEZE bit followed by a
try_to_freeze(). Could you please explain the rationale behind the
SKIP flag?

I do see that SKIP seems to be relevant for only userspace threads and
presumably only kernel threads are allowed to set NOFREEZE, but why
this distinction between the two?

Also, I do have several gripes against the naming of some of these functions:


 static inline int freezing(struct task_struct *p)


This could be called task_should_freeze().


 /*
- * Sometimes we may need to cancel the previous 'freeze' request
+ * Cancel the previous 'freeze' request
  */
 static inline void do_not_freeze(struct task_struct *p)


This definitely needs to be undo_freeze() or unfreeze().
do_not_freeze() sounds like what freeze_exempt() does.


 static inline void frozen_process(struct task_struct *p)


frozen_process() sounds like what frozen() is supposed to do. This
could instead be mark_task_frozen(), or even mark_frozen(), because
only the current task can ever mark *itself* frozen before freezing
itself.


 static inline void freezer_do_not_count(void)
 static inline void freezer_count(void)


These could be called freezer_skip() and freezer_do_not_skip(). Better
to stick to consistent naming / terminology.

Cheers,
Satyam
-
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] CFS scheduler, -v5

[Nick Piggin]

On Mon, Apr 23, 2007 at 05:43:10AM +0200, Ingo Molnar wrote:
> 
> * Nick Piggin <[EMAIL PROTECTED]> wrote:
> 
> > > note that CFS's "granularity" value is not directly comparable to 
> > > "timeslice length":
> > 
> > Right, but it does introduce the kbuild regression, [...]
> 
> Note that i increased the granularity from 1msec to 5msecs after your 
> kbuild report, could you perhaps retest kbuild with the default settings 
> of -v5?

I'm looking at mysql again today, but I will try eventually. It was
just a simple kbuild.


> > [...] and as we discussed, this will be only worse on newer CPUs with 
> > bigger caches or less naturally context switchy workloads.
> 
> yeah - but they'll all be quad core, so the SMP timeslice multiplicator 
> should do the trick. Most of the CFS testers use single-CPU systems.

But desktop users could have have quad thread and even 8 thread CPUs
soon, so if the number doesn't work for both then you're in trouble.
It just smells like a hack to scale with CPU numbers.

 
> > > (in -v6 i'll scale the granularity up a bit with the number of CPUs, 
> > > like SD does. That should get the right result on larger SMP boxes 
> > > too.)
> > 
> > I don't really like the scaling with SMP thing. The cache effects are 
> > still going to be significant on small systems, and there are lots of 
> > non-desktop users of those (eg. clusters).
> 
> CFS using clusters will want to tune the granularity up drastically 
> anyway, to 1 second or more, to maximize throughput. I think a small 
> default with a scale-up-on-SMP rule is pretty sane. We'll gather some 
> more kbuild data and see what happens, ok?
> 
> > > while i agree it's a tad too finegrained still, I agree with Con's 
> > > choice: rather err on the side of being too finegrained and lose 
> > > some small amount of throughput on cache-intense workloads like 
> > > compile jobs, than err on the side of being visibly too choppy for 
> > > users on the desktop.
> > 
> > So cfs gets too choppy if you make the effective timeslice comparable 
> > to mainline?
> 
> it doesnt in any test i do, but again, i'm erring on the side of it 
> being more interactive.

I'd start by erring on the side of trying to ensure no obvious
performance regressions like this because that's the easy part. Suppose
everybody finds your scheduler wonderfully interactive, but you can't
make it so with a larger timeslice?

For _real_ desktop systems, sure, erring on the side of being more
interactive is fine. For RFC patches for testing, I really think you
could be taking advantage of the fact that people will give you feedback
on the issue.


-
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] lazy freeing of memory through MADV_FREE

[Nick Piggin]

Rik van Riel wrote:


I've added a 5th column, with just your mmap_sem patch and
without my madv_free patch.  It is run with the glibc patch,
which should make it fall back to MADV_DONTNEED after the
first MADV_FREE call fails.


Thanks! (I edited slightly so it doesn't wrap)



  vanilla   new glibc   madv_freemmap_semboth
threads

1 610 609 596 534 545
210321136119611801200
410701128201420272024
810001088166520892087
167791073131020121999


Not doing the mprotect calls is the big one I guess, especially
the fact that we don't need to take the mmap_sem for writing.


Yes.



With both our patches, single and two thread performance with
MySQL sysbench is somewhat better than with just your patch,
4 and 8 thread performance are basically the same and just
your patch gives a slight benefit with 16 threads.

I guess I should benchmark up to 64 or 128 threads tomorrow,
to see if this is just luck or if the cache benefit of doing
the page faults and reusing hot pages is faster than not
having page faults at all.

I should run some benchmarks on other systems, too.  Some of
these results could be an artifact of my quad core CPU.  The
results could be very different on other systems...


I'm getting the 16 core box out of retirement as we speak :)

--
SUSE Labs, Novell Inc.
-
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: Question about Reiser4

[William Heimbigner]

Eric Hopper wrote:

 I know that this whole effort has been put in disarray by the
 prosecution of Hans Reiser, but I'm curious as to its status. 


It was in disarray well before.  Many of the reiser4 features,
like filesystem plugins, make more technical sense in the Linux
VFS, but made more business sense for Namesys as a reiserfs 4
thing.  That lead to a stalemate.

Shouldn't it be a matter of stability though? Benchmarks suggest that 
reiser4 is a good file system; reiser4 is the successor to the 
already-accepted reiserfs; we've got experimental ext4 support but no 
reiser4 support, etc.


I don't see why something like plugins should matter. If it works enough 
to be marked as experimental, why shouldn't reiser4 support be included?
It's a pain for me personally to have to patch any kernel with reiser4 
support so I can use the reiser4 fs.


William Heimbigner
[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] lazy freeing of memory through MADV_FREE

[Rik van Riel]

Rik van Riel wrote:

Nick Piggin wrote:

Rik van Riel wrote:

Nick Piggin wrote:


Rik van Riel wrote:



Here are the transactions/seconds for each combination:


I've added a 5th column, with just your mmap_sem patch and
without my madv_free patch.  It is run with the glibc patch,
which should make it fall back to MADV_DONTNEED after the
first MADV_FREE call fails.

   vanilla   new glibc  madv_free kernel   madv_free + mmap_sem  
mmap_sem

threads

1 610 609 596545 534
2103211361196   12001180
4107011282014   20242027
8100010881665   20872089
1677910731310   19992012


Now that I think about it - this is all with the rawhide kernel
configuration, which has an ungodly number of debug config
options enabled.

I should try this with a more normal kernel, on various different
systems.

It would also be helpful if other people tried this same benchmark,
and others, on their systems.

-
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: Question about Reiser4

[Rik van Riel]

Eric Hopper wrote:

I know that this whole effort has been put in disarray by the
prosecution of Hans Reiser, but I'm curious as to its status. 


It was in disarray well before.  Many of the reiser4 features,
like filesystem plugins, make more technical sense in the Linux
VFS, but made more business sense for Namesys as a reiserfs 4
thing.  That lead to a stalemate.

> Is Reiser4 going to be going into the Linus kernel anytime soon?

I wouldn't count on it.
-
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] lazy freeing of memory through MADV_FREE

[Rik van Riel]

Nick Piggin wrote:

Rik van Riel wrote:

Nick Piggin wrote:


Rik van Riel wrote:



Here are the transactions/seconds for each combination:


I've added a 5th column, with just your mmap_sem patch and
without my madv_free patch.  It is run with the glibc patch,
which should make it fall back to MADV_DONTNEED after the
first MADV_FREE call fails.


   vanilla   new glibc  madv_free kernel   madv_free + mmap_sem  mmap_sem
threads

1 610 609 596545 534
2103211361196   12001180
4107011282014   20242027
8100010881665   20872089
1677910731310   19992012


Not doing the mprotect calls is the big one I guess, especially
the fact that we don't need to take the mmap_sem for writing.

With both our patches, single and two thread performance with
MySQL sysbench is somewhat better than with just your patch,
4 and 8 thread performance are basically the same and just
your patch gives a slight benefit with 16 threads.

I guess I should benchmark up to 64 or 128 threads tomorrow,
to see if this is just luck or if the cache benefit of doing
the page faults and reusing hot pages is faster than not
having page faults at all.

I should run some benchmarks on other systems, too.  Some of
these results could be an artifact of my quad core CPU.  The
results could be very different on other systems...


Yeah. That's funny, because it means either there is some
contention on the mmap_sem (or ptl) at 1 thread, or that my
patch alters the uncontended performance.


Maybe MySQL has various different threads to do
different tasks.  Something to look into...
-
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] CFS scheduler, -v5

[Ingo Molnar]

* Nick Piggin <[EMAIL PROTECTED]> wrote:

> > note that CFS's "granularity" value is not directly comparable to 
> > "timeslice length":
> 
> Right, but it does introduce the kbuild regression, [...]

Note that i increased the granularity from 1msec to 5msecs after your 
kbuild report, could you perhaps retest kbuild with the default settings 
of -v5?

> [...] and as we discussed, this will be only worse on newer CPUs with 
> bigger caches or less naturally context switchy workloads.

yeah - but they'll all be quad core, so the SMP timeslice multiplicator 
should do the trick. Most of the CFS testers use single-CPU systems.

> > (in -v6 i'll scale the granularity up a bit with the number of CPUs, 
> > like SD does. That should get the right result on larger SMP boxes 
> > too.)
> 
> I don't really like the scaling with SMP thing. The cache effects are 
> still going to be significant on small systems, and there are lots of 
> non-desktop users of those (eg. clusters).

CFS using clusters will want to tune the granularity up drastically 
anyway, to 1 second or more, to maximize throughput. I think a small 
default with a scale-up-on-SMP rule is pretty sane. We'll gather some 
more kbuild data and see what happens, ok?

> > while i agree it's a tad too finegrained still, I agree with Con's 
> > choice: rather err on the side of being too finegrained and lose 
> > some small amount of throughput on cache-intense workloads like 
> > compile jobs, than err on the side of being visibly too choppy for 
> > users on the desktop.
> 
> So cfs gets too choppy if you make the effective timeslice comparable 
> to mainline?

it doesnt in any test i do, but again, i'm erring on the side of it 
being more interactive.

Ingo
-
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] CFS scheduler, -v5

[Nick Piggin]

On Mon, Apr 23, 2007 at 04:55:53AM +0200, Ingo Molnar wrote:
> 
> * Nick Piggin <[EMAIL PROTECTED]> wrote:
> 
> > > the biggest user-visible change in -v5 are various interactivity 
> > > improvements (especially under higher load) to fix reported 
> > > regressions, and an improved way of handling nice levels. There's 
> > > also a new sys_sched_yield_to() syscall implementation for i686 and 
> > > x86_64.
> > > 
> > > All known regressions have been fixed. (knock on wood)
> > 
> > I think the granularity is still much too low. Why not increase it to 
> > something more reasonable as a default?
> 
> note that CFS's "granularity" value is not directly comparable to 
> "timeslice length":

Right, but it does introduce the kbuild regression, and as we
discussed, this will be only worse on newer CPUs with bigger
caches or less naturally context switchy workloads.


> > [ Note: while CFS's default preemption granularity is currently set to
> >   5 msecs, this value does not directly transform into timeslices: for 
> >   example two CPU-intense tasks will have effective timeslices of 10 
> >   msecs with this setting. ]
> 
> also, i just checked SD: 0.46 defaults to 8 msecs rr_interval (on 1 CPU 
> systems), which is lower than the 10 msecs effective timeslice length 
> CVS-v5 achieves on two CPU-bound tasks.

This is about an order of magnitude more than the current scheduler, so
I still think it is too small.


> (in -v6 i'll scale the granularity up a bit with the number of CPUs, 
> like SD does. That should get the right result on larger SMP boxes too.)

I don't really like the scaling with SMP thing. The cache effects are
still going to be significant on small systems, and there are lots of
non-desktop users of those (eg. clusters).


> while i agree it's a tad too finegrained still, I agree with Con's 
> choice: rather err on the side of being too finegrained and lose some 
> small amount of throughput on cache-intense workloads like compile jobs, 
> than err on the side of being visibly too choppy for users on the 
> desktop.

So cfs gets too choppy if you make the effective timeslice comparable
to mainline?

My approach is completely the opposite. For testing, I prefer to make
the timeslice as large as possible so any problems or regressions are
really noticable and will be reported; it can be scaled back to be
smaller once those kinks are ironed out.
-
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] CFS scheduler, -v5 (build problem - make headers_check fails)

[Zach Carter]

Ingo Molnar wrote:
i'm pleased to announce release -v5 of the CFS scheduler patchset. The 
patch against v2.6.21-rc7 and v2.6.20.7 can be downloaded from:




FYI, make headers_check seems to fail on this:

[EMAIL PROTECTED] linux-2.6]$ make headers_check

[snip]

  CHECK   include/linux/usb/cdc.h
  CHECK   include/linux/usb/audio.h
make[2]: *** No rule to make target `/src/linux-2.6/usr/include/linux/.check.sched.h', needed by 
`__headerscheck'.  Stop.

make[1]: *** [linux] Error 2
make: *** [headers_check] Error 2
[EMAIL PROTECTED] linux-2.6]$

This also fails if I have CONFIG_HEADERS_CHECK=y in my .config

unset CONFIG_HEADERS_CHECK and it builds just fine.

-Zach
-
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 -mm 2/3] freezer: Introduce freezer_flags

[Satyam Sharma]

On 4/23/07, Paul Jackson <[EMAIL PROTECTED]> wrote:

One more question - why would I want to do this?


Check out the FAQ in Documentation/power/swsusp.txt.


Is this like something that would be useful on a laptop, to suspend
activity and reduce battery drain, while preserving the current state
of ones sessions and avoiding having to logout or shutdown?


Yes, the original purpose for the inclusion of the freezer code was to
support suspend-resume (mainly for laptops, but suspend-resume could
be useful in other circumstances too, see the FAQ).


Is it useful for quietting a system down before doing hot plug or
unplug of key components, such as processors and memory?


Yes, the freezer is (proposed to be, at least) moving on from being
merely a suspend-resume-only thing to other usage scenarios, such as
kprobes and hotlpug.
-
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 errors/messages after upgrade to 2.6.20.7

[alex=lists-linux-kernel]

It is a Samsung HD501LJ SATA drive connected to 631xESB/632xESB controller.
Reading and writing every block of the drive does not generate any other
errors/failures. This is observed in 2.6.20.7 like a clockwork on any
badblocks -v run or rebuild of a MD raid1 array onto the disk. 

It, however, was not observed on 2.6.18 in 182 badblocks -v runs followed by
rebuild of MD raid1 array.

Any idea what it might be?

Apr 23 14:45:34 stdsrv-x86-64bit kernel: ata4.00: exception Emask 0x0 SAct 0x1 
SErr 0x0 action 0x0
Apr 23 14:45:34 stdsrv-x86-64bit kernel: ata4.00: (irq_stat 0x4008)
Apr 23 14:45:34 stdsrv-x86-64bit kernel: ata4.00: cmd 
60/80:00:14:16:c4/00:00:05:00:00/40 tag 0 cdb 0x0 data 65536 in
Apr 23 14:45:34 stdsrv-x86-64bit kernel:  res 
51/40:00:40:16:c4/6f:00:05:00:00/40 Emask 0x9 (media error)
Apr 23 14:45:34 stdsrv-x86-64bit kernel: ata4.00: configured for UDMA/133
Apr 23 14:45:34 stdsrv-x86-64bit kernel: ata4: EH complete
Apr 23 14:45:37 stdsrv-x86-64bit kernel: ata4.00: exception Emask 0x0 SAct 0x1 
SErr 0x0 action 0x0
Apr 23 14:45:37 stdsrv-x86-64bit kernel: ata4.00: (irq_stat 0x4008)
Apr 23 14:45:37 stdsrv-x86-64bit kernel: ata4.00: cmd 
60/80:00:14:16:c4/00:00:05:00:00/40 tag 0 cdb 0x0 data 65536 in
Apr 23 14:45:37 stdsrv-x86-64bit kernel:  res 
51/40:00:40:16:c4/6f:00:05:00:00/40 Emask 0x9 (media error)
Apr 23 14:45:37 stdsrv-x86-64bit kernel: ata4.00: configured for UDMA/133
Apr 23 14:45:37 stdsrv-x86-64bit kernel: ata4: EH complete
Apr 23 14:45:40 stdsrv-x86-64bit kernel: ata4.00: exception Emask 0x0 SAct 0x1 
SErr 0x0 action 0x0
Apr 23 14:45:49 stdsrv-x86-64bit kernel: ata4.00: (irq_stat 0x4008)
Apr 23 14:45:49 stdsrv-x86-64bit kernel: ata4.00: cmd 
60/80:00:14:16:c4/00:00:05:00:00/40 tag 0 cdb 0x0 data 65536 in
Apr 23 14:45:49 stdsrv-x86-64bit kernel:  res 
51/40:00:40:16:c4/6f:00:05:00:00/40 Emask 0x9 (media error)
Apr 23 14:45:49 stdsrv-x86-64bit kernel: ata4.00: configured for UDMA/133
Apr 23 14:45:50 stdsrv-x86-64bit kernel: ata4: EH complete
Apr 23 14:45:50 stdsrv-x86-64bit kernel: ata4.00: exception Emask 0x0 SAct 0x1 
SErr 0x0 action 0x0
Apr 23 14:45:50 stdsrv-x86-64bit kernel: ata4.00: (irq_stat 0x4008)
Apr 23 14:45:50 stdsrv-x86-64bit kernel: ata4.00: cmd 
60/80:00:14:16:c4/00:00:05:00:00/40 tag 0 cdb 0x0 data 65536 in
Apr 23 14:45:51 stdsrv-x86-64bit kernel:  res 
51/40:00:40:16:c4/6f:00:05:00:00/40 Emask 0x9 (media error)
Apr 23 14:45:51 stdsrv-x86-64bit kernel: ata4.00: configured for UDMA/133
Apr 23 14:45:51 stdsrv-x86-64bit kernel: ata4: EH complete
Apr 23 14:45:51 stdsrv-x86-64bit kernel: ata4.00: exception Emask 0x0 SAct 0x1 
SErr 0x0 action 0x0
Apr 23 14:45:52 stdsrv-x86-64bit kernel: ata4.00: (irq_stat 0x4008)
Apr 23 14:45:52 stdsrv-x86-64bit kernel: ata4.00: cmd 
60/80:00:14:16:c4/00:00:05:00:00/40 tag 0 cdb 0x0 data 65536 in
Apr 23 14:45:52 stdsrv-x86-64bit kernel:  res 
51/40:00:40:16:c4/6f:00:05:00:00/40 Emask 0x9 (media error)
Apr 23 14:45:52 stdsrv-x86-64bit kernel: ata4.00: configured for UDMA/133
Apr 23 14:45:52 stdsrv-x86-64bit kernel: ata4: EH complete
Apr 23 14:45:52 stdsrv-x86-64bit kernel: ata4.00: exception Emask 0x0 SAct 0x1 
SErr 0x0 action 0x0
Apr 23 14:45:53 stdsrv-x86-64bit kernel: ata4.00: (irq_stat 0x4008)
Apr 23 14:45:53 stdsrv-x86-64bit kernel: ata4.00: cmd 
60/80:00:14:16:c4/00:00:05:00:00/40 tag 0 cdb 0x0 data 65536 in
Apr 23 14:45:53 stdsrv-x86-64bit kernel:  res 
51/40:00:40:16:c4/6f:00:05:00:00/40 Emask 0x9 (media error)
Apr 23 14:45:54 stdsrv-x86-64bit kernel: ata4.00: configured for UDMA/133
Apr 23 14:45:54 stdsrv-x86-64bit kernel: ata4: EH complete
Apr 23 14:45:54 stdsrv-x86-64bit kernel: SCSI device sdd: 976773168 512-byte 
hdwr sectors (500108 MB)
Apr 23 14:45:54 stdsrv-x86-64bit kernel: sdd: Write Protect is off
Apr 23 14:45:54 stdsrv-x86-64bit kernel: SCSI device sdd: write cache: enabled, 
read cache: enabled, doesn't support DPO or FUA
Apr 23 14:45:54 stdsrv-x86-64bit kernel: SCSI device sdd: 976773168 512-byte 
hdwr sectors (500108 MB)
Apr 23 14:45:55 stdsrv-x86-64bit kernel: sdd: Write Protect is off
Apr 23 14:45:55 stdsrv-x86-64bit kernel: SCSI device sdd: write cache: enabled, 
read cache: enabled, doesn't support DPO or FUA
-
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] kthread: Spontaneous exit support

[Eric W. Biederman]

This patch implements the kthread helper functions kthread_start
and kthread_end which make it simple to support a kernel thread
that may decided to exit on it's own before we request it to.
It is still assumed that eventually we will get around to requesting
that the kernel thread stop.

Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
---
 include/linux/kthread.h |   23 +++
 kernel/kthread.c|   18 ++
 2 files changed, 41 insertions(+), 0 deletions(-)

diff --git a/include/linux/kthread.h b/include/linux/kthread.h
index a8ea31d..4f1eff1 100644
--- a/include/linux/kthread.h
+++ b/include/linux/kthread.h
@@ -28,6 +28,29 @@ struct task_struct *kthread_create(int (*threadfn)(void 
*data),
 
 void kthread_bind(struct task_struct *k, unsigned int cpu);
 int kthread_stop(struct task_struct *k);
+/**
+ * kthread_start - create and wake a thread.
+ * @threadfn: the function to run until kthread_should_stop().
+ * @data: data ptr for @threadfn.
+ * @namefmt: printf-style name for the thread.
+ *
+ * Description: Convenient wrapper for kthread_create() followed by
+ * get_task_struct() and wake_up_process. kthread_start should be paired
+ * with kthread_end() so we don't leak task structs.
+ *
+ * Returns the kthread or ERR_PTR(-ENOMEM).
+ */
+#define kthread_start(threadfn, data, namefmt, ...)   \
+({\
+   struct task_struct *__k\
+   = kthread_create(threadfn, data, namefmt, ## __VA_ARGS__); \
+   if (!IS_ERR(__k)) {\
+   get_task_struct(__k);  \
+   wake_up_process(__k);  \
+   }  \
+   __k;   \
+})
+int kthread_end(struct task_struct *k);
 
 static inline int __kthread_should_stop(struct task_struct *tsk)
 {
diff --git a/kernel/kthread.c b/kernel/kthread.c
index 9b3c19f..d6d63c6 100644
--- a/kernel/kthread.c
+++ b/kernel/kthread.c
@@ -179,6 +179,24 @@ int kthread_stop(struct task_struct *tsk)
 }
 EXPORT_SYMBOL(kthread_stop);
 
+/**
+ * kthread_end - signal a kthread and wait for it to exit.
+ * @task: The kthread to end.
+ *
+ * Description: Convenient wrapper for kthread_stop() followed by
+ * put_task_struct().  Returns the kthread exit code.
+ *
+ * kthread_start()/kthread_end() can handle kthread that spontaneously exit
+ * before the kthread is requested to terminate.
+ */
+int kthread_end(struct task_struct *task)
+{
+   int ret;
+   ret = kthread_stop(task);
+   put_task_struct(task);
+   return ret;
+}
+EXPORT_SYMBOL(kthread_end);
 
 static __init void kthreadd_setup(void)
 {
-- 
1.5.0.g53756

-
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] CFS scheduler, -v5

[Ingo Molnar]

* Gene Heskett <[EMAIL PROTECTED]> wrote:

> I haven't approached that yet, but I just noticed, having been booted 
> to this for all of 5 minutes, that although I told it not to renice x 
> when my script ran 'make oldconfig', and I answered n, but there it 
> is, sitting at -19 according to htop.
> 
> The .config says otherwise:
> [EMAIL PROTECTED] linux-2.6.21-rc7-CFS-v5]# grep RENICE .config
> # CONFIG_RENICE_X is not set
> 
> So v5 reniced X in spite of the 'no' setting.

Hmm, apparently your X uses ioperm() while mine uses iopl(), and i only 
turned off the renicing for iopl. (I fixed this in my tree and it will 
show up in -v6.)

> Although I hadn't noticed it, one way or the other, I just set it (X) 
> back to the default -1 so that I'm comparing the same apples when I do 
> compare.

note that CFS handles negative nice levels differently from other 
schedulers, so the disadvantages of agressively reniced X (lost 
throughput due to overscheduling, worse interactivity) do _not_ apply to 
CFS.

I think the 'fair' setting would be whatever the scheduler writer 
recommends: for SD, X probably performs better at around nice 0 (i'll 
let Con correct me if his experience is different). On CFS, nice -10 is 
perfectly fine too, and you'll have a zippier desktop under higher 
loads. (on servers this might be unnecessary/disadvantegous so there 
this can be turned off.)

(also, in my tree i've changed the default from -19 to -10 to make it 
less scary to people and to leave more levels to the sysadmin, this 
change too will show up in -v6.)

Ingo
-
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] CFS scheduler, -v5

[Ingo Molnar]

* Nick Piggin <[EMAIL PROTECTED]> wrote:

> > the biggest user-visible change in -v5 are various interactivity 
> > improvements (especially under higher load) to fix reported 
> > regressions, and an improved way of handling nice levels. There's 
> > also a new sys_sched_yield_to() syscall implementation for i686 and 
> > x86_64.
> > 
> > All known regressions have been fixed. (knock on wood)
> 
> I think the granularity is still much too low. Why not increase it to 
> something more reasonable as a default?

note that CFS's "granularity" value is not directly comparable to 
"timeslice length":

> [ Note: while CFS's default preemption granularity is currently set to
>   5 msecs, this value does not directly transform into timeslices: for 
>   example two CPU-intense tasks will have effective timeslices of 10 
>   msecs with this setting. ]

also, i just checked SD: 0.46 defaults to 8 msecs rr_interval (on 1 CPU 
systems), which is lower than the 10 msecs effective timeslice length 
CVS-v5 achieves on two CPU-bound tasks.

(in -v6 i'll scale the granularity up a bit with the number of CPUs, 
like SD does. That should get the right result on larger SMP boxes too.)

while i agree it's a tad too finegrained still, I agree with Con's 
choice: rather err on the side of being too finegrained and lose some 
small amount of throughput on cache-intense workloads like compile jobs, 
than err on the side of being visibly too choppy for users on the 
desktop.

Ingo
-
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] CFS scheduler, -v5

[Gene Heskett]

On Sunday 22 April 2007, Nick Piggin wrote:
>On Mon, Apr 23, 2007 at 03:12:29AM +0200, Ingo Molnar wrote:
>> i'm pleased to announce release -v5 of the CFS scheduler patchset. The
>> patch against v2.6.21-rc7 and v2.6.20.7 can be downloaded from:
>>
>> http://redhat.com/~mingo/cfs-scheduler/
>>
>> this CFS release mainly fixes regressions and improves interactivity:
>>
>> 13 files changed, 211 insertions(+), 199 deletions(-)
>>
>> the biggest user-visible change in -v5 are various interactivity
>> improvements (especially under higher load) to fix reported regressions,
>> and an improved way of handling nice levels. There's also a new
>> sys_sched_yield_to() syscall implementation for i686 and x86_64.
>>
>> All known regressions have been fixed. (knock on wood)
>
>I think the granularity is still much too low. Why not increase it to
>something more reasonable as a default?

I haven't approached that yet, but I just noticed, having been booted to this 
for all of 5 minutes, that although I told it not to renice x when my script 
ran 'make oldconfig', and I answered n, but there it is, sitting at -19 
according to htop.

The .config says otherwise:
[EMAIL PROTECTED] linux-2.6.21-rc7-CFS-v5]# grep RENICE .config
# CONFIG_RENICE_X is not set

So v5 reniced X in spite of the 'no' setting.

Although I hadn't noticed it, one way or the other, I just set it (X) back to 
the default -1 so that I'm comparing the same apples when I do compare.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Fortune finishes the great quotations, #2

If at first you don't succeed, think how many people
you've made happy.

-
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/

[report] renicing X, cfs-v5 vs sd-0.46

[Ingo Molnar]

* Linus Torvalds <[EMAIL PROTECTED]> wrote:

> The X server should not be re-niced. It was done in the past, and it 
> was wrogn then (and caused problems - we had to tell people to undo 
> it, because some distros had started doing it by default).
> 
> If you have a single client, the X server is *not* more important than 
> the client, and indeed, renicing the X server causes bad patterns: 
> just because the client sends a request does not mean that the X 
> server should immediately be given the CPU as being "more important".

You are completely right in the case of traditional schedulers.

Note that this is not the case for CFS though. CFS has natural, built-in 
buffering against high-rate preemptions from lower nice-level 
SCHED_OTHER tasks. So while X will indeed get more CPU time (and that i 
think is fully justified), it wont get nearly as high of a 
context-switch rate as under priority/runqueue-based schedulers.

To demonstrate this i have done the following simple experiment: i 
started 4 xterms on a single-CPU box, then i started the 'yes' utility 
in each xterm and resized all of the xterms to just 2 lines vertical. 
This generates a _lot_ of screen refresh events. Naturally, such a 
workload utilizes the whole CPU.

Using CFS-v5, with Xorg at nice 0, the context-switch rate is low:

procs ---memory-- ---swap-- -io --system-- 
-cpu--
 r  b   swpd   free   buff  cache   si   sobibo   in   cs us sy id wa st
 2  0  0 472132  13712 17860400 032  113  170 83 17  0  0  0
 2  0  0 472172  13712 17860400 0 0  112  184 85 15  0  0  0
 2  0  0 472196  13712 17860400 0 0  108  162 83 17  0  0  0
 1  0  0 472076  13712 17860400 0 0  115  189 86 14  0  0  0

X's CPU utilization is 49%, xterm's go to 12% each. Userspace 
utilization is 85%, system utilization is 15%.

Renicing X to -10 increases context-switching, but not dramatically so, 
because it is throttled by CFS:

procs ---memory-- ---swap-- -io --system-- 
-cpu--
 r  b   swpd   free   buff  cache   si   sobibo   in   cs us sy id wa st
 4  0  0 475752  13492 17632000 064  116 1498 85 15  0  0  0
 4  0  0 475752  13492 17632000 0 0  107 1488 84 16  0  0  0
 4  0  0 475752  13492 17632000 0 0  140 1514 86 14  0  0  0
 4  0  0 475752  13492 17632000 0 0  107 1477 85 15  0  0  0
 4  0  0 475752  13492 17632000 0 0  122 1498 84 16  0  0  0

The system is still usable, Xorg is 44% busy, each xterm is 14% busy. 
User utilization 85%, system utilization is 15% - just like in the first 
case.

"Performance of scrolling" is exactly the same in both cases (i have 
tested this by inserting periodic beeps after every 10,000 lines of text 
scrolled) - but the screen refresh rate is alot more eye-pleasing in the 
nice -10 case. (screen refresh it happens at ~500 Hz, while in the nice 
0 case it happens at ~40 Hz and visibly flickers. This is especially 
noticeable if the xterms have full size.)

I have tested the same workload on vanilla v2.6.21-rc7 and on SD-0.46
too, and they give roughly the same xterm scheduling behavior when Xorg 
is at nice 0:

procs ---memory-- ---swap-- -io --system-- 
-cpu--
 r  b   swpd   free   buff  cache   si   sobibo   in   cs us sy id wa st
 4  0  0 450564  14844 19497600 0 0  287  594 58 10 32  0  0
 4  0  0 450704  14844 19497600 0 0  108  370 89 11  0  0  0
 0  0  0 449588  14844 19497600 0 0  175  434 85 13  2  0  0
 3  0  0 450688  14852 19497600 032  242  315 62  9 29  0  0

but when Xorg is reniced to -10 on the vanilla or SD schedulers, it 
indeed gives the markedly higher context-switching behavior you 
predicted:

procs ---memory-- ---swap-- -io --system-- 
-cpu--
 r  b   swpd   free   buff  cache   si   sobibo   in   cs us sy id wa st
 5  0  0 452272  13936 19489600 0 0  126 14147 78 22  0  0  0
 4  0  0 452252  13944 19489600 064  155 14143 80 20  0  0  0
 5  0  0 452612  13944 19489600 0 0  187 14031 79 21  0  0  0
 4  0  0 452624  13944 19489600 0 0  121 14300 82 18  0  0  0

User time drops to 78%, system time increases to 22%. "Scrolling 
performance" clearly decreases.

so i agree that renicing X can be a very bad idea, but it very much 
depends on the scheduler implementation too.

Ingo
-
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][RFC][POWERPC] i2c: adds support for i2c bus on 8xx

[Olof Johansson]

On Fri, Apr 20, 2007 at 08:27:14AM +0400, Vitaly Bordug wrote:

> diff --git a/arch/powerpc/platforms/8xx/mpc885ads_setup.c 
> b/arch/powerpc/platforms/8xx/mpc885ads_setup.c
> index 9bd81c7..d32e066 100644
> --- a/arch/powerpc/platforms/8xx/mpc885ads_setup.c
> +++ b/arch/powerpc/platforms/8xx/mpc885ads_setup.c
> @@ -51,6 +51,7 @@ static void init_smc1_uart_ioports(struc
>  static void init_smc2_uart_ioports(struct fs_uart_platform_info* fpi);
>  static void init_scc3_ioports(struct fs_platform_info* ptr);
>  static void init_irda_ioports(void);
> +static void init_i2c_ioports(void);
>  
>  void __init mpc885ads_board_setup(void)
>  {
> @@ -120,6 +121,10 @@ #endif
>  #ifdef CONFIG_8XX_SIR
>   init_irda_ioports();
>  #endif
> +
> +#ifdef CONFIG_I2C_RPXLITE
> + init_i2c_ioports();
> +#endif

Does it hurt to always do it, even when the driver is not enabled? THat'd
do away with an ifdef.

Also, if you move the static function up, you don't need a prototype. That
goes for other stuff in this file too.

>  }
>  
>  
> @@ -361,6 +366,15 @@ static void init_irda_ioports()
>   immr_unmap(cp);
>  }
>  
> +static void init_i2c_ioports()
> +{
> + cpm8xx_t *cp = (cpm8xx_t *)immr_map(im_cpm);
> +
> +setbits32(>cp_pbpar, 0x0030);
> +setbits32(>cp_pbdir, 0x0030);
> +setbits16(>cp_pbodr, 0x0030);
> +}

Looks like you moved this out of the driver and into the platform
code. What happens to other platforms where it's used?

> +
>  int platform_device_skip(const char *model, int id)
>  {
>  #ifdef CONFIG_MPC8xx_SECOND_ETH_SCC3
> diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
> index 419b688..7ecd537 100644
> --- a/arch/powerpc/sysdev/fsl_soc.c
> +++ b/arch/powerpc/sysdev/fsl_soc.c
> @@ -331,7 +331,7 @@ static int __init fsl_i2c_of_init(void)
>   for (np = NULL, i = 0;
>(np = of_find_compatible_node(np, "i2c", "fsl-i2c")) != NULL;
>i++) {
> - struct resource r[2];
> + struct resource r[3];

Why? No code that uses it has been changed. Is it a bugfix?

>   struct fsl_i2c_platform_data i2c_data;
>   const unsigned char *flags = NULL;
>  
> @@ -1215,4 +1215,63 @@ err:
>  
>  arch_initcall(fs_irda_of_init);
>  
> +static const char *i2c_regs = "regs";
> +static const char *i2c_pram = "pram";
> +static const char *i2c_irq = "interrupt";
> +
> +static int __init fsl_i2c_cpm_of_init(void)
> +{
> + struct device_node *np;
> + unsigned int i;
> + struct platform_device *i2c_dev;
> + int ret;
> +
> + for (np = NULL, i = 0;
> +  (np = of_find_compatible_node(np, "i2c", "fsl-i2c-cpm")) != NULL;
> +  i++) {
> + struct resource r[3];
> + struct fsl_i2c_platform_data i2c_data;
> +
> + memset(, 0, sizeof(r));
> + memset(_data, 0, sizeof(i2c_data));
> +
> + ret = of_address_to_resource(np, 0, [0]);
> + if (ret)
> + goto err;
> + r[0].name = i2c_regs;
> +
> + ret = of_address_to_resource(np, 1, [1]);
> + if (ret)
> + goto err;
> + r[1].name = i2c_pram;
> +
> + r[2].start = r[2].end = irq_of_parse_and_map(np, 0);
> + r[2].flags = IORESOURCE_IRQ;
> + r[2].name = i2c_irq;
> +
> + i2c_dev = platform_device_register_simple("fsl-i2c-cpm", i, 
> [0], 3);
> + if (IS_ERR(i2c_dev)) {
> + ret = PTR_ERR(i2c_dev);
> + goto err;
> + }
> +
> + ret =
> + platform_device_add_data(i2c_dev, _data,
> +  sizeof(struct
> + fsl_i2c_platform_data));
> + if (ret)
> + goto unreg;
> + }
> +
> + return 0;
> +
> +unreg:
> + platform_device_unregister(i2c_dev);
> +err:
> + return ret;
> +}
> +
> +arch_initcall(fsl_i2c_cpm_of_init);

This could all be done with an of_platform driver instead, and avoid the above.
(Someone else already suggested that I believe).

>  #endif /* CONFIG_8xx */
> diff --git a/drivers/i2c/algos/Kconfig b/drivers/i2c/algos/Kconfig
> index 5889907..7d7fb87 100644
> --- a/drivers/i2c/algos/Kconfig
> +++ b/drivers/i2c/algos/Kconfig
> @@ -37,6 +37,8 @@ config I2C_ALGOPCA
>  config I2C_ALGO8XX
>   tristate "MPC8xx CPM I2C interface"
>   depends on 8xx
> + help
> +   8xx I2C Algorithm
>  
>  config I2C_ALGO_SGI
>   tristate "I2C SGI interfaces"
> diff --git a/drivers/i2c/algos/Makefile b/drivers/i2c/algos/Makefile
> index cac1051..1bd3b37 100644
> --- a/drivers/i2c/algos/Makefile
> +++ b/drivers/i2c/algos/Makefile
> @@ -6,6 +6,7 @@ obj-$(CONFIG_I2C_ALGOBIT) += i2c-algo-bi
>  obj-$(CONFIG_I2C_ALGOPCF)+= i2c-algo-pcf.o
>  obj-$(CONFIG_I2C_ALGOPCA)+= i2c-algo-pca.o
>  obj-$(CONFIG_I2C_ALGO_SGI)   += i2c-algo-sgi.o
> 

Re: Question about Reiser4

[Lee Revell]

On 4/22/07, Eric Hopper <[EMAIL PROTECTED]> wrote:

I'm not an LKML subscriber.



Did you try searching LKML archives?

Lee
-
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: Wrong free clusters count on FAT32

[OGAWA Hirofumi]

DervishD <[EMAIL PROTECTED]> writes:

>> It would add the limitation to following simple usage,
>> 
>>  # mount -t vfat /dev/sda1 /mnt
>> # cp -a * /mnt
>> # umount
>> 
>> if /dev/sda1 was the large and slow device, "mount" will need several
>> minutes to counts free clusters. I think the user will be hard to
>> accept the several minutes at "mount".
>
> I can carry some tests, but if Windows does that tasks lightning
> fast, Linux surely does it faster ;) I don't think, anyway, that having
> a huge USB disk is a common practice when using "modest" machines.
>
> If you want, I can perform a couple of tests. I have a 80GB disk
> that I can connect using an USB adapter and my machine is AMD Athlon XP
> 1900+ with 1GB of RAM, which looks pretty slow nowadays O:)

Yes, I think it's not common practice too. But I don't see why do you
want to scanning at the mount.

Thanks.
-- 
OGAWA Hirofumi <[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/

Question about Reiser4

[Eric Hopper]

I know that this whole effort has been put in disarray by the
prosecution of Hans Reiser, but I'm curious as to its status.  Is
Reiser4 going to be going into the Linus kernel anytime soon?  Is there
somewhere I should be looking to find this out without wasting bandwidth
here?

I'm not an LKML subscriber.

Thanks,
-- 
Eric Hopper (http://www.omnifarious.org/~hopper/)


pgpwR2Oqc0PDz.pgp
Description: PGP signature

Re: Wrong free clusters count on FAT32

[OGAWA Hirofumi]

Bodo Eggert <[EMAIL PROTECTED]> writes:

>> > - usefree is a bad name (I'd suggest recalc_free instead),
>> 
>> Is it about nofree option?
>
> Yes. I think recalc_free is way more descriptive.

Recalc is already default on current patch.
-- 
OGAWA Hirofumi <[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/

Fwd: [ck] [ANNOUNCE] Staircase Deadline cpu scheduler version 0.46

[hechacker1]

From: hechacker1 <[EMAIL PROTECTED]>
Date: Apr 22, 2007 6:09 PM
Subject: Re: [ck] [ANNOUNCE] Staircase Deadline cpu scheduler version 0.46
To: Con Kolivas <[EMAIL PROTECTED]>

First of all, thank you for your continued development of SD. I've
been using RSDL v.30 since it came out with skunk-sources (a gentoo
patchset). It has ran stable since that time.

I went ahead and taught myself how to patch a kernel together so I
could try  SD-0.46.

[EMAIL PROTECTED] ~ $ uname -a
Linux 700m 2.6.21-rc7-sd046-rsdl #2 PREEMPT Sun Apr 22 15:13:36 PDT
2007 i686 Intel(R) Pentium(R) M processor 1.70GHz GenuineIntel
GNU/Linux

My findings:
SD 0.46 is much more responsive than RSDL  0.30. I have portage niced
to 19, make -j2, and it doesn't interfere with Xorg/Beryl at all.
Animations are silky smooth in beryl compared to the standard 2.6.21
scheduler which lags/becomes jerky when there is any kind of load (and
nicing it didn't help). This is especially important since I use
resier4 with cryptcompress (lzo) and it does peg out my CPU at 100%
during portage database rebuilds and searches. Not to mention all the
untaring/unzipping that portage does to build from source (and i have
everything built in tmpfs, so there isn't an i/o limitation).

I have rr_interval at 6 ms.

Xorg is "slightly" more responsive (doesn't lag) under load with nice
-10, although I also have beryl and emerald to worry about too since
they draw the windows and consume cpu. Xorg with nice 0 is still
responsive under all loads, so at least the tweak isn't required.

So far this is my new favorite scheduler. I'm compiling openoffice in
the background right now and I can't even notice it.

I will spend some time with this scheduler to get a feel for its
performance and later try CFS to get a comparison.



On 4/22/07, Con Kolivas <[EMAIL PROTECTED] > wrote:

 Yet another significant bugfix for SMP balancing was just posted for the
staircase deadline cpu scheduler which improves behaviour dramatically on any
SMP machine.

Thanks to Willy Tarreau for noticing more bugs.

As requested was a version in the Makefile so this version of the patch
adds -sd046 to the kernel version.

 http://ck.kolivas.org/patches/staircase-deadline/2.6.21-rc7-sd-0.46.patch
http://ck.kolivas.org/patches/staircase-deadline/2.6.20.7-sd-0.46.patch

Renicing X to -10, while not essential, may be desirable on the desktop.
Unlike the CFS scheduler which renices X without your intervention to
nice -19, the SD patches do not alter nice level on their own.

See the patch just posted called 'sched: implement staircase deadline
 scheduler load  weight fix' for details of the fixes.

Thanks to all testing and giving feedback.

Well I'm exhausted...

--
-ck
___
  http://ck.kolivas.org/faqs/replying-to-mailing-list.txt
ck mailing list - mailto: [EMAIL PROTECTED]
 http://vds.kolivas.org/mailman/listinfo/ck


-
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: [REPORT] cfs-v4 vs sd-0.44

[Nick Piggin]

On Sun, Apr 22, 2007 at 04:24:47PM -0700, Linus Torvalds wrote:
> 
> 
> On Sun, 22 Apr 2007, Juliusz Chroboczek wrote:
> > 
> > Why not do it in the X server itself?  This will avoid controversial
> > policy in the kernel, and have the added advantage of working with
> > X servers that don't directly access hardware.
> 
> It's wrong *wherever* you do it.
> 
> The X server should not be re-niced. It was done in the past, and it was 
> wrogn then (and caused problems - we had to tell people to undo it, 
> because some distros had started doing it by default).

The 2.6 scheduler can get very bad latency problems with the X server
reniced.


> If you have a single client, the X server is *not* more important than the 
> client, and indeed, renicing the X server causes bad patterns: just 
> because the client sends a request does not mean that the X server should 
> immediately be given the CPU as being "more important". 

If the client is doing some processing, and the user moves the mouse, it
feels much more interactive if the pointer moves rather than waits for
the client to finish processing.
-
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] CFS scheduler, -v5

[Nick Piggin]

On Mon, Apr 23, 2007 at 03:12:29AM +0200, Ingo Molnar wrote:
> 
> i'm pleased to announce release -v5 of the CFS scheduler patchset. The 
> patch against v2.6.21-rc7 and v2.6.20.7 can be downloaded from:
> 
> http://redhat.com/~mingo/cfs-scheduler/
> 
> this CFS release mainly fixes regressions and improves interactivity:
> 
> 13 files changed, 211 insertions(+), 199 deletions(-)
> 
> the biggest user-visible change in -v5 are various interactivity 
> improvements (especially under higher load) to fix reported regressions, 
> and an improved way of handling nice levels. There's also a new 
> sys_sched_yield_to() syscall implementation for i686 and x86_64.
> 
> All known regressions have been fixed. (knock on wood)

I think the granularity is still much too low. Why not increase it to
something more reasonable as a default?

-
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] CFS scheduler, -v5

[Ingo Molnar]

i'm pleased to announce release -v5 of the CFS scheduler patchset. The 
patch against v2.6.21-rc7 and v2.6.20.7 can be downloaded from:

http://redhat.com/~mingo/cfs-scheduler/

this CFS release mainly fixes regressions and improves interactivity:

13 files changed, 211 insertions(+), 199 deletions(-)

the biggest user-visible change in -v5 are various interactivity 
improvements (especially under higher load) to fix reported regressions, 
and an improved way of handling nice levels. There's also a new 
sys_sched_yield_to() syscall implementation for i686 and x86_64.

All known regressions have been fixed. (knock on wood)

[ Note: while CFS's default preemption granularity is currently set to 5 
  msecs, this value does not directly transform into timeslices: for 
  example two CPU-intense tasks will have effective timeslices of 10 
  msecs with this setting. ]

Changes since -v4:

 - interactivity bugfix: fix xterm latencies and general desktop delays 
   and child task startup delays under load. (reported by Willy Tarreau 
   and Caglar Onur)

 - bugfix: the in_atomic_preempt_off() call on !PREEMPT_BKL was buggy
   and spammed the console with bogus warnings.

 - implementation fix: make the nice levels implementation
   starvation-free and smpnice-friendly. Remove the nice_offset hack.

 - feature: add initial sys_sched_yield_to() implementation. Not hooked 
   into the futex code yet, but testers are encouraged to give the 
   syscalls a try, on i686 the new syscall is __NR_yield_to==320, on 
   x86_64 it's __NR_yield_to==280. The prototype is 
   sys_sched_yield_to(pid_t), as suggested by Ulrich Drepper.

 - usability feature: add CONFIG_RENICE_X: those who dont want the 
   kernel to renice X should disable this option. (the boot option and 
   the sysctl is still available too)

 - removed my home-made "Con was right about scheduling fairness" 
   attribution to Con's scheduler interactivity work - some have 
   suggested that Con might want to see another text there. Con,
   please feel free to fill it in!

 - feature: make the CPU usage of nice levels logarithmic instead of 
   linear. This is more usable and more intuitive. (Going four nice 
   levels forward/backwards give half/twice the CPU power) [ This was
   requested a number of times in the past few years and is 
   straightforward under CFS because there nice levels are not tied to 
   any timeslice distribution mechanism. ]

 - cleanup: removed the stupid "Ingo was here" banner printk from 
   sched_init(), the -cfs EXTRAVERSION serves the purpose (of 
   identifying a booted up kernel as a CFS one) equally well.

 - various other code cleanups

As usual, any sort of feedback, bugreport, fix and suggestion is more 
than welcome,

Ingo
-
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] lazy freeing of memory through MADV_FREE

[Nick Piggin]

Rik van Riel wrote:

Nick Piggin wrote:


Rik van Riel wrote:



Here are the transactions/seconds for each combination:

   vanilla   new glibc  madv_free kernel   madv_free + mmap_sem
threads

1 610 609 596545
2103211361196   1200
4107011282014   2024
8100010881665   2087
1677910731310   1999




Is "new glibc" meaning MADV_DONTNEED + kernel with mmap_sem patch?



No, that's just the glibc change, with a vanilla kernel.


OK. That would be interesting to see with the mmap_sem change,
because that should increase scalability.



The third column is glibc change + mmap_sem patch.

The fourth column has your patch in it, too.


The strange thing with your madv_free kernel is that it doesn't
help single-threaded performance at all. So that work to avoid
zeroing the new page is not a win at all there (maybe due to the
cache effects I was worried about?).



Well, your patch causes the performance to drop from
596 transactions/second to 545.  Your patch is the only
difference between the third and the fourth column.


Yeah. That's funny, because it means either there is some
contention on the mmap_sem (or ptl) at 1 thread, or that my
patch alters the uncontended performance.



However MADV_FREE does improve scalability, which is interesting.
The most likely reason I can see why that may be the case is that
it avoids mmap_sem when faulting pages back in (I doubt it is due
to avoiding the page allocator, but maybe?).

So where is the down_write coming from in this workload, I wonder?
Heap management? What syscalls?



I wonder if the increased parallelism simply caused
more cache line bouncing, with bounces happening in
some inner loop instead of an outer loop.

Btw, it is quite possible that the MySQL sysbench
thing gives different results on your system.  It
would be good to know what it does on a real SMP
system, vs. a single quad-core chip :)

Other architectures would be interesting to know,
too.


I don't see why parallelism should come into it at 1 thread, unless
MySQL is parallelising individual transactions. Anyway, I'll try to do
some more digging.

--
SUSE Labs, Novell Inc.
-
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: [REPORT] cfs-v4 vs sd-0.44

[Rusty Russell]

On Sun, 2007-04-22 at 09:16 -0700, Ulrich Drepper wrote:
> On 4/22/07, William Lee Irwin III <[EMAIL PROTECTED]> wrote:
> > On Sun, Apr 22, 2007 at 12:17:31AM -0700, Ulrich Drepper wrote:
> > > For futex(), the extension is needed for the FUTEX_WAIT operation.  We
> > > need a new operation FUTEX_WAIT_FOR or so which takes another (the
> > > fourth) parameter which is the PID of the target.
> > > For FUTEX_LOCK_PI we need no extension.  The futex value is the PID of
> > > the current owner.  This is required for the whole interface to work
> > > in the first place.
> >
> > We'll have to send things out and see what sticks here. There seems to
> > be some pickiness above.
> 
> I know Rusty will shudder since it makes futexes yet more complicated
> (although only if the user wants it) but if you introduce the concept
> of "yield to" then this extension makes really sense and it is a quite
> simple extension.  Plus: I'm the most affected by the change since I
> have to change code to use it and I'm fine with it.

Hi Uli,

I wouldn't worry: futexes long ago jumped the shark.

I think it was inevitable that once we started endorsing programs
bypassing the kernel for IPC that we'd want some form of yield_to().
And yield_to(p) has much more sane semantics than yield().

Cheers,
Rusty.


-
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] use spinlock instead of binary mutex in idt77252 driver

[Satyam Sharma]

On 4/23/07, Matthias Kaehlcke <[EMAIL PROTECTED]> wrote:

use spinlock instead of binary mutex in idt77252 driver

Signed-off-by: Matthias Kaehlcke <[EMAIL PROTECTED]>

--

diff --git a/drivers/atm/idt77252.c b/drivers/atm/idt77252.c
index b4b8014..e3cf141 100644
--- a/drivers/atm/idt77252.c
+++ b/drivers/atm/idt77252.c
@@ -2430,7 +2430,7 @@ idt77252_open(struct atm_vcc *vcc)

set_bit(ATM_VF_ADDR, >flags);

-   down(>mutex);
+   mutex_lock(>mutex);


Note that you're actually replacing a semaphore with a mutex here (and
not a mutex with a spinlock). I guess that should be fine and
desirable as long as the semaphore was indeed being used a mutex
(binary) in this code.
-
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] use spinlock instead of binary mutex in idt77252 driver

[Kyle Moffett]

On Apr 22, 2007, at 17:39:59, Matthias Kaehlcke wrote:

use spinlock instead of binary mutex in idt77252 driver


I think you really meant: "Use mutex instead of binary semaphore in  
idt77252 driver", since this is a binary semaphore (not a mutex,  
which are always binary):

-   struct semaphoremutex;


and this is a mutex, not a spinlock:

+   struct mutexmutex;


Everything else looks good though

Cheers,
Kyle Moffett
-
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: [BUG? -rc7] SMP: Just one CPU activated: P4 3GHz HT

[Robert Hancock]

Miguel Ojeda wrote:

Hi all,

I have a ASUS P4P800 Deluxe, P4 3GHz HT, 1GB RAM and testing -rc7 I
noticed I just got 1 CPU.

I checked my .config but I do not see anything bad. Also I read
Documentation/smp.txt. Just for being sure this is not a bug, I'm
posting it.

Here you have .config and dmesg.


You didn't enable ACPI, it's needed for almost all systems to detect HT 
and also for many systems to detect multi-cores as well.


Aside from that, in general I would say that on any modern x86 system 
ACPI should always be enabled. In many cases it seems the BIOS code is 
not tested much without ACPI anymore, so going without ACPI can be 
problematic.


--
Robert Hancock  Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/

-
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/

More reiserfs trouble in 2.6.21-rc5

[Andi Kleen]

FYI,

This was a debugging kernel (preempt, slab debugging, lockdep etc. enabled)
running autotest and some other load on a 4 core Opteron system

There was also another lockdep warning before that which I'm sending
separately.

Looks like some memory corruption. Could be something else, but at least
reiserfs is the messenger.

BTW these kind of backtraces are a good example on why I want the dwarf2
unwinder back.

-Andi

[ cut here ]
kernel BUG at /mnt/dm-2/newautoboot/autoboot/lsrc/mainline/linux/mm/slab.c:2380!
invalid opcode:  [1] PREEMPT SMP
CPU 0
Modules linked in:
Pid: 12205, comm: find Not tainted 2.6.21-rc5-git6 #44
RIP: 0010:[]  [] 
cache_alloc_refill+0xe6/0x22a
RSP: 0018:810078be7a28  EFLAGS: 00010002
RAX: 0001 RBX: 0001 RCX: 8027b826
RDX: 0003 RSI: 81017d077000 RDI: 8100f7f7c540
RBP: 81017d077000 R08: 8100f7f7ec78 R09: 8101fa6cf178
R10: 810100116070 R11:  R12: 810100116070
R13: 8100f7f7ec78 R14: 8100f7f7c540 R15: 000c
FS:  2acc1ce646d0() GS:8074a000() knlGS:5b3f2b90
CS:  0010 DS:  ES:  CR0: 8005003b
CR2: 43d45000 CR3: 88a9b000 CR4: 06e0
Process find (pid: 12205, threadinfo 810078be6000, task 81002a76d0c0)
Stack:  000100d0 8101002b6248 8100f7f7c540 0246
 00d0 802ce4cb 802c7590 8027bda3
 8101002b6248  8100070a9988 8101002b6248
Call Trace:
 [] reiserfs_alloc_inode+0x15/0x2a
 [] reiserfs_find_actor+0x0/0x1b
 [] kmem_cache_alloc+0x8c/0xe2
 [] reiserfs_alloc_inode+0x15/0x2a
 [] alloc_inode+0x12/0x13f
 [] iget5_locked+0x5a/0x18a
 [] reiserfs_init_locked_inode+0x0/0x12
 [] reiserfs_iget+0x30/0x92
 [] pathrelse+0x24/0x3c
 [] reiserfs_lookup+0xcf/0x138
 [] _read_trylock+0x47/0x6b
 [] d_alloc+0x1c4/0x1d0
 [] do_lookup+0xc4/0x1ae
 [] __link_path_walk+0x885/0xd2b
 [] link_path_walk+0x58/0xe0
 [] do_path_lookup+0x1be/0x1e2
 [] getname+0x152/0x196
 [] __user_walk_fd+0x37/0x53
 [] vfs_lstat_fd+0x18/0x47
 [] sys_newlstat+0x19/0x31
 [] trace_hardirqs_on_thunk+0x35/0x37
 [] _atomic_dec_and_lock+0x39/0x58
 [] system_call+0x7e/0x83


Code: 0f 0b eb fe 49 8b 86 70 03 00 00 49 ff 86 78 03 00 00 48 ff
RIP  [] cache_alloc_refill+0xe6/0x22a
 RSP 
note: find[12205] exited with preempt_count 1
BUG: scheduling while atomic: find/0x1001/12205
INFO: lockdep is turned off.
UG: scheduling while atomic: find/0x1001/12205
INFO: lockdep is turned off.

Call Trace:
 [] __sched_text_start+0x81/0x80b
 [] vt_console_print+0x21f/0x235
 [] _spin_unlock_irqrestore+0x49/0x69
 [] __cond_resched+0x13/0x32
 [] cond_resched+0x2e/0x39
 [] unmap_vmas+0x5e5/0x778
 [] exit_mmap+0x80/0x117
 [] mmput+0x2c/0x9e
 [] do_exit+0x21a/0x82e
 [] _spin_unlock_irqrestore+0x49/0x69
 [] kernel_math_error+0x0/0x90
 [] do_invalid_op+0xb2/0xbc
 [] cache_alloc_refill+0xe6/0x22a
 [] trace_hardirqs_on_thunk+0x35/0x37
 [] restore_args+0x0/0x30
 [] error_exit+0x0/0x96
 [] cache_alloc_refill+0x6f/0x22a
 [] cache_alloc_refill+0xe6/0x22a
 [] cache_alloc_refill+0xcd/0x22a
 [] reiserfs_alloc_inode+0x15/0x2a
 [] reiserfs_find_actor+0x0/0x1b
 [] kmem_cache_alloc+0x8c/0xe2
 [] reiserfs_alloc_inode+0x15/0x2a
 [] alloc_inode+0x12/0x13f
 [] iget5_locked+0x5a/0x18a
 [] reiserfs_init_locked_inode+0x0/0x12
 [] reiserfs_iget+0x30/0x92
 [] pathrelse+0x24/0x3c
 [] reiserfs_lookup+0xcf/0x138
 [] _read_trylock+0x47/0x6b
 [] d_alloc+0x1c4/0x1d0
 [] do_lookup+0xc4/0x1ae
 [] __link_path_walk+0x885/0xd2b
 [] link_path_walk+0x58/0xe0
 [] do_path_lookup+0x1be/0x1e2
 [] getname+0x152/0x196
 [] __user_walk_fd+0x37/0x53
 [] vfs_lstat_fd+0x18/0x47
 [] sys_newlstat+0x19/0x31
 [] trace_hardirqs_on_thunk+0x35/0x37
 [] _atomic_dec_and_lock+0x39/0x58
 [] system_call+0x7e/0x83

BUG: scheduling while atomic: find/0x1001/12205
INFO: lockdep is turned off.

[... more similar messages ...]
-
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] Add missing USRobotics Wireless Adapter (Model 5423) id into zd1211rw

[Daniel Drake]

S.Çağlar Onur wrote:
USRobotics Wireless Adapter (Model 5423) works well with current zd1211rw 
driver also (i have tested 2.6.18, 2.6.20 and 2.6.21-rc7). I know -mm/and 
Daniel's tree has new version (i think with more features like rate estimator 
etc.) of this driver but maybe you should consider that one as a .21 material 
instead of waiting full wireless-dev merge? 


This ID addition is already on the way up the chain. It will be 
supported in 2.6.22.


Thanks,
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/

reiserfs lockdep warning in 2.6.21-rc5

[Andi Kleen]

===
[ INFO: possible circular locking dependency detected ]
2.6.21-rc5-git6 #44
---
perl/7968 is trying to acquire lock:
 (>i_mutex){--..}, at: [] 
reiserfs_file_release+0x109/0x2cc

but task is already holding lock:
 (>mmap_sem){}, at: [] sys_munmap+0x32/0x5a

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #1 (>mmap_sem){}:
   [] __lock_acquire+0x9e0/0xb79
   [] lock_acquire+0x48/0x63
   [] do_page_fault+0x3a4/0x7b2
   [] down_read_trylock+0xe/0x3b
   [] down_read+0x21/0x2a
   [] do_page_fault+0x3a4/0x7b2
   [] trace_hardirqs_on+0x11c/0x140
   [] _read_unlock_irq+0x2f/0x4a
   [] find_lock_page+0x91/0x9d
   [] find_or_create_page+0x1e/0x75
   [] error_exit+0x0/0x96
   [] reiserfs_release_claimed_blocks+0x22/0x49
   [] reiserfs_copy_from_user_to_file_region+0x7e/0xf3
   [] reiserfs_file_write+0x15a1/0x1795
   [] _spin_unlock_irqrestore+0x49/0x69
   [] trace_hardirqs_on_thunk+0x35/0x37
   [] _spin_unlock_irq+0x24/0x4a
   [] trace_hardirqs_on+0x11c/0x140
   [] _spin_unlock_irq+0x2f/0x4a
   [] thread_return+0xee/0x135
   [] _read_unlock_irq+0x24/0x4a
   [] trace_hardirqs_on+0x11c/0x140
   [] _read_unlock_irq+0x2f/0x4a
   [] find_get_pages_tag+0x75/0x80
   [] vfs_write+0xad/0x136
   [] sys_pwrite64+0x50/0x70
   [] ia32_sysret+0x0/0xa
   [] 0x

-> #0 (>i_mutex){--..}:
   [] print_circular_bug_header+0xcc/0xd3
   [] __lock_acquire+0x8dc/0xb79
   [] lock_acquire+0x48/0x63
   [] reiserfs_file_release+0x109/0x2cc
   [] debug_mutex_lock_common+0x16/0x23
   [] __mutex_lock_slowpath+0xe1/0x293
   [] reiserfs_file_release+0x109/0x2cc
   [] __fput+0xa1/0x15e
   [] remove_vma+0x35/0x5c
   [] do_munmap+0x258/0x27a
   [] __down_write_nested+0x34/0x9e
   [] sys_munmap+0x40/0x5a
   [] system_call+0x7e/0x83
   [] 0x

other info that might help us debug this:

1 lock held by perl/7968:
 #0:  (>mmap_sem){}, at: [] sys_munmap+0x32/0x5a

stack backtrace:
Call Trace:
 [] print_circular_bug_tail+0x69/0x72
 [] print_circular_bug_header+0xcc/0xd3
 [] __lock_acquire+0x8dc/0xb79
 [] lock_acquire+0x48/0x63
 [] reiserfs_file_release+0x109/0x2cc
 [] debug_mutex_lock_common+0x16/0x23
 [] __mutex_lock_slowpath+0xe1/0x293
 [] reiserfs_file_release+0x109/0x2cc
 [] __fput+0xa1/0x15e
 [] remove_vma+0x35/0x5c
 [] do_munmap+0x258/0x27a
 [] __down_write_nested+0x34/0x9e
 [] sys_munmap+0x40/0x5a
 [] system_call+0x7e/0x83
-
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: Bitbanging i2c bus driver using the GPIO API

[Jordan Crouse]

On 22/04/07 11:41 -0400, [EMAIL PROTECTED] wrote:
> scx200_acb doesn't detect any device that it can drive (nothing in dmesg
> at all when loaded) on the sc1200.  I believe the main changes that
> happened to scx200_acb was adding support for the newer CS chipsets,
> such as the one used with the geode LX (which does work now).

That ISA detection is almost definately suffering from severe bit rot.
Once you get past that though, you should be fine - the silicon behind
the ACB hasn't changed since the MediaGX days.

Jordan

-- 
Jordan Crouse
Senior Linux Engineer
Advanced Micro Devices, Inc.



-
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: [REPORT] cfs-v4 vs sd-0.44

[Linus Torvalds]

On Sun, 22 Apr 2007, Juliusz Chroboczek wrote:
> 
> Why not do it in the X server itself?  This will avoid controversial
> policy in the kernel, and have the added advantage of working with
> X servers that don't directly access hardware.

It's wrong *wherever* you do it.

The X server should not be re-niced. It was done in the past, and it was 
wrogn then (and caused problems - we had to tell people to undo it, 
because some distros had started doing it by default).

If you have a single client, the X server is *not* more important than the 
client, and indeed, renicing the X server causes bad patterns: just 
because the client sends a request does not mean that the X server should 
immediately be given the CPU as being "more important". 

In other words, the things that make it important that the X server _can_ 
get CPU time if needed are all totally different from the X server being 
"more important". The X server is more important only in the presense of 
multiple clients, not on its own! Needing to renice it is a hack for a bad 
scheduler, and shows that somebody doesn't understand the problem!

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/

BUG: Null pointer dereference (2.6.21-rc7)

[William Heimbigner]

On running "pktsetup 0 /dev/hdd", I get the following:

[ 3970.461403] =
[ 3970.482051] [ INFO: possible recursive locking detected ]
[ 3970.498210] 2.6.21-rc7 #2
[ 3970.506062] -
[ 3970.58] vol_id/8686 is trying to acquire lock:
[ 3970.536576]  (>bd_mutex){--..}, at: [] do_open+0x65/0x285
[ 3970.557104]
[ 3970.557109] but task is already holding lock:
[ 3970.574627]  (>bd_mutex){--..}, at: [] do_open+0x65/0x285
[ 3970.595160]
[ 3970.595161] other info that might help us debug this:
[ 3970.614757] 2 locks held by vol_id/8686:
[ 3970.626505]  #0:  (>bd_mutex){--..}, at: [] 
do_open+0x65/0x285
[ 3970.648388]  #1:  (_mutex#2){--..}, at: [] mutex_lock+0x1c/0x1f
[ 3970.670065]
[ 3970.670070] stack backtrace:
[ 3970.683165]  [] show_trace_log_lvl+0x1a/0x2f
[ 3970.698604]  [] show_trace+0x12/0x14
[ 3970.711964]  [] dump_stack+0x16/0x18
[ 3970.725322]  [] __lock_acquire+0x12e/0xb93
[ 3970.740243]  [] lock_acquire+0x68/0x82
[ 3970.754122]  [] mutex_lock_nested+0xef/0x275
[ 3970.769560]  [] do_open+0x65/0x285
[ 3970.782397]  [] __blkdev_get+0x73/0x7e
[ 3970.796279]  [] blkdev_get+0x15/0x17
[ 3970.809638]  [] pkt_open+0x95/0xc4e
[ 3970.822737]  [] do_open+0x94/0x285
[ 3970.835578]  [] blkdev_open+0x28/0x51
[ 3970.849196]  [] __dentry_open+0xff/0x1b1
[ 3970.863594]  [] nameidata_to_filp+0x27/0x37
[ 3970.878770]  [] do_filp_open+0x33/0x3b
[ 3970.892654]  [] do_sys_open+0x43/0xc2
[ 3970.906274]  [] sys_open+0x1c/0x1e
[ 3970.919113]  [] sysenter_past_esp+0x5d/0x99
[ 3970.934292]  ===
[ 3971.630710] pktcdvd: pkt_get_last_written failed
[ 3971.645027] BUG: unable to handle kernel NULL pointer dereference at virtual 
address 000e
[ 3971.670652]  printing eip:
[ 3971.678786] c0161aef
[ 3971.685361] *pde = 
[ 3971.693761] Oops:  [#1]
[ 3971.702120] PREEMPT
[ 3971.708722] Modules linked in: udf snd_intel8x0 snd_ac97_codec ac97_bus 
i810_audio ac97_codec 8139cp 8139too iTCO_wdt
[ 3971.741005] CPU:0
[ 3971.741006] EIP:0060:[]Not tainted VLI
[ 3971.741008] EFLAGS: 00010203   (2.6.21-rc7 #2)
[ 3971.777034] EIP is at do_sys_open+0x59/0xc2
[ 3971.789555] eax: 0002   ebx: 8000   ecx: c0182a6b   edx: dc8df650
[ 3971.809878] esi: ff9c   edi: 0002   ebp: de336fa4   esp: de336f88
[ 3971.830200] ds: 007b   es: 007b   fs: 00d8  gs: 0033  ss: 0068
[ 3971.847674] Process vol_id (pid: 8686, ti=de336000 task=d0b90de0 
task.ti=de336000)
[ 3971.869812] Stack:   cef97000 0003 bf9d7f65 8000 
b7facff4 de336fb0
[ 3971.895286]c0161b90  de336000 c0103e24 bf9d7f65 8000 
 8000
[ 3971.920755]b7facff4 bf9d5e08 0005 007b 007b  
0005 e410
[ 3971.946228] Call Trace:
[ 3971.954126]  [] show_trace_log_lvl+0x1a/0x2f
[ 3971.969563]  [] show_stack_log_lvl+0x9d/0xa5
[ 3971.985004]  [] show_registers+0x1fb/0x33c
[ 3971.24]  [] die+0x107/0x21f
[ 3972.011984]  [] do_page_fault+0x448/0x520
[ 3972.026644]  [] error_code+0x74/0x7c
[ 3972.040003]  [] sys_open+0x1c/0x1e
[ 3972.052841]  [] sysenter_past_esp+0x5d/0x99
[ 3972.068022]  ===
[ 3972.078728] Code: f0 78 7e 8b 45 08 89 d9 8b 55 ec 89 04 24 89 f0 e8 82 ff ff ff 
3d 00 f0 ff ff 89 c7 76 0d 8b 45 f0 e8 dc fb ff ff 89 7d f0 eb 56 <8b> 40 0c bb 
20 00 00 40 8b 70 30 0f b7 56 66 81 e2 00 f0 00 00
[ 3972.138557] EIP: [] do_sys_open+0x59/0xc2 SS:ESP 0068:de336f88

Is this a bug?

If any more information is necessary, I'd be happy to provide it.
William Heimbigner
[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/

Linux 2.6.16.49

[Adrian Bunk]

Location:
ftp://ftp.kernel.org/pub/linux/kernel/v2.6/

git tree:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.16.y.git

RSS feed of the git tree:
http://www.kernel.org/git/?p=linux/kernel/git/stable/linux-2.6.16.y.git;a=rss


Changes since 2.6.16.48:

Adrian Bunk (2):
  Linux 2.6.16.49-rc1
  Linux 2.6.16.49

Ard van Breemen (1):
  start_kernel: test if irq's got enabled early, barf, and disable them 
again

Aristeu Sergio Rozanski Filho (1):
  tty_io: fix race in master pty close/slave pty close path

Aubrey Li (1):
  [NET]: Fix UDP checksum issue in net poll mode.

David S. Miller (3):
  [SCSI] QLOGICPTI: Do not unmap DMA unless we actually mapped something.
  [SPARC64]: Fix SBUS IOMMU allocation code.
  [SPARC64]: Fix arg passing to compat_sys_ipc().

Jean Delvare (1):
  hwmon/w83627ehf: Fix the fan5 clock divider write

Linas Vepstas (1):
  elevator: move clearing of unplug flag earlier

Olaf Kirch (1):
  [IrDA]: Correctly handling socket error

Tom Callaway (1):
  [SPARC64]: Fix inline directive in pci_iommu.c


 Makefile|2 
 arch/sparc64/kernel/pci_iommu.c |2 
 arch/sparc64/kernel/sbus.c  |  560 +---
 arch/sparc64/kernel/sys32.S |1 
 arch/sparc64/kernel/systbls.S   |2 
 block/elevator.c|   11 
 drivers/char/tty_io.c   |   14 
 drivers/hwmon/w83627ehf.c   |6 
 drivers/scsi/qlogicpti.c|2 
 init/main.c |5 
 net/core/netpoll.c  |7 
 net/irda/af_irda.c  |3 
 12 files changed, 272 insertions(+), 343 deletions(-)

-
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: [REPORT] cfs-v4 vs sd-0.44

[Juliusz Chroboczek]

> Oh I definitely was not advocating against renicing X,

Why not do it in the X server itself?  This will avoid controversial
policy in the kernel, and have the added advantage of working with
X servers that don't directly access hardware.

Con, if you tell me ``if you're running under Linux and such and such
/sys variable has value so-and-so, then it's definitely a good idea to
call nice(42) at the X server's start up'', then I'll commit it into
X.Org.  (Please CC both me the list, so I can point any people
complaining to the archives.)

Juliusz
-
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] [KERNEL-DOC] kill warnings when building mandocs

[Randy Dunlap]

---
~Randy


--- Original Message ---
> On Thu, Apr 19, 2007 at 08:53:36AM -0700, Randy Dunlap wrote:
> > On Thu, 19 Apr 2007 08:20:59 +0200 Borislav Petkov wrote:
> > 
> > > 
> > > > > I'm pretty sure the reason you cannot reproduce this warning is the 
> > > > > line 
> > > > > 
> > > > > 1
> > > > > 
> > > > > which can be found in param.xsl, it being a part of the docbook-xsl
> > > > > distribution. The parameter's name is self-explanatory and a '1' 
> > > > > suppresses
> > > > > the version generation. I was able to get this error because in the
> > > > > debian docbook-xsl package this param value is set to 0 by default.
> > > > 
> > > > Hm, I don't seem to have that file installed (except in
> > > > /usr/share/xml/docbook/stylesheet/...).  Where would it normally
> > > > be installed?
> > > 
> > > /usr/share/xml/docbook/stylesheet/nwalsh/manpages/param.xsl here
> > 
> > OK, I have that one, with a /current/ stuck in there:
> > 
> > 
> > /usr/share/xml/docbook/stylesheet/nwalsh/1.69.1/manpages/param.xsl
> > 
> > 0
> 
> That's why you don't get the warnings.
> 
> > > > > This means, some users will get this warning and some will not, 
> > > > > depending on the
> > > > > setting in the param.xsl file. What is the way to go here wrt to a 
> > > > > solution
> > > > > dealing with all cases:
> > > > > 
> > > > > 1. patch the kernel-doc?
> > > > > 2. issue an info so that the user can suppress the annoying warning by
> > > > > themselves?
> > > > > 3. ...?
> > > > 
> > > > 
> > > > Are other people seeing these warning messages ??
> > > Hm, is anyone building the manpages target at all?
> > 
> > Other than the 2 of us... I couldn't say.
> 
> By the way, can we consider the item 
> "- clean up Documentation/DocBook/, fix warnings that occur
> on make *docs."  
> from the KJ TODO list as now done?

i'm traveling atm  i'll check on that next week.


> > > > If so, I think that we should patch the kernel-doc.  I don't think
> > > > that many people would read info about how to avoid the warnings.
> > 
> > 
> > ---
> > ~Randy
> > *** Remember to use Documentation/SubmitChecklist when testing your code ***
> 
> -- 
> Regards/Gruß,
> Boris.

-
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] dma_declare_coherent_memory wrong allocation

[Guennadi Liakhovetski]

On Mon, 23 Apr 2007, Guennadi Liakhovetski wrote:

> to also allow for size not an integer number of pages as Andrew noticed? 
> This could be done in 2 patches:

patch 2:

---
Fix bitmap allocation and size non-multiple of PAGE_SIZE in 
dma_declare_coherent_memory implementations. i386 compile-tested.

Signed-off-by: G. Liakhovetski <[EMAIL PROTECTED]>

diff --git a/arch/i386/kernel/pci-dma.c b/arch/i386/kernel/pci-dma.c
index 3ebcea0..0a9317a 100644
--- a/arch/i386/kernel/pci-dma.c
+++ b/arch/i386/kernel/pci-dma.c
@@ -76,8 +76,8 @@ int dma_declare_coherent_memory(struct device *dev, 
dma_addr_t bus_addr,
dma_addr_t device_addr, size_t size, int flags)
 {
void __iomem *mem_base = NULL;
-   int pages = size >> PAGE_SHIFT;
-   int bitmap_size = (pages + 31)/32;
+   int pages = DIV_ROUND_UP(size, PAGE_SIZE);
+   int bitmap_size = BITS_TO_LONGS(pages) * BYTES_PER_LONG;
 
if ((flags & (DMA_MEMORY_MAP | DMA_MEMORY_IO)) == 0)
goto out;
diff --git a/arch/cris/arch-v32/drivers/pci/dma.c 
b/arch/cris/arch-v32/drivers/pci/dma.c
index d634347..99f760e 100644
--- a/arch/cris/arch-v32/drivers/pci/dma.c
+++ b/arch/cris/arch-v32/drivers/pci/dma.c
@@ -75,8 +75,8 @@ int dma_declare_coherent_memory(struct device *dev, 
dma_addr_t bus_addr,
dma_addr_t device_addr, size_t size, int flags)
 {
void __iomem *mem_base;
-   int pages = size >> PAGE_SHIFT;
-   int bitmap_size = (pages + 31)/32;
+   int pages = DIV_ROUND_UP(size, PAGE_SIZE);
+   int bitmap_size = BITS_TO_LONGS(pages) * BYTES_PER_LONG;
 
if ((flags & (DMA_MEMORY_MAP | DMA_MEMORY_IO)) == 0)
goto out;
-
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] macintosh/therm_pm72.c: Convert to kthread API.

[Paul Mackerras]

Christoph Hellwig writes:

> Why is this driver using a thread at all?  It's only doing a bunch
> of rather short-lived things in the thread.

It's doing i2c reads and writes, which block, and are actually quite
slow.

Paul.
-
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] dma_declare_coherent_memory wrong allocation

[Guennadi Liakhovetski]

On Sun, 22 Apr 2007, James Bottomley wrote:

> On Fri, 2007-04-13 at 20:08 +0200, Guennadi Liakhovetski wrote:
> > -   int bitmap_size = (pages + 31)/32;
> > +   int bitmap_size = DIV_ROUND_UP(pages, 8);
> 
> This isn't quite right.  Bitmaps are arrays of longs, not arrays of
> bytes.  The bug is forgetting that kmalloc() takes bytes ...
> 
> How about
> 
> int bitmap_size = DIV_ROUNDUP(pages, 32) * 4;

Right, thinko. How about using his:

+   int pages = DIV_ROUND_UP(size, PAGE_SIZE);
+   int bitmap_size = BITS_TO_LONGS(pages) * BYTES_PER_LONG;

to also allow for size not an integer number of pages as Andrew noticed? 
This could be done in 2 patches:

---
Introduce BYTES_PER_LONG and remove local definitions. fbsys 
compile-tested, amifb untested (framebuffer maintainer cc'ed)...

Signed-off-by: G. Liakhovetski <[EMAIL PROTECTED]>

--- a/include/linux/types.h 2007-04-15 22:07:52.0 +0200
+++ b/include/linux/types.h 2007-04-22 22:51:17.0 +0200
@@ -9,6 +9,7 @@
unsigned long name[BITS_TO_LONGS(bits)]
 
 #define BITS_PER_BYTE 8
+#define BYTES_PER_LONG (BITS_PER_LONG / BITS_PER_BYTE)
 #endif
 
 #include 
diff --git a/drivers/video/fbsysfs.c b/drivers/video/fbsysfs.c
index 40c80c8..6bb68b8 100644
--- a/drivers/video/fbsysfs.c
+++ b/drivers/video/fbsysfs.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define FB_SYSFS_FLAG_ATTR 1
 
@@ -37,7 +38,6 @@
  */
 struct fb_info *framebuffer_alloc(size_t size, struct device *dev)
 {
-#define BYTES_PER_LONG (BITS_PER_LONG/8)
 #define PADDING (BYTES_PER_LONG - (sizeof(struct fb_info) % BYTES_PER_LONG))
int fb_info_size = sizeof(struct fb_info);
struct fb_info *info;
diff --git a/drivers/video/amifb.c b/drivers/video/amifb.c
index 1a849b8..a53d5a2 100644
--- a/drivers/video/amifb.c
+++ b/drivers/video/amifb.c
@@ -51,6 +51,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include 
 #include 
@@ -1350,15 +1352,7 @@ static int amifb_pan_display(struct fb_var_screeninfo 
*var,
 }
 
 
-#if BITS_PER_LONG == 32
-#define BYTES_PER_LONG 4
-#define SHIFT_PER_LONG 5
-#elif BITS_PER_LONG == 64
-#define BYTES_PER_LONG 8
-#define SHIFT_PER_LONG 6
-#else
-#define Please update me
-#endif
+#define SHIFT_PER_LONG ilog2(BITS_PER_LONG)
 
 
 /*
-
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 -mm 2/3] freezer: Introduce freezer_flags

[Paul Jackson]

Rafael wrote:
> I'll try to explain how it works.

Ok - thanks.  Good explanation of how it works.

One more question - why would I want to do this?

Is this like something that would be useful on a laptop, to suspend
activity and reduce battery drain, while preserving the current state
of ones sessions and avoiding having to logout or shutdown?

Or are there other good uses for this?

Is it useful for quietting a system down before doing hot plug or
unplug of key components, such as processors and memory?

Thanks.

-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson <[EMAIL PROTECTED]> 1.925.600.0401
-
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: ChunkFS - measuring cross-chunk references

[Amit Gud]

Karuna sagar K wrote:

Hi,

The attached code contains program to estimate the cross-chunk
references for ChunkFS file system (idea from Valh). Below are the
results:



Nice to see some numbers! But would be really nice to know:

- what the chunk size is
- how the files were created or, more vaguely, how 'aged' the fs is
- what is the chunk allocation algorithm


Best,
AG
--
May the source be with you.
http://www.cis.ksu.edu/~gud

-
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] use spinlock instead of binary mutex in CDU-31A driver

[Andi Kleen]

Matthias Kaehlcke <[EMAIL PROTECTED]> writes:

> -static DECLARE_MUTEX(sony_sem);  /* Semaphore for drive hardware 
> access */
> +static DEFINE_MUTEX(sony_mtx);   /* Mutex for drive hardware 
> access */

That's not a spinlock.  Also normally some rationale is added to the
description for a change?

-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: [RFC][PATCH -mm 2/3] freezer: Introduce freezer_flags

[Rafael J. Wysocki]

On Sunday, 22 April 2007 23:14, Paul Jackson wrote:
> Rafael wrote:
> > Move all of the freezer-related flags to a separate field in task_struct and
> > introduce functions to operate them using set_bit() etc.
> 
> It's getting time I learned what this freezer thing is.
> 
> What would you suggest I read?
> 
> I looked in include/linux/freezer.h and didn't see any explanations.
> I found one Documenation file, power/kernel_threads.txt, that explained
> the interaction of freezing and kernel threads.  I looked in the
> comments for various 2.6.21-rc6-mm1 freezer* patches, and saw various
> interesting details.
> 
> But I couldn't find any documentation telling me what a freezer was,
> or what a refrigerator is.
> 
> Did I miss something?

Well, unfortunately not.  The freezer is not separately documented, mainly
because (1) for a long time it's been a part of the suspend code and no one
else used it, and (2) because it's been changing a lot recently and it's been
a 'moving target' from the documentation point of view.

I'll try to explain how it works.

In short, we use the freezer to make tasks enter a specific function, called
the refrigerator, and stay there until they are let out.  This is done by
calling freeze_processes() (in 2.6.21-rc7 it is located in
kernel/power/process.c) that executes try_to_freeze_tasks() separately for
userland processes and kernel threads (the sync() in between is needed by
the suspend code).  try_to_freeze_tasks() sets the FREEZE flag (TIF_FREEZE in
2.6.21-rc7) for each freezable (I'll explain what that means in a while) task
and sends a fake signal to it.

Userland processes then go to get_signal_to_deliver(), where they execute
try_to_freeze() (defined in include/linux/freezer.h) and call refrigerator()
(in kernel/power/process.c), since the FREEZE flag is set.  In refrigerator()
they reset the FREEZE flag and set the FROZEN flag (in 2.6.21-rc7 it is a
process flag defined in sched.h).  Next, they loop in refrigerator() until
someone resets the FROZEN flag for them.  Then we say that they are 'frozen'.

Kernel threads don't call get_signal_to_deliver(), so they have to execute
try_to_freeze() directly to go to the refrigerator.  Moreover, kernel threads
may not want to go there at all, in which case they should set the NOFREEZE
flag (in 2.6.21-rc7 it is a process flag defined in sched.h), that makes
try_to_freeze_tasks() ignore them.

Apart from the kernel threads that have the NOFREEZE flag set,
try_to_freeze_tasks() ignores the task that's running it (its current task)
and the tasks that have exit_state different from 0.  They all are regarded
as 'not freezable'.

Of course, kernel threads that declare themselves as not freezable, by setting
the NOFREEZE flag, should be careful enough not to interfere with the subsystem
that is using the freezer (ie. has called freeze_processes()), which may be
quite difficult in practice, so only a few kernel threads do it (and even some
of them really shouldn't).

The subsystem that has called freeze_processes() is responsible for the
'thawing' of tasks, which is done by calling thaw_processes() (defined in
kernel/power/process.c).  It runs thaw_tasks() (in the same file) for kernel
threads and userland processes.  This function loops over all tasks and
resets the FROZEN flag for them, so that they can leave the refrigerator.

The suspend code uses the freezer to make sure that processes won't get
in the way when some suspend-related low-level operations are carried out
(like suspending devices, the creation of a suspend image by swsusp etc.).
Other subsystems may use it for similar purposes.

Greetings,
Rafael
-
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] sas_scsi_host: Convert to use the kthread API

[Eric W. Biederman]

James Bottomley <[EMAIL PROTECTED]> writes:

> Changelog and cc to linux-scsi, and I think it can go in ... not that it
> matters; nothing ever activates this code inside libsas anyway ...

Should we just remove the relevant code then?

Eric
-
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: [PATCH][RFC] PCMCIA support for 8xx using platform devices

[Arnd Bergmann]

On Sunday 22 April 2007, Vitaly Bordug wrote:
> This utilizes PCMCIA on mpc885ads and mpc866ads from arch/powerpc. In the
> new approach, direct IMMR accesses from within drivers/ were totally
> eliminated, that requires hardware_enable, hardware_disable, voltage_set
> board-specific functions to be moved over to BSP code section   
> (arch/powerpc/platforms/8xx in 885 case). There is just no way to have
> both arch/ppc and arch/powerpc approaches to work simultaneously because
> of that.  

Maybe I'm missing a key issue here, but what's the point of adding
more platform_devices for stuff that is already in the device tree?
Shouldn't this be made an of_platform_driver instead so you can
use the existing of_device directly?

Arnd <><
-
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: Wrong free clusters count on FAT32

[Bodo Eggert]

On Sun, 22 Apr 2007, OGAWA Hirofumi wrote:
> Bodo Eggert <[EMAIL PROTECTED]> writes:

> > Windows _does_ care*, it will pretend the disk to be full.
> 
> Did you test on 2000 or XP? (e.g. write 0 to free_clusters, then
> create new file.)

That was back when I still used W98.

> > - usefree is a bad name (I'd suggest recalc_free instead),
> 
> Is it about nofree option?

Yes. I think recalc_free is way more descriptive.

> > and your description is too cryptic to be understood by a non-linux
> > FAT expert.
> 
> Um... why do we need to care about non-linux people in the patch?

Non-experts in Linux FAT implementation details. "recalc sounds like might 
take long, let's try to disable it" should be all it takes to get a fast 
mount.
-- 
Top 100 things you don't want the sysadmin to say:
35. Ummm... Didn't you say you turned it off?
-
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] sas_scsi_host: Convert to use the kthread API

[James Bottomley]

On Sun, 2007-04-22 at 20:38 +0100, Christoph Hellwig wrote:
> On Thu, Apr 19, 2007 at 05:37:53PM -0700, Andrew Morton wrote:
> > On Thu, 19 Apr 2007 01:58:38 -0600
> > "Eric W. Biederman" <[EMAIL PROTECTED]> wrote:
> > 
> > > From: Eric W. Biederman <[EMAIL PROTECTED]>
> > > 
> > > This patch modifies the sas scsi host thread startup
> > > to use kthread_run not kernel_thread and deamonize.
> > > kthread_run is slightly simpler and more maintainable.
> > > 
> > 
> > Again, I'll rename this to "partially convert...".  This driver should be
> > using kthread_should_stop() and kthread_stop() rather than the
> > apparently-unnecessary ->queue_thread_kill thing.
> > 
> > This driver was merged two and a half years after the kthread API was
> > available.   Our coding-vs-reviewing effort is out of balance.
> 
> Here's a full conversion.

Changelog and cc to linux-scsi, and I think it can go in ... not that it
matters; nothing ever activates this code inside libsas anyway ...

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/

[PATCH] use spinlock instead of binary mutex in idt77252 driver

[Matthias Kaehlcke]

use spinlock instead of binary mutex in idt77252 driver

Signed-off-by: Matthias Kaehlcke <[EMAIL PROTECTED]>

--
 
diff --git a/drivers/atm/idt77252.c b/drivers/atm/idt77252.c
index b4b8014..e3cf141 100644
--- a/drivers/atm/idt77252.c
+++ b/drivers/atm/idt77252.c
@@ -2430,7 +2430,7 @@ idt77252_open(struct atm_vcc *vcc)
 
set_bit(ATM_VF_ADDR, >flags);
 
-   down(>mutex);
+   mutex_lock(>mutex);
 
OPRINTK("%s: opening vpi.vci: %d.%d\n", card->name, vpi, vci);
 
@@ -2441,7 +2441,7 @@ idt77252_open(struct atm_vcc *vcc)
break;
default:
printk("%s: Unsupported AAL: %d\n", card->name, vcc->qos.aal);
-   up(>mutex);
+   mutex_unlock(>mutex);
return -EPROTONOSUPPORT;
}
 
@@ -2450,7 +2450,7 @@ idt77252_open(struct atm_vcc *vcc)
card->vcs[index] = kzalloc(sizeof(struct vc_map), GFP_KERNEL);
if (!card->vcs[index]) {
printk("%s: can't alloc vc in open()\n", card->name);
-   up(>mutex);
+   mutex_unlock(>mutex);
return -ENOMEM;
}
card->vcs[index]->card = card;
@@ -2479,14 +2479,14 @@ idt77252_open(struct atm_vcc *vcc)
if (inuse) {
printk("%s: %s vci already in use.\n", card->name,
   inuse == 1 ? "tx" : inuse == 2 ? "rx" : "tx and rx");
-   up(>mutex);
+   mutex_unlock(>mutex);
return -EADDRINUSE;
}
 
if (vcc->qos.txtp.traffic_class != ATM_NONE) {
error = idt77252_init_tx(card, vc, vcc, >qos);
if (error) {
-   up(>mutex);
+   mutex_unlock(>mutex);
return error;
}
}
@@ -2494,14 +2494,14 @@ idt77252_open(struct atm_vcc *vcc)
if (vcc->qos.rxtp.traffic_class != ATM_NONE) {
error = idt77252_init_rx(card, vc, vcc, >qos);
if (error) {
-   up(>mutex);
+   mutex_unlock(>mutex);
return error;
}
}
 
set_bit(ATM_VF_READY, >flags);
 
-   up(>mutex);
+   mutex_unlock(>mutex);
return 0;
 }
 
@@ -2515,7 +2515,7 @@ idt77252_close(struct atm_vcc *vcc)
unsigned long addr;
unsigned long timeout;
 
-   down(>mutex);
+   mutex_lock(>mutex);
 
IPRINTK("%s: idt77252_close: vc = %d (%d.%d)\n",
card->name, vc->index, vcc->vpi, vcc->vci);
@@ -2586,7 +2586,7 @@ done:
free_scq(card, vc->scq);
}
 
-   up(>mutex);
+   mutex_unlock(>mutex);
 }
 
 static int
@@ -2597,7 +2597,7 @@ idt77252_change_qos(struct atm_vcc *vcc, struct atm_qos 
*qos, int flags)
struct vc_map *vc = vcc->dev_data;
int error = 0;
 
-   down(>mutex);
+   mutex_lock(>mutex);
 
if (qos->txtp.traffic_class != ATM_NONE) {
if (!test_bit(VCF_TX, >flags)) {
@@ -2643,7 +2643,7 @@ idt77252_change_qos(struct atm_vcc *vcc, struct atm_qos 
*qos, int flags)
set_bit(ATM_VF_HASQOS, >flags);
 
 out:
-   up(>mutex);
+   mutex_unlock(>mutex);
return error;
 }
 
@@ -3703,7 +3703,7 @@ idt77252_init_one(struct pci_dev *pcidev, const struct 
pci_device_id *id)
membase = pci_resource_start(pcidev, 1);
srambase = pci_resource_start(pcidev, 2);
 
-   init_MUTEX(>mutex);
+   mutex_init(>mutex);
spin_lock_init(>cmd_lock);
spin_lock_init(>tst_lock);
 
diff --git a/drivers/atm/idt77252.h b/drivers/atm/idt77252.h
index 544b397..a3b2f74 100644
--- a/drivers/atm/idt77252.h
+++ b/drivers/atm/idt77252.h
@@ -359,7 +359,7 @@ struct idt77252_dev
unsigned long   srambase;   /* SAR's sram  base address */
void __iomem*fbq[4];/* FBQ fill addresses */
 
-   struct semaphoremutex;
+   struct mutexmutex;
spinlock_t  cmd_lock;   /* for r/w utility/sram */
 
unsigned long   softstat;

-- 
Matthias Kaehlcke
Linux Application Developer
Barcelona

  Insanity: doing the same thing over and over
again and expecting different results
(Albert Einstein)
 .''`.
using free software / Debian GNU/Linux | http://debian.org  : :'  :
`. `'`
gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4  `-
-
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 1/1] Char: icom, mark __init as __devinit

[Jiri Slaby]

icom, mark __init as __devinit

Two functions are called from __devinit context, but they are marked as
__init. Fix this.

Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>

---
commit 257f51b72348e8879e8ef397f82e1408233843c1
tree 79a82d6c884adc7b941773929c92d269a9b91679
parent 6f42cfdf174bdd2c05edf7d192713042bf25339c
author Jiri Slaby <[EMAIL PROTECTED]> Sun, 22 Apr 2007 23:29:21 +0200
committer Jiri Slaby <[EMAIL PROTECTED]> Sun, 22 Apr 2007 23:29:21 +0200

 drivers/serial/icom.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/serial/icom.c b/drivers/serial/icom.c
index e4f8873..0a3268b 100644
--- a/drivers/serial/icom.c
+++ b/drivers/serial/icom.c
@@ -163,7 +163,7 @@ static void free_port_memory(struct icom_port *icom_port)
}
 }
 
-static int __init get_port_memory(struct icom_port *icom_port)
+static int __devinit get_port_memory(struct icom_port *icom_port)
 {
int index;
unsigned long stgAddr;
@@ -1379,7 +1379,7 @@ static void icom_port_active(struct icom_port *icom_port, 
struct icom_adapter *i
0x8024 + 2 - 2 * (icom_port->port - 2);
}
 }
-static int __init icom_load_ports(struct icom_adapter *icom_adapter)
+static int __devinit icom_load_ports(struct icom_adapter *icom_adapter)
 {
struct icom_port *icom_port;
int port_num;
-
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] use spinlock instead of binary mutex in CDU-31A driver

[Matthias Kaehlcke]

use spinlock instead of binary mutex in CDU-31A driver

Signed-off-by: Matthias Kaehlcke <[EMAIL PROTECTED]>

--
 
diff --git a/drivers/cdrom/cdu31a.c b/drivers/cdrom/cdu31a.c
index 2157c58..d3649e4 100644
--- a/drivers/cdrom/cdu31a.c
+++ b/drivers/cdrom/cdu31a.c
@@ -263,7 +263,7 @@ static int sony_toc_read = 0;   /* Has the TOC been 
read for
 static struct s_sony_subcode last_sony_subcode;/* Points to the last
   subcode address read */
 
-static DECLARE_MUTEX(sony_sem);/* Semaphore for drive hardware 
access */
+static DEFINE_MUTEX(sony_mtx); /* Mutex for drive hardware access */
 
 static int is_double_speed = 0;/* does the drive support double speed 
? */
 
@@ -339,11 +339,11 @@ static int scd_drive_status(struct cdrom_device_info 
*cdi, int slot_nr)
return -EINVAL;
if (sony_spun_up)
return CDS_DISC_OK;
-   if (down_interruptible(_sem))
+   if (mutex_lock_interruptible(_mtx))
return -ERESTARTSYS;
if (scd_spinup() == 0)
sony_spun_up = 1;
-   up(_sem);
+   mutex_unlock(_mtx);
return sony_spun_up ? CDS_DISC_OK : CDS_DRIVE_NOT_READY;
 }
 
@@ -452,7 +452,7 @@ static int scd_reset(struct cdrom_device_info *cdi)
 {
unsigned long retry_count;
 
-   if (down_interruptible(_sem))
+   if (mutex_lock_interruptible(_mtx))
return -ERESTARTSYS;
reset_drive();
 
@@ -461,7 +461,7 @@ static int scd_reset(struct cdrom_device_info *cdi)
sony_sleep();
}
 
-   up(_sem);
+   mutex_unlock(_mtx);
return 0;
 }
 
@@ -655,10 +655,10 @@ static int scd_select_speed(struct cdrom_device_info 
*cdi, int speed)
else
sony_speed = speed - 1;
 
-   if (down_interruptible(_sem))
+   if (mutex_lock_interruptible(_mtx))
return -ERESTARTSYS;
set_drive_params(sony_speed);
-   up(_sem);
+   mutex_unlock(_mtx);
return 0;
 }
 
@@ -673,10 +673,10 @@ static int scd_lock_door(struct cdrom_device_info *cdi, 
int lock)
} else {
is_auto_eject = 0;
}
-   if (down_interruptible(_sem))
+   if (mutex_lock_interruptible(_mtx))
return -ERESTARTSYS;
set_drive_params(sony_speed);
-   up(_sem);
+   mutex_unlock(_mtx);
return 0;
 }
 
@@ -1143,7 +1143,7 @@ static void handle_abort_timeout(unsigned long data)
 {
pr_debug(PFX "Entering %s\n", __FUNCTION__);
/* If it is in use, ignore it. */
-   if (down_trylock(_sem) == 0) {
+   if (mutex_trylock(_mtx) == 0) {
/* We can't use abort_read(), because it will sleep
   or schedule in the timer interrupt.  Just start
   the operation, finish it on the next access to
@@ -1154,7 +1154,7 @@ static void handle_abort_timeout(unsigned long data)
 
sony_blocks_left = 0;
abort_read_started = 1;
-   up(_sem);
+   mutex_unlock(_mtx);
}
pr_debug(PFX "Leaving %s\n", __FUNCTION__);
 }
@@ -1300,7 +1300,7 @@ static void do_cdu31a_request(request_queue_t * q)
pr_debug(PFX "Entering %s\n", __FUNCTION__);
 
spin_unlock_irq(q->queue_lock);
-   if (down_interruptible(_sem)) {
+   if (mutex_lock_interruptible(_mtx)) {
spin_lock_irq(q->queue_lock);
return;
}
@@ -1435,7 +1435,7 @@ static void do_cdu31a_request(request_queue_t * q)
add_timer(_abort_timer);
 #endif
 
-   up(_sem);
+   mutex_unlock(_mtx);
spin_lock_irq(q->queue_lock);
pr_debug(PFX "Leaving %s at %d\n", __FUNCTION__, __LINE__);
 }
@@ -1906,10 +1906,10 @@ static int scd_get_last_session(struct 
cdrom_device_info *cdi,
return 1;
 
if (!sony_toc_read) {
-   if (down_interruptible(_sem))
+   if (mutex_lock_interruptible(_mtx))
return -ERESTARTSYS;
sony_get_toc();
-   up(_sem);
+   mutex_unlock(_mtx);
}
 
ms_info->addr_format = CDROM_LBA;
@@ -1988,11 +1988,11 @@ scd_get_mcn(struct cdrom_device_info *cdi, struct 
cdrom_mcn *mcn)
unsigned int res_size;
 
memset(mcn->medium_catalog_number, 0, 14);
-   if (down_interruptible(_sem))
+   if (mutex_lock_interruptible(_mtx))
return -ERESTARTSYS;
do_sony_cd_cmd(SONY_REQ_UPC_EAN_CMD,
   NULL, 0, resbuffer, _size);
-   up(_sem);
+   mutex_unlock(_mtx);
if ((res_size < 2) || ((resbuffer[0] & 0xf0) == 0x20));
else {
/* packed bcd to single ASCII digits */
@@ -2207,7 +2207,7 @@ static int read_audio(struct cdrom_read_audio *ra)
unsigned int res_size;
unsigned int cframe;
 
-   if (down_interruptible(_sem))
+   if 

Re: [ANNOUNCE] Staircase Deadline cpu scheduler version 0.46

[Con Kolivas]

On Monday 23 April 2007 03:58, Thomas Backlund wrote:
> mån 2007-04-23 klockan 01:03 +1000 skrev Con Kolivas:
> > Yet another significant bugfix for SMP balancing was just posted for the
> > staircase deadline cpu scheduler which improves behaviour dramatically on
> > any SMP machine.
> >
> > Thanks to Willy Tarreau for noticing more bugs.
> >
> > As requested was a version in the Makefile so this version of the patch
> > adds -sd046 to the kernel version.
> >
> > http://ck.kolivas.org/patches/staircase-deadline/2.6.21-rc7-sd-0.46.patch
> > http://ck.kolivas.org/patches/staircase-deadline/2.6.20.7-sd-0.46.patch
> >
> > Renicing X to -10, while not essential, may be desirable on the desktop.
> > Unlike the CFS scheduler which renices X without your intervention to
> > nice -19, the SD patches do not alter nice level on their own.
> >
> > See the patch just posted called 'sched: implement staircase deadline
> > scheduler load  weight fix' for details of the fixes.
> >
> > Thanks to all testing and giving feedback.
> >
> > Well I'm exhausted...
>
> This one broke 2.6.20.7 build...
>
> kernel/sched.c: In function ‘dependent_sleeper’:
> kernel/sched.c:3319: error: ‘DEF_TIMESLICE’ undeclared (first use in
> this function)
> kernel/sched.c:3319: error: (Each undeclared identifier is reported only
> once
> kernel/sched.c:3319: error: for each function it appears in.)

Apologies it was a blind merge.

Use this instead
http://ck.kolivas.org/patches/staircase-deadline/2.6.20.7-sd-0.46-1.patch

-- 
-ck
-
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 -mm 2/3] freezer: Introduce freezer_flags

[Paul Jackson]

Rafael wrote:
> Move all of the freezer-related flags to a separate field in task_struct and
> introduce functions to operate them using set_bit() etc.

It's getting time I learned what this freezer thing is.

What would you suggest I read?

I looked in include/linux/freezer.h and didn't see any explanations.
I found one Documenation file, power/kernel_threads.txt, that explained
the interaction of freezing and kernel threads.  I looked in the
comments for various 2.6.21-rc6-mm1 freezer* patches, and saw various
interesting details.

But I couldn't find any documentation telling me what a freezer was,
or what a refrigerator is.

Did I miss something?

-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson <[EMAIL PROTECTED]> 1.925.600.0401
-
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] reiserfs: fix xattr root locking/refcount bug

[Jeff Mahoney]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Andrew Morton wrote:
> On Sat, 21 Apr 2007 11:26:31 -0400 Jeff Mahoney <[EMAIL PROTECTED]> wrote:
> 
>>  The listxattr() and getxattr() operations are only protected by a read
>>  lock. As a result, if either of these operations run in parallel, a race
>>  condition exists where the xattr_root will end up being cached twice,
>>  which results in the leaking of a reference and a BUG() on umount.
>>
>>  This patch refactors get_xa_root(), __get_xa_root(), and
>>  create_xa_root(), into one get_xa_root() function that takes
>>  the appropriate locking around the entire critical section.
> 
> Great, thanks.
>  
> Now we need to work out the timing.  Our options are to shove
> it into 2.6.21 immediately, or to give it a run in 2.6.22-rc1 then
> backport into 2.6.21.x.
> 
> What is everyone's confidence level?

I'm pretty confident in this patch for 2.6.21, but I wouldn't object to
waiting until 2.6.22-rc1 either. Operationally, the change isn't that
big and makes the locking more clear and the code simpler. I've tested
on populated file systems, virgin file systems, and tested the error
handling path with each. There is still a bug lurking in how a failure
in ACL inheritance is cleaned up that I ran into while testing, but this
patch didn't introduce it or exacerbate it. I'll add that to my xattr
patch queue.

- -Jeff

- --
Jeff Mahoney
SUSE Labs
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFGK8p0LPWxlyuTD7IRAthXAJ9Hk4f40vwuir2fp2dyte5U1juzlgCeLyiW
UnrEFDbKp/iVAE+CrFVSmqs=
=6s1J
-END PGP SIGNATURE-
-
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/

Testing framework

[Karuna sagar K]

Hi,

For some time I had been working on this file system test framework.
Now I have a implementation for the same and below is the explanation.
Any comments are welcome.

Introduction:
The testing tools and benchmarks available around do not take into
account the repair and recovery aspects of file systems. The test
framework described here focuses on repair and recovery capabilities
of file systems. Since most file systems use 'fsck' to recover from
file system inconsistencies, the test framework characterizes file
systems based on outcomes of running 'fsck'.

Overview:
The model can be described in brief as - prepare a file system, record
the state of the file system, corrupt it, use repair and recovery
tools and finally compare and report the status of the recovered file
system against its initial state.

Prepare Phase:
This is the first phase in the model. Here we prepare a file system to
carry out subsequent phases. A new file system image is created with
the specified name. 'mkfs' program is run on this image and then the
file system is aged after populating it sufficiently. This state of
the file system is considered as an ideal state.

Corruption Phase:
The file system prepared in the prepare phase is corrupted to simulate
a system crash or in general an inconsistency in the file system.
Obviously we are more interested in corrupting the metadata
information. A random corruption would provide us with the results
like that of fs_mutator or fs_fuzzer. However, for different test runs
the corruption would vary and hence it wouldn't be fair and tedious to
have a comparison between file systems. So, we would like have a
mechanism where the corruption could be replayable thus ensuring
almost same amount of corruption be reproduced across test runs. The
techniques for corruption are:

Higher level perspective/approach:
In this approach the file system is viewed as a tree of nodes, where
nodes are either files or directories. The metadata information
corresponding to some randomly chosen nodes of the tree are corrupted.
Nodes which are corrupted are marked or recorded to be able to replay
later. This file system is called source file system while the file
system on which we need to replay the corruption is called target file
system. The assumption is that the target file system contains a set
of files and directories which is a superset of that in the source
file system. Hence to replay the corruption we need point out which
nodes in the source file system were corrupted in the source file
system and corrupt the corresponding nodes in the target file system.

A major disadvantage with this approach is that on-disk structures
(like superblocks, block group descriptors, etc.) are not considered
for corruption.

Lower level perspective/approach:
The file system is looked upon as a set of blocks (more precisely
metadata blocks). We randomly choose from this set of blocks to
corrupt. Hence we would be able to overcome the deficiency of the
previous approach. However this approach makes it difficult to have a
replayable corruption. Further thought about this approach has to be
given.

We could have a blend of both the approaches in the program to
compromise between corruption and replayability.

Repair Phase:
The corrupted file system is repaired and recovered with 'fsck' or any
other tools; this phase considers the repair and recovery action on
the file system as a black box. The time taken to repair by the tool
is measured.

Comparison Phase:
The current state of the file system is compared with the ideal state
of the file system. The metadata information of the file system is
checked with that of the ideal file system and the outcome is noted to
summarize on this test run. If repair tool used is 100% effective then
the current state of the file system should be exactly the same as
that of the ideal file system. Simply checking for equality wouldn't
be right because it doesn't take care of lost and found files. Hence
we need to check node-by-node for each node in the ideal state of the
file system.

State Record:
The comparison phase requires that the ideal state of the file system
be known. Replicating the whole file system would eat up a lot of disk
space. Storing the state of the file system in memory would be costly
in case of huge file systems. So, we need to store the state of the
file system on the disk such that it wouldn't take up a lot of disk
space. We record the metadata information and store it onto a file.
One approach is replicating the metadata blocks of the source file
system and storing the replica blocks under a single file called state
file. Additional metadata such as checksum of the data blocks can be
stored in the same state file. However this may store some unnecessary
metadata information in the state file and hence swelling it up for
huge source file systems. So, instead of storing the metadata blocks
themselves we would summarize the information in them before storing
in the state 

Re: [PATCH] ia64 sn xpc: Convert to use kthread API.

[Christoph Hellwig]

On Thu, Apr 19, 2007 at 01:58:44AM -0600, Eric W. Biederman wrote:
> From: Eric W. Biederman <[EMAIL PROTECTED]>
> 
> This patch starts the xpc kernel threads using kthread_run
> not a combination of kernel_thread and daemonize.  Resuling
> in slightly simpler and more maintainable code.

This driver is a really twisted maze.  It has a lot of threads,
some of them running through the whole lifetime of the driver,
some short-lived and some in a sort of a pool.

The patch below fixes up the long-lived thread as well as fixing
gazillions of leaks in the init routine by switching to proper
goto-based unwinding.

Note that thread pools are something we have in a few places,
and might be worth handling in the core kthread infrastructure,
as tearing down pools will get a bit complicated using the
kthread APIs.


Signed-off-by: Christoph Hellwig <[EMAIL PROTECTED]>

Index: linux-2.6/arch/ia64/sn/kernel/xpc_main.c
===
--- linux-2.6.orig/arch/ia64/sn/kernel/xpc_main.c   2007-04-22 
21:19:22.0 +0200
+++ linux-2.6/arch/ia64/sn/kernel/xpc_main.c2007-04-22 21:33:54.0 
+0200
@@ -55,6 +55,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -159,16 +160,14 @@ static struct ctl_table_header *xpc_sysc
 int xpc_disengage_request_timedout;
 
 /* #of IRQs received */
-static atomic_t xpc_act_IRQ_rcvd;
+static atomic_t xpc_act_IRQ_rcvd = ATOMIC_INIT(0);
 
 /* IRQ handler notifies this wait queue on receipt of an IRQ */
 static DECLARE_WAIT_QUEUE_HEAD(xpc_act_IRQ_wq);
 
+static struct task_struct *xpc_hb_checker_thread;
 static unsigned long xpc_hb_check_timeout;
 
-/* notification that the xpc_hb_checker thread has exited */
-static DECLARE_COMPLETION(xpc_hb_checker_exited);
-
 /* notification that the xpc_discovery thread has exited */
 static DECLARE_COMPLETION(xpc_discovery_exited);
 
@@ -250,17 +249,10 @@ xpc_hb_checker(void *ignore)
int new_IRQ_count;
int force_IRQ=0;
 
-
/* this thread was marked active by xpc_hb_init() */
-
-   daemonize(XPC_HB_CHECK_THREAD_NAME);
-
-   set_cpus_allowed(current, cpumask_of_cpu(XPC_HB_CHECK_CPU));
-
xpc_hb_check_timeout = jiffies + (xpc_hb_check_interval * HZ);
 
-   while (!(volatile int) xpc_exiting) {
-
+   while (!kthread_should_stop()) {
dev_dbg(xpc_part, "woke up with %d ticks rem; %d IRQs have "
"been received\n",
(int) (xpc_hb_check_timeout - jiffies),
@@ -304,14 +296,10 @@ xpc_hb_checker(void *ignore)
(void) wait_event_interruptible(xpc_act_IRQ_wq,
(last_IRQ_count < atomic_read(_act_IRQ_rcvd) ||
jiffies >= xpc_hb_check_timeout ||
-   (volatile int) xpc_exiting));
+   kthread_should_stop()));
}
 
dev_dbg(xpc_part, "heartbeat checker is exiting\n");
-
-
-   /* mark this thread as having exited */
-   complete(_hb_checker_exited);
return 0;
 }
 
@@ -966,9 +954,7 @@ xpc_do_exit(enum xpc_retval reason)
/* wait for the discovery thread to exit */
wait_for_completion(_discovery_exited);
 
-   /* wait for the heartbeat checker thread to exit */
-   wait_for_completion(_hb_checker_exited);
-
+   kthread_stop(xpc_hb_checker_thread);
 
/* sleep for a 1/3 of a second or so */
(void) msleep_interruptible(300);
@@ -1219,29 +1205,29 @@ xpc_system_die(struct notifier_block *nb
 int __init
 xpc_init(void)
 {
-   int ret;
+   int ret = -ENODEV;
partid_t partid;
struct xpc_partition *part;
pid_t pid;
size_t buf_size;
 
+   if (!ia64_platform_is("sn2"))
+   goto out;
 
-   if (!ia64_platform_is("sn2")) {
-   return -ENODEV;
-   }
-
-
+   ret = -ENOMEM;
buf_size = max(XPC_RP_VARS_SIZE,
XPC_RP_HEADER_SIZE + XP_NASID_MASK_BYTES);
xpc_remote_copy_buffer = xpc_kmalloc_cacheline_aligned(buf_size,
 GFP_KERNEL, _remote_copy_buffer_base);
-   if (xpc_remote_copy_buffer == NULL)
-   return -ENOMEM;
+   if (!xpc_remote_copy_buffer)
+   goto out;
 
snprintf(xpc_part->bus_id, BUS_ID_SIZE, "part");
snprintf(xpc_chan->bus_id, BUS_ID_SIZE, "chan");
 
xpc_sysctl = register_sysctl_table(xpc_sys_dir);
+   if (!xpc_sysctl)
+   goto out_free_remote_buffer;
 
/*
 * The first few fields of each entry of xpc_partitions[] need to
@@ -1278,12 +1264,6 @@ xpc_init(void)
xpc_allow_IPI_ops();
 
/*
-* Interrupts being processed will increment this atomic variable and
-* awaken the heartbeat thread which will process the interrupts.
-*/
-   atomic_set(_act_IRQ_rcvd, 0);
-
-

ChunkFS - measuring cross-chunk references

[Karuna sagar K]

Hi,

The attached code contains program to estimate the cross-chunk
references for ChunkFS file system (idea from Valh). Below are the
results:

test on ext3, / partition-1 on 27 March 2007
Number of files = 217806
Number of directories = 24295
Total size = 8193116 KB
Total data stored = 7557892 KB
Size of block groups = 131072 KB
Number of inodes per block group = 16288
Total no. of cross references = 60657

test on ext3, / partition-1 on 22 March 2007
Number of files = 230615
Number of directories = 24243
Total size = 8193116 KB
Total data stored = 7167212 KB
Size of block groups = 131072 KB
Number of inodes per block group = 16288
Total no. of cross references = 62163

test on ext3, / partition-2 on 22 March 2007
Number of files = 79509
Number of directories = 6397
Total size = 3076888 KB
Total data stored = 1685100 KB
Size of block groups = 131072 KB
Number of inodes per block group = 16032
Total no. of cross references = 17996
---
test on ext3, /home partition-3 on 20 April 2007
Number of files = 157632
Number of directories = 13652
Total size = 10233404 KB
Total data stored = 9490196 KB
Size of block groups = 131072 KB
Number of inodes per block group = 16224
Total no. of cross references = 27184
---

Comments??

Thanks,
Karuna


cref.tar.bz2
Description: BZip2 compressed data

Re: [PATCH] arm ecard: Conver to use the kthread API.

[Christoph Hellwig]

On Thu, Apr 19, 2007 at 01:58:43AM -0600, Eric W. Biederman wrote:
> From: Eric W. Biederman <[EMAIL PROTECTED]>
> 
> This patch modifies the startup of kecardd to use
> kthread_run not a kernel_thread combination of kernel_thread
> and daemonize.  Making the code slightly simpler and more
> maintainable.

Looks good.  Given that this is non-modular and there's no
exit function there is no need for further action.

-
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] s390/scsi/zfcp_erp: Convert to use the kthread API

[Christoph Hellwig]

On Thu, Apr 19, 2007 at 01:58:42AM -0600, Eric W. Biederman wrote:
> From: Eric W. Biederman <[EMAIL PROTECTED]>
> 
> Modify zfcperp%s to be started with kthread_run not
> a combination of kernel_thread, daemonize and siginitsetinv
> making the code slightly simpler and more maintainable.

This driver would also benefit from a full kthread conversion.
Unfortunately it has a strange dual-use semaphore (->erp_ready_sem)
that hinders a straight conversion.  Maybe the maintainer can take
a look whether there's a nice way to get rid of that one?

-
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] bluetooth rfcomm: Convert to kthread API.

[Christoph Hellwig]

On Thu, Apr 19, 2007 at 04:12:53PM -0700, Andrew Morton wrote:
> On Thu, 19 Apr 2007 01:58:54 -0600
> "Eric W. Biederman" <[EMAIL PROTECTED]> wrote:
> 
> > From: Eric W. Biederman <[EMAIL PROTECTED]>
> > 
> > This patch starts krfcommd using kthread_run instead of a combination
> > of kernel_thread and daemonize making the code slightly simpler
> > and more maintainable.
> 
> gargh, the more I look at these things, the more I agree with Christoph.

Hehe.  Here's a patch to do the full kthread conversion for rfcomm, it
doesn't have the asynchrnous termination issues the other bluetooth drivers
have.  Also handle init failures in rfcomm while we're at it.


Signed-off-by: Christoph Hellwig <[EMAIL PROTECTED]>

Index: linux-2.6/net/bluetooth/rfcomm/core.c
===
--- linux-2.6.orig/net/bluetooth/rfcomm/core.c  2007-04-22 21:01:31.0 
+0200
+++ linux-2.6/net/bluetooth/rfcomm/core.c   2007-04-22 21:12:30.0 
+0200
@@ -37,6 +37,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -67,7 +68,6 @@ static DEFINE_MUTEX(rfcomm_mutex);
 static unsigned long rfcomm_event;
 
 static LIST_HEAD(session_list);
-static atomic_t terminate, running;
 
 static int rfcomm_send_frame(struct rfcomm_session *s, u8 *data, int len);
 static int rfcomm_send_sabm(struct rfcomm_session *s, u8 dlci);
@@ -1846,26 +1846,6 @@ static inline void rfcomm_process_sessio
rfcomm_unlock();
 }
 
-static void rfcomm_worker(void)
-{
-   BT_DBG("");
-
-   while (!atomic_read()) {
-   if (!test_bit(RFCOMM_SCHED_WAKEUP, _event)) {
-   /* No pending events. Let's sleep.
-* Incoming connections and data will wake us up. */
-   set_current_state(TASK_INTERRUPTIBLE);
-   schedule();
-   }
-
-   /* Process stuff */
-   clear_bit(RFCOMM_SCHED_WAKEUP, _event);
-   rfcomm_process_sessions();
-   }
-   set_current_state(TASK_RUNNING);
-   return;
-}
-
 static int rfcomm_add_listener(bdaddr_t *ba)
 {
struct sockaddr_l2 addr;
@@ -1931,23 +1911,27 @@ static void rfcomm_kill_listener(void)
 
 static int rfcomm_run(void *unused)
 {
-   rfcomm_thread = current;
-
-   atomic_inc();
-
-   daemonize("krfcommd");
set_user_nice(current, -10);
current->flags |= PF_NOFREEZE;
 
BT_DBG("");
 
rfcomm_add_listener(BDADDR_ANY);
+   while (!kthread_should_stop()) {
+   if (!test_bit(RFCOMM_SCHED_WAKEUP, _event)) {
+   /* No pending events. Let's sleep.
+* Incoming connections and data will wake us up. */
+   set_current_state(TASK_INTERRUPTIBLE);
+   schedule();
+   }
 
-   rfcomm_worker();
-
+   /* Process stuff */
+   clear_bit(RFCOMM_SCHED_WAKEUP, _event);
+   rfcomm_process_sessions();
+   }
+   set_current_state(TASK_RUNNING);
rfcomm_kill_listener();
 
-   atomic_dec();
return 0;
 }
 
@@ -2052,24 +2036,52 @@ static CLASS_ATTR(rfcomm_dlc, S_IRUGO, r
 /*  Initialization  */
 static int __init rfcomm_init(void)
 {
+   int err;
+
l2cap_load();
 
-   hci_register_cb(_cb);
+   err = hci_register_cb(_cb);
+   if (err)
+   goto out;
 
-   kernel_thread(rfcomm_run, NULL, CLONE_KERNEL);
+   rfcomm_thread = kthread_run(rfcomm_run, NULL, "krfcommd");
+   if (IS_ERR(rfcomm_thread)) {
+   err = PTR_ERR(rfcomm_thread);
+   goto out_unregister_hci;
+   }
 
-   if (class_create_file(bt_class, _attr_rfcomm_dlc) < 0)
+   err = class_create_file(bt_class, _attr_rfcomm_dlc);
+   if (err < 0) {
BT_ERR("Failed to create RFCOMM info file");
+   goto out_kthread_stop;
+   }
 
-   rfcomm_init_sockets();
+   err = rfcomm_init_sockets();
+   if (err)
+   goto out_remove_sysfs_files;
 
 #ifdef CONFIG_BT_RFCOMM_TTY
-   rfcomm_init_ttys();
+   err = rfcomm_init_ttys();
+   if (err)
+   goto out_cleanup_sockets;
 #endif
 
BT_INFO("RFCOMM ver %s", VERSION);
 
return 0;
+
+#ifdef CONFIG_BT_RFCOMM_TTY
+ out_cleanup_sockets:
+   rfcomm_cleanup_sockets();
+#endif
+ out_remove_sysfs_files:
+   class_remove_file(bt_class, _attr_rfcomm_dlc);
+ out_unregister_hci:
+   hci_unregister_cb(_cb);
+ out_kthread_stop:
+   kthread_stop(rfcomm_thread);
+ out:
+   return err;
 }
 
 static void __exit rfcomm_exit(void)
@@ -2077,15 +2089,7 @@ static void __exit rfcomm_exit(void)
class_remove_file(bt_class, _attr_rfcomm_dlc);
 
hci_unregister_cb(_cb);
-
-   /* Terminate working thread.
-* ie. Set terminate flag and wake it up */
-   atomic_inc();
-   rfcomm_schedule(RFCOMM_SCHED_STATE);
-

Re: Wrong free clusters count on FAT32

[DervishD]

Hi Bodo :)

 * Bodo Eggert <[EMAIL PROTECTED]> dixit:
> OGAWA Hirofumi <[EMAIL PROTECTED]> wrote:
> >>  * Juergen Beisert <[EMAIL PROTECTED]> dixit:
> 
> >>> So the last free sector count is also stored. When mounting this
> >>> filesystem you don't need to walk through the whole FAT to calculate
> >>> the available space, you can use this "cached" value instead. And this
> >>> cached value seems not to be updated in your portable device.
> >>
> >> It doesn't, certainly, but Windows doesn't care. Moreover, the
> >> device doesn't seem to recalculate the value on every run (unless it
> >> does it lightning fast!), so maybe the number is stored elsewhere (the
> >> count can be stored in many places as far as I've read, but I don't know
> >> the details).
> 
> AFAIR it's stored twice on FAT32, once in a backup sector and once in the
> superblock or extended superblock (don't remember, I think it was the
> extended ~). It's not stored on FAT{12,16}.

I hadn't noticed the same problem with FAT16 pendrives, so I
suspected that. Thanks for confirming :)

Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!
-
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: Wrong free clusters count on FAT32

[DervishD]

Hi Ogawa :)

 * OGAWA Hirofumi <[EMAIL PROTECTED]> dixit:
> DervishD <[EMAIL PROTECTED]> writes:
> > The problem is that if a program writes a file onto the filesystem
> > without using statfs first to check for free space, the free_clusters
> > entry won't have the real value and the driver may report "disk full" (I
> > haven't read the code for the vfat driver, sorry, so I'm not sure about
> > this) when really there are plenty of clusters to write the new file.
> 
> No need to worry about it. If we ignored the ->free_clusters in
> FSINFO, the fat drivers counts the current free clusters by scaning
> FAT entries if needed.

Cool! :)

> > Probably it's stupid to update the free clusters count at mount time
> > (sorry if so...) but it looks like a good idea to me. And of course, I
> > don't mean to update the value _on disk_, but the kernel's idea of free
> > clusters (so even FAT filesystems mounted R/O will report correct
> > values).
> 
> It would add the limitation to following simple usage,
> 
>   # mount -t vfat /dev/sda1 /mnt
> # cp -a * /mnt
> # umount
> 
> if /dev/sda1 was the large and slow device, "mount" will need several
> minutes to counts free clusters. I think the user will be hard to
> accept the several minutes at "mount".


I can carry some tests, but if Windows does that tasks lightning
fast, Linux surely does it faster ;) I don't think, anyway, that having
a huge USB disk is a common practice when using "modest" machines.

If you want, I can perform a couple of tests. I have a 80GB disk
that I can connect using an USB adapter and my machine is AMD Athlon XP
1900+ with 1GB of RAM, which looks pretty slow nowadays O:)

Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!
-
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 -mm 1/3] Separate freezer from PM code

[Rafael J. Wysocki]

From: Rafael J. Wysocki <[EMAIL PROTECTED]>

Now that the freezer is used by kprobes, it is no longer a PM-specific piece of
code.  Move the freezer code out of kernel/power and introduce the
CONFIG_FREEZER option that will be chosen automatically if PM or KPROBES is set.

Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
---
 arch/arm/Kconfig |5 +
 arch/avr32/Kconfig.debug |5 +
 arch/blackfin/Kconfig|5 +
 arch/frv/Kconfig |5 +
 arch/i386/Kconfig|5 +
 arch/ia64/Kconfig|5 +
 arch/mips/Kconfig|5 +
 arch/powerpc/Kconfig |5 +
 arch/ppc/Kconfig |5 +
 arch/s390/Kconfig|5 +
 arch/sh/Kconfig  |5 +
 arch/sparc64/Kconfig |5 +
 arch/x86_64/Kconfig  |8 +
 include/linux/freezer.h  |2 
 kernel/Makefile  |1 
 kernel/freezer.c |  224 +++
 kernel/kprobes.c |2 
 kernel/power/Makefile|2 
 kernel/power/process.c   |  224 ---
 19 files changed, 296 insertions(+), 227 deletions(-)

Index: linux-2.6.21-rc6-mm1/arch/x86_64/Kconfig
===
--- linux-2.6.21-rc6-mm1.orig/arch/x86_64/Kconfig   2007-04-22 
14:14:44.0 +0200
+++ linux-2.6.21-rc6-mm1/arch/x86_64/Kconfig2007-04-22 14:16:03.0 
+0200
@@ -695,6 +695,14 @@ config GENERIC_PENDING_IRQ
depends on GENERIC_HARDIRQS && SMP
default y
 
+#
+# Use the tasks freezer
+#
+config FREEZER
+   bool
+   default y
+   depends on PM || KPROBES
+
 menu "Power management options"
 
 source kernel/power/Kconfig
Index: linux-2.6.21-rc6-mm1/arch/avr32/Kconfig.debug
===
--- linux-2.6.21-rc6-mm1.orig/arch/avr32/Kconfig.debug  2007-04-22 
14:14:44.0 +0200
+++ linux-2.6.21-rc6-mm1/arch/avr32/Kconfig.debug   2007-04-22 
14:16:03.0 +0200
@@ -17,3 +17,8 @@ config KPROBES
   If in doubt, say "N".
 
 endmenu
+
+config FREEZER
+   bool
+   default y
+   depends on KPROBES
Index: linux-2.6.21-rc6-mm1/arch/frv/Kconfig
===
--- linux-2.6.21-rc6-mm1.orig/arch/frv/Kconfig  2007-04-22 14:14:44.0 
+0200
+++ linux-2.6.21-rc6-mm1/arch/frv/Kconfig   2007-04-22 14:16:03.0 
+0200
@@ -364,6 +364,11 @@ source "drivers/pcmcia/Kconfig"
 #sleep-deprived psychotic hacker types can say Y now, everyone else
 #should probably wait a while.
 
+config FREEZER
+   bool
+   default y
+   depends on PM
+
 menu "Power management options"
 source kernel/power/Kconfig
 endmenu
Index: linux-2.6.21-rc6-mm1/arch/i386/Kconfig
===
--- linux-2.6.21-rc6-mm1.orig/arch/i386/Kconfig 2007-04-22 14:14:44.0 
+0200
+++ linux-2.6.21-rc6-mm1/arch/i386/Kconfig  2007-04-22 14:16:03.0 
+0200
@@ -912,6 +912,11 @@ config ARCH_ENABLE_MEMORY_HOTPLUG
def_bool y
depends on HIGHMEM
 
+config FREEZER
+   bool
+   default y
+   depends on PM || KPROBES
+
 menu "Power management options (ACPI, APM)"
depends on !X86_VOYAGER
 
Index: linux-2.6.21-rc6-mm1/arch/ia64/Kconfig
===
--- linux-2.6.21-rc6-mm1.orig/arch/ia64/Kconfig 2007-04-22 14:14:44.0 
+0200
+++ linux-2.6.21-rc6-mm1/arch/ia64/Kconfig  2007-04-22 14:16:03.0 
+0200
@@ -490,6 +490,11 @@ source "fs/Kconfig.binfmt"
 
 endmenu
 
+config FREEZER
+   bool
+   default y
+   depends on PM || KPROBES
+
 menu "Power management and ACPI"
 
 source "kernel/power/Kconfig"
Index: linux-2.6.21-rc6-mm1/arch/powerpc/Kconfig
===
--- linux-2.6.21-rc6-mm1.orig/arch/powerpc/Kconfig  2007-04-22 
14:14:44.0 +0200
+++ linux-2.6.21-rc6-mm1/arch/powerpc/Kconfig   2007-04-22 14:16:03.0 
+0200
@@ -569,6 +569,11 @@ config CMDLINE
  some command-line options at build time by entering them here.  In
  most cases you will need to specify the root device here.
 
+config FREEZER
+   bool
+   default y
+   depends on PM || KPROBES
+
 if !44x || BROKEN
 source kernel/power/Kconfig
 endif
Index: linux-2.6.21-rc6-mm1/arch/ppc/Kconfig
===
--- linux-2.6.21-rc6-mm1.orig/arch/ppc/Kconfig  2007-04-22 14:14:44.0 
+0200
+++ linux-2.6.21-rc6-mm1/arch/ppc/Kconfig   2007-04-22 14:16:03.0 
+0200
@@ -1154,6 +1154,11 @@ config PROC_HARDWARE
 source "drivers/zorro/Kconfig"
 
 if !44x || BROKEN
+config FREEZER
+   bool
+   default y
+   depends on PM
+
 source kernel/power/Kconfig
 endif
 
Index: linux-2.6.21-rc6-mm1/arch/s390/Kconfig

[RFC][PATCH -mm 3/3] freezer: Fix problem with kthread_stop

[Rafael J. Wysocki]

From: Rafael J. Wysocki <[EMAIL PROTECTED]>

Fix the problem with kthread_stop() that causes the freezer to fail if a
freezable thread is attempting to stop a frozen one and that may cause the
freezer to fail if the thread being stopped is freezable and
try_to_freeze_tasks() is running concurrently with kthread_stop().

Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
---
 kernel/kthread.c |9 +
 1 file changed, 9 insertions(+)

Index: linux-2.6.21-rc6-mm1/kernel/kthread.c
===
--- linux-2.6.21-rc6-mm1.orig/kernel/kthread.c  2007-04-09 15:23:48.0 
+0200
+++ linux-2.6.21-rc6-mm1/kernel/kthread.c   2007-04-22 19:05:29.0 
+0200
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 /*
@@ -232,6 +233,14 @@ int kthread_stop(struct task_struct *k)
 
/* Now set kthread_should_stop() to true, and wake it up. */
kthread_stop_info.k = k;
+   if (!freezer_should_exempt(current)) {
+   /* We are freezable, so we must make sure that the thread being
+* stopped is not frozen and will not be frozen until it dies
+*/
+   freezer_exempt(k);
+   if (frozen(k))
+   clear_frozen_flag(k);
+   }
wake_up_process(k);
put_task_struct(k);
 
-
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 -mm 2/3] freezer: Introduce freezer_flags

[Rafael J. Wysocki]

From: Rafael J. Wysocki <[EMAIL PROTECTED]>

Move all of the freezer-related flags to a separate field in task_struct and
introduce functions to operate them using set_bit() etc.

Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
---
 Documentation/power/kernel_threads.txt |2 -
 Documentation/power/swsusp.txt |6 +--
 arch/i386/kernel/apm.c |2 -
 drivers/block/loop.c   |2 -
 drivers/char/apm-emulation.c   |6 +--
 drivers/ieee1394/ieee1394_core.c   |2 -
 drivers/md/md.c|2 -
 drivers/mmc/card/queue.c   |3 +
 drivers/mtd/mtd_blkdevs.c  |3 +
 drivers/scsi/libsas/sas_scsi_host.c|2 -
 drivers/scsi/scsi_error.c  |2 -
 drivers/usb/storage/usb.c  |2 -
 include/asm-arm/thread_info.h  |2 -
 include/asm-blackfin/thread_info.h |2 -
 include/asm-frv/thread_info.h  |2 -
 include/asm-i386/thread_info.h |2 -
 include/asm-ia64/thread_info.h |2 -
 include/asm-mips/thread_info.h |2 -
 include/asm-powerpc/thread_info.h  |2 -
 include/asm-sh/thread_info.h   |2 -
 include/asm-x86_64/thread_info.h   |2 -
 include/linux/freezer.h|   65 ++---
 include/linux/sched.h  |8 ++--
 kernel/fork.c  |2 -
 kernel/freezer.c   |2 -
 kernel/rcutorture.c|4 +-
 kernel/sched.c |2 -
 kernel/softirq.c   |2 -
 kernel/softlockup.c|2 -
 kernel/workqueue.c |2 -
 30 files changed, 83 insertions(+), 58 deletions(-)

Index: linux-2.6.21-rc6-mm1/include/linux/sched.h
===
--- linux-2.6.21-rc6-mm1.orig/include/linux/sched.h 2007-04-22 
19:37:42.0 +0200
+++ linux-2.6.21-rc6-mm1/include/linux/sched.h  2007-04-22 20:55:01.0 
+0200
@@ -1002,7 +1002,10 @@ struct task_struct {
/* Deadlock detection and priority inheritance handling */
struct rt_mutex_waiter *pi_blocked_on;
 #endif
-
+#ifdef CONFIG_FREEZER
+   /* Used by the process freezer, defined in freezer.h */
+   unsigned int freezer_flags;
+#endif
 #ifdef CONFIG_DEBUG_MUTEXES
/* mutex deadlock detection */
struct mutex_waiter *blocked_on;
@@ -1187,8 +1190,6 @@ static inline void put_task_struct(struc
 #define PF_MEMALLOC0x0800  /* Allocating memory */
 #define PF_FLUSHER 0x1000  /* responsible for disk writeback */
 #define PF_USED_MATH   0x2000  /* if unset the fpu must be initialized 
before use */
-#define PF_NOFREEZE0x8000  /* this thread should not be frozen */
-#define PF_FROZEN  0x0001  /* frozen for system suspend */
 #define PF_FSTRANS 0x0002  /* inside a filesystem transaction */
 #define PF_KSWAPD  0x0004  /* I am kswapd */
 #define PF_SWAPOFF 0x0008  /* I am in swapoff */
@@ -1200,7 +1201,6 @@ static inline void put_task_struct(struc
 #define PF_SPREAD_SLAB 0x0200  /* Spread some slab caches over cpuset 
*/
 #define PF_MEMPOLICY   0x1000  /* Non-default NUMA mempolicy */
 #define PF_MUTEX_TESTER0x2000  /* Thread belongs to the rt 
mutex tester */
-#define PF_FREEZER_SKIP0x4000  /* Freezer should not count it 
as freezeable */
 
 /*
  * Only the _current_ task can read/write to tsk->flags, but other
Index: linux-2.6.21-rc6-mm1/include/asm-arm/thread_info.h
===
--- linux-2.6.21-rc6-mm1.orig/include/asm-arm/thread_info.h 2007-04-22 
19:37:42.0 +0200
+++ linux-2.6.21-rc6-mm1/include/asm-arm/thread_info.h  2007-04-22 
20:55:01.0 +0200
@@ -147,7 +147,6 @@ extern void iwmmxt_task_switch(struct th
 #define TIF_POLLING_NRFLAG 16
 #define TIF_USING_IWMMXT   17
 #define TIF_MEMDIE 18
-#define TIF_FREEZE 19
 
 #define _TIF_NOTIFY_RESUME (1 << TIF_NOTIFY_RESUME)
 #define _TIF_SIGPENDING(1 << TIF_SIGPENDING)
@@ -155,7 +154,6 @@ extern void iwmmxt_task_switch(struct th
 #define _TIF_SYSCALL_TRACE (1 << TIF_SYSCALL_TRACE)
 #define _TIF_POLLING_NRFLAG(1 << TIF_POLLING_NRFLAG)
 #define _TIF_USING_IWMMXT  (1 << TIF_USING_IWMMXT)
-#define _TIF_FREEZE(1 << TIF_FREEZE)
 
 /*
  * Change these and you break ASM code in entry-common.S
Index: linux-2.6.21-rc6-mm1/include/asm-blackfin/thread_info.h
===
--- linux-2.6.21-rc6-mm1.orig/include/asm-blackfin/thread_info.h
2007-04-22 19:37:42.0 +0200
+++ linux-2.6.21-rc6-mm1/include/asm-blackfin/thread_info.h 2007-04-22 
20:55:01.0 +0200
@@ -125,7 +125,6 @@ static inline 

[RFC][PATCH -mm 0/3] Separate freezer flags

[Rafael J. Wysocki]

Hi,

The following three patches are related to the separation of the freezer flags
from process/threadinfo flags.

The first patch separates the freezer from the PM code, because it's no longer
a PM-specific piece of code.  This also makes the second patch look better.

The second patch introduces the freezer_flags field of task_struct, present
only if the freezer is compiled in.  All of the freezer-related flags per-task
flags are moved to this field and auxiliary functions for operating them are
defined in freezer.h .  This overlaps with the Gautham's work to some extent,
but I think it's better to introduce these changes independently of the CPU
hotplug code.

The third patch is a bonus. ;-)

Greetings,
Rafael

-
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/

CPU 3: Machine Check Exception: 0000000000000004

[Mr. James W. Laferriere]

Hello All ,  Has anyone else had an occurance of this hard lockup .
	last time it was the scsi bus that was the last item on the console this 
time it's  CPU #3 ...
	Everytime I try & run a bonnie on this system something locks the system 
up hard .  I do not trust this system at this time & need to put it into 
production soon .

Anybody any pointerswhere to look , ... ?

Kernel: Linux 2.6.21-rc7 ,  unpatched .

<<>>
 [EMAIL PROTECTED]:~ # CPU 3: Machine Check Exception: 0004
Kernel panic - not syncing: Unable to continue
Kernel panic - not syncing: Unable to continue

 +-A-+[ sc933s2 jbod chassis ] With 7-FUJITSU-MAP3147NC
 |
 +-B-+[ sc933s2 jbod chassis ] With 7-FUJITSU-MAP3147NC
 |
 + lsi22320 in pci-64-133 slot
[ system ] a SuperServer 6035B-8R
 + aic7902 on board
 |
 +-A-+[ internally ] With 2-Compaq/Seagate-18GB-u320 & 2-FUJITSU-MAP3147NC
 |
 +-B-+[ internally ] With 4-FUJITSU-MAP3147NC

lsi22320 is attached to the sc933s2 on channels A & B ,
cable lengths are ~ 4 feet on both channels .

aic7902 is attached internally thru 'system' ,  a SuperServer 6035B-8R .


 root@(none):~ # ( time bonnie++-1.03a/bonnie++ -u0:0 -d /home -s 524288 ) 2>&1
 | tee 512GB-bonnie++-run-ext3-200704181557.log
Using uid:0, gid:0.
Writing with putc()...mptscsih: ioc0: attempting task abort! (sc=d0795800)
sd 4:0:3:0:
command: <4>mptscsih: ioc1: attempting task abort! (sc=d8c28500)
sd 5:0:1:0:
command: Read(10): 28 00 00 1d d1 b9 00 00 08 00
Read(10): 28 00 00 1e 12 b9 00 00 08 00
mptscsih: ioc1: WARNING - TM Handler for type=1: IOC Not operational 
(0x)!
sd 1:0:3:0: Attempting to queue an A


<<<\previous>>>



You can get the previous log here .
http://www.baby-dragons.com/new-sc933s2-coming-online-to-linux-scsi.log

Any help is greatly appreciated .
JimL

--
+-+
| James   W.   Laferriere | System   Techniques | Give me VMS |
| NetworkEngineer | 663  Beaumont  Blvd |  Give me Linux  |
| [EMAIL PROTECTED] | Pacifica, CA. 94044 |   only  on  AXP |
+-+
-
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] ipv4/ipvs: Convert to kthread API

[Christoph Hellwig]

On Thu, Apr 19, 2007 at 03:59:44PM -0700, Andrew Morton wrote:
> There still seems to be quite a lot of complexity in this driver's
> thread handling which could be removed if we did a full conversion 
> to the kthread API.
> 
> It all looks surprisingly complex in there.

It is.  There quite a few interesting oddities in this code:

 - creation of a forker thread.  This is superflous when using the
   kthread infrastructure as a thread created by kthread_create
   always comes from our dedicated forker thread.
 - the infinite retry on failure looks very bogus, the system
   doesn't recover very well if you try to fork forever in a loop :)
 - a lot of very overlapping state variables.  My reading of the
   code suggests that both a 'master' and 'backup' thread can
   run at the same time.  I think the code would benefit a lot
   from totally separating these codepathes.
 - start_sync_thread and stop_sync_thread are called with
   unchecked user supplied arguments and bug if they don't
   match the expected values.  While all this is under
   capable(CAP_NET_ADMIN) it still sounds like something to
   fix.
 - and the usual removal of semaphores and completions for
   startup/shutdown would benefit the code a lot, as for most
   thread users.
-
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] bluetooth bnep: Convert to kthread API.

[Christoph Hellwig]

On Thu, Apr 19, 2007 at 04:24:59PM -0700, Andrew Morton wrote:
> On Thu, 19 Apr 2007 01:58:51 -0600
> "Eric W. Biederman" <[EMAIL PROTECTED]> wrote:
> 
> > From: Eric W. Biederman <[EMAIL PROTECTED]>
> > 
> > This patch starts kbenpd using kthread_run replacing
> > a combination of kernel_thread and daemonize.  Making
> > the code a little simpler and more maintainable.
> > 
> >
> 
>   while (!atomic_read(>killed)) {
> 
> ho hum.

Note that this also stands against a full kthread conversion.
Marcel put my old patches for a full kthread conversion in, but
they didn't deal properly with some of the premaure exit cases,
and causes OOPSes.

I don't remember what the problems where, but the case of a thread
terminating earlier and possibly asynchronously is one of the
cases we'll probably have to add to the kthread infrastructure
before all uses of kernel_thread in drivers can be converted.

-
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.20 7/14] CRIS architecture update - Boot

[Sam Ravnborg]

On Sun, Apr 22, 2007 at 09:25:23PM +0200, Mikael Starvik wrote:
> The attached patch relates to CRIS kernel booting (decompresser etc)

--- ../linux/arch/cris/arch-v32/boot/compressed/Makefile2007-02-04 
19:44:54.0 +0100
+++ linux-2.6/arch/cris/arch-v32/boot/compressed/Makefile   2007-02-13 
12:55:23.0 +0100
@@ -1,41 +1,30 @@
 #
-# lx25/arch/cris/arch-v32/boot/compressed/Makefile
+# arch/cris/arch-v32/boot/compressed/Makefile
 #
-# create a compressed vmlinux image from the original vmlinux files and romfs
-#
-
-target = $(target_compressed_dir)
-src= $(src_compressed_dir)

-CC = gcc-cris -mlinux -march=v32 -I $(TOPDIR)/include
-CFLAGS = -O2
+CC = gcc-cris -mlinux -march=v32 -I $(TOPDIR)/include
+AFLAGS += -I $(TOPDIR)/include/asm/mach/ -I $(TOPDIR)/include/asm/arch
+CFLAGS += -O2 -I $(TOPDIR)/include/asm/mach/ -I $(TOPDIR)/include/asm/arch
 LD = gcc-cris -mlinux -march=v32 -nostdlib

Use of $(TOPDIR) is deprecated.
Please replace with $(srctree).

There was lots of other Makefile changes but they looked OK in general.
When the patch-set I would like to give to full set a review - please ping me.

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: [PATCH 2.6.20 1/14] CRIS architecture update - Build system

[Sam Ravnborg]

On Sun, Apr 22, 2007 at 09:24:34PM +0200, Mikael Starvik wrote:
> The attached patch improves the CRIS build system by allowing out-of-tree 
> objdir everywhere
I have browsed through the changes and this is in addition a much more readable
set of Makefile's - good work!

I stumbled over this:

+AFLAGS = -traditional
+LD = gcc-cris -mlinux -nostdlib
+LDFLAGS = -T $(obj)/rescue.ld

We have in i386 / x86_64 recently managed to get rid of -traditional.
And it looks a bit strange that you use gcc as linker.

But thats how it was also done before so not a big issue.

>  
> Signed-off-by: Mikael Starvik <[EMAIL PROTECTED]>
Acked-by: Sam Ravnborg <[EMAIL PROTECTED]>


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: [PATCH] mtd_blkdevs: Convert to use the kthread API

[Christoph Hellwig]

On Sun, Apr 22, 2007 at 01:24:53PM +0100, Christoph Hellwig wrote:
> On Thu, Apr 19, 2007 at 12:55:28AM -0600, Eric W. Biederman wrote:
> > From: Eric W. Biederman <[EMAIL PROTECTED]> - unquoted
> > 
> > thread_run is used intead of kernel_thread, daemonize, and mucking
> > around blocking signals directly.
> 
> This is the full conversion I sent to Dave in April 2006, but never got
> any feedback to:

Here's a slightly updated version that corrects the set_current_state
placement as discussed with Dave on irc:


Signed-off-by: Christoph Hellwig <[EMAIL PROTECTED]>

Index: linux-2.6/drivers/mtd/mtd_blkdevs.c
===
--- linux-2.6.orig/drivers/mtd/mtd_blkdevs.c2007-01-29 10:03:52.0 
+0100
+++ linux-2.6/drivers/mtd/mtd_blkdevs.c 2007-04-22 20:39:20.0 +0200
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 static LIST_HEAD(blktrans_majors);
@@ -28,9 +29,7 @@ extern struct mutex mtd_table_mutex;
 extern struct mtd_info *mtd_table[];
 
 struct mtd_blkcore_priv {
-   struct completion thread_dead;
-   int exiting;
-   wait_queue_head_t thread_wq;
+   struct task_struct *thread;
struct request_queue *rq;
spinlock_t queue_lock;
 };
@@ -83,38 +82,19 @@ static int mtd_blktrans_thread(void *arg
/* we might get involved when memory gets low, so use PF_MEMALLOC */
current->flags |= PF_MEMALLOC | PF_NOFREEZE;
 
-   daemonize("%sd", tr->name);
-
-   /* daemonize() doesn't do this for us since some kernel threads
-  actually want to deal with signals. We can't just call
-  exit_sighand() since that'll cause an oops when we finally
-  do exit. */
-   spin_lock_irq(>sighand->siglock);
-   sigfillset(>blocked);
-   recalc_sigpending();
-   spin_unlock_irq(>sighand->siglock);
-
spin_lock_irq(rq->queue_lock);
-
-   while (!tr->blkcore_priv->exiting) {
+   while (!kthread_should_stop()) {
struct request *req;
struct mtd_blktrans_dev *dev;
int res = 0;
-   DECLARE_WAITQUEUE(wait, current);
 
req = elv_next_request(rq);
 
if (!req) {
-   add_wait_queue(>blkcore_priv->thread_wq, );
set_current_state(TASK_INTERRUPTIBLE);
-
spin_unlock_irq(rq->queue_lock);
-
schedule();
-   remove_wait_queue(>blkcore_priv->thread_wq, );
-
spin_lock_irq(rq->queue_lock);
-
continue;
}
 
@@ -133,13 +113,13 @@ static int mtd_blktrans_thread(void *arg
}
spin_unlock_irq(rq->queue_lock);
 
-   complete_and_exit(>blkcore_priv->thread_dead, 0);
+   return 0;
 }
 
 static void mtd_blktrans_request(struct request_queue *rq)
 {
struct mtd_blktrans_ops *tr = rq->queuedata;
-   wake_up(>blkcore_priv->thread_wq);
+   wake_up_process(tr->blkcore_priv->thread);
 }
 
 
@@ -388,8 +368,6 @@ int register_mtd_blktrans(struct mtd_blk
return ret;
}
spin_lock_init(>blkcore_priv->queue_lock);
-   init_completion(>blkcore_priv->thread_dead);
-   init_waitqueue_head(>blkcore_priv->thread_wq);
 
tr->blkcore_priv->rq = blk_init_queue(mtd_blktrans_request, 
>blkcore_priv->queue_lock);
if (!tr->blkcore_priv->rq) {
@@ -403,13 +381,14 @@ int register_mtd_blktrans(struct mtd_blk
blk_queue_hardsect_size(tr->blkcore_priv->rq, tr->blksize);
tr->blkshift = ffs(tr->blksize) - 1;
 
-   ret = kernel_thread(mtd_blktrans_thread, tr, CLONE_KERNEL);
-   if (ret < 0) {
+   tr->blkcore_priv->thread = kthread_run(mtd_blktrans_thread, tr,
+   "%sd", tr->name);
+   if (IS_ERR(tr->blkcore_priv->thread)) {
blk_cleanup_queue(tr->blkcore_priv->rq);
unregister_blkdev(tr->major, tr->name);
kfree(tr->blkcore_priv);
mutex_unlock(_table_mutex);
-   return ret;
+   return PTR_ERR(tr->blkcore_priv->thread);
}
 
INIT_LIST_HEAD(>devs);
@@ -432,9 +411,7 @@ int deregister_mtd_blktrans(struct mtd_b
mutex_lock(_table_mutex);
 
/* Clean up the kernel thread */
-   tr->blkcore_priv->exiting = 1;
-   wake_up(>blkcore_priv->thread_wq);
-   wait_for_completion(>blkcore_priv->thread_dead);
+   kthread_stop(tr->blkcore_priv->thread);
 
/* Remove it from the list of active majors */
list_del(>list);
-
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] sas_scsi_host: Convert to use the kthread API

[Christoph Hellwig]

On Thu, Apr 19, 2007 at 05:37:53PM -0700, Andrew Morton wrote:
> On Thu, 19 Apr 2007 01:58:38 -0600
> "Eric W. Biederman" <[EMAIL PROTECTED]> wrote:
> 
> > From: Eric W. Biederman <[EMAIL PROTECTED]>
> > 
> > This patch modifies the sas scsi host thread startup
> > to use kthread_run not kernel_thread and deamonize.
> > kthread_run is slightly simpler and more maintainable.
> > 
> 
> Again, I'll rename this to "partially convert...".  This driver should be
> using kthread_should_stop() and kthread_stop() rather than the
> apparently-unnecessary ->queue_thread_kill thing.
> 
> This driver was merged two and a half years after the kthread API was
> available.   Our coding-vs-reviewing effort is out of balance.

Here's a full conversion.


Signed-off-by: Christoph Hellwig <[EMAIL PROTECTED]>

Index: linux-2.6/drivers/scsi/libsas/sas_scsi_host.c
===
--- linux-2.6.orig/drivers/scsi/libsas/sas_scsi_host.c  2007-04-22 
20:30:39.0 +0200
+++ linux-2.6/drivers/scsi/libsas/sas_scsi_host.c   2007-04-22 
20:36:51.0 +0200
@@ -23,6 +23,8 @@
  *
  */
 
+#include 
+
 #include "sas_internal.h"
 
 #include 
@@ -184,7 +186,7 @@ static int sas_queue_up(struct sas_task 
list_add_tail(>list, >task_queue);
core->task_queue_size += 1;
spin_unlock_irqrestore(>task_queue_lock, flags);
-   up(>queue_thread_sema);
+   wake_up_process(core->queue_thread);
 
return 0;
 }
@@ -819,7 +821,7 @@ static void sas_queue(struct sas_ha_stru
struct sas_internal *i = to_sas_internal(core->shost->transportt);
 
spin_lock_irqsave(>task_queue_lock, flags);
-   while (!core->queue_thread_kill &&
+   while (!kthread_should_stop() &&
   !list_empty(>task_queue)) {
 
can_queue = sas_ha->lldd_queue_size - core->task_queue_size;
@@ -858,8 +860,6 @@ static void sas_queue(struct sas_ha_stru
spin_unlock_irqrestore(>task_queue_lock, flags);
 }
 
-static DECLARE_COMPLETION(queue_th_comp);
-
 /**
  * sas_queue_thread -- The Task Collector thread
  * @_sas_ha: pointer to struct sas_ha
@@ -867,40 +867,33 @@ static DECLARE_COMPLETION(queue_th_comp)
 static int sas_queue_thread(void *_sas_ha)
 {
struct sas_ha_struct *sas_ha = _sas_ha;
-   struct scsi_core *core = _ha->core;
 
-   daemonize("sas_queue_%d", core->shost->host_no);
current->flags |= PF_NOFREEZE;
 
-   complete(_th_comp);
-
while (1) {
-   down_interruptible(>queue_thread_sema);
+   set_current_state(TASK_INTERRUPTIBLE);
+   schedule();
sas_queue(sas_ha);
-   if (core->queue_thread_kill)
+   if (kthread_should_stop())
break;
}
 
-   complete(_th_comp);
-
return 0;
 }
 
 int sas_init_queue(struct sas_ha_struct *sas_ha)
 {
-   int res;
struct scsi_core *core = _ha->core;
 
spin_lock_init(>task_queue_lock);
core->task_queue_size = 0;
INIT_LIST_HEAD(>task_queue);
-   init_MUTEX_LOCKED(>queue_thread_sema);
 
-   res = kernel_thread(sas_queue_thread, sas_ha, 0);
-   if (res >= 0)
-   wait_for_completion(_th_comp);
-
-   return res < 0 ? res : 0;
+   core->queue_thread = kthread_run(sas_queue_thread, sas_ha,
+"sas_queue_%d", core->shost->host_no);
+   if (IS_ERR(core->queue_thread))
+   return PTR_ERR(core->queue_thread);
+   return 0;
 }
 
 void sas_shutdown_queue(struct sas_ha_struct *sas_ha)
@@ -909,10 +902,7 @@ void sas_shutdown_queue(struct sas_ha_st
struct scsi_core *core = _ha->core;
struct sas_task *task, *n;
 
-   init_completion(_th_comp);
-   core->queue_thread_kill = 1;
-   up(>queue_thread_sema);
-   wait_for_completion(_th_comp);
+   kthread_stop(core->queue_thread);
 
if (!list_empty(>task_queue))
SAS_DPRINTK("HA: %llx: scsi core task queue is NOT empty!?\n",
Index: linux-2.6/include/scsi/libsas.h
===
--- linux-2.6.orig/include/scsi/libsas.h2007-04-22 20:32:41.0 
+0200
+++ linux-2.6/include/scsi/libsas.h 2007-04-22 20:32:59.0 +0200
@@ -314,8 +314,7 @@ struct scsi_core {
struct list_head  task_queue;
int   task_queue_size;
 
-   struct semaphore  queue_thread_sema;
-   int   queue_thread_kill;
+   struct task_struct *queue_thread;
 };
 
 struct sas_ha_event {
-
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] i386 voyager: Convert the monitor thread to use the kthread API

[Christoph Hellwig]

On Thu, Apr 19, 2007 at 12:55:27AM -0600, Eric W. Biederman wrote:
> From: Eric W. Biederman <[EMAIL PROTECTED]> - unquoted
> 
> This patch just trivially replaces kernel_thread and daemonize
> with a single call to kthread_run.

Here's a better patch that does the full kthread conversion +
switch to wake_up_process.  Only compile tested of course due to
lack of voyager hardware.


Signed-off-by: Christoph Hellwig <[EMAIL PROTECTED]>

Index: linux-2.6/arch/i386/mach-voyager/voyager_cat.c
===
--- linux-2.6.orig/arch/i386/mach-voyager/voyager_cat.c 2007-04-22 
15:19:28.0 +0200
+++ linux-2.6/arch/i386/mach-voyager/voyager_cat.c  2007-04-22 
15:27:03.0 +0200
@@ -,7 +,7 @@ voyager_cat_do_common_interrupt(void)
printk(KERN_ERR "Voyager front panel switch 
turned off\n");
voyager_status.switch_off = 1;
voyager_status.request_from_kernel = 1;
-   up(_sem);
+   wake_up_process(voyager_thread);
}
/* Tell the hardware we're taking care of the
 * shutdown, otherwise it will power the box off
@@ -1157,7 +1157,7 @@ voyager_cat_do_common_interrupt(void)
outb(VOYAGER_CAT_END, CAT_CMD);
voyager_status.power_fail = 1;
voyager_status.request_from_kernel = 1;
-   up(_sem);
+   wake_up_process(voyager_thread);
}


Index: linux-2.6/arch/i386/mach-voyager/voyager_thread.c
===
--- linux-2.6.orig/arch/i386/mach-voyager/voyager_thread.c  2007-04-22 
15:15:24.0 +0200
+++ linux-2.6/arch/i386/mach-voyager/voyager_thread.c   2007-04-22 
15:25:51.0 +0200
@@ -24,33 +24,16 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 
-#define THREAD_NAME "kvoyagerd"
 
-/* external variables */
-int kvoyagerd_running = 0;
-DECLARE_MUTEX_LOCKED(kvoyagerd_sem);
-
-static int thread(void *);
-
-static __u8 set_timeout = 0;
-
-/* Start the machine monitor thread.  Return 1 if OK, 0 if fail */
-static int __init
-voyager_thread_start(void)
-{
-   if(kernel_thread(thread, NULL, CLONE_KERNEL) < 0) {
-   /* This is serious, but not fatal */
-   printk(KERN_ERR "Voyager: Failed to create system monitor 
thread!!!\n");
-   return 1;
-   }
-   return 0;
-}
+struct task_struct *voyager_thread;
+static __u8 set_timeout;
 
 static int
 execute(const char *string)
@@ -110,31 +93,15 @@ check_continuing_condition(void)
}
 }
 
-static void
-wakeup(unsigned long unused)
-{
-   up(_sem);
-}
-
 static int
 thread(void *unused)
 {
-   struct timer_list wakeup_timer;
-
-   kvoyagerd_running = 1;
-
-   daemonize(THREAD_NAME);
-
-   set_timeout = 0;
-
-   init_timer(_timer);
-
-   sigfillset(>blocked);
-
printk(KERN_NOTICE "Voyager starting monitor thread\n");
 
-   for(;;) {
-   down_interruptible(_sem);
+   for (;;) {
+   set_current_state(TASK_INTERRUPTIBLE);
+   schedule_timeout(set_timeout ? HZ : MAX_SCHEDULE_TIMEOUT);
+
VDEBUG(("Voyager Daemon awoken\n"));
if(voyager_status.request_from_kernel == 0) {
/* probably awoken from timeout */
@@ -143,20 +110,26 @@ thread(void *unused)
check_from_kernel();
voyager_status.request_from_kernel = 0;
}
-   if(set_timeout) {
-   del_timer(_timer);
-   wakeup_timer.expires = HZ + jiffies;
-   wakeup_timer.function = wakeup;
-   add_timer(_timer);
-   }
}
 }
 
+static int __init
+voyager_thread_start(void)
+{
+   voyager_thread = kthread_run(thread, NULL, "kvoyagerd");
+   if (IS_ERR(voyager_thread)) {
+   printk(KERN_ERR "Voyager: Failed to create system monitor 
thread.\n");
+   return PTR_ERR(voyager_thread);
+   }
+   return 0;
+}
+
+
 static void __exit
 voyager_thread_stop(void)
 {
-   /* FIXME: do nothing at the moment */
+   kthread_stop(voyager_thread);
 }
 
 module_init(voyager_thread_start);
-//module_exit(voyager_thread_stop);
+module_exit(voyager_thread_stop);
Index: linux-2.6/include/asm-i386/voyager.h
===
--- linux-2.6.orig/include/asm-i386/voyager.h   2007-04-22 15:18:39.0 
+0200
+++ linux-2.6/include/asm-i386/voyager.h2007-04-22 15:24:13.0 
+0200
@@ -487,15 +487,11 @@ extern struct voyager_qic_cpi *voyager_q
 extern 

Re: Today's 'master' leaves .idx/.pack in 0400

[Linus Torvalds]

On Sun, 22 Apr 2007, Junio C Hamano wrote:
> 
> How about this as a replacement (hot off the press -- still
> running the tests).

Looks good, but..

> + mode_t mode = umask(0);
> +
> + umask(mode);
> + mode = 0666 & ~mode;

I would really suggest just defaulting to

mode = 0444 & ~mode;

since there simply is never any reason to allow a writable pack-file.

The fact that we have some tests that try to corrupt a pack-file is not 
really a reason. Just make them do "chmod +w" before corrupting it.

But your patch is an obvious improvement regardless, so I certainly don't 
think this is a *big* issue.

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] mtd_blkdevs: Convert to use the kthread API

[Christoph Hellwig]

On Sun, Apr 22, 2007 at 02:23:00PM +0100, David Woodhouse wrote:
> On Sun, 2007-04-22 at 13:24 +0100, Christoph Hellwig wrote:
> > This is the full conversion I sent to Dave in April 2006, but never
> > got any feedback to:
> 
> Sorry about that; I need prodding sometimes. I'll provide some now... 
> 
> Can you show me why the thread won't now miss a wakeup if it goes to
> sleep just as a new request is added to its queue?

Exactly the same thing that happened before.  If you look at
wake_up_process it's just a tiny wrapper around try_to_wake_up.

And wake_up expands to __wake_up expaneds to __wake_up_common
which just walks the list of threads attached to the waitqueue
and then calls curr->func, which expands to try_to_wake_up.

So when your thread still is in running state nothing changes.
If your thread is not in running state it'll get woken by both
variants.

-
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/

Fw: [PATCH][RFC] PCMCIA support for 8xx using platform devices

[Vitaly Bordug]

This utilizes PCMCIA on mpc885ads and mpc866ads from arch/powerpc. In the new 
approach,
direct IMMR accesses from within drivers/ were totally eliminated, that 
requires hardware_enable, hardware_disable, voltage_set board-specific 
functions to be moved over to BSP code section 
(arch/powerpc/platforms/8xx in 885 case). There is just no way to have both 
arch/ppc and arch/powerpc approaches to work simultaneously because of that.

It implies a bit of work to move other target's bits over to BSP region, but no 
ifdef hell worths it,
in addition to the fact of being moved/merged to arch/powerpc, the code would 
spot this problem 
anyway.

Signed-off-by: Vitaly Bordug <[EMAIL PROTECTED]>
---
This is FW of original message sent to [EMAIL PROTECTED] to attach wider 
audience.
Original maillist kept in loop to prevent misunderstanding...

 arch/powerpc/boot/dts/mpc885ads.dts  |   12 +
 arch/powerpc/platforms/8xx/mpc885ads.h   |5 
 arch/powerpc/platforms/8xx/mpc885ads_setup.c |   63 +
 arch/powerpc/sysdev/fsl_soc.c|   58 
 drivers/pcmcia/Kconfig   |1 
 drivers/pcmcia/m8xx_pcmcia.c |  342 --
 include/linux/fs_pcmcia_pd.h |   27 ++
 7 files changed, 318 insertions(+), 190 deletions(-)

diff --git a/arch/powerpc/boot/dts/mpc885ads.dts 
b/arch/powerpc/boot/dts/mpc885ads.dts
index 90e047a..330ac91 100644
--- a/arch/powerpc/boot/dts/mpc885ads.dts
+++ b/arch/powerpc/boot/dts/mpc885ads.dts
@@ -112,6 +112,18 @@
compatible = "CPM";
};
 
+   [EMAIL PROTECTED] {
+   linux,phandle = <0080>;
+   #interrupt-cells = <1>;
+   #size-cells = <2>;
+   compatible = "8xx";
+   device_type = "pcmcia";
+   reg = <80 80>;
+   clock-frequency = <2faf080>;
+   interrupt-parent = ;
+   interrupts = ;
+   };
+
[EMAIL PROTECTED] {
linux,phandle = ;
#address-cells = <1>;
diff --git a/arch/powerpc/platforms/8xx/mpc885ads.h 
b/arch/powerpc/platforms/8xx/mpc885ads.h
index 7c31aec..4439346 100644
--- a/arch/powerpc/platforms/8xx/mpc885ads.h
+++ b/arch/powerpc/platforms/8xx/mpc885ads.h
@@ -91,5 +91,10 @@ #define PC_ENET_RENA ((ushort)0x0800)
 #define SICR_ENET_MASK ((uint)0x00ff)
 #define SICR_ENET_CLKRT((uint)0x002c)
 
+/* Some internal interrupt registers use an 8-bit mask for the interrupt
+ * level instead of a number.
+ */
+#define mk_int_int_mask(IL) (1 << (7 - (IL/2)))
+
 #endif /* __ASM_MPC885ADS_H__ */
 #endif /* __KERNEL__ */
diff --git a/arch/powerpc/platforms/8xx/mpc885ads_setup.c 
b/arch/powerpc/platforms/8xx/mpc885ads_setup.c
index 394f983..1ba423f 100644
--- a/arch/powerpc/platforms/8xx/mpc885ads_setup.c
+++ b/arch/powerpc/platforms/8xx/mpc885ads_setup.c
@@ -22,6 +22,7 @@ #include 
 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -375,6 +376,68 @@ static void init_i2c_ioports()
 setbits16(>cp_pbodr, 0x0030);
 }
 
+void pcmcia_hw_setup(int slot, int enable)
+{
+   unsigned *bcsr_io;
+
+   bcsr_io = ioremap(BCSR1, sizeof(unsigned long));
+   if (enable)
+   clrbits32(bcsr_io, BCSR1_PCCEN);
+   else
+   setbits32(bcsr_io, BCSR1_PCCEN);
+
+   iounmap(bcsr_io);
+}
+
+int pcmcia_set_voltage(int slot, int vcc, int vpp)
+{
+u32 reg = 0;
+unsigned *bcsr_io;
+
+bcsr_io = ioremap(BCSR1, sizeof(unsigned long));
+
+switch(vcc) {
+case 0:
+break;
+case 33:
+reg |= BCSR1_PCCVCC0;
+break;
+case 50:
+reg |= BCSR1_PCCVCC1;
+break;
+default:
+return 1;
+}
+
+switch(vpp) {
+case 0:
+break;
+case 33:
+case 50:
+if(vcc == vpp)
+reg |= BCSR1_PCCVPP1;
+else
+return 1;
+break;
+case 120:
+if ((vcc == 33) || (vcc == 50))
+reg |= BCSR1_PCCVPP0;
+else
+return 1;
+default:
+return 1;
+}
+
+/* first, turn off all power */
+clrbits32(bcsr_io, 0x0061);
+
+/* enable new powersettings */
+setbits32(bcsr_io, reg);
+
+iounmap(bcsr_io);
+return 0;
+}
+
 int platform_device_skip(char *model, int id)
 {
 #ifdef CONFIG_MPC8xx_SECOND_ETH_SCC3
diff --git a/arch/powerpc/sysdev/fsl_soc.c 

[PATCH 2.6.20 7/14] CRIS architecture update - Boot

[Mikael Starvik]

The attached patch relates to CRIS kernel booting (decompresser etc)
 
Signed-off-by: Mikael Starvik <[EMAIL PROTECTED]>
 
/Mikael


cris7_boot.patch
Description: cris7_boot.patch

PATCH 2.6.20 11/14; CRIS architecture update - IDE driver

[Mikael Starvik]

The attached patch updates the CRIS IDE driver.
 
Signed-off-by: Mikael Starvik <[EMAIL PROTECTED]  >
 
/Mikael
 


cris11_ide.patch
Description: cris11_ide.patch

[PATCH 2.6.20 3/14] CRIS architecture update - Configuration

[Mikael Starvik]

The attached patch relates to CRIS kernel configuration.
 
Signed-off-by: Mikael Starvik <[EMAIL PROTECTED]>
 
/Mikael
 


cris3_config.patch
Description: cris3_config.patch

[PATCH 2.6.20 6/14] CRIS architecture update - Library

[Mikael Starvik]

The attached patch relates to CRIS library functions
 
Signed-off-by: Mikael Starvik <[EMAIL PROTECTED]>
 
/Mikael
 


cris6_lib.patch
Description: cris6_lib.patch

[PATCH 2.6.20 2/14] CRIS architecture update - subarchs

[Mikael Starvik]

The attached patch corrects a few paths related to sub-architectures.
 
Signed-off-by: Mikael Starvik <[EMAIL PROTECTED]>
 
/Mikael


cris2_arch.patch
Description: cris2_arch.patch