date:20070827

On Tue, 28 Aug 2007 07:33:08 +0200 Jiri Slaby <[EMAIL PROTECTED]> wrote:

> > Again, ARRAY_SIZE() would be clearer here.
> 
> No, this is only do this 16 times, no corresponding table :).

OK, poorly chosen example.  But there are lots of others, like:

+
+   for (i = 0; i < 59; i++) {
+   stk11xx_read_dummy(dev, 0x02ff);
+   stk11xx_write_reg(dev, 0x02ff, 0x00);
+
+   stk11xx_write_reg(dev, 0x0204, values_204[i]);
+   stk11xx_write_reg(dev, 0x0205, values_205[i]);

-
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 1/1] V4L: stk11xx, add a new webcam driver

2007-08-27 Thread Jiri Slaby

Andrew Morton napsal(a):
> On Sun, 26 Aug 2007 07:09:02 -0700
> Jiri Slaby <[EMAIL PROTECTED]> wrote:
> + retok = stk11xx_check_device(dev, 500);
> + if (retok != 1) {
> + dev_err(>udev->dev, "load microcode fail\n");
> + return -EIO;
> + }
> 
> Normally we'd use a return value of zero to indicate success.  So that the
> negative return value can tell people _why_ it failed.

it returns
-EIO = fail
0 = we succeeded, but the device is not ready
1 = the device is OK

Seems proper to change the 0 -> EBUSY or something and 1 -> 0 anyway, if we
check only for 1.

>> +
>> +for (i = 0; i < 16; i++) {
>> +stk11xx_write_reg(dev, 0x, 0x25);
>> +stk11xx_write_reg(dev, 0x, 0x24);
>> +stk11xx_read_reg(dev, 0x, );
>> +
>> +dev_dbg(>udev->dev, "Loop 1: Read 0x = %02x\n", value);
>> +}
>> +
>> +ret = stk11xx_process_table(dev, table_2);
>> +if (ret)
>> +goto end;
>> +
>> +for (i = 0; i < 16; i++) {
>> +stk11xx_write_reg(dev, 0x, 0x25);
>> +stk11xx_write_reg(dev, 0x, 0x24);
>> +stk11xx_read_reg(dev, 0x, );
>> +
>> +dev_dbg(>udev->dev, "Loop 2: Read 0x = %02x\n", value);
>> +}
>> +
>> +ret = stk11xx_process_table(dev, table_3);
>> +if (ret)
>> +goto end;
>> +
>> +for (i = 0; i < 16; i++) {
>> +stk11xx_write_reg(dev, 0x, 0x25);
>> +stk11xx_write_reg(dev, 0x, 0x24);
>> +stk11xx_read_reg(dev, 0x, );
>> +
>> +dev_dbg(>udev->dev, "Loop 3: Read 0x = %02x\n", value);
>> +}
> 
> Again, ARRAY_SIZE() would be clearer here.

No, this is only do this 16 times, no corresponding table :).

thanks for review,
-- 
Jiri Slaby ([EMAIL PROTECTED])
Faculty of Informatics, Masaryk University
-
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: CFS review

2007-08-27 Thread Al Boldi

Linus Torvalds wrote:
> On Tue, 28 Aug 2007, Al Boldi wrote:
> > No need for framebuffer.  All you need is X using the X.org vesa-driver.
> > Then start gears like this:
> >
> >   # gears & gears & gears &
> >
> > Then lay them out side by side to see the periodic stallings for ~10sec.
>
> I don't think this is a good test.
>
> Why?
>
> If you're not using direct rendering, what you have is the X server doing
> all the rendering, which in turn means that what you are testing is quite
> possibly not so much about the *kernel* scheduling, but about *X-server*
> scheduling!
>
> I'm sure the kernel scheduler has an impact, but what's more likely to be
> going on is that you're seeing effects that are indirect, and not
> necessarily at all even "good".
>
> For example, if the X server is the scheduling point, it's entirely
> possible that it ends up showing effects that are more due to the queueing
> of the X command stream than due to the scheduler - and that those
> stalls are simply due to *that*.
>
> One thing to try is to run the X connection in synchronous mode, which
> minimizes queueing issues. I don't know if gears has a flag to turn on
> synchronous X messaging, though. Many X programs take the "[+-]sync" flag
> to turn on synchronous mode, iirc.

I like your analysis, but how do you explain that these stalls vanish when 
__update_curr is disabled?


Thanks!

--
Al

-
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: oom-killer with 27G free swap and overcommit_memory=2

2007-08-27 Thread Al Boldi

Patrick J. LoPresti wrote:
> My system is a SunFire x4100 (x86_64) with 16G of RAM and 32G of swap
> in a single partition.  I have an application which consumes a lot of
> memory, and after a few hours the oom-killer kills it.
> 
> This would not be surprising, except a) the machine still has 27G of
> free swap at the time; and b) it happens even when I set
> vm.overcommit_memory=2 (with overcommit_ratio=50).  It is
> time-consuming to reproduce, but consistent.
:
:
> 2) Is there any sysctl setting that might "avoid" this problem?  Or a
> way to change my application to avoid it?

Try setting the overcommit_ratio=0.


Thanks!

--
Al

-
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: [pre-2.6.23 REGRESSION] 2.6.23-rc3-git1 crash/stuck on VIA CN700 system

2007-08-27 Thread Stefan Becker


Hi,

Stefan Becker wrote:


while trying to debug a hibernation/rtc_cmos alarm wakeup problem in 
2.6.22 (or later) I noticed that the latest kernel crashes (or gets 
stuck sometimes) during boot after the message:


SMP alternatives: switching to UP code


Retested with 2.6.23-rc3-git10. Same result :-/

Regards,

Stefan

---
Stefan Becker
E-Mail: [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: CFS review

2007-08-27 Thread Linus Torvalds

On Tue, 28 Aug 2007, Al Boldi wrote:
> 
> No need for framebuffer.  All you need is X using the X.org vesa-driver.  
> Then start gears like this:
> 
>   # gears & gears & gears &
> 
> Then lay them out side by side to see the periodic stallings for ~10sec.

I don't think this is a good test.

Why?

If you're not using direct rendering, what you have is the X server doing 
all the rendering, which in turn means that what you are testing is quite 
possibly not so much about the *kernel* scheduling, but about *X-server* 
scheduling!

I'm sure the kernel scheduler has an impact, but what's more likely to be 
going on is that you're seeing effects that are indirect, and not 
necessarily at all even "good".

For example, if the X server is the scheduling point, it's entirely 
possible that it ends up showing effects that are more due to the queueing 
of the X command stream than due to the scheduler - and that those 
stalls are simply due to *that*.

One thing to try is to run the X connection in synchronous mode, which 
minimizes queueing issues. I don't know if gears has a flag to turn on 
synchronous X messaging, though. Many X programs take the "[+-]sync" flag 
to turn on synchronous mode, iirc.

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/

[PATCH] Remove valueless definition of hard-selected RAMFS option.

2007-08-27 Thread Robert P. J. Day


Since CONFIG_RAMFS is currently hard-selected to "y", and since
Documentation/filesystems/ramfs-rootfs-initramfs.txt reads as follows:

"The amount of code required to implement ramfs is tiny, because all
the work is done by the existing Linux caching infrastructure.
Basically, you're mounting the disk cache as a filesystem.  Because of
this, ramfs is not an optional component removable via menuconfig,
since there would be negligible space savings."

it seems pointless to leave this as a Kconfig entry.

Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>

---

  this also allows almost 300 "CONFIG_RAMFS=y" lines to be dropped
from various defconfig files.  and that horribly misleading Kconfig
help text disappears as well.  :-)

  compile tested under i386.


 fs/Kconfig|   14 --
 fs/Makefile   |2 +-
 fs/ramfs/Makefile |2 +-
 3 files changed, 2 insertions(+), 16 deletions(-)


diff --git a/fs/Kconfig b/fs/Kconfig
index 58a0650..60d859b 100644
--- a/fs/Kconfig
+++ b/fs/Kconfig
@@ -1002,20 +1002,6 @@ config HUGETLBFS
 config HUGETLB_PAGE
def_bool HUGETLBFS

-config RAMFS
-   bool
-   default y
-   ---help---
- Ramfs is a file system which keeps all files in RAM. It allows
- read and write access.
-
- It is more of an programming example than a useable file system.  If
- you need a file system which lives in RAM with limit checking use
- tmpfs.
-
- To compile this as a module, choose M here: the module will be called
- ramfs.
-
 config CONFIGFS_FS
tristate "Userspace-driven configuration filesystem (EXPERIMENTAL)"
depends on SYSFS && EXPERIMENTAL
diff --git a/fs/Makefile b/fs/Makefile
index 720c29d..500cf15 100644
--- a/fs/Makefile
+++ b/fs/Makefile
@@ -72,7 +72,7 @@ obj-$(CONFIG_JBD) += jbd/
 obj-$(CONFIG_JBD2) += jbd2/
 obj-$(CONFIG_EXT2_FS)  += ext2/
 obj-$(CONFIG_CRAMFS)   += cramfs/
-obj-$(CONFIG_RAMFS)+= ramfs/
+obj-y  += ramfs/
 obj-$(CONFIG_HUGETLBFS)+= hugetlbfs/
 obj-$(CONFIG_CODA_FS)  += coda/
 obj-$(CONFIG_MINIX_FS) += minix/
diff --git a/fs/ramfs/Makefile b/fs/ramfs/Makefile
index 5a0236e..c71e65d 100644
--- a/fs/ramfs/Makefile
+++ b/fs/ramfs/Makefile
@@ -2,7 +2,7 @@
 # Makefile for the linux ramfs routines.
 #

-obj-$(CONFIG_RAMFS) += ramfs.o
+obj-y += ramfs.o

 file-mmu-y := file-nommu.o
 file-mmu-$(CONFIG_MMU) := file-mmu.o

-- 

Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://crashcourse.ca

-
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 v3 1/1] md: Software Raid autodetect dev list not array

2007-08-27 Thread Randy Dunlap


Michael J. Evans wrote:

On Monday 27 August 2007, Randy Dunlap wrote:

On Mon, 27 Aug 2007 15:16:21 -0700 Michael J. Evans wrote:


=
--- linux/drivers/md/md.c.orig  2007-08-21 03:19:42.511576248 -0700
+++ linux/drivers/md/md.c   2007-08-21 04:30:09.775525710 -0700
@@ -24,4 +24,6 @@

+   - autodetect dev list not array: Michael J. Evans 

<[EMAIL PROTECTED]>

+

Nowadays we use an SCM for such comments, not the source file(s).


SCM?  Is this automatic, where do I go to see it?


See Documentation/SubmittingPatches:
14) The canonical patch format:

The canonical patch message body contains the following:

 - A "from" line specifying the patch author.

 - An empty line.

 - The body of the explanation, which will be copied to the
   permanent changelog to describe this patch.

 - The "Signed-off-by:" lines, described above, which will
   also go in the changelog.

 - A marker line containing simply "---".

 - Any additional comments not suitable for the changelog.

 - The actual patch (diff output).


so just put whatever you want to be in the permanent SCM logs
into the "body of the explanation" part of the email.


--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your 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 v3 1/1] md: Software Raid autodetect dev list not array

2007-08-27 Thread Michael J. Evans

On Monday 27 August 2007, Randy Dunlap wrote:
> On Mon, 27 Aug 2007 15:16:21 -0700 Michael J. Evans wrote:
> 
> > =
> > --- linux/drivers/md/md.c.orig  2007-08-21 03:19:42.511576248 -0700
> > +++ linux/drivers/md/md.c   2007-08-21 04:30:09.775525710 -0700
> > @@ -24,4 +24,6 @@
> > 
> > +   - autodetect dev list not array: Michael J. Evans 
<[EMAIL PROTECTED]>
> > +
> 
> Nowadays we use an SCM for such comments, not the source file(s).

SCM?  Is this automatic, where do I go to see it?

> 
> > This program is free software; you can redistribute it and/or modify
> > it under the terms of the GNU General Public License as published by
> > the Free Software Foundation; either version 2, or (at your option)
> > @@ -5752,13 +5754,26 @@ void md_autodetect_dev(dev_t dev)
> >   * Searches all registered partitions for autorun RAID arrays
> >   * at boot time.
> >   */
> > -static dev_t detected_devices[128];
> > -static int dev_cnt;
> > +
> > +static LIST_HEAD(all_detected_devices);
> > +struct detected_devices_node {
> > +   struct list_head list;
> > +   dev_t dev;
> > +};
> >  
> >  void md_autodetect_dev(dev_t dev)
> >  {
> > -   if (dev_cnt >= 0 && dev_cnt < 127)
> > -   detected_devices[dev_cnt++] = dev;
> > +   struct detected_devices_node *node_detected_dev;
> > +   char strbuf[BDEVNAME_SIZE];
> > +
> > +   node_detected_dev = kzalloc(sizeof(*node_detected_dev), GFP_KERNEL);\
> 
> Drop the trailing '\', as someone has already commented on.
> 

I thought I had fixed that, I must have copied the unfixed version out of the 
way when I made the other changes to it.

> > +   if (node_detected_dev) {
> > +   node_detected_dev->dev = dev;
> > +   list_add_tail(_detected_dev->list, _detected_devices);
> > +   } else {
> > +   printk(KERN_CRIT "md: md_autodetect_dev: kzAlloc node failed"
> > +   " (null return), skipping dev(%d,%d)\n", MAJOR(dev), 
> > MINOR(dev));
> 
> printk() formatting is bad.
> Drop the " (null return)" and indent that line more than the
> printk line is indented.
> 
> > +   }
> >  }
> >  
> >  
> 
> ---
> ~Randy
> *** Remember to use Documentation/SubmitChecklist when testing your 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 v4 1/1] md: Software Raid autodetect dev list not array

2007-08-27 Thread Michael J. Evans

From: Michael J. Evans <[EMAIL PROTECTED]>

In current release kernels the md module (Software RAID) uses a static array
 (dev_t[128]) to store partition/device info temporarily for autostart.

This patch replaces that static array with a list.

Signed-off-by: Michael J. Evans <[EMAIL PROTECTED]>
--- 
Version 4:
Minor formatting cleanup for kzAlloc error message.
Should I remove the first patch section in version 5?

Version 3:
md_autodetect_dev failure message is now more usefully verbose.
removed unused i_found that was leftover from initial verification.
Thank you Randy Dunlap for pointing where INT_MAX was, fixme fixed.

Version 2:
using list_add_tail, and corrected missing i_passed++;.
removed sections of code that would never be reached.

Version 1:
The data/structures are only used within md.c, and very close together.
However I wonder if the structural information shouldn't go in to...
../../include/linux/raid/md_k.h instead.


I discovered this (and that the devices are added as disks/partitions are
discovered at boot) while I was debugging why only one of my MD arrays would
come up whole, while all the others were short a disk.

I eventually discovered that it was enumerating through all of 9 of my 11 hds
(2 had only 4 partitions apiece) while the other 9 have 15 partitions
(I wanted 64 per drive...). The last partition of the 8th drive in my 9 drive
raid 5 sets wasn't added, thus making the final md array short both a parity
and data disk, and it was started later, elsewhere.

Subject: [patch 1/1] md: Software Raid autodetect dev list not array

SOFTWARE RAID (Multiple Disks) SUPPORT
P:  Ingo Molnar
M:  [EMAIL PROTECTED]
P:  Neil Brown
M:  [EMAIL PROTECTED]
L:  [EMAIL PROTECTED]
S:  Supported
Unless you have a reason NOT to do so, CC [EMAIL PROTECTED]

12: Has been tested with CONFIG_PREEMPT, CONFIG_DEBUG_PREEMPT,
CONFIG_DEBUG_SLAB, CONFIG_DEBUG_PAGEALLOC, CONFIG_DEBUG_MUTEXES,
CONFIG_DEBUG_SPINLOCK, CONFIG_DEBUG_SPINLOCK_SLEEP all simultaneously
enabled.

It has been tested with CONFIG_SMP set and unset (Different x86_64 systems).
It has been tested with CONFIG_PREEMPT set and unset (same system).
CONFIG_LBD isn't even an option in my .config file.

Note: between 2.6.22 and 2.6.23-rc3-git5
rdev = md_import_device(dev,0, 0);
became
rdev = md_import_device(dev,0, 90);
So the patch has been edited to patch around that line.

Signed-off-by: Michael J. Evans <[EMAIL PROTECTED]>
=
--- linux/drivers/md/md.c.orig  2007-08-21 03:19:42.511576248 -0700
+++ linux/drivers/md/md.c   2007-08-21 04:30:09.775525710 -0700
@@ -24,4 +24,6 @@

+   - autodetect dev list not array: Michael J. Evans <[EMAIL PROTECTED]>
+
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2, or (at your option)
@@ -5752,13 +5754,26 @@ void md_autodetect_dev(dev_t dev)
  * Searches all registered partitions for autorun RAID arrays
  * at boot time.
  */
-static dev_t detected_devices[128];
-static int dev_cnt;
+
+static LIST_HEAD(all_detected_devices);
+struct detected_devices_node {
+   struct list_head list;
+   dev_t dev;
+};
 
 void md_autodetect_dev(dev_t dev)
 {
-   if (dev_cnt >= 0 && dev_cnt < 127)
-   detected_devices[dev_cnt++] = dev;
+   struct detected_devices_node *node_detected_dev;
+   char strbuf[BDEVNAME_SIZE];
+
+   node_detected_dev = kzalloc(sizeof(*node_detected_dev), GFP_KERNEL);
+   if (node_detected_dev) {
+   node_detected_dev->dev = dev;
+   list_add_tail(_detected_dev->list, _detected_devices);
+   } else {
+   printk(KERN_CRIT "md: md_autodetect_dev: kzAlloc node failed"
+   ", skipping dev(%d,%d)\n", MAJOR(dev), MINOR(dev));
+   }
 }
 
 
@@ -5765,7 +5760,12 @@ static void autostart_arrays(int part)
 static void autostart_arrays(int part)
 {
mdk_rdev_t *rdev;
-   int i;
+   struct detected_devices_node *node_detected_dev;
+   dev_t dev;
+   int i_scanned, i_passed;
+
+   i_scanned = 0;
+   i_passed = 0;
 
printk(KERN_INFO "md: Autodetecting RAID arrays.\n");
 
@@ -5772,3 +5792,7 @@ static void autostart_arrays(int part)
-   for (i = 0; i < dev_cnt; i++) {
-   dev_t dev = detected_devices[i];
-
+   while (!list_empty(_detected_devices) && i_scanned < INT_MAX) {
+   i_scanned++;
+   node_detected_dev = list_entry(all_detected_devices.next,
+   struct detected_devices_node, list);
+   list_del(_detected_dev->list);
+   dev = node_detected_dev->dev;
+   kfree(node_detected_dev);
@@ -5781,8 +5807,11 @@ static void autostart_arrays(int part)
continue;

Re: CFS review

2007-08-27 Thread Al Boldi

Ingo Molnar wrote:
> * Al Boldi <[EMAIL PROTECTED]> wrote:
> > > Could you try the patch below instead, does this make 3x glxgears
> > > smooth again? (if yes, could you send me your Signed-off-by line as
> > > well.)
> >
> > The task-startup stalling is still there for ~10sec.
> >
> > Can you see the problem on your machine?
>
> nope (i have no framebuffer setup)

No need for framebuffer.  All you need is X using the X.org vesa-driver.  
Then start gears like this:

  # gears & gears & gears &

Then lay them out side by side to see the periodic stallings for ~10sec.

> - but i can see some chew-max
> latencies that occur when new tasks are started up. I _think_ it's
> probably the same problem as yours.

chew-max is great, but it's too accurate in that it exposes any scheduling 
glitches and as such hides the startup glitch within the many glitches it 
exposes.  For example, it fluctuates all over the place using this:

  # for ((i=0;i<9;i++)); do chew-max 60 > /dev/shm/chew$i.log & done

Also, chew-max locks-up when disabling __update_curr, which means that the 
workload of chew-max is different from either the ping-startup loop or the 
gears.  You really should try the gears test by any means, as the problem is 
really pronounced there.

> could you try the patch below (which is the combo patch of my current
> queue), ontop of head 50c46637aa? This makes chew-max behave better
> during task mass-startup here.

Still no improvement.

Thanks!

--
Al

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

SIGNAL_STOP_DEQUEUED

2007-08-27 Thread Roland McGrath

> But SIGNAL_STOP_DEQUEUED code should be OK, afaics. We only need it to
> make sure do_signal_stop() can't miss SIGNAL_STOP_CONTINUED/GROUP_EXIT.
> 
> Can't we remove SIGNAL_STOP_DEQUEUED, btw?

No, we can't.

>   dequeue_signal:
> 
>   if (sig_kernel_stop(sig))
>   ->flags &= ~SIGNAL_STOP_CONTINUED;
> 
>   do_signal_stop:
> 
>   if (flags & (SIGNAL_STOP_CONTINUED | SIGNAL_GROUP_EXIT))
>   return 0;
> 
> Possible?

SIGNAL_STOP_CONTINUED exists to keep track of whether CLD_CONTINUED has
been reported to the parent's wait* call using the WCONTINUED flag.
wait_task_continued (kernel/exit.c) clears it.  It should only be cleared
by the signals code when a job control stop actually happens before a wait*
call clears it.  In dequeue_signal, you do not yet know whether it will
actually lead to a stop.

SIGNAL_STOP_DEQUEUED exists to fix a particular race, when we dequeue a
signal and then unlock the siglock before acting on it.  This happens when
we call is_current_pgrp_orphaned(), and there might be other cases that
arise.  In the window while we do not hold the lock, a kill or suchlike can
take the long to post a SIGCONT.  The generation of a SIGCONT must clear
all pending stop signals from all the queues.  But, the thread that
dequeued the signal and then released the lock effectively has that signal
still "pending" in its stack state, where it cannot be cleared.  So, when
clearing stop signals from queues, we also clear the SIGNAL_STOP_DEQUEUED
flag.  After retaking the siglock and considering the previously dequeued
stop signal, we check that SIGNAL_STOP_DEQUEUED is still set.  This way, if
the stop signal had a handler, it runs, the stop signal having been
considered logically delivered before the SIGCONT was generated.  The
SIGKILL/group-exit case has the same need, where rather than needing to
have stop signals cleared from queus, we need to make sure SIGKILL
overrides any stop in progress just as it would wake up the stopped thread
if it came after the race.


Thanks,
Roland
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [2.6.24 patch] the planned eepro100 removal

On Mon, Aug 27, 2007 at 02:58:05PM -0700, Kok, Auke wrote:
> Adrian Bunk wrote:
>...
>> This patch has been sent on:
>> - 14 Aug 2007
>> - 29 Jul 2007
>
> currently we won't have e100 fixed up for ARM in 2.6.23, so removing this 
> for 2.6.24 sounds a bit premature. Maybe 2.6.25. Can you 
> reschedule/postpone this?

OK, I'll resend it after 2.6.24-rc1.

> Auke

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-rc3-mm1: m32r defconfig compile error

2007-08-27 Thread Hirokazu Takata

From: Adrian Bunk <[EMAIL PROTECTED]>
Subject: 2.6.23-rc3-mm1: m32r defconfig compile error
Date: Mon, 27 Aug 2007 23:27:48 +0200
> On Wed, Aug 22, 2007 at 02:06:48AM -0700, Andrew Morton wrote:
> >...
> > Changes since 2.6.23-rc2-mm2:
> >...
> >  git-m32r.patch
> >...
> >  git trees
> >...
> 
> <--  snip  -->
> 
> ...
>   AS  arch/m32r/kernel/entry.o
> /home/bunk/linux/kernel-2.6/linux-2.6.23-rc3-mm1/arch/m32r/kernel/entry.S: 
> Assembler messages:
> /home/bunk/linux/kernel-2.6/linux-2.6.23-rc3-mm1/arch/m32r/kernel/entry.S:358:
>  Error: bad instruction `addi r0,#(0)+(64))+(32))+(32)))'
> make[2]: *** [arch/m32r/kernel/entry.o] Error 1
> 
> <--  snip  -->
> 
> cu
> Adrian
> 

Hello, Adrian,

Thank you for the report.


M32700UT/OPSPUT Users,

Please apply this patch to build an m32r 2.6.23-rc3-mm1 kernel.

This patch has also included to my m32r kernel development git repository.
 git://www.linux-m32r.org/git/takata/linux-2.6_dev.git linux-m32r

Thanks,

-- Takata


[PATCH 2.6.23-rc3-mm1] m32r: build fix of entry.S

This patch is required to fix build errors for the modification:
  m32r: Simplify ei_handler code
  commit f6c7546d53a4288501dcdd96d5297214697e7237

Signed-off-by: Hirokazu Takata <[EMAIL PROTECTED]>
---
 arch/m32r/kernel/entry.S |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/m32r/kernel/entry.S b/arch/m32r/kernel/entry.S
index c46cfaa..42b08bf 100644
--- a/arch/m32r/kernel/entry.S
+++ b/arch/m32r/kernel/entry.S
@@ -355,7 +355,7 @@ ENTRY(ei_handler)
lduhr0, @(low(M32R_INT0ICU_ISTS),r0); bit10-6 : ISN
sllir0, #21
srlir0, #27 ; ISN
-   addir0, #(M32R_INT0ICU_IRQ_BASE)
+   add3r0, r0, #(M32R_INT0ICU_IRQ_BASE)
bra check_end
.fillinsn
 4:
@@ -367,7 +367,7 @@ ENTRY(ei_handler)
lduhr0, @(low(M32R_INT2ICU_ISTS),r0); bit10-6 : ISN
sllir0, #21
srlir0, #27 ; ISN
-   addir0, #(M32R_INT2ICU_IRQ_BASE)
+   add3r0, r0, #(M32R_INT2ICU_IRQ_BASE)
; bra   check_end
.fillinsn
 5:
-- 
1.5.2.4

--
Hirokazu Takata <[EMAIL PROTECTED]>
Linux/M32R Project:  http://www.linux-m32r.org/
-
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.23-rc4

2007-08-27 Thread Linus Torvalds


Ok, I lost it, and let two weeks pass between -rc releases. My bad.

As a result, -rc4 is a bit bigger than it would/should have been, but 
hopefully it's all good, and we've fixed most regressions. There's some 
arch updates (MIPS, power, sparc64, s390) and an ACPI update, but the 
rest of it is mainly lots of small fixes (mostly to various random 
drivers). With some scheduler and networking noise.

I think the shortlog is _just_ too big to be posted on the kernel mailing 
list, but since it can mostly be described with the one word "boring", 
it's not a huge loss. As usual, just do

git shortlog v2.6.23-rc3..v2.6.23-rc4

if you have the git trees to get the all the details on extraneous 
semicolons, missed or duplicate include files, kzalloc conversions, new 
PCI ID's etc etc.

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: oom-killer with 27G free swap and overcommit_memory=2

2007-08-27 Thread Nick Piggin


Patrick J. LoPresti wrote:

I am using Linux 2.6.16.46-0.12-smp (SUSE 10 SP1 stock kernel).
I do intend to bother SUSE, but I am hoping some kind kernel savant
can help me interpret these log messages and/or give me some
suggestions for how to proceed.

My system is a SunFire x4100 (x86_64) with 16G of RAM and 32G of swap
in a single partition.  I have an application which consumes a lot of
memory, and after a few hours the oom-killer kills it.

This would not be surprising, except a) the machine still has 27G of
free swap at the time; and b) it happens even when I set
vm.overcommit_memory=2 (with overcommit_ratio=50).  It is
time-consuming to reproduce, but consistent.

Below is the first batch of messages from the oom-killer.  In this
case, overcommit_memory was set to 2, and the application
received no failures from malloc() or new.

9-10 more such batches appear in the log in rapid succession before
I get the "Kill process  ... Killed process " pair of messages.

Here are my questions.  I realize these log messages may be insufficient
to answer them, and I am ready to provide more information upon
request.  (Unfortunately I cannot provide the application itself.  But
I can perform tests and provide logs.)

1) Does this behavior definitely indicate a kernel bug?  If not, what
could my application possibly be doing to cause it?

2) Is there any sysctl setting that might "avoid" this problem?  Or a
way to change my application to avoid it?

3) Should I attempt to reproduce this problem on the stock kernel.org
kernel?


Hi,

Yeah it doesn't seem like the right behaviour. Your app isn't allocating
mlocked memory, is it? What is the value of your /proc/sys/vm/swappiness
sysctl? (increasing it may help).

I'll take a look at the SLES kernel and see whether we can do better
there. Thanks.

Nick

--
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] v1 of IBM power meter driver

2007-08-27 Thread Henrique de Moraes Holschuh

On Mon, 27 Aug 2007, Darrick J. Wong wrote:
> documentation doesn't mention any naming conventions for sensors that
> measure Watts, so I am proposing that they be called "powerX_input" in a
> fashion similar to temperature/rpm/current sensors.  If that is
> agreeable to everyone, I'll post a follow-up patch to amend the
> documentation.

What unit should we use? Watts are way, way too big as there is no
floating/fixed point in sysfs.  10^-6 W is probably what is called for,
since we already need 10^-3 V and 10^-3 A.  Small portable devices can
easily draw less than 10^-3 W nowadays.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
-
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 01/28] Fall back on interrupt disable in cmpxchg8b on 80386 and 80486

2007-08-27 Thread Nick Piggin


Mathieu Desnoyers wrote:


Q:
What's the reason to have cmpxchg64_local on 32 bit architectures?
Without that need all this would just be a few simple defines.

A:
cmpxchg64_local on 32 bits architectures takes unsigned long long
parameters, but cmpxchg_local only takes longs. Since we have cmpxchg8b
to execute a 8 byte cmpxchg atomically on pentium and +, it makes sense
to provide a flavor of cmpxchg and cmpxchg_local using this instruction.

Also, for 32 bits architectures lacking the 64 bits atomic cmpxchg, it
makes sense _not_ to define cmpxchg64 while cmpxchg could still be
available.

Moreover, the fallback for cmpxchg8b on i386 for 386 and 486 is a
different case than cmpxchg (which is only required for 386). Using
different code makes this easier.

However, cmpxchg64_local will be emulated by disabling interrupts on all
architectures where it is not supported atomically.

Therefore, we *could* turn cmpxchg64_local into a cmpxchg_local, but it
would make the 386/486 fallbacks ugly, make its design different from
cmpxchg/cmpxchg64 (which really depends on atomic operations and cannot
be emulated) and require the __cmpxchg_local to be expressed as a macro
rather than an inline function so the parameters would not be fixed to
unsigned long long in every case.

So I think cmpxchg64_local makes sense there, but I am open to
suggestions.


Every new thing like this (especially 64 bit operation on 32 bit
architectures) adds a tiny bit more burden for maintainers. Are
there any callers? If not, don't add it. It's simple to add if we
do get a good reason.

--
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 2/4] Fix mainline filesystems to handle ATTR_KILL_ bits correctly

2007-08-27 Thread Timothy Shimmin


Jeff Layton wrote:

On Tue, 21 Aug 2007 17:21:28 -0400
Josef Sipek <[EMAIL PROTECTED]> wrote:


On Tue, Aug 21, 2007 at 07:35:51AM -0400, Jeff Layton wrote:

On Tue, 21 Aug 2007 15:35:08 +1000
Timothy Shimmin <[EMAIL PROTECTED]> wrote:


Jeff Layton wrote:

This should fix all of the filesystems in the mainline kernels to handle
ATTR_KILL_SUID and ATTR_KILL_SGID correctly. For most of them, this is
just a matter of making sure that they call generic_attrkill early in
the setattr inode op.

Signed-off-by: Jeff Layton <[EMAIL PROTECTED]>
---
 fs/xfs/linux-2.6/xfs_iops.c   |5 -
--- a/fs/xfs/linux-2.6/xfs_iops.c
+++ b/fs/xfs/linux-2.6/xfs_iops.c
@@ -651,12 +651,15 @@ xfs_vn_setattr(
struct iattr*attr)
 {
struct inode*inode = dentry->d_inode;
-   unsigned intia_valid = attr->ia_valid;
+   unsigned intia_valid;
bhv_vnode_t *vp = vn_from_inode(inode);
bhv_vattr_t vattr = { 0 };
int flags = 0;
int error;
 
+	generic_attrkill(inode->i_mode, attr);

+   ia_valid = attr->ia_valid;
+
if (ia_valid & ATTR_UID) {
vattr.va_mask |= XFS_AT_UID;
vattr.va_uid = attr->ia_uid;

Looks reasonable to me for XFS.
Acked-by: Tim Shimmin <[EMAIL PROTECTED]>

So before, this clearing would happen directly in notify_change()
and now this won't happen until notify_change() calls i_op->setattr
which for a particular fs it can call generic_attrkill() to do it.
So I guess for the cases where i_op->setattr is called outside of
via notify_change, we don't normally have ATTR_KILL_SUID/SGID
set so that nothing will happen there?

Right. If neither ATTR_KILL bit is set then generic_attrkill is a
noop.


I guess just wondering the effect with having the code on all
setattr's. (I'm not familiar with the code path)


These bits are referenced in very few places in the current kernel
tree -- mostly in the VFS layer. The *only* place I see that they
actually get interpreted into a mode change is in notify_change. So
places that call setattr ops w/o going through notify_change are
not likely to have those bits set.

But hypothetically, if a fs did set ATTR_KILL_* and call setattr
directly, then the setattr would now include a mode change that
clears setuid or setgid bits where it may not have before.


I should probably clarify -- in the hypothetical situation above,
the setattr function would have to call generic_attrkill (as most
filesystems should do with this change).


Thanks for the confirmation. That's what it looked like to me
but I wanted to know explicitly what the thinking was.


It almost sounds like an argument for a new inode op (NULL would use
generic_attr_kill).



That's not a bad idea at all. I suppose that would be easier than
modifying every fs like this, and it does seem like it might be
cleaner. I need to mull it over, but that might be the best
solution.


Yeah, sounds a much more direct way of handling things and as you
say wouldn't need most of the filesystems to all be modified calling
generic_attrkill.
Not sure what the ramifications of adding a new iop are though.

Cheers,
Tim.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: NFS woes again

2007-08-27 Thread Florin Iucha

On Mon, Aug 27, 2007 at 06:19:29PM -0700, Bret Towe wrote:
> On 8/27/07, Trond Myklebust <[EMAIL PROTECTED]> wrote:
> > > > this sounds alot like the post i did yesterday titled 'nfs4 hang 
> > > > regression'
> > > > i tracked it down to commit 3d39c691ff486142dd9aaeac12f553f4476b7a6
> > >
> > > Yes, it certainly does -- all the symptoms match!
> >
> > Could you and Bret please check if the attached patch fixes the hang?
>
> no good for me still hangs after ~30minutes

I just booted into the new kernel
(3d39c691ff486142dd9aaeac12f553f4476b7a6 + Trond's patch) and it hangs
in 10-15 minutes.

Process traces available at http://iucha.net/nfs/23-rc2-nfs-fix-1/kernel.log.gz

Regards,
florin

-- 
Bruce Schneier expects the Spanish Inquisition.
  http://geekz.co.uk/schneierfacts/fact/163


signature.asc
Description: Digital signature

Re: [PATCH] SLUB use cmpxchg_local

Measurements on IA64 slub w/per cpu vs slub w/per cpu/cmpxchg_local 
emulation. Results are not good:

slub/per cpu
1 times kmalloc(8)/kfree -> 105 cycles
1 times kmalloc(16)/kfree -> 104 cycles
1 times kmalloc(32)/kfree -> 105 cycles
1 times kmalloc(64)/kfree -> 104 cycles
1 times kmalloc(128)/kfree -> 104 cycles
1 times kmalloc(256)/kfree -> 115 cycles
1 times kmalloc(512)/kfree -> 116 cycles
1 times kmalloc(1024)/kfree -> 115 cycles
1 times kmalloc(2048)/kfree -> 115 cycles
1 times kmalloc(4096)/kfree -> 115 cycles
1 times kmalloc(8192)/kfree -> 117 cycles
1 times kmalloc(16384)/kfree -> 439 cycles
1 times kmalloc(32768)/kfree -> 800 cycles


slub/per cpu + cmpxchg_local emulation
1 times kmalloc(8)/kfree -> 143 cycles
1 times kmalloc(16)/kfree -> 143 cycles
1 times kmalloc(32)/kfree -> 143 cycles
1 times kmalloc(64)/kfree -> 143 cycles
1 times kmalloc(128)/kfree -> 143 cycles
1 times kmalloc(256)/kfree -> 154 cycles
1 times kmalloc(512)/kfree -> 154 cycles
1 times kmalloc(1024)/kfree -> 154 cycles
1 times kmalloc(2048)/kfree -> 154 cycles
1 times kmalloc(4096)/kfree -> 155 cycles
1 times kmalloc(8192)/kfree -> 155 cycles
1 times kmalloc(16384)/kfree -> 440 cycles
1 times kmalloc(32768)/kfree -> 819 cycles
1 times kmalloc(65536)/kfree -> 902 cycles


Parallel allocs:

Kmalloc N*alloc N*free(16): 0=102/136 1=97/136 2=99/140 3=98/140 4=100/138 
5=99/139 6=100/139 7=101/141 Average=99/139

cmpxchg_local emulation
Kmalloc N*alloc N*free(16): 0=116/147 1=116/145 2=115/151 3=115/147 
4=115/149 5=117/147 6=116/148 7=116/146 Average=116/147

Patch used:

Index: linux-2.6/include/asm-ia64/atomic.h
===
--- linux-2.6.orig/include/asm-ia64/atomic.h2007-08-27 16:42:02.0 
-0700
+++ linux-2.6/include/asm-ia64/atomic.h 2007-08-27 17:50:24.0 -0700
@@ -223,4 +223,17 @@ atomic64_add_negative (__s64 i, atomic64
 #define smp_mb__after_atomic_inc() barrier()
 
 #include 
+
+static inline void *cmpxchg_local(void **p, void *old, void *new)
+{
+   unsigned long flags;
+   void *before;
+
+   local_irq_save(flags);
+   before = *p;
+   if (likely(before == old))
+   *p = new;
+   local_irq_restore(flags);
+   return before;
+}
 #endif /* _ASM_IA64_ATOMIC_H */

kmem_cache_alloc before

8900 :
8900:   01 28 31 0e 80 05   [MII]   alloc r37=ar.pfs,12,7,0
8906:   40 02 00 62 00 00   mov r36=b0
890c:   00 00 04 00 nop.i 0x0;;
8910:   0b 18 01 00 25 04   [MMI]   mov r35=psr;;
8916:   00 00 04 0e 00 00   rsm 0x4000
891c:   00 00 04 00 nop.i 0x0;;
8920:   08 50 90 1b 19 21   [MMI]   adds r10=3300,r13
8926:   70 02 80 00 42 40   mov r39=r32
892c:   05 00 c4 00 mov r42=b0
8930:   09 40 01 42 00 21   [MMI]   mov r40=r33
8936:   00 00 00 02 00 20   nop.m 0x0
893c:   f5 e7 ff 9f mov r41=-1;;
8940:   0b 48 00 14 10 10   [MMI]   ld4 r9=[r10];;
8946:   00 00 00 02 00 00   nop.m 0x0
894c:   01 48 58 00 sxt4 r8=r9;;
8950:   0b 18 20 40 12 20   [MMI]   shladd r3=r8,3,r32;;
8956:   20 80 0f 82 48 00   addl r2=8432,r3
895c:   00 00 04 00 nop.i 0x0;;
8960:   0a 00 01 04 18 10   [MMI]   ld8 r32=[r2];;
8966:   e0 a0 80 00 42 60   adds r14=20,r32
896c:   05 00 01 84 mov r43=r32
8970:   0b 10 01 40 18 10   [MMI]   ld8 r34=[r32];;
8976:   70 00 88 0c 72 00   cmp.eq p7,p6=0,r34
897c:   00 00 04 00 nop.i 0x0;;
8980:   cb 70 00 1c 10 90   [MMI] (p06) ld4 r14=[r14];;
8986:   e1 70 88 24 40 00 (p06) shladd r14=r14,3,r34
898c:   00 00 04 00 nop.i 0x0;;
8990:   c2 70 00 1c 18 10   [MII] (p06) ld8 r14=[r14]
8996:   00 00 00 02 00 00   nop.i 0x0;;
899c:   00 00 04 00 nop.i 0x0
89a0:   d8 00 38 40 98 11   [MMB] (p06) st8 [r32]=r14
89a6:   00 00 00 02 00 03   nop.m 0x0
89ac:   30 00 00 40   (p06) br.cond.sptk.few 89d0 

89b0:   11 00 00 00 01 00   [MIB]   nop.m 0x0
89b6:   00 00 00 02 00 00   nop.i 0x0
89bc:   18 d8 ff 58 br.call.sptk.many b0=61c0 
<__slab_alloc>;;
89c0:   08 10 01 10 00 21   [MMI]   mov r34=r8
89c6:   00 00 00 02 00 00   nop.m 0x0
89cc:

Re: [RFC][PATCH 0/2 -mm] kexec based hibernation

2007-08-27 Thread Huang, Ying

On Mon, 2007-08-27 at 13:15 +, Pavel Machek wrote:
> Hi!
> 
> > >> > Does this make sense?
> > >> 
> > >> Yes, this is a sensible optimization. But I think it may be better to
> > >> make bootloader load kernel D directly into a specified memory location.
> > >> For example, we can add a option to "kernel" command of grub. 
> > >> 
> > >> And, I think we can do more in bootloader. Such as we can prepare
> > >> two
> > >
> > > Yes, that would be nice.
> > >
> > > It will mean quite a bit of work, but I guess it should be the long
> > > term goal. Loading restore kernel directly from bootloader means:
> > >
> > > 1) it is fast -- no need to boot another kernel
> > >
> > > 2) it is "classical" way of doing things
> > >
> > > On the other hand, we loose flexibility that way:
> > >
> > > 1) it locks you onto one bootloader
> > >
> > > 2) you no longer have userland there to do uncompression, decryption,
> > > etc..
> > 
> > True although for the uncompression and decryption those aren't exactly 
> > foreign
> > requirements for bootloaders.
> 
> Well, uncompression yes, but crypto? What is that, some kind of
> trusted computing thingie?
> 
> We do RSA for uswsusp, that may be a bit of problem for a bootloader,
> but I'm glad bootloaders are bloated already :-).

As far as I know, the grub 2.0 uses a modular implementation scheme.
That is, every OS loader (Multi-boot, Linux, FreeBSD etc), partition
table, file system is implemented as a module, and these modules can be
statically linked into the final image.

So I think the hibernation image loading can be implemented in grub 2.0
in a manageable way. :)

Best Regards,
Huang Ying
-
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: NFS woes again Was: [linux-usb-devel] USB-related oops in sysfs with linux v2.6.23-rc3-50-g28e8351

2007-08-27 Thread Bret Towe

On 8/27/07, Trond Myklebust <[EMAIL PROTECTED]> wrote:
> On Thu, 2007-08-23 at 12:36 -0500, Florin Iucha wrote:
> > On Thu, Aug 23, 2007 at 10:14:38AM -0700, Bret Towe wrote:
> > > this sounds alot like the post i did yesterday titled 'nfs4 hang 
> > > regression'
> > > i tracked it down to commit 3d39c691ff486142dd9aaeac12f553f4476b7a6
> >
> > Yes, it certainly does -- all the symptoms match!
> >
> > I'm not [alone in] seeing dead keyboards!
> >
> > Now, if only somebody could clarify to me the connection between
> > the bad NFS4 shooting the keyboard but not the mouse, that would
> > be wonderful.
> >
> > florin
>
> Could you and Bret please check if the attached patch fixes the hang?

no good for me still hangs after ~30minutes

> Cheers
>   Trond
>
>
>
>
> -- Forwarded message --
> From: Trond Myklebust <[EMAIL PROTECTED]>
> To:
> Date: Mon, 27 Aug 2007 09:14:56 -0400
> Subject: No Subject
> We need to ensure that nobody adds anything to nfs_automount_list while we
> are killing off the work queue entry, or else nfs_expire_automounts will
> simply rearm it, and we hang.
>
> Signed-off-by: Trond Myklebust <[EMAIL PROTECTED]>
> ---
>
>  fs/nfs/namespace.c |   14 +-
>  1 files changed, 13 insertions(+), 1 deletions(-)
>
> diff --git a/fs/nfs/namespace.c b/fs/nfs/namespace.c
> index aea76d0..bcd0777 100644
> --- a/fs/nfs/namespace.c
> +++ b/fs/nfs/namespace.c
> @@ -22,6 +22,11 @@ static void nfs_expire_automounts(struct work_struct 
> *work);
>
>  LIST_HEAD(nfs_automount_list);
>  static DECLARE_DELAYED_WORK(nfs_automount_task, nfs_expire_automounts);
> +/*
> + * The following mutex prevents nfs_follow_mountpoint from adding new
> + * entries to nfs_automount_list
> + */
> +static DEFINE_MUTEX(nfs_automount_mutex);
>  int nfs_mountpoint_expiry_timeout = 500 * HZ;
>
>  static struct vfsmount *nfs_do_submount(const struct vfsmount *mnt_parent,
> @@ -128,18 +133,21 @@ static void * nfs_follow_mountpoint(struct dentry 
> *dentry, struct nameidata *nd)
> goto out_err;
>
> mntget(mnt);
> +   mutex_lock(_automount_mutex);
> err = do_add_mount(mnt, nd, nd->mnt->mnt_flags|MNT_SHRINKABLE, 
> _automount_list);
> if (err < 0) {
> +   mutex_unlock(_automount_mutex);
> mntput(mnt);
> if (err == -EBUSY)
> goto out_follow;
> goto out_err;
> }
> +   schedule_delayed_work(_automount_task, 
> nfs_mountpoint_expiry_timeout);
> +   mutex_unlock(_automount_mutex);
> mntput(nd->mnt);
> dput(nd->dentry);
> nd->mnt = mnt;
> nd->dentry = dget(mnt->mnt_root);
> -   schedule_delayed_work(_automount_task, 
> nfs_mountpoint_expiry_timeout);
>  out:
> dprintk("%s: done, returned %d\n", __FUNCTION__, err);
>
> @@ -175,8 +183,12 @@ static void nfs_expire_automounts(struct work_struct 
> *work)
>
>  void nfs_release_automount_timer(void)
>  {
> +   if (!list_empty(_automount_list))
> +   return;
> +   mutex_lock(_automount_mutex);
> if (list_empty(_automount_list))
> cancel_delayed_work_sync(_automount_task);
> +   mutex_unlock(_automount_mutex);
>  }
>
>  /*
>
>
-
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] Make rcutorture RNG use temporal entropy

2007-08-27 Thread Paul E. McKenney

On Thu, Aug 23, 2007 at 02:40:37PM -0500, Matt Mackall wrote:
> On Thu, Aug 23, 2007 at 11:58:31AM -0700, Paul E. McKenney wrote:
> > On Thu, Aug 23, 2007 at 01:06:58PM -0500, Matt Mackall wrote:
> > > On Fri, Aug 17, 2007 at 01:00:22PM -0700, Paul E. McKenney wrote:
> > > > On Fri, Aug 17, 2007 at 11:53:56AM -0700, Andrew Morton wrote:
> > > > > On Wed, 15 Aug 2007 19:49:04 -0700
> > > > > "Paul E. McKenney" <[EMAIL PROTECTED]> wrote:
> > > > > 
> > > > > > Repost of http://lkml.org/lkml/2007/8/10/472 made available by 
> > > > > > request.
> > > > > > 
> > > > > > The locking used by get_random_bytes() can conflict with the
> > > > > > preempt_disable() and synchronize_sched() form of RCU.  This patch 
> > > > > > changes
> > > > > > rcutorture's RNG to gather entropy from the new cpu_clock() 
> > > > > > interface
> > > > > > (relying on interrupts, preemption, daemons, and rcutorture's reader
> > > > > > thread's rock-bottom scheduling priority to provide useful entropy),
> > > > > > and also adds and EXPORT_SYMBOL_GPL() to make that interface 
> > > > > > available
> > > > > > to GPLed kernel modules such as rcutorture.
> > > > > > 
> > > > > > Passes several hours of rcutorture.
> > > > > 
> > > > > Please explain what "conflict with" means so that I can work out if
> > > > > this is a needed-in-2.6.23 change, thanks.
> > > > 
> > > > Not needed in 2.6.23.  This change falls into the "preparation for -rt"
> > > > category.  Also in the "don't unnecessarily eat entropy, leave some for
> > > > the people needing crypographically secure randomness" category.
> > > 
> > > We've had several calls for a more fast and loose version of
> > > get_random_bytes. Generalizing one of the cookie generation functions
> > > is probably a good way to go.
> > 
> > Are you thinking in terms of secure_tcp_syn_cookie(), or did you have
> > something else in mind?
> 
> Yes. Using a hash function rather than a trivial LFSR is preferable.
> But pulling the guts out and giving it an n-bytes interface like
> get_random_bytes().

OK.  But this cannot be the first discussion of getting a fast and loose
version of get_random_bytes() into the kernel.  Anyplace I should look
for cautionary tales?  A quick search located a spirited discussion of
proposed kernel infrastructure for user-mode random number generation
back in 2003, but...

Also a 2006 proposal from Stephan Eranian: http://lkml.org/lkml/2006/8/23/41
This appears to have gotten zero replies.  :-/  (Though not hash-based.)

Other semi-related threads:

http://lkml.org/lkml/2005/3/15/102
http://lkml.org/lkml/2004/9/23/337

Some years back, my reflexive design would have been per-CPU state,
accessed with interrupts disabled.  Not so good for realtime usage,
though.  One could go with per-task state in order to avoid the
interrupt disabling, which might be OK if the state is quite small.

Thanx, 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: [RFC][PATCH 2/2 -mm] kexec based hibernation: kexec restore

2007-08-27 Thread Huang, Ying

On Mon, 2007-08-27 at 23:31 +0200, Pavel Machek wrote:
> Hi!
> 
> > This patch adds writing support for /dev/oldmem. This is used to
> > restore the memory contents of hibernated system.
> > 
> > Signed-off-by: Huang Ying <[EMAIL PROTECTED]>
> 
> > +ssize_t write_oldmem_page(unsigned long pfn, const char *buf,
> > + size_t csize, unsigned long offset, int userbuf)
> 
> Hmm, int userbuf is only ever set to one... Does it make sense to have
> write_oldmem_page in the separate file? The onl user is mem.c, perhaps
> it should go there?
> 

write_oldmem_page is kept to be consistent with copy_oldmem_page as much
as possible. The userbuf is used by copy_oldmem_page too, and
write_oldmem_page is in the same file as copy_oldmem_page. I think the
consistence between them is reasonable.

And the copy_oldmem_page/write_oldmem_page is considered to be
architecture dependent. Now, there are different implementations for
copy_oldmem_page on different architectures. So I think the
copy_oldmem_page/write_oldmem_page should be kept in separate file
instead of go mem.c.

Best Regards,
Huang Ying
-
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] trivial - convert "for(foo=0;foo

2007-08-27 Thread Joe Perches

On Mon, 2007-08-27 at 17:12 -0700, Andrew Morton wrote:
> Right now, pretty much every instance of NR_CPUS in the tree is a flag
> which says "old, krufty, fixme".

I thought of that when I changed them.

Perhaps the new for_each_possible_cpu code can
now be more easily inspected/transformed by the
appropriate parties to for_each_(online|present)_cpu.

cheers, Joe

-
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] trivial - convert "for(foo=0;foo

2007-08-27 Thread Michal Piotrowski

Hi Joe,

On 28/08/07, Joe Perches <[EMAIL PROTECTED]> wrote:
> Done via grep/sed and compile tested i386 with xen
>
> Changed the foo++ and ++foo forms
[snip]
> There are 3 more lines that could be modified:
>
> arch/powerpc/sysdev/mpic.c: for (i = 0; i < NR_CPUS; ++i, cpumask >>= 1)

for_each_possible_cpu(i) {
[..]
cpumask >>= 1;
}

> arch/sparc/kernel/smp.c:for (cpu = 0, num = 0; cpu < NR_CPUS; cpu++)

num = 0;
for_each_possible_cpu(cpu) {
[..]
}

> arch/sparc64/kernel/smp.c:  for (i = 0; i < NR_CPUS; i++, ptr += size)

for_each_possible_cpu(i) {
[..]
ptr += size;
}

BTW1. There is a huge difference between pre and post incrementation -
have you checked all cases?

BTW2. Could you convert each i -> cpu?

Regards,
Michal

-- 
LOG
http://www.stardust.webpages.pl/log/
-
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] trivial - convert "for(foo=0;foo

On Mon, 27 Aug 2007 16:54:47 -0700
Joe Perches <[EMAIL PROTECTED]> wrote:

> Done via grep/sed and compile tested i386 with xen
> 
> Changed the foo++ and ++foo forms
> 
> $ egrep -r -l 
> "for[[:space:]]*\([[:space:]]*([A-Za-z0-9_]+)[[:space:]]*=[[:space:]]*0[[:space:]]*;[[:space:]]*\1[[:space:]]*<[[:space:]]*NR_CPUS[[:space:]]*;[[:space:]]*\1\+\+[[:space:]]*[[:space:]]*\)"
>  * | xargs sed -i -r -e 
> "s/for[[:space:]]*\([[:space:]]*([A-Za-z0-9_]+)[[:space:]]*=[[:space:]]*0[[:space:]]*;[[:space:]]*\1[[:space:]]*<[[:space:]]*NR_CPUS[[:space:]]*;[[:space:]]*\1[[:space:]]*\+\+[[:space:]]*\)/for_each_possible_cpu\(\1\)/g"
> $ egrep -r -l 
> "for[[:space:]]*\([[:space:]]*([A-Za-z0-9_]+)[[:space:]]*=[[:space:]]*0[[:space:]]*;[[:space:]]*\1[[:space:]]*<[[:space:]]*NR_CPUS[[:space:]]*;[[:space:]]*\+\+[[:space:]]*\1[[:space:]]*\)"
>  * | xargs sed -i -r -e 
> "s/for[[:space:]]*\([[:space:]]*([A-Za-z0-9_]+)[[:space:]]*=[[:space:]]*0[[:space:]]*;[[:space:]]*\1[[:space:]]*<[[:space:]]*NR_CPUS[[:space:]]*;[[:space:]]*\+\+[[:space:]]*\1[[:space:]]*\)/for_each_possible_cpu\(\1\)/g"

No, each of these sites needs careful attention.

- Can we reduce the amount of memory which is being used?  Because
  hweight(num_possible_cpus) <= hweight(NR_CPUS)

- Do we _really_ need to be iterating across all possible CPUS?  Or
  should we really have been using for_each_online_cpu() or
  for_each_present_cpu()?

See, many of these sites will be old code which predates cpu hotplug and
the more advanced cpu masks.  We shouldn't just blindly go and pretend that
these sites have been modernised when they haven't.

Right now, pretty much every instance of NR_CPUS in the tree is a flag
which says "old, krufty, fixme".   Let's not hide that please. 
-
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 find out how many other processes share VM with $PID?

2007-08-27 Thread Fengguang Wu

On Mon, Aug 27, 2007 at 02:26:50PM +0100, Denys Vlasenko wrote:
> On Monday 27 August 2007 13:13, Fengguang Wu wrote:
> > Hi Denys,
> >
> > On Mon, Aug 27, 2007 at 12:56:31PM +0100, Denys Vlasenko wrote:
> > > Hi,
> > >
> > > I was a bit frustrated by bad quality of memory usage info
> > > from top and ps, and decided to write my own utility.
> > >
> > > One problem I don't know how to solve is how to avoid counting
> > > twice (or more) memory used by processes which share VM
> > > (by use of CLONE_VM flage to sys_clone).
> > >
> > > I know how to detect and correctly account for threads
> > > (processes created with CLONE_THREAD), but how to detect non-threads
> > > with shared VM?
> >
> > There is a nice LWN article on this issue:
> > ELC: How much memory are applications really using?
> > http://lwn.net/Articles/230975/
> >
> > Another helpful patch could be:
> > maps: PSS(proportional set size) accounting in smaps
> > http://lkml.org/lkml/2007/8/19/23
> 
> Thanks a lot, very useful pages indeed.
> 
> However they still don't explain how I can avoid counting memory
> twice for /proc/PID1 and /proc/PID2 when PID2 is a child of PID1,
> created with CLONE_VM.
> 
> The example: I allocate 1234k, dirty it, then clone with CLONE_VM.
> I will seemingly have two processes, each using 1234k, _privately_
> (i.e., pages are not shown as shared in smaps) -
> which is technically correct, pages are not shared with other VMs,
> but they ARE shared by means of these two processes having the same VM!
> 
> How userspace tools can figure out that these processes have shared VM?
> 
> IOW: do we need "VMsharecount: N" in addition to "Threads: N"
> in /proc/PID/status?

A full solution would require two parameters, i.e. VmUsers/VmMagic.

But please make sure the new lines won't break important tools like
ps/top/pmaps/...

A quick test shows that only ps will parse /proc//status:

strace -e open ps
strace -e open top
strace -e open pmap $$

-
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] trivial - convert "for(foo=0;foo

2007-08-27 Thread Joe Perches

Done via grep/sed and compile tested i386 with xen

Changed the foo++ and ++foo forms

$ egrep -r -l 
"for[[:space:]]*\([[:space:]]*([A-Za-z0-9_]+)[[:space:]]*=[[:space:]]*0[[:space:]]*;[[:space:]]*\1[[:space:]]*<[[:space:]]*NR_CPUS[[:space:]]*;[[:space:]]*\1\+\+[[:space:]]*[[:space:]]*\)"
 * | xargs sed -i -r -e 
"s/for[[:space:]]*\([[:space:]]*([A-Za-z0-9_]+)[[:space:]]*=[[:space:]]*0[[:space:]]*;[[:space:]]*\1[[:space:]]*<[[:space:]]*NR_CPUS[[:space:]]*;[[:space:]]*\1[[:space:]]*\+\+[[:space:]]*\)/for_each_possible_cpu\(\1\)/g"
$ egrep -r -l 
"for[[:space:]]*\([[:space:]]*([A-Za-z0-9_]+)[[:space:]]*=[[:space:]]*0[[:space:]]*;[[:space:]]*\1[[:space:]]*<[[:space:]]*NR_CPUS[[:space:]]*;[[:space:]]*\+\+[[:space:]]*\1[[:space:]]*\)"
 * | xargs sed -i -r -e 
"s/for[[:space:]]*\([[:space:]]*([A-Za-z0-9_]+)[[:space:]]*=[[:space:]]*0[[:space:]]*;[[:space:]]*\1[[:space:]]*<[[:space:]]*NR_CPUS[[:space:]]*;[[:space:]]*\+\+[[:space:]]*\1[[:space:]]*\)/for_each_possible_cpu\(\1\)/g"

There are 3 more lines that could be modified:

arch/powerpc/sysdev/mpic.c: for (i = 0; i < NR_CPUS; ++i, cpumask >>= 1)
arch/sparc/kernel/smp.c:for (cpu = 0, num = 0; cpu < NR_CPUS; cpu++)
arch/sparc64/kernel/smp.c:  for (i = 0; i < NR_CPUS; i++, ptr += size)

Also available for git pull:

git pull git://repo.or.cz/linux-2.6/trivial-mods.git for_each_possible_cpu

Signed-off-by: Joe Perches <[EMAIL PROTECTED]>

--

 arch/alpha/kernel/core_t2.c|2 +-
 arch/alpha/kernel/smp.c|   10 +-
 arch/cris/arch-v32/kernel/irq.c|2 +-
 arch/i386/kernel/smp.c |2 +-
 arch/i386/kernel/smpboot.c |4 ++--
 arch/i386/mach-voyager/voyager_smp.c   |   10 +-
 arch/i386/xen/smp.c|6 +++---
 arch/ia64/kernel/mca.c |4 ++--
 arch/ia64/kernel/numa.c|4 ++--
 arch/ia64/kernel/perfmon.c |4 ++--
 arch/ia64/kernel/salinfo.c |2 +-
 arch/ia64/kernel/smpboot.c |2 +-
 arch/ia64/mm/contig.c  |2 +-
 arch/ia64/mm/discontig.c   |8 
 arch/ia64/sn/kernel/setup.c|2 +-
 arch/m32r/kernel/smpboot.c |6 +++---
 arch/mips/kernel/gdb-stub.c|2 +-
 arch/mips/kernel/setup.c   |2 +-
 arch/mips/kernel/smtc-proc.c   |6 +++---
 arch/mips/kernel/smtc.c|   12 ++--
 arch/mips/sibyte/bcm1480/irq.c |2 +-
 arch/mips/sibyte/sb1250/irq.c  |2 +-
 arch/powerpc/kernel/machine_kexec_64.c |2 +-
 arch/powerpc/mm/numa.c |2 +-
 arch/powerpc/platforms/iseries/dt.c|2 +-
 arch/powerpc/xmon/xmon.c   |2 +-
 arch/ppc/syslib/open_pic.c |2 +-
 arch/ppc/xmon/xmon.c   |2 +-
 arch/sparc/kernel/sun4d_smp.c  |4 ++--
 arch/sparc/kernel/sun4m_smp.c  |2 +-
 arch/sparc64/kernel/traps.c|2 +-
 arch/x86_64/kernel/apic.c  |2 +-
 arch/x86_64/kernel/head64.c|2 +-
 arch/x86_64/kernel/nmi.c   |2 +-
 arch/x86_64/mm/numa.c  |6 +++---
 arch/x86_64/mm/srat.c  |2 +-
 drivers/acpi/processor_core.c  |2 +-
 drivers/acpi/processor_thermal.c   |2 +-
 drivers/cpufreq/cpufreq.c  |2 +-
 drivers/infiniband/hw/ehca/ehca_irq.c  |2 +-
 drivers/pnp/pnpbios/bioscalls.c|2 +-
 include/asm-ia64/smp.h |2 +-
 kernel/module.c|4 ++--
 mm/page_alloc.c|2 +-
 net/core/dev.c |4 ++--
 45 files changed, 76 insertions(+), 76 deletions(-)

diff --git a/arch/alpha/kernel/core_t2.c b/arch/alpha/kernel/core_t2.c
index f5ca525..99ad08b 100644
--- a/arch/alpha/kernel/core_t2.c
+++ b/arch/alpha/kernel/core_t2.c
@@ -413,7 +413,7 @@ t2_init_arch(void)
unsigned long temp;
unsigned int i;
 
-   for (i = 0; i < NR_CPUS; i++) {
+   for_each_possible_cpu(i) {
mcheck_expected(i) = 0;
mcheck_taken(i) = 0;
}
diff --git a/arch/alpha/kernel/smp.c b/arch/alpha/kernel/smp.c
index ad17644..be95c1b 100644
--- a/arch/alpha/kernel/smp.c
+++ b/arch/alpha/kernel/smp.c
@@ -247,7 +247,7 @@ recv_secondary_console_msg(void)
 
mycpu = hard_smp_processor_id();
 
-   for (i = 0; i < NR_CPUS; i++) {
+   for_each_possible_cpu(i) {
if (!(txrdy & (1UL << i)))
continue;
 
@@ -502,7 +502,7 @@ smp_cpus_done(unsigned int max_cpus)
int cpu;
unsigned long bogosum = 0;
 
-   for(cpu = 0; cpu < NR_CPUS; cpu++) 
+   for_each_possible_cpu(cpu) 
if (cpu_online(cpu))
bogosum += cpu_data[cpu].loops_per_jiffy;

@@ -854,7 +854,7 @@ flush_tlb_mm(struct mm_struct *mm)

Re: [patch 0/6] Per cpu structures for SLUB

On Mon, 27 Aug 2007 11:50:10 -0700 (PDT)
Christoph Lameter <[EMAIL PROTECTED]> wrote:

> On Fri, 24 Aug 2007, Andrew Morton wrote:
> 
> > I'm struggling a bit to understand these numbers.  Bigger is better, I
> > assume?  In what units are these numbers?
> 
> No less is better. These are cycle counts. Hmmm... We discussed these 
> cycle counts so much in the last week that I forgot to mention that.
> 
> > > Page allocator pass through
> > > ---
> > > There is a significant difference in the columns marked with a * because
> > > of the way that allocations for page sized objects are handled.
> > 
> > OK, but what happened to the third pair of columns (Concurrent Alloc,
> > Kmalloc) for 1024 and 2048-byte allocations?  They seem to have become
> > significantly slower?
> 
> There is a significant performance increase there. That is the main point 
> of the patch.
> 
> > Thanks for running the numbers, but it's still a bit hard to work out
> > whether these changes are an aggregate benefit?
> 
> There is a drawback because of the additional code introduced in the fast 
> path. However, the regular kmalloc case shows improvements throughout. 
> This is in particular of importance for SMP systems. We see an improvement 
> even for 2 processors.

umm, OK.  When you have time, could you please whizz up a clearer
changelog for this 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 08/15] knfsd: spawn kernel thread to probe callback channel

2007-08-27 Thread J. Bruce Fields

On Tue, Aug 28, 2007 at 09:26:36AM +1000, Neil Brown wrote:
> On Monday August 27, [EMAIL PROTECTED] wrote:
> >  
> > +/* Reference counting, callback cleanup, etc., all look racy as heck.
> > + * And why is cb_set an atomic? */
> 
> Agreed so do we really want this code in mainline?  is the old
> code so bad that this is better?

The code in question is just moved, not rewritten, so those are
preexisting problems that I was just adding a whiny comment about in
hopes it would remind me some more patches were probably needed.
(Thanks for the reminder)

>  - cb_set should not be atomic.
>  - This looks like a job for async-rpc rather than a kernel thread

The problem isn't the wait for the rpc itself, it's the creation of the
new cred that's needed in the gss case.  That could also be made
asynchronous, but as there's several other delicate changes in the
pipeline (keyring stuff, etc.), I'd rather not touch it for now.

>  - If you do use a thread, you at least want __module_get before
>starting the thread, and module_put_and_exit to terminate the
>thread.
>  - Can you just use 'cb_client' rather than cb_set?  If you move
>rpc_create into the thread, you don't need to set cb_client until
>the callback is successful.  Then add a 'cb_active' flag bit
>so that you don't have two callbacks at the same time, and it
>should be less racy..

Yep, probably so.

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

[ANNOUNCE] util-linux-ng 2.13 (stable)

2007-08-27 Thread Karel Zak


The stable util-linux-ng 2.13 release is available at:

ftp://ftp.kernel.org/pub/linux/utils/util-linux-ng/

A few numbers:
- 8 months (grr...)
- 368 patches (wow...)
- 35 contributors (thanks...!)

Feedback and bug reports, as always, are welcomed.

Karel



Util-linux-ng 2.13 Release Notes  (28-Aug-2007)
===

Release highlights:
--

 mount(8) doesn't include NFS client code anymore. Don't forget to
 install nfs-utils 1.1.0 or newer with /sbin/[u]mount.{nfs,nfs4}.

 mount(8) doesn't include filesystem detection code anymore. You
 have to compile --with-fsprobe={blkid,volume_id}, and libblkid
 (e2fsprogs) or libvolume_id (udev >= v110) is required.

 mount(8) supports new relatime, context, fscontext, and defcontext
 mount options.

 losetup(8) supports command line option "-a" to list all used loop
 devices, '-s' to print a device name if "-f" and a file argument
 are present, and "-r" to create a read-only loop device.

 fdisk(8) Sun label support has been improved. fdisk(8) is also able
 to warn about detected GPT (fdisk doesn't support GPT).

 taskset(1) is independent on hardcoded NR_CPUS. chrt(1) supports
 SCHED_BATCH scheduling policy.

 The package build system is now based on autotools. The build system
 supports  separate CFLAGS and LDFLAGS for suid programs (SUID_CFLAGS,
 SUID_LDFLAGS). For more details see the README file

 hwclock(8) supports command line option --rtc= and /dev/rtc0
 device. --systohc functionality has been improved, and it doesn't cause
 a 500ms inaccuracy each time it is used.

 Audit system support (--with-audit) has been added to hwclock(8) and
 login(1).

 SELinux support (--with-selinux) has been added to mkswap(8) and
 mount(8).

 setarch(8) upstream has been merged with util-linux-ng.

 rtcwake(8) command has been added to util-linux-ng.

 arch(1) is deprecated in favor of "uname -m" or arch(1) from coreutils
 (>= 6.9+). The util-linux-ng package doesn't build arch by default,
 you have to use the option --enable-arch.


Fixed security issues:
-

 CVE-2007-0822 - mount(8) allows local users to trigger a NULL
 dereference and an application crash
 CVE-2006-7108 - login(1) omits PAM account validation when auth is
 skipped


Changelog:
-

 For more details see ChangeLog files at:
 ftp://ftp.kernel.org/pub/linux/utils/util-linux-ng/v2.13/


agetty:
   - 8 bit characters on the Linux console lead to input corruption  [Samuel 
Thibault]
   - add 'O' escape code to display domain name  [Karel Zak]
   - check gethostname() return value  [Karel Zak]
   - fix short malloc in initstring handling  [LaMont Jones]
blockdev:
   - add BLKFRAGET/BLKFRASET ioctls  [Karel Zak]
   - cleanup usage() and update man page  [Karel Zak]
   - fix "blockdev --getsz" for large devices  [Karel Zak]
   - use LU and LLU for BLKGETSIZE and BLKGETSIZE64  [Karel Zak]
build-sys:
   - add ${AC,AP,AM,AH}_OPTS to autogen.sh  [Karel Zak]
   - add AC_GNU_SOURCE  [Karel Zak]
   - add Automake option dist-bzip2  [Stepan Kasal]
   - add --disable-makeinstall-chown  [Karel Zak]
   - add missing files  [Karel Zak]
   - add SUID_CFLAGS  [Karel Zak]
   - add SUID_LDFLAGS  [Stepan Kasal]
   - add support for audit  [Karel Zak]
   - add warning when libuuid is not found  [Karel Zak]
   - amend .gitignore  [Stepan Kasal]
   - call automake after autoconf  [Stepan Kasal]
   - cleanup architecture conditionals  [Karel Zak]
   - cleanup sys-utils/ rdev symlinks  [Karel Zak]
   - configure.am selinux support cleanup  [Karel Zak]
   - declare SUID_CFLAGS and SUID_LDFLAGS as precious  [Stepan Kasal]
   - do not build convenience libraries in lib/  [Stepan Kasal]
   - do not kick off AM_CFLAGS by SUID_CFLAGS  [Stepan Kasal]
   - do not play with DEFS, use AM_CPPFLAGS  [Stepan Kasal]
   - do not set with_foo twice  [Stepan Kasal]
   - do not use internal Autoconf variables  [Stepan Kasal]
   - do not use wildcards in EXTRA_DIST  [Stepan Kasal]
   - factor out common parts from mount/Makefile.am  [Stepan Kasal]
   - fix directories in EXTRA_DIST  [Karel Zak]
   - fix HAVE_NCURSES  [Karel Zak]
   - fix ifdef ENABLE_WIDECHAR usage  [Karel Zak]
   - fix linking when ncurses is built with --with-termlib=tinfo  [Arkadiusz 
Miskiewicz]
   - fix README filenames and add missing files to EXTRA_DISTs  [Karel Zak]
   - fix the example configure call in README  [Stepan Kasal]
   - fix the final message of autogen.sh  [Stepan Kasal]
   - in configure.ac, change "po" -> "$srcdir/po"  [Stepan Kasal]
   - in the clean targets use "find ... | xargs rm -f"  [Stepan Kasal]
   - let configure instantiate the misc-utils/*.pl scripts  [Stepan Kasal]
   - make the getopt example directory relative to datadir  [Stepan Kasal]
   - merge adjacent AC_CONFIG_HEADERS and AC_CONFIG_FUNCS calls  [Stepan Kasal]
   - minor fixes in configure.in  [Karel Zak]
   - missing header when NLS is disabled  [Gabriel Barazer]

Re: [RFC] block_device_operations prototype changes

2007-08-27 Thread Neil Brown

On Monday August 27, [EMAIL PROTECTED] wrote:
>   * a bug (AFAICT) in md.c - we open raid components r/w and if it
> fails, it fails.  Good for our purposes, but... how about raid0 on read-only
> devices?  In any case, we have a ready place to store mode_t, so it's not a
> problem for getting the right value to blkdev_put().  FWIW, I think that
> allowing fallback to r/o (and making the entire array r/o, of course) would
> be a good thing to have.  Any comments from drivers/md folks?

I've never heard any suggestion of anybody wanting to include a
readonly device in an md array -  I guess one could imagine an array
of CDROMs, but I doubt anyone would actually create one.
However I agree that falling back to read-only (particular if the
error value indicated that this was the only problem) would be a
sensible thing to do in some circumstances.

More interestingly:  one could argue that when the md array is
switched to read-only, each component device should be reopened as
read-only.  So I would really like the interface to have a way to
switch a device between read-only and read-write without closing and
re-opening.

Though I guess opening and then closing as you suggest below would be OK.

>   * open_bdev_excl()/close_bdev_excl().  Needs an extra argument for
> the latter.  Two interesting callers:
>   * kill_block_super() - need to store relevant mode_t in superblock,
> along with reference to bdev.  Note that just looking at sb->s_flags is *not*
> enough - some filesystems go read-only on errors and that changes ->s_flags.
> Another side of that is explicit remount from r/o to r/w and there we have
> a bug - we do _not_ tell the driver that something had happened.  Proper
> fix is simple enough - bdget() + blkdev_get() for write + blkdev_put() with
> old mode_t (i.e. FMODE_READ) once we are done remounting (and similar for
> explicit remount to r/o).

I would *really* like to see this.  When the root filesystem gets
mounted read-only, I want md to know so that it can mark the array as
'clean' straight away.  I really don't like having a reboot-notifier
to mark all arrays as 'clean' on shutdown.

So each device would be responsible for keeping a count of 'readonly'
and 'read-write' accesses?  Or would that be in common code?

I look forward to this all getting cleaned up!

NeilBrown
-
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 08/15] knfsd: spawn kernel thread to probe callback channel

2007-08-27 Thread Neil Brown

On Monday August 27, [EMAIL PROTECTED] wrote:
>  
> +/* Reference counting, callback cleanup, etc., all look racy as heck.
> + * And why is cb_set an atomic? */

Agreed so do we really want this code in mainline?  is the old
code so bad that this is better?

 - cb_set should not be atomic.
 - This looks like a job for async-rpc rather than a kernel thread
 - If you do use a thread, you at least want __module_get before
   starting the thread, and module_put_and_exit to terminate the
   thread.
 - Can you just use 'cb_client' rather than cb_set?  If you move
   rpc_create into the thread, you don't need to set cb_client until
   the callback is successful.  Then add a 'cb_active' flag bit
   so that you don't have two callbacks at the same time, and it
   should be less racy..


The other 14 patches all look ok.

Thanks,
NeilBrown
-
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] Fix tiny compiler warning in smount example program from Documentation/sharedsubtree.txt

2007-08-27 Thread Jesper Juhl


Hi,

If one compiles the example smount program, found in 
Documentation/sharedsubtree.txt, with -Wall then there's a small 
compiler warning rearing its ugly head : 

 smount.c: In function 'main':
 smount.c:45: warning: implicit declaration of function 'strcmp'

Easily fixed by just including string.h


Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---

 Documentation/sharedsubtree.txt |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/Documentation/sharedsubtree.txt b/Documentation/sharedsubtree.txt
index ccf1ceb..7365400 100644
--- a/Documentation/sharedsubtree.txt
+++ b/Documentation/sharedsubtree.txt
@@ -153,6 +153,7 @@ replicas continue to be exactly same.
#include 
#include 
#include 
+   #include 
#include 
#include 
 


-
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: [-mm patch] unexport sys_{open,read}

On Mon, Aug 27, 2007 at 03:53:02PM -0700, Arjan van de Ven wrote:
> On Mon, 27 Aug 2007 23:27:23 +0200
> Adrian Bunk <[EMAIL PROTECTED]> wrote:
> 
> > On Wed, Aug 22, 2007 at 02:06:48AM -0700, Andrew Morton wrote:
> > >...
> > > Changes since 2.6.23-rc2-mm2:
> > >...
> > >  git-alsa.patch
> > >...
> > >  git trees
> > >...
> > 
> > sys_{open,read} can finally be unexported.
> > 
> 
> isn't sys_close in the same boat?

Still used in fs/binfmt_misc.c ...

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-
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-cifs-client] Re: BUG: scheduling while atomic - linux 2.6.22

2007-08-27 Thread Michael Deegan

Hi,

On Tue Aug 7 16:00:19 GMT 2007, Martin Koegler  wrote:
> A vanilla 2.6.22 kernel (SMP PREEMPT i686) produced the following messages, 
> while working with a CIFS mount point:
> 
> Aug  7 16:12:30 localhost kernel: BUG: scheduling while atomic: 
> bash/0x0001/5868
> Aug  7 16:12:30 localhost kernel:  [schedule+1312/2250] schedule+0x520/0x8ca
> Aug  7 16:12:30 localhost kernel:  [__switch_to+157/410] 
> __switch_to+0x9d/0x19a
> Aug  7 16:12:30 localhost kernel:  [kernel_sendmsg+39/53] 
> kernel_sendmsg+0x27/0x35
> Aug  7 16:12:30 localhost kernel:  [] wait_for_response+0xca/0x134 
> [cifs]
> Aug  7 16:12:30 localhost kernel:  [autoremove_wake_function+0/53] 
> autoremove_wake_function+0x0/0x35
> Aug  7 16:12:30 localhost kernel:  [] SendReceive+0x12b/0x457 [cifs]
> Aug  7 16:12:30 localhost kernel:  [] CIFSSMBOpen+0x109/0x2c2 [cifs]
> Aug  7 16:12:30 localhost kernel:  [] cifs_reopen_file+0x123/0x3d0 
> [cifs]
> Aug  7 16:12:30 localhost kernel:  [] find_writable_file+0x7b/0xdb 
> [cifs]
> Aug  7 16:12:30 localhost kernel:  [] 
> is_size_safe_to_change+0x18/0x7a [cifs]
> Aug  7 16:12:30 localhost kernel:  [] cifs_readdir+0x1118/0x167f 
> [cifs]
> Aug  7 16:12:30 localhost kernel:  [filldir64+0/197] filldir64+0x0/0xc5
> Aug  7 16:12:30 localhost kernel:  [filldir64+0/197] filldir64+0x0/0xc5
> Aug  7 16:12:30 localhost kernel:  [vfs_readdir+124/145] vfs_readdir+0x7c/0x91
> Aug  7 16:12:30 localhost kernel:  [sys_getdents64+99/165] 
> sys_getdents64+0x63/0xa5
> Aug  7 16:12:30 localhost kernel:  [syscall_call+7/11] syscall_call+0x7/0xb
> Aug  7 16:12:30 localhost kernel:  [netlbl_unlabel_list+143/479] 
> netlbl_unlabel_list+0x8f/0x1df
> Aug  7 16:12:30 localhost kernel:  ===
> Aug  7 16:13:03 localhost kernel:  CIFS VFS: Send error in Close = -9

FWIW, I saw something very similar:

Aug 27 22:33:08 wibble kernel: BUG: scheduling while atomic: 
bash/0x0001/4077
Aug 27 22:33:08 wibble kernel:
Aug 27 22:33:08 wibble kernel: Call Trace:
Aug 27 22:33:08 wibble kernel:  [] 
__sched_text_start+0x5f/0x79b
Aug 27 22:33:08 wibble kernel:  [] kernel_sendmsg+0x2c/0x3e
Aug 27 22:33:08 wibble kernel:  [] 
wait_for_response+0xbe/0x155
Aug 27 22:33:08 wibble kernel:  [] 
autoremove_wake_function+0x0/0x2e
Aug 27 22:33:08 wibble kernel:  [] SendReceive+0x1fb/0x3f8
Aug 27 22:33:08 wibble kernel:  [] CIFSSMBOpen+0x1c6/0x27a
Aug 27 22:33:08 wibble kernel:  [] 
cifs_reopen_file+0x1ea/0x356
Aug 27 22:33:08 wibble kernel:  [] 
find_writable_file+0x84/0xe7
Aug 27 22:33:08 wibble kernel:  [] 
is_size_safe_to_change+0x16/0x4e
Aug 27 22:33:08 wibble kernel:  [] fill_in_inode+0x270/0x4ec
Aug 27 22:33:08 wibble kernel:  [] cifs_readdir+0xe24/0x1071
Aug 27 22:33:08 wibble kernel:  [] filldir64+0x0/0xb8
Aug 27 22:33:08 wibble kernel:  [] do_page_fault+0x40b/0x74a
Aug 27 22:33:08 wibble kernel:  [] 
__mutex_lock_slowpath+0x234/0x23f
Aug 27 22:33:08 wibble kernel:  [] filldir64+0x0/0xb8
Aug 27 22:33:08 wibble kernel:  [] vfs_readdir+0x5d/0x92
Aug 27 22:33:08 wibble kernel:  [] sys_getdents64+0x75/0xba
Aug 27 22:33:08 wibble kernel:  [] error_exit+0x0/0x84
Aug 27 22:33:08 wibble kernel:  [] system_call+0x7e/0x83
Aug 27 22:33:08 wibble kernel:

I'm using a 2.6.22.1 kernel (with SMP and PREEMPT, including BKL) on Debian
etch AMD64, and Samba 3.0.24-6etch4.

(please CC replies)

-MD

-- 
---
Michael Deegan   Hugaholic  http://wibble.darktech.org/gallery/
- Nyy Tybel Gb Gur Ulcabgbnq! -
-
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: nmi_watchdog=2 regression in 2.6.21

2007-08-27 Thread Daniel Walker

On Mon, 2007-08-27 at 15:55 -0700, Stephane Eranian wrote:

> Yet the model name looks strange. So we need to run one more test,
> as the fam/model is not enough. What we need to check is whether or
> not this processor implements architectural perfmon or not.
> 
> Could you please compile and run the attached program and send me 
> the output?

The output below is all the output ..

eax=0x7280201: version=1  num_cnt=2

Daniel

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] clean up exports in fs/{open,read_write}.c

On Fri, Aug 24, 2007 at 11:33:10AM +0800, Eugene Teo wrote:
> Takashi-san fixed sound/isa/wavefront/wavefront_synth.c to use
> request_firmware instead of sys_*. Since that is the last driver in the
> kernel that uses sys_{read,close}, this patch kills these exports. sys_open
> is left exported for sparc64 only.
>...

fs/binfmt_misc.c still uses sys_close.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-
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] block_device_operations prototype changes

2007-08-27 Thread Alasdair G Kergon

On Mon, Aug 27, 2007 at 11:30:53AM +0100, Al Viro wrote:
> 3) ->ioctl().  What a mess...  

Yup.

See also:
  Subject: [PATCH] dm: support ioctls on mapped devices: fix with fake file
  http://uwsg.indiana.edu/hypermail/linux/kernel/0606.2/2979.html

and related threads.

> First of all, we have 3 methods with different
> calling conventions:
>   ->ioctl(inode, file, cmd, arg)
>   ->unlocked_ioctl(inode, file, cmd, arg)

When I last looked it was:
  long (*unlocked_ioctl) (struct file *, unsigned int, unsigned long);
with the lack of inode forcing dm to use ->ioctl (because file can be NULL when
only the block device is known) and immediately drop the pointless-for-us
lock!

Alasdair
-- 
[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: nmi_watchdog=2 regression in 2.6.21

2007-08-27 Thread Stephane Eranian

Daniel,

On Mon, Aug 27, 2007 at 10:55:31AM -0700, Daniel Walker wrote:

> Here is the cpuinfo for processor 0 .. It's got four cores so this isn't
> the full /proc/cpuinfo output ..
> 

> processor   : 0
> vendor_id   : GenuineIntel 
> cpu family  : 6
> model   : 14

The looks like a Core Duo. If that is really the case,
then commit e82f64e5bb0648a13630d752c35be1e7bd8bab96 from Bjorn
should fix your problem. I have it is my 2.6.23-rc3 tree.


> model name  : Intel(R) Dual Pentium(R) M CPU@ 2.00GHz

Yet the model name looks strange. So we need to run one more test,
as the fam/model is not enough. What we need to check is whether or
not this processor implements architectural perfmon or not.

Could you please compile and run the attached program and send me 
the output?

Thanks.

> 

-- 

-Stephane
#include 
#include 
#include 
#include 

typedef struct {
unsigned int version:8;
unsigned int num_cnt:8;
unsigned int cnt_width:8;
unsigned int ebx_length:8;
} pmu_eax_t;

static inline void cpuid(unsigned int op, unsigned int *eax, unsigned int *ebx, 
unsigned int *ecx, unsigned int *edx)
{
__asm__("cpuid"
: "=a" (*eax),
"=b" (*ebx),
"=c" (*ecx),
"=d" (*edx)
: "0" (op), "c"(0));
}

int main(void)
{
unsigned int ecx, ebx, edx;
union {
unsigned int val;
pmu_eax_t eax;
} eax;

cpuid(0, , , , );
if (eax.val < 0xa) {
printf("does not support architected PMU\n");
return 0;
}
cpuid(0xa, , , , );

printf("eax=0x%lx: version=%d  num_cnt=%d\n",
   eax.val,
   eax.eax.version,
   eax.eax.num_cnt);
return 0;
}

RE: [PATCH] mptsas: scan the logical volume at first

2007-08-27 Thread Moore, Eric

On Monday, August 27, 2007 4:52 PM,  Yinghai Lu wrote:
> Yes, I was wondering why kernel.org mainline will have 
> /dev/sdb for first raid. but it seems RHEL 5 kernel have 
> first raid before second raid...( it 
> after all left over raw devices..), maybe they already aplied 
> some patch?
> 
> can you send out patch?
> 

That is not necessary, as we have already implemented the change to sort
volumes in acsending order to Red hat and Suse, and its been accepted.
I will post the change to lsml.

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: [PATCH] clean up exports in fs/{open,read_write}.c

2007-08-27 Thread Arjan van de Ven


Christoph Hellwig wrote:

On Fri, Aug 24, 2007 at 11:33:10AM +0800, Eugene Teo wrote:

Takashi-san fixed sound/isa/wavefront/wavefront_synth.c to use
request_firmware instead of sys_*. Since that is the last driver in the
kernel that uses sys_{read,close}, this patch kills these exports. sys_open
is left exported for sparc64 only.


I can't find any spar user of it, so please kill it.  


it's in the solaris compat code which is modular



In the case a symbol
is needed only for a particular architecture it's better to do it in the
architecture-specific ksyms file than with an ifdef, btw.


agreed.
(well if it's only 1 or 2, if it's "half of them" it's obviously a 
different story)

-
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: [-mm patch] unexport sys_{open,read}

2007-08-27 Thread Arjan van de Ven

On Mon, 27 Aug 2007 23:27:23 +0200
Adrian Bunk <[EMAIL PROTECTED]> wrote:

> On Wed, Aug 22, 2007 at 02:06:48AM -0700, Andrew Morton wrote:
> >...
> > Changes since 2.6.23-rc2-mm2:
> >...
> >  git-alsa.patch
> >...
> >  git trees
> >...
> 
> sys_{open,read} can finally be unexported.
> 

isn't sys_close in the same boat?
-
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] mptsas: scan the logical volume at first

2007-08-27 Thread Yinghai Lu

Moore, Eric wrote:

On Monday, August 27, 2007 11:58 AM, Yinghai Lu wrote:

[PATCH] mptsas: scan the logical volume at first

user like to see the raid show as /dev/sda before left raw disks.
So scan the volume at first to make their life easier.

Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>

Although I agree with the patch, there are people on this list that will
reject it due to the fact distro's ship today having udev label and
device id mapping, so device ordering should be an non-issue. However

even so, user still can customize it to use /dev/sdaX as root instead of use
/dev/scsi/by-id/...or LABEL=/ as root.

there are systems that ship that don't have BIOS BBS support, allowing
you to select the boot device. Without it BBS support, you are forced to
boot to the lowest device id. There are HP and Dell systems like that.
Are SUN systems like that? If so, there is an additional patch which I
have yet posted that will sort the raid volumes in acsending order.
Currently they are in descending order (due to Firmware putting them in
that order), which if you did a install to what you think is /dev/sda,
its really the highest target id, and when you reboot, the BIOS will
boot to the lowest id, which is /dev/sdb, and it will not find the boot
partition.
Yes, I was wondering why kernel.org mainline will have /dev/sdb for first raid. but it seems RHEL 5 kernel have first raid before second raid...( it
after all left over raw devices..), maybe they already aplied some patch?

can you send out patch?

Thanks

Yinghai Lu
-
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: Problems with IDE on linux 2.6.22.X

2007-08-27 Thread José Luis Patiño Andrés

El Miércoles, 22 de Agosto de 2007 16:54, Rene Herman escribió:
> José: do you have SCSI CD-ROM support compiled in? What are the ATA/SCSI
> related messages in the output of "dmesg" when you compile with the
> CONFIG_ATA_PIIX driver, SCSI disk and SCSI CD-ROM support (and nothing from
> the old IDE menu)?
>
> Rene.

Hi again. I'm very sorry for the delay. I was on a travel since wednesday 22.

Okay Rene, I activated SCSI CD-ROM support in kernel config and now all works 
again. It's strange, because I never used this option to get my DVD device 
on.

Well, sorry for the inconvenience. Thanks for your help.
-
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: [-mm patch] make "struct menu_governor" static (again)

2007-08-27 Thread Adam Belay

This is already fixed in the most recent ACPI CPUIDLE tree.

Thanks,
Adam

On Mon, 2007-08-27 at 23:27 +0200, Adrian Bunk wrote:
> On Wed, Aug 22, 2007 at 02:06:48AM -0700, Andrew Morton wrote:
> >...
> > Changes since 2.6.23-rc2-mm2:
> >...
> >  git-acpi.patch
> >...
> >  git trees
> >...
> 
> "struct menu_governor" needlessly again became global.
> 
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
> 
> ---
> cb33b296204127cf50df54b84b2d79e152fb924b 
> diff --git a/drivers/cpuidle/governors/menu.c 
> b/drivers/cpuidle/governors/menu.c
> index f5a8865..8d3fdc5 100644
> --- a/drivers/cpuidle/governors/menu.c
> +++ b/drivers/cpuidle/governors/menu.c
> @@ -117,7 +117,7 @@ static int menu_enable_device(struct cpuidle_device *dev)
>   return 0;
>  }
>  
> -struct cpuidle_governor menu_governor = {
> +static struct cpuidle_governor menu_governor = {
>   .name = "menu",
>   .rating =   20,
>   .enable =   menu_enable_device,
> 

-
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 1/1] V4L: stk11xx, add a new webcam driver

On Sun, 26 Aug 2007 07:09:02 -0700
Jiri Slaby <[EMAIL PROTECTED]> wrote:

> Hi,
> 
> is it possible to have this driver in the -mm tree for testing purposes until
> v4l library will be developped and image resize with bayer->rgb conversion
> will be moved there? (Then, I'll push it through v4l people.)
> 
> --
> stk11xx, add a new webcam driver
> 
> Adds support for stk1125, stk1135 and stkdcnew webcam built-in some
> notebooks.
> 
> ...
>
> --- /dev/null
> +++ b/drivers/media/video/stk1125.c
> @@ -0,0 +1,667 @@
> +/*
> + * STK-1125 part
> + *
> + * Copyright (c) 2007 Jiri Slaby <[EMAIL PROTECTED]>
> + *
> + * Based on Nicolas VIVIEN's driver
> + *
> + * Licences
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + */
> +
> +#include 
> +#include 
> +
> +#include "stk11xx.h"
> +
> +static int stk1125_load_microcode(struct stk11xx *dev)
> +{
> + unsigned int i;
> + const u8 *values_204, *values_205;
> + int retok;
> +
> + /* From 80x60 to 640x480 */
> + const u8 values_1_204[] = {
> + 0x12, 0x11, 0x3b, 0x6a, 0x13, 0x10, 0x00, 0x01, 0x02, 0x13,
> + 0x39, 0x38, 0x37, 0x35, 0x0e, 0x12, 0x04, 0x0c, 0x0d, 0x17,
> + 0x18, 0x32, 0x19, 0x1a, 0x03, 0x1b, 0x16, 0x33, 0x34, 0x41,
> + 0x96, 0x3d, 0x69, 0x3a, 0x8e, 0x3c, 0x8f, 0x8b, 0x8c, 0x94,
> + 0x95, 0x40, 0x29, 0x0f, 0xa5, 0x1e, 0xa9, 0xaa, 0xab, 0x90,
> + 0x91, 0x9f, 0xa0, 0x24, 0x25, 0x26, 0x14, 0x2a, 0x2b
> + };
> + const u8 values_1_205[] = {
> + 0x45, 0x80, 0x01, 0x7d, 0x80, 0x00, 0x00, 0x80, 0x80, 0x80,
> + 0x50, 0x93, 0x00, 0x81, 0x20, 0x45, 0x00, 0x00, 0x00, 0x24,
> + 0xc4, 0xb6, 0x00, 0x3c, 0x36, 0x00, 0x07, 0xe2, 0xbf, 0x00,
> + 0x04, 0x19, 0x40, 0x0d, 0x00, 0x73, 0xdf, 0x06, 0x20, 0x88,
> + 0x88, 0xc1, 0x3f, 0x42, 0x80, 0x04, 0xb8, 0x92, 0x0a, 0x00,
> + 0x00, 0x00, 0x00, 0x68, 0x5c, 0xc3, 0x2e, 0x00, 0x00
> + };
> +
> + /* From 800x600 to 1280x1024 */
> + const u8 values_2_204[] = {
> + 0x12, 0x11, 0x3b, 0x6a, 0x13, 0x10, 0x00, 0x01, 0x02, 0x13,
> + 0x39, 0x38, 0x37, 0x35, 0x0e, 0x12, 0x04, 0x0c, 0x0d, 0x17,
> + 0x18, 0x32, 0x19, 0x1a, 0x03, 0x1b, 0x16, 0x33, 0x34, 0x41,
> + 0x96, 0x3d, 0x69, 0x3a, 0x8e, 0x3c, 0x8f, 0x8b, 0x8c, 0x94,
> + 0x95, 0x40, 0x29, 0x0f, 0xa5, 0x1e, 0xa9, 0xaa, 0xab, 0x90,
> + 0x91, 0x9f, 0xa0, 0x24, 0x25, 0x26, 0x14, 0x2a, 0x2b
> + };
> + const u8 values_2_205[] = {
> + 0x05, 0x80, 0x01, 0x7d, 0x80, 0x00, 0x00, 0x80, 0x80, 0x80,
> + 0x50, 0x93, 0x00, 0x81, 0x20, 0x05, 0x00, 0x00, 0x00, 0x1b,
> + 0xbb, 0xa4, 0x01, 0x81, 0x12, 0x00, 0x07, 0xe2, 0xbf, 0x00,
> + 0x04, 0x19, 0x40, 0x0d, 0x00, 0x73, 0xdf, 0x06, 0x20, 0x88,
> + 0x88, 0xc1, 0x3f, 0x42, 0x80, 0x04, 0xb8, 0x92, 0x0a, 0x00,
> + 0x00, 0x00, 0x00, 0x68, 0x5c, 0xc3, 0x2e, 0x00, 0x00
> + };

hm, OK, it seems that even though we've asked the compiler to build these
arrays on the stack at runtime it will, as an optimisation, create static
storage for them due to the `const'.  I don't know that the compielr _has_
to do that, nor do I know if all versions of gcc and other compilers will
also do this.

Perhaps it would be safer to put the `static' in there?  There are many
such sites.


> + /* From the resolution */
> + switch (dev->resolution) {
> + case STK11XX_1280x1024:
> + case STK11XX_1024x768:
> + case STK11XX_800x600:
> + values_204 = values_2_204;
> + values_205 = values_2_205;
> + break;
> +
> + case STK11XX_640x480:
> + case STK11XX_320x240:
> + case STK11XX_160x120:
> + case STK11XX_80x60:
> + default:
> + values_204 = values_1_204;
> + values_205 = values_1_205;
> + break;
> + }
> +
> + for (i = 0; i < 59; i++) {

ARRAY_SIZE would be nice, if only for clarity..

+   retok = stk11xx_check_device(dev, 500);
+   if (retok != 1) {
+   dev_err(>udev->dev, "load microcode fail\n");
+   return -EIO;
+   }

Normally we'd use a return value of zero to indicate success.  So that the
negative return value can tell people _why_ it failed.

> +
> + for (i = 0; i < 16; i++) {
> + stk11xx_write_reg(dev, 0x, 0x25);
> + stk11xx_write_reg(dev, 0x, 0x24);
> + stk11xx_read_reg(dev, 0x, );
> +
> + dev_dbg(>udev->dev, "Loop 1: Read 0x = %02x\n", value);
> + }
> +
> + ret = stk11xx_process_table(dev, table_2);
> + if (ret)
> + goto end;
> +
> + for

Re: [-mm patch] iwl-base.c bugfixes

2007-08-27 Thread Tomas Winkler

On 8/28/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> On Wed, Aug 22, 2007 at 02:06:48AM -0700, Andrew Morton wrote:
> >...
> > Changes since 2.6.23-rc2-mm2:
> >...
> >  git-wireless.patch
> >...
> >  git trees
> >...
>
> This patch fixes two obvious bugs.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
>
> ---
>
>  drivers/net/wireless/iwl-base.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> 600ffdc11b25ac0aee15271d1b2ce99a367efa31
> diff --git a/drivers/net/wireless/iwl-base.c b/drivers/net/wireless/iwl-base.c
> index b8293fe..f65c30e 100644
> --- a/drivers/net/wireless/iwl-base.c
> +++ b/drivers/net/wireless/iwl-base.c
> @@ -343,7 +343,7 @@ int iwl_tx_queue_init(struct iwl_priv *priv,
>  * command is very huge the system will not have two scan at the
>  * same time */
> len = sizeof(struct iwl_cmd) * slots_num;
> -   if (txq_id == IWL_CMD_QUEUE_NUM);
> +   if (txq_id == IWL_CMD_QUEUE_NUM)
> len +=  IWL_MAX_SCAN_SIZE;
> txq->cmd = pci_alloc_consistent(dev, len, >dma_addr_cmd);
> if (!txq->cmd)
> @@ -390,7 +390,7 @@ void iwl_tx_queue_free(struct iwl_priv *priv, struct 
> iwl_tx_queue *txq)
> iwl_hw_txq_free_tfd(priv, txq);
>
> len = sizeof(struct iwl_cmd) * q->n_window;
> -   if (q->id == IWL_CMD_QUEUE_NUM);
> +   if (q->id == IWL_CMD_QUEUE_NUM)
> len += IWL_MAX_SCAN_SIZE;
>
> pci_free_consistent(dev, len, txq->cmd, txq->dma_addr_cmd);
>
>
Shame on me.
Thanks
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch v3 1/1] md: Software Raid autodetect dev list not array

2007-08-27 Thread Randy Dunlap

On Mon, 27 Aug 2007 15:16:21 -0700 Michael J. Evans wrote:

> Note: between 2.6.22 and 2.6.23-rc3-git5
> rdev = md_import_device(dev,0, 0);
> became
> rdev = md_import_device(dev,0, 90);
> So the patch has been edited to patch around that line. (might be fuzzy)

so you should update the patch to the latest mainline.

It's up to the (RAID) maintainer(s) if they want to merge a patch with fuzz.
Andrew may fix it up.  Linus wouldn't accept it with fuzz.

> Signed-off-by: Michael J. Evans <[EMAIL PROTECTED]>
> =
> --- linux/drivers/md/md.c.orig2007-08-21 03:19:42.511576248 -0700
> +++ linux/drivers/md/md.c 2007-08-21 04:30:09.775525710 -0700
> @@ -24,4 +24,6 @@
> 
> +   - autodetect dev list not array: Michael J. Evans <[EMAIL PROTECTED]>
> +

Nowadays we use an SCM for such comments, not the source file(s).

> This program is free software; you can redistribute it and/or modify
> it under the terms of the GNU General Public License as published by
> the Free Software Foundation; either version 2, or (at your option)
> @@ -5752,13 +5754,26 @@ void md_autodetect_dev(dev_t dev)
>   * Searches all registered partitions for autorun RAID arrays
>   * at boot time.
>   */
> -static dev_t detected_devices[128];
> -static int dev_cnt;
> +
> +static LIST_HEAD(all_detected_devices);
> +struct detected_devices_node {
> + struct list_head list;
> + dev_t dev;
> +};
>  
>  void md_autodetect_dev(dev_t dev)
>  {
> - if (dev_cnt >= 0 && dev_cnt < 127)
> - detected_devices[dev_cnt++] = dev;
> + struct detected_devices_node *node_detected_dev;
> + char strbuf[BDEVNAME_SIZE];
> +
> + node_detected_dev = kzalloc(sizeof(*node_detected_dev), GFP_KERNEL);\

Drop the trailing '\', as someone has already commented on.

> + if (node_detected_dev) {
> + node_detected_dev->dev = dev;
> + list_add_tail(_detected_dev->list, _detected_devices);
> + } else {
> + printk(KERN_CRIT "md: md_autodetect_dev: kzAlloc node failed"
> + " (null return), skipping dev(%d,%d)\n", MAJOR(dev), 
> MINOR(dev));

printk() formatting is bad.
Drop the " (null return)" and indent that line more than the
printk line is indented.

> + }
>  }
>  
>  

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your 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] SLUB use cmpxchg_local

On Mon, 27 Aug 2007, Mathieu Desnoyers wrote:

> Hrm, I just want to certify one thing: A lot of code paths seems to go
> to the slow path without requiring cmpxchg_local to execute at all. So
> is the slow path more likely to be triggered by the (!object),
> (!node_match) tests or by these same tests done in the redo after the
> initial cmpxchg_local ?

The slow path is more likely to be triggered by settings in the per cpu 
structure. The cmpxchg failure is comparatively rare. So the worst case
is getting worse but the average use of interrupt enable/disable may not 
change much. Need to have some measurements to confirm that. I can try to 
run the emulation on IA64 and see what the result will be.

-
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] SLUB use cmpxchg_local

2007-08-27 Thread Mathieu Desnoyers

* Christoph Lameter ([EMAIL PROTECTED]) wrote:
> On Mon, 27 Aug 2007, Mathieu Desnoyers wrote:
> 
> > > The slow path would require disable preemption and two interrupt disables.
> > If the slow path have to call new_slab, then yes. But it seems that not
> > every slow path must call it, so for the other slow paths, only one
> > interrupt disable would be required.
> 
> If we include new_slab then we get to 3 times:
> 
> 1. In the cmpxchg_local emulation that fails
> 
> 2. For the slow path
> 
> 3. When calling the page allocator.
> 

Hrm, I just want to certify one thing: A lot of code paths seems to go
to the slow path without requiring cmpxchg_local to execute at all. So
is the slow path more likely to be triggered by the (!object),
(!node_match) tests or by these same tests done in the redo after the
initial cmpxchg_local ?

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
-
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] mptsas: scan the logical volume at first

2007-08-27 Thread Moore, Eric

On Monday, August 27, 2007 11:58 AM,  Yinghai Lu wrote:
> 
> [PATCH] mptsas: scan the logical volume at first
> 
> user like to see the raid show as /dev/sda before left raw disks.
> So scan the volume at first to make their life easier.
> 
> Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
> 

Although I agree with the patch, there are people on this list that will
reject it due to the fact distro's ship today having udev label and
device id mapping, so device ordering should be an non-issue.  However
there are systems that ship that don't have BIOS BBS support, allowing
you to select the boot device. Without it BBS support, you are forced to
boot to the lowest device id.  There are HP and Dell systems like that.
Are SUN systems like that?   If so, there is an additional patch which I
have yet posted that will sort the raid volumes in acsending order.
Currently they are in descending order (due to Firmware putting them in
that order), which if you did a install to what you think is /dev/sda,
its really the highest target id, and when you reboot, the BIOS will
boot to the lowest id, which is /dev/sdb, and it will not find the boot
partition.

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: [PATCH 0/3] pci: let devices flush DMA to host memory

2007-08-27 Thread akepner

On Mon, Aug 27, 2007 at 04:05:48PM -0600, Grant Grundler wrote:

> .
> After reading the thread, my take is we need a more elegant way for a
> device driver to handle registration of DMA regions allocated by user
> space. The API would "make this page/region act like dma_alloc_coherent()".
> That implies strong ordering between CPU and DMA to/from the device.
> Maybe the code is the right thing and I want a name that makes
> sense in the context of current DMA API.

Need to think about this...

> 
> On IRC, willy suggested an mmap() flag and that sounds reasonable too
> though I don't know if it's feasible. 
> 

Yeah, we're doing something like this now as a band-aid solution. 
Not a flag to mmap(), but a magic offset value. But it wasn't 
acceptable to the maintainer of the mthca IB driver (Roland 
Dreier), hence the new proposal

-- 
Arthur

-
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 v3 1/1] md: Software Raid autodetect dev list not array

2007-08-27 Thread Michael J. Evans

From: Michael J. Evans <[EMAIL PROTECTED]>

In current release kernels the md module (Software RAID) uses a static array
 (dev_t[128]) to store partition/device info temporarily for autostart.

This patch replaces that static array with a list.

Signed-off-by: Michael J. Evans <[EMAIL PROTECTED]>
--- 
Sorry, it looks like I hit reply instead of reply to all yesterday.

Version 3:
md_autodetect_dev failure message is now more usefully verbose.
removed unused i_found that was leftover from initial verification.
Thank you Randy Dunlap for pointing where INT_MAX was, fixme fixed.

Version 2:
using list_add_tail, and corrected missing i_passed++;.
removed sections of code that would never be reached.

Version 1:
The data/structures are only used within md.c, and very close together.
However I wonder if the structural information shouldn't go in to...
../../include/linux/raid/md_k.h instead.


I discovered this (and that the devices are added as disks/partitions are
discovered at boot) while I was debugging why only one of my MD arrays would
come up whole, while all the others were short a disk.

I eventually discovered that it was enumerating through all of 9 of my 11 hds
(2 had only 4 partitions apiece) while the other 9 have 15 partitions
(I wanted 64 per drive...). The last partition of the 8th drive in my 9 drive
raid 5 sets wasn't added, thus making the final md array short both a parity
and data disk, and it was started later, elsewhere.

Subject: [patch 1/1] md: Software Raid autodetect dev list not array

SOFTWARE RAID (Multiple Disks) SUPPORT
P:  Ingo Molnar
M:  [EMAIL PROTECTED]
P:  Neil Brown
M:  [EMAIL PROTECTED]
L:  [EMAIL PROTECTED]
S:  Supported
Unless you have a reason NOT to do so, CC [EMAIL PROTECTED]

12: Has been tested with CONFIG_PREEMPT, CONFIG_DEBUG_PREEMPT,
CONFIG_DEBUG_SLAB, CONFIG_DEBUG_PAGEALLOC, CONFIG_DEBUG_MUTEXES,
CONFIG_DEBUG_SPINLOCK, CONFIG_DEBUG_SPINLOCK_SLEEP all simultaneously
enabled.

It has been tested with CONFIG_SMP set and unset (Different x86_64 systems).
It has been tested with CONFIG_PREEMPT set and unset (same system).
CONFIG_LBD isn't even an option in my .config file.

Note: between 2.6.22 and 2.6.23-rc3-git5
rdev = md_import_device(dev,0, 0);
became
rdev = md_import_device(dev,0, 90);
So the patch has been edited to patch around that line. (might be fuzzy)

Signed-off-by: Michael J. Evans <[EMAIL PROTECTED]>
=
--- linux/drivers/md/md.c.orig  2007-08-21 03:19:42.511576248 -0700
+++ linux/drivers/md/md.c   2007-08-21 04:30:09.775525710 -0700
@@ -24,4 +24,6 @@

+   - autodetect dev list not array: Michael J. Evans <[EMAIL PROTECTED]>
+
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2, or (at your option)
@@ -5752,13 +5754,26 @@ void md_autodetect_dev(dev_t dev)
  * Searches all registered partitions for autorun RAID arrays
  * at boot time.
  */
-static dev_t detected_devices[128];
-static int dev_cnt;
+
+static LIST_HEAD(all_detected_devices);
+struct detected_devices_node {
+   struct list_head list;
+   dev_t dev;
+};
 
 void md_autodetect_dev(dev_t dev)
 {
-   if (dev_cnt >= 0 && dev_cnt < 127)
-   detected_devices[dev_cnt++] = dev;
+   struct detected_devices_node *node_detected_dev;
+   char strbuf[BDEVNAME_SIZE];
+
+   node_detected_dev = kzalloc(sizeof(*node_detected_dev), GFP_KERNEL);\
+   if (node_detected_dev) {
+   node_detected_dev->dev = dev;
+   list_add_tail(_detected_dev->list, _detected_devices);
+   } else {
+   printk(KERN_CRIT "md: md_autodetect_dev: kzAlloc node failed"
+   " (null return), skipping dev(%d,%d)\n", MAJOR(dev), 
MINOR(dev));
+   }
 }
 
 
@@ -5765,7 +5760,12 @@ static void autostart_arrays(int part)
 static void autostart_arrays(int part)
 {
mdk_rdev_t *rdev;
-   int i;
+   struct detected_devices_node *node_detected_dev;
+   dev_t dev;
+   int i_scanned, i_passed;
+
+   i_scanned = 0;
+   i_passed = 0;
 
printk(KERN_INFO "md: Autodetecting RAID arrays.\n");
 
@@ -5772,3 +5792,7 @@ static void autostart_arrays(int part)
-   for (i = 0; i < dev_cnt; i++) {
-   dev_t dev = detected_devices[i];
-
+   while (!list_empty(_detected_devices) && i_scanned < INT_MAX) {
+   i_scanned++;
+   node_detected_dev = list_entry(all_detected_devices.next,
+   struct detected_devices_node, list);
+   list_del(_detected_dev->list);
+   dev = node_detected_dev->dev;
+   kfree(node_detected_dev);
@@ -5781,8 +5807,11 @@ static void autostart_arrays(int part)
continue;
}

Re: [PATCH] SLUB use cmpxchg_local

H. One wild idea would be to use a priority futex for the slab lock? 
That would make the slow paths interrupt safe without requiring interrupt 
disable? Does a futex fit into the page struct?

-
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] SLUB use cmpxchg_local

On Mon, 27 Aug 2007, Mathieu Desnoyers wrote:

> > The slow path would require disable preemption and two interrupt disables.
> If the slow path have to call new_slab, then yes. But it seems that not
> every slow path must call it, so for the other slow paths, only one
> interrupt disable would be required.

If we include new_slab then we get to 3 times:

1. In the cmpxchg_local emulation that fails

2. For the slow path

3. When calling the page allocator.

-
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] Fix kobject uevent string handling errors (updated)

2007-08-27 Thread Mathieu Desnoyers

Hi Andrew,

I thought you were going to use Kay Sievers's patch, which adds error
value checking to much of the add_event_var callers, so I did not bother
sending the updated version of my patch. Here it is, with the changelog.

---

Fix kobject uevent string handling errors

- increment env->buflen in dmi-id.c
- fix off-by-one in add_uevent_var in error checking of vsnprintf
- add warnings when add_uevent_var. Proper handling of its return values should
  really be done by the callers, but they aren't, so things currently
  fail silently. This is why I add warnings.

Fixes the following BUG in 2.6.23-rc3-mm1:

[   23.876358] skb_over_panic: text:c0252e5b len:97 put:11 head:c2b54400 
data:c2b54400 tail:0xc2b54461 end:0xc2b54460 dev:
[   23.910278] [ cut here ]
[   23.924080] Kernel BUG at c039e12c [verbose debug info unavailable]
[   23.942809] invalid opcode:  [#1] PREEMPT SMP
[   23.957213] last sysfs file: /devices/pci:00/:00:1f.1/ide0/0.0/media
[   23.978275] Modules linked in:
[   23.987429]
[   23.991884] Pid: 1038, comm: udevtrigger Not tainted 
(2.6.23-rc3-mm1-testssmp #286)
[   24.014773] EIP: 0060:[] EFLAGS: 00010286 CPU: 0
[   24.031168] EIP is at skb_over_panic+0x5c/0x60
[   24.04] EAX: 0084 EBX: c2b54400 ECX: 0001 EDX: 
[   24.063171] ESI:  EDI: c2b54456 EBP: c2b67eb4 ESP: c2b67e88
[   24.081895]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[   24.098027] Process udevtrigger (pid: 1038, ti=c2b66000 task=c2b08030 
task.ti=c2b66000)
[   24.121423] Stack: c050110c c0252e5b 0061 000b c2b54400 c2b54400 
c2b54461 c2b54460
[   24.146658]c04d21e0 c2ad8e80 0005 c2b67efc c0252e60 c2b54400 
c04d2183 c04ce0e4
[   24.171897]c2f60c40  c04ce0e4 c2f60c40 c04e2ecb c05401e0 
c2f58000 c2b67f04
[   24.197135] Call Trace:
[   24.205001]  [] show_trace_log_lvl+0x1a/0x30
[   24.220388]  [] show_stack_log_lvl+0xa8/0xe0
[   24.235772]  [] show_registers+0xca/0x250
[   24.250378]  [] die+0x115/0x280
[   24.262389]  [] do_trap+0x91/0xc0
[   24.274919]  [] do_invalid_op+0x89/0xa0
[   24.289004]  [] error_code+0x72/0x78
[   24.302313]  [] kobject_uevent_env+0x370/0x390
[   24.318217]  [] kobject_uevent+0xa/0x10
[   24.332303]  [] store_uevent+0x2b/0x70
[   24.346130]  [] dev_attr_store+0x2f/0x40
[   24.360476]  [] sysfs_write_file+0xa0/0x100
[   24.375602]  [] vfs_write+0x99/0x130
[   24.388910]  [] sys_write+0x3d/0x70
[   24.401958]  [] syscall_call+0x7/0xb
[   24.415265]  ===
[   24.425947] INFO: lockdep is turned off.
[   24.437665] Code: 00 00 89 5c 24 14 8b 98 8c 00 00 00 89 54 24 0c 89 5c 24 
10 8b 40 50 89 4c 24 04 c7 04 24 0c 11 50 c0 89 44 24 08 e8 84 20 d9 ff <0f> 0b 
eb fe 55 89 e5 56 89 d6 53 89 c3 83 ec 0c 8b 40 50 39
[   24.496006] EIP: [] skb_over_panic+0x5c/0x60 SS:ESP 0068:c2b67e88

Changelog:
- Use KERN_ERR for printks
- in dmi-id.c, env->buflen += len should be used instead of env->buflen
  += len + 1. This is because the originally present \0 is overwritten
  by the new data and should therefore be counted out.

Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
Reviewed-by: Greg KH <[EMAIL PROTECTED]>
Reviewed-by: Kay Sievers <[EMAIL PROTECTED]>
---
 drivers/firmware/dmi-id.c |5 +++--
 lib/kobject_uevent.c  |   12 ++--
 2 files changed, 13 insertions(+), 4 deletions(-)

Index: linux-2.6-lttng/lib/kobject_uevent.c
===
--- linux-2.6-lttng.orig/lib/kobject_uevent.c   2007-08-25 09:25:26.0 
-0400
+++ linux-2.6-lttng/lib/kobject_uevent.c2007-08-27 18:02:11.0 
-0400
@@ -247,8 +247,12 @@ int add_uevent_var(struct kobj_uevent_en
va_list args;
int len;
 
-   if (env->envp_idx >= ARRAY_SIZE(env->envp))
+   if (env->envp_idx >= ARRAY_SIZE(env->envp)) {
+   printk(KERN_ERR "add_uevent_var: too small array size %u %u\n",
+   env->envp_idx, ARRAY_SIZE(env->envp));
+   WARN_ON(1);
return -ENOMEM;
+   }
 
va_start(args, format);
len = vsnprintf(>buf[env->buflen],
@@ -256,8 +260,12 @@ int add_uevent_var(struct kobj_uevent_en
format, args);
va_end(args);
 
-   if (len + 1 >= (sizeof(env->buf) - env->buflen))
+   if (len >= (sizeof(env->buf) - env->buflen)) {
+   printk(KERN_ERR "add_uevent_var: failed vsnprintf %d %u\n",
+   len, (sizeof(env->buf) - env->buflen));
+   WARN_ON(1);
return -ENOMEM;
+   }
 
env->envp[env->envp_idx++] = >buf[env->buflen];
env->buflen += len + 1;
Index: linux-2.6-lttng/drivers/firmware/dmi-id.c
===
--- linux-2.6-lttng.orig/drivers/firmware/dmi-id.c  2007-08-25 
09:25:26.0 -0400
+++ linux-2.6-lttng/drivers/firmware/dmi-id.c   2007-08-25 14:41:16.0 
-0400
@@ -152,9

Re: division and cpu usage

2007-08-27 Thread Luka Napotnik

Jan Engelhardt pravi:
> On Aug 24 2007 07:34, linux-os (Dick Johnson) wrote:
>>> I'm new to kernel development and have some questions.
>>>
>>> 1. Why can't I divide with regular casting to double ((double)a /
>>> (double)b)? It gives me strange errors when compiling:
>>>
>>> WARNING: "__divdf3" [/root] undefined!
>>> WARNING: "__addf3" [/root/...] undefined!
>>> WARNING: "__floatsidf" [/root/...] undefined!
>>>
>>> And if I compile with normal integers, I get zero as the result.
>>>
>>> 2. I'm trying to get the percentage of CPU used for a certain
>>> task_struct and figured the following formula:
>>>
>>> (task->utime + task->stime) / jiffies

This formula just doesn't work. I have a task with 99% CPU (top) but the
result of that formula is random (4, sometimes 8). What am I doing
wrong? Please help.

>>>
>>> Before calculating I convert all the variables to jiffies. Is this correct?
> 
> * So use integer math: (task->utime + task->stime) * 100 / jiffies
>   and you get the 'common' percentage. In integer, that is.
> 
> * I am not sure about the use of jiffies when it comes to CONFIG_NO_HZ=y.
> 
>> Floating point operations are not allowed in the kernel. Often,
> 
> IIRC they are allowed since ... recently (2.6.16, .17? can't remember). When
> the kernel tries to execute an FP instruction (and traps as a result), more
> kernel code will enable that the FP stack gets properly switched when a 
> process
> changes between userspace-kernelspace.
> 
>> You can use "long long" for high precision math if necessary.
> 
> That will give link failure for __udivdi3. Use do_div().
> 
> 
>   Jan

-
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: [PATCH] IdealTEK URTC1000 support for usbtouchscreen

2007-08-27 Thread Daniel Ritz

> OK, so here's the new patch, inline this time:

thanks. looks fine now. forwarding to Dmitry for mainline inclusion...

rgds
-daniel

-

[PATCH] IdealTEK URTC1000 support for usbtouchscreen

This patch adds support for IdealTEK URTC1000 touchscreen controllers.

Documentation can be downloaded at 
http://projects.tbmn.org/cgi-bin/trac.cgi/wiki/urtc-1000

Signed-off-by: Ondrej Zary <[EMAIL PROTECTED]>
Signed-off-by: Daniel Ritz <[EMAIL PROTECTED]>


diff -ur linux-2.6.23-rc3-orig/drivers/input/touchscreen/Kconfig 
linux-2.6.23-rc3/drivers/input/touchscreen/Kconfig
--- linux-2.6.23-rc3-orig/drivers/input/touchscreen/Kconfig 2007-08-21 
15:32:50.0 +0200
+++ linux-2.6.23-rc3/drivers/input/touchscreen/Kconfig  2007-08-23 
16:07:08.0 +0200
@@ -191,6 +191,7 @@
  - Gunze AHL61
  - DMC TSC-10/25
  - IRTOUCHSYSTEMS/UNITOP
+ - IdealTEK URTC1000
 
  Have a look at  for
  a usage description and the required user-space stuff.
@@ -238,4 +239,9 @@
bool "IRTOUCHSYSTEMS/UNITOP device support" if EMBEDDED
depends on TOUCHSCREEN_USB_COMPOSITE
 
+config TOUCHSCREEN_USB_IDEALTEK
+   default y
+   bool "IdealTEK URTC1000 device support" if EMBEDDED
+   depends on TOUCHSCREEN_USB_COMPOSITE
+
 endif
diff -ur linux-2.6.23-rc3-orig/drivers/input/touchscreen/usbtouchscreen.c 
linux-2.6.23-rc3/drivers/input/touchscreen/usbtouchscreen.c
--- linux-2.6.23-rc3-orig/drivers/input/touchscreen/usbtouchscreen.c
2007-08-23 16:24:16.0 +0200
+++ linux-2.6.23-rc3/drivers/input/touchscreen/usbtouchscreen.c 2007-08-27 
09:29:06.0 +0200
@@ -10,6 +10,7 @@
  *  - Gunze AHL61
  *  - DMC TSC-10/25
  *  - IRTOUCHSYSTEMS/UNITOP
+ *  - IdealTEK URTC1000
  *
  * Copyright (C) 2004-2006 by Daniel Ritz <[EMAIL PROTECTED]>
  * Copyright (C) by Todd E. Johnson (mtouchusb.c)
@@ -92,7 +93,7 @@
 };
 
 
-#if defined(CONFIG_TOUCHSCREEN_USB_EGALAX) || 
defined(CONFIG_TOUCHSCREEN_USB_ETURBO)
+#if defined(CONFIG_TOUCHSCREEN_USB_EGALAX) || 
defined(CONFIG_TOUCHSCREEN_USB_ETURBO) || 
defined(CONFIG_TOUCHSCREEN_USB_IDEALTEK)
 #define MULTI_PACKET
 #endif
 
@@ -112,6 +113,7 @@
DEVTYPE_GUNZE,
DEVTYPE_DMC_TSC10,
DEVTYPE_IRTOUCH,
+   DEVTYPE_IDEALTEK,
 };
 
 static struct usb_device_id usbtouch_devices[] = {
@@ -157,6 +159,10 @@
{USB_DEVICE(0x6615, 0x0001), .driver_info = DEVTYPE_IRTOUCH},
 #endif
 
+#ifdef CONFIG_TOUCHSCREEN_USB_IDEALTEK
+   {USB_DEVICE(0x1391, 0x1000), .driver_info = DEVTYPE_IDEALTEK},
+#endif
+
{}
 };
 
@@ -438,6 +444,39 @@
 
 
 /*
+ * IdealTEK URTC1000 Part
+ */
+#ifdef CONFIG_TOUCHSCREEN_USB_IDEALTEK
+static int idealtek_get_pkt_len(unsigned char *buf, int len)
+{
+   if (buf[0] & 0x80)
+   return 5;
+   if (buf[0] == 0x01)
+   return len;
+   return 0;
+}
+
+static int idealtek_read_data(struct usbtouch_usb *dev, unsigned char *pkt)
+{
+   if ((pkt[0] & 0x98) == 0x88) {
+   /* touch data in IdealTEK mode */
+   dev->x = (pkt[1] << 5) | (pkt[2] >> 2);
+   dev->y = (pkt[3] << 5) | (pkt[4] >> 2);
+   dev->touch = (pkt[0] & 0x40) ? 1 : 0;
+   return 1;
+   } else if ((pkt[0] & 0x98) == 0x98) {
+   /* touch data in MT emulation mode */
+   dev->x = (pkt[2] << 5) | (pkt[1] >> 2);
+   dev->y = (pkt[4] << 5) | (pkt[3] >> 2);
+   dev->touch = (pkt[0] & 0x40) ? 1 : 0;
+   return 1;
+   }
+   return 0;
+}
+#endif
+
+
+/*
  * the different device descriptors
  */
 static struct usbtouch_device_info usbtouch_dev_info[] = {
@@ -537,6 +576,20 @@
.read_data  = irtouch_read_data,
},
 #endif
+
+#ifdef CONFIG_TOUCHSCREEN_USB_IDEALTEK
+   [DEVTYPE_IDEALTEK] = {
+   .min_xc = 0x0,
+   .max_xc = 0x0fff,
+   .min_yc = 0x0,
+   .max_yc = 0x0fff,
+   .rept_size  = 8,
+   .flags  = USBTOUCH_FLG_BUFFER,
+   .process_pkt= usbtouch_process_multi,
+   .get_pkt_len= idealtek_get_pkt_len,
+   .read_data  = idealtek_read_data,
+   },
+#endif
 };
 
 


-- 
Ondrej Zary

---
-
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 0/3] pci: let devices flush DMA to host memory

2007-08-27 Thread Grant Grundler

On Fri, Aug 24, 2007 at 11:02:32AM -0700, [EMAIL PROTECTED] wrote:
> 
> On Altix, DMA may be reordered within the NUMA interconnect. 
> This can be a problem with Infiniband, where DMA to Completion 
> Queues can race with data DMA. This patchset allows a driver 
> to associate a memory region with a "dmaflush" attribute, so 
> that writes to the memory region flush in-flight DMA, preventing 
> the CQ/data race.

FYI to linux-pci folks
This patch had previous discussion on LKML:
http://lkml.org/lkml/2007/8/17/336

James Bottomley at one point obliquely referred to
my OLS2003 paper: "DMA Hints on ia64/PARISC"

After reading the thread, my take is we need a more elegant way for a
device driver to handle registration of DMA regions allocated by user
space. The API would "make this page/region act like dma_alloc_coherent()".
That implies strong ordering between CPU and DMA to/from the device.
Maybe the code is the right thing and I want a name that makes
sense in the context of current DMA API.

On IRC, willy suggested an mmap() flag and that sounds reasonable too
though I don't know if it's feasible. 

hth,
grant

> There are three patches in this set:
> 
>   [1/3]: add pci_dma_flags_set_dmaflush() to pci interface
>   [2/3]: redefine pci_dma_flags_set_dmaflush() for sn-ia64
>   [3/3]: document pci_dma_flags_set_dmaflush()
> 
> And there would be additional patches to IB drivers to make use 
> of the interface, of course. 
> 
> -- 
> Arthur
-
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] Version2 Smack: Simplified Mandatory Access Control Kernel

2007-08-27 Thread Thomas Bleher

* Casey Schaufler <[EMAIL PROTECTED]> [2007-08-27 22:51]:
> 
> Smack is the Simplified Mandatory Access Control Kernel.
> 
> Smack implements mandatory access control (MAC) using labels
> attached to tasks and data containers, including files, SVIPC,
> and other tasks. Smack is a kernel based scheme that requires
> an absolute minimum of application support and a very small
> amount of configuration data.
> 
> Smack is implemented as a clean LSM. It requires no external
> code changes and the patch modifies only the Kconfig and Makefile
> in the security directory. Smack uses extended attributes and
> provides a set of general mount options, borrowing technics used
> elsewhere. Smack uses netlabel for CIPSO labeling. Smack provides
> a pseudo-filesystem smackfs that is used for manipulation of
> system Smack attributes.
> 
> The patch, patches for ls and sshd, a README, a startup script,
> and x86 binaries for ls and sshd are also available on
> 
> http:/www.schaufler-ca.com

I like the general idea of this LSM.
One question about your security model, though:
If I understand your LSM correctly, MAC override is based on
capabilities, specifically on CAP_LINUX_IMMUTABLE. So any root process
which doesn't explicitly give up this capability is effectively
unconfined, right?

If so, this is a serious limitation that should be mentioned in the
docs. File capabilities should alleviate this problem, but they first
need to be configured correctly...

Some other comments below:

> --- linux-2.6.22-base/security/smack/Kconfig  1969-12-31 16:00:00.0 
> -0800
> +++ linux-2.6.22-smack/security/smack/Kconfig 2007-08-22 02:18:55.0 
> -0700
> @@ -0,0 +1,10 @@
> +config SECURITY_SMACK
> + bool "Simplified Mandatory Access Control Kernel Support"
> + depends on NETLABEL && SECURITY_NETWORK
> + default n
> + help
> +   This selects the Simplified Mandatory Access Control Kernel.
> +   Smack is useful for sensitivity, integrity, and a variety
> +   of other mandatory security schemes.
> +   If you are unsure how to answer this question, answer N.

I think a link to further documentation would be nice.
Maybe you could include the README from your site in Documentation/?

BTW: Some documentation missing there:
* the various mount options
* how to enable cipso (Do I have to enable it explicitly? Most people
  won't even know what cipso is)


> +/**
> + * smack_syslog - Smack approval on syslog
> + * @type: message type
> + *
> + * Require that the task has the floor label
> + *
> + * Returns 0 on success, error code otherwise.
> + */
> +static int smack_syslog(int type)
> +{
> + int rc;
> + smack_t *sp = current->security;
> +
> + rc = cap_syslog(type);
> + if (rc == 0)
> +  if (*sp != SMK_FLOOR)
> + rc = -EACCES;
> +
> + return rc;
> +}

Can you explain why you limit syslog that way?

> +/**
> + * smackfs_follow_link - follow a smackfs symlink
  ^^^ should be put_link
> + * @dentry: unused
> + * @nd: name entry
> + * @ptr: unused
> + *
> + * free the buffer used in following the link.
> + */
> +static void smackfs_put_link(struct dentry *dentry, struct nameidata *nd, 
> void *ptr)
> +{
> + kfree(nd_get_link(nd));
> +}


> +   for (cp = data - 1; cp != NULL; cp = strchr(cp + 1, '\n')) {
> +   if (*++cp == '\0')
> +   break;
> +   if (sscanf(cp, "%14s %30s\n", name, target) != 2) {
> +   printk("%s:%d bad scan\n",
> +   __func__, __LINE__);

Leftover debugging printk? Otherwise, a level would be nice.

> +   break;
> +   }
> +   smk_add_symlink(name, target);
> +   printk("%s:%d add %s -> %s\n",
> +   __func__, __LINE__, name, target);

Ditto.

> +   }


> +/**
> + * smackfs_follow_link - follow a smackfs symlink
> + * @dentry: name cache entry
> + * @nd: name entry
> + *
> + * A symlink on smackfs has unusual semantics.
> + *
> + * The Smack value of the task is appended to the link string.
> + * Thus, if a task labeled "Gentoo" does chdir("/smack/tmp")
> + * it will use "/moldy/Gentoo".
> + *
> + * The expected usage is the /tmp is a symlink to /smack/tmp
> + * which is itself a symlink to /moldy. /moldy should have a
> + * directory for each label in use to accomodate the value
> + * appended on the redirection.
> + *
> + * An interesting addition would be a file system that automatically
> + * creates directories as needed, at the appropriate label.
> + */

I'm not very versed in the VFS, so I don't think I understand the code
fully there, but shouldn't the above read /smack/links?


> + static struct tree_descr smack_files[] = {
> + [SMK_LOAD]  = {"load", _load_ops, S_IRUGO|S_IWUSR},
> + [SMK_LINKS] = {"links", _links_ops, S_IRUGO|S_IWUSR},

I really don't understand your symlink code (not

RE: Linux-Kernel MAINTAINERS - LSILOGIC MPT FUSION DRIVERS

2007-08-27 Thread Moore, Eric

On Monday, August 27, 2007 9:59 AM, Joe Perches wrote:
> On Mon, 2007-08-27 at 09:30 -0600, Moore, Eric wrote:
> > Yes it was changed to [EMAIL PROTECTED] I had posted a
> > patch about a month back, along with the changes for all the driver
> > sources. 
> 
> This is what I have:
> 
> LSILOGIC MPT FUSION DRIVERS (FC/SAS/SPI)
> P:Eric Moore
> M:[EMAIL PROTECTED]
> M:[EMAIL PROTECTED]
> L:[EMAIL PROTECTED]
> L:[EMAIL PROTECTED]
> W:http://www.lsilogic.com/support
> S:Supported
> F:drivers/message/fusion/
> 
> > You will notice the sources were updated
> > (driver/message/fusion), I have no idea why MAINTAINERS didn't'.
> 
> I can't find a patch for MAINTAINERS and DL-MPTFusionLinux
> This commit is just for the sources.
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.g
> it;a=commitdiff;h=16d201016a9f29e0557849907352769c63cef259
> 

Attached is my patch I posted on June 13, 2007, the same day as the
patch you found.Here is the weblink:
http://marc.info/?l=linux-scsi=118177408121329=2

Eric
--- Begin Message ---
LSI has a new distribution list for linux support and associated inquires.  The 
previous list at [EMAIL PROTECTED] has been deleted.  I will continue 
maintaining this driver, as well as others at LSI.

Signed-off-by: Eric Moore <[EMAIL PROTECTED]>

--- b/MAINTAINERS   2007-06-12 12:21:42.0 -0600
+++ a/MAINTAINERS   2007-06-13 14:38:30.0 -0600
@@ -2277,11 +2277,10 @@ L:  [EMAIL PROTECTED]
 W: http://www.linux-ntfs.org/content/view/19/37/
 S: Maintained
 
-LSILOGIC MPT FUSION DRIVERS (FC/SAS/SPI)
-P: Eric Moore
-M: [EMAIL PROTECTED]
+LSI MPT FUSION DRIVERS (FC/SAS/SPI)
+P: MPT Fusion Linux Team
+M: [EMAIL PROTECTED]
 M: [EMAIL PROTECTED]
-L: [EMAIL PROTECTED]
 L: [EMAIL PROTECTED]
 W: http://www.lsilogic.com/support
 S: Supported
--- End Message ---

Re: [2.6.24 patch] the planned eepro100 removal

2007-08-27 Thread Kok, Auke


Adrian Bunk wrote:

This patch contains the planned removal of the eepro100 driver.

Signed-off-by: Adrian Bunk 


you lost your e-mail address? :)


---

This patch has been sent on:
- 14 Aug 2007
- 29 Jul 2007


currently we won't have e100 fixed up for ARM in 2.6.23, so removing this for 
2.6.24 sounds a bit premature. Maybe 2.6.25. Can you reschedule/postpone this?


Auke
-
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: cpu hotplug support broken in 2.6.23-rc3

On Mon 2007-08-27 23:59:31, Rafael J. Wysocki wrote:
> On Monday, 27 August 2007 23:32, Pavel Machek wrote:
> > On Mon 2007-08-27 22:36:57, Jeff Chua wrote:
> > > On 8/27/07, Pavel Machek <[EMAIL PROTECTED]> wrote:
> > > > On Mon 2007-08-27 12:43:50, Pavel Machek wrote:
> > > > > Hi!
> > > > >
> > > > > Trying to do few onlines/offlines reliably hangs my machine (thinkpad
> > > > > x60, i386 architecture).
> > > 
> > > I just 3 cycles of on-line/off-line on 2.6.23-rc3 on ThinkPad x60s,
> > > and my system still survives.
> > 
> > Can you try 20-or-so tests? Mine hangs randomly, so it survived 4 or
> > so cycles at one point.
> > 
> > ...or maybe difference is in the .config, or maybe I broken something
> > in my kernel sources
> 
> Well, something seems to be wrong with the CPU hotplug, but it's insanely
> difficult to reproduce on my boxes.
> 
> I bet on one of the notifiers blocking while waiting on a frozen task.

It happens reliably for me, with this script... and randomly, when I
just echo 0/1 > online from commandline... so it should not be
anything with the frozen tasks.

echo test > /sys/power/disk
echo disk > /sys/power/state

reliably hangs on resume in the attached script. It works ok with
nosmp.

Pavel

#!/bin/bash
killall klogd

echo -n "testing refrigerator (testproc)..."
echo testproc > /sys/power/disk
echo disk > /sys/power/state
echo "okay"

sleep 2
echo -n "testing drivers (test)..."
echo test > /sys/power/disk
echo disk > /sys/power/state
echo "okay"

sleep 2
echo -n "testing swsusp (reboot)..."
echo reboot > /sys/power/disk
echo disk > /sys/power/state
echo "okay"

sleep 2
echo -n "testing s2ram..."
s2ram
echo "okay"

sleep 2
echo -n "testing swsusp (shutdown)..."
echo shutdown > /sys/power/disk
echo disk > /sys/power/state
echo "okay"

sleep 2
echo -n "testing swsusp (platform)..."
echo platform > /sys/power/disk
echo disk > /sys/power/state
echo "okay"

sleep 2
echo -n "testing s2ram..."
s2ram
echo "okay"
 

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [1/1] Block device throttling [Re: Distributed storage.]

2007-08-27 Thread Daniel Phillips

Say Evgeniy, something I was curious about but forgot to ask you 
earlier...

On Wednesday 08 August 2007 03:17, Evgeniy Polyakov wrote:
> ...All oerations are not atomic, since we do not care about precise
> number of bios, but a fact, that we are close or close enough to the
> limit. 
> ... in bio->endio
> + q->bio_queued--;

In your proposed patch, what prevents the race:

cpu1cpu2

read q->bio_queued

q->bio_queued--
write q->bio_queued - 1
Whoops! We leaked a throttle count.

Regards,

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/

[PATCH] Track accurate idle time with tick_sched.idle_sleeptime

2007-08-27 Thread Venki Pallipadi


Current idle time in kstat is based on jiffies and is coarse grained.
tick_sched.idle_sleeptime is making some attempt to keep track of
idle time in a fine grained manner. But, it is not handling
the time spent in interrupts fully.

Make tick_sched.idle_sleeptime accurate with respect to time spent on
handling interrupts and also add tick_sched.idle_lastupdate, which
keeps track of last time when idle_sleeptime was updated.

This statistics will be crucial for cpufreq-ondemand governor, which can shed
some conservative gaurd band that is uses today while setting the frequency.
The ondemand changes that uses the exact idle time is coming soon. 

Signed-off-by: Venkatesh Pallipadi <[EMAIL PROTECTED]>

Index: linux-2.6.22/kernel/time/tick-sched.c
===
--- linux-2.6.22.orig/kernel/time/tick-sched.c
+++ linux-2.6.22/kernel/time/tick-sched.c
@@ -141,6 +141,43 @@ void tick_nohz_update_jiffies(void)
local_irq_restore(flags);
 }
 
+void tick_nohz_stop_idle(int cpu)
+{
+   struct tick_sched *ts = _cpu(tick_cpu_sched, cpu);
+
+   if (ts->idle_active) {
+   ktime_t now, delta;
+   now = ktime_get();
+   delta = ktime_sub(now, ts->idle_entrytime);
+   ts->idle_lastupdate = now;
+   ts->idle_sleeptime = ktime_add(ts->idle_sleeptime, delta);
+   ts->idle_active = 0;
+   }
+}
+
+static void tick_nohz_start_idle(int cpu)
+{
+   struct tick_sched *ts = _cpu(tick_cpu_sched, cpu);
+   ktime_t now, delta;
+
+   now = ktime_get();
+   if (ts->idle_active) {
+   delta = ktime_sub(now, ts->idle_entrytime);
+   ts->idle_lastupdate = now;
+   ts->idle_sleeptime = ktime_add(ts->idle_sleeptime, delta);
+   }
+   ts->idle_entrytime = now;
+   ts->idle_active = 1;
+}
+
+u64 get_cpu_idle_time_us(int cpu, u64 *last_update_time)
+{
+   struct tick_sched *ts = _cpu(tick_cpu_sched, cpu);
+
+   *last_update_time = ktime_to_us(ts->idle_lastupdate);
+   return ktime_to_us(ts->idle_sleeptime);
+}
+
 /**
  * tick_nohz_stop_sched_tick - stop the idle tick from the idle task
  *
@@ -152,13 +189,15 @@ void tick_nohz_stop_sched_tick(void)
 {
unsigned long seq, last_jiffies, next_jiffies, delta_jiffies, flags;
struct tick_sched *ts;
-   ktime_t last_update, expires, now, delta;
+   ktime_t last_update, expires, now;
struct clock_event_device *dev = __get_cpu_var(tick_cpu_device).evtdev;
int cpu;
 
local_irq_save(flags);
 
cpu = smp_processor_id();
+   tick_nohz_start_idle(cpu);
+
ts = _cpu(tick_cpu_sched, cpu);
 
if (unlikely(ts->nohz_mode == NOHZ_MODE_INACTIVE))
@@ -178,19 +217,7 @@ void tick_nohz_stop_sched_tick(void)
}
}
 
-   now = ktime_get();
-   /*
-* When called from irq_exit we need to account the idle sleep time
-* correctly.
-*/
-   if (ts->tick_stopped) {
-   delta = ktime_sub(now, ts->idle_entrytime);
-   ts->idle_sleeptime = ktime_add(ts->idle_sleeptime, delta);
-   }
-
-   ts->idle_entrytime = now;
ts->idle_calls++;
-
/* Read jiffies and the time when jiffies were updated last */
do {
seq = read_seqbegin(_lock);
@@ -320,23 +347,22 @@ void tick_nohz_restart_sched_tick(void)
int cpu = smp_processor_id();
struct tick_sched *ts = _cpu(tick_cpu_sched, cpu);
unsigned long ticks;
-   ktime_t now, delta;
+   ktime_t now;
+
+   local_irq_disable();
+   tick_nohz_stop_idle(cpu);
 
-   if (!ts->tick_stopped)
+   if (!ts->tick_stopped) {
+   local_irq_enable();
return;
+   }
 
/* Update jiffies first */
-   now = ktime_get();
-
-   local_irq_disable();
select_nohz_load_balancer(0);
+   now = ktime_get();
tick_do_update_jiffies64(now);
cpu_clear(cpu, nohz_cpu_mask);
 
-   /* Account the idle time */
-   delta = ktime_sub(now, ts->idle_entrytime);
-   ts->idle_sleeptime = ktime_add(ts->idle_sleeptime, delta);
-
/*
 * We stopped the tick in idle. Update process times would miss the
 * time we slept as update_process_times does only a 1 tick
Index: linux-2.6.22/include/linux/tick.h
===
--- linux-2.6.22.orig/include/linux/tick.h
+++ linux-2.6.22/include/linux/tick.h
@@ -51,8 +51,10 @@ struct tick_sched {
unsigned long   idle_jiffies;
unsigned long   idle_calls;
unsigned long   idle_sleeps;
+   int idle_active;
ktime_t idle_entrytime;
ktime_t idle_sleeptime;
+   ktime_t idle_lastupdate;
ktime_t

Re: RFC: issues concerning the next NAPI interface

2007-08-27 Thread David Miller

From: James Chapman <[EMAIL PROTECTED]>
Date: Mon, 27 Aug 2007 22:41:43 +0100

> I don't recall saying anything in previous posts about this. Are you 
> confusing my posts with Jan-Bernd's?

Yes, my bad.

> Jan-Bernd has been talking about using hrtimers to _reschedule_
> NAPI. My posts are suggesting an alternative mechanism that keeps
> NAPI active (with interrupts disabled) for a jiffy or two after it
> would otherwise have gone idle in order to avoid too many interrupts
> when the packet rate is such that NAPI thrashes between poll-on and
> poll-off.

So in this scheme what runs ->poll() to process incoming packets?
The hrtimer?
-
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 -mm 2/3] PM: More fine grained ACPI handling during suspend and hibernation (rev. 3)

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

According to the ACPI specification (eg. ACPI 2.0c, sec. 7.3.1, 7.3.3,
ACPI 3.0b, sec. 7.3.1, 7.3.3) the _GTS and _BFS global control methods should
be executed, respectively, right before entering a sleep state (S1-S4) and right
after leaving it, but we don't follow this reqirement.  Namely, in our
implementation the nonboot CPUs are disabled after executing _GTS and enabled
before executing _BFS, which doesn't seem to be correct.  [In fact, the ACPI
specification requires that no physical I/O and interrupt servicing be performed
after the sleep state has been left and before _BFS is executed as well as after
executing _GTS and before the sleep state is entered, but we can't follow this
requirement literally, since our AML interpreter needs to run with interrupts
enabled and we need to carry out some operations with interrupts disabled before
entering the sleep state and after leaving it.]  Moreover, acpi_enable() called
after restoring the system memory state from a hibernation image should really
be executed before enabling the nonboot CPUs, since functional ACPI may be
needed for that.  All of this means that we need to handle ACPI in a more fine
grained manner during suspend and hibernation.

For this reason we can introduce new global platform callbacks prepare_late()
and finish_early() to be executed, respectively, between disabling the nonboot
CPUs and entering a sleep state and between leaving the sleep state and enabling
the nonboot CPUs.  For ACPI systems they can be used to execute the _GTS and
_BFS global control methods, respectively.

It also seems to be a good idea to introduce new hibernation-related callback
post_snapshot() to be executed after creating a hibernation image, instead of
finish() (for now, both these callbacks are defined to point to the same
function, but that will be changed in the future).

Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
Acked-by: Pavel Machek <[EMAIL PROTECTED]>
---
 drivers/acpi/hardware/hwsleep.c |   98 
 drivers/acpi/sleep/main.c   |   57 +--
 include/acpi/acpixf.h   |4 +
 include/linux/suspend.h |   57 +++
 kernel/power/disk.c |   50 +---
 kernel/power/main.c |   16 +-
 6 files changed, 241 insertions(+), 41 deletions(-)

Index: linux-2.6.23-rc3/include/linux/suspend.h
===
--- linux-2.6.23-rc3.orig/include/linux/suspend.h
+++ linux-2.6.23-rc3/include/linux/suspend.h
@@ -49,7 +49,7 @@ typedef int __bitwise suspend_state_t;
  * passed to @enter() is meaningless and should be ignored.
  *
  * @prepare: Prepare the platform for entering the system sleep state indicated
- * by @set_target().
+ * by @set_target() (first stage).
  * @prepare() is called right after devices have been suspended (ie. the
  * appropriate .suspend() method has been executed for each device) and
  * before the nonboot CPUs are disabled (it is executed with IRQs enabled).
@@ -57,12 +57,27 @@ typedef int __bitwise suspend_state_t;
  * error code otherwise, in which case the system cannot enter the desired
  * sleep state (@enter() and @finish() will not be called in that case).
  *
+ * @prepare_late: Prepare the platform for entering the system sleep state
+ * indicated by @set_target() (second stage).
+ * @prepare_late() is called right after the nonboot CPUs have been
+ * disabled (it is executed with on CPU on line and with IRQs enabled).
+ * This callback is optional.  It returns 0 on success or a negative
+ * error code otherwise, in which case the system cannot enter the desired
+ * sleep state (@enter() will not be called in that case).
+ *
  * @enter: Enter the system sleep state indicated by @set_target() or
  * represented by the argument if @set_target() is not implemented.
  * This callback is mandatory.  It returns 0 on success or a negative
  * error code otherwise, in which case the system cannot enter the desired
  * sleep state.
  *
+ * @finish_early: Called when the system has just left a sleep state, right
+ * prior to enabling the nonboot CPUs (it is executed with one CPU on line
+ * and with IRQs enabled).
+ * This callback is optional, but should be implemented by the platforms
+ * that implement @prepare_late().  If @enter() fails, this callback will
+ * not be executed.
+ *
  * @finish: Called when the system has just left a sleep state, right after
  * the nonboot CPUs have been enabled and before devices are resumed (it is
  * executed with IRQs enabled).
@@ -74,7 +89,9 @@ struct platform_suspend_ops {
int (*valid)(suspend_state_t state);
int (*set_target)(suspend_state_t state);
int (*prepare)(void);
+   int (*prepare_late)(void);
int (*enter)(suspend_state_t

Re: cpu hotplug support broken in 2.6.23-rc3

On Monday, 27 August 2007 23:32, Pavel Machek wrote:
> On Mon 2007-08-27 22:36:57, Jeff Chua wrote:
> > On 8/27/07, Pavel Machek <[EMAIL PROTECTED]> wrote:
> > > On Mon 2007-08-27 12:43:50, Pavel Machek wrote:
> > > > Hi!
> > > >
> > > > Trying to do few onlines/offlines reliably hangs my machine (thinkpad
> > > > x60, i386 architecture).
> > 
> > I just 3 cycles of on-line/off-line on 2.6.23-rc3 on ThinkPad x60s,
> > and my system still survives.
> 
> Can you try 20-or-so tests? Mine hangs randomly, so it survived 4 or
> so cycles at one point.
> 
> ...or maybe difference is in the .config, or maybe I broken something
> in my kernel sources

Well, something seems to be wrong with the CPU hotplug, but it's insanely
difficult to reproduce on my boxes.

I bet on one of the notifiers blocking while waiting on a frozen task.

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/

[PATCH -mm 3/3] PM: Improve handling of ACPI system state indicator (rev. 3)

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

Introduce a separate ACPI function for setting the system status indicator and
use it in the right places in the suspend and hibernation related ACPI callbacks
instead of setting the system status indicator implicitly in
acpi_enter_sleep_state_prep() and acpi_leave_sleep_state().

This allows us to avoid turning off the sleep state indicator during hibernation
on Thinkpads (currently, it is turned off before saving the image, because we
need to call finish() before unfreezing devices).

Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
Acked-by: Pavel Machek <[EMAIL PROTECTED]>
---
 drivers/acpi/hardware/hwsleep.c |   51 +++-
 drivers/acpi/sleep/main.c   |   40 ---
 include/acpi/acpixf.h   |2 +
 3 files changed, 68 insertions(+), 25 deletions(-)

Index: linux-2.6.23-rc3/drivers/acpi/hardware/hwsleep.c
===
--- linux-2.6.23-rc3.orig/drivers/acpi/hardware/hwsleep.c
+++ linux-2.6.23-rc3/drivers/acpi/hardware/hwsleep.c
@@ -199,15 +199,46 @@ acpi_status acpi_enter_sleep_state_prep(
return_ACPI_STATUS(status);
}
 
-   /* Setup the argument to _SST */
+   /* Disable/Clear all GPEs */
+
+   status = acpi_hw_disable_all_gpes();
+
+   return_ACPI_STATUS(status);
+}
+
+/***
+ *
+ * FUNCTION:acpi_set_sleep_state_indicator
+ *
+ * PARAMETERS:  sleep_state - Which sleep state to enter
+ *
+ * RETURN:  Status
+ *
+ * DESCRIPTION: Make the system status indicator reflect the sleep state being
+ *  entered.
+ *  This function must execute with interrupts enabled.
+ *
+ 
**/
+acpi_status acpi_set_sleep_state_indicator(u8 sleep_state)
+{
+   acpi_status status;
+   struct acpi_object_list arg_list;
+   union acpi_object arg;
+
+   ACPI_FUNCTION_TRACE(acpi_set_sleep_state_indicator);
+
+   arg_list.count = 1;
+   arg_list.pointer = 
+
+   arg.type = ACPI_TYPE_INTEGER;
 
+   /* Setup the argument to _SST */
switch (sleep_state) {
case ACPI_STATE_S0:
arg.integer.value = ACPI_SST_WORKING;
break;
 
case ACPI_STATE_S1:
-   case ACPI_STATE_S2:
case ACPI_STATE_S3:
arg.integer.value = ACPI_SST_SLEEPING;
break;
@@ -217,27 +248,21 @@ acpi_status acpi_enter_sleep_state_prep(
break;
 
default:
-   arg.integer.value = ACPI_SST_INDICATOR_OFF; /* Default is 
off */
+   /* Default is off */
+   arg.integer.value = ACPI_SST_INDICATOR_OFF;
break;
}
 
/* Set the system indicators to show the desired sleep state. */
-
status = acpi_evaluate_object(NULL, METHOD_NAME__SST, _list, NULL);
if (ACPI_FAILURE(status) && status != AE_NOT_FOUND) {
ACPI_EXCEPTION((AE_INFO, status,
"While executing method _SST"));
}
 
-   /* Disable/Clear all GPEs */
-
-   status = acpi_hw_disable_all_gpes();
-
return_ACPI_STATUS(status);
 }
 
-ACPI_EXPORT_SYMBOL(acpi_enter_sleep_state_prep)
-
 
/***
  *
  * FUNCTION:acpi_enter_sleep_state_prep_late
@@ -669,12 +694,6 @@ acpi_status acpi_leave_sleep_state(u8 sl
acpi_set_register(acpi_gbl_fixed_event_info
  [ACPI_EVENT_POWER_BUTTON].status_register_id, 1);
 
-   arg.integer.value = ACPI_SST_WORKING;
-   status = acpi_evaluate_object(NULL, METHOD_NAME__SST, _list, NULL);
-   if (ACPI_FAILURE(status) && status != AE_NOT_FOUND) {
-   ACPI_EXCEPTION((AE_INFO, status, "During Method _SST"));
-   }
-
return_ACPI_STATUS(status);
 }
 
Index: linux-2.6.23-rc3/drivers/acpi/sleep/main.c
===
--- linux-2.6.23-rc3.orig/drivers/acpi/sleep/main.c
+++ linux-2.6.23-rc3/drivers/acpi/sleep/main.c
@@ -70,6 +70,8 @@ static int acpi_pm_prepare(void)
 
if (error)
acpi_target_sleep_state = ACPI_STATE_S0;
+   else
+   acpi_set_sleep_state_indicator(acpi_target_sleep_state);
 
return error;
 }
@@ -186,6 +188,7 @@ static void acpi_pm_finish(void)
acpi_set_firmware_waking_vector((acpi_physical_address) 0);
 
acpi_target_sleep_state = ACPI_STATE_S0;
+   acpi_set_sleep_state_indicator(ACPI_STATE_S0);
 
 #ifdef CONFIG_X86
if (init_8259A_after_S1) {
@@ -246,9 +249,33 @@ static struct dmi_system_id __initdata a
 static int acpi_hibernation_start(void)
 {
acpi_target_sleep_state = ACPI_STATE_S4;
+
return 0;
 }
 
+static int

[PATCH -mm 1/3] Hibernation: Enter platform hibernation state in a consistent way (rev. 3)

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

Make hibernation_platform_enter() execute the enter-a-sleep-state sequence
instead of the mixed shutdown-with-entering-S4 thing.

Replace the shutting down of devices done by kernel_shutdown_prepare(), before
entering the ACPI S4 sleep state, with suspending them and the shutting down of
sysdevs with calling device_power_down(PMSG_SUSPEND) (just like before entering
S1 or S3, but the target state is now S4).  Also, disable the nonboot CPUs
before entering the sleep state (S4), which generally always is a good idea.

This is known to fix the "double disk spin down during hibernation" on some
machines, eg. HPC nx6325 (ref. http://lkml.org/lkml/2007/8/7/316 and the
following thread).  It also generally causes the hibernation state (ACPI S4) to
be entered faster.

Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
Acked-by: Pavel Machek <[EMAIL PROTECTED]>
---
 kernel/power/disk.c |   55 ++--
 1 file changed, 41 insertions(+), 14 deletions(-)

Index: linux-2.6.23-rc3/kernel/power/disk.c
===
--- linux-2.6.23-rc3.orig/kernel/power/disk.c
+++ linux-2.6.23-rc3/kernel/power/disk.c
@@ -222,21 +222,48 @@ int hibernation_platform_enter(void)
 {
int error;
 
-   if (hibernation_ops) {
-   kernel_shutdown_prepare(SYSTEM_SUSPEND_DISK);
-   /*
-* We have cancelled the power transition by running
-* hibernation_ops->finish() before saving the image, so we
-* should let the firmware know that we're going to enter the
-* sleep state after all
-*/
-   error = hibernation_ops->prepare();
-   sysdev_shutdown();
-   if (!error)
-   error = hibernation_ops->enter();
-   } else {
-   error = -ENOSYS;
+   if (!hibernation_ops)
+   return -ENOSYS;
+
+   /*
+* We have cancelled the power transition by running
+* hibernation_ops->finish() before saving the image, so we should let
+* the firmware know that we're going to enter the sleep state after all
+*/
+   error = hibernation_ops->start();
+   if (error)
+   return error;
+
+   suspend_console();
+   error = device_suspend(PMSG_SUSPEND);
+   if (error)
+   return error;
+
+   error = hibernation_ops->prepare();
+   if (error)
+   goto Resume_devices;
+
+   error = disable_nonboot_cpus();
+   if (error)
+   goto Finish;
+
+   local_irq_disable();
+   error = device_power_down(PMSG_SUSPEND);
+   if (!error) {
+   hibernation_ops->enter();
+   /* We should never get here */
+   while (1);
}
+   local_irq_enable();
+
+   /*
+* We don't need to reenable the nonboot CPUs or resume consoles, since
+* the system is going to be halted anyway.
+*/
+ Finish:
+   hibernation_ops->finish();
+ Resume_devices:
+   device_resume();
return error;
 }
 
-
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 source address to sunrpc svc errors

2007-08-27 Thread J. Bruce Fields

On Sat, Aug 25, 2007 at 04:09:27PM +0100, Dr. David Alan Gilbert wrote:
>   This patch adds the address of the client that caused an
> error in sunrpc/svc.c so that you get errors that look like:
> 
> svc: 192.168.66.28, port=709: unknown version (3 for prog 13, nfsd)
> 
> I've seen machines which get bunches of unknown version or similar
> errors from time to time, and while the recent patch to add
> the service helps to find which service has the wrong version it doesn't
> help find the potentially bad client.

Looks like a reasonable idea to me, thanks!  Any objection to just
calling it "svc_printk" instead of "svc_printkerr"?

I also wonder whether these shouldn't all be dprintk's instead of
printk's.  One misbehaving client could create a lot of noise in the
logs.

--b.
-
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 -mm 0/3] PM: Improve ACPI handling during suspend and hibernation (rev. 3)

Hi,

The patches in this series are intended to improve the handling of the ACPI
platform during suspend and hibernation.

They do the following things:
* make hibernation_platform_enter() consistent with the sleep state entering
  code in kernel/power/main.c
* introduce global platform callbacks allowing us to handle ACPI in a more fine
  grained way during suspend and hibernation
* improve the handling of the system status indicator during suspend and
  hibernation.

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: Configuring previously loaded module

2007-08-27 Thread Thiago Ramos dos Santos

It worked.
Thanks a lot.

Thiago

On 8/26/07, Kay Sievers <[EMAIL PROTECTED]> wrote:
> On 8/27/07, Thiago Ramos dos Santos <[EMAIL PROTECTED]> wrote:
> > I have 2 devices which use the usbserial module: a CDMA modem and a
> > Palm PDA (to be more especific, the PDA uses the visor module, which
> > uses the usbserial).
> > When I plug the PDA to the computer, the visor module gets
> > automatically loaded by the kernel, and so is the usbserial module.
> > When the modem is pluged, the module is not loaded automaticaly, so I
> > created a hotplug entry for it.
> > For both devices I put rules in udev configuration files, so they are
> > autmaticaly mapped to the same /dev node in despite of the ttyUSB*
> > node they are mapped to.
> >
> > The problem is that the modem requires the usbserial module to be
> > loaded with some parameters: product=x vendor=x. So, if I plug
> > the PDA first, the usbserial is loaded without those parameters, and
> > when the modem is pluged, the ttyUSB nodes are not created for it. So
> > I have to manually unload both the visor and usbserial modules, reload
> > the usbserial with the specific parameters (to get the ttyUSB nodes
> > for the modem) and reload the visor module (to recreate the ttyUSB
> > nodes for the PDA).
> >
> > Is there anyway to configure the previously loaded usbserial module
> > with the modem parameters without having to unload it? If it is not
> > possible, is there any other solution?
>
> Try putting:
>   options usbserial product=x vendor=x
> in:
>   /etc/modprobe.d/serial
>
> Kay
>
-
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: issues concerning the next NAPI interface

2007-08-27 Thread James Chapman

David Miller wrote:

From: James Chapman <[EMAIL PROTECTED]>
Date: Mon, 27 Aug 2007 16:51:29 +0100

To implement this, there's no need for timers, hrtimers or generic NAPI 
support that others have suggested. A driver's poll() would set an 
internal flag and record the current jiffies value when finding 
workdone=0 rather than doing an immediate napi_complete(). Early in 
poll() it would test this flag and if set, do a low-cost test to see if 
it had any work to do. If no work, it would check the saved jiffies 
value and do the napi_complete() only if no work has been done for a 
configurable number of jiffies. This keeps interrupts disabled longer at 
the expense of many more calls to poll() where no work is done. So 
critical to this scheme is modifying the driver's poll() to fastpath the 
case of having no work to do while waiting for its local jiffy count to 
expire.

Here's an untested patch for tg3 that illustrates the idea.

It's only going to work with hrtimers, these interfaces can
process at least 100,000 per jiffies tick.

I don't understand where hrtimers or interface speed comes in. If the 
CPU is fast enough to call poll() 100,000 times per jiffies tick, it 
means 100,000 wasted poll() calls while the netdev migrates from active 
to poll-off state. Hence the need to fastpath the "no work" case in the 
netdev's poll(). These extra poll() calls are tolerable if it avoids 
NAPI thrashing between poll-on and poll-off states for certain packet rates.

And the hrtimer granularity is going to need to be significantly low,
and futhermore you're adding a guaranteed extra interrupt (for the
hrtimer firing) in these cases where we're exactly trying to avoid is
more interrupts.

If you can make it work, fine, but it's going to need to be at a
minimum disabled when the hrtimer granularity is not sufficient.

But there are huger fish to fry for you I think.  Talk to your
platform maintainers and ask for an interface for obtaining
a flat static distribution of interrupts to cpus in order to
support multiqueue NAPI better.

In your previous postings you made arguments saying that the
automatic placement of interrupts to cpus made everything
bunch of to a single cpu and you wanted to propagate the
NAPI work to other cpu's software interrupts from there.

I don't recall saying anything in previous posts about this. Are you 
confusing my posts with Jan-Bernd's? Jan-Bernd has been talking about 
using hrtimers to _reschedule_ NAPI. My posts are suggesting an 
alternative mechanism that keeps NAPI active (with interrupts disabled) 
for a jiffy or two after it would otherwise have gone idle in order to 
avoid too many interrupts when the packet rate is such that NAPI 
thrashes between poll-on and poll-off.

That logic is bogus, because it merely proves that the hardware
interrupt distribution is broken.  If it's a bad cpu to run
software interrupts on, it's also a bad cpu to run hardware
interrupts on.

--
James Chapman
Katalix Systems Ltd
http://www.katalix.com
Catalysts for your Embedded Linux software development

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [-mm patch] make types.h usable for non-gcc C parsers

2007-08-27 Thread Mike Frysinger

On 8/27/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> On Mon, Aug 27, 2007 at 05:34:21PM -0400, Mike Frysinger wrote:
> > On 8/27/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > > This patch makes the 64bit integers on 32bit architectures usable for
> > > all C parsers that know about "long long".
> >
> > ah, yet another attempt at this stuff
> >
> > you probably need to update linux/types.h as well
>
> What problems do you observe with linux/types.h?

just grep for __GNUC__ ...

#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
typedef __u64   uint64_t;
typedef __u64   u_int64_t;
typedef __s64   int64_t;
#endif

#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
typedef __u64 __bitwise __le64;
typedef __u64 __bitwise __be64;
#endif

you've made available __u64 and __s64, but not the rest ...
-mike
-
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] clean up exports in fs/{open,read_write}.c

2007-08-27 Thread Christoph Hellwig

On Fri, Aug 24, 2007 at 11:33:10AM +0800, Eugene Teo wrote:
> Takashi-san fixed sound/isa/wavefront/wavefront_synth.c to use
> request_firmware instead of sys_*. Since that is the last driver in the
> kernel that uses sys_{read,close}, this patch kills these exports. sys_open
> is left exported for sparc64 only.

I can't find any spar user of it, so please kill it.  In the case a symbol
is needed only for a particular architecture it's better to do it in the
architecture-specific ksyms file than with an ifdef, btw.

-
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] SLUB use cmpxchg_local

2007-08-27 Thread Mathieu Desnoyers

* Christoph Lameter ([EMAIL PROTECTED]) wrote:
> On Mon, 27 Aug 2007, Mathieu Desnoyers wrote:
> 
> > > a clean solution source code wise. It also minimizes the interrupt 
> > > holdoff 
> > > for the non-cmpxchg_local arches. However, it means that we will have to 
> > > disable interrupts twice for the slow path. If that is too expensive then 
> > > we need a different solution.
> > > 
> > 
> > cmpxchg_local is not used on the slow path... ?
> 
> Right.
> 
> > Did you meant:
> > 
> > it means that we will have to disable preemption _and_ interrupts on the
> > fast path for non-cmpxchg_local arches ?
> 
> We would have to disable preemption and interrupts once on the fast path. 
> The interrupt holdoff would just be a couple of instructions.
> 

Right.

> The slow path would require disable preemption and two interrupt disables.
> 

If the slow path have to call new_slab, then yes. But it seems that not
every slow path must call it, so for the other slow paths, only one
interrupt disable would be required.

> Question is if this makes sense performance wise. If not then we may have 
> to look at more complicated schemes.
> 

Yep, such as the arch_have_cmpxchg() macro that I proposed, but it
really hurts my eyes... :(

Mathieu

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
-
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: "double" hpet clocksource && hard freeze [bisected]

2007-08-27 Thread john stultz

On Mon, 2007-08-27 at 17:34 -0300, Luiz Fernando N. Capitulino wrote:
> Em Fri, 24 Aug 2007 11:17:34 -0700
> john stultz <[EMAIL PROTECTED]> escreveu:
> 
> | On Fri, 2007-08-24 at 08:46 -0400, Bob Picco wrote:
> | > john stultz wrote:[Thu Aug 23 2007, 05:41:45PM EDT]
> | > > On Thu, 2007-08-23 at 14:05 -0700, john stultz wrote:
> | > > > On Thu, 2007-08-23 at 13:41 -0700, Luck, Tony wrote:
> | > > > > > I have a double "hpet" entry in "available_clocksource":
> | > > > > >   $ cat 
> /sys/devices/system/clocksource/clocksource0/available_clocksource
> | > > > > >   tsc hpet hpet acpi_pm jiffies
> | > > > > 
> | > > > > Oops.  If seems that both drivers/char/hpet.c and 
> arch/x86_64/kernel/hpet.c
> | > > > > both register a clocksource named "hpet".  Probably a result of 
> bringing
> | > > > > back to life a long lost patch, and having someone else (John 
> Stultz, according
> | > > > > to git blame) make a similar change to a different file in the 
> intervening
> | > > > > time.
> | > > > > 
> | > > > > Presumably the thing to do would be merge the x86_64 specific 
> version
> | > > > > into the drivers/char/hpet.c version?
> | > > > 
> | > > > Ugh. Yea. i386 has an hpet clocksource as well. We should kill the
> | > > > duplication, but at the moment I'm not comfortable that the
> | > > > driver/char/hpet.c is ok to be used for i386/x86_64 (Bob: Do you know
> | > > > why the shift value is only 10?).
> | > > > 
> | > > > 
> | > > > I'm a little surprised by this, as the clocksource code use to prevent
> | > > > duplicate named clocksources from being registered, so I'm not sure 
> how
> | > > > that check got dropped.  Also I'm not quite sure I see where the hard
> | > > > freeze is coming from.
> | > > > 
> | > > > My initial reaction would be to either ifdef ia64 implementation in
> | > > > drivers/char/hpet.c or move the code under the ia64 arch dir until it 
> is
> | > > > really usable by all arches.
> | > > 
> | > > Here is a possible quick fix. I'm open to other approaches, but I also
> | > > want to avoid too much churn before 2.6.23 goes out.
> | > > 
> | > > Paolo, could you verify this fixes the issue for you?
> | > > 
> | > > thanks
> | > > -john
> | > > 
> | > [snip]
> | > 
> | > I saw what was missed by me in my brief examination of this last night.
> | > The platform registers the hpet clocksource too.
> | > 
> | > Instead of adding the config flag to hpet driver, how about the patch
> | > below? Since you already check for duplication by address then adding
> | > a check for by name too seems okay to me.
> | > 
> | > bob
> | > 
> | > 
> | > Prevent duplicate names being registered with clocksource. This also
> | > eliminates the duplication of hpet clock registration when the arch
> | > uses the hpet timer and the hpet driver does too. The patch was
> | > compile and link tested.
> | 
> | Yea. While I'm still not completely comfortable leaving this up to boot
> | order alone (the ia64 hpet clocksource is clearly causing issues on
> | x86_64), I think this patch is something we need as well.
> 
>  Does -stable need this too?

Looking at the git log, the ia64 clocksource code didn't land until
7/20, so I don't think so.

thanks
-john


-
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 01/23] introduce drm_zalloc as a drm_alloc + memset replacement

2007-08-27 Thread Mariusz Kozlowski

> Add drm_zalloc().

Ugh. Too fast. Ofcourse this is the correct version. Sorry.

Signed-off-by: Mariusz Kozlowski <[EMAIL PROTECTED]>

--- linux-2.6.23-rc3-mm1-a/drivers/char/drm/drmP.h  2007-08-27 
18:32:26.0 +0200
+++ linux-2.6.23-rc3-mm1-b/drivers/char/drm/drmP.h  2007-08-26 
15:34:40.0 +0200
@@ -1125,10 +1125,17 @@ static __inline__ void *drm_calloc(size_
 {
return kcalloc(nmemb, size, GFP_KERNEL);
 }
+
+/** Wrapper around kzalloc() */
+static __inline__ void *drm_zalloc(size_t size, int area)
+{
+   return kzalloc(size, GFP_KERNEL);
+}
 #else
 extern void *drm_alloc(size_t size, int area);
 extern void drm_free(void *pt, size_t size, int area);
 extern void *drm_calloc(size_t nmemb, size_t size, int area);
+extern void *drm_zalloc(size_t size, int area);
 #endif

 /[EMAIL PROTECTED]/
--- linux-2.6.23-rc3-mm1-a/drivers/char/drm/drm_memory_debug.h  2007-08-27 
18:32:26.0 +0200
+++ linux-2.6.23-rc3-mm1-b/drivers/char/drm/drm_memory_debug.h  2007-08-27 
23:28:31.0 +0200
@@ -167,13 +167,24 @@ void *drm_alloc (size_t size, int area)
 void *drm_calloc (size_t nmemb, size_t size, int area) {
void *addr;

-   addr = drm_alloc (nmemb * size, area);
-   if (addr != NULL)
-   memset((void *)addr, 0, size * nmemb);
+   addr = drm_alloc(nmemb * size, area);
+   if (addr)
+   memset(addr, 0, size * nmemb);

return addr;
 }

+void *drm_zalloc(size_t size, int area)
+{
+   void *addr;
+
+   addr = drm_alloc(size, area);
+   if (addr)
+   memset(addr, 0, size);
+
+   return addr;
+}
+
 void *drm_realloc (void *oldpt, size_t oldsize, size_t size, int area) {
void *pt;

-
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: [-mm patch] make types.h usable for non-gcc C parsers

On Mon, Aug 27, 2007 at 05:34:21PM -0400, Mike Frysinger wrote:
> On 8/27/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > This patch makes the 64bit integers on 32bit architectures usable for
> > all C parsers that know about "long long".
> 
> ah, yet another attempt at this stuff
> 
> you probably need to update linux/types.h as well

What problems do you observe with linux/types.h?

> -mike

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-
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] trivial - constify sched.h

2007-08-27 Thread Alexey Dobriyan

On Mon, Aug 27, 2007 at 01:40:31PM -0700, Joe Perches wrote:
> Add const to some struct task_struct * uses

Why, oh, why? This way code there are more characters on screen and zero
change in vmlinux, at least here.

> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -1222,22 +1222,22 @@ static inline int rt_prio(int prio)
>   return 0;
>  }
>  
> -static inline int rt_task(struct task_struct *p)
> +static inline int rt_task(const struct task_struct *p)
>  {
>   return rt_prio(p->prio);
>  }
...
-
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 -mm 1/4] Hibernation: Arbitrary boot kernel support - generic code (rev. 2)

On Mon 2007-08-27 23:33:43, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <[EMAIL PROTECTED]>
> 
> Add the bits needed for supporting arbitrary boot kernels to the common
> hibernation code.
> 
> To support arbitrary boot kernels, make it possible to replace the 'struct
> new_utsname' and the kernel version in the hibernation image header by some
> architecture specific data that will be used to verify if the image is valid
> and to restore the image.
> 
> Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>

ACK.

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [-mm patch] make types.h usable for non-gcc C parsers

2007-08-27 Thread Mike Frysinger

On 8/27/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> This patch makes the 64bit integers on 32bit architectures usable for
> all C parsers that know about "long long".

ah, yet another attempt at this stuff

you probably need to update linux/types.h as well
-mike
-
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 -mm 1/4] Hibernation: Arbitrary boot kernel support - generic code (rev. 2)

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

Add the bits needed for supporting arbitrary boot kernels to the common
hibernation code.

To support arbitrary boot kernels, make it possible to replace the 'struct
new_utsname' and the kernel version in the hibernation image header by some
architecture specific data that will be used to verify if the image is valid
and to restore the image.

Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
---
 kernel/power/power.h|   20 +-
 kernel/power/snapshot.c |   53 +++-
 2 files changed, 54 insertions(+), 19 deletions(-)

Index: linux-2.6.23-rc3/kernel/power/power.h
===
--- linux-2.6.23-rc3.orig/kernel/power/power.h  2007-08-23 23:13:34.0 
+0200
+++ linux-2.6.23-rc3/kernel/power/power.h   2007-08-25 21:18:59.0 
+0200
@@ -11,14 +11,32 @@ struct swsusp_info {
unsigned long   size;
 } __attribute__((aligned(PAGE_SIZE)));
 
+#ifdef CONFIG_HIBERNATION
+#ifdef CONFIG_ARCH_HIBERNATION_HEADER
+/* Maximum size of architecture specific data in a hibernation header */
+#define MAX_ARCH_HEADER_SIZE   (sizeof(struct new_utsname) + 4)
 
+extern int arch_hibernation_header_save(void *addr, unsigned int max_size);
+extern int arch_hibernation_header_restore(void *addr);
+
+static inline int init_header_complete(struct swsusp_info *info)
+{
+   return arch_hibernation_header_save(info, MAX_ARCH_HEADER_SIZE);
+}
+
+static inline char *check_image_kernel(struct swsusp_info *info)
+{
+   return arch_hibernation_header_restore(info) ?
+   "architecture specific data" : NULL;
+}
+#endif /* CONFIG_ARCH_HIBERNATION_HEADER */
 
-#ifdef CONFIG_HIBERNATION
 /*
  * Keep some memory free so that I/O operations can succeed without paging
  * [Might this be more than 4 MB?]
  */
 #define PAGES_FOR_IO   ((4096 * 1024) >> PAGE_SHIFT)
+
 /*
  * Keep 1 MB of memory free so that device drivers can allocate some pages in
  * their .suspend() routines without breaking the suspend to disk.
Index: linux-2.6.23-rc3/kernel/power/snapshot.c
===
--- linux-2.6.23-rc3.orig/kernel/power/snapshot.c   2007-08-23 
23:13:34.0 +0200
+++ linux-2.6.23-rc3/kernel/power/snapshot.c2007-08-25 21:21:55.0 
+0200
@@ -1239,17 +1239,39 @@ asmlinkage int swsusp_save(void)
return 0;
 }
 
-static void init_header(struct swsusp_info *info)
+#ifndef CONFIG_ARCH_HIBERNATION_HEADER
+static int init_header_complete(struct swsusp_info *info)
 {
-   memset(info, 0, sizeof(struct swsusp_info));
+   memcpy(>uts, init_utsname(), sizeof(struct new_utsname));
info->version_code = LINUX_VERSION_CODE;
+   return 0;
+}
+
+static char *check_image_kernel(struct swsusp_info *info)
+{
+   if (info->version_code != LINUX_VERSION_CODE)
+   return "kernel version";
+   if (strcmp(info->uts.sysname,init_utsname()->sysname))
+   return "system type";
+   if (strcmp(info->uts.release,init_utsname()->release))
+   return "kernel release";
+   if (strcmp(info->uts.version,init_utsname()->version))
+   return "version";
+   if (strcmp(info->uts.machine,init_utsname()->machine))
+   return "machine";
+   return NULL;
+}
+#endif /* CONFIG_ARCH_HIBERNATION_HEADER */
+
+static int init_header(struct swsusp_info *info)
+{
+   memset(info, 0, sizeof(struct swsusp_info));
info->num_physpages = num_physpages;
-   memcpy(>uts, init_utsname(), sizeof(struct new_utsname));
-   info->cpus = num_online_cpus();
info->image_pages = nr_copy_pages;
info->pages = nr_copy_pages + nr_meta_pages + 1;
info->size = info->pages;
info->size <<= PAGE_SHIFT;
+   return init_header_complete(info);
 }
 
 /**
@@ -1303,7 +1325,11 @@ int snapshot_read_next(struct snapshot_h
return -ENOMEM;
}
if (!handle->offset) {
-   init_header((struct swsusp_info *)buffer);
+   int error;
+
+   error = init_header((struct swsusp_info *)buffer);
+   if (error)
+   return error;
handle->buffer = buffer;
memory_bm_position_reset(_bm);
memory_bm_position_reset(_bm);
@@ -1394,22 +1420,13 @@ duplicate_memory_bitmap(struct memory_bi
}
 }
 
-static inline int check_header(struct swsusp_info *info)
+static int check_header(struct swsusp_info *info)
 {
-   char *reason = NULL;
+   char *reason;
 
-   if (info->version_code != LINUX_VERSION_CODE)
-   reason = "kernel version";
-   if (info->num_physpages != num_physpages)
+   reason = check_image_kernel(info);
+   if (!reason && info->num_physpages != num_physpages)
reason = "memory size";
-   if

Re: cpu hotplug support broken in 2.6.23-rc3

On Mon 2007-08-27 22:36:57, Jeff Chua wrote:
> On 8/27/07, Pavel Machek <[EMAIL PROTECTED]> wrote:
> > On Mon 2007-08-27 12:43:50, Pavel Machek wrote:
> > > Hi!
> > >
> > > Trying to do few onlines/offlines reliably hangs my machine (thinkpad
> > > x60, i386 architecture).
> 
> I just 3 cycles of on-line/off-line on 2.6.23-rc3 on ThinkPad x60s,
> and my system still survives.

Can you try 20-or-so tests? Mine hangs randomly, so it survived 4 or
so cycles at one point.

...or maybe difference is in the .config, or maybe I broken something
in my kernel sources
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH -mm 4/4] Hibernation: Use temporary page tables for kernel text mapping on x86_64

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

Use temporary page tables for the kernel text mapping during hibernation restore
on x86_64.

Without the patch, the original boot kernel's page tables that represent the
kernel text mapping are used while the core of the image kernel is being
restored.  However, in principle, if the boot kernel is not identical to the
image kernel, the location of these page tables in the image kernel need not be
the same, so we should create a safe copy of the kernel text mapping prior to
restoring the core of the image kernel.

Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
Acked-by: Pavel Machek <[EMAIL PROTECTED]>
---
 arch/x86_64/kernel/suspend.c |   39 +--
 1 file changed, 33 insertions(+), 6 deletions(-)

Index: linux-2.6.23-rc3/arch/x86_64/kernel/suspend.c
===
--- linux-2.6.23-rc3.orig/arch/x86_64/kernel/suspend.c  2007-08-25 
22:51:56.0 +0200
+++ linux-2.6.23-rc3/arch/x86_64/kernel/suspend.c   2007-08-25 
22:53:01.0 +0200
@@ -191,25 +191,42 @@ static int res_phys_pud_init(pud_t *pud,
return 0;
 }
 
+static int res_kernel_text_pud_init(pud_t *pud, unsigned long start)
+{
+   pmd_t *pmd;
+   unsigned long paddr;
+
+   pmd = (pmd_t *)get_safe_page(GFP_ATOMIC);
+   if (!pmd)
+   return -ENOMEM;
+   set_pud(pud + pud_index(start), __pud(__pa(pmd) | _KERNPG_TABLE));
+   for (paddr = 0; paddr < KERNEL_TEXT_SIZE; pmd++, paddr += PMD_SIZE) {
+   unsigned long pe;
+
+   pe = __PAGE_KERNEL_LARGE_EXEC | _PAGE_GLOBAL | paddr;
+   pe &= __supported_pte_mask;
+   set_pmd(pmd, __pmd(pe));
+   }
+
+   return 0;
+}
+
 static int set_up_temporary_mappings(void)
 {
unsigned long start, end, next;
+   pud_t *pud;
int error;
 
temp_level4_pgt = (pgd_t *)get_safe_page(GFP_ATOMIC);
if (!temp_level4_pgt)
return -ENOMEM;
 
-   /* It is safe to reuse the original kernel mapping */
-   set_pgd(temp_level4_pgt + pgd_index(__START_KERNEL_map),
-   init_level4_pgt[pgd_index(__START_KERNEL_map)]);
-
/* Set up the direct mapping from scratch */
start = (unsigned long)pfn_to_kaddr(0);
end = (unsigned long)pfn_to_kaddr(end_pfn);
 
for (; start < end; start = next) {
-   pud_t *pud = (pud_t *)get_safe_page(GFP_ATOMIC);
+   pud = (pud_t *)get_safe_page(GFP_ATOMIC);
if (!pud)
return -ENOMEM;
next = start + PGDIR_SIZE;
@@ -220,7 +237,17 @@ static int set_up_temporary_mappings(voi
set_pgd(temp_level4_pgt + pgd_index(start),
mk_kernel_pgd(__pa(pud)));
}
-   return 0;
+
+   /* Set up the kernel text mapping from scratch */
+   pud = (pud_t *)get_safe_page(GFP_ATOMIC);
+   if (!pud)
+   return -ENOMEM;
+   error = res_kernel_text_pud_init(pud, __START_KERNEL_map);
+   if (!error)
+   set_pgd(temp_level4_pgt + pgd_index(__START_KERNEL_map),
+   __pgd(__pa(pud) | _PAGE_TABLE));
+
+   return error;
 }
 
 int swsusp_arch_resume(void)
-
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 -mm 3/4] Hibernation: Pass CR3 in the image header on x86_64 (rev. 2)

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

Since we already pass the address of restore_registers() in the image header,
we can also pass the value of the CR3 register from before the hibernation in
the same way.  This will allow us to avoid using init_level4_pgt page tables
during the restore.

Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
Acked-by: Pavel Machek <[EMAIL PROTECTED]>
---
 arch/x86_64/kernel/suspend.c |   16 
 arch/x86_64/kernel/suspend_asm.S |8 +---
 2 files changed, 17 insertions(+), 7 deletions(-)

Index: linux-2.6.23-rc3/arch/x86_64/kernel/suspend.c
===
--- linux-2.6.23-rc3.orig/arch/x86_64/kernel/suspend.c  2007-08-25 
22:11:43.0 +0200
+++ linux-2.6.23-rc3/arch/x86_64/kernel/suspend.c   2007-08-25 
22:51:56.0 +0200
@@ -150,6 +150,12 @@ extern int restore_image(void);
  */
 unsigned long restore_jump_address;
 
+/*
+ * Value of the cr3 register from before the hibernation (this value is passed
+ * in the image header).
+ */
+unsigned long restore_cr3;
+
 pgd_t *temp_level4_pgt;
 
 void *relocated_restore_code;
@@ -248,7 +254,8 @@ int pfn_is_nosave(unsigned long pfn)
 
 struct restore_data_record {
unsigned long jump_address;
-   unsigned long control;
+   unsigned long cr3;
+   unsigned long magic;
 };
 
 #define RESTORE_MAGIC  0x0123456789ABCDEFUL
@@ -265,7 +272,8 @@ int arch_hibernation_header_save(void *a
if (max_size < sizeof(struct restore_data_record))
return -EOVERFLOW;
rdr->jump_address = restore_jump_address;
-   rdr->control = (restore_jump_address ^ RESTORE_MAGIC);
+   rdr->cr3 = restore_cr3;
+   rdr->magic = RESTORE_MAGIC;
return 0;
 }
 
@@ -279,7 +287,7 @@ int arch_hibernation_header_restore(void
struct restore_data_record *rdr = addr;
 
restore_jump_address = rdr->jump_address;
-   return (rdr->control == (restore_jump_address ^ RESTORE_MAGIC)) ?
-   0 : -EINVAL;
+   restore_cr3 = rdr->cr3;
+   return (rdr->magic == RESTORE_MAGIC) ? 0 : -EINVAL;
 }
 #endif /* CONFIG_HIBERNATION */
Index: linux-2.6.23-rc3/arch/x86_64/kernel/suspend_asm.S
===
--- linux-2.6.23-rc3.orig/arch/x86_64/kernel/suspend_asm.S  2007-08-25 
22:10:25.0 +0200
+++ linux-2.6.23-rc3/arch/x86_64/kernel/suspend_asm.S   2007-08-25 
22:51:56.0 +0200
@@ -39,6 +39,9 @@ ENTRY(swsusp_arch_suspend)
/* save the address of restore_registers */
movq$restore_registers, %rax
movq%rax, restore_jump_address(%rip)
+   /* save cr3 */
+   movq%cr3, %rax
+   movq%rax, restore_cr3(%rip)
 
call swsusp_save
ret
@@ -60,6 +63,7 @@ ENTRY(restore_image)
 
/* prepare to jump to the image kernel */
movqrestore_jump_address(%rip), %rax
+   movqrestore_cr3(%rip), %rbx
 
/* prepare to copy image data to their original locations */
movqrestore_pblist(%rip), %rdx
@@ -98,9 +102,7 @@ done:
 
 ENTRY(restore_registers)
/* go back to the original page tables */
-   movq$(init_level4_pgt - __START_KERNEL_map), %rax
-   addqphys_base(%rip), %rax
-   movq%rax, %cr3
+   movq%rbx, %cr3
 
/* Flush TLB, including "global" things (vmalloc) */
movqmmu_cr4_features(%rip), %rax
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH -mm 0/4] Hibernation: Arbitrary boot kernel support on x86_64 (rev. 2)

Hi,

The first two patches in this series make it possible to restore the memory
state from a hibernation image with the help of a kernel different from the
image one.

The first patch adds the generic, platform independent code needed for that.
The second patch implements the idea on x86_64.

The remaining two patches remove some implicit assumptions about the boot and
image kernels from the x86_64 restore code.

Greetings,
Rafael


-- 
"Premature optimization is the root of all evil." - Donald Knuth

-
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 -mm 2/4] Hibernation: Arbitrary boot kernel support on x86_64 (rev. 2)

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

Make it possible to restore a hibernation image on x86_64 with the help of a
kernel different from the one in the image.

The idea is to split the core restoration code into two separate parts and to
place each of them in a different page.  The first part belongs to the boot
kernel and is executed as the last step of the image kernel's memory restoration
procedure.  Before being executed, it is relocated to a safe page that won't be
overwritten while copying the image kernel pages.

The final operation performed by it is a jump to the second part of the core
restoration code that belongs to the image kernel and has just been restored.
This code makes the CPU switch to the image kernel's page tables and
restores the state of general purpose registers (including the stack pointer)
from before the hibernation.

The main issue with this idea is that in order to jump to the second part of the
core restoration code the boot kernel needs to know its address.  However, this
address may be passed to it in the image header.  Namely, the part of the image
header previously used for checking if the version of the image kernel is
correct can be replaced with some architecture specific data that will allow
the boot kernel to jump to the right address within the image kernel.  These
data should also be used for checking if the image kernel is compatible with
the boot kernel (as far as the memory restroration procedure is concerned).
It can be done, for example, with the help of a "magic" value that has to be
equal in both kernels, so that they can be regarded as compatible.

Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
Acked-by: Pavel Machek <[EMAIL PROTECTED]>
---
 arch/x86_64/Kconfig  |5 +++
 arch/x86_64/kernel/suspend.c |   54 ++-
 arch/x86_64/kernel/suspend_asm.S |   41 -
 include/asm-x86_64/suspend.h |3 ++
 4 files changed, 95 insertions(+), 8 deletions(-)

Index: linux-2.6.23-rc3/arch/x86_64/kernel/suspend_asm.S
===
--- linux-2.6.23-rc3.orig/arch/x86_64/kernel/suspend_asm.S  2007-08-25 
22:09:53.0 +0200
+++ linux-2.6.23-rc3/arch/x86_64/kernel/suspend_asm.S   2007-08-25 
22:10:25.0 +0200
@@ -2,8 +2,8 @@
  *
  * Distribute under GPLv2.
  *
- * swsusp_arch_resume may not use any stack, nor any variable that is
- * not "NoSave" during copying pages:
+ * swsusp_arch_resume must not use any stack or any nonlocal variables while
+ * copying pages:
  *
  * Its rewriting one kernel image with another. What is stack in "old"
  * image could very well be data page in "new" image, and overwriting
@@ -36,6 +36,10 @@ ENTRY(swsusp_arch_suspend)
pushfq
popqpt_regs_eflags(%rax)
 
+   /* save the address of restore_registers */
+   movq$restore_registers, %rax
+   movq%rax, restore_jump_address(%rip)
+
call swsusp_save
ret
 
@@ -54,7 +58,16 @@ ENTRY(restore_image)
movq%rcx, %cr3;
movq%rax, %cr4;  # turn PGE back on
 
+   /* prepare to jump to the image kernel */
+   movqrestore_jump_address(%rip), %rax
+
+   /* prepare to copy image data to their original locations */
movqrestore_pblist(%rip), %rdx
+   movqrelocated_restore_code(%rip), %rcx
+   jmpq*%rcx
+
+   /* code below has been relocated to a safe page */
+ENTRY(core_restore_code)
 loop:
testq   %rdx, %rdx
jz  done
@@ -62,7 +75,7 @@ loop:
/* get addresses from the pbe and copy the page */
movqpbe_address(%rdx), %rsi
movqpbe_orig_address(%rdx), %rdi
-   movq$512, %rcx
+   movq$(PAGE_SIZE >> 3), %rcx
rep
movsq
 
@@ -70,6 +83,20 @@ loop:
movqpbe_next(%rdx), %rdx
jmp loop
 done:
+   /* jump to the restore_registers address from the image header */
+   jmpq*%rax
+   /*
+* NOTE: This assumes that the boot kernel's text mapping covers the
+* image kernel's page containing restore_registers and the address of
+* this page is the same as in the image kernel's text mapping (it
+* should always be true, because the text mapping is linear, starting
+* from 0, and is supposed to cover the entire kernel text for every
+* kernel).
+*
+* code below belongs to the image kernel
+*/
+
+ENTRY(restore_registers)
/* go back to the original page tables */
movq$(init_level4_pgt - __START_KERNEL_map), %rax
addqphys_base(%rip), %rax
@@ -84,10 +111,7 @@ done:
movq%rcx, %cr3
movq%rax, %cr4;  # turn PGE back on
 
-   movl$24, %eax
-   movl%eax, %ds
-
-   /* We don't restore %rax, it must be 0 anyway */
+   /* restore GPRs (we don't restore %rax, it must be 0 anyway) */
movq

[2.6 patch] drivers/scsi/imm.c: fix check-after-use

The Coverity checker spotted that we have already oops'ed if "cmd"
was NULL.

Since "cmd" being NULL doesn't seem to be possible at this point this 
patch removes the NULL check.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

This patch has been sent on:
- 31 Jul 2007

--- linux-2.6.23-rc1-mm1/drivers/scsi/imm.c.old 2007-07-30 13:58:00.0 
+0200
+++ linux-2.6.23-rc1-mm1/drivers/scsi/imm.c 2007-07-30 13:58:24.0 
+0200
@@ -740,10 +740,6 @@ static void imm_interrupt(struct work_st
struct Scsi_Host *host = cmd->device->host;
unsigned long flags;
 
-   if (!cmd) {
-   printk("IMM: bug in imm_interrupt\n");
-   return;
-   }
if (imm_engine(dev, cmd)) {
schedule_delayed_work(>imm_tq, 1);
return;
-
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 2/2 -mm] kexec based hibernation: kexec restore

Hi!

> This patch adds writing support for /dev/oldmem. This is used to
> restore the memory contents of hibernated system.
> 
> Signed-off-by: Huang Ying <[EMAIL PROTECTED]>

> +ssize_t write_oldmem_page(unsigned long pfn, const char *buf,
> +   size_t csize, unsigned long offset, int userbuf)

Hmm, int userbuf is only ever set to one... Does it make sense to have
write_oldmem_page in the separate file? The onl user is mem.c, perhaps
it should go there?

> +
> +/*
> + * Write memory corresponding to the old kernel.
> + */
> +static ssize_t write_oldmem(struct file *file, const char __user *buf,
> + size_t count, loff_t *ppos)
> +{
> + unsigned long pfn, offset;
> + size_t write = 0, csize;
> + int rc = 0;
> +
> + while (count) {
> + pfn = *ppos / PAGE_SIZE;
> + if (pfn > saved_max_pfn)
> + return write;
> +
> + offset = (unsigned long)(*ppos % PAGE_SIZE);
> + if (count > PAGE_SIZE - offset)
> + csize = PAGE_SIZE - offset;
> + else
> + csize = count;
> + rc = write_oldmem_page(pfn, buf, csize, offset, 1);
> + if (rc < 0)
> + return rc;
> + buf += csize;
> + *ppos += csize;
> + write += csize;
> + count -= csize;
> + }
> + return write;
> +}

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[2.6 patch] drivers/block/cciss.c: fix check-after-use

The Coverity checker spotted that we have already oops'ed if "disk"
was NULL.

Since "disk" being NULL seems impossible at this point this patch 
removes the NULL check.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Acked-by: Mike Miller <[EMAIL PROTECTED]>

---

This patch has been sent on:
- 31 Jul 2007

 drivers/block/cciss.c |   56 --
 1 file changed, 27 insertions(+), 29 deletions(-)

--- linux-2.6.23-rc1-mm1/drivers/block/cciss.c.old  2007-07-30 
02:27:15.0 +0200
+++ linux-2.6.23-rc1-mm1/drivers/block/cciss.c  2007-07-30 02:28:28.0 
+0200
@@ -1569,66 +1569,64 @@ static int deregister_disk(struct gendis
ctlr_info_t *h = get_host(disk);
 
if (!capable(CAP_SYS_RAWIO))
return -EPERM;
 
/* make sure logical volume is NOT is use */
if (clear_all || (h->gendisk[0] == disk)) {
if (drv->usage_count > 1)
return -EBUSY;
} else if (drv->usage_count > 0)
return -EBUSY;
 
/* invalidate the devices and deregister the disk.  If it is disk
 * zero do not deregister it but just zero out it's values.  This
 * allows us to delete disk zero but keep the controller registered.
 */
if (h->gendisk[0] != disk) {
-   if (disk) {
-   struct request_queue *q = disk->queue;
-   if (disk->flags & GENHD_FL_UP)
-   del_gendisk(disk);
-   if (q) {
-   blk_cleanup_queue(q);
-   /* Set drv->queue to NULL so that we do not try
-* to call blk_start_queue on this queue in the
-* interrupt handler
-*/
-   drv->queue = NULL;
-   }
-   /* If clear_all is set then we are deleting the logical
-* drive, not just refreshing its info.  For drives
-* other than disk 0 we will call put_disk.  We do not
-* do this for disk 0 as we need it to be able to
-* configure the controller.
+   struct request_queue *q = disk->queue;
+   if (disk->flags & GENHD_FL_UP)
+   del_gendisk(disk);
+   if (q) {
+   blk_cleanup_queue(q);
+   /* Set drv->queue to NULL so that we do not try
+* to call blk_start_queue on this queue in the
+* interrupt handler
+*/
+   drv->queue = NULL;
+   }
+   /* If clear_all is set then we are deleting the logical
+* drive, not just refreshing its info.  For drives
+* other than disk 0 we will call put_disk.  We do not
+* do this for disk 0 as we need it to be able to
+* configure the controller.
+   */
+   if (clear_all){
+   /* This isn't pretty, but we need to find the
+* disk in our array and NULL our the pointer.
+* This is so that we will call alloc_disk if
+* this index is used again later.
*/
-   if (clear_all){
-   /* This isn't pretty, but we need to find the
-* disk in our array and NULL our the pointer.
-* This is so that we will call alloc_disk if
-* this index is used again later.
-   */
-   for (i=0; i < CISS_MAX_LUN; i++){
-   if(h->gendisk[i] == disk){
-   h->gendisk[i] = NULL;
-   break;
-   }
+   for (i=0; i < CISS_MAX_LUN; i++){
+   if(h->gendisk[i] == disk){
+   h->gendisk[i] = NULL;
+   break;
}
-   put_disk(disk);
}
+   put_disk(disk);
}
} else {
set_capacity(disk, 0);
}
 
--h->num_luns;
/* zero out the disk size info */
drv->nr_blocks = 0;
drv->block_size = 0;
drv->heads = 0;
drv->sectors = 0;
drv->cylinders = 0;
drv->raid_level = -1;   /* This can be used as a flag variable to
 * indicate that this element of the drive
 * array is free.

2.6.23-rc3-mm1: i386: -maccumulate-outgoing-args unconditionally

On Wed, Aug 22, 2007 at 02:06:48AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.23-rc2-mm2:
>...
> +x86_64-mm-unwinder.patch
>...
> +x86_64-mm-remove-maccumulate-outgoing-args.patch
>...
>  x86 tree updates
>...

-maccumulate-outgoing-args on i386 count:
1 + 1 - 1 = 1

If the stack unwinder needs it please enable it only explicitely when 
the unwinder is enabled - we are talking about a 2.5% size increase 
with defconfig.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

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

[-mm patch] ivtv-fb.c bugfix

On Wed, Aug 22, 2007 at 02:06:48AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.23-rc2-mm2:
>...
>  git-dvb.patch
>...
>  git trees
>...

This patch fixes an obvious bug in ivtvfb_release_buffers().

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---
093bdc9ba94bffbec2ed44743418899771488832 
diff --git a/drivers/media/video/ivtv/ivtv-fb.c 
b/drivers/media/video/ivtv/ivtv-fb.c
index 0080765..8a344d5 100644
--- a/drivers/media/video/ivtv/ivtv-fb.c
+++ b/drivers/media/video/ivtv/ivtv-fb.c
@@ -1068,8 +1068,8 @@ static void ivtvfb_release_buffers (struct ivtv *itv)
struct osd_info *oi = itv->osd_info;
 
/* Release cmap */
-   if (oi->ivtvfb_info.cmap.len);
-   fb_dealloc_cmap(>ivtvfb_info.cmap);
+   if (oi->ivtvfb_info.cmap.len)
+   fb_dealloc_cmap(>ivtvfb_info.cmap);
 
/* Release pseudo palette */
if (oi->ivtvfb_info.pseudo_palette)

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

[-mm patch] iwl-base.c bugfixes

On Wed, Aug 22, 2007 at 02:06:48AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.23-rc2-mm2:
>... 
>  git-wireless.patch
>...
>  git trees
>...

This patch fixes two obvious bugs.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

 drivers/net/wireless/iwl-base.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

600ffdc11b25ac0aee15271d1b2ce99a367efa31 
diff --git a/drivers/net/wireless/iwl-base.c b/drivers/net/wireless/iwl-base.c
index b8293fe..f65c30e 100644
--- a/drivers/net/wireless/iwl-base.c
+++ b/drivers/net/wireless/iwl-base.c
@@ -343,7 +343,7 @@ int iwl_tx_queue_init(struct iwl_priv *priv,
 * command is very huge the system will not have two scan at the
 * same time */
len = sizeof(struct iwl_cmd) * slots_num;
-   if (txq_id == IWL_CMD_QUEUE_NUM);
+   if (txq_id == IWL_CMD_QUEUE_NUM)
len +=  IWL_MAX_SCAN_SIZE;
txq->cmd = pci_alloc_consistent(dev, len, >dma_addr_cmd);
if (!txq->cmd)
@@ -390,7 +390,7 @@ void iwl_tx_queue_free(struct iwl_priv *priv, struct 
iwl_tx_queue *txq)
iwl_hw_txq_free_tfd(priv, txq);
 
len = sizeof(struct iwl_cmd) * q->n_window;
-   if (q->id == IWL_CMD_QUEUE_NUM);
+   if (q->id == IWL_CMD_QUEUE_NUM)
len += IWL_MAX_SCAN_SIZE;
 
pci_free_consistent(dev, len, txq->cmd, txq->dma_addr_cmd);

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[2.6 patch] au88x0_synth.c bugfix