twitter: linux.kernel - 26 new messages in 20 topics

linux.kernel
http://groups.google.com/group/linux.kernel?hl=en

Today's topics:

==============================================================================
TOPIC: [PATCH 66/66] arch/um/sys-x86_64/shared/sysdep/skas_ptrace.h:
Checkpatch cleanup
http://groups.google.com/group/linux.kernel/t/e0ce05b42ac96287?hl=en
==============================================================================

== 1 of 2 ==
Date: Sun, Feb 28 2010 12:50 pm
From: Al Viro

On Sun, Feb 28, 2010 at 03:06:21PM +0100, Andrea Gelmini wrote:
> 2010/2/27 Jeff Dike <jdike@addtoit.com>:
> Hi Jeff,
> and thanks for your reply.
>
> > Don't you have anything better to do with your time?
>
> It's a dirty job, but somebody has to do it...
> Enlighted by Greg's talk at FOSDEM?? I sent him some patches (nothing
> more than boring things for a real programmer, but a good solitaire
> alternative for a rookie like me).
>
> These patches are just a try to see if there are other subtree
> maintainers interested in stuff like this.

Note to gregkh: the next time you give a talk like that, consider including
"spamming l-k with sixty-odd solitaire sessions^W^Wwhitespace-removal patches
can lead to considerable annoyance"...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 2 of 2 ==
Date: Sun, Feb 28 2010 2:40 pm
From: andrew hendry

Acked-by: Andrew Hendry <andrew.hendry@gmail.com>

On Sun, Feb 28, 2010 at 7:11 PM, David Miller <davem@davemloft.net> wrote:
> From: Andrea Gelmini <andrea.gelmini@gelma.net>
> Date: Sat, 27 Feb 2010 17:51:11 +0100
>
>> include/net/x25device.h:13: ERROR: trailing whitespace
>>
>> Signed-off-by: Andrea Gelmini <andrea.gelmini@gelma.net>
>
> Acked-by: David S. Miller <davem@davemloft.net>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: hw-breakpoint fix
http://groups.google.com/group/linux.kernel/t/81fd06bc804fde02?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Feb 28 2010 1:00 pm
From: Frederic Weisbecker

Ingo,

Please pull the perf/urgent branch that can be found at:

git://git.kernel.org/pub/scm/linux/kernel/git/frederic/random-tracing.git
perf/urgent

Thanks,
Frederic
---

Frederic Weisbecker (1):
hw-breakpoints: Remove stub unthrottle callback

arch/x86/kernel/hw_breakpoint.c | 5 -----
kernel/hw_breakpoint.c | 1 -
2 files changed, 0 insertions(+), 6 deletions(-)

---
commit 1e259e0a9982078896f3404240096cbea01daca4
Author: Frederic Weisbecker <fweisbec@gmail.com>
Date: Sun Feb 28 20:51:15 2010 +0100

hw-breakpoints: Remove stub unthrottle callback

We support event unthrottling in breakpoint events. It means
that if we have more than sysctl_perf_event_sample_rate/HZ,
perf will throttle, ignoring subsequent events until the next
tick.

So if ptrace exceeds this max rate, it will omit events, which
breaks the ptrace determinism that is supposed to report every
triggered breakpoints. This is likely to happen if we set
sysctl_perf_event_sample_rate to 1.

This patch removes support for unthrottling in breakpoint
events to break throttling and restore ptrace determinism.

Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
Cc: 2.6.33.x <stable@kernel.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: K.Prasad <prasad@linux.vnet.ibm.com>
Cc: Paul Mackerras <paulus@samba.org>

diff --git a/arch/x86/kernel/hw_breakpoint.c b/arch/x86/kernel/hw_breakpoint.c
index bb6006e..1e8cead 100644
--- a/arch/x86/kernel/hw_breakpoint.c
+++ b/arch/x86/kernel/hw_breakpoint.c
@@ -531,8 +531,3 @@ void hw_breakpoint_pmu_read(struct perf_event *bp)
{
/* TODO */
}
-
-void hw_breakpoint_pmu_unthrottle(struct perf_event *bp)
-{
- /* TODO */
-}
diff --git a/kernel/hw_breakpoint.c b/kernel/hw_breakpoint.c
index 967e661..4d99512 100644
--- a/kernel/hw_breakpoint.c
+++ b/kernel/hw_breakpoint.c
@@ -489,5 +489,4 @@ struct pmu perf_ops_bp = {
.enable = arch_install_hw_breakpoint,
.disable = arch_uninstall_hw_breakpoint,
.read = hw_breakpoint_pmu_read,
- .unthrottle = hw_breakpoint_pmu_unthrottle
};
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: PCI changes for 2.6.34
http://groups.google.com/group/linux.kernel/t/5251906101240ac7?hl=en
==============================================================================

== 1 of 5 ==
Date: Sun, Feb 28 2010 1:20 pm
From: Yinghai

On Feb 28, 2010, at 12:46 PM, Linus Torvalds <torvalds@linux-foundation.org
> wrote:

>
>
> On Sun, 28 Feb 2010, Linus Torvalds wrote:
>>
>> I just bisected a Nouveau boot failure to commit 977d17bb17 ("PCI:
>> update
>> bridge resources to get more big ranges in PCI assign unssigned"),
>> and I'm
>> going to revert that today one unless I can get a patch that fixes
>> it for
>> me.
>
> Btw, it's not just bisected, I also verified that a revert on top of
> the
> current git tree does fix it for me.

Sorry for that

Maybe we need to put back pci=try=num back
And set pci_try_num=1 by default

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

== 2 of 5 ==
Date: Sun, Feb 28 2010 1:20 pm
From: Linus Torvalds

On Sun, 28 Feb 2010, Yinghai wrote:
>
> Maybe we need to put back pci=try=num back
> And set pci_try_num=1 by default

Well, why does your patch trigger any changes at all in the first place?
The old situation was fine. All the resources were mapped.

Sure, there were ROM resources that aren't even enabled, but that is
_normal_. Iirc, several graphics chips actually alias the ROM resources
with the regular memory-mapped IO resource, ie you can't even map both of
them at the same time at some separate address, because the hardware
shares address decoding resources.

There's a reson PCI ROM resources are treated specially by the kernel.

And as far as I can see, all the other resources are already allocated
even without your patch. So there is some fundamental _bug_ there. This is
not about enabling/disabling your patch, this is about your patch
apparently simply being wrong.

But maybe I'm missing something.

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

== 3 of 5 ==
Date: Sun, Feb 28 2010 2:50 pm
From: Yinghai Lu

On 02/28/2010 01:19 PM, Linus Torvalds wrote:
>
>
> On Sun, 28 Feb 2010, Yinghai wrote:
>>
>> Maybe we need to put back pci=try=num back
>> And set pci_try_num=1 by default
>
> Well, why does your patch trigger any changes at all in the first place?
> The old situation was fine. All the resources were mapped.
>
> Sure, there were ROM resources that aren't even enabled, but that is
> _normal_. Iirc, several graphics chips actually alias the ROM resources
> with the regular memory-mapped IO resource, ie you can't even map both of
> them at the same time at some separate address, because the hardware
> shares address decoding resources.
>
> There's a reson PCI ROM resources are treated specially by the kernel.
>
> And as far as I can see, all the other resources are already allocated
> even without your patch. So there is some fundamental _bug_ there. This is
> not about enabling/disabling your patch, this is about your patch
> apparently simply being wrong.
>

looks like

[ 0.942502] pci 0000:04:00.0: reg 10: [mem 0xc6000000-0xc6ffffff]

[ 0.942510] pci 0000:04:00.0: reg 14: [mem 0xe0000000-0xefffffff 64bit pref]

[ 0.942519] pci 0000:04:00.0: reg 1c: [mem 0xc4000000-0xc5ffffff 64bit]

[ 0.942523] pci 0000:04:00.0: reg 24: [io 0x3000-0x307f]

[ 0.942528] pci 0000:04:00.0: reg 30: [mem 0xfffe0000-0xffffffff pref]

[ 0.942558] pci 0000:03:00.0: PCI bridge to [bus 04-04]

[ 0.942613] pci 0000:03:00.0: bridge window [io 0x3000-0x3fff]

[ 0.942616] pci 0000:03:00.0: bridge window [mem 0xc4000000-0xc6ffffff]

[ 0.942619] pci 0000:03:00.0: bridge window [mem 0xe0000000-0xefffffff 64bit pref]

[ 0.942657] pci 0000:05:00.0: reg 10: [mem 0xc2000000-0xc2ffffff]

[ 0.942665] pci 0000:05:00.0: reg 14: [mem 0xd0000000-0xdfffffff 64bit pref]

[ 0.942675] pci 0000:05:00.0: reg 1c: [mem 0xc0000000-0xc1ffffff 64bit]

[ 0.942679] pci 0000:05:00.0: reg 24: [io 0x2000-0x207f]

[ 0.942684] pci 0000:05:00.0: reg 30: [mem 0xfffe0000-0xffffffff pref]
[ 0.942715] pci 0000:03:02.0: PCI bridge to [bus 05-05]

[ 0.942770] pci 0000:03:02.0: bridge window [io 0x2000-0x2fff]

[ 0.942773] pci 0000:03:02.0: bridge window [mem 0xc0000000-0xc2ffffff]

[ 0.942777] pci 0000:03:02.0: bridge window [mem 0xd0000000-0xdfffffff 64bit pref]

later
[ 0.977506] pci 0000:04:00.0: no compatible bridge window for [mem 0xfffe0000-0xffffffff pref]

[ 0.977575] pci 0000:05:00.0: no compatible bridge window for [mem 0xfffe0000-0xffffffff pref]

that trigger the reallocating...

it seems old code
1. read out from pci rom bar
2. disable it, if it is enabled, but don't registered it
3. before pci_assign_unassigned..., will check PCI_ASSIGN_ROMS, and could register it...
3. to allocate for ROM bar together with other bar, for disabled or enabled but don't have PCI_ASSIGN_ROMS
4. it will not update the BAR if old setting is not enabled by BIOS.

looks like we should not allocate for those ROM bar at first place?

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

== 4 of 5 ==
Date: Sun, Feb 28 2010 4:00 pm
From: Yinghai Lu

please check

[PATCH] pci: don't reassign to ROM res if it is not going to be enabled

Signed-off-by: Yinghai Lu <yinghai@kernel.org>

---
drivers/pci/setup-bus.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)

Index: linux-2.6/drivers/pci/setup-bus.c
===================================================================
--- linux-2.6.orig/drivers/pci/setup-bus.c
+++ linux-2.6/drivers/pci/setup-bus.c
@@ -101,9 +101,17 @@ static void __assign_resources_sorted(st
for (list = head->next; list;) {
res = list->res;
idx = res - &list->dev->resource[0];
+
if (pci_assign_resource(list->dev, idx)) {
- if (fail_head && !pci_is_root_bus(list->dev->bus))
- add_to_failed_list(fail_head, list->dev, res);
+ if (fail_head && !pci_is_root_bus(list->dev->bus)) {
+ /*
+ * if the failed res is for ROM BAR, and it will
+ * be enabled later, don't add it to the list
+ */
+ if (!((idx == PCI_ROM_RESOURCE) &&
+ (!(res->flags & IORESOURCE_ROM_ENABLE))))
+ add_to_failed_list(fail_head, list->dev, res);
+ }
res->start = 0;
res->end = 0;
res->flags = 0;

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

== 5 of 5 ==
Date: Sun, Feb 28 2010 4:00 pm
From: Yinghai Lu

please check

[PATCH] pci: disable pci trying to reallocate pci bridge by default.

it broken Linus's Nouveau

bisected:to commit 977d17bb17
| PCI: update bridge resources to get more big ranges in PCI assign unssigned

so try disable it by default.

Signed-off-by: Yinghai Lu <yinghai@kernel.org>

---
Documentation/kernel-parameters.txt | 6 ++++++
drivers/pci/pci.c | 4 ++++
drivers/pci/pci.h | 2 ++
drivers/pci/setup-bus.c | 14 +++++++++-----
4 files changed, 21 insertions(+), 5 deletions(-)

Index: linux-2.6/Documentation/kernel-parameters.txt
===================================================================
--- linux-2.6.orig/Documentation/kernel-parameters.txt
+++ linux-2.6/Documentation/kernel-parameters.txt
@@ -1963,6 +1963,12 @@ and is between 256 and 4096 characters.
for broken drivers that don't call it.
skip_isa_align [X86] do not align io start addr, so can
handle more pci cards
+ try=n set the pci_try_num to reallocate the pci bridge resource
+ 1: default
+ 2: will set the num to max_depth, and try to reallocate res
+ to get big range for the bridge. assume the pci peer root
+ resource is right from _CRS or from hostbridge pci reg
+ reading out.
firmware [ARM] Do not re-enumerate the bus but instead
just use the configuration from the
bootloader. This is currently used on
Index: linux-2.6/drivers/pci/pci.c
===================================================================
--- linux-2.6.orig/drivers/pci/pci.c
+++ linux-2.6/drivers/pci/pci.c
@@ -2974,6 +2974,10 @@ static int __init pci_setup(char *str)
pci_no_aer();
} else if (!strcmp(str, "nodomains")) {
pci_no_domains();
+ } else if (!strncmp(str, "try=", 4)) {
+ int try_num = memparse(str + 4, &str);
+ if (try_num > 0)
+ pci_try_num = try_num;
} else if (!strncmp(str, "cbiosize=", 9)) {
pci_cardbus_io_size = memparse(str + 9, &str);
} else if (!strncmp(str, "cbmemsize=", 10)) {
Index: linux-2.6/drivers/pci/pci.h
===================================================================
--- linux-2.6.orig/drivers/pci/pci.h
+++ linux-2.6/drivers/pci/pci.h
@@ -212,6 +212,8 @@ static inline int pci_ari_enabled(struct
return bus->self && bus->self->ari_enabled;
}

+extern int pci_try_num;
+
#ifdef CONFIG_PCI_QUIRKS
extern int pci_is_reassigndev(struct pci_dev *dev);
resource_size_t pci_specified_resource_alignment(struct pci_dev *dev);
Index: linux-2.6/drivers/pci/setup-bus.c
===================================================================
--- linux-2.6.orig/drivers/pci/setup-bus.c
+++ linux-2.6/drivers/pci/setup-bus.c
@@ -869,6 +869,7 @@ static int __init pci_get_max_depth(void
* second and later try will clear small leaf bridge res
* will stop till to the max deepth if can not find good one
*/
+int pci_try_num = 1;
void __init
pci_assign_unassigned_resources(void)
{
@@ -879,14 +880,17 @@ pci_assign_unassigned_resources(void)
unsigned long type_mask = IORESOURCE_IO | IORESOURCE_MEM |
IORESOURCE_PREFETCH;
unsigned long failed_type;
- int max_depth = pci_get_max_depth();
- int pci_try_num;

head.next = NULL;

- pci_try_num = max_depth + 1;
- printk(KERN_DEBUG "PCI: max bus depth: %d pci_try_num: %d\n",
- max_depth, pci_try_num);
+ if (pci_try_num > 1) {
+ int max_depth = pci_get_max_depth();
+
+ if (max_depth + 1 > pci_try_num)
+ pci_try_num = max_depth + 1;
+ printk(KERN_DEBUG "PCI: max bus depth: %d pci_try_num: %d\n",
+ max_depth, pci_try_num);
+ }

again:
/* Depth first, calculate sizes and alignments of all
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: Fix race condition in drivers/base/dd.c
http://groups.google.com/group/linux.kernel/t/4c243136e07cdb42?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Feb 28 2010 1:40 pm
From: Stefani Seibold

This patch fix a potential race condition in the driver_bound() function
in the file driver/base/dd.c.

The broadcast of the BUS_NOTIFY_BOUND_DRIVER notifier should be done
after adding the new device to the driver list. Otherwise notifier
listener will fail if they use functions like usb_find_interface().

The patch is against kernel 2.6.33. Please merge it.

Signed-off-by: Stefani Seibold <stefani@seibold.net>
---
dd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- linux-2.6.33.orig/drivers/base/dd.c 2010-02-24 19:52:17.000000000 +0100
+++ linux-2.6.33/drivers/base/dd.c 2010-02-28 20:25:06.595037275 +0100
@@ -40,11 +40,11 @@ static void driver_bound(struct device *
pr_debug("driver: '%s': %s: bound to device '%s'\n", dev_name(dev),
__func__, dev->driver->name);

+ klist_add_tail(&dev->p->knode_driver, &dev->driver->p->klist_devices);
+
if (dev->bus)
blocking_notifier_call_chain(&dev->bus->p->bus_notifier,
BUS_NOTIFY_BOUND_DRIVER, dev);
-
- klist_add_tail(&dev->p->knode_driver, &dev->driver->p->klist_devices);
}

static int driver_sysfs_add(struct device *dev)

==============================================================================
TOPIC: drivers/scsi/ch.c: Don't use vprintk as macro
http://groups.google.com/group/linux.kernel/t/49040d0b7227d9c3?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Feb 28 2010 1:40 pm
From: Joe Perches

It's an exported symbol of kernel/printk.c

Rename vprintk and dprintk macros to more common VPRINTK and DPRINTK
Add do { } while(0) around macros
Add level to VPRINTK so KERN_CONT can be used a couple of times.

Signed-off-by: Joe Perches <joe@perches.com>
drivers/scsi/ch.c | 87 +++++++++++++++++++++++++++--------------------------
1 files changed, 44 insertions(+), 43 deletions(-)

diff --git a/drivers/scsi/ch.c b/drivers/scsi/ch.c
index fe11c1d..5bd396f 100644
--- a/drivers/scsi/ch.c
+++ b/drivers/scsi/ch.c
@@ -83,10 +83,16 @@ static const char * vendor_labels[CH_TYPES-4] = {
};
// module_param_string_array(vendor_labels, NULL, 0444);

-#define dprintk(fmt, arg...) if (debug) \
- printk(KERN_DEBUG "%s: " fmt, ch->name , ## arg)
-#define vprintk(fmt, arg...) if (verbose) \
- printk(KERN_INFO "%s: " fmt, ch->name , ## arg)
+#define DPRINTK(fmt, arg...) \
+do { \
+ if (debug) \
+ printk(KERN_DEBUG "%s: " fmt, ch->name, ##arg); \
+} while (0)
+#define VPRINTK(level, fmt, arg...) \
+do { \
+ if (verbose) \
+ printk(level "%s: " fmt, ch->name, ##arg); \
+} while (0)

/* ------------------------------------------------------------------- */

@@ -185,7 +191,7 @@ ch_do_scsi(scsi_changer *ch, unsigned char *cmd,
retry:
errno = 0;
if (debug) {
- dprintk("command: ");
+ DPRINTK("command: ");
__scsi_print_command(cmd);
}

@@ -193,7 +199,7 @@ ch_do_scsi(scsi_changer *ch, unsigned char *cmd,
buflength, &sshdr, timeout * HZ,
MAX_RETRIES, NULL);

- dprintk("result: 0x%x\n",result);
+ DPRINTK("result: 0x%x\n",result);
if (driver_byte(result) & DRIVER_SENSE) {
if (debug)
scsi_print_sense_hdr(ch->name, &sshdr);
@@ -249,7 +255,7 @@ ch_read_element_status(scsi_changer *ch, u_int elem, char *data)
cmd[9] = 255;
if (0 == (result = ch_do_scsi(ch, cmd, buffer, 256, DMA_FROM_DEVICE))) {
if (((buffer[16] << 8) | buffer[17]) != elem) {
- dprintk("asked for element 0x%02x, got 0x%02x\n",
+ DPRINTK("asked for element 0x%02x, got 0x%02x\n",
elem,(buffer[16] << 8) | buffer[17]);
kfree(buffer);
return -EIO;
@@ -258,10 +264,10 @@ ch_read_element_status(scsi_changer *ch, u_int elem, char *data)
} else {
if (ch->voltags) {
ch->voltags = 0;
- vprintk("device has no volume tag support\n");
+ VPRINTK(KERN_INFO, "device has no volume tag support\n");
goto retry;
}
- dprintk("READ ELEMENT STATUS for element 0x%x failed\n",elem);
+ DPRINTK("READ ELEMENT STATUS for element 0x%x failed\n",elem);
}
kfree(buffer);
return result;
@@ -273,12 +279,12 @@ ch_init_elem(scsi_changer *ch)
int err;
u_char cmd[6];

- vprintk("INITIALIZE ELEMENT STATUS, may take some time ...\n");
+ VPRINTK(KERN_INFO, "INITIALIZE ELEMENT STATUS, may take some time ...\n");
memset(cmd,0,sizeof(cmd));
cmd[0] = INITIALIZE_ELEMENT_STATUS;
cmd[1] = ch->device->lun << 5;
err = ch_do_scsi(ch, cmd, NULL, 0, DMA_NONE);
- vprintk("... finished\n");
+ VPRINTK(KERN_INFO, "... finished\n");
return err;
}

@@ -321,20 +327,20 @@ ch_readconfig(scsi_changer *ch)
(buffer[buffer[3]+18] << 8) | buffer[buffer[3]+19];
ch->counts[CHET_DT] =
(buffer[buffer[3]+20] << 8) | buffer[buffer[3]+21];
- vprintk("type #1 (mt): 0x%x+%d [medium transport]\n",
+ VPRINTK(KERN_INFO, "type #1 (mt): 0x%x+%d [medium transport]\n",
ch->firsts[CHET_MT],
ch->counts[CHET_MT]);
- vprintk("type #2 (st): 0x%x+%d [storage]\n",
+ VPRINTK(KERN_INFO, "type #2 (st): 0x%x+%d [storage]\n",
ch->firsts[CHET_ST],
ch->counts[CHET_ST]);
- vprintk("type #3 (ie): 0x%x+%d [import/export]\n",
+ VPRINTK(KERN_INFO, "type #3 (ie): 0x%x+%d [import/export]\n",
ch->firsts[CHET_IE],
ch->counts[CHET_IE]);
- vprintk("type #4 (dt): 0x%x+%d [data transfer]\n",
+ VPRINTK(KERN_INFO, "type #4 (dt): 0x%x+%d [data transfer]\n",
ch->firsts[CHET_DT],
ch->counts[CHET_DT]);
} else {
- vprintk("reading element address assigment page failed!\n");
+ VPRINTK(KERN_INFO, "reading element address assigment page failed!\n");
}

/* vendor specific element types */
@@ -345,7 +351,7 @@ ch_readconfig(scsi_changer *ch)
continue;
ch->firsts[CHET_V1+i] = vendor_firsts[i];
ch->counts[CHET_V1+i] = vendor_counts[i];
- vprintk("type #%d (v%d): 0x%x+%d [%s, vendor specific]\n",
+ VPRINTK(KERN_INFO, "type #%d (v%d): 0x%x+%d [%s, vendor specific]\n",
i+5,i+1,vendor_firsts[i],vendor_counts[i],
vendor_labels[i]);
}
@@ -365,21 +371,19 @@ ch_readconfig(scsi_changer *ch)
if (elem < CH_DT_MAX && -1 != dt_id[elem]) {
id = dt_id[elem];
lun = dt_lun[elem];
- vprintk("dt 0x%x: [insmod option] ",
+ VPRINTK(KERN_INFO, "dt 0x%x: [insmod option] ",
elem+ch->firsts[CHET_DT]);
} else if (0 != ch_read_element_status
(ch,elem+ch->firsts[CHET_DT],data)) {
- vprintk("dt 0x%x: READ ELEMENT STATUS failed\n",
+ VPRINTK(KERN_INFO, "dt 0x%x: READ ELEMENT STATUS failed\n",
elem+ch->firsts[CHET_DT]);
} else {
- vprintk("dt 0x%x: ",elem+ch->firsts[CHET_DT]);
+ VPRINTK(KERN_INFO, "dt 0x%x: ",elem+ch->firsts[CHET_DT]);
if (data[6] & 0x80) {
- if (verbose)
- printk("not this SCSI bus\n");
+ VPRINTK(KERN_CONT, "not this SCSI bus\n");
ch->dt[elem] = NULL;
} else if (0 == (data[6] & 0x30)) {
- if (verbose)
- printk("ID/LUN unknown\n");
+ VPRINTK(KERN_CONT, "ID/LUN unknown\n");
ch->dt[elem] = NULL;
} else {
id = ch->device->id;
@@ -389,22 +393,19 @@ ch_readconfig(scsi_changer *ch)
}
}
if (-1 != id) {
- if (verbose)
- printk("ID %i, LUN %i, ",id,lun);
+ VPRINTK(KERN_CONT, "ID %i, LUN %i, ",id,lun);
ch->dt[elem] =
scsi_device_lookup(ch->device->host,
ch->device->channel,
id,lun);
if (!ch->dt[elem]) {
/* should not happen */
- if (verbose)
- printk("Huh? device not found!\n");
+ VPRINTK(KERN_CONT, "Huh? device not found!\n");
} else {
- if (verbose)
- printk("name: %8.8s %16.16s %4.4s\n",
- ch->dt[elem]->vendor,
- ch->dt[elem]->model,
- ch->dt[elem]->rev);
+ VPRINTK(KERN_CONT, "name: %8.8s %16.16s %4.4s\n",
+ ch->dt[elem]->vendor,
+ ch->dt[elem]->model,
+ ch->dt[elem]->rev);
}
}
}
@@ -421,7 +422,7 @@ ch_position(scsi_changer *ch, u_int trans, u_int elem, int rotate)
{
u_char cmd[10];

- dprintk("position: 0x%x\n",elem);
+ DPRINTK("position: 0x%x\n",elem);
if (0 == trans)
trans = ch->firsts[CHET_MT];
memset(cmd,0,sizeof(cmd));
@@ -440,7 +441,7 @@ ch_move(scsi_changer *ch, u_int trans, u_int src, u_int dest, int rotate)
{
u_char cmd[12];

- dprintk("move: 0x%x => 0x%x\n",src,dest);
+ DPRINTK("move: 0x%x => 0x%x\n",src,dest);
if (0 == trans)
trans = ch->firsts[CHET_MT];
memset(cmd,0,sizeof(cmd));
@@ -462,7 +463,7 @@ ch_exchange(scsi_changer *ch, u_int trans, u_int src,
{
u_char cmd[12];

- dprintk("exchange: 0x%x => 0x%x => 0x%x\n",
+ DPRINTK("exchange: 0x%x => 0x%x => 0x%x\n",
src,dest1,dest2);
if (0 == trans)
trans = ch->firsts[CHET_MT];
@@ -510,7 +511,7 @@ ch_set_voltag(scsi_changer *ch, u_int elem,
if (!buffer)
return -ENOMEM;

- dprintk("%s %s voltag: 0x%x => \"%s\"\n",
+ DPRINTK("%s %s voltag: 0x%x => \"%s\"\n",
clear ? "clear" : "set",
alternate ? "alternate" : "primary",
elem, tag);
@@ -549,7 +550,7 @@ static int ch_gstatus(scsi_changer *ch, int type, unsigned char __user *dest)
}
put_user(data[2], dest+i);
if (data[2] & CESTATUS_EXCEPT)
- vprintk("element 0x%x: asc=0x%x, ascq=0x%x\n",
+ VPRINTK(KERN_INFO, "element 0x%x: asc=0x%x, ascq=0x%x\n",
ch->firsts[type]+i,
(int)data[4],(int)data[5]);
retval = ch_read_element_status
@@ -659,7 +660,7 @@ static long ch_ioctl(struct file *file,
return -EFAULT;

if (0 != ch_checkrange(ch, pos.cp_type, pos.cp_unit)) {
- dprintk("CHIOPOSITION: invalid parameter\n");
+ DPRINTK("CHIOPOSITION: invalid parameter\n");
return -EBADSLT;
}
mutex_lock(&ch->lock);
@@ -679,7 +680,7 @@ static long ch_ioctl(struct file *file,

if (0 != ch_checkrange(ch, mv.cm_fromtype, mv.cm_fromunit) ||
0 != ch_checkrange(ch, mv.cm_totype, mv.cm_tounit )) {
- dprintk("CHIOMOVE: invalid parameter\n");
+ DPRINTK("CHIOMOVE: invalid parameter\n");
return -EBADSLT;
}

@@ -702,7 +703,7 @@ static long ch_ioctl(struct file *file,
if (0 != ch_checkrange(ch, mv.ce_srctype, mv.ce_srcunit ) ||
0 != ch_checkrange(ch, mv.ce_fdsttype, mv.ce_fdstunit) ||
0 != ch_checkrange(ch, mv.ce_sdsttype, mv.ce_sdstunit)) {
- dprintk("CHIOEXCHANGE: invalid parameter\n");
+ DPRINTK("CHIOEXCHANGE: invalid parameter\n");
return -EBADSLT;
}

@@ -795,7 +796,7 @@ static long ch_ioctl(struct file *file,
}
} else if (ch->voltags) {
ch->voltags = 0;
- vprintk("device has no volume tag support\n");
+ VPRINTK(KERN_INFO, "device has no volume tag support\n");
goto voltag_retry;
}
kfree(buffer);
@@ -823,7 +824,7 @@ static long ch_ioctl(struct file *file,
return -EFAULT;

if (0 != ch_checkrange(ch, csv.csv_type, csv.csv_unit)) {
- dprintk("CHIOSVOLTAG: invalid parameter\n");
+ DPRINTK("CHIOSVOLTAG: invalid parameter\n");
return -EBADSLT;
}
elem = ch->firsts[csv.csv_type] + csv.csv_unit;

==============================================================================
TOPIC: tracing/perf: Fix lock events recursions in the fast path
http://groups.google.com/group/linux.kernel/t/88914be5e6b28d7d?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Feb 28 2010 2:30 pm
From: Frederic Weisbecker

On Fri, Feb 05, 2010 at 02:01:55PM +0100, Peter Zijlstra wrote:
> On Fri, 2010-02-05 at 13:12 +0100, Peter Zijlstra wrote:
> > On Fri, 2010-02-05 at 13:10 +0100, Peter Zijlstra wrote:
> > > On Fri, 2010-02-05 at 11:49 +0100, Ingo Molnar wrote:
> > > >
> > > > > That said, I'm not at all happy about removing lockdep annotations to make
> > > > > the tracer faster, that's really counter productive.
> > > >
> > > > Are there no dynamic techniques that could be used here?
> > > >
> > > > Lockdep obviously wants maximum instrumentation coverage - performance be
> > > > damned.
> > > >
> > > > Lock profiling/tracing/visualization wants the minimum subset of events it is
> > > > interested in - everything else is unnecessary overhead.
> > >
> > > Well, they could start by moving the tracepoint inside the lockdep
> > > recursion check.
> >
> > IIRC the reason its now outside is that you'd loose tracepoint on
> > lockdep_off() usage, but having the tracer folks help on removing any
> > such usage is of course a good thing.
> >
> > The usage thereof in nmi_enter() doesn't seem like a problem, since
> > you're not supposed to be using locks from nmi context anyway, more so,
> > I'd not be adverse to putting BUG_ON(in_nmi()) in every lockdep hook.
>
> Another nasty side effect is that it (lockdep recursion) isn't IRQ aware
> in that we don't do any tracking for IRQ's that hit while we're doing
> lockdep. We can fix that using a recursion context like we did for perf,
> that would actually improve lockdep itself too.

Actually, looking at lock_acquire/release/acquired/contended, they are
all performing their job under a raw_lock_irq_save() window, so it
doesn't seem we are losing anything.

Something that could be nice though: dropping this irq saving from the
main window, add the perf style recursion protection, and eventually
have a raw_local_irq_save only when we take internal lockdep locks.
This will let irqs happen during lockdep checks.

I just guess the irq disabled thing is also protecting something else,
something I'll probably discover after testing that :)

==============================================================================
TOPIC: 2.6.33 dies on modprobe
http://groups.google.com/group/linux.kernel/t/89ac756ead52e900?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Feb 28 2010 2:30 pm
From: M G Berberich

Hello,

I tried to build a 2.6.33 kernel but on boot it dies on modprobe
(kernel-Oops). This might be the result of faulty config, but I'm
totaly clueless what's the fault.

The kernel starts up fine and mounts the root-filesystem, but then
dies on the first modprobe executed. I can boot it with init=/bin/bash
and get a working bash (until I do modprobe on any module).

System is a Gigabyte M55S-S3 rev 2.0 (nForce 550) with an AMD Athlon64
X2 5000+ and amd64-kernel architecture. kernel-sources are from
kernel.org.

[...]
EXT4-fs (sda2): mounted filesystem with ordered data mode
VFS: Mounted root (ext4 filesystem) readonly on device 8:2.
Freeing unused kernel memory: 408k freed
BUG: unable to handle kernel paging request at ffffffffa001b57f
IP: [<ffffffff811895db>] strcmp+0xb/0x30
PGD 1498067 PUD 149c063 PMD 12daf2067 PTE 0
Oops: 0000 [#1] SMP
last sysfs file: /sys/devices/pci0000:00/0000:00:05.0/host0/target0:0:0/0:0:0:0/
type
CPU 1
Pid: 1249, comm: modprobe Not tainted 2.6.33-bmg #1 M55S-S3/
[...]

I have attached the config and the complete kernel-log of an
boot-attempt.

MfG
bmg

P.S. I'm not subscribed to lkml
--
„Des is völlig wurscht, was heut beschlos- | M G Berberich
sen wird: I bin sowieso dagegn!" | berberic@fmi.uni-passau.de
(SPD-Stadtrat Kurt Schindler; Regensburg) | www.fmi.uni-passau.de/~berberic

==============================================================================
TOPIC: fix PHY polling system blocking
http://groups.google.com/group/linux.kernel/t/e365b35fc0142489?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Feb 28 2010 2:40 pm
From: Stefani Seibold

This patch fix the PHY poller, which can block the whole system. On a
Freescale PPC 834x this result in a delay of 450 us due the slow
communication with the PHY chip.

For PHY chips without interrupts, the status of the ethernet will be
polled every 2 sec. The poll function will read some register of the MII
PHY. The time between the sending the MII_READ_COMMAND and receiving the
result is more the 100 us on a PPC 834x.

The patch modifies the poller a lit bit. Only a link status state change
will result in a successive detection of the connection type. The poll
cycle on the other hand will be increased to every seconds.

Together this patch will prevent a blocking of nearly 400 us every two
seconds of the whole system on a PPC 834x.

The patch is against kernel 2.6.33. Please merge it.

Signed-off-by: Stefani Seibold <stefani@seibold.net>
---
phy.c | 5 ++---
phy_device.c | 12 +++++++++---
2 files changed, 11 insertions(+), 6 deletions(-)

diff -u -N -r -p linux-2.6.33.orig/drivers/net/phy/phy.c linux-2.6.33/drivers/net//phy/phy.c
--- linux-2.6.33.orig/drivers/net/phy/phy.c 2010-02-24 19:52:17.000000000 +0100
+++ linux-2.6.33/drivers/net//phy/phy.c 2010-02-28 22:53:14.725464101 +0100
@@ -871,9 +871,8 @@ void phy_state_machine(struct work_struc
case PHY_RUNNING:
/* Only register a CHANGE if we are
* polling */
- if (PHY_POLL == phydev->irq)
- phydev->state = PHY_CHANGELINK;
- break;
+ if (PHY_POLL != phydev->irq)
+ break;
case PHY_CHANGELINK:
err = phy_read_status(phydev);

diff -u -N -r -p linux-2.6.33.orig/drivers/net/phy/phy_device.c linux-2.6.33/drivers/net//phy/phy_device.c
--- linux-2.6.33.orig/drivers/net/phy/phy_device.c 2010-02-24 19:52:17.000000000 +0100
+++ linux-2.6.33/drivers/net//phy/phy_device.c 2010-02-28 22:53:14.726464145 +0100
@@ -161,7 +161,7 @@ struct phy_device* phy_device_create(str
dev->speed = 0;
dev->duplex = -1;
dev->pause = dev->asym_pause = 0;
- dev->link = 1;
+ dev->link = 0;
dev->interface = PHY_INTERFACE_MODE_GMII;

dev->autoneg = AUTONEG_ENABLE;
@@ -694,10 +694,16 @@ int genphy_update_link(struct phy_device
if (status < 0)
return status;

- if ((status & BMSR_LSTATUS) == 0)
+ if ((status & BMSR_LSTATUS) == 0) {
+ if (phydev->link==0)
+ return 1;
phydev->link = 0;
- else
+ }
+ else {
+ if (phydev->link==1)
+ return 1;
phydev->link = 1;
+ }

return 0;
}

==============================================================================
TOPIC: MFD: TWL4030: introduce remove_script function
http://groups.google.com/group/linux.kernel/t/752708254b25ebf8?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Feb 28 2010 3:00 pm
From: Samuel Ortiz

Hi Mike,

On Mon, Feb 22, 2010 at 11:16:30AM -0600, mturquette@gmail.com wrote:
> From: Mike Turquette <mturquette@ti.com>
>
> New function twl4030_remove_script(u8 flags) takes a script type as
> defined in twl.h and prevents any script already loaded in that position
> from running. This is accomplished by programming SEQ_ADD_* to 0x3f,
> the END_OF_SCRIPT value, where SEQ_ADD_* is determined by flags.
Patch applied, thanks a lot.

Cheers,
Samuel.

> Signed-off-by: Mike Turquette <mturquette@ti.com>
> ---
>
> Based on MFD for-next branch.
>
> Future users of this function include OMAP board files for machines
> facing a race condition between sleep and warm reset.
>
> drivers/mfd/twl4030-power.c | 50 +++++++++++++++++++++++++++++++++++++++++++
> include/linux/i2c/twl.h | 1 +
> 2 files changed, 51 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
> index 5b045ff..7efa878 100644
> --- a/drivers/mfd/twl4030-power.c
> +++ b/drivers/mfd/twl4030-power.c
> @@ -461,6 +461,56 @@ out:
> return err;
> }
>
> +int twl4030_remove_script(u8 flags)
> +{
> + int err = 0;
> +
> + err = twl_i2c_write_u8(TWL4030_MODULE_PM_MASTER, R_KEY_1,
> + R_PROTECT_KEY);
> + if (err) {
> + pr_err("twl4030: unable to unlock PROTECT_KEY\n");
> + return err;
> + }
> +
> + err = twl_i2c_write_u8(TWL4030_MODULE_PM_MASTER, R_KEY_2,
> + R_PROTECT_KEY);
> + if (err) {
> + pr_err("twl4030: unable to unlock PROTECT_KEY\n");
> + return err;
> + }
> +
> + if (flags & TWL4030_WRST_SCRIPT) {
> + err = twl_i2c_write_u8(TWL4030_MODULE_PM_MASTER, END_OF_SCRIPT,
> + R_SEQ_ADD_WARM);
> + if (err)
> + return err;
> + }
> + if (flags & TWL4030_WAKEUP12_SCRIPT) {
> + if (err)
> + err = twl_i2c_write_u8(TWL4030_MODULE_PM_MASTER, END_OF_SCRIPT,
> + R_SEQ_ADD_S2A12);
> + return err;
> + }
> + if (flags & TWL4030_WAKEUP3_SCRIPT) {
> + err = twl_i2c_write_u8(TWL4030_MODULE_PM_MASTER, END_OF_SCRIPT,
> + R_SEQ_ADD_S2A3);
> + if (err)
> + return err;
> + }
> + if (flags & TWL4030_SLEEP_SCRIPT) {
> + err = twl_i2c_write_u8(TWL4030_MODULE_PM_MASTER, END_OF_SCRIPT,
> + R_SEQ_ADD_A2S);
> + if (err)
> + return err;
> + }
> +
> + err = twl_i2c_write_u8(TWL4030_MODULE_PM_MASTER, 0, R_PROTECT_KEY);
> + if (err)
> + pr_err("TWL4030 Unable to relock registers\n");
> +
> + return err;
> +}
> +
> void __init twl4030_power_init(struct twl4030_power_data *twl4030_scripts)
> {
> int err = 0;
> diff --git a/include/linux/i2c/twl.h b/include/linux/i2c/twl.h
> index 33d9d5c..d4baff8 100644
> --- a/include/linux/i2c/twl.h
> +++ b/include/linux/i2c/twl.h
> @@ -550,6 +550,7 @@ struct twl4030_power_data {
> };
>
> extern void twl4030_power_init(struct twl4030_power_data *triton2_scripts);
> +extern int twl4030_remove_script(u8 flags);
>
> struct twl4030_codec_audio_data {
> unsigned int audio_mclk;
> --
> 1.6.3.2
>

--
Intel Open Source Technology Centre
http://oss.intel.com/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: Problem with bridges and wireless NIC's
http://groups.google.com/group/linux.kernel/t/8d69d44c6b387788?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Feb 28 2010 3:00 pm
From: Bjarke Istrup Pedersen

Hey,

There is a problem when trying to create a bridge containing a normal
NIC and a wireless NIC, and using hostapd.

The problem is, that it is not possible to create a bridge containing
a wireless NIC, if it hasn't been setup first.

Does anyone have a solution for this?

(The commit that introduced this problem is
ad4bb6f8883a13bb0f65b194dae36c62a02ac779 , reverting it solves the
problem).

For more info, please have a look at this bug report:
http://bugs.gentoo.org/show_bug.cgi?id=298824

Best regards,
Bjarke I. Pedersen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: mfd: Use completion interrupt for WM835x AUXADC
http://groups.google.com/group/linux.kernel/t/f4894fff1f592065?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Feb 28 2010 3:10 pm
From: Samuel Ortiz

Hi Mark,

On Tue, Feb 23, 2010 at 11:08:05AM +0000, Mark Brown wrote:
> Use the completion interrupt generated by the device rather than
> polling for conversions to complete. As a backup we still check
> the state of the AUXADC if we don't get a completion, mostly for
> systems that don't have the WM8350 interrupt infrastructure hooked
> up.
Patch applied, many thanks.

Cheers,
Samuel.

> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
> ---
> drivers/mfd/wm8350-core.c | 35 +++++++++++++++++++++++++++++------
> include/linux/mfd/wm8350/core.h | 2 ++
> 2 files changed, 31 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/mfd/wm8350-core.c b/drivers/mfd/wm8350-core.c
> index 9a970bd..bd75807 100644
> --- a/drivers/mfd/wm8350-core.c
> +++ b/drivers/mfd/wm8350-core.c
> @@ -339,7 +339,6 @@ EXPORT_SYMBOL_GPL(wm8350_reg_unlock);
> int wm8350_read_auxadc(struct wm8350 *wm8350, int channel, int scale, int vref)
> {
> u16 reg, result = 0;
> - int tries = 5;
>
> if (channel < WM8350_AUXADC_AUX1 || channel > WM8350_AUXADC_TEMP)
> return -EINVAL;
> @@ -363,12 +362,13 @@ int wm8350_read_auxadc(struct wm8350 *wm8350, int channel, int scale, int vref)
> reg |= 1 << channel | WM8350_AUXADC_POLL;
> wm8350_reg_write(wm8350, WM8350_DIGITISER_CONTROL_1, reg);
>
> - do {
> - schedule_timeout_interruptible(1);
> - reg = wm8350_reg_read(wm8350, WM8350_DIGITISER_CONTROL_1);
> - } while ((reg & WM8350_AUXADC_POLL) && --tries);
> + /* We ignore the result of the completion and just check for a
> + * conversion result, allowing us to soldier on if the IRQ
> + * infrastructure is not set up for the chip. */
> + wait_for_completion_timeout(&wm8350->auxadc_done, msecs_to_jiffies(5));
>
> - if (!tries)
> + reg = wm8350_reg_read(wm8350, WM8350_DIGITISER_CONTROL_1);
> + if (reg & WM8350_AUXADC_POLL)
> dev_err(wm8350->dev, "adc chn %d read timeout\n", channel);
> else
> result = wm8350_reg_read(wm8350,
> @@ -385,6 +385,15 @@ int wm8350_read_auxadc(struct wm8350 *wm8350, int channel, int scale, int vref)
> }
> EXPORT_SYMBOL_GPL(wm8350_read_auxadc);
>
> +static irqreturn_t wm8350_auxadc_irq(int irq, void *irq_data)
> +{
> + struct wm8350 *wm8350 = irq_data;
> +
> + complete(&wm8350->auxadc_done);
> +
> + return IRQ_HANDLED;
> +}
> +
> /*
> * Cache is always host endian.
> */
> @@ -682,11 +691,22 @@ int wm8350_device_init(struct wm8350 *wm8350, int irq,
> }
>
> mutex_init(&wm8350->auxadc_mutex);
> + init_completion(&wm8350->auxadc_done);
>
> ret = wm8350_irq_init(wm8350, irq, pdata);
> if (ret < 0)
> goto err;
>
> + if (wm8350->irq_base) {
> + ret = request_threaded_irq(wm8350->irq_base +
> + WM8350_IRQ_AUXADC_DATARDY,
> + NULL, wm8350_auxadc_irq, 0,
> + "auxadc", wm8350);
> + if (ret < 0)
> + dev_warn(wm8350->dev,
> + "Failed to request AUXADC IRQ: %d\n", ret);
> + }
> +
> if (pdata && pdata->init) {
> ret = pdata->init(wm8350);
> if (ret != 0) {
> @@ -736,6 +756,9 @@ void wm8350_device_exit(struct wm8350 *wm8350)
> platform_device_unregister(wm8350->gpio.pdev);
> platform_device_unregister(wm8350->codec.pdev);
>
> + if (wm8350->irq_base)
> + free_irq(wm8350->irq_base + WM8350_IRQ_AUXADC_DATARDY, wm8350);
> +
> wm8350_irq_exit(wm8350);
>
> kfree(wm8350->reg_cache);
> diff --git a/include/linux/mfd/wm8350/core.h b/include/linux/mfd/wm8350/core.h
> index fae08aa..98fcc97 100644
> --- a/include/linux/mfd/wm8350/core.h
> +++ b/include/linux/mfd/wm8350/core.h
> @@ -16,6 +16,7 @@
> #include <linux/kernel.h>
> #include <linux/mutex.h>
> #include <linux/interrupt.h>
> +#include <linux/completion.h>
>
> #include <linux/mfd/wm8350/audio.h>
> #include <linux/mfd/wm8350/gpio.h>
> @@ -621,6 +622,7 @@ struct wm8350 {
> u16 *reg_cache;
>
> struct mutex auxadc_mutex;
> + struct completion auxadc_done;
>
> /* Interrupt handling */
> struct mutex irq_lock;
> --
> 1.7.0
>

==============================================================================
TOPIC: mfd: Use completion interrupt for WM831x AUXADC
http://groups.google.com/group/linux.kernel/t/6ca115d4ee7e0e47?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Feb 28 2010 3:10 pm
From: Samuel Ortiz

On Tue, Feb 23, 2010 at 11:08:06AM +0000, Mark Brown wrote:
> Use the completion interrupt generated by the device rather than
> polling for conversions to complete. As a backup we still check
> the status of the AUXADC if we don't get a completion, mostly for
> systems that don't have the WM831x interrupt infrastructure hooked
> up.
Patch applied to my for-next branch, thanks a lot.

Cheers,
Samuel.

> Also reduce the timeout for completion of conversions to 5ms from
> the previous 10ms, the lower timeout should be sufficient.
>
> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
> ---
> drivers/mfd/wm831x-core.c | 36 +++++++++++++++++++++++++++++-------
> include/linux/mfd/wm831x/core.h | 2 ++
> 2 files changed, 31 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/mfd/wm831x-core.c b/drivers/mfd/wm831x-core.c
> index c428d9f..07101e9 100644
> --- a/drivers/mfd/wm831x-core.c
> +++ b/drivers/mfd/wm831x-core.c
> @@ -321,7 +321,6 @@ EXPORT_SYMBOL_GPL(wm831x_set_bits);
> */
> int wm831x_auxadc_read(struct wm831x *wm831x, enum wm831x_auxadc input)
> {
> - int tries = 10;
> int ret, src;
>
> mutex_lock(&wm831x->auxadc_lock);
> @@ -349,13 +348,14 @@ int wm831x_auxadc_read(struct wm831x *wm831x, enum wm831x_auxadc input)
> goto disable;
> }
>
> - do {
> - msleep(1);
> + /* Ignore the result to allow us to soldier on without IRQ hookup */
> + wait_for_completion_timeout(&wm831x->auxadc_done, msecs_to_jiffies(5));
>
> - ret = wm831x_reg_read(wm831x, WM831X_AUXADC_CONTROL);
> - if (ret < 0)
> - ret = WM831X_AUX_CVT_ENA;
> - } while ((ret & WM831X_AUX_CVT_ENA) && --tries);
> + ret = wm831x_reg_read(wm831x, WM831X_AUXADC_CONTROL);
> + if (ret < 0) {
> + dev_err(wm831x->dev, "AUXADC status read failed: %d\n", ret);
> + goto disable;
> + }
>
> if (ret & WM831X_AUX_CVT_ENA) {
> dev_err(wm831x->dev, "Timed out reading AUXADC\n");
> @@ -390,6 +390,15 @@ out:
> }
> EXPORT_SYMBOL_GPL(wm831x_auxadc_read);
>
> +static irqreturn_t wm831x_auxadc_irq(int irq, void *irq_data)
> +{
> + struct wm831x *wm831x = irq_data;
> +
> + complete(&wm831x->auxadc_done);
> +
> + return IRQ_HANDLED;
> +}
> +
> /**
> * wm831x_auxadc_read_uv: Read a voltage from the WM831x AUXADC
> *
> @@ -1411,6 +1420,7 @@ static int wm831x_device_init(struct wm831x *wm831x, unsigned long id, int irq)
> mutex_init(&wm831x->io_lock);
> mutex_init(&wm831x->key_lock);
> mutex_init(&wm831x->auxadc_lock);
> + init_completion(&wm831x->auxadc_done);
> dev_set_drvdata(wm831x->dev, wm831x);
>
> ret = wm831x_reg_read(wm831x, WM831X_PARENT_ID);
> @@ -1523,6 +1533,16 @@ static int wm831x_device_init(struct wm831x *wm831x, unsigned long id, int irq)
> if (ret != 0)
> goto err;
>
> + if (wm831x->irq_base) {
> + ret = request_threaded_irq(wm831x->irq_base +
> + WM831X_IRQ_AUXADC_DATA,
> + NULL, wm831x_auxadc_irq, 0,
> + "auxadc", wm831x);
> + if (ret < 0)
> + dev_err(wm831x->dev, "AUXADC IRQ request failed: %d\n",
> + ret);
> + }
> +
> /* The core device is up, instantiate the subdevices. */
> switch (parent) {
> case WM8310:
> @@ -1593,6 +1613,8 @@ static void wm831x_device_exit(struct wm831x *wm831x)
> {
> wm831x_otp_exit(wm831x);
> mfd_remove_devices(wm831x->dev);
> + if (wm831x->irq_base)
> + free_irq(wm831x->irq_base + WM831X_IRQ_AUXADC_DATA, wm831x);
> wm831x_irq_exit(wm831x);
> kfree(wm831x);
> }
> diff --git a/include/linux/mfd/wm831x/core.h b/include/linux/mfd/wm831x/core.h
> index 53580b5..5915f6e 100644
> --- a/include/linux/mfd/wm831x/core.h
> +++ b/include/linux/mfd/wm831x/core.h
> @@ -15,6 +15,7 @@
> #ifndef __MFD_WM831X_CORE_H__
> #define __MFD_WM831X_CORE_H__
>
> +#include <linux/completion.h>
> #include <linux/interrupt.h>
>
> /*
> @@ -261,6 +262,7 @@ struct wm831x {
> int num_gpio;
>
> struct mutex auxadc_lock;
> + struct completion auxadc_done;
>
> /* The WM831x has a security key blocking access to certain
> * registers. The mutex is taken by the accessors for locking
> --
> 1.7.0
>

==============================================================================
TOPIC: USB mass storage and ARM cache coherency
http://groups.google.com/group/linux.kernel/t/68938cdf1fa061a9?hl=en
==============================================================================

== 1 of 2 ==
Date: Sun, Feb 28 2010 3:20 pm
From: Catalin Marinas

On Fri, 2010-02-26 at 21:49 +0000, Benjamin Herrenschmidt wrote:
> > > > On ARM11MPCore we flush the caches in flush_dcache_page() because the
> > > > cache maintenance operations weren't visible to the other CPUs.
> > >
> > > I'm not even sure that's going to be 100% correct. Don't you also need
> > > to flush the remote icaches when you are dealing with instructions (such
> > > as swap) anyways ?
> >
> > I don't think we tried swap but for pages that have been mapped for the
> > first time, the I-cache would be clean.
> >
> > At mm switching, if a thread
> > migrates to a new CPU we invalidate the cache at that point.
>
> That sounds fragile. What about a multithread app with one thread on
> each core hitting the pages at the same time ? Sounds racy to me...

Interestingly, until commit 826cbdaff29 (< 2 years ago), we didn't have
any I-cache flushing in update_mmu_cache() and it was working fine. I
added it for correctness reasons rather than to fix something. My theory
is that it was working because a page cache page tends to keep the same
physical address, especially if we don't swap pages, and a 16KB PIPT
cache cannot hold enough lines to show any issues (lines are replaced
frequently).

I suspect that's one of the reasons why only invalidating the whole
I-cache when switching the mm to a new CPU seems to suffice. Once we
enable some form of swapping, it may show the problem.

--
Catalin

== 2 of 2 ==
Date: Sun, Feb 28 2010 3:30 pm
From: Catalin Marinas

On Fri, 2010-02-26 at 22:03 +0000, Russell King - ARM Linux wrote:
> On Sat, Feb 27, 2010 at 08:49:40AM +1100, Benjamin Herrenschmidt wrote:
> > It will deadlock if you use normal IRQs. I don't see a good way around
> > that other than using a higher-level type of IRQs. I though ARM has
> > something like that (FIQs ?). Can you use those guys for IPIs ?
[...]
> The other problem we'd encounter using FIQs for IPIs is that some IPIs
> need to take locks - and in order to make that safe, we'd either need
> another class of locks which disable IRQs and FIQs together, or we'd
> need to disable FIQs everywhere we disable IRQs - at which point FIQs
> become utterly pointless.

You could use the FIQ only for the DMA cache maintenance operations and
not as a generic IPI mechanism. But the hardware needs to be modified.

--
Catalin

==============================================================================
TOPIC: linux-next: reminder
http://groups.google.com/group/linux.kernel/t/a4551faa32ba8fdd?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Feb 28 2010 3:40 pm
From: Stephen Rothwell

Hi all,

Please do not put stuff destined for v2.6.35 into linux-next until *after*
Linus' releases v2.6.34-rc1.

Thanks for your cooperation.

--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

==============================================================================
TOPIC: EXT4 is ~2X as slow as XFS (593MB/s vs 304MB/s) for writes?
http://groups.google.com/group/linux.kernel/t/e7b189bcaa2c1cb4?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Feb 28 2010 4:00 pm
From: Dave Chinner

On Sat, Feb 27, 2010 at 06:36:37AM -0500, Justin Piszcz wrote:
> Besides large sequential I/O, ext4 seems to be MUCH faster than XFS when
> working with many small files.
>
> EXT4
>
> p63:/r1# sync; /usr/bin/time bash -c 'tar xf linux-2.6.33.tar; sync'
> 0.18user 2.43system 0:02.86elapsed 91%CPU (0avgtext+0avgdata 5216maxresident)k
> 0inputs+0outputs (0major+971minor)pagefaults 0swaps
> linux-2.6.33 linux-2.6.33.tar
> p63:/r1# sync; /usr/bin/time bash -c 'rm -rf linux-2.6.33; sync'
> 0.02user 0.98system 0:01.03elapsed 97%CPU (0avgtext+0avgdata 5216maxresident)k
> 0inputs+0outputs (0major+865minor)pagefaults 0swaps
>
> XFS
>
> p63:/r1# sync; /usr/bin/time bash -c 'tar xf linux-2.6.33.tar; sync'
> 0.20user 2.62system 1:03.90elapsed 4%CPU (0avgtext+0avgdata 5200maxresident)k
> 0inputs+0outputs (0major+970minor)pagefaults 0swaps
> p63:/r1# sync; /usr/bin/time bash -c 'rm -rf linux-2.6.33; sync'
> 0.03user 2.02system 0:29.04elapsed 7%CPU (0avgtext+0avgdata 5200maxresident)k
> 0inputs+0outputs (0major+864minor)pagefaults 0swaps

Mount XFS with "-o logbsize=262144". Metadata intensive workloads on
XFS are log IO bound, so larger log buffer size makes a big
difference. On 2.6.33 kernels on a single 15krpm SCSI drive I've
been getting ~21s for the untar, and 8s for the rm -rf with that
option set. Still slower than ext4, but nowhere near as bad.

> So I guess that's the tradeoff, for massive I/O you should use XFS, else,
> use EXT4?

I wouldn't consider writing an 11GB file "massive IO", nor would I
consider an 600MB/s massive, either, since you can get that out of a
sub-$10k server these days....

> I still would like to know however, why 350MiB/s seems to be the maximum
> performance I can get from two different md raids (that easily do 600MiB/s
> with XFS).

Check whether the dd process on ext4 is CPU bound....

Cheers,

Dave.
--
Dave Chinner
david@fromorbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: linux-next: manual merge of the omap tree with the tree
http://groups.google.com/group/linux.kernel/t/969028fe9f20fe21?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Feb 28 2010 4:30 pm
From: Stephen Rothwell

Hi all,

Today's linux-next merge of the omap tree got a conflict in
arch/arm/plat-omap/Kconfig between commit
d6d502fa4be1acd01971476fc732c95a4da16d90 ("ARM: 5952/1: ARM: MM: Add
ARM_L1_CACHE_SHIFT_6 for handle inside each ARCH Kconfig") from the arm
tree and commits 56213ca4e440c0b6e56a48f5901c55c4ce3cf1ba ("omap2/3:
Multiboot compile fixes to compile in omap2 and omap3") and
a8eb7ca0cbb41c9cd379b8d2a2a5efb503aa65e9 ("omap3: Replace ARCH_OMAP34XX
with ARCH_OMAP3") from the omap tree.

I fixed it up (see below) and can carry the fix as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au

diff --cc arch/arm/plat-omap/Kconfig
index 2e3eec6,be9484a..0000000
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@@ -19,10 -28,9 +28,10 @@@ config ARCH_OMAP

config ARCH_OMAP3
bool "TI OMAP3"
+ depends on ARCH_OMAP2PLUS
select CPU_V7
- select COMMON_CLKDEV
+ select ARM_L1_CACHE_SHIFT_6
+ select USB_ARCH_HAS_EHCI

config ARCH_OMAP4
bool "TI OMAP4"
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: compiler: prevent dead store elimination
http://groups.google.com/group/linux.kernel/t/1182a2565515906c?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Feb 28 2010 4:40 pm
From: Bill Davidsen

Andi Kleen wrote:
>> Every byte in the [p,p+n[ range must be used. If you only use the
>> first byte, via e.g. asm("" :: "m"(*(char*)p)), then the compiler
>> _will_ skip scrubbing bytes beyond the first. This works with
>> gcc-3.2.3 up to gcc-4.4.3.
>
> You forgot to credit Mikael who did all the hard work figuring
> this out?
>
>> /*
>> + * Dead store elimination (DSE) is an optimization that may remove a write to
>> + * a buffer that is not used anymore. Use ARRAY_PREVENT_DSE after a write when
>> + * the scrub is required for security reasons.
>> + */
>> +#define ARRAY_PREVENT_DSE(p, n) \
>
> Maybe it's just me, but the name is ugly.
>
>> + do { \
>> + struct __scrub { char c[n]; }; \
>
>
> Better typeof(*p)[n]
>
>> +++ b/include/linux/compiler-intel.h
>> @@ -14,9 +14,11 @@
>> * It uses intrinsics to do the equivalent things.
>> */
>> #undef barrier
>> +#undef ARRAY_PREVENT_DSE
>> #undef RELOC_HIDE
>>
>> #define barrier() __memory_barrier()
>> +#define ARRAY_PREVENT_DSE(p, n)
>
> Who says the Intel compiler doesn't need this?
>
> I'm sure it does dead store elimination too and it understands
> gcc asm syntax.
>
According to the Intel forum, it not only doesn't, but a request for this as a
feature was rejected, so it won't. Or am I misreading this?

http://software.intel.com/en-us/forums/showthread.php?t=46770

--
Bill Davidsen <davidsen@tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot

==============================================================================
TOPIC: Loan Agency
http://groups.google.com/group/linux.kernel/t/879444cd158d03cf?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Feb 28 2010 4:50 pm
From: Nationwide Finance and loan company

Nationwide Finance and loan company, is happy to inform you that we are giving out loan to individuals at 3% interest rate. Interested applicant should send a notification.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: [PATCH 1/2] memcg: oom kill handling improvement
http://groups.google.com/group/linux.kernel/t/178d74044405d9f7?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Feb 28 2010 5:00 pm
From: KAMEZAWA Hiroyuki

On Fri, 26 Feb 2010 21:30:15 +0900
Daisuke Nishimura <d-nishimura@mtf.biglobe.ne.jp> wrote:

> On Fri, 26 Feb 2010 16:17:52 +0900
> KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:

> > Okay. following is a candidate we can have. This will be incomplete until
> > we have oom notifier for memcg but may be better than miss-firing
> > page_fault_out_of_memory. Nishimura-san, how do you think this ?
> > (Added Andrew to CC.)
> >
> Thank you very much for your patch.
> I agree it's enough for quick fix, and it seems to work.
>
> > ==
> >
> > From: KAMEZAWA Hiroyuk <kamezawa.hiroyu@jp.fujitsu.com>
> >
> > In current page-fault code,
> >
> > handle_mm_fault()
> > -> ...
> > -> mem_cgroup_charge()
> > -> map page or handle error.
> > -> check return code.
> >
> > If page fault's return code is VM_FAULT_OOM, page_fault_out_of_memory()
> > is called. But if it's caused by memcg, OOM should have been already
> > invoked.
> > Then, I added a patch: a636b327f731143ccc544b966cfd8de6cb6d72c6
> >
> > That patch records last_oom_jiffies for memcg's sub-hierarchy and
> > prevents page_fault_out_of_memory from being invoked in near future.
> >
> > But Nishimura-san reported that check by jiffies is not enough
> > when the system is terribly heavy.
> >
> > This patch changes memcg's oom logic as.
> > * If memcg causes OOM-kill, continue to retry.
> > * memcg hangs when there are no task to be killed.
> IIUC, this behavior is the same as current behavior. mem_cgroup_out_of_memory()
> hangs if all of the tasks in the cgroup are OOM_DISABLE'ed.
>

Ah, yes. I'll add that comment.

> > * remove jiffies check which is used now.
> >
> > TODO:
> > * add oom notifier for informing management daemon.
> > * more clever sleep logic for avoiding to use much CPU.
> >
> > Signed-off-by: KAMEZAWA Hiroyuk <kamezawa.hiroyu@jp.fujitsu.com>
> > ---
> > include/linux/memcontrol.h | 6 ----
> > mm/memcontrol.c | 56 ++++++++++++++++-----------------------------
> > mm/oom_kill.c | 28 ++++++++++++----------
> > 3 files changed, 37 insertions(+), 53 deletions(-)
> >
> > Index: mmotm-2.6.33-Feb11/include/linux/memcontrol.h
> > ===================================================================
> > --- mmotm-2.6.33-Feb11.orig/include/linux/memcontrol.h
> > +++ mmotm-2.6.33-Feb11/include/linux/memcontrol.h
> > @@ -124,7 +124,6 @@ static inline bool mem_cgroup_disabled(v
> > return false;
> > }
> >
> > -extern bool mem_cgroup_oom_called(struct task_struct *task);
> > void mem_cgroup_update_file_mapped(struct page *page, int val);
> > unsigned long mem_cgroup_soft_limit_reclaim(struct zone *zone, int order,
> > gfp_t gfp_mask, int nid,
> > @@ -258,11 +257,6 @@ static inline bool mem_cgroup_disabled(v
> > return true;
> > }
> >
> > -static inline bool mem_cgroup_oom_called(struct task_struct *task)
> > -{
> > - return false;
> > -}
> > -
> > static inline int
> > mem_cgroup_inactive_anon_is_low(struct mem_cgroup *memcg)
> > {
> > Index: mmotm-2.6.33-Feb11/mm/memcontrol.c
> > ===================================================================
> > --- mmotm-2.6.33-Feb11.orig/mm/memcontrol.c
> > +++ mmotm-2.6.33-Feb11/mm/memcontrol.c
> > @@ -200,7 +200,6 @@ struct mem_cgroup {
> > * Should the accounting and control be hierarchical, per subtree?
> > */
> > bool use_hierarchy;
> > - unsigned long last_oom_jiffies;
> > atomic_t refcnt;
> >
> > unsigned int swappiness;
> > @@ -1234,34 +1233,6 @@ static int mem_cgroup_hierarchical_recla
> > return total;
> > }
> >
> > -
> > /*
> > * Currently used to update mapped file statistics, but the routine can be
> > * generalized to update other statistics as well.
> > @@ -1549,11 +1520,27 @@ static int __mem_cgroup_try_charge(struc
> > }
> >
> > if (!nr_retries--) {
> > - if (oom) {
> > - mem_cgroup_out_of_memory(mem_over_limit, gfp_mask);
> > - record_last_oom(mem_over_limit);
> > + if (!oom)
> > + goto nomem;
> > + mem_cgroup_out_of_memory(mem_over_limit, gfp_mask);
> > + /*
> > + * If killed someone, we can retry. If killed myself,
> > + * allow to go ahead in force.
> > + *
> > + * Note: There may be a case we can never kill any
> > + * processes under us.(by OOM_DISABLE) But, in that
> > + * case, if we return -ENOMEM, pagefault_out_of_memory
> > + * will kill someone innocent, out of this memcg.
> > + * So, what we can do is just try harder..
> > + */
> > + if (test_thread_flag(TIF_MEMDIE)) {
> Is "if (test_thread_flag(TIF_MEMDIE) || fatal_signal_pending(current))" better
> to accept SIGKILL ?
>
Hmm, ok, will add that. One problem of TIF_MEMDIE is that it's added to a thread
not to a process.

> > + css_put(&mem->css);
> > + *memcg = NULL;
> > + return 0;
> > }
> > - goto nomem;
> > + /* give chance to run */
> > + schedule_timeout(1);
> > + nr_retries = MEM_CGROUP_RECLAIM_RETRIES;
> > }
> > }
> > if (csize > PAGE_SIZE)
> > @@ -2408,8 +2395,7 @@ void mem_cgroup_end_migration(struct mem
> >
> > /*
> > * A call to try to shrink memory usage on charge failure at shmem's swapin.
> > - * Calling hierarchical_reclaim is not enough because we should update
> > - * last_oom_jiffies to prevent pagefault_out_of_memory from invoking global OOM.
> > + * Calling hierarchical_reclaim is not enough. We may have to call OOM.
> > * Moreover considering hierarchy, we should reclaim from the mem_over_limit,
> > * not from the memcg which this page would be charged to.
> > * try_charge_swapin does all of these works properly.
> > Index: mmotm-2.6.33-Feb11/mm/oom_kill.c
> > ===================================================================
> > --- mmotm-2.6.33-Feb11.orig/mm/oom_kill.c
> > +++ mmotm-2.6.33-Feb11/mm/oom_kill.c
> > @@ -466,27 +466,39 @@ static int oom_kill_process(struct task_
> > }
> >
> > #ifdef CONFIG_CGROUP_MEM_RES_CTLR
> > +/*
> > + * When select_bad_process() can't find proper process and we failed to
> > + * kill current, returns 0 as faiulre of OOM-kill. Otherwise, returns 1.
> > + */
> hmm, what function does this comment describe ?
> mem_cgroup_out_of_memory() returns void.
>
Ahhh, I'll remove this. This is garbage.

I'll clean up this and post as quick-fix.

Thanks,
-Kame

>
> Thanks,
> Daisuke Nishimura.
>
> > void mem_cgroup_out_of_memory(struct mem_cgroup *mem, gfp_t gfp_mask)
> > {
> > unsigned long points = 0;
> > struct task_struct *p;
> > + int not_found = 0;
> >
> > if (sysctl_panic_on_oom == 2)
> > panic("out of memory(memcg). panic_on_oom is selected.\n");
> > read_lock(&tasklist_lock);
> > retry:
> > + not_found = 0;
> > p = select_bad_process(&points, mem);
> > if (PTR_ERR(p) == -1UL)
> > goto out;
> > -
> > - if (!p)
> > + if (!p) {
> > + not_found = 1;
> > p = current;
> > + printk(KERN_ERR "It seems there are no killable processes "
> > + "under memcg in OOM. Try to kill current\n");
> > + }
> >
> > if (oom_kill_process(p, gfp_mask, 0, points, mem,
> > - "Memory cgroup out of memory"))
> > - goto retry;
> > + "Memory cgroup out of memory")) {
> > + if (!not_found) /* some race with OOM_DISABLE etc ? */
> > + goto retry;
> > + }
> > out:
> > read_unlock(&tasklist_lock);
> > + /* Even if we don't kill any, give chance to try to recalim more */
> > }
> >

twitter

Sunday, February 28, 2010

linux.kernel - 26 new messages in 20 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts